DNS Amplification (DNS gain)

Not so long ago I ran into a problem (and its solution), given the relevance of this topic lately, as well as how many people are suffering from this trouble, decided to combine the information into one article. Maybe someone else will find it useful.

Start

A couple of weeks ago, I noticed a strange activity directed to my DNS server. At once I will say that I use the gateway on Linux, respectively, the bind DNS server is installed there. The activity was that on port 53 (DNS) of my server I had several UDP packets per second from different IP addresses:

10: 41: 42.163334 IP 89.149.221.182.52264> MY_IP.53: 22912+ NS ?. (17)
10: 41: 42.163807 IP MY_IP.53> 89.149.221.182.52264: 22912 Refused- 0/0/0 (17)

To which, as can be seen from the log, the server responded with failures. Naturally it became interesting to me that for IP addresses they dig my DNS. After looking at several addresses through whois, I determined that these are large hosting companies, I wrote a request to stop the attack on my server in technical support for some of them. In response, I received a formal reply that this type of attack relates to the fact that they cannot block, and that they themselves suffer from this abnormal activity. It was decided to deal with everything myself.

DNS Amplification (DNS gain). Theory

The type of attack itself is not new - it was known about it back in 2006, details in English can be found here, however, it began to be actively used relatively recently. In January-February 2009, several online publications published information about the large-scale use of this type of DDOS by cybercriminals, which can be found here and in English here.
Explaining in simple terms, the essence of the gain is that the attacker sends a (usually short) request to a vulnerable DNS server that responds to the request with a packet that is significantly larger in size. If you use the address of the victim’s computer (ip spoofing) as the source IP address, then the vulnerable DNS server will send a large number of unnecessary packets to the victim computer until it is completely paralyzed.

Practice

This type of attack is most effective on an old (unpatched) or incorrectly configured DNS server, which, as already mentioned, responds to short requests by attackers with large packets.
Here is an example of such an interaction (by the way, such requests are most often used by attackers):
Send an NS request to the server with the command
#dig @SERVER_IP NS
where SERVER_IP is the IP address of the server. As a result, in the log on port 53 of the server we get:
11: 08: 47.994604 IP MY_IP.47816> SERVER_IP.53: 5655+ NS ?. (17)
those. just those 17 bytes of the request that we wanted to send.
In the answer in the same log we see:
11: 08: 47.995853 IP 192.168.100.254.53> 192.168.100.100.47816: 5655 13/0/6 NS C.ROOT-SERVERS.NET., [| Domain]
those. the server responded with a hint in the form of the addresses of the root DNS servers, which is already 360 bytes. These are the lengths of the DNS request and response, the total length of the packets is 60 and 402 bytes, respectively. The gain is evident.

What to do?

First, of course, check the relevance of the version of your DNS server, regardless of which platform it is running. Secondly, make sure that the server is configured securely enough and does not respond to "left" requests to everyone. You can find many manuals and recommendations on the network; I will mention here only one document that I found not so long ago.

What else can you do?

In my case, there was nothing special to do. If you look at the very first log I gave, you can see that the attacker sends a request 17 bytes long and receives a REJECT of the same length (17 bytes), i.e. no gain occurs. But, apparently, “ddos-ery” especially not in a hurry to remove from their lists the addresses of DNS servers that are not affected by this vulnerability, and continue to bother them with their swotting ... This situation did not suit me. It is unpleasant that someone receives unnecessary traffic to my server from my address (even though I am not guilty of this).
At first, I began to put sender addresses on a black list, but that was not the case, the attack from the old addresses ceased, but more and more new ones appeared. It was decided to use more sophisticated filtering methods and use iptables modules on my Linux server, which I had never reached before. Kill two birds with one stone, so to speak, and an attacker to make -1 and deal with a pair of iptables modules.

String module

Of course, I could not close port 53 (DNS) completely - I have many clients who need it. I decided to filter packets by the contents of DNS queries and remove those that contain the requests of the attackers, and they all contained “NS” as one. For this task, the iptables string module is suitable, which just allows you to look into the contents of packages.
In order to understand what to filter, let's look at the attacker's packet through wireshark.

Here and here you can read about the structure of UDP packets and the DNS frame format, respectively. For brevity, I will say that the first 14 bytes of a packet occupy data from the Ethernet protocol (in red), then there are 20 bytes of the IP protocol header (in blue), then 8 bytes - a UDP header (in green), after which DNS protocol data (in yellow). The first 12 bytes of the DNS frame is occupied by the header, after which, finally, the DNS Query field begins (i.e., the query itself, shown in orange in Figure). The packets sent by the attacker starting from the 54th (14 + 20 + 8 + 12) bytes contain the following data: 00 00 02 00 01 (in hexadecimal code), which corresponds to the “NS” query I mentioned earlier. Thus, it is necessary to distinguish packets that, starting at 54 bytes, contain these bytes. It will look like this:

iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --jump DROP

I will explain a little.
--in-interface - indicates on which interface to catch packets. You need to put only the external interface, which is attacked (there is no need to infringe on users within the network).
--match state --state NEW - we only catch packets with the NEW state, so as not to check all transactions in a row, but only initiating packets (can it be sent to port 53).
Next comes the most interesting - use the sting module. We use the following parameters:
- algo - indicates the search algorithm, in fact it does not matter, I specified kmp, but you can also specify bm;
--hex-string - the same string in hexadecimal is written, which we are looking for;
--from 40 - we are looking for starting from 40 bytes (note, not from 54 because the string starts the search, and accordingly, the countdown from the first byte of the IP protocol, that is, the Ethernet protocol is ejected, which is 14 bytes in length (in red in the figure) A total of 54 - 14 = 40);
--to 45 - search for up to 45 bytes of packet accordingly.

Module Recent

On this one could already stop. Packages will no longer reach bind, but I haven’t been consoled by the idea that I have closed to ALL the opportunity to contact NS for my DNS server, so I decided to use another iptables module - recent.
This module allows you to create dynamic tables of IP addresses depending on certain conditions, and then set allow and deny rules for these tables.
Consider a simple example of using recent, consisting of two lines:

iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --update --seconds 30 --name SSHT --jump DROP
iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --set --name SSHT --jump ACCEPT
Let's start to deal with the second rule. Everyone who tries to log in (exactly log in because we use --state NEW) on port 22 (SSH) is skipped (--jump ACCEPT), but its IP address falls into a table named SSHT. When they try to connect again from this address, the first rule begins to work, the meaning of which is to update (--update) an entry in the table and at the same time check when this entry was installed / updated last time. If the record was installed / updated less than 30 seconds ago (--seconds 30), then - jump DROP is triggered and the packet is discarded. Thus, brute forcers trying to hammer on the SSH port will be discarded if the frequency of sending their packets exceeds 1 packet in 30 seconds.
Let's try to use recent for our needs:


Thus, I allow to make NS requests for an external interface no more than once every 10 minutes.

After adding these rules to the / proc / net / xt_recent of my server, a DNST file appeared in which the IP addresses of the attackers began to be written. And the DNS server has ceased to give in to provocations:

After a few days of working the rules, the number of packages by the attackers decreased several times. Now I get 2-3 packets per minute, which are immediately discarded by the firewall.