Re: DNS Speculation

["Joseph Patterson" <jpatterson () terremark com>]

________________________________

From: Jeff Jarmoc [mailto:jeff () jarmoc com] 
Sent: Wednesday, July 23, 2008 8:19 PM
To: Joseph Patterson
Subject: Re: [Dailydave] DNS Speculation

 

Sorry if you're getting multiple message from me.. my email client is
acting wonky.

I think you're underestimating the impact of this pretty significantly.



[Joseph Patterson] Quite possibly.


Anyhow - "the DNS resolver is behind a firewall that does source port
randomization for it (I know Cisco PIX/ASA does this by default and has
for some time, probably others do as well)"

That's flat out not true.  Cisco doesn't have an option to randomize
source ports either with DNS inspection, PAT, or any other feature.
I've heard from Cisco that this is going to be included in ASA v8.0(4)
due out real soon now.. 



[Joseph Patterson] I stand corrected.  I swear that I read about the ASA
doing that in version 7.x on this page:
http://www.cisco.com/web/about/security/intelligence/dns-bcp.html just
yesterday, but I was wrong on two counts... first because that page
*doesn't* say that, and second because I didn't check it myself even
though I had the capability (I just checked, and saw a whole bunch of
identical source ports.  Sigh.)


In fact, not only that, but putting a patched server behind a firewall
might make things worse.  Cisco's PAT configuration will allocate ports,
sequentially, for each connection it sees.  Since there's very little
outbound UDP traffic on most networks, this means that rapidly sending
multiple DNS requests from a patched server will almost certainly result
in an ASA sequentializing the once-random ports, if it goes through a
PAT.  With static routes you're somewhat safer, as there's no port
modification so random source ports remain random.

Checkpoint isn't much better.  PATs (Hide NATs in Checkpoint parlance)
do the same thing.  However, Checkpoint does have a feature as part of
it's DNS Application inspection called 'port scrambling' which allows
you to scramble source ports of DNS requests... I've not tested it, but
if it works as advertised it could provide a decent level of protection
for both patched and unpatched servers.

As for your points;

1.      the DNS resolver already uses source port randomization (several
do) 
2.      the DNS resolver is behind a firewall that does source port
randomization for it (I know Cisco PIX/ASA does this by default and has
for some time, probably others do as well) 
3.      There's RPF in the middle 
4.      the DNS resolver doesn't cache.  That isn't all *that* uncommon.

5.      DNSSEC is being used all the way up the chain (probably less
common than non-caching resolvers) 


1 - Several do *NOW*  two weeks ago, the vast majority of servers used
totally static, or static from time of instantiation, source ports.

[Joseph Patterson] Once again, I stand corrected.  I had looked briefly
at bind's queryport-pool stuff, but on further inspection, that *isn't*
particularly useful.


2 - Addressed above, also see; http://blogs.iss.net/archive/dnsnat.html
3 - RPF is really not all that common, and the further you get from the
true source, the less likely it is to be effected.  After all, I can do
RPF on my border router, but if the whole internet is on one end, it's
not going to be all that effective.  If RPF hasn't been able to stop
spoofed SPAM, it won't be able to stop spoofed DNS.

[Joseph Patterson] Yeah, RPF isn't that common, and that's a shame...
It's one of those things that would help out in a lot of places, but is
hard to push for... endpoints don't get much good out of it for exactly
the reason you say (although I still think they should do it to prevent
spoofed packets from malware in their organization), and it's difficult
to do in the core where there's much higher chances for asymmetric
routing, so the best place for it is small ISP's, and possibly at the
edge of some larger ones... and it's a hard sell there.

4 - Yah.. not very common and would likely degrade performance
significantly if it were.

[Joseph Patterson] I recall one place I worked where their entire
organization used a single publicly available DNS server that did no
caching.  And yes, performance was a significant issue.  Installing an
internal resolver for them made a huge difference to almost everything.

5 - DNSSEC is really the only real proposal I see for a long term fix to
this.. but it's just that - a proposal.  Until we have a unified,
internet-wide PKI system deployed in reality, DNSSEC is just a dream.
It's got about as much likelihood of being widely deployed in the near
future as IPv6....



 [Joseph Patterson] yah.  I like it, but it is a hard sell.  Even the
people evangelizing it start out with "here's a list of the problems
you're going to have to live with... but it's still worth it!"

-Joe

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave