Distributed denial-of-service (DDoS) attacks can be a major threat to the availability...
DNS Amplification Attacks Detection with NetFlow or sFlow
Picture 1: DNS Response Length 618 Bytes
|Note: BAF is calculated as the number of UDP payload bytes that an amplifier sends as a response to the query, compared to the number of UDP payload bytes of the query.|
The asymmetric nature of DNS query and response pairs in terms of their size is very well known and used in the Distributed Denial of Service (DDoS) amplification attacks. DDoS DNS amplification attacks exploit DNS servers (resolvers) to target other systems. The goal of the attack is to disrupt a targeted system by consuming its resources such as CPU, memory or bandwidth. An attacker keeps sending a stream of DNS queries to many Open DNS resolvers, instructing them to reply back to a victim with the DNS response messages. DNS queries contain a spoofed source IP address matching the victim’s IP address. As a result, amplified DNS queries effectively overwhelm a targeted system so it becomes inaccessible.
|Note: Other application protocols such as Memcached, NTP, LDAP, Quake that use connection-less UDP transport protocol can be used in a DDoS amplification attack as well. They are more suitable for conducting the DDoS amplification attacks as they have better BAF .|
The magnitude of a successful DDoS DNS amplification attack relies on three factors. Firstly, it is a number of hosts flooding forged DNS requests. Very often, an attacking machine is a part of a large botnet, controlled by the command-and-control server (C&C). A side effect of using a botnet is the obfuscation of the attacker’s identity as it is impossible to track an attacker without taking control of the C&C server. A volume of the DNS amplification attacks also relies on the number of open DNS resolvers used to reflect attack to the victim. Open DNS Resolver is any DNS resolver that is publicly accessible, and willing to resolve recursive queries for anyone on the Internet. According to the Open resolver project, there are 15 million resolvers that respond to queries in some fashion (2017-01-22) and 10 million of these pose a significant threat. The last factor that counts is BAF.
DNS request message of some 60 bytes can be configured to elicit a response message of over 4000 bytes to the target server – resulting in a 70:1 amplification factor .
Evidences of a DNS DDoS Amplification Attack in the NetFlow Records
The volume of DNS response packets is larger than normally expected. If more than one DNS resolver is used in the attack, flow records indicate DNS responses from the increased amount of contacted DNS servers. Moreover, there is an absence of appropriate DNS queries in NetFlow data. Only the DNS responses are presented in flow records (Picture 2).
Picture 2: A Large Amount of DNS Responses in NetFlow Records
DDoS DNS Amplification Attack Detection in NetFlow Records
Detection Logic Based on Network Traffic Statistics Analysis
The detection logic using statistical analysis of network traffic is based on a total number of DNS response packets per flow and an average number of bytes per flow. The attack is detected when the values exceed a defined threshold. Therefore, this method depends on the ability to define a proper threshold. A threshold is subjected to optimization and is dependent on network profiles. On one hand, if the threshold is set to a high value, some attacks may go unnoticed. On the other hand, the reduction of the threshold may lead to false positives. The detection method based on statistical analysis is susceptible to delays. DDoS DNS amplification attack would go undetected until enough NetFlow records are collected that exceed the threshold value.
As for setting a proper threshold in order to avoid inaccuracy or false positives, the recent study released in the Sindh university research journal gives us the recommended values. The flows are considered suspicious if the total number of packets per flow exceeds 1000 packet counts, or if the average number of bytes per flow exceeds 900 bytes for flows with less than 1000 packet counts.
Detection Logic Based on Pattern Matching
Pattern matching detection logic is based on using certain patterns extracted from DNS header. In contrast to fixed NetFlow, sFlow can export those patterns from the IP payload. Therefore, DNS attributes such as query ID, query type, query name, return code can be extracted from the sFlow packets and used as filters. For instance, the Transaction ID is the same for both the DNS query and response message (Picture 3). If Transaction ID in received DNS responses does not match ID in sent DNS queries, there is an attempt of DNS amplification attack. Pattern matching detection of DDoS DNS traffic is fast and distinctive as it is not depended on the exceeding defined threshold values. It can be used along with traffic statistics method of detection to avoid false positives and inaccuracy. For instance, DNS traffic amplification will be detected if a certain number of DNS transaction IDs are not matched.
Picture 3: Same Transaction ID in DNS Query and Response Messages
NetFlow v5 Configuration on Cisco router NetFlow-exporter
ip flow-export version 5 ip flow-export destination 126.96.36.199 2055 ip flow-cache timeout active 1 ip flow-cache timeout inactive 15 interface GigabitEthernet0/0 ip flow ingress
Picture 4: Network Infrastructure for Simulation and Detection of DDoS DNS Amplification Attack
|Note: The exhibit is intended for educational purpose only. Noction is NOT responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of software used in this lab.|
We are going to examine flow records received by the server NetFlow-collector for traffic attributes such as source UDP port 53, number of received bytes and packets in order to detect ongoing DDoS DNS amplification attack. The threshold values match the values that we have defined in part 2.1. A simple BASH script serves this purpose.
#!/bin/bash nf_record_dir='NetFlow' dns_ddos_count_all="0" no_flow='No matched flows' for file in "$nf_record_dir"/*; do dns_ddos_count=$(nfdump -R "$file" -o csv -q 2>/dev/null '(proto udp and src port 53 and packets > 1000) or (proto udp and src port 53 and packets < 1001 and bytes > 900)' | grep -v "$no_flow" | wc -l) dns_ddos_count_all=$((dns_ddos_count_all + dns_ddos_count)) done [ "$dns_ddos_count_all" -gt 0 ] && echo "Warning! Found '$dns_ddos_count_all' suspicious DNS querry flows, possible DNS DDoS attack?" || echo "Status 'OK', no suspicious DNS flows found" exit 0
Now, start to capture NetFlow records on the NetFlow collector with the command below. The utility nfcap is listening on the port 2055 and creating a file with flow records every 30 seconds.
Run the script in a loop. The output is depicted in Picture 5. The number of suspicious NetFlow records reflects the ongoing DoS DNS amplification attack and it depends on the processing of flow records by nfdump utility.
Picture 5: Detection of DNS Amplification Attack Detection Process Based on Suspicious NetFlow Records
The scale and frequency of DDoS amplification attacks launched against companies have a growing tendency with undesirable consequences in terms of service disruption. When precisely planned and conducted, these can bring financial losses and damage reputation. For this reason, they should be taken seriously and adequate precautions should be applied in advance. Fast detection is the first step in the effort of DDoS mitigation and NetFlow (or sFlow) is one of the methods that can be used for this purpose. Moreover, NetFlow records can be used in the process of post-attack investigation.
SUBSCRIBE TO NEWSLETTER
You May Also Like
Diverting DDoS traffic using the FlowSpec redirect via VRF capability. Configuration example.
In the previous article, we described different DDoS attacks and their impact on network infrastructure. We focused on...
BGP traffic rerouting, Flowspec, and the DDoS Scrubbing Centers
When it comes to distributed denial-of-service (DDoS) attacks, they are far from a downward trend. Although the...
Optimizing BGP convergence
When there is a change in the reachability of one or more prefixes, BGP needs to do some work to adapt to that change...