[Dnsmasq-discuss] stop-dns-rebind and IPv6

[d***@flyingout.name]

Hey all,

I've searched the list, man, conf, etc. and didn't find anything on
this.

I've been testing the rebinding protection and thought it was working
until I hit it with a little dns testing tool over at grc.com. Some
browsers issue A and AAAA queries and it appears dnsmasq is only
blocking the A records. So, for example, if I point to my router via one
of the grc generated urls in Firefox (OS X and Ubuntu), it gets there
despite dnsmasq blocking the A record.

Is there a way to block the AAAA records as well?

dig net10.grctech.com A

; <<>> DiG 9.6.0-APPLE-P2 <<>> net10.grctech.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57692
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;net10.grctech.com. IN A

;; Query time: 22 msec


good, but:

dig net10.grctech.com AAAA

; <<>> DiG 9.6.0-APPLE-P2 <<>> net10.grctech.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19161
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;net10.grctech.com. IN AAAA

;; ANSWER SECTION:
net10.grctech.com. 599819 IN AAAA ::ffff:10.0.0.1

;; Query time: 18 msec

Thanks,
Paul

[Simon Kelley]

Post by d***@flyingout.name
Hey all,
I've searched the list, man, conf, etc. and didn't find anything on
this.
I've been testing the rebinding protection and thought it was working
until I hit it with a little dns testing tool over at grc.com. Some
browsers issue A and AAAA queries and it appears dnsmasq is only
blocking the A records. So, for example, if I point to my router via one
of the grc generated urls in Firefox (OS X and Ubuntu), it gets there
despite dnsmasq blocking the A record.
Is there a way to block the AAAA records as well?

No but there probably should be.

Post by d***@flyingout.name
dig net10.grctech.com A
; <<>> DiG 9.6.0-APPLE-P2 <<>> net10.grctech.com A
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57692
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;net10.grctech.com. IN A
;; Query time: 22 msec
dig net10.grctech.com AAAA
; <<>> DiG 9.6.0-APPLE-P2 <<>> net10.grctech.com AAAA
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19161
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;net10.grctech.com. IN AAAA
net10.grctech.com. 599819 IN AAAA ::ffff:10.0.0.1
;; Query time: 18 msec

What IPv6 ranges need to be blocked? the IPv4-mapped ones obviously, but
::1 also? What about the fe80:: link-local addresses.

Cheers,

Simon.

[Jan 'RedBully' Seiffert]

[snip - IPv6 rebind filter failing]

Post by Simon Kelley
What IPv6 ranges need to be blocked? the IPv4-mapped ones obviously, but
::1 also?

Sure, it's the equivalent to 127.0.0.1

Post by Simon Kelley
What about the fe80:: link-local addresses.

I would say yes.
An attacker could see a/the mac address in a/the global IPv6 address,
and then try a rebind to the linklocal + mac.

sitelocal are deprecated (but better safe then sorry?), hmmm, what's
with unique local?

I have some code for my software here, but it's more a bogon filter:

bool combo_addr_is_public(const union combo_addr *addr)
{
in_addr_t a;

// TODO: when IPv6 is common, change it
if(unlikely(AF_INET6 == addr->s.fam))
{
const struct in6_addr *a6 = &addr->in6.sin6_addr;
if(unlikely(IN6_IS_ADDR_UNSPECIFIED(a6)))
return false;
if(unlikely(IN6_IS_ADDR_LOOPBACK(a6)))
return false;
if(unlikely(IN6_IS_ADDR_MULTICAST(a6)))
return false;
if(unlikely(IN6_IS_ADDR_LINKLOCAL(a6)))
return false;
if(unlikely(IN6_IS_ADDR_SITELOCAL(a6)))
return false;
if(unlikely(IN6_IS_ADDR_UNIQUELOCAL_A(a6)))
return false;
if(unlikely(IN6_IS_ADDR_UNIQUELOCAL_B(a6)))
return false;
if(unlikely(IN6_IS_ADDR_DOCU(a6)))
return false;
/* keep test for v4 last */
if(IN6_IS_ADDR_V4MAPPED(a6) ||
IN6_IS_ADDR_V4COMPAT(a6))
a = a6->s6_addr32[3];
else
goto out;
}
else
a = addr->in.sin_addr.s_addr;

/* according to RFC 3330 & RFC 5735 */
if(IP_CMP(a, 0xFFFFFFFF, SLASH32)) /* 255.255.255.255/32 Broadcast */
return false;

.... rest of ipv4 part here ...

out:
return true;
}

