[Dnsmasq-discuss] configurable stop-dns-rebind?

[clemens fischer]

Hi,

I have one little nit with option "stop-dns-rebind": it breaks the
RBL's needed to defend against spam. If only it could be a sub-option
to the "server" option to select which servers are allowed to receive
answers in the 127/8 or some other range!

Maybe a new option is needed, because "server" requires the IP of the
nameserver. The configuration would need to allow something like:

rbl=<rbl-domain>/<allowed-range(s)>

This should signal dnsmasq that clients don't actually use IPs from the
<allowed-range(s)> for networking and should be returned even with
"stop-dns-rebind" set.

Simon, would you accept a patch to that effect or implement it yourself?
How should the possibly new option be named? "rbl" sounds a bit too
specific for a general concept like this.


clemens

[Simon Kelley]

Post by clemens fischer
Hi,
I have one little nit with option "stop-dns-rebind": it breaks the
RBL's needed to defend against spam. If only it could be a sub-option
to the "server" option to select which servers are allowed to receive
answers in the 127/8 or some other range!
Maybe a new option is needed, because "server" requires the IP of the
rbl=<rbl-domain>/<allowed-range(s)>
This should signal dnsmasq that clients don't actually use IPs from the
<allowed-range(s)> for networking and should be returned even with
"stop-dns-rebind" set.
Simon, would you accept a patch to that effect or implement it yourself?
How should the possibly new option be named? "rbl" sounds a bit too
specific for a general concept like this.

One way to do this which would require very little code would be to
extend the current domain matching code:


server=/subdomain.domain/1.2.3.4

and

address=/subdomain.domain/1.2.3.4

By simply giving the ability to switch off rbl checking on some domains
with something like

rbl-domain=/subdomain.domain/

If the ability to specify particular IP ranges is not needed (why should
it be?) then this could be implemented very cheaply (in terms of
developer effort and extra code-size.)


Would that work?


Cheers,

Simon.

[clemens fischer]

Post by Simon Kelley

I have one little nit with option "stop-dns-rebind": it breaks
the RBL's needed to defend against spam. If only it could be a
sub-option to the "server" option to select which servers are allowed
to receive answers in the 127/8 or some other range!
Maybe a new option is needed, because "server" requires the IP of the
rbl=<rbl-domain>/<allowed-range(s)>
This should signal dnsmasq that clients don't actually use IPs from
the <allowed-range(s)> for networking and should be returned even
with "stop-dns-rebind" set.
Simon, would you accept a patch to that effect or implement it
yourself? How should the possibly new option be named? "rbl" sounds
a bit too specific for a general concept like this.

One way to do this which would require very little code would be to
server=/subdomain.domain/1.2.3.4
and
address=/subdomain.domain/1.2.3.4
By simply giving the ability to switch off rbl checking on some
domains with something like
rbl-domain=/subdomain.domain/
If the ability to specify particular IP ranges is not needed (why
should it be?) then this could be implemented very cheaply (in terms
of developer effort and extra code-size.)

In general narrowing to specific IP ranges could prove useful, but
I don't know how myself. I just thought it to be a nifty security
feature or something.

Post by Simon Kelley
Would that work?

Yes it would. I had thought about adding a flag to the "server" option:

server=/subdomain.domain/no-rbl

but that's awkward. Dnsmasq would need to recognize and handle it
specially in that no IP is given and the IP would have to be got from
other "server" statements.

"rbl-domain" is the better way. Dnsmasq would still need to add to the
internal structure keeping "server" info indicating that the
"stop-dns-rebind" is disabled for the "rbl-domain"s. I even tried to
figure out where to put the code, but didn't find the right place.


clemens

[/dev/rob0]

Post by clemens fischer
"rbl-domain" is the better way. Dnsmasq would still need to
add to the internal structure keeping "server" info indicating
that the "stop-dns-rebind" is disabled for the "rbl-domain"s.

I would suggest that "RBL" is not the proper term, it is "DNSBL".
"RBL" refers specifically to the MAPS RBL.

