02-11-2016, 04:01 PM
1463620812-MastersReport.doc (Size: 214.94 KB / Downloads: 6)
UDP attacks have become very common in todays world. The aim of the research project is to identify the reason behind such attacks and to come up with a solution to prevent such attacks. The project focusses on DNS and NTP amplification attacks.
DNS and NTP amplification attacks can be caused when a certain query with a spoofed IP address is sent to open DNS or NTP servers which in turn reply with significantly larger replies that leads to a Denial of Service attack.
We have come across protocols that are the reasons for such kinds of attacks. With the help of Network Function Virtualization, we have proposed a solution that can help prevent such attacks while keeping in mind the performance of the network.
The goal of the project is to implement the solution by maybe not trying to affect the networks performance.
INTRODUCTION
UDP traffic has recently been used extensively in flooding-based distributed denial of service (DDoS) attacks, most notably by those launched by the Anonymous group. Despite extensive past research in the general area of DDoS detection/prevention, the industry still lacks effective tools to deal with DDoS attacks leveraging UDP traffic.
UDP is vulnerable to amplification attacks where a small request can lead to a significantly large response. In this project we concentrate on two kinds of amplification attacks:
DNS Amplification Attacks:
In this type of attack, the attacker sends a query for as much information as possible, generally of type “ANY” with a spoofed IP address to be the victim’s IP address to an open DNS server. As a result of this request, the DNS server will result in generating a large amount of response messages, i.e. a 50-byte request can produce a total of 500 bytes in response messages. Since the response traffic is coming from valid servers, it is hard to prevent this type of attack.
NTP Amplification Attack:
NTP is used for time synchronization between a server and a client. A “MONLIST” request sent to the NTP server can result in the retrieval of a list of addresses of clients that queried the server before the request. This list can contain a great number of IPs, up to 600. An attacker can spoof its source IP to a victim’s in order to request a “MONLIST”, possibly to multiple NTP servers. The amplified response will thus be redirected to the victim and cause a DDoS attack.
LITERATURE REVIEW
After researching for the project we cam up with a list of protocols and the commands that are responsible for such kind of attacks. The protocols have been listed in table 1.
TABLE 1
We focus on only DNS and NTP amplification attacks as of now. A DNS amplification attack is caused when an attacker sends a DNS “ANY” request with a spoofed IP address to a DNS server. The DNS server will respond to the victims IP address with a packet that is significantly bigger. Many requests of such kind can lead to using up a lot of the victim’s resources thereby causing an amplification attack. Same is the case for an NTP attack where the attacker has to send an NTP “MONLIST” request with a spoofed IP address to a NTP server thereby causing an amplification attack.
As of now there is no concrete solution to prevent such kinds of attacks unless these commands are disabled on the servers. We propose a solution to prevent these attacks without changing the configuration of the servers.
METHODOLOGY & CHALLENGES
Initially, under the assumption that all the replies from the servers will have the same payload we came up with a solution to use a Bloom filter to block all the duplicate packets after a certain threshold, but this solution didn’t bode well since we discovered that more advanced tools have the capability to change the payloads and their size for every packet.
In our proposal, we have implemented a code on a virtual machine that is connected to the switch directly connected to these servers. The switch has a rule installed that sends all DNS and NTP packets to the virtual machine. The switch uses the port numbers 53 and 123 for DNS and NTP packets respectively.
On receiving the packets, the virtual machine checks the packets payload to see if the DNS packets are using the “ANY” query and if the NTP packets are using the “MONLIST” query. If the packets don’t use such commands they are sent back to the switch to be sent further to the servers as they can’t cause amplification attacks.
The method we used to parse the DNS packets can be explained with the two Wireshark files below.
FIGURE 1
FIGURE 2
Figure 1 shows a normal DNS query for
HYPERLINK "http://www.redhat.com"
www.redhat.com
. When we go further in the packet we can see that under the queries section the query type is marked as “A” since the command is asking only for A records from the DNS server. Figure 2 shows the packet capture when a DNS “ANY” query is sent. Here we can see that under the queries section the query type is marked as “ANY”. Therefore, we use the “query type” field to detect the malicious packets.
The challenge we faced here was that the query section length is not constant as the the domain name lengths keep changing. Figure 3 and 4 show a DNS query for
HYPERLINK "http://www.cisco.com"
www.cisco.com
and support.novell.com respectively. Since both these domain names have different lengths it is difficult to extract the Query Type. The solution we came up with is based on the fact that the UDP header is always 8 bytes and the length of the UDP packet can be extracted from the UDP header. Since the length of all the other fields are fixed we were able to extract the Query Type field. Foe example: In figure 3 we can see that the length of the UDP packet is 39 bytes. Out of that 8 bytes are taken up by UDP header. That leaves us with 31 bytes. In the DNS section the first 12 bytes and the last 4 bytes are fixed. That means the domain name is 15 bytes (31-12-4 bytes) long and therefore the Query Type field starts at 28th byte.
FIGURE 3 FIGURE 4
In the case of NTP the the request code field is used to identify the plackets that can cause an NTP attack. Figure 5 shows the arrangement of an NTP packet. The fourth byte represents the Request code which is 0x2F for a “MONLIST” command.
FIGURE 5
FIGURE 6
Figure 6 gives a brief overview of how our proposal can be implemented. Here an openflow switch is connected to a controller, 2 hosts, a filter VM and a server(DNS/NTP).
Whenever a DNS/NTP packet comes in, the rule on the switch sends it to the filter VM for further processing. The filter VM based on the methods described above parse the payloads and determine if the packet can cause an amplification attack or not. If the packet is benign then it is sent back to the switch else the VM adds an entry to its table with the packets source IP address, protocol type and a counter. The packet is then sent back to the switch so that it can reach the server. If there are less than 3 requests of such kind in 10 seconds then the requests are sent through to the server but if it exceeds that, then whenever such packets come in, the counter on the VM keeps increasing which after reaching a certain threshold starts dropping such packets.
This way we make sure that such requests still get to the server and most importantly the server responds to them but if the same packets are coming in at an unusually faster rate then it can be identified as an aplification attack. By blocking such packets the VM can prevent the amplification attack.
Taking figure 6 as an example, host H1 spoofs host H2’s IP address and sends 5 DNS “ANY” requests to the server within 10 second. Under normal circumstances, the server would send back 5 significantly large responses to H2 which might use up all its resources and cause a Denial of Service attack. If our solution is implemeted then on the first packet arrival, the VM adds an entry to its table with H2 IP adress, Protocol type DNS and counter as 1. When the next two packets come in the counter is increased to 3 and the threshold is reached. Till now only the counter value was increasing but the packets weren’t affected at all, that is they were being sent to the server and H2 was getting response messgaes. But when the fourth and the fifth packet come in the VM detects it and starts dropping the request which leads to H2 not getting any response messgaes from now on. This is how the amplification attack is prevented.
Another challenge we faced was relating to performance. Since a DNS/NTP server would send out a lot of responses to different hosts the performance would be affected if all those packets are sent for parsing to the VM. But since the controller already sets up the path when the servers get request it didn’t turn out to be a problem.
IMPLEMENTATION & RESULTS
FIGURE 7
The topology used in the impementation of our soultion is shown in Figure 7. The switch is connected to 4 hosts. H1 acts as the attacker and spoofs the IP 10.0.0.1 of the victim. H3 acts as the server and H2 is the implementation of NFV which acts as a VM to detect the mailicious packets. By installing rules on the switch, all the DNS and the NFV packets that reach the switch are directed to H2. If the packets are not of type “DNS ANY” or “NTP MONLIST” then H2 forwards them back to the switch but if they are malicious then the switch adds them to a dictionary to keep track of them and forwards them to the switch. Depending on the users value of C and T, H2 has the capabitily to block the malicious packets after a certain threshold C and also to refresh the list after T seconds.