Post by Simon Kelley
Cheers,
Simon.

Greetings
Jan

[Mark Cross]

Post by Jan 'RedBully' Seiffert

Post by Simon Kelley
What IPv6 ranges need to be blocked? the IPv4-mapped ones obviously, but
::1 also?
What about the fe80:: link-local addresses.

I would say yes.
sitelocal are deprecated (but better safe then sorry?),
hmmm, what's with unique local?

I would propose this blocking:
V4COMPAT ::0/96
"being deprecated is no longer valid, and that range
includes the ::/0/128 and ::1/128 already. This will prevent
older software from using such addresses at no connectivity
cost (until this range gets reassigned)"
LINKLOCAL fe80::/10
UNIQUELOCAL fc00::/7
Some unroutable addresses:
DOCUMENT 2001:db8::/32
BMWG 2001:0002::/48
ORCHID 2001:10::/28
If the system has IPv6 assigned from the ISP, this addresses make no sense in the LAN:
6TO4 2002::/16
TEREDO 2001::/32
If the address is (or):
V4MAPPED ::ffff:0:0/96
BEHAVE 64:ff9b::/96 "Well Known Prefix"
Extract the IPv4 address and do IPv4 testing:
Any RFC1918 10/8, 172.16/12,192.168/16
Loopback 127.0.0.0/8
"This network" 0.0.0.0/8
Link Local 169.254.0.0/16
Multicast 224.0.0.0/4 maybe not?
Future 240.0.0.0/4 Which includes 255.255.255.255


This addresses may? be also interesting to block, ( probably not?).
MULTICAST ff00::/8
SITELOCAL fec0::/10 (deprecated definition)




References:

From: http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml
V4COMPAT This definition has been deprecated by [RFC4291].
SITELOCAL has been deprecated as of September 2004 [RFC3879].
BEHAVE The "Well Known Prefix" 64:ff9b::/96

From: http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml
DOCUMENT 2001:0DB8::/32 [RFC3849].
6TO4 2002::/16 [RFC3056].
TEREDO 2001::/32 [RFC4380].

From: http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml
BMWG 2001:0002::/48
ORCHID 2001:10::/28

[Jan 'RedBully' Seiffert]

2010/9/10 Mark Cross <***@gmx.com>:
[snip]

   BEHAVE          64:ff9b::/96  "Well Known Prefix"

Oh, drafts are also OK?

Then i have this nice comment here in my code:
//TODO: add DS-Lite well known addresses
/*
* When the draft gets to standard:
* 192.0.0.0/29 is reserved for the p2p tunnel link between
* B4 & AFTR (CPE and Carrier NAT).
* These should not show up in the internet.
*/

http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-05#section-5.7

[snip]

--
Mark Cross

Greetings
Jan

[Mark Cross]

Post by Jan 'RedBully' Seiffert
[snip]

Post by Mark Cross
BEHAVE 64:ff9b::/96 "Well Known Prefix"

Oh, drafts are also OK?

No, not really, But should be given some consideration as it has been
reserved in the IANA numbering system already. Seems to me it will be
"approved" soon (note 6):
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml

Post by Jan 'RedBully' Seiffert
//TODO: add DS-Lite well known addresses
/*
* 192.0.0.0/29 is reserved for the p2p tunnel link between
* B4 & AFTR (CPE and Carrier NAT).
* These should not show up in the internet.
*/
http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-

lite-05#section-5.7

Keep it as a comment as that won't be in effect till the "IPv4 Exhaustion"
does happen. (some time next year?) :-)

That range fall into the ""IANA IPv4 Special Purpose Address Registry" at
192.0.0.0/24 [RFC5736] but does not appear here:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

Post by Jan 'RedBully' Seiffert
Greetings
Jan

Hi!

[d***@flyingout.name]

On Wed, 08 Sep 2010 22:24 +0100, "Simon Kelley"

Post by Simon Kelley

Post by d***@flyingout.name
Is there a way to block the AAAA records as well?

No but there probably should be.

Cool.

Post by Simon Kelley
What IPv6 ranges need to be blocked? the IPv4-mapped ones obviously, but
::1 also? What about the fe80:: link-local addresses.

Good question. (And I'll admit that I'm no expert here.) Definitely the
IPv4 mapped and ::1.