clemens fischer wrote: > 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. > >
Both sensible suggestions: implemented in test29, from the usual place. Cheers, Simon.
