Re: [Dnsmasq-discuss] configurable stop-dns-rebind?
Simon Kelley wrote: 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. 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
Re: [Dnsmasq-discuss] tftp 'Permission denied' issue...
Simon, Thanks for the response. I do not have --tftp-secure. But I do launch with sudo /etc/rc.d/initd/dnsmasq So it seems that it will be run by root. Therefore I need world readable permission on my bootrom.pxe.0. I thought I had that! --- /home/Steve/Shared/workspace/xxx/xxx/ -rwxrwxr-x. 1 Steve Steve 482040 2010-05-13 17:32 bootrom.pxe.0 --- This is my config: (I leave /etc/dnsmasq.conf as delivered and customise /etc/dnsmasq.d/01dnsmasq.more.conf /etc/dnsmasq.d/10service.conf) Left file: /etc/dnsmasq.conf Right file: /etc/dnsmasq.d/01dnsmasq.more.conf 25a26 filterwin2k 107a109 no-hosts 146a149,151 # Defer dhcp to another dhcp-server dhcp-range=10.0.0.0,proxy 363a369 pxe-prompt=Which bootrom shall I load? 390a397 enable-tftp 393a401 tftp-root=/home/Steve/Shared/workspace 536a545 log-dhcp With /etc/dnsmasq.d/10service.conf # Loads a file from dnsmasq TFTP server. #pxe-service=x86PC, Install Linux, pxelinux pxe-service=x86PC, , /xxx/xxx/bootrom.pxe Steve Elliott - Embedded Overflow 4, Glassop St., Balmain, NSW 2041. -- -- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] could not bind dnsmasq to mutiple interfaces with same ip-address
Am 14.05.2010 16:08, schrieb Simon Kelley: Different versions of dnsmasq? I only looked at the latest code to see how it would behave with repeated IP addresses, older code may break differently dnsmasq -v prints the same Version 2.52 *strange*
Re: [Dnsmasq-discuss] tftp 'Permission denied' issue...
Hallo, Steve, Du meintest am 15.05.10: But I do launch with sudo /etc/rc.d/initd/dnsmasq So it seems that it will be run by root. Therefore I need world readable permission on my bootrom.pxe.0. I thought I had that! --- /home/Steve/Shared/workspace/xxx/xxx/ -rwxrwxr-x. 1 Steve Steve 482040 2010-05-13 17:32 bootrom.pxe.0 --- world may need the x rights (go into the next subdir) in the directory tree too. Viele Gruesse! Helmut
Re: [Dnsmasq-discuss] tftp 'Permission denied' issue...
Steve Elliott wrote: Simon, Thanks for the response. I do not have --tftp-secure. But I do launch with sudo /etc/rc.d/initd/dnsmasq So it seems that it will be run by root. No, it will be running as non-privileged user, nobody or dnsmasq unless you have user=root somewhere. Try su nobody and then reading that file. Cheers, Simon. Therefore I need world readable permission on my bootrom.pxe.0. I thought I had that! --- /home/Steve/Shared/workspace/xxx/xxx/ -rwxrwxr-x. 1 Steve Steve 482040 2010-05-13 17:32 bootrom.pxe.0 --- This is my config: (I leave /etc/dnsmasq.conf as delivered and customise /etc/dnsmasq.d/01dnsmasq.more.conf /etc/dnsmasq.d/10service.conf) Left file: /etc/dnsmasq.conf Right file: /etc/dnsmasq.d/01dnsmasq.more.conf 25a26 filterwin2k 107a109 no-hosts 146a149,151 # Defer dhcp to another dhcp-server dhcp-range=10.0.0.0,proxy 363a369 pxe-prompt=Which bootrom shall I load? 390a397 enable-tftp 393a401 tftp-root=/home/Steve/Shared/workspace 536a545 log-dhcp With /etc/dnsmasq.d/10service.conf # Loads a file from dnsmasq TFTP server. #pxe-service=x86PC, Install Linux, pxelinux pxe-service=x86PC, , /xxx/xxx/bootrom.pxe Steve Elliott - Embedded Overflow 4, Glassop St., Balmain, NSW 2041. -- -- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] configurable stop-dns-rebind?
clemens fischer wrote: Hi Simon, did you intend to send this privately? The dnsmasq list was not Cc'ed. Simon Kelley: clemens fischer wrote: Simon Kelley wrote: 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. 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. 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.
Re: [Dnsmasq-discuss] configurable stop-dns-rebind?
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
