DNS Reflective Attacks
A DNS reflective attack is used in many distributed denial-of-service (DDoS) attacks to knock down an internet pipe. The attack is a two-step attack; the attacker sends a large amount of requests to one or more legitimate DNS servers while using spoofed source IP of the target victim. The DNS server receiving the semi-legitimate requests replies to the spoofed IP, thereby unknowingly launching an attack on the target victim with responses to requests that the victim never sent.
The internet is full of DNS servers offered as open-resolvers which will serve any request sent to them, some reports name millions as the amount. This huge number makes it very hard to pre-identify the attack using IP reputation. Furthermore, the servers are actually legitimate servers that usually send legitimate traffic, making any IP reputation service confused about whether or not their nature is malicious.
Most DNS queries are sent using UDP, a protocol that does not enable source IP validation. This is why the intermediary DNS server assumes the requests are arriving from the victim and sends the replies back to him. The IP spoofing makes it extremely difficult for the victim server to detect the attacker, as it appears as if it is being attacked by a legitimate DNS server, and the attacker IP is completely hidden. IP spoofing also invalidates IP reputation services, which, if not written properly, may assign a bad reputation to a legitimate DNS server. It also removes any tractability for security expects trying to identify the attack source.
Another advantage for spoofing is the ability to attack any server or service. The attacker can use the victim’s public server IP and port to make sure the attack is sent to any service, not just a DNS service. The traffic will simply look like a lot of data and the server will have to parse and examine the data to ensure it is not legitimate traffic.
Note that the IP spoofing is also a limitation of this attack – if IP spoofing is not possible, the attack cannot be launched as there is no way to direct the responses to the victim’s IP. This is the case with the Mirai bots running on IoT devices behind a router that performs NAT. However, recent Mirai infection tactics are aiming at the home routers themselves, thus bypassing the NAT limitation.
The latest and biggest advantage contributing to the destructive potential of reflective DNS floods is amplification, which can be achieved using DNS extensions (EDNS0, defined in RFC 2671) and DNSSec. EDNS0 allows the DNS response to be larger than the original 512 allowed, while DNSSec allows authentication of the response to prevent cache poisoning. DNSSec requires EDNS0 to operate since it adds cryptographic data to the response. Since DNSSec is becoming popular in today’s security-aware internet, it makes more and more DNS servers support EDNS0 and allows an attacker to achieve large responses to their requests.
The possible size of the response – up to 4096 bytes, allows the attacker to send a small number of short requests, while the replies sent by the DNS server are greatly amplified, exhausting the victim’s internet pipe. Attackers can study the DNS server and find which legitimate queries can result in large replies, and also use DNSSec to make them even bigger with cryptographic data. In many cases, the response can get up to the maximum of 4096 bytes, which gives an amplification factor of x100 for the original request.
[You might also like: DNS and DNS Attacks]
With today’s large internet connectivity, a 100 M connection to the internet can send a modest attack on its own and still cause some damage to a normal site. However, if the attacker has the ability to use this huge 4096 bytes’ response for his 44bytes request and get 100x amplification, the victim server will receive 10G of attack traffic, above its normal traffic bandwidth. Such traffic will cause any normal service to immediately become out of service. Imagine what can be achieved with a botnet of even few of such bots.
Adding to the size of the response, comes the fact that such responses cannot fit into a normal IP packet. In cases such as this, servers use the IP-fragmentation option, which allows them to divide the message into several packets. Using fragmented traffic in the attack makes the attack mitigation even harder – the mitigator needs to store the first packet’s layer 4 data (UDP ports) in a table and apply it to the rest of the packets from the same message. Many network entities are fast exhausted by a lot of fragmented traffic, which makes this attack even more efficient.
Radware’s YouTube DNS amplification attack Video graphically illustrates the structure and flow of a Reflective DNS attack.
After learning all the ins and outs of the DNS reflective attack, one thing remains – how to protect an organization against such attack and mitigate it? Unlike the sophistication of the attack itself, this problem has a known solution – in order to mitigate a DNS reflection attack, you have to have a good detector on-site to quickly detect the attack and prevent downtime. The detector should be smart enough to understand that the attack it sees is saturating the internet connection and traffic diversion needs to take place to a cloud scrubbing center. Once traffic is diverted to cloud scrubbing, it will be cleaned and sent to the site.
The scrubbing itself depends on the amount of similar traffic which is considered legit – does the site sees a lot of UDP traffic? DNS traffic? Fragmented traffic? And if so, what distinguishes it from the attack traffic? Using an automated technique to separate the legitimate and the attack traffic will give you good and fast cloud mitigation and also, some peace of mind.
For more information, check out my previous blog: DNS and DNS Attacks
