DNS rebinding: prevention?

[Chris Buxton]

Mark,

Please explain where you think the flaw is.

Is it the job of the web browser to understand what IP space is  
private and what is public? Is it the job of the browser to create  
its own DNS cache? Isn't it valuable that a web browser be responsive  
to changes in DNS?

Web servers should always use name-based virtual hosts, with no  
default site, in order to somewhat prevent the attack (but the  
attacker can still use this method to find out what IP addresses have  
web servers, or other open ports). But there is a plethora of reasons  
why this is often not done. And FTP service doesn't have the concept  
at all, but the attack can work just as well against FTP as HTTP.

In order to protect private data which should be freely available  
within an intranet but completely hidden from the outside, without  
crippling the browser's ability to adapt to DNS changes, one of the  
following must be done, as I see it:

- The browser (on every client machine) must know what domains should  
map to internal addresses, and should know what the private IP space  
looks like.

- The resolving name server must be prevented from returning private,  
internal addresses in A records whose names are not trusted.

It seems to me that the following are true:

- Any layer 7 firewall that understands and inspects DNS messages  
should easily be extensible to have a list of internal subnets and  
filter responses based on that list. For example, if no outside name  
servers should know anything about the internal subnets, drop any  
inbound response (or outbound response, for that matter) that  
contains such an address. Or if there are external servers that  
should be able to return such addresses, special-case them in an  
exceptions list; this option must be used with care.

- To help protect the private subnets of those organizations without  
a layer 7 firewall, the resolving name server (BIND, dnsmasq, etc.)  
should be configurable with a list of private subnets and the  
authoritative servers that should be allowed to return answers  
containing addresses from those subnets. Perhaps something involving  
a default behavior in the case of conditional forwarding would make  
this easier to configure, or perhaps it would be simplest to ignore  
that. I foresee an option substatement named "private-subnets" that  
takes an ACL, plus a new server substatement named "allow-private- 
subnets".

I really don't see this as being much more difficult for named to  
process than sorting responses by network topology, or the zone type  
"delegation-only". And for a large organization that uses global  
forwarding from small resolvers to big forwarders, it's something  
that can be set up on the big forwarders on the edges of the network.

Chris Buxton
Men & Mice

On Aug 6, 2007, at 10:00 PM, Mark Andrews wrote:

>
> 	It's also not as straight forward as people seem to think.
>
> 	You would need lots of exception processing which would be
> 	a combination of name and/or address and/or tsig pairs.
> 	All of this to "fix" a flawed security model.
> 	
> 	Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>
>