View Single Post
Old 13th January 2010
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by joostvgh View Post
Ok. I thought openbsd would work as forwarding dns server automatically and answer dns requests itself by first looking in the file and then bind, but this is not the fact then.
All resolv.conf has is a set of rules for OpenBSD's own name and address resolution. It can point to /etc/conf, and it can point to one or more DNS servers, on behalf of internal requests, such as performanced by the gethostbyname(3) library call.

OpenBSD, configured as a router, will forward IP packets without inspection. If you enable PF, only the link layer is inspected (IP addresses, protocol, port, flags...), not the internal packet payloads.

A DNS resolution request sent over a network must be handled by a DNS server. By convention (and RFC), these are sent either via UDP or TCP protocols, using destination port # 53. However, I can tunnel them another way, if you block external DNS traffic.
Quote:
So if I wanted to make it act as DNS, all clients should have it as their (only) dns. To do this I thought i had to enable DHCP too. So then I should add NAT too.
You misundertand both DHCP and NAT. Allow me to provide a small amount of level-setting:
  • DHCP is primarily used for automatic TCP/IP configuration. It has no impact on security whatsoever, and any belief that it has an impact on security is magical thinking. I will restate what I wrote above, regarding DHCP: the server can send the client IP address and other TCP/IP configuration information. The client can agree, disagree, or accept and then ignore any information provided by the server.
  • NAT is used to share a single public IP address among multiple private network users. Unlike DHCP though, NAT can indeed impact security, but not the security you have been asking for in this thread. All NAT can do is prevent unanticipated traffic from being forwarded from the NAT device inward to a destination on the private network. Outbound sessions using NAT will have traffic directed to them via state table management; inbound sessions must be configured for acceptance (such as "port forwarding" for TCP and UDP protocol). That is all.

Quote:
Then if opendns were the dns server I could add rapidshare.com to its hosts file and the problem would be 'solved' (ok workarounds are always possible).
As I have stated, several times already, anyone can defeat a DNS-based security implementation. A few minutes with Google and you can obtain a "how to" for your OS of choice, including prebuilt software solutions to install. You will only stop the person who is lazy, you will never stop someone who knows how to use a search engine, and the questions to ask.
Quote:
I would also add all 'current' (and for our dns-servers) rapidshare ip's to a blocked list, as well as all other dns servers (other than openbsd).

The 'only' way then to access rapidshare would be through another ip (which I don't know), or a proxy?
PF is started before BIND or a 3rd party DNS server daemon. If OpenBSD is both your router and your server, you will have to load your DNS-based rules after the DNS daemon is already up and running, and not have them in the pf.conf file used at start up. This requires PF's anchor subsystem.
Quote:
If I don't make openbsd the dns server then I can only add the 21 current rapidshare ip's to a blocking rule and all other dns servers than the 2 provided by the ISP.

Correct?
You will have to determine what domain names are actually used, and add them to your various block rules.

Once more -- you could hunt down and block every single IP address that is actually used by Rapidshare, and set up your own DNS servers with false addresses, but you will not stop anyone from using Rapidshare who actually wants to, and is willing to spend five minutes with Google.
Examples of only a few of the many technologies that could be used to defeat your "security theater" depending on its eventual configuration:
SSH
VPN
Tor
Corkscrew
SOCKS
Squid
IPSec
.
.
.

(The list is effectively endless. Some can be used in combination with others, or, be used by themselves.)

Last edited by jggimi; 13th January 2010 at 07:01 PM.
Reply With Quote