Glad to have helped! I have tried to scrutinise the amazingly complex SuSEfirewall2 script to understand it better. I more or less understood SuSEfirewall but this adds orders of magnitudes of complexity, I'm still trying to get my head round the best way to use/reason for use of all these tables in iptables - I was "brought up" on ipchains, which my small mind could just about handle! :) One of the things that FW_SERVICE_DNS does is implicitly open UDP highports and this is unfortunately critical it seems. From what I understand of IP, having looked at the RFCs (very educational they are too!) TCP/IP (which is what people are used to thinking in terms of) makes reliable two-way connections. Outbound and inbound traffic have serial numbers on the packets kinda thing so it's easy for a firewall to work out what's the return traffic. UDP was designed to be "connectionless" so that packets come and go, some are dropped, etc. All sounds casual but the resulting improvement in speed is critical for many applications, including DNS, as I understand it. The downside is that returning UDP packets could be as a result of querys that you've sent or "other". I think this is where you have to trust that your server (BIND or whatever) that's listening on the high UDP ports will be hardened and not fall over like a Microsoft product in a stiff breeze. One of the universal helping features as I see it is that "random" highports are used so the worms would have to hit a moving target. My answers, such as they are!... 1) I was somewhat aware that I wasn't making this clear as I wrote! The port that DNS querys go to is 53. That should not be open on your external UDP services. So if you have a line like FW_SERVICES_EXT_UDP="domain" then I'd suggest that you remove the "domain" (or 53 if in numeric form) . On the other hand I was talking about my hack to get round the protection of global services (which affects high and low ports, UDP and TCP) so that returning traffic from the DNS servers being queried wasn't blocked. SuSEfirewall2 seems to have a few bits in it to get around this problem so my "hack" is probably not needed with SuSEfirewall2. Whichever way you do it, you won't have a DNS that's receiving queries from the internet - it will just be receiving the replies to its queries. The best way to make sure? Go to one of the many sites that do portscans and firewall hardness checks. They will tell you soon enough what ports you've got open that might be vulnerable to attack. Most of the sites are Windows-centric but that's OK. I did a quick Google for "scan my firewall" and got www.auditmypc.com, give it a go - it may well give you a nice warm "I'm glad I use Linux with an enterprise strength firewall" type feeling! :) 2) Absolutely. The host command takes a second parameter - the DNS you want to query, e.g. ... root@myhost:~ # host www.microsoft.com localhost Using domain server: Name: localhost Address: 127.0.0.1 Aliases: www.microsoft.com is a nickname for www.microsoft.com.edgesuite.net www.microsoft.com.edgesuite.net is a nickname for a562.cd.akamai.net a562.cd.akamai.net has address 80.15.236.25 a562.cd.akamai.net has address 80.15.236.17 a562.cd.akamai.net has address 80.15.236.16 a562.cd.akamai.net has address 80.15.236.14 a562.cd.akamai.net has address 80.15.236.33 ...versus... root@myhost:~ # host www.microsoft.com 195.82.96.40 Using domain server 195.82.96.40: www.microsoft.com is a nickname for www.microsoft.com.edgesuite.net www.microsoft.com.edgesuite.net is a nickname for a562.cd.akamai.net a562.cd.akamai.net has address 80.15.236.14 a562.cd.akamai.net has address 80.15.236.33 a562.cd.akamai.net has address 80.15.236.25 a562.cd.akamai.net has address 80.15.236.17 a562.cd.akamai.net has address 80.15.236.16 This command is critical for working out where DNS issues are coming from! 3) You got me! I don't know! I think they're something like "timeout" and probably more to do with DNS replication. With the files we're using that are "master" files they probably have no effect... probably! :) Hope this all reassures you! Carl Peto ("JJ")
From: "Philip B Cook"
To: "J J" , Subject: Re: [suse-security] Automatically Updating named (bind9) with local address translations Date: Wed, 17 Sep 2003 17:21:47 +0100 JJ,
many thanks for your comprehensive reply. I have been away a few days, so have not had chance to follow your instructions.
I am now up and running successfully.
In addition to your instructions, I had to also do the following... in case anyone else out there can learn from my experience.
1. I stopped my gateway machine using automatic settings for DNS servers from my cable company and instead directed it to use 127.0.0.1 (the loopback address). This way my gateway can also query IP addresses on the local network from BIND 9.
As you said I have placed the cable companies DNS servers in the Forwarders statement in named.conf
2. I also had to add the line
FW_SERVICE_DNS="yes"
to my SuSEfirewall2 configuration file. So as to allow the local DNS server to be accessed.
3. I have added named (BIND 9) into Run Level 3 & 5
I found a text on zone files which helped me understand the contents of these.
I do have three final questions ...
1. Is my DNS server now visible from the INTERNET .. how can I tell ? I dont want it to be. 2. Is there a way to directly query the DNS server and know the result has come from there and not some other name resolution process. 3. What does the repeated 172800 (equiv seconds in 2 days) mean in your example of a zone file. I didnt seem to need them, and my zone file text did not mention any entry in this position of each line of the file.
Many, many thanks for your help.
Philip
----- Original Message ----- From: "J J"
To: ; Sent: Sunday, September 14, 2003 11:49 AM Subject: Re: [suse-security] Automatically Updating named (bind9) with local address translations Yes, this isn't too hard.
(I used to run a configuration almost exactly like the one you say. The differences were trivial - masquerading instead of proxy and SuSEfirewall instead of SuSEfirewall2.)
The first thing you need to do after installing BIND9 is set it to run automatically, configure it to forward DNS requests to your ISPs DNS servers and set the dhcp daemon so that clients query your gateway's server instead of the ISPs DNSes. You said that was "easy" so I won't go on about it here, tell me if you have any problems with that! :)
You'll need to create "zone definition" files for the computers on your local network and refer to them in /etc/named.conf. Taking the example of my network, which is running on 192.168.0.0 subnet mask 255.255.255.0...
You'll probably already have the following entries in named.conf:
zone "localhost" in { type master; file "localhost.zone"; };
zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; };
Copy these entries to create new entries for your subnet, e.g.
zone "bookman-headoffice.co.uk" in { type master; file "bookman-headoffice.zone"; allow-update { 192.168.0/24; 127/8; }; };
zone "0.168.192.in-addr.arpa" in { type master; file "192.168.0.zone"; allow-update { 192.168.0/24; 127/8; }; };
Note the extra clause in each entry? That's the critical bit. It allows the dhcp server to update the DNS server.
In the DNS directory (I think /var/lib/named for the SuSE 8.2 BIND9 package), copy the zone definition files for localhost as a template for your new zone definition files.
For example:
$ORIGIN co.uk. bookman-headoffice 172800 IN SOA localhost. root.localhost. ( 20021086 10800 900 604800 86400 ) ;Cl=3 172800 IN NS localhost. ;Cl=3 172800 IN MX 10 gateway.bookman-headoffice.co.uk. ;Cl=3 172800 IN A 192.168.0.127 ;Cl=3
$ORIGIN bookman-headoffice.co.uk.
host1 172800 IN A 192.168.0.127 ;Cl=3
It's going to be too complex for me to explain zone definition files on this mailing list but the documentation with BIND9 seems good (I use BIND8 in production) and the example files look good. You won't need to put in all the host definitions, of course, because we're hoping that dhcp will do that for you!
Next set the dhcpd.conf file to trigger these automatic updates:
ddns-update-style interim;
And you should be away. When the dhcp server grants a lease it should also update the DNS server with the hostname that the client gives it.
I couldn't get M$ clients to update the DNS server themselves - probably some proprietory protocol stuff - but setting them all with useful hostnames and all to get their IP address from my SuSE 7.2 gateway got round the problem, as I've described.
Hope this helps. Tell me if you succeed!
Carl (aka. "JJ")
From: "Philip B Cook"
To: Subject: [suse-security] Automatically Updating named (bind9) with local address translations Date: Sat, 13 Sep 2003 17:00:40 +0100 I am successfully using SuSE Linux as a gateway, router and http proxy.
I am connected to the internet via a Cable Modem. The Linux machine is running Squid, SuSEfirewall2, dhcpcd and Samba (smbd and nmbd).
My local machines get their IP addresses from the dhcpcd server, these are allocated dynamically. DHCPCD tells each machine to use the Cable Companies two DNS servers for name resolution. I would like to use named (BIND9) to provide a local cache of internet addresses, which is easy, but how can I also provide name resolution for each of the local machines from BIND9 without having to use static IP addresses on my local network or use fixed addressing for each MAC address in DHCPD.
Once a local machine gets an IP address from DHCPCD can this information be given to BIND9 so that it will do local lookups as well as caching internet addresses. Can this be done by either the server or the hosts.
Thanks ...
Philip
_________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
_________________________________________________________________ Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile