[nSLUG] firewalls that can prevent DNS rebinding attack

Rich budman85 at eastlink.ca
Sat Aug 11 20:43:12 ADT 2007



Ian Campbell wrote:
> On Wed, Aug 08, 2007 at 10:08:03AM -0300, D G Teed wrote:
>   
>> On slashdot the other day, there was a reference to a Stanford University
>> paper on security threats from DNS rebinding, with proof of concept.
>>
>> http://crypto.stanford.edu.nyud.net/dns/dns-rebinding.pdf
>>
>> Essentially, a malicious DNS server and web site can be set up
>> with short TTLs so that it can alter the resolved IP periodically
>> and use your web browser as a network client behind your firewall
>> or within your VPN to their liking.
>>
>> I've also googled this topic and it is being discussed all over the place,
>> but with no specific solutions.  Historically, a disclosure like this,
>> with proof of concept, is followed by the appearance of real malicious
>> threats.
>>
>> The conclusion at the end of the article mentions:
>>
>>   firewalls should block circumvention by preventing external
>>   DNS names from resolving to internal IP addresses
>>
>> Has anyone knowledge of a firewall product (or a rule in iptables) which
>> can do this blocking?
>>     
>
> I can't think of anything that will do it right now, but depending on
> your enthusiasm and amount of free time, I can think of a couple of
> options:
>
> 1) Should be able to do it with l7-filter (http://l7-filter.sf.net/)
> relatively easily -- write a pattern that matches an answer record
> with your IP range in that comes in on an external interface.
>
> ... or snort, for that matter. Anything that will let you apply a
> regexp to packets. While writing the regexp, keep in mind that it
> should match all record types, not just the obvious ones like A.
>
> 2) May be able to do it with --hex-string-match in iptables, but that
> would require you to have it skip bytes in a packet (the TTL, which is
> in between type+class and length+addr) ... and it's not immediately
> clear that you can.
>
> 3) You could run a caching nameserver locally that's patched to ignore
> local ips in responses to recursive requests. I haven't looked at the
> BIND source, but I can't imagine it would be THAT hard to add.
> Obviously you'd have to force all requests through that nameserver for
> it to be effective.
>
> 4) You could run a caching nameserver locally that enforces a minimum
> (arbitrary) TTL, something greater than the session length your
> vulnerable app is interacting with the malicious server, and
> overriding any TTL accompanying the record. Not a great idea, but it
> would work... somewhat.
>   

I agree.  If you can I'd run a local DNS and filter out any DNS requests 
coming thru the firewall.
Force it to only accept the root servers for updates, and block any 
reroutes.

However, after reading the article, it seems the classic round robin 
load balancing in bind is causing one of the problems.
Maybe its time to disable software balancing... never really worked any 
way...  hardware balancing works more efficiently.

Browsers deciding speed was better than security is really sad.  Thats 
good to know about flash and other plugins.
Maybe running flashblock would help - no flash runs unless you click 
play.  I kind of like it, no more ads in my face.
But once you click play.. you can be redirected. 

The article doesn't mention if any packet analysis was done to see if a 
sniffer would help. (unless I missed it)
I found the article rather interesting and would like to see future 
developments.
Luckily, Linux doesn't have the multitude of plugins Windows does - but 
I can see where this can get really ugly.


Thanks for sharing
Rich







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20070811/5d927968/attachment-0001.html>


More information about the nSLUG mailing list