DNS rebinding: prevention?
Chris Buxton
cbuxton at menandmice.com
Wed Aug 8 01:26:40 UTC 2007
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
>
>
More information about the bind-users
mailing list