deny-answer-addresses { %source%; };
deny-answer-aliases { %source%; };
Maybe?
- Kevin
On 8/17/2010 12:22 AM, Bradley Falzon wrote:
bind-users,
In light of Craig Heffner's recent Black Hat talk (here:
https://media.blackhat.com/bh-us-10/whitepapers/Heffner/BlackHat-USA-2010-Heffner-How-to-Hack-Millions-of-Routers-wp.pdf
and here: http://rebind.googlecode.com) I would like to propose a
possible solution in line with the 'DNS rebinding attack prevention'
provided in version 9.7.
Craig Heffner's version of the DNS Rebinding attack, similar to all
DNS Rebinding attacks, requires the DNS Servers to respond with an
Attackers IP Address as well as the Victims IP Address, in a typical
Round Robin fashion. Previous attacks would normally have the Victims
IP Address to be their Private IP.
BIND, in version 9.7, developed two new options: deny-answer-addresses
and deny-answer-aliases. Within these ranges an ISP or Corporation
could put in the list of RFC1918 Addresses or other address clients
should never be resolving to. However, Craig's attack would bypass
these rules: the Victims IP is actually the Victims WAN IP - not their
internal address. An ISP would be unable to place their entire IP pool
into the 'deny-answer-*' options, allocated to customers, because this
would break many legitimate uses.
I would like to know though, what if bind was given the option that
allowed an ISP to block and/or log DNS requests (again with a
SERVFAIL), based on if the query-source was in the response along with
at least one other address.
Basically:
if ( query.source = query.result[0]&& count(query.result)> 1 ) {
return (servfail)
}
If the Source IP of the client was also at least one of the results,
log and return a SERVFAIL. The rule would permit queries with a single
response.
Craig Heffner's method is serious for ISP's that supply their
customers modems that are vulnerable. The proper protections on the
customers modems would be a logistical nightmare.
Placing these protections, along with the current DNS Rebinding
protections already in 9.7 would be a great step forward in
realistically protecting these types of attacks.
I would propose "three" parameters for this. The first mode being
completely off (and I assume the default); the second, Permissive,
would only log the attacks; the third, Enforcing, would log and block
the attacks.
This would allow ISPs to upgrade to these specific versions of bind,
turn on Permissive parameter first and Enforcing if the attacks become
well known or impact is minimal.
What are your thoughts on this ? What could these protection break the
legitimate use for ?
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
