[nSLUG] firewalls that can prevent DNS rebinding attack
ian at slu.ms
Wed Aug 8 11:19:30 ADT 2007
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.
> 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
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the nSLUG