UnBound 1.02
Is there an option to filter DNS responses?
My concern is DNS rebinding, wherein external DNS responses point to
local addresses. I'd like the option to Block responses that point to:
private IP addresses (127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8,
172.16.0.0/12 and 169.254.0.0/16)
More info:
http://crypto.stanford.edu/dns/
http://code.google.com/p/google-dnswall/
http://kb-disclosure.blogspot.com/2007/10/full-disclosure-simple-dns-rebinding.html
Thank You
7v5w7go9ub0o wrote:
UnBound 1.02
Is there an option to filter DNS responses?
My concern is DNS rebinding, wherein external DNS responses point to
local addresses. I'd like the option to Block responses that point to:private IP addresses (127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8,
172.16.0.0/12 and 169.254.0.0/16)
I'll see what I can do. Maybe turn this on by default (if it does not
hinder legit users), with an option to turn off or add subnets to filter
as well.
Best regards,
~ Wouter
private IP addresses (127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8,
172.16.0.0/12 and 169.254.0.0/16)
Filtering 127/8 would break DNSBLs, so you can't really do this.
Florian Weimer wrote:
private IP addresses (127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8,
172.16.0.0/12 and 169.254.0.0/16)Filtering 127/8 would break DNSBLs, so you can't really do this.
Sorry; I'm a newbie and don't understand the problem.
1. If I want to install a black list, I'd expect to find it as a configuration option.
2. I don't see any configuration items specifically titled "DNSBL"; closest option seems to be local-data:
# You can override certain queries with
# local-data: "adserver.example.com A 127.0.0.1"
3. This request simply blocks external replies that resolve to private addresses; how could some external name server legitimately resolve to a 127/8 address within my computer?
At any rate, if it is a configuration alternative, the local administrator could determine whether it would be advantageous or problematic.
Thank you for considering this!
I think Florian was talking about making it default.
Ondrej.
Please consider another newbie posting and question.
Referring to this article (Matasano):
<http://beezari.livejournal.com/141796.html>
and this article (Friedl):
<http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html#poisoning>
there seems to be two attacks of current (Kaminsky) interest:
1. "poison a single address record" attack.
This is when an attacker tries to match the qid/port of a request. This is clearly is not an issue with unbound, which is well designed in
terms of randomness, and has first-rate test results; e.g.
<https://www.dns-oarc.net/oarc/services/porttest> )
2. "hijack the authority records" (RRset poisoning). This where the
server is sent to a bogus authority NS that is in-bailiwick with the target.
The last five paragraphs of the Matasano paper (from "5" to the end)
describe how an in-bailiwick poisoning could occur; the last few
paragraphs of the Friedl paper perhaps describe it more elegantly.
If I understand correctly, this second attack is much more likely to succeed because it is continuous - a series of requested in-bailiwick addresses can be sequentially increased and re-requested, resulting in continuous queries by the recursive server.
Suggestion: That unbound incorporate additional logic to defend against a "poisoned authority record" attack - logic in addition to its superior
port/qid randomization?
This additional logic is: that an exact match, not merely an "in-bailiwick" match be required before unbound would accept glue/RR record additions or updates.
It seems to me that little harm would result if unbound were instructed
to accept glue/RR records only from *exact* matches, and not from *inexact*, but in-bailiwick authority records.
Thanks for considering this.
1. "poison a single address record" attack.
This is when an attacker tries to match the qid/port of a request. This is
clearly is not an issue with unbound, which is well designed in
terms of randomness, and has first-rate test results; e.g.
Argh, not again... Kaminsky-style attack is not about port randomization.
Read his papers from doxpara.com... It's just much more easier to poison
cache if you don't do random ports.
Suggestion: That unbound incorporate additional logic to defend against a
"poisoned authority record" attack - logic in addition to its superior
port/qid randomization?This additional logic is: that an exact match, not merely an "in-bailiwick"
match be required before unbound would accept glue/RR record additions or
updates.It seems to me that little harm would result if unbound were instructed
to accept glue/RR records only from *exact* matches, and not from *inexact*,
but in-bailiwick authority records.
"seems to" and "little harm" are really dangerous words in context of DNS.
There are lot of servers in the wild which doesn't do the right thing, there
is a lot of inconsistencies in DNS data and that "little harm" you are speaking
about could cause severe damage.
But I think this is not right place to discuss that. This issue is
spreads across
platforms and servers and the right place (or just better place) to
discuss this is
namedroppers list (mailling list of dnsext working group @ ietf). And
you should
probably start by reading archives before making suggestions, so you
are not rehashing
issues already discussed.
Ondrej.
OndÅej Surý wrote:
1. "poison a single address record" attack.
This is when an attacker tries to match the qid/port of a request. This is
clearly is not an issue with unbound, which is well designed in
terms of randomness, and has first-rate test results; e.g.Argh, not again... Kaminsky-style attack is not about port randomization.
Read his papers from doxpara.com... It's just much more easier to poison
cache if you don't do random ports.
Argh yes ...... The basic system design weakness remains.
But as a consequence of good randomness, the *likelihood* of being poisoned by an unverified response is reduced to almost zero - quite acceptable. In this first type of attack.
Suggestion: That unbound incorporate additional logic to defend against a
"poisoned authority record" attack - logic in addition to its superior
port/qid randomization?This additional logic is: that an exact match, not merely an "in-bailiwick"
match be required before unbound would accept glue/RR record additions or
updates.It seems to me that little harm would result if unbound were instructed
to accept glue/RR records only from *exact* matches, and not from *inexact*,
but in-bailiwick authority records."seems to" and "little harm" are really dangerous words in context of DNS.
There are lot of servers in the wild which doesn't do the right thing, there
is a lot of inconsistencies in DNS data and that "little harm" you are speaking
about could cause severe damage.
Well......yes, it ....... could .....
But we really don't know, do we! This second type of attack is much more threatening than the first, and no one else has any answers. FWICT
DNSSEC won't defend against it.
You're very likely right - it is not perfect. But it may prove to be very good in many applications.
Unbound is under active development at a time of "danger"; this is a
perfect opportunity to test some radical approaches that may work well 99% of the time.
Put the option in with a default setting to "off"; not activated. Put a
little note next to it that this option is for beta testing.
This would allow folks to test it. It may work quite well in many
situations; not so well in others. A log entry could record when an
in-bailiwick RR record was rejected.
But I think this is not right place to discuss that. This issue is
spreads across
platforms and servers and the right place (or just better place) to
discuss this is
namedroppers list (mailling list of dnsext working group @ ietf). And
you should
probably start by reading archives before making suggestions, so you
are not rehashing
issues already discussed.
I will do that. Thank you.
7v5w7go9ub0o wrote:
Read his papers from doxpara.com... It's just much more easier to
poison
cache if you don't do random ports.Argh yes ...... The basic system design weakness remains.
Yes.
Suggestion: That unbound incorporate additional logic to defend
against a
"poisoned authority record" attack - logic in addition to its superior
port/qid randomization?
Well......yes, it ....... could .....
But we really don't know, do we! This second type of attack is much more
threatening than the first, and no one else has any answers. FWICT
DNSSEC won't defend against it.You're very likely right - it is not perfect. But it may prove to be
very good in many applications.Unbound is under active development at a time of "danger"; this is a
perfect opportunity to test some radical approaches that may work well
99% of the time.Put the option in with a default setting to "off"; not activated. Put a
little note next to it that this option is for beta testing.This would allow folks to test it. It may work quite well in many
situations; not so well in others. A log entry could record when an
in-bailiwick RR record was rejected.
I am working on working, non-disruptive filtering mechanisms. Just like
the ones released in 1.0.2.
Thanks for the suggestion. Such options, like caps-for-id (0x20), are
good to have.
Best regards,
~ Wouter
1. Are the logging message categories: info, notice, error, warning?
2. At this point, it seems that one can control the quantity of logged
information, but not its category; i.e. the present -v -v option
produces lots of good information for developers. For production or beta testing, it would be good to be able to configure unbound to log only error, or error and warning messages. This would keep the volume down, and a log monitor could popup on errors, advising that something is going wrong.
3. How would a failure in passing the: "use-caps-for-id: yes" check be
logged (warning or error)?
TIA
3. How would a failure in passing the: "use-caps-for-id: yes" check be
logged (warning or error)?
Like this:
[1218876864] unbound[9689:0] notice: wrong 0x20-ID in reply qname, answer dropped
[1218876864] unbound[9689:0] info: from server 62.212.64.121 port 53
[1218876864] unbound[9689:0] info: for packet[79:0] B32C840000010001000000000236350332303102313702383507696E2D61646472046172706100000C0001C00C000C000100015180001809686F737465642D6279086C6561736577656203636F6D00
The above 0x20 failure is because the leaseweb.nl name servers,
ns1.leaseweb.nl. A 62.212.64.121
ns4.leaseweb.net. A 62.212.78.199
ns5.leaseweb.nl. A 83.149.64.123
downcase everything, presumably because they are behind some sort of
load balancer.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
sthaug@nethelp.no wrote:
3. How would a failure in passing the: "use-caps-for-id: yes" check be
logged (warning or error)?Like this:
[1218876864] unbound[9689:0] notice: wrong 0x20-ID in reply qname, answer dropped
[1218876864] unbound[9689:0] info: from server 62.212.64.121 port 53
[1218876864] unbound[9689:0] info: for packet[79:0] B32C840000010001000000000236350332303102313702383507696E2D61646472046172706100000C0001C00C000C000100015180001809686F737465642D6279086C6561736577656203636F6D00The above 0x20 failure is because the leaseweb.nl name servers,
ns1.leaseweb.nl. A 62.212.64.121
ns4.leaseweb.net. A 62.212.78.199
ns5.leaseweb.nl. A 83.149.64.123downcase everything, presumably because they are behind some sort of
load balancer.
Ah, thank you! I now see a couple of these in my (big) logs 
. I'll set my log monitor to look for unbound notices.
(Would be useful if the subsequent two "info" entries were also "notice".)
7v5w7go9ub0o wrote:
3. How would a failure in passing the: "use-caps-for-id: yes" check be
logged (warning or error)?
These 0x20 errors are logged at verbosity value 1.
Verbosity value 0 is quiet - only errors really.
Verbosity value 1 gives 'operator useful information'.
Verbosity value 2 (and higher) print per-query information, for
troubleshooting.
verbosity 1 is the default.
Ah, thank you! I now see a couple of these in my (big) logs
set my log monitor to look for unbound notices.(Would be useful if the subsequent two "info" entries were also "notice".)
Fixed in svn trunk (other info: printouts are also classified to notice
as appropriate).
Best regards,
Wouter
The US government has called on all federal offices to take measures to prepare their domains for DNSSEC. Starting in January 2009, the US government will use DNSSEC for all .gov top level domains Second level domains for federal offices will follow. The move is the US government's reaction to the increasing threat of cache poisoning attacks on name servers, which make it possible to redirect even .gov addresses to servers controlled by criminals.
With the DNSSEC extension, all responses to a name server are signed, allowing the recipient to verify via public key infrastructure (PKI) whether they are authentic responses derived from the responsible name server. International implementation of DNSSEC has so far been hampered by disagreements over who would control the PKI.
While the implementation schedule for DNSSEC appears to be rather generous, federal offices tend to move rather slowly. Government offices are scheduled to have their initial plans for the implementation ready by early September. By December 2009 DNSSEC is supposed to be established for all second level domains under .gov.
7v5w7go9ub0o wrote:
<http://www.heise-online.co.uk/security/The-US-to-implement-DNSSEC-in-all-federal-offices--/news/111417>
Sigh... I failed to mention:
Posted this only because IMHO, this is going to open the DNSSEC
floodgates; that the U.S. has been dragging its feet, but will now
encourage itself and others to get on board.
This is a great opportunity for DNSSEC-by-design Unbound, which appears
to both work well as a DNSSEC resolver AND is leading the pack with important new security features (e.g. scrubbers), that both enterprise and users are beginning to value.
(sorry about responding to my own post)
This is nice to see, DNSSEC is very under-used at the moment.
Hopefully the US will actually pull through with this.
Cheers,
Teran (sega01)