V.R.

SIDDHARTHA ENGINEERING COLLEGE

(AUTONOMOUS)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

SE VR

Spoof Detection for preventing DoS attacks against DNS Servers using ICMP

C:

ya

sh

Authors

A.yaswanth Raj Ch.Satyanarayana

an d Sa tya
i

ABSTRACT
The Domain Name System (DNS) is a critical element of the Internet infrastructure. Even a small part of the DNS infrastructure being unavailable for a very short period could potentially upset the entire Internet and is thus very unacceptable. Unfortunately because DNS queries and responses are mostly UDP-based, it is vulnerable to spoong-based denial of service (DoS) attacks, which are difcult to defeat without incurring signicant collateral damage. The key to thwart this type of DoS attacks is spoof detection, which enables selective discarding of spoofed DNS requests without jeopardizing the quality of service to legitimate requests. This paper presents an imaginary situation of possible DoS attack and is a study on spoof detection for protecting DNS servers from such attack. This strategy utilizes python package called scapy.

CHAPTER 1: INTRODUCTION 1.1 Introduction

SE VR

We have implemented this in backtrack a linux based operating system .The aim is to present this as a rewall module called DNS guard. This strategy works much like a packet-filtering router. In the process, a shell level application is developed to make the details to be presented by to the user. This project is the outcome of searching for other possible solutions in detection of spoofed packets. This much simpler idea is proposed as alternate solution rather than the one presented in the IEEE paper mentioned in references.

The Domain Name System (DNS) is a critical component of the Internet infrastructure, because most network services and applications require a translation step from domain name to IP address to just send the packets out. As a result, even a small part of the DNS infrastructure being unavailable for a short period of time could have a signicant rippling effect on the rest of the Internet. However, common DNS queries and responses use UDP as their transport protocol. The combination of the simplicity of the DNS protocol and its use of UDP makes DNS extremely vulnerable to spoong-based Denial of Service (DoS) attack. Unlike TCP, UDP does not use threeway handshake procedure to start a connection and therefore has no way to be sure that a UDP packet indeed comes from where the packets source address indicates. Worse yet, a DNS server only sees one UDP query and replies with one UDP response for most DNS interactions. Therefore it is not possible for a DNS server to ascertain the identity of the requesting host at the DNS level, either.

C:

ya

sh

an

An effective defense against spoong-based DoS attacks on DNS servers requires source address spoof detection. Assuming a DNS server can distinguish between spoofed requests from real ones, it can selectively drop those spoofed ones with little collateral damage. If a DNS server is sure that the incoming requests use a

Sa

tya

genuine source IP address, it can use a ratelimiting strategy to drop packets in a fair way.

decreasing the amount of legitimate requests served by the overloaded servers. The other attack strategy is to exploit DNS servers to amplify attack trafc. The attacker crafts a DNS request that gets a response signicantly larger than the request itself, e.g., a 50-byte request for a 500-byte response. The amplied response is replied to a spoofed third-party victim machine. Under this attack, both the amplifying DNS servers upstream bandwidth and the third-party machines downstream bandwidth could be exhausted. Due to trafc amplication, an attacker can starve the bandwidth of its victims even if his bandwidth is 10 times smaller

SE VR
1.2

Problem statement

Due to the vulnerability existing with the DNS server as it is based on UDP protocol for the processing and transfer of packets. An attacker could take advantage of this vulnerability and launch a DoS attack against a DNS server by spoong the source address of the requests.

Indeed, several spoong-based DoS attacks against DNS have been reported in the past reported that seven of the Internets thirteen DNS root servers became inaccessible for an hour, an attack aiming at Akamais DNS servers blocked nearly all accesses to Apple Computer, Google, Microsoft and Yahoos Web sites for two hours.

By exploiting the existing vulnerability the whole DNS system can be brought down , which virtually effects the whole domains (.com , .net , .gov , .edu , etc ) which in-turn destroys the whole internet . There are two possible DoS attack strategies against DNS servers. The rst is to send a large number of requests to a DNS server to overload it. Because a standard DNS server cannot distinguish between spoofed and non-spoofed requests, it has no choice but to handle all of them when it can, and starts to drop requests indiscriminately when it becomes overloaded. However, legitimate requesters interpret request drops as a sign of congestion and back off its timer for retransmission, thus drastically