I've never had the issue, because I don't use --stop-dns-rebind. I
have VPN-linked RFC 1918 netblocks that I want to resolve on the
other ends of the VPN. So, maybe the exceptions need to be broader
than just for DNSBLs?

[clemens fischer]

Post by /dev/rob0
I would suggest that "RBL" is not the proper term, it is "DNSBL".
"RBL" refers specifically to the MAPS RBL.

Good idea.

Post by /dev/rob0
I've never had the issue, because I don't use --stop-dns-rebind.
I have VPN-linked RFC 1918 netblocks that I want to resolve on the
other ends of the VPN. So, maybe the exceptions need to be broader
than just for DNSBLs?

Ah, hadn't thought of that! Ok, then a possible option DNSBL should
look like "DNSBL=/dnsbl.example.com/". I thought this to mean that only
the answers to queries to dnsbl.example.com are exempted from the
stop-dns-rebind check.

src/rfc1035.c::private_net() defines all the customary rfc-1918
netblocks. It is the basis for the exceptions handled for OPT_BOGUSPRIV
and OPT_NO_REBIND. Currently, the latter applies only to IPv4 IP's. If
the hosts IP stack has no bugs, this should be ok considering IPv6 has
scopes.

It looks like you could put your VPN's names into "DNSBL=/.../"
statements and have their names protected from the rfc-1918 check.


clemens

[Simon Kelley]

Post by clemens fischer

Post by /dev/rob0
I would suggest that "RBL" is not the proper term, it is "DNSBL".
"RBL" refers specifically to the MAPS RBL.

Good idea.

Post by /dev/rob0
I've never had the issue, because I don't use --stop-dns-rebind.
I have VPN-linked RFC 1918 netblocks that I want to resolve on the
other ends of the VPN. So, maybe the exceptions need to be broader
than just for DNSBLs?

Ah, hadn't thought of that! Ok, then a possible option DNSBL should
look like "DNSBL=/dnsbl.example.com/". I thought this to mean that only
the answers to queries to dnsbl.example.com are exempted from the
stop-dns-rebind check.
src/rfc1035.c::private_net() defines all the customary rfc-1918
netblocks. It is the basis for the exceptions handled for OPT_BOGUSPRIV
and OPT_NO_REBIND. Currently, the latter applies only to IPv4 IP's. If
the hosts IP stack has no bugs, this should be ok considering IPv6 has
scopes.
It looks like you could put your VPN's names into "DNSBL=/.../"
statements and have their names protected from the rfc-1918 check.

OK, try test25, in the usual place. I called the option
--rebind-domain-ok but otherwise it's as Clemens describes.


Comments welcome.


Cheers,

Simon.

[clemens fischer]

Post by Simon Kelley
OK, try test25, in the usual place. I called the option
--rebind-domain-ok but otherwise it's as Clemens describes.

What can I say? It just works! I have "stop-dns-rebind" on and three
dnsbl's configured:

--rebind-domain-ok=/zen.spamhaus.org/
--rebind-domain-ok=/dnsbl-1.uceprotect.net/
--rebind-domain-ok=/ix.dnsbl.manitu.net/

The smtp server (postfix) does its lookups and gets the proper results
in the 127/8 range. Then I removed the above arguments from dnsmasq's
command line: now I see "possible DNS-rebind attack detected" for
connecting IPs listed for spamming.

A perfect result!


clemens

[Simon Kelley]

Post by clemens fischer

Post by Simon Kelley
OK, try test25, in the usual place. I called the option
--rebind-domain-ok but otherwise it's as Clemens describes.

What can I say? It just works! I have "stop-dns-rebind" on and three
--rebind-domain-ok=/zen.spamhaus.org/
--rebind-domain-ok=/dnsbl-1.uceprotect.net/
--rebind-domain-ok=/ix.dnsbl.manitu.net/
The smtp server (postfix) does its lookups and gets the proper results
in the 127/8 range. Then I removed the above arguments from dnsmasq's
command line: now I see "possible DNS-rebind attack detected" for
connecting IPs listed for spamming.
A perfect result!

