13:25 Dns amplification (dns amplification) | |
Not so long ago, faced with the problem (and solution) given the relevance of this topic in recent years, as well as how many people currently suffer from this trouble, decided to merge the information into one article. Maybe someone else it will be useful.HomeA couple of weeks ago I noticed strange activity aimed at my DNS-server. I must say that using a gateway on Linux, respectively, there is installed DNS-server bind. Activity was that the port 53 (DNS) of my server poured several UDP packets per second with a different IP-addresses: 10:41:42.163334 IP 89.149.221.182.52264> MY_IP.53: 22,912 + NS?. (17) 10:41:42.163807 IP MY_IP.53> 89.149.221.182.52264: 22912 Refused-0/0/0 (17) To which, as is evident from the log, the server refuses . Naturally I was curious that the IP-address hammering my DNS. After seeing several addresses via whois I found that it is the large hosting companies, I wrote a request to stop an attack on my server tech support of some of them. In response, I received a formal reply that this kind of attack relates to the fact that they can not block, and that they themselves are suffering from this abnormal activity. It was decided to deal with everything himself. DNS Amplification (DNS amplification). TheoryThe very type of attack is not new - for it was known back in 2006, details in English can be found here, but to actively use it started relatively recently. In January-February 2009, several Internet publications published information about large-scale use of cyber criminals of this kind of DDOS, as can be found here and in English here To explain in simple language, the essence of amplification is that the attacker sends a (usually short ) request for a vulnerable DNS-server, which responds to the request is significantly larger in size package. If used as a source IP-address when sending the request addressed to the victim's computer (ip spoofing), then the vulnerable DNS-server will send a large number of unnecessary packages target computer, while not completely paralyze its work. PracticeThe most effective is this type of attack on the old (unpatched), or incorrectly configured DNS-server, which, as already stated, is responsible for short queries intruders large-sized packages. Here is an example of such an interaction (by the way it is these queries often used by attackers): sent to the server NS query command # dig @ SERVER_IP NS where SERVER_IP - IP-address of the server. As a result, the log server port to 53 we find: 11:08:47.994604 IP MY_IP.47816> SERVER_IP.53: 5655 + NS?. (17) ie just those 17 bytes of inquiry that we would like to send. In response to that 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] ie server said to us a hint in the form of address the root DNS-servers, which is already 360 bytes. This is the length of a DNS query and response, the overall length is 60 packets and 402 bytes respectively. Amplification is available. What should I do?First of course check the latest version of your DNS-server, regardless of what platform it is running. Second, make sure that the server is configured quite safe and is not responsible for the "Left" needs all in a row. On this network you can find a lot of manuals and recommendations, I will mention here only on one document, found not long ago. What else can you do?In my case it was already doing nothing special. If you look at the very first log, which I cited, we see that the attacker sends a query to a 17 byte receive and REJECT the same length (17 bytes), ie no amplification occurs. But apparently, «ddos-EASURES" especially not in a hurry to remove from their lists addresses DNS-servers that are not prone to this vulnerability, and continue to bother them with his swotting ... This situation does not suit me. Unpleasant that from my address someone gets to your server unnecessary traffic (even though I in this and not guilty). Initially, I started to put in a black-list sender addresses, but there it was, from the old address of the attacker was stopped, but there are more and more. It was decided to use more sophisticated methods of filtering and use on my Linux-server modules iptables, to which earlier I could not reach his hands. To kill, so to speak, two birds - and to make intruder -1 and deal with a pair of modules iptables. Module StringClose port 53 (DNS) all of course I could not - I have many clients who need it. I decided to filter on content DNS-queries, and remove those that contain requests attackers, and they are all as one contained a «NS». For this problem, suitable module iptables string, which just allows you to look at the contents of the package. To understand that filter, look at the packet attack via wireshark. Here and here you can read about the structure of the UDP packets frame format and DNS respectively. For brevity, I will say that the first 14 bytes of packet data protocol occupy Ethernet (in Fig. Red), followed by a 20-byte header of IP (in Fig. Blue), then 8 bytes - header UDP (in Fig. Green), followed by a Data Protocol DNS (in Fig. yellow). The first 12 bytes of the frame DNS takes the title, after which, finally, the field starts DNS Query (ie directly to the query in Fig. Orange). In packets sent by attackers from the 54th (14 20 8 +12) bytes are the following: 00 00 02 00 01 (in hex), which corresponds to the request «NS», which I mentioned earlier. Thus the need to identify packages that are starting with 54 bytes contain these bytes. It will look like this: iptables-A INPUT - in-interface eth1 - protocol udp - dport 1953 - match state - state NEW - match string - algo kmp - hex-string "| 00 00 02 00 01 | "- from 40 - to 45 - jump DROP Few explain. --In-interface - shows what the interface to catch packets. To supply only the external interface, which is an attack (no need to infringe on users within the network). --Match state - state NEW - catches only packages with the state NEW, so do not verify all transactions in a row, but only initiating bags (you never know what can be transmitted via port 53). Next comes the fun part - deploy the module sting. We use the following parameters: --algo - specifies search algorithm, in fact is not important, I have kmp, but you can specify bm; --hex-string - is written that same line in hexadecimal, we are looking for; --from 40 - looking for starting at 40 bytes (notice, not to 54 because it starts the search string and, accordingly, counting from the first byte of the protocol IP, is thrown protocol Ethernet, whose length is 14 bytes (in Fig. top red). Total 54 - 14 = 40); --to 45 -, respectively, to seek up to 45 bytes of the packet. Module RecentThis was already possible to stay. Packages will no longer be up to bind, but I have not tried to comfort the idea that I closed the opportunity for everyone to make inquiries NS to my DNS-server, so I decided to use another module iptables - recent. This module allows you to create dynamic table IP-addresses, depending on certain conditions, and then set the allow and deny rules for these tables. Consider a simple example of recent, consisting of two lines: iptables-A INPUT - protocol tcp - match state - state NEW - dport 1922 - match recent - update - seconds 30 - name SSHT - jump DROP iptables-A INPUT - protocol tcp - match state - state NEW - dport 1922 - match recent - set - name SSHT - jump ACCEPT To begin to understand the second rule. Anyone who tries to enter (just go, because we use - state NEW) to port 22 (SSH) is skipped (- jump ACCEPT), but its IP-address gets to the table with the name SSHT. When from this address trying to connect again, starts the first rule, the meaning of which is to update the (- update) record in the table and at the same time to check if this record was installed / updated in last time. If the record has been installed / updated less than 30 seconds back (- seconds 30), it works - jump DROP and the packet is discarded. Thus brootforce trying to peck on the SSH port will be discarded if the rate to send their packages will be more than 1 packet in 30 seconds. Try to use recent for our needs: iptables-A INPUT - in-interface eth1 - protocol udp - dport 1953 - match state - state NEW - match string - algo kmp - -hex-string "| 00 00 02 00 01 |" - from 40 - to 45 - match recent - name DNST - update - seconds 600 - jump DROP iptables-A INPUT - in-interface eth1 - protocol udp - dport 1953 - match state - state NEW - match string - algo kmp - hex-string "| 00 00 02 00 01 |" - from 40 - to 45 - match recent - name DNST - set - jump ACCEPT So I'm allowed to make requests to the external NS interface is not more than 1 every 10 minutes. After adding these rules in the / proc / net / xt_recent my server will create a file DNST, which began to record IP-addresses of the attackers. A DNS-server stopped to yield to provocations: 14:10:19.011818 IP 89.149.221.182.40320> MY_IP.53: 23508 + NS?. (17) 14:10:25.243499 IP 89.149.221.182.64984> MY_IP.53: 25306 + NS?. (17) 14:11:08.832827 IP 89.149.221.182.15864> MY_IP.53: 48029 + NS?. (17) 14:11:15.063058 IP 89.149.221.182.30959> MY_IP.53: 64444 + NS?. (17) After a few days of the rules of packets from the attackers dropped a few times. Now I get 3.2 bags per minute, which were immediately discarded firewall. UPD: In the last block of code and wrote a hurried mistake is corrected, thank you noticed | |
|
| |
| Total comments: 0 | |