C:

ya

1.3

Scope

sh

This project is aimed for linux based operating systems as it's incredibly secure, stable, fast, and proven to be efficient as server/supercomputer OS. It also has a better TCP/IP stack than windows Operating system. This is developed with the intention of making this as a firewall module so that it could be run in a proxy/router of any device of that kind. For executing this project, a system similar to dual-homed device is used and is tested on that device. File management is also required as a file named guard file is used to filter packets and other files are used to present information to the user.For testing purposes a device connected to internet through fast Ethernet and connected to local network via wireless interface is used.

an

Sa

tya

ii

1.4

Objective

Problem statement:

identified as spoofed packets and blindly forwarded by router to server (DNS). In order to indentify illegitimate packets we thought of using ICMP req and reply protocol , the way we approached is we hold every DNS query packet in the DNS guard at router level and certain certain constraints are checked before forwarding it . These include the match pair of IP and MAC this matching pair is identified by using a special file called guard file which exists in DNS guard. In order to implement the code python language has been used as it as a package called SCAPY which is a powerful packet manipulation open source package available .The best deployable device would be a LINUX based O.S. This is based on the idea that if a ICMP PING is received by a system, then if the IP and MAC in the ping packet matches to that of the system, then it would send the reply response. Considering this fact,the spoofed packet would have Ip and Mac that wont match(according to the attacking scenario) . That is why,we store the Ip and the corresponding Mac in the DNS query Packet in a separate file called Guard File only if it is a legal packet. To identify if it is really a legal one,we send the ping to the Ip and Mac from the DNS query packet.If the packet is not spoofed,sure the reply comes , then we would know it is a legal packet.Next,the Ip and Mac would be stored in the guard file.From the next DNS request on,Ip and Mac duo are checked in this file,If there is mismatch then it is a spoofed packet.If the Ip field doesnt exist then we would gain

SE VR
Solution: 1.5 Approach

Victim sends DNS Query packet to the DNS Server.Before it reaches the DNS Server ,the packet as it reaches the internal router is sniffed by the hacker in the middle.Hacker manipulates the packet: changes the source IP of the packet. As the spoofed packet reaches the server,it responds to it and send the DNS Response.But as the response reaches the Internal Router,it is stripped off to see that it is not intented to reach legitimate user and hence the packet is destroyed.Extending the same in the large scale will finally lead to ultimate denial of legitimate request of the user which leads to success of DoS attack. This problem came into existence firstly because it is reaching the DNS server for the request.If the spoofed packet is stopped at the Router its self then this couldnt have arised.The necessary code to be executed to identify the spoofed packet is presented in a module called DNS GUARD which is integrated with the router that identifies the spoofed packet and destroys there its self preventing it to reach the DNS Server there by preventing the attack.

According to the scenario taken the possible attack we are considering is change of the ip address or mac address by an intruder in local private network (LAN). This packets are filtered at router level by a traditional packet filter router ,but are not

C:

ya

sh

an

Sa

tya

iii

apply Ping-Reply strategy to know if that deserves to be entered into the guard file. It so happens that the reply packets can be lost.So,we send ping for 5 times(counter is set to five ,determined by experimental basis).Then,it is known that the reply is returned atleast once in those 5 requests.

SE VR

C: ya sh an d Sa tya
iv

CHAPTER2:LITERATURE SURVEY 2.1 Introduction

where the cookie could be represented by a referrals name or a part of an IP address. The second scheme is TCP-based DNS, where the cookie is represented by TCPs sequence number. The third scheme is to modify DNS by explicitly introducing a cookie exchange procedure. The rst two schemes do not require modications to LRS(Local Recursive Server), whereas the third scheme does.

SE VR
2.2 Existing System
paper.