I added the offending domain to the log message and turned it on on my
mail server box, which is running spamassasin. In addition to the three
you have, I've added

rebind-domain-ok=/rfc-ignorant.org/
rebind-domain-ok=/sorbs.net/
rebind-domain-ok=/uribl.com/
rebind-domain-ok=/surbl.org/
rebind-domain-ok=/dnswl.org/
rebind-domain-ok=/njabl.org/

and it seems to be quiet now.

Cheers,

Simon.

[clemens fischer]

Post by Simon Kelley
I added the offending domain to the log message and turned it on on my
mail server box, which is running spamassasin. In addition to the three
you have, I've added
rebind-domain-ok=/rfc-ignorant.org/
rebind-domain-ok=/sorbs.net/
rebind-domain-ok=/uribl.com/
rebind-domain-ok=/surbl.org/
rebind-domain-ok=/dnswl.org/
rebind-domain-ok=/njabl.org/
and it seems to be quiet now.

Good idea about the log message, but this is in a test release later
than 2.53test25, right? Would it be 26?


clemens

[Simon Kelley]

Post by clemens fischer

Post by Simon Kelley
I added the offending domain to the log message and turned it on on my
mail server box, which is running spamassasin. In addition to the three
you have, I've added
rebind-domain-ok=/rfc-ignorant.org/
rebind-domain-ok=/sorbs.net/
rebind-domain-ok=/uribl.com/
rebind-domain-ok=/surbl.org/
rebind-domain-ok=/dnswl.org/
rebind-domain-ok=/njabl.org/
and it seems to be quiet now.

Good idea about the log message, but this is in a test release later
than 2.53test25, right? Would it be 26?

I've just put up test27, which includes this.


Cheers,

Simon.

[Simon Kelley]

Post by Simon Kelley
I added the offending domain to the log message and turned it on on my
mail server box, which is running spamassasin. In addition to the three
you have, I've added
rebind-domain-ok=/rfc-ignorant.org/
rebind-domain-ok=/sorbs.net/
rebind-domain-ok=/uribl.com/
rebind-domain-ok=/surbl.org/
rebind-domain-ok=/dnswl.org/
rebind-domain-ok=/njabl.org/
and it seems to be quiet now.

I did some more research on this, and found a couple of relevant facts.

1) Spamassasin can potentially contact _dozens_ of RBLs, look in
/usr/share/spamassassin/20_dnsbl_tests.cf to get some idea. Presumably
the set can expand as new SA tests are added. Keeping the list
up-to-date in dnsmasq may be a bit of a headache,

2) There's an IETF draft on implementing these things, which implies
that the result of any A query to a RBl will be in 127.0.0.0/8

There is no widely used convention for mapping sublist names to bits
or values, beyond the convention that all A values SHOULD be in the
127.0.0.0/8 range to prevent unwanted network traffic if the value is
erroneously used as an IP address.


The fact that stop-dns-rebind blocks 127.0.0.0 is bit of a coincidence,
which comes from the fact that it uses the same address-checking code as
--bogus-priv. My understanding of the rebind attack is that it can't be
done via 127.0.0.1: That might get you a backdoor into the machine
running the program being attacked, but nothing you can't get be using
"localhost" to do the same thing.

I therefore propose to remove the rebind-domain-ok option, and just
change stop-dns-rebind to reject RFC1918 addresses, and not 127.0.0.0/8


Comments?


Cheers,

Simon.

[clemens fischer]

Post by Simon Kelley
The fact that stop-dns-rebind blocks 127.0.0.0 is bit of
a coincidence, which comes from the fact that it uses the same
address-checking code as --bogus-priv. My understanding of the rebind
attack is that it can't be done via 127.0.0.1: That might get you
a backdoor into the machine running the program being attacked, but
nothing you can't get be using "localhost" to do the same thing.

Sorry, I don't understand that last sentence.

