dns exploit

[Brian Keefer]

On Jul 25, 2008, at 11:43 PM, Chris Buxton wrote:
>
> On Jul 25, 2008, at 11:30 PM, Brian Keefer wrote:
>
>> I just looked at it a bit more closely...
>>
>> I'm using OpenBSD for my firewall and my nameservers.  The  
>> firewall is 3.5, the nameservers are 4.3.  The firewall is just  
>> doing standard PF nat for outbound requests.  Whether I used the  
>> doxpara tool, or dns-oarc the source ports from my recursive  
>> resolver were the same (pre-patch), but on the external interface  
>> of my firewall, the packets to doxpara did not get randomized  
>> ports, while those to dns-oarc did.  Post-patch the resolver  
>> itself has random source ports, so it's moot.


I verified that they're random on the external side of my firewall,  
in addition to simply be random coming out of my resolver on the  
internal net.

> I'm not exactly sure what you said, but I do know that if your  
> firewall or port forwarder is changing the source ports of outbound  
> queries to be something predictable, or to be all the same, then  
> you have a problem. The patch on your name server is not enough -  
> you also have to fix your firewall.
>

In English it translates close enough as:  In one set of cases my  
firewall was randomizing the ports from the original static values,  
while in another set of cases it was not randomizing them from the  
original static values.  I found this very odd.  Since applying the  
patch they're random on both sides.

> Linux iptables does not appear to change source ports.
>
> Chris Buxton
> Professional Services
> Men & Mice
>

Not by default, but people have written custom netfilter/iptables  
rules to do it.

iptables:
http://cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning- 
attacks-with-iptables.html

PF:
http://blog.spoofed.org/2008/07/mitigating-dns-cache-poisoning-with- 
pf.html

Any way, I welcome the continued discussion as it seems like this  
will be a very long and laborious procedure to get even 80% of  
network infrastructure protected.  I spent half the day today  
tracking down servers at work that needed to be patched, and fixing  
some that had query-source-port 53; //sigh

Fortunately smart folks have pointed out forwarding requests to  
patched resolvers, or using packet filter port randomization as  
immediate work-arounds until permanent solutions can be put into place.

Brian Keefer
Sr. Systems Engineer
www.Proofpoint.com
"Defend email.  Protect data."