This project is actually based on an IEEE paper SPOOF DETECTION FOR PREVENTING DoS ATTACKS AGIANST DNS.This paper gave us an idea on different types of DNS attacks out of which spoofing attack is what we have considered. This paper also provided different strategies for detecting spoof packets .The paper is based on real time DNS attack.We considered typical attack scenario in which IP and MAC addresses spoofed by intruder for executing the system.

DNS-based: Embedding Cookies in DNS Messages:

The ANS can return two kinds of answers: a referral answer or a non-referral answer. A referral answer provides information about the ANSs in the next level of the domain name hierarchy. A nonreferral answer is any answer that is not a referral.

Different strategies are presented in the paper for spoof detection. In all those strategies, a DNS server sends a distinct cookie to each requesting host, and the requester associates each request it sends to the DNS server with the servers corresponding cookie. By checking the cookie that comes with each incoming request, it is possible to determine if a DNS request indeed originates from source address indicated in the packet. Three schemes are proposed in that . The rst scheme is to embed cookies into legitimate DNS messages,

C:

ya

sh

1) Referral Answer: Embedding Cookie

in NS Name: The referral information in DNS is represented in two types of resource records. The rst type is the NS (Name Server) record, which provides the name of an ANS. The second type is the A (Address) record, which provides the IP addresses of an ANS. If an LRS only receives the name of an ANS, it issues another query to nd out the ANSs IP address and query the ANS. The key idea here is to exploit the fact thatan LRS is capable of executing further queries when the LRS only receives the name of an ANS. Basically this algorithm replaces the real name of an ANS with a fabricated name in which the cookie is embedded. That is, an LRS never sees the

an

Sa

tya

real NS records. Instead, a fabricated NS record is received for each domain. Embedding Cookie in NS Name and IP: The above scheme does not work if the ANS returns non-referral information, e.g., an A (Address) resource record for the queried name. A second cookie is introduced to achieve second request. The key idea is to fabricate an ANS for each non-referral answer. For each fabricated ANS, two records are faked: an NS record and an A record. Each record embeds one cookie.

2)Non-Referral Answer:

SE VR

2.3. Proposed Solution

We simple used ICMP ping and Request strategy to detect spoofed packets.There by reducing the complicated cookie strategies.Instead of using a cookie to find if the query is legal or not we hold the packet and send a ICMP ping request with the IP and MAC obtained,if there is a reply to the ping request then it will be known that it is a legal packet,decision is taken accordingly.

2.4 System Architecture

Our Dns guard can be taken as a module in DMZ.This Dns guard works much like a packet filter router. Though the kind of attack we took in this project is unlikely to happen, this project helps us to have deep insight into the working details of network like packet sniffing,packet manipulating etc. The Dns guard is implemented in a router/Dual-homed PC/proxy.

C:

The functionalities of a DNS guard can be the follwing pic:

ya

sh an
The DNS guard is placed in DMZ zone. In computer security, a DMZ, or De Militarized Zone, is a physical or logical sub network that contains and exposes an organization's external services to a larger untrusted network, usually the Internet. Information technology professionals normally refer to the term as a DMZ. It is sometimes referred to as a perimeter network. The purpose of a DMZ is to add an

Sa

tya

vi

additional layer of security to an organization's local area network (LAN); an external attacker only has access to equipment in the DMZ, rather than any other part of the network.

SE VR

C: ya sh an d Sa tya
vii

CHAPTER3:FUNCTIONAL REQUIREMENTS

To interact with a file module to perform operations.

Scapy a Python program that enables the user to send, sniff and dissect and forge network packets is required.This capability allows construction of tools that can probe, scan or attack networks.In other words, Scapy is a powerful interactive packet manipulation program. It is able to forge or decodepackets of a wide number of protocols, send them on the wire, capture them, match requests and replies,and much more. Scapy can easily handle most classical tasks like scanning, tracerouting, probing, unittests, attacks or network discovery. It can replace hping, arpspoof, arp-sk, arping, p0f and even someparts of Nmap, tcpdump, and tshark) . Functions used: sr : Send and receive packets at layer 3 sr1 : Send packets at layer 3 and return only the first answer srp : Send and receive packets at layer 2 srp1 : Send and receive packets at layer 2 and return only the first answer sniff : Sniff packets The functional requirements include: Sniffing the packets in the LAN Filtering packets Storing packets Destroying packets Sending packets created Receive reply to the sent packets