AFAIK the rebinding attack makes user programs act as proxies after an
attackers domain suddenly resolved to a rfc1918 IP.

Post by Simon Kelley
I therefore propose to remove the rebind-domain-ok option, and just
change stop-dns-rebind to reject RFC1918 addresses, and not
127.0.0.0/8

But then what is rob supposed to do with his VPN's? He needs RFC1918
IPs and cannot use stop-dns-rebind currently.


clemens

[Simon Kelley]

Hi Simon, did you intend to send this privately? The dnsmasq list was
not Cc'ed.

Post by clemens fischer

Post by Simon Kelley
The fact that stop-dns-rebind blocks 127.0.0.0 is bit of a
coincidence, which comes from the fact that it uses the same
address-checking code as --bogus-priv. My understanding of the
rebind attack is that it can't be done via 127.0.0.1: That might
get you a backdoor into the machine running the program being
attacked, but nothing you can't get be using "localhost" to do the
same thing.

Sorry, I don't understand that last sentence.

Javascript or whatever running on a browser may be able to make
connections to the same machine via 127.0.0.1 that would not pass
through a firewall. It's possible to do that by using the domain
"localhost" which always resolves to 127.0.0.1, it doesn't need a
special domain returning IP addresses to do it.

Post by clemens fischer
AFAIK the rebinding attack makes user programs act as proxies after an
attackers domain suddenly resolved to a rfc1918 IP.

exactly, the proxies can be used to attack the machine they are
running on too.

As a matter of fact, any program asking for an IP and getting one from
the RFC1918 range could turn into a proxy. The users browser being the
prime target for this attack. This is what I meant by "proxy".

Post by clemens fischer

Post by Simon Kelley
I therefore propose to remove the rebind-domain-ok option, and
just change stop-dns-rebind to reject RFC1918 addresses, and not
127.0.0.0/8

But then what is rob supposed to do with his VPN's? He needs RFC1918
IPs and cannot use stop-dns-rebind currently.

Good point, maybe both changes are needed?

To me your changes from test25..test27 were quite adequate by using the
bogus-priv checks. Rob said he wants his VPN remotes to resolve. I can
imagine he just enters the remotes as rebind-domain-ok domains and be
happy.

I think so too, but it doesn't fix my problem of the large-and-growing
list of possible RBL domains in spamassassin rules. To avoid having a
large number of domains in /etc/dnsmasq.conf, removing 127.0.0.0/8 from
the addresses banned by stop-dns-rebind works much better, and doesn't
remove any protection.

BTW, I tested test27 and it's working perfectly. It's fast and the
logging is much better for my purposes than anything bind or pdnsd give
me.

Great. I've put up test28 which makes the 127.0.0.0/8 change, and also
allows

rebind-domain-ok=thekelleys.org.uk

without the '/' characters if only one domain is given. That will catch
people out otherwise.

gruss, clemens
regards, clemens
PS: Since you sent a private mail, I don't feel authorized to Cc the
list, but you can do this if you want.

I sent it privately by mistake, sorry: CC:ing the list this time.....



Cheers,

Simon.

[clemens fischer]

Post by Simon Kelley

To me your changes from test25..test27 were quite adequate by using
the bogus-priv checks. Rob said he wants his VPN remotes to resolve.
I can imagine he just enters the remotes as rebind-domain-ok domains
and be happy.

I think so too, but it doesn't fix my problem of the large-and-growing
list of possible RBL domains in spamassassin rules. To avoid having
a large number of domains in /etc/dnsmasq.conf, removing 127.0.0.0/8
from the addresses banned by stop-dns-rebind works much better, and
doesn't remove any protection.

Suppose some user, maybe on a window$ box[1], has some (browser)
accessible service on his machine, listening on 127/8. The rebind
attacker resolves something to 127.0.0.1. No firewall will stop the
reply, and it will even allow to connect like for any local service, but
some HTML5(?)/actionscript/java/javascript forwards the info out to the
attacker. Again, I don't see anything stopping this beside the resolver
blocking outside resources to resolve to _any_ RFC1918 range. Using the
name "localhost" doesn't appear in this equation, because AFAIK the
rebinding attack works by providing A records and doesn't care for PTR
names.

