...making Linux just a little more fun!
Rick Moen [rick at linuxmafia.com]
Two posts that help clarify the threat model.
----- Forwarded message from Keith Owens <kaos@ocs.com.au> -----
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-12) with nmh-1.2
From: Keith Owens <kaos@ocs.com.au> To: luv-main@luv.asn.au Date: Fri, 25 Jul 2008 12:10:40 +1000 Subject: Re: DNS Exploit: Fix for older Fedora machines??"Leigh Sharpe" (on Fri, 25 Jul 2008 11:56:41 +1000) wrote:
> I have a couple of older FC2 machines running bind DNS. Is there an rpm >available with the fix for the recent DNS exploit? Or am I stuck with >the choice of compiling from source or upgrading the OS?
You need a version of bind9 that is less than 2 months old. bind8 is not being fixed. If Redhat do not have a recent bind9 for FC2 then get the latest src.rpm and build your own.
Alternatively install a small machine running a newer OS with a fixed DNS server and direct all DNS queries via that machine. It is only the final query (the one that hits the outside world) that needs to come from a fixed DNS server. Add firewall rules to block DNS queries from any other machine to the outside world.
Also turn off recursion for DNS queries that come from outside your site and are not for sites in your DNS. One of the ways that attackers are getting information is by issuing recursive requests to your DNS and pointing back at their machines. If you allow external recursive requests then it is much easier for an attacker to get information about your DNS's internal state.
Not sure how to turn off recursion for external requests? See https://www.cymru.com/Documents/secure-bind-template.html
----- End forwarded message ----- ----- Forwarded message from Keith Owens <kaos@ocs.com.au> -----
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-12) with nmh-1.2
From: Keith Owens <kaos@ocs.com.au> To: James Harper <james.harper@bendigoit.com.au>cc: luv-main@luv.asn.au
Date: Fri, 25 Jul 2008 11:24:36 +1000 Subject: Re: DNS exploit: watch out for NAT boxes"James Harper" (on Fri, 25 Jul 2008 11:04:15 +1000) wrote:
>> Even if your DNS server is using random ports (say 10978, 15737, >60925, >> 24758 from a recent trace), the NAT box may map those random ports to >a >> sequential sequence (say 12786, 12787, 12788, 12789). This is a nasty >> side effect of the way that some NAT boxes do the mapping from >internal >> to external port numbers, many just pick the next free external port >> number. This effectively removes the effect of source port >> randomization and you are left with just the 16 bits of the TXID for >> protection. That reduces the number of possible TXID/source port >> combinations from 4294967296 to 65536 and makes it much easier for an >> attacker to hack your DNS. All right, maybe 65536*(a small number) >> possibilities. > >Doesn't the attacker still have to guess the port number though? If the >attacker knew that the box had just started up it could make some >assumptions about the port number being low, but apart from that, a >series of incrementing numbers is still 'random' as far as a third party >is concerned, unless that third party can somehow gain some insight into >where in the sequence your nat box is up to, and if they could do that >then you are probably pwned already.
All the exploits start by making a query using your DNS, either a direct query from outside or via some external code that generates a DNS query from inside. If the initial query is from inside (say a link on a poisoned web page which you view) then that gives the attacker a starting point for the source port sequence. You are not pwned at that stage, it is just a normal DNS operation.
>It might be a good idea to make sure your firewall isn't sending any >responses to undeliverable udp packets too, as that would be giving the >attacker information they could use, eg by finding a port that is >accepting udp responses they might be able to determine where in the >sequence you are up to...
A NAT box will only accept a UDP packet if it matches the entire tuple of source IP, source port, destination IP and destination port. While the last two are fixed (your IP, port 53) the attacker would have to use a valid source IP and port to get a response from an open port and, by definition, that response will then go the source IP of the query, not to the attacker. IOW, mapping which ports are open to the attacker gives no information about which ports are open to other IP addresses and vice versa.
Of course, you are still vulnerable to man in the middle attacks from anybody who can intercept your packets upstream. Unfortunately that is true even with the DNS fixes. AFAIK the only way of avoiding MIM attacks on DNS over open circuits is to use DNSSEC.
----- End forwarded message -----