Right now our DNS servers are used for a DNS root query amplification attack. The attack works like this: Mallory (the bad guy) is sending a lot of UDP queries for the root zone to a number of DNS servers. These queries are very short and don’t require a lot of bandwidth. In theory, the DNS server will respond with a very large response, because the response would contain the whole DNS root zone file. When sending the queries, Mallory will spoof the IP address of the source. He uses the IP of Alice (the good gal). The DNS server will send all the large root zone files back to Alice. Alice connection will be filled with root zone files from all over the world. This is a very nice attack vector, as it allows Mallory to send much more traffic to Alice then he can actually generate himself. Also, this does not really affect the DNS servers that are used by Mallory. If he does it the right way, it might even go unnoticed.
According to our DNS server log, these forged queries come in at a rate of about 20 Hz. Of course, our DNS server does not allow recursion from outside the trusted company network, so this is not really a problem either for us nor for Alice. Our DNS servers respond with a servfail. The log is full of these errors at the moment:
Not authoritative for '', sending servfail to 89.149.221.182 (recursion was desired)
It is important to note that the IP address displayed in the log (which is in the middle of a subnet of a German provider based in Frankfurt/Main) is not Mallory, the attacker. It is Alice, the target of the attack.
While not as bad as a full root zone response, a servfail is still data. If we send enough data down the line to Alice, their service will go down. Also, our own log files will be full of error messages and they will grow big. We don’t want any of this, so what else can we do beyond disabling recursion for the outside world? Of course we could stop responding to those kind of requests entirely, playing stealth DNS. Unfortunately, this makes DNS cache poisoning easier, so we don’t want to do this. Instead, we use fail2ban to block an IP address temporarily after 10 failed queries for the root zone in a relatively short time frame. The following regular expressions will be fine for PowerDNS:
not authoritative for(.*)servfail(.*)<HOST>pdns\[.*\]: Not authoritative for '', sending servfail to <HOST>
If you are administering your own DNS server, check your log files for these kind of attacks and implement appropriate measures to prevent them.
Shameless plug: If this post was useful to you, please consider buying yourself something from one of my Amazon stores: US store, UK store, FR store, DE store, CA store. If you're not into Amazon, why not donate something to GNOME, Mozilla or Wikipedia? Thank you!
New target since yesterday afternoon: 195.68.176.4
New target: 82.146.35.143
Seeing 62.109.4.89 now.
Hey Patrick,
Searching the IP 62.109.4.89 in google found your page here…
Reading the story here i’m not that disturbed. But it just someone is requesting these dns queries to an target.
So what can we do with fail2ban ? Does it work for bind as well ?
- Martijn
Martijn,
first, make sure that your DNS server does not allow direct recursion for anyone. Just allow recursion for trusted networks that you know. This will send a servfail to the target of the attack (some kind of Russian SEO business). If you are at this state, you’re ok. Check the link in the post above for a tool that checks your DNS server for this and infomation on how to configure Bind to disable recursion for anyone.
You can go a step further, though. And that is what I’m describing above. The failserv is still data, that you send out and traffic, you have to pay for. fail2ban (http://www.fail2ban.org/) is a software, that monitors log files and uses regular expressions to check for certain patterns. It then blocks IPs that match these patterns using iptables or another firewall. Check it out, it’s quite straight forward. You can also use it for Bind, you just need to use another regular expression that fits the log messages you’re getting. If you’re lucky, Bind is supported out of the box, but I’m not sure at the moment.
If you’ve got more control over your network, you can even block routing of this traffic at router or switch level directly, which is much more effective. Or ask your colo/upstream provider to do it for you.
[...] DNS Root Query Amplification [...]
For the record: The attack ended on the 6th of March.