It is required that file module has to perform the following functionalities, Check If Ip entry exists Check if Ip and Mac duo pair matches Open and close file Write Ip and Mac to file Dumping packet information in to file Display content of file to the user.

SE VR

C:

ya

sh an d Sa tya
vi

CHAPTER4:SYSTEM REPRESENTATION 4.2 Class and Activity Diagrams

Our project requires a shell level application to be developed,Hence it is required to develop class and activity diagrams presenting the classes we have developed and the logic is presented in Activity diagrams.

SE VR

4.1 Running Environment

We used a linux based backtrack operating system where our project is executed. **INTERNET::ETH0>>>>>>[[ BACKTRACK]] >>>>>ETH1::LAN** Eth0 is the fast Ethernet interface where the system gets connected to the internet.Eth1 is the Wireless Interface where other PCs are connected.

C:

ya

sh an d Sa tya
1

Class Diagram for DNS GUARD

The class diagram presents classes that are possible in our project and corresponding operations and attributes. Class file deals with all file operations like opening ,closing,reading,writing. Class dnsguard has critical functions in our project like sniffing,filtering and dissecting packet These classes use Scapy a python based packet manipulation package

rounded activities;

rectangles representing

SE VR
-Activity:

diamonds representing decisions; bars represent the start (split) or end (join) of concurrent activities; a black circle represents the start (initial state) of the workflow; an encircled black circle represents the end (final state).

The activity diagram presents the tasks and gives details information about how the Spoofed packets are detected. The diagram presents the conditions that are checked and activities performed. The Activity diagram is a graphical representation of workflow of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control. Activity diagrams are constructed from a limited number of shapes, connected with arrows. The most important shape types used:

C:

Activity states, which represent the performance of a step within the workflow.Transitions that show what activity state follows after another. This type of transition can be referred to as a completion transition. It differs from a transition in that it does not require an explicit trigger event; it is triggered by the completion of the activity that the activity state represents. Decisions for which a set of guard conditions are defined. These guard conditions control which transition of a set of alternative transitions follows once the activity has been completed. You may also use the decision icon to show where the threads merge again. Decisions and guard conditions allow you to show alternative threads in the workflow of a business use case. Synchronization bars, which you can use to show parallel subflows. Synchronization bars allow you to show concurrent threads in the workflow of a business use case..

ya

sh

an

Sa

tya

SE VR C: ya
Activity Diagram for DNS GUARD

sh an d Sa tya
1

CONCLUSION
DNS is one of the most critical components of the Internet infrastructure, but is vulnerable to spoong based DoS attack. A DNS server cannot tell if a request packet comes from the IP address as indicated in the request. Spoofed attack requests result in DoS attack by overloading a DNS server or by saturating a victims bandwidth via amplied DNS response. The key technology to protect DNS from DoS attacks is spoof detection. Once spoofed requests are identied, a DNS server can safely drop the spoofed requests without any collateral damage. Attack requests using real IP addresses can be rate-limited. The key contribution of this paper is that it provides a alternate solution for DNS spoof detection rather than using complicated cookies. Each DNS Query is hold and conditions are checked to decide whether to forward or destroy the packet. This paper presented just one solution but paves way for moving into much simpler solution. The efficacy of this approach has yet to be tested. But there hasnt been much overhead in checking when compared to the cookies approach. This approach can further be extended by using the existing ARP table to sense the spoofed packets. The perfect usage of this approach in real time situations and the need of these kind of approaches to detect the DNS spoof packets to prevent DoS attacks has yet to be considered carefully.

Thus, the solution presented can be implemented as part of TCP/IP protocol suite as a method that is followed universally to prevent such attacks. Presenting this as it is would be in efficient , so there must be improvement in this approach and scope has to be extended for its implementation. That would be the future ideas of the project.

SE VR

C:

ya

sh an d Sa tya
1