Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
I am testing my current setup with dnsmasq as an authorized server and a 3 slave dns server. I am using a standard domain register with slave dns support. ( www.nxs.nl ) Only the slave dns servers has access from the internet to dnsmasq, the rest is blocked by the firewall. This setup adds a extra DNS server but reduces the risk that dnsmasq is exposed to the internet for everybody. The current problem with this setup you can't added out of the zone IP addressen IPv4 nor IPv6. I am not sure but I don't know if dnsmasq created PTR record on the slave server. My dns provider nor my ISP does support this. Which is for 99% the case and also no problem. I also have a Sixxs IPv6 tunnel which allows me to setup a reverse dns server. I want to use this range for my fix servers. I did send Simon a email with my ideas and though about it. I think we will see some changes in the upcoming releases. Greats, René van Dorst /dev/rob0 r...@gmx.co.uk , 25-10-2013 0:06: On Thu, Oct 24, 2013 at 05:28:29PM +0100, Simon Kelley wrote: On 24/10/13 17:03, Brian Rak wrote: We've recently undertaken a project to clean up our network, and lock down all the open DNS resolvers. As you may know, these are very frequently used for DDOS attacks: http://openresolverproject.org/ , http://www.team-cymru.org/Services/Resolvers/ . I haven't been able to find any sort of configuration option that would prevent DNSMasq from being abused like this, and I've had to resort to iptables rules instead. Is there a configuration option that that would disable responding to DNS queries from certain interfaces? The other option that seems handy would be one to only reply to DNS queries from hosts that have a configured DHCP lease. Are there any features of DNSMasq that would prevent it from being abused to conduct attacks? This is an important topic, and quite difficult to understand, so I'm going to take this opportunity to try and put a definitive statement on the record. Good stuff here, as usual, but questions still exist. Yes, I think of dnsmasq in its original mission mostly: as a DNS forwarder and provider of internal DNS for [DHCP usually] LAN hosts. That seems to be the gist of your response here: to keep dnsmasq safe from Internet attackers, don't expose dnsmasq to the Internet. However, in the coming age of IPv6 and [we hope] the decline of NAT, users will be more likely to want to expose dnsmasq to the Internet as an authoritative nameserver. I can see the potential need for serving both ip6.arpa zones and a zone such as dh6.example.com (the --domain in dnsmasq terms.) I have reviewed the AUTHORITATIVE CONFIGURATION section as well as all the --auth-* settings in the manual, and I still have two concerns: 1. Is there a way to designate interfaces which ONLY respond to queries for our authoritative names? (--auth-server looks like it might do this, but it does not quite say so.) If I'm acting as NS host for dh6.example.com and whatever.ip6.arpa, I need to respond to those queries to anyone, but I don't want to let them look up google.com nor lists.thekelleys.org.uk. For that matter, they shouldn't even be able to get any names from /etc/hosts UNLESS those names are in my zone. 2. Is there a way to limit the response rate on these queries on the external IP address[es]? A third concern, which isn't quite relevant to this thread, but I might as well mention anyway: 3. what about DNSSEC signing, will dnsmasq ever be able to serve signed data? I'm a big fan of dnsmasq, BTW; it has made the jobs of SMB/SOHO network administrators much easier. The features I mention would improve safety while exposed to the Internet, but I am not sure they're worth the added size and code complexity. It could well be best that dnsmasq should stick to its original mission. Those who want advanced features could use it as a hidden master for BIND (or other nameservers.) That part can work safely, and the slave server could do inline signing. PS to Simon, a note on your manual: you should stick to example names for zones, not our.zone.com or secondary.myisp.com. Note that both zone.com and myisp.com exist (the former being owned by Microsoft.) I'd consider perhaps s/com/example/ for those. Reference: RFC 6761. Also in three places you make reference to ipv6.arpa, which in other placess is correctly called ip6.arpa. Another very minor nitpick: under --interface you mention IP alias interfaces (eg eth1:0). Those aren't interfaces at all; only the brokenness of Linux ifconfig(8) displays them as such. Please consider changing interfaces there to labels. Help stamp out ignorance ... and even Linux net-tools itself! :) First the simple stuff. Dnsmasq has --interface --except-interface and --listen-address configuration options that disable response to DNS queries from certain
[Dnsmasq-discuss] BUG in synth-domain.
Only tested with ipv4 with the latest git version. Dnsmasq doesn't accept: synth-domain=domain,ip address,ip address,prefix It does accept: synth-domain=domain,ip address,ip address or synth-domain=domain, ip address/netmask,prefix Greats, René van Dorst___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
On 24/10/13 18:11, Brian Rak wrote: Ah, but that's the problem. The machines I'm referring to only have one interface. So, I'm primarily running this on virtual machine hosts. They have one connection to the internet, and no internal network. So, for example we have a virtual machine host running with eth0 being 198.51.100.10. DNSMasq is configured to listen on eth0 and provide 198.51.100.11-198.51.100.15 for any virtual machines that start up (virtual machines are recognized by preconfigured static leases, all other DHCP requests are ignored). The virtual machines are all bridged to the eth0 interface, and have no other connectivity. I should also note that my primary concern is preventing my machines from being abused to attack other people's machines. Cases where someone would abuse my DNS server to attack my own machines are not currently a concern (as they're significantly easier to block). There's nothing in dnsmasq to mitigate this situation. I suppose that an option to only reply to queries from local subnet(s) would do it, but I think once you're in this place, a firewall rule to block incoming port 53 UDP is the simplest, most obvious and most correct solution. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
On 24/10/13 21:40, richardvo...@gmail.com wrote: Sorry, I should mention only drop packets in state NEW, you don't want to drop replies to your own queries. Dropping replies to your own queries shouldn't be a problem. The queries originate from ports other than 53 (normally, a newly randomly-chosen port for each query) so the replies will not have destination port 53, whilst incoming queries will. Simon. On Thu, Oct 24, 2013 at 3:39 PM, richardvo...@gmail.com richardvo...@gmail.com wrote: Your case should be easy to stop with a firewall rule. Just block all packets matching the dns listen port (53 usually) in the INPUT chain, where the source address is outside your block. Optionally (this prevents reflection attacks against your own network which you said is not required), configure your router to drop packets arriving on its external interface where the source IP is within your internal network. This is called a reverse route check. On Thu, Oct 24, 2013 at 12:11 PM, Brian Rakb...@gameservers.com wrote: On 10/24/2013 1:00 PM, Simon Kelley wrote: On 24/10/13 17:46, Brian Rak wrote: On 10/24/2013 12:28 PM, Simon Kelley wrote: On 24/10/13 17:03, Brian Rak wrote: We've recently undertaken a project to clean up our network, and lock down all the open DNS resolvers. As you may know, these are very frequently used for DDOS attacks: http://openresolverproject.**org/http://openresolverproject.org/, http://www.team-cymru.org/**Services/Resolvers/http://www.team-cymru.org/Services/Resolvers/. I haven't been able to find any sort of configuration option that would prevent DNSMasq from being abused like this, and I've had to resort to iptables rules instead. Is there a configuration option that that would disable responding to DNS queries from certain interfaces? The other option that seems handy would be one to only reply to DNS queries from hosts that have a configured DHCP lease. Are there any features of DNSMasq that would prevent it from being abused to conduct attacks? This is an important topic, and quite difficult to understand, so I'm going to take this opportunity to try and put a definitive statement on the record. First the simple stuff. Dnsmasq has --interface --except-interface and --listen-address configuration options that disable response to DNS queries from certain interfaces. The first thing that has to be done is to use these. Mostly it's the only thing that needs to done. Now, the complicated stuff. Under certain circumstances, --interface=interface degrades to mean the same as --listen-address=address on interface. For instance if eth0 has address 192.168.0.1 and dnsmasq is configured with --interface=eth0, then dnsmasq will reply to any query which is sent to 192.168.0.1, no matter what interface it actually arrives at. The circumstance under which happens is when the --bind-interfaces flag is used. Now, in the above example, this isn't a problem, since a botnet can't direct traffic to an RFC-1918 address. If, on the other hand, the address of an internal interface (ie one configured to accept DNS queries) is globally routable, then queries which arrive via another interface (ie one linked to the internet) with the destination address of the internal interface _will_ be replied to, and a DNS reflection attack is possible. This has mainly been seen in libvirt and OpenStack installations which use dnsmasq, since sometimes they are provisioned with real addresses. I'd expect to see problems in the future with IPv6, since far more people will be using globally routable addresses with IPv6. The reason that this happens is that --bind-interfaces uses the bare-minimum BSD sockets API only. Detecting which interface a packet arrived on, rather than the address to which it was sent, needs non-portable API, and is impossible on some platforms (openBSD, for instance) --bind-interfaces is a works everywhere least common denominator. It's also useful when you're running multiple instances of dnsmasq on one host, which is why most people use it. The fix is to use either the default listening mode, or if running multiple instances, the new --bind-dynamic mode. --bind-dynamic is only available on Linux, and --bind-interfaces is the only mode available on openBSD, so BSD users have rather more problems here. Summary. There's a problem is you want to accept queries in an internal interface with a globally routable address and use --bind-interfaces. The fix is to remove --bind-interfaces and, if necessary, replace it with --bind-dynamic. This fix is not applicable on all platforms, The Real Soon Now 2.67 release logs a very prominent warning if the dangerous combination is configured. Cheers, Simon. Thanks for the detailed explanation! It seems that for some of my servers I can resolve the issue by using --interface and --except-interface. I do however have some DNSMasq instances that are providing public, globally routable IP addresses via DHCP. In
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
On 24/10/13 23:03, /dev/rob0 wrote: On Thu, Oct 24, 2013 at 05:28:29PM +0100, Simon Kelley wrote: On 24/10/13 17:03, Brian Rak wrote: We've recently undertaken a project to clean up our network, and lock down all the open DNS resolvers. As you may know, these are very frequently used for DDOS attacks: http://openresolverproject.org/ , http://www.team-cymru.org/Services/Resolvers/ . I haven't been able to find any sort of configuration option that would prevent DNSMasq from being abused like this, and I've had to resort to iptables rules instead. Is there a configuration option that that would disable responding to DNS queries from certain interfaces? The other option that seems handy would be one to only reply to DNS queries from hosts that have a configured DHCP lease. Are there any features of DNSMasq that would prevent it from being abused to conduct attacks? This is an important topic, and quite difficult to understand, so I'm going to take this opportunity to try and put a definitive statement on the record. Good stuff here, as usual, but questions still exist. Yes, I think of dnsmasq in its original mission mostly: as a DNS forwarder and provider of internal DNS for [DHCP usually] LAN hosts. That seems to be the gist of your response here: to keep dnsmasq safe from Internet attackers, don't expose dnsmasq to the Internet. However, in the coming age of IPv6 and [we hope] the decline of NAT, users will be more likely to want to expose dnsmasq to the Internet as an authoritative nameserver. I can see the potential need for serving both ip6.arpa zones and a zone such as dh6.example.com (the --domain in dnsmasq terms.) I have reviewed the AUTHORITATIVE CONFIGURATION section as well as all the --auth-* settings in the manual, and I still have two concerns: 1. Is there a way to designate interfaces which ONLY respond to queries for our authoritative names? (--auth-server looks like it might do this, but it does not quite say so.) It does do exactly this, is you didn't understand that, it's a documentation bug. If I'm acting as NS host for dh6.example.com andwhatever.ip6.arpa, I need to respond to those queries to anyone, but I don't want to let them look up google.com nor lists.thekelleys.org.uk. For that matter, they shouldn't even be able to get any names from /etc/hosts UNLESS those names are in my zone. That's what happens. In addition, ANY queries are no responded to for auth zones. 2. Is there a way to limit the response rate on these queries on the external IP address[es]? No. I'm watching and waiting on that, but I'm not sure it makes sense. The DNS amplification attacks work by sending a pre-crafted query with a forged source address which is the address of the victim. The query is designed to produce the biggest possible answer for the smallest possible query so that as much bandwidth lands on the victim as possible for the smallest bandwidth use by the attacker. This only really works for recursive nameservers In the case of an authoritative-only server, this won't work, since a query will not be in the zone, and therefore will get an empty answer. The only way to make it work is for the attacker to somehow determine which zone the server is authoritative for, and generate a suitable query on-the-fly. A third concern, which isn't quite relevant to this thread, but I might as well mention anyway: 3. what about DNSSEC signing, will dnsmasq ever be able to serve signed data? The first priority for DNSSEC, indeed the first priority period, post 2.67, is DNSSEC validation. Once that's done, I figure I'll have enough knowledge to approach the problem of signing. I'm a big fan of dnsmasq, BTW; it has made the jobs of SMB/SOHO network administrators much easier. The features I mention would improve safety while exposed to the Internet, but I am not sure they're worth the added size and code complexity. It could well be best that dnsmasq should stick to its original mission. Those who want advanced features could use it as a hidden master for BIND (or other nameservers.) That part can work safely, and the slave server could do inline signing. An valid point. There's an internet draft around at the moment that I've had some input to which proposes more-or-less exactly that. http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-03 Cheers, Simon. PS to Simon, a note on your manual: you should stick to example names for zones, not our.zone.com or secondary.myisp.com. Note that both zone.com and myisp.com exist (the former being owned by Microsoft.) I'd consider perhaps s/com/example/ for those. Reference: RFC 6761. Also in three places you make reference to ipv6.arpa, which in other placess is correctly called ip6.arpa. Another very minor nitpick: under --interface you mention IP alias interfaces (eg eth1:0). Those aren't interfaces at all; only the brokenness of Linux ifconfig(8) displays them as such. Please consider
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
On 24/10/13 23:41, Vladislav Grishenko wrote: From: Simon Kelley Sent: Thursday, October 24, 2013 11:00 PM So, don't use --bind-interfaces. If you're on Linux, you can use --bind- dynamic instead if you're running multiple dnsmasq instances. So, on linux --bind-interfaces can be just an alias of --bind-dynamic, with no --bind-interfaces code and no warnings, less binary size, more seciruty. There's practically no code that could be removed with --bind-interfaces, --bind-dynamic is pretty much bind-interfaces plus the code to determine arrival interface which is disabled or missing with bind interfaces plus some new code to notice new addresses arriving. If it could be supported everywhere, I'd just have extended bind-interfaces to work in the way that the new bind-dynamic mode does, but I don't want to have one mode which behaves subtly differently on different platforms. By giving the new mode a new option, I can raise an error when it's not available. Cheers, Simon. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Announce: dnsmasq-2.67
dnsmsaq-2.67 is now available to download from http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.67.tar.gz Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] What is the required configuration for enabling periodic RA's
Hi there, I'm trying to use dnsmasq to provide RA for stateless IPV6 configuration. Does anyone know the configuration required to get dnsmasq to send out RA's periodically? So far I seem to only see RA's be sent after a DHCP request occurs. I'm trying to set this up on a router that has a dynamic backhaul where the assigned IPV6 prefix can change abruptly. I've seen problems in the past where clients such as Windows XP seem to ignore a single RA after an IP change. The only way I've found to get this bullet proof is to use RADVD to periodically broadcast RAs. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] What is the required configuration for enabling periodic RA's
On 25/10/13 16:28, Gordon Scott wrote: Hi there, I'm trying to use dnsmasq to provide RA for stateless IPV6 configuration. Does anyone know the configuration required to get dnsmasq to send out RA's periodically? So far I seem to only see RA's be sent after a DHCP request occurs. How are you looking for the RAs? In some configurations, dnsmasq will unicast an RA after a DHCPv4 request, but the periodic RAs are always multicast. If you're looking at packets and only looking for unicast packets, that would explain your observations. Dnsmasq always logs each time it sends an RA, so it's worth looking in the system logs. I'm trying to set this up on a router that has a dynamic backhaul where the assigned IPV6 prefix can change abruptly. I've seen problems in the past where clients such as Windows XP seem to ignore a single RA after an IP change. The only way I've found to get this bullet proof is to use RADVD to periodically broadcast RAs. For dynamic prefixes, you want something like dhcp-range=::,constructor:interface,slaac Which will pick up the address installed on the local interface by tyhe backhaul and advertise the subnet over that interface. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
From: Simon Kelley Sent: Friday, October 25, 2013 4:15 PM On 24/10/13 23:41, Vladislav Grishenko wrote: From: Simon Kelley Sent: Thursday, October 24, 2013 11:00 PM So, don't use --bind-interfaces. If you're on Linux, you can use --bind- dynamic instead if you're running multiple dnsmasq instances. So, on linux --bind-interfaces can be just an alias of --bind-dynamic, with no --bind-interfaces code and no warnings, less binary size, more seciruty. There's practically no code that could be removed with --bind-interfaces, -- bind-dynamic is pretty much bind-interfaces plus the code to determine arrival interface which is disabled or missing with bind interfaces plus some new code to notice new addresses arriving. If it could be supported everywhere, I'd just have extended bind-interfaces to work in the way that the new bind-dynamic mode does, but I don't want to have one mode which behaves subtly differently on different platforms. By giving the new mode a new option, I can raise an error when it's not available. I see, wasn't aware it can't be supported on BSD. makes sense than, thanks for pointing out. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
