If you are running a DNS server, then you need to check it is not being co-opted into ‘DNS amplification attacks’.
Random nasty servers (typically part of virus created bot-nets) send your DNS server a short request but use a fake source IP address. Your DNS server then sends a (typically) long reply back to that fake source IP address.
The fake source IP address gets a lot of traffic from your DNS server. You get abuse complaints. Your server uses a ton of bandwidth.
Why do the ‘nasty servers’ do this?
First, their involvement is hidden. The target IP is getting traffic from your server responding to the fake source IP. And you cannot easily tell where the traffic is really coming from. Typically the requests are fire-and-forget UDP requests.
Secondly, the ‘nasty servers’ get to multiply their bandwidth capacity in their DoS attack. For example, a short 75 byte request to list all .ar records can result in a 4096 byte response.
To see if you are subject to attack install and run iftop and see if certain IPs are resulting in lots of traffic. Also run tcpdump -vv proto UDP
Use tcpdump to look for queries for domains for which you are authoritative. Queries to .isc.org and .ar and . seem to be common indicators of an amplification DoS.
To resolve this it is difficult to simply ban source IPs via IP tables. Since the IPs are typically faked.
One effective way is to not run a recursive DNS server. Most people running a DNS server do so because they want a DNS server for their own domains’ DNS records. And they may not intend the general public (including bot nets) to use their name servers for other domains.
In bind check you disable recursive lookups in your config file’s ‘options’ section. e.g. if you bind config file is at /etc/named.conf then you might need this section:
options {allow-recursion {none;};
additional-from-cache no;
recursion no;};
Then restart named /etc/init.d/named restart
To confirm that recursive lookups are disabled run a command like ‘host google.com your.ip.here’ and expect to not see any records come back. (Unless you are actually authoritative for the google.com domain. In which case you probably know all this stuff anyway.)
If you still do need to offer a recursive DNS service then first, consider using iptables to drop UDP requests for users not on IP ranges you wish to provide lookup responses.
If you need to provide answers to a wide range of users then something like these iptable rules may throttle the damage:
#create a new table
iptables -N RATELIMITER
# have that drop requests when they start getting too frequent
iptables -I RATELIMITER -m hashlimit –hashlimit-name DNS –hashlimit-above 50/minute –hashlimit-mode srcip –hashlimit-burst 100 –hashlimit-srcmask 28 -j DROP
# send all incoming requests through that table
iptables -I INPUT -p udp –dport 53 -j RATELIMITER
If you want to permit high rate DNS lookups then you may have to find a pattern to the specific queries you are running. And only restrict those. e.g. ‘ANY’ queries for the isc.org domain. See https://lists.isc.org/pipermail/bind-users/2012-July/088223.html
Note that after you setup these rules you will still see the requests in tcpdump (since that shows packets before the iptables rules are invoked). But if you run iptables -nvL then you will see how many packets get dropped by those rules.
Image credit: Artiii