Spoof Detection Abstract Watermarked

8/3/2019 Spoof Detection Abstract Watermarked

1/13

i

V.R.SIDDHARTHA ENGINEERING COLLEGE(AUTONOMOUS)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Spoof Detection forpreventing DoS attacks against

DNS Servers using ICMP

Authors

A.yaswanth Raj

Ch.Satyanarayana


2/13

i

ABSTRACTThe Domain Name System (DNS) is

a critical element of the Internet

infrastructure. Even a small part of the DNS

infrastructure being unavailable for a veryshort 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 spoofing-based denial of

service (DoS) attacks, which are difficult to

defeat without incurring significant

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.

We have implemented this in

backtrack a linux based operating system

.The aim is to present this as a firewall

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.

CHAPTER 1: INTRODUCTION

1.1 IntroductionThe 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 significant

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

spoofing-based Denial of Service (DoS)

attack. Unlike TCP, UDP does not use three-

way handshake procedure to start a

connection and therefore has no way to be

sure that a UDP packet indeed comes fromwhere 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.

An effective defense against

spoofing-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


3/13

ii

genuine source IP address, it can use a rate-

limiting strategy to drop packets in a fair

way.

1.2 Pr oblem statementDue 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 spoofing the source

address of the requests.

Indeed, several spoofing-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 first 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 nochoice 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

decreasing the amount of legitimate requests

served by the overloaded servers.

The other attack strategy is to exploit

DNS servers to amplify attack traffic. The

attacker crafts a DNS request that gets aresponse significantly larger than the request

itself, e.g., a 50-byte request for a 500-byte

response. The amplified 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 traffic

amplification, an attacker can starve the

bandwidth of its victims even if his

bandwidth is 10 times smaller

1.3 ScopeThis 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 Operatingsystem.

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 otherfiles 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.


4/13

iii

1.4 ObjectiveProblem statement:

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.

Solution: 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 packetis 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.

1.5 ApproachAccording 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

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 iswe 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 wewould 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


5/13

iv

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 byexperimental basis).Then,it is known that

the reply is returned atleast once in those 5

requests.


6/13

v

CHAPTER2:LITERATURE

SURVEY

2.1 IntroductionThis 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 spoofpackets .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.

2.2Existing SystemDifferent 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

paper.

. The first scheme is to embed

cookies into legitimate DNS messages,

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 first two schemes do not

require modifications to LRS(Local

Recursive Server), whereas the third scheme

does.

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 non-

referral answer is any answer that is not a

referral.

1) Referral Answer: Embedding Cookie

in NS Name: The referral information inDNS is represented in two types of resource

records. The first 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 find

out the ANSs IP address and query the

ANS. The key idea here is to exploit the fact

thatan LRS is capable of executing furtherqueries 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


7/13

vi

real NS records. Instead, a fabricated NS

record is received for each domain.

2)Non-Referral Answer: Embedding

Cookie in NS Name and IP: The above

scheme does not work if the ANS returnsnon-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.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 ofnetwork like packet sniffing,packet

manipulating etc.

The Dns guard is implemented in a

router/Dual-homed PC/proxy.

The functionalities of a DNS guard can be

the follwing pic:

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 aperimeter

network. The purpose of a DMZ is to add an


8/13

vii

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.


9/13

vi

CHAPTER3:FUNCTIONAL

REQUIREMENTS

Scapy a Python program that enablesthe 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 3sr1 : 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

To interact with a file module toperform operations.

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.


10/13

1

CHAPTER4:SYSTEM

REPRESENTATION

4.1Running EnvironmentWe 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 theinternet.Eth1 is the Wireless Interface

where other PCs are connected.

4.2Class and Activity Diagr amsOur 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.


11/13

Class Diagram for DNS GUARD

The class diagram presents classes

that are possible in our project andcorresponding operations and attributes.

Class file deals with all fileoperations like opening

,closing,reading,writing.

Class dnsguardhas critical functionsin our project like

sniffing,filtering and dissecting

packet

These classes use Scapy a pythonbased packet manipulation package

-Activity:

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 graphicalrepresentation 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:

rounded rectangles representingactivities;

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 representsthe end (final state).

Activity states, which represent the

performance of a step within theworkflow.Transitions that show whatactivity state follows after another. This type

of transition can be referred to as acompletion transition. It differs from a

transition in that it does not require anexplicit trigger event; it is triggered by the

completion of the activity that the activitystate represents.

Decisions for which a set of guard

conditions are defined. These guardconditions control which transition of a set

of alternative transitions follows once theactivity has been completed. You may also

use the decision icon to show where thethreads merge again. Decisions and guard

conditions allow you to show alternativethreads in the workflow of a business use

case.

Synchronization bars, which you can use

to show parallel subflows. Synchronizationbars allow you to show concurrent threads in

the workflow of a business use case..


12/13

1

Activity Diagram for DNS GUARD


13/13

1

CONCLUSION

DNS is one of the most critical

components of the Internet infrastructure,

but is vulnerable to spoofi

ng based DoSattack. 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

amplified DNS response. The key

technology to protect DNS from DoS attacks

is spoof detection. Once spoofed requests

are identified, a DNS server can safely dropthe 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 andthe 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.

Documents

Spoof Detection Abstract Watermarked