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

[clemens fischer]

Simon Kelley wrote:

> clemens fischer wrote:
>
>> 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 ...

> 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