I see src/rfc1035.c::private_net() now has an additional argument
"ban_localhost" used to differentiate its use in bogus-priv and
stop-rebind. How about making "ban_localhost" a real option so that
users can decide for themselves what they need? A host running
spamassassin should propably not run services with access to private
info. Users could either specify all the DNSBL's and run with
"ban_localhost" for maximum security or run things like spamassassin
with "ban_localhost" off.

[1] with a lot of funky services ist user doesn't know about ...

Post by Simon Kelley
Great. I've put up test28 which makes the 127.0.0.0/8 change, and also
allows
rebind-domain-ok=thekelleys.org.uk
without the '/' characters if only one domain is given. That will
catch people out otherwise.

I just noticed: the replies to TXT queries aren't logged. These
records are routinely queried by DNSBL's to provide the user readable
blocking reason. It would help to see them logged in case the SMTP
server has problems.


clemens

[Simon Kelley]

Post by clemens fischer

Post by Simon Kelley

To me your changes from test25..test27 were quite adequate by using
the bogus-priv checks. Rob said he wants his VPN remotes to resolve.
I can imagine he just enters the remotes as rebind-domain-ok domains
and be happy.

I think so too, but it doesn't fix my problem of the large-and-growing
list of possible RBL domains in spamassassin rules. To avoid having
a large number of domains in /etc/dnsmasq.conf, removing 127.0.0.0/8
from the addresses banned by stop-dns-rebind works much better, and
doesn't remove any protection.

Suppose some user, maybe on a window$ box[1], has some (browser)
accessible service on his machine, listening on 127/8. The rebind
attacker resolves something to 127.0.0.1. No firewall will stop the
reply, and it will even allow to connect like for any local service, but
some HTML5(?)/actionscript/java/javascript forwards the info out to the
attacker. Again, I don't see anything stopping this beside the resolver
blocking outside resources to resolve to _any_ RFC1918 range. Using the
name "localhost" doesn't appear in this equation, because AFAIK the
rebinding attack works by providing A records and doesn't care for PTR
names.
I see src/rfc1035.c::private_net() now has an additional argument
"ban_localhost" used to differentiate its use in bogus-priv and
stop-rebind. How about making "ban_localhost" a real option so that
users can decide for themselves what they need? A host running
spamassassin should propably not run services with access to private
info. Users could either specify all the DNSBL's and run with
"ban_localhost" for maximum security or run things like spamassassin
with "ban_localhost" off.
[1] with a lot of funky services ist user doesn't know about ...

Post by Simon Kelley
Great. I've put up test28 which makes the 127.0.0.0/8 change, and also
allows
rebind-domain-ok=thekelleys.org.uk
without the '/' characters if only one domain is given. That will
catch people out otherwise.

I just noticed: the replies to TXT queries aren't logged. These
records are routinely queried by DNSBL's to provide the user readable
blocking reason. It would help to see them logged in case the SMTP
server has problems.

Both sensible suggestions: implemented in test29, from the usual place.


Cheers,

Simon.

[clemens fischer]

Post by Simon Kelley

Post by clemens fischer
I see src/rfc1035.c::private_net() now has an additional argument
"ban_localhost" used to differentiate its use in bogus-priv and
stop-rebind. How about making "ban_localhost" a real option so that
users can decide for themselves what they need? A host running
spamassassin should propably not run services with access to private
info. Users could either specify all the DNSBL's and run with
"ban_localhost" for maximum security or run things like spamassassin
with "ban_localhost" off.
...
I just noticed: the replies to TXT queries aren't logged. These
records are routinely queried by DNSBL's to provide the user readable
blocking reason. It would help to see them logged in case the SMTP
server has problems.

Both sensible suggestions: implemented in test29, from the usual place.

thanks. works. as always 8-)


clemens