[Unbound-users] Filtering unbound Responses (DNS Rebinding issue)

[7v5w7go9ub0o]

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

[Wouter Wijngaards]

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

[Florian Weimer]

Post by 7v5w7go9ub0o
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.

[7v5w7go9ub0o]

Post by Florian Weimer

Post by 7v5w7go9ub0o
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!

[Ondřej Surý]

Post by 7v5w7go9ub0o

Post by Florian Weimer

Post by 7v5w7go9ub0o
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.

I think Florian was talking about making it default.

Ondrej.

[7v5w7go9ub0o]

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.

[Ondřej Surý]

Post by 7v5w7go9ub0o
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> )

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.

Post by 7v5w7go9ub0o
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 dis

[7v5w7go9ub0o]

Post by Ondřej Surý

Post by 7v5w7go9ub0o
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> )

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.

Post by Ondřej Surý

Post by 7v5w7go9ub0o
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.

Post by Ondřej Surý
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
you should
probably start by reading archives before making suggestions, so you
are not rehashing
issues already discussed.

I will do that. Thank you.

[Wouter Wijngaards]

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

[7v5w7go9ub0o]

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

[s***@nethelp.no]

Post by 7v5w7go9ub0o
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, ***@nethelp.no

[7v5w7go9ub0o]

Post by s***@nethelp.no

Post by 7v5w7go9ub0o
3. How would a failure in passing the: "use-caps-for-id: yes" check be
logged (warning or error)?

[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.

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".)

[Wouter Wijngaards]

Post by 7v5w7go9ub0o

Post by 7v5w7go9ub0o
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.

Post by 7v5w7go9ub0o
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".)

Fixed in svn trunk (other info: printouts are also classified to notice
as appropriate).

Best regards,
Wouter

[7v5w7go9ub0o]

<http://www.heise-online.co.uk/security/The-US-to-implement-DNSSEC-in-all-federal-offices--/news/111417>

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]

Post by 7v5w7go9ub0o
<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)

[Teran McKinney]

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)

Post by 7v5w7go9ub0o

Post by 7v5w7go9ub0o
<http://www.heise-online.co.uk/security/The-US-to-implement-DNSSEC-in-all-federal-offices--/news/111417>

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)
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users