amplification and drdos attack defense – a survey and …against future amplification attacks....
TRANSCRIPT
Amplification and DRDoS Attack Defense –A Survey and New Perspectives
Fabrice J. Ryba∗, Matthew Orlinski∗, Matthias Wahlisch∗, Christian Rossow†, Thomas C. Schmidt‡∗ Freie Universitat Berlin, Berlin, Germany,
Email: {fabrice.ryba, m.orlinski, m.waehlisch}@fu-berlin.de† Saarland University, Saarbruecken, Germany,
Email: [email protected]‡ HAW Hamburg, Hamburg, Germany,
Email: [email protected]
Abstract—The severity of amplification attacks hasgrown in recent years. Since 2013 there have been atleast two attacks which involved over 300Gbps of attacktraffic. This paper offers an analysis of these and manyother amplification attacks. We compare a wide selectionof different proposals for detecting and preventing am-plification attacks, as well as proposals for tracing theattackers. Since source IP spoofing plays an importantpart in almost all of the attacks mentioned, a survey on thestate of the art in spoofing defenses is also presented. Thiswork acts as an introduction into amplification attacks andsource IP address spoofing. By combining previous worksinto a single comprehensive bibliography, and with ourconcise discussion, we hope to prevent redundant work andencourage others to find practical solutions for defendingagainst future amplification attacks.
I. INTRODUCTION
Denial of Service (DoS) attacks attempt to make amachine or network connected to the Internet unavailablefor its intended purpose [1]. In most cases DoS attackscause a complete loss of Internet connectivity for thevictim [2]. The motivation for DoS attacks can befinancial [3], political [2], reputation [4], or purely fordisruptive purposes [5].
This paper will focus on a particular type of DoSattack where the attacker amplifies the amount of attacktraffic by targeting vulnerabilities in Internet protocolsand services. These kinds of attacks are called amplifi-cation attacks [6]–[12].
The ease of performing amplification attacks andgreater understanding of their affect has led to an in-crease in attacks in recent years [13], [14]. In 2014the OpenDNS Security Lab claimed to see over 5,000different amplification attacks every hour [15].
The most predominant form of amplification attackuses vulnerabilities in the Internet Protocol (IP) to trick
third-party servers into sending data to a victim [16].This is sometimes called reflection because attackers“reflect” attack traffic off of benign third-party servers.UDP based protocols that have a higher response payloadsize than the requests are also often used as the methodof attack traffic amplification.
By combining reflection and amplification, attackershave initiated attack traffic volumes which are signifi-cantly larger than their uplink bandwidth [2], [3], [5],[17]. Furthermore, it is not only the victim who isaffected by these types of attacks. Entire networks maystruggle to cope with the extra bandwidth and processingdemands placed on them because of the huge volume ofattack traffic [17].
Defending against amplification attacks is challengingfor network operators for at least four reasons. Firstly,the attacker sends only a small amount of (triggering)packets which are hard to detect in high volume uplinks.Secondly, attackers may issue commands to botnets ofslave machines to attack from multiple locations atthe same time [9]. Thirdly, in cases where reflectionis used, attack packets are sent to victims by benignthird-parties such as open DNS resolvers [18]. Fourthly,when multiple third-parties are used the volume of attacktraffic generated at a single server or router may beindistinguishable from normal traffic.
It is common to see amplification attacks also referredto as Distributed Reflective Denial of Service (DRDoS)attacks [19], [20], DNS reply flooding [21], or simplyreflection attacks [22]. However, in Section II we willoffer a distinction between reflection and amplificationand discuss application layers protocols other than DNSwhich are used in amplification attacks. We will alsoargue that the terms reflection and amplification canbe confusing because not all reflection attacks use am-
arX
iv:1
505.
0789
2v1
[cs
.NI]
29
May
201
5
plification [23], and not all amplification attacks usereflection [8].
In Section II, we present prominent incidents from thepast and systematically discuss the problem space. Wethen describe methods to prevent amplification attacksin Section III, with a special focus on reflection and IPspoofing in Section IV. We finish the discussion aboutthe solution space in Section V by presenting approachesto detect amplification attacks. Finally, we conclude inSection VI.
II. AMPLIFICATION ATTACKS
In this section we will provide an introduction toreflection and amplification attacks. We start with abrief review of previous incidents and describe the mostcommonly used techniques. We then discuss the problemspace as a whole.
A. Historical Background
In 1999, AusCERT [24] warned about amplificationattacks where attackers trick DNS servers into sendinglarge amounts of data to spoofed IP addresses [16]. To-day, DNS is widely used in amplification attacks becausea 60 byte request from an attacker can easily generatea 512 byte response [2], [5], [6]. Furthermore, DNSservers which support Extension mechanisms for DNS(EDNS) [25] can generate responses which are nearly100 times larger than requests [20]. Some attackers evenensure large responses by creating domains specificallyto use in amplification attacks [15].
Any public DNS server which is configured to respondto requests for hosts outside of their domain can beused in inter-domain amplification attacks. DNS serversthat are configured to respond to all such requests areknown as open DNS resolvers. According to the OpenDNS Resolver Project approximately 25 million openDNS resolvers currently “pose a significant threat” to theInternet [18]. It is also not difficult to find enough openDNS resolvers to use in amplification attacks. Rossowshowed that it currently only takes 90 seconds to acquirea list of 100,000 [20].
Any Internet service or protocol which can be usedto amplify attack traffic is an amplifier. Amplifiers arenot limited to DNS servers and other application layerprotocols. For example, prior to 1998 attackers weresending ICMP requests to the broadcast address of net-works whilst spoofing the source IP address of victims.The routers responsible for the networks then broadcastthe requests to all of the hosts on their network. Theseattacks are known as Smurf attacks [26], [27], and in
Smurf attacks the routers which broadcast the requestsact as amplifiers because they increase the volume ofattack traffic.
End hosts which respond to requests after they arebroadcast may be amplifiers as well. For example, inFraggle attacks an attacker may send CharGen requeststo the broadcast address of many networks at the sametime [28]. End hosts which receive CharGen requestsmay respond with much more data than they receive,thus the end hosts in Fraggle attacks are amplifiers aswell as the routers which broadcast the request.
The DNS, Smurf, and Fraggle amplification attacksdescribed so far all use source IP address spoofingto trick third-parties into attacking a different IP ad-dress [16]. Source IP address spoofing also makes itvery difficult for the victim to track attackers becauseall attack traffic they receive will come from third-parties. UDP is also used by attackers as the transportlayer protocol because it is stateless and has no built inmechanism to verifying the source IP address of packets.
Recently, another UDP based protocol (SSDP) hasbeen used with source IP address spoofing in amplifi-cation attacks. The United States Computer EmergencyReadiness Team (US-CERT) first issued a warning aboutSSDP in January 2014 [29], and in October 2014 it wasused to generate 54Gbps of traffic in a single attack [30].
Other well documented attacks using UDP and sourceIP address spoofing are the MIT SNMP based at-tack [31], and the CloudFlare attack which reached apeak of nearly 400Gbps using 4,529 NTP servers [17].The huge volume of traffic generated in the Cloud-Flare attack was caused by a command in NTP called“monlist”, which returns a list of the previous 600 IPaddresses to access the server. Monlist does not affectthe core functionality of NTP and should be disabled byupgrading to version 4.2.7 and above [32].
There is also another category of amplification attackin the literature which we have not yet covered. In 2009Shankesi et al. [34] described an amplification attack asbeing where ”the number of messages on the networkcan amplify to essentially an arbitrary large number” [8].However, this definition doesn’t take into account thesize of packets which is an important factor in manyprevious amplification attacks. The amplification attacksdescribed by Shankesi et al. use fork loops to attack VoIPnetworks using SIP [34]. Fork loops are situations whererequests are sent between SIP proxies indefinitely and atleast one extra request is generated every iteration [8].Using this type of amplification attack it is possible tocause 2 SIP proxies to exchange up to 270 duplicate
2
Est
imat
edatt
ack
traffi
c(G
bp
s)
167
300
100
400
54
1998 2001 2004 2007 2013 Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 Feb Mar Oct
Aus
CE
RT
war
nsab
out
DN
S
base
dam
plifi
cation
atta
cks
DN
Sis
regu
larly
used
in
ampl
ifica
tion
atta
cks
Vau
ghn
and
Evr
onpr
esen
tD
NS
Am
plifi
cation
Att
acks
atD
EFC
ON
14
SNM
Pat
tack
atM
ITan
d
Pro
lexi
cre
port
sa
167G
bps
DN
Sat
tack
100G
bps
DN
Sat
tack
agai
nst
Gre
enN
et
300G
bps
DN
Sat
tack
agai
nst
Spam
Hau
s
DE
RP
clai
ms
resp
onsibi
lity
for
man
y
atta
cks
agai
nst
the
gam
ing
indu
stry
Clo
udFla
rere
port
sa
400G
bps
NT
Pat
tack
Aka
mai
repo
rts
a54
Gbp
s
SSD
Pat
tack
Fig. 1. Timeline of amplification attacks and related events.
requests consuming their resources and preventing themfrom responding to legitimate requests [34].
B. Responding to a Growing Threat
Akamai detected 9 DoS attacks involving NTP, Char-Gen, and SSDP which peaked over 100 Gbps in the last3 months of 2014. This is three times more than in thesame period in 2013 [33].
Figure 1 and Table I illustrate that the bandwidth usedin amplification attacks is also growing. In March 2013an amplification attack was launched against Spamhaus[5]. The DNS based attack reached an estimated peakof about 300Gbps and was the biggest DoS attack everrecorded [35]. Nearly a year later and an even biggerattack reportedly reached a peak of 400Gbps by usingNTP [17].
The attack traffic generated during the Spamhausattack came from over 30,000 different DNS servers.In order to guard against this and future attacks, theydeployed anycast routing and a distributed ContentDelivery Network (CDN) [5]. Anycast involves BGProuters simultaneously advertising the same destinationIP address so that attack traffic can be absorbed bymany different data centers. However, relying on anycastand CDNs may be a short term solution, and it canonly prevent amplification attacks when amplifiers andanycast routes are evenly distributed around the Internet.
The CloudFlare attack came 1 month after a warningabout monlist issued by US-CERT [32], and during a13-week period in which Kuhrer et al. reported a 92%drop in the number of vulnerable NTP servers [11].As a consequence we may need to reevaluate how werespond to threats as they are discovered. The worry isthat current methods of alerting system administrators tovulnerable protocols are actually prompting attackers toinitiate attacks.
C. Problem Description
In this section we will provide high level descriptionsof the attacks and concepts seen so far. We will start bydiscussing the amplification factor of different attacksand go on to describe the building blocks of the mostcommon amplification attacks.
1) Amplification Factor: The amplification factor ofan attack (X(P )) for a protocol (P ) is the ratio of thetotal number of bytes in the amplified traffic and thebytes sent by the attacker as shown in Equation 1.
X(P ) =number of response bytes(P )
number of request bytes(P )(1)
The wording used for X(P ) in Equation 1 is differentfrom the one used in [20] because payload can differbetween responses for a single protocol. Nevertheless itis useful to look at the amplification factors provided byRossow [20] because they offer us a convenient way ofcomparing protocols and looking at which to prioritize.For example, Rossow found that NTP had the highestamplification factor all of the protocols he tested. Hefound that if attacks carefully select the NTP servers tomaximize their attack they can achieve an amplificationfactor of 4670, which when compared to 64 for openDNS resolvers shows us how urgent it is to updateexisting NTP infrastructure.
2) Reflection: Many of the amplification attacks inthe past were possible because the attacker can spoofthe address of the victim causing traffic to be “reflected”by third-party servers, e.g., by open DNS resolvers [36](see Section II-A). Figure 2 shows a reflection attackwhere an attacker (M ) changes the source address inthe request it sends to the reflector (R). With no way ofknowing that source address was spoofed, the reflectorthen forwards its response to the final destination (D).
The key advantages of reflection attacks for the at-tacker are: (a) attackers are able to hide their identityfrom D because all traffic received by D comes from
3
Reference Year Amplification Protocol Peak Traffic Attacker Description
MIT [31] 2013 SNMP Unknown Unknown
Spoofed requests were directed toSNMP enabled devices on the MIT net-work which attacked devices outsidethe network.
GreenNet [2] 2013 DNS 100 Gbps Unknown
Attackers brought down GreenNet, ahosting company who’s customers in-cluding Privacy International and Zim-babwe Human Rights Forum.
Prolexic [3] 2013 DNS 167Gbps Unknown The attack targeted a real-time financialexchange platform.
Spamhaus [5] 2013 DNS 300Gbps Cyberbunk
Over 30,000 DNS servers were in-volved in the amplification attack. At-tackers also used SYN floods and pre-fix hijacking to disrupt the Internetconnectivity of Spamhaus and ProjectHoneypot.
PhantomL0rd [4] 2013 NTP 100GbpsA hacker group namedDERP claimed respon-sibility on Twitter.
Attackers targeted game servers andstreaming sites. Attacks against thegames industry are becoming increas-ingly popular [33].
CloudFlare [17] 2014 NTP 400Gbps Unknown
Latency increased all over Europe fol-lowing attack using 4,529 NTP servers.French hosting firm OVH also claimedto have seen an attack over 350Gbps atthe same time.
Akamai [30] 2014 SSDP 54Gbps Unknown Many of the devices used in this attackwere home-based UPnP devices.
TABLE IRECENT LARGE SCALE AMPLIFICATION ATTACKS AND THEIR PROPERTIES
third-parties; (b) attackers can trigger attacks comingfrom different geographic or topological regions of theInternet; and (c) attackers do not receive responses andtherefore do not risk using up their available downloadbandwidth.
R
M D
Request Response
Fig. 2. Reflection attack. An attacker (M ) sends a spoofed requestto a reflector (R) which responds to the final destination (D).
The common amplification attack pattern seen in Sec-tion II-A targets the final destination as the victim. For
example, in some SYN/ACK attacks, an attacker sendsspoofed SYN requests to a reflector so that the reflectorsends SYN/ACK packets to the victim [23].
As well as the final destination as indicated by thespoofed source IP address, it is also possible for reflec-tors, uplinks, and other end-hosts which rely on themto be victims of reflection attacks. In SYN floodingattacks [21], [37]–[41], the attacker floods a reflectorwith spoofed SYN requests and changes the source IPaddress of packets so they do not receive replies. Theaim of SYN flooding attacks is not to attack the finaldestination indicated by the spoofed IP address, but toconsume enough resources at the reflector to make itunresponsive to legitimate traffic. The adversary canalso attack multi-homed networks using reflectors. Forexample, if the reflector is connected to the Internet by atleast two uplinks, and the link between the reflector andthe final destination offers significantly lower bandwidthcompared to the link between the attacker and reflector.Then by carefully selecting a spoofed source address
4
which is reachable via the low bandwidth connection,the attacker can implement a DoS attack on this link.
It is worth mentioning again, however, that not allof the amplification attacks described in this paper usereflection, e.g., fork loop based attacks do not [8].
3) Amplification: A key factor in amplification at-tacks is the ability of attackers to initiate responseswhich are many times larger than the requests. Figure 3illustrates the basic scenario where an attacker sendsa request to an amplifier (A) which responds with ahigher volume of data than it receives. In this scenariothe amplifier, and the network between the attackerand the amplifier, are the victim because they cannotcope with the amplified traffic. Figure 3 can be used todescribe attacks against mobile devices which typicallyhave lower upload than download bandwidth, or attackswhere attackers can change their IP address often anddo not receive the returning amplified traffic. The mainadvantage of such an attack is resource saving for theadversary.
M A
Request
Response
Fig. 3. Simple amplification attack. An attacker (M ) sends a requestto an amplifier (A) which responds with more data than it received.
4) Reflection and Amplification Together: All of theamplification attacks seen in Table I combine reflectionand amplification, and can be described using Figure 4.In this model an attacker (M ) sends requests using theamplification protocol (P ) to the amplifiers (A) but alsouses reflection so that the amplifiers respond to the victim(V ).
The volume of attack traffic which can be sent toV will depend on the available bandwidth between Mand A, the available bandwidth between A and V , thenumber of amplifiers used, and the amplification factorof P . Depending on the success of the attack the volumeof traffic sent to the victim can be devastating, andcan result in a complete loss of connectivity for thevictim and their network. However, there are also anumber of bottlenecks in this attack model. For example,attackers may not have sufficient uplink bandwidth to
A1M
A2
A3
V
Request
Request
Request
Response
Response
Response
1) Attacker sendssmall requests toamplifiers usingthe source IPaddress of V.
2) Amplifiers sendlarge and/or manyresponses to Vsaturating itsbandwidth.
Fig. 4. The model used in the more devastating amplification attacksseen so far. An attacker (M ) simultaneously sends spoofed requeststo many amplifiers (A) causing amplified responses to be sent to thevictim (V ).
send requests to many amplifiers. For this reason manylarge scale amplification attacks are perpetrated usingbotnets; which are made up of slave hosts which sendrequests to many amplifiers at the same time [9].
Fraggle and Smurf also use reflection and amplifica-tion, but their attacks look slightly different from themodel in Figure 4. Figure 5 shows a Smurf attack whereM sends a request to the broadcast address of network(N ), A acts as the amplifier by duplicating the request,and the reflectors (R) send responses to the victim V .Fraggle attacks are similar to Smurf attacks but therequests are amplified even further by the end hosts thatreceive them.
Network N
M A R2
R1
R3
VRequest Request
Request
Request
Response
Response
Response
1) M sends a singlerequest to the broadcastaddress of network N.
2) A acts an emplifierby broadcasting therequest to R1, R2, and R3.
3) The reflectorssend responses tothe victim.
Fig. 5. Smurf attack. An attacker (M ) sends a spoofed request tothe broadcast address of network (N ). The amplifier (A) broadcaststhe request to many reflectors (R) which respond to the victim (V ).
The major advantages from an attackers point of viewof using the attacks described in Figure 4 and Figure 5
5
are:
• Attack traffic can be amplified far beyond the at-tackers upload bandwidth.
• The attacker remains anonymous by using reflection(IP address spoofing).
• The volume of attack traffic at single reflectors andamplifiers can be very difficult to distinguish fromlegitimate traffic.
• This “force over technique” [33] exploits vulner-abilities in the Internet and doesn’t require theattacker to compromise systems with malware priorto the attack.
5) Fork Loops: Fork loops are different to the reflec-tion and amplification attacks we’ve just described [8].Yet fork loops have also been referred to as amplificationattacks because they provide a way for an attacker toamplify the number of requests they send to SIP proxies.
Figure 6 shows one example of what can happenwhen two SIP proxies (L1 and L2) are not configuredcorrectly and do not perform loop-detection. It depictsthe scenario described in [34] where a request for theuser a@L1 is sent to the proxy L1. In this exampleL1 has two options for reaching a@L1 which are bothlocated at L2. This causes L1 to fork the request andsend two copies to a@L2 and b@L2 which also bothfork the request to a@L1 and b@L1. The scenario iscaused by misconfiguration and can potentially result in2n duplicate requests created where n is the number ofiterations.
a@L1
a@L2
a@L1
a@L2
......
b@L2
......
b@L1
a@L2
......
b@L2
......
b@L2
a@L1
a@L2
......
b@L2
......
b@L1
a@L2
......
b@L2
......
Fig. 6. Fork Loops. In this example taken from [34] a single requestspawns 2n duplicates where n is the number of iterations.
III. AMPLIFICATION ATTACK PREVENTION
Now we have analyzed amplification attacks in Sec-tion II, we can now discuss ways in which they canbe prevented. In this section we will present techniqueswhich could stop or make amplification attacks moredifficult for the attacker.
A. Alternative Internet Architectures
Moving to an alternative Internet architectures suchas Content-Centric Networking (CCN) [42] may removemany existing DoS attacks. Specifically, CCN will re-move the possibility of DNS based amplification attackssimply because DNS is no longer required. In CCN, ISPscan deploy content routers to cache data which manyusers request. However, CCN uses the request/responseparadigm in the form of “Interest” and “Data” packets,and it is currently unknown how resilient these newnetwork paradigms would be to amplification attacks ornew forms of DoS attacks.
B. Lowering Amplification Factors
One approach which would reduce the efficiency ofamplification attacks on the current Internet is to increasethe size of requests in vulnerable protocols. This wouldreduce the amplification factor but the increase in trafficacross the Internet would not be desirable. Moreover, itis not reasonable to suggest that all protocols should beamplification free. For example, it is quite reasonable toexpect that request packets for large files are smaller orfewer than the response.
A more practical approach for lowering the ampli-fication factors may be to disable the redundant ser-vices that amplifiers offer. For example, Rossow showedthat the Network Time Protocol (NTP) has the highestamplification factor out of the 14 UDP protocols hetested [20]. Whilst Kuhrer et al. achieved a reductionof the amplification factor of NTP by disabling the NTPservices with the highest request/response factors [11].Since the services with the highest request/responsefactors do not affect the core capabilities of NTP, theseextra services can be disabled whilst still enabling timesynchronization.
As well as NTP, there are many other protocols (e.g.DNS, CharGen, SNMP) that can be used for amplifica-tion attacks. Some DNS providers have recently starteddeprecating the DNS ANY request in response to thegrowing threat of amplification attacks. One provider,CloudFlare, now responds with the RCODE 4 “NotImplemented” 1. However, identifying and disabling
1https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/
6
services with high request/response factors takes time,and may result in the loss of functionality which someapplications rely on.
C. Reducing the Number of Amplifiers
Many amplifiers were used in the larger amplificationattacks. For example, over 30,000 separate open DNSresolvers were used in the Spamhaus attack (See Table I).A number of projects listed in Section VI are attemptingto bring misconfigured amplifiers to the attention ofsystem administrators so that they can be patched orconfigured correctly. However, this relies on widespreadcooperation between administrators who may not havethe knowledge or the resources to update their servers.
Another interesting point to make here is does theInternet need so many amplifiers, e.g., DNS servers?Perhaps more cooperation between network providerscan lower the impact of amplification attacks by loweringthe number of amplifiers required to operate the Internet.
D. Response Rate Limiting
In addition to patches that lower the amplificationfactor, amplifiers could be configured to respond to alimited number of request from each IP or networkaddress within a given time frame. For example, supportfor response rate limiting is easily applied to DNS whenusing newer versions of BIND. However, rate responserate limiting protects against abuse of a single amplifierand an attacker may simply choose to use multipleamplifiers at a low request rate. It only takes an attackera short amount of time to look for a sufficient number ofdifferent amplifiers (less than a minute in some case [20]).
E. Model Checking
Model checking can also be used to reveal protocolswhich suffer from amplification attacks due to miscon-figuration or bad design [8]. By modeling the protocolusing rewriting logic [43], a set of system states canbe generated and checked for amplification by compar-ing the cost of servicing requests against a predefinedthreshold 2. This approach can be used to detect flawsin protocols where the amplification factor at a singlepoint might not seem significantly high, and it has beenused to describe forking loops in SIP [8].
However, the model checking as used in [8] relies ona breadth first search in a graph of system states to lookfor signs of amplification. This offers many challenges,
2The cost in [8] is the number of duplicate packets generated bySIP proxies
the most difficult of which may be that it requires a lotof time and space to construct the graph of states forlarger and more complex systems.
F. Sessions for UDPMany amplification attacks rely on stateless commu-
nication via the UDP protocol in order to send largeamounts of data to spoofed IP addresses. Those am-plification attacks are made more difficult if all UDPprotocols required sessions to be opened (similar tothe TCP three-way handshake) before large amounts ofresponse data can be transmitted.
It is possible to include session information in UDPpackets. For example, clients using the Steam queryprotocol have to request a 4-byte challenge before theycan request large amounts of information about a gameserver [44]. The client simply has to append the chal-lenge response to future requests. However, attackerscan still use session hardened services for amplificationattacks so long as they can open new sessions forthe same victim with many amplifiers, and can alsoeavesdrop on the victims Internet traffic to see responsesin plain text.
Another downside to session hardening UDP protocolsis that it increases the packet sizes and the number ofpackets sent, which conflicts in particular with mobileregimes. It may also add latency to the requests, butin some cases latency may only be added to the firstrequest because sessions can be opened pro-activelyor kept alive if the protocol is used often. The mostchallenging aspect of session hardening existing UDPbased services is compatibility with existing clients. Inorder to prevent amplification attacks session supportwould have to be universal, and upgrading may causeproblems with legacy systems.
G. Filtering Spoofed PacketsIn most amplification attacks the attacker sends re-
quests with the spoofed IP address of the victim. Fil-tering spoofed packets is considered one of the mosteffective countermeasures against amplification and otherDoS attacks [11], [45]–[47]. However, in 2005 the MITANA Spoofer Project showed that around 25% of ASesallowed spoofed IP packets to be sent out of their net-work, and the ability of attackers to launch amplificationattacks shows that it is still a problem today. Recentestimates state that it is still possible to send spoofed IPpackets from about 20% of the Internet [45].
The next section will discuss spoofing in more detailand discuss some of the methods proposed to defendagainst it.
7
Survey Name Papers Covered
Detecting Spoofed Packets [58] [59]–[61]
IP Spoofing Defense: An Intro-duction [52]
[62]–[77]
On the State of IP Spoofing De-fense [53]
[58], [62], [64], [65], [70],[71], [74], [75], [78]–[95]
DDoS: Survey of TracebackMethods [55]
[60], [65], [79], [96]–[106]
A Survey of IP TracebackMechanisms to OvercomeDenial-of-service Attacks [56]
[99], [102], [107]–[110]
A Survey on Packet Markingand Logging [57]
[79], [99], [100], [102],[104], [107], [109]–[117]
On IP Traceback [54] [21], [59], [93], [96]–[100],[102], [118], [119]
TABLE IISURVEY PAPERS FOR FILTERING SPOOFED IP PACKETS AND
DETECTING ATTACKERS.
IV. SOURCE IP ADDRESS SPOOFING
Many of the amplification attacks which are currentlyvisible involve the attacker tricking amplifiers into send-ing large amounts of data to victims (see Section II-A).To do this the attacker changes the source address onIP packets before sending them. UDP has no builtin mechanism of determining if the source IP addressis spoofed, so amplifiers reply to the spoofed addressinstead of the original sender.
This technique is called source IP address spoofing(we will refer to it here simply as spoofing for conve-nience) and it is commonly used in DoS attacks insteadof more complex address hijacking techniques [48],[49]. Using spoofing for malicious purposes was firstdiscussed in 1989 [16], and a detailed analyses of theproblem was carried out by Heberlein and Bishop in1996 [50] and Dunigan in 2001 [51]. Since then therehave been many other surveys related to spoofing whichwe have summarized in Table II. These surveys canbe broadly categorized as either focusing on filteringspoofed packets [52], [53], or tracing the attacker [54]–[57].
In this section we will (a) survey the contributionslisted in Table II in a single concise discussion and(b) significantly extend the discussion by including newapproaches. We will start by discussing the techniquesused to monitor spoofing and to map networks which donot guard against it.
A. Monitor Spoofing In The WildThere are two techniques which are being used to look
at spoofing on the Internet. Active monitoring attemptsto send spoofed packets and monitor the replies. Whilstpassive monitoring requires analyses of Internet traffic,e.g, NetFlow data. In the following two subsections weexamples of both approaches.
1) Active Monitoring: The MIT Spoofer Project [45]measures how susceptible the Internet is to IP spoof-ing. To achieve a high coverage they have created anddistributed an application which volunteers can install.Their application sends several spoofed UDP packetsto a server controlled by the project. The applicationthen connects to the server using legitimate means todetermine which packets were received or lost. Theresults of the MIT Spoofer Project have shown that about25% of ASs are currently vulnerable to IP spoofing.Daily statistics are also available on their website [120].
Penetration testing can also be used to test howsusceptible a network is to spoofing. This can be doneinternally by network administrators to test they haveconfigured border routers correctly. Software such asScapy [121] can be used to modify the source address onan IP packet, alternatively it is possible to construct andsend spoofed packets using high level languages such asC [26].
Kuhrer et al. [11] test open DNS resolvers to seeif ASs allow IP spoofing. The disadvantage of theirapproach is that it relies on networks which have openDNS resolvers that do not change the source IP addresson responses. However, their approach does not dependon the distribution of volunteers like the Spoofer Project,and the researchers were largely free to choose whichnetworks to investigate due to the many available openDNS resolvers.
2) Passive Monitoring: We know of many ASs thatallow spoofing because of the Spoofer Project and thework done by Kuhrer et al. The next question is howmuch Internet traffic is actually being spoofed. TheUCSD Network Telescope from CAIDA [46] is attempt-ing to answer this question by monitoring traffic whichis sent to darknets. A darknet is an address-space whichis routable but where no traffic is expected to be sent,i.e., the addresses are not allocated. Monitoring trafficto darknets can be used to spot attacks, scans of theInternet, and misconfiguration of machines.
To explain how a darknet can be used to detect spoofedpackets we will briefly describe the steps of a TCP-SYN flooding attack [122]. When an attacker is usingspoofing for a TCP-SYN flooding attack and randomly
8
chooses a source address for the spoofed packets, thereis a chance that the address is in the address-space ofthe darknet. As a consequence, the victim of the attackwill response to the spoofed addresses, and the ACK-SYN packets from the victim will appear as traffic tothe darknet. These ACK-SYN packets are known asbackscatter, and since the darknets are supposed to causeno traffic, backscatter is assumed to be the result ofspoofing once misconfiguration has been ruled out.
B. Filtering Spoofed Packets Using Authentication
There is no built in mechanism in the Internet Protocolwhich can prevent spoofing. Its function is simply toprovide best effort delivery of datagrams [123] and it isnot possible to prevent spoofing completely. Neverthe-less, over the next two sections we will discuss varioustechniques which can be used to filter spoofed packets.In this section we will concentrate on methods whichuse some form of authentication to validate packets.
1) Session Tokens: There are many methods whichaim to validate packets using session tokens whichare unique between two parties, and may have a timelimit associated with them [64], [73], [86], [92], [124],[125]. Some of these papers use different terminologyto refer to the session tokens. Some papers use theword “cookie” [86], [87], [126], whilst others use theword “key” [64], [127]. To avoid confusion we willalways refer to them as session tokens. Whilst the basicprinciple of using session tokens to authenticate packetsis the same these proposals have their own strengths andweaknesses. For example, large session tokens sent byservers may also be used in amplification attacks [87].
One approach which was specifically designed toguard against amplification attacks is to include a sessiontoken in all requests sent to amplifiers [126]. This re-quires that the first time a request is received from a newaddress, the amplifier replies with a unique session tokenwhich the sender should include in all future requeststo the amplifier. Including the same session token inall requests has low processing overheads but adds tothe size of each packet. Furthermore, it is prone toeavesdropping if session tokens are not encrypted. If theattacker can eavesdrop on the victims Internet traffic thenthey can also agree new session tokens with amplifiersthe victim has not yet contacted.
The Source Address Validation Architecture with HostIdentity Protocol (SAVAH) [127] can filter spoofed pack-ets at the edge of local networks. It requires that allend-hosts and gateway routers support the Host IdentityProtocol (HIP) [128], [129]. SAVAH filters spoofed
packets by requiring senders to replace the source IPaddress of packets with a hash. The hash is createdusing the contents of each packet and a session tokenagreed previously when the sender joined the network.This is cryptographically stronger than [126] so long asthe session token was exchange securely. However, thisapproach degrades performance of the network rapidlydue to the processing overheads of hashing every packet.
2) Encryption: A more secure approach than usingsession tokens is to encrypt packets, including the net-work layer. Using encryption between end-hosts wouldnot only prevent most spoofing attacks, but it also hasthe added benefit of all Internet traffic being secureby default [83]. One suitable mechanism by Gilad andHerzberg provides lightweight encrypted communicationthat also prevents spoofing packets [41].
However, currently the computational overheads andextra traffic caused by encrypting all IP traffic is im-practical. Those approaches would conflict with IoTscenarios including constrained devices, for examples.Nevertheless, encryption can be used in select cases suchas communication with amplifiers.
3) Third-party Authentication: Many of the filteringmethods described so far allow end-points to negotiate asession token or encryption key so they can authenticatepackets. However, sometimes this is not desirable be-cause of the additional processing and latency overheads.
Using third-parties offers a way of authenticatingpackets which can potentially lower the extra processingdemands placed on routers and end-points [39], [130]–[132]. For example, Gonzalez et al. [131] proposedthat routers should send copies of packets to a “judge”(the trusted third-party). The judge should know the IPaddresses serviced by the routers, and the judge can alsoquery routers in the absence of data.
Noureldien et al. [39], [132] suggested that authenti-cation servers in local networks can be used to determineif TCP-SYN packets are spoofed. They propose thatall packets that exit a network are inspected by anauthentication server. An authentication server can alsocheck incoming packets with the authentication server atthe source network. This approach can lower processingoverheads for some hosts in the network but it doesnot address concerns about additional latency and trafficvolume.
C. Filtering Spoofed Packets Based on Network Topol-ogy
Almost all of the filtering methods seen so far comewith a high cost in terms of additional latency, traffic
9
volume, and/or processing at routers. In this section wewill discuss methods which can lower the overheadsby using what information is already known about theInternet. For example, some IP addresses are not meantto be used outside of local networks. If a packet entersa network with a private IP address (e.g. 192.168.1.1)then it doesn’t make sense to route this packet internally.In this case Network Address Translation (NAT) [133]at the source network should have changed the sourceaddress of the packet and this may be a sign of spoofingor misconfiguration.
Some of the more complicated methods of detectingspoofed packets that will be discussed in this sectionare probabilistic because the Internet is both dynamicand complex. However, some of these approaches alsoinclude a mechanism to determine if a packet wasactually spoofed following detection.
1) Using IP Headers: One way with which spoofedpackets can be filtered without using additional band-width is to use the information present in the IP headers.For example, packets can be filtered if their hop countdoes not match what is known about the topology of up-stream routers. This information can be estimated usingthe Time To Live (TTL) field in the IP header [74], [88].It is even possible to filter spoofed packets by detectingwhat operating system a remote host is using [80], [82]However, these methods do not guard against attackswhere the attacker can manipulate the TTL or othervalues in the IP headers.
2) Ingress and Egress filtering: Filtering IP packetswith spoofed addresses can be achieved using knowledgeof the IP addresses allocated by the upstream or down-stream networks [62], [89], [134]. Ingress filtering filtersincoming packets. In contrast, egress filtering filterspackets which are exiting the network.
Ingress filtering (BCP 38) is sometimes implementedat the periphery of the Internet to stop packets withspoofed addresses being routed by edge routers [62].However, network operators can not always be trusted toimplement BCP 38. Ingress Access Lists are also typi-cally maintained manually, and having outdated or mis-configured lists can prevent legitimate or allow spoofedtraffic [91].
3) Learning Directions: Routers can record informa-tion from incoming packets in order to filter traffic whichcomes from unexpected directions [63], [67]–[69], [78],[95]. The Source Address Validity Enforcement (SAVE)protocol [93] is one example where routers can learnthe expected incoming interface for a source addressin order to authenticate subsequent packets. However,
these methods do not perform well during legitimatechanges to the Internet’s structure or when there aremultiple paths between two routers [63]. To counter thisproblem these methods consider multiple valid interfacesper source address at the cost of lower filtering accuracy.
4) Using BGP and Routing Tables: BGP is responsi-ble exchanging routing information between ASs. Manypapers have proposed that BGP can also be used to helpfilter spoofed packets [65], [66], [94], e.g., by addinganti-spoofing information to BGP update messages [70].
One way to use BGP routing tables to filterspoofed packets is to use Distributed Packet Filtering(DPF) [65], and its extensions Inter-Domain Packet Fil-ters (IDPF) [66], [94] and Extended IDPF [125]. UsingIDPF a router examines BGP routing tables to check ifit is on the optimal path between the packet’s sourceand destination. However, this approach suffers fromthe same security flaws as BGP [135]. To improve thesecurity of BGP and thus IDPF, Dawakhar et al. havesuggested using Credible BGP [136].
D. Tracing the Attacker
We have seen many approaches for detecting andfiltering spoofed packets. A different challenge is to tracethe packets back to their original source [54]. Tracingspoofed packets is difficult because of limited accessto external routers and the the high overheads involved.Traceback methods are also different depending on theirobjective and where they are to be implemented. Forexample, an administrator of a local network might wantto know which MAC address or interface is being usedto send spoofed packets by using ARP cache poisoningor ARP spoofing attacks [137]. Where as the victim ofan attack coming from an external network might wantto know which network the attack originated from.
1) IPSec and DECIDUOUS: IPSec [138]–[140] isused to trace the network from where a spoofed packetoriginated in DECIDUOUS [59]. Once an attack involv-ing spoofing has been detected by DECIDUOUS, thevictim creates secure tunnels between itself and upstreamrouters until it finds the network from where the attackis coming from. However, DECIDUOUS needs to havea complete overview of the network topology in orderto choose routers with which to tunnel. Furthermore,DECIDUOUS has high processing and traffic overheadscaused by setting up and tearing down secure tunnelsduring an attack.
2) Using Traffic Logs: Tracing spoofed packets backto the attacker can be also be done by analyzing datacollected by routers [102], [110], [141]. The biggest
10
advantage of log-based traceback is the potential to tracea single packet [142]. However, these methods oftenrequire that traffic data is either collected or stored byrouters [96]. This comes with many practical difficultiessuch as additional hardware costs, as was the case withthe original proposal by Snoeren et al. [102] whichrequires Source Path Isolation Engine (SPIE) routersin place of existing routers. One solution to replacingexisting routers is to use Tap Boxes which eavesdrop onincoming and outgoing traffic [143]. It is also possible tolower the amount of storage required to trace attackers byusing hashes [110]. Nevertheless, it is desirable to keepthe complexity of routers and cost of additional hardwareto a minimum so many traceback proposals focus on“marking” packets with additional data instead [60].
3) Packet Marking: The idea of packet markingis to record the path which packets follow into thepackets themselves [60]. Some other early packet mark-ing schemes appended the IP addresses of routers intopackets [60], [108]. However, the 4-bytes needed torepresent a single IPv4 address and the large number ofhops quickly adds to the size of packets. Song and Perrigsuggested reducing the amount of space required byencoding addresses using hashing and a map of upstreamrouters [100]. Yaar et al. also discussed a number of waysto lower the space needed by using shorter identifiersthan IP addresses [71]. However, appending data unnec-essarily to packets is still undesirable because it increasesfragmentation. To address this problem some packetmarking schemes also suggested overloading IP headerfields [60], [75], [77], [79], [100] and only encoding theaddresses of edge routers [76].
Savage et al. also introduced Probabilistic PacketMarking (PPM) in order to reduce size and processingoverheads of packet marking even further [60]. PPM canbe used to identify network path(s) traversed during anattack so long as the victim receives sufficient markedpackets. However, PPM has a number of trade-offs.Adler [81] noted that there is a trade-off between thenumber of bits allocated to PPM and the number of pack-ets that must be received by the victim. PPM is also lesseffective against multiple attack sources [116]. WhilstSong and Perrig looked at the security of markings andproposed using time-released key chains to authenticatethem [100].
Li et al. [19] proposed an efficient packet markingscheme specifically for reflection attacks called Authen-ticated Deterministic Packet Marking (ADPM), whichis an extension of the approach proposed by Belenkyet al. [144]. It assumes that all routers are capable of
matching request and response packets and that routersadjacent to reflectors cooperate to copy packet markingsfrom the request packets to the replies.
Dean et al. approached packet marking in an entirelydifferent way and phrased it as a polynomial reconstruc-tion problem [79]. Chen and Lee extended their work totarget reflection attacks [145]. They did this by requiringreflectors copy packet markings from the request packetsto the replies. This enables the victim to trace paths tothe attacker using less than 4,100 packets, but it maybe possible to combine logging at routers and PPMto achieve traceback with a smaller number of markedpackets [109]
4) ICMP Traceback: Bellovin et al. proposed iTracewhere routers send ICMP messages to the destinationaddress of packets they forward [98]. ICMP tracebackcan also be probabilistic in that the chance of a routergenerating an ICMP message is small, thus loweringoverheads in a similar way to PPM [118], [146], [147].
Mankin et al. improved iTrace with “intention-driven”traceback after they noticed that the chance of a routerpicking an attack packet close to the attacker is muchsmaller than closer to the victim for certain DoS at-tacks [118]. Wang and Schulzrinne also proposed a newICMP message which can be used in ICMP tracebackfor reflection attacks [148].
5) Link Testing: Link testing is the systematic testingof intermediary links between routers, and can be donein several ways. For example, input debugging [96], andcontrolled flooding [97].
Input debugging attempts to determine from whichupstream router the attack traffic is coming from byrecursively generating attack signatures to distinguishmalicious packets from normal traffic. However, attacksignatures that only match malicious traffic are diffi-cult to create. A good attack signature is one whichmatches attack traffic and a small amount of legitimatetraffic [96].
The Intruder Detection and Isolation Protocol(IDIP) [61] describes an architecture which can beused for link testing and attack mitigation and sharessome similarities with input debugging. In IDIP a singleDiscovery Coordinator sends trace messages to otherIDIP enabled devices. The trace messages contain a de-scription of the event, i.e., an attack signature, using theCommon Intrusion Specification Language (CISL) [149].IDIP devices which receive trace messages reply withreport packets. The Discovery Coordinator can thendecide what action to take, including instructing otherIDIP devices to block attack traffic for a short amount
11
of time [61].Controlled Flooding is a method for detecting the
attackers network which floods each upstream routerwith packets. This technique needs the knowledge of thetopology of the Internet. Thus, a map of the Internet isobtained before link testing [97]. The purpose of floodingupstreaming routers is to determine if the attack trafficaffected. If the attack traffic is disturbed significantlywhen sending traffic to a router then it is assumed thatthis particular router is one forwarding attack traffic.
E. Discussion
In this section we have focused on practical ap-proaches to countering spoofing. However, there is alsomore theoretical work in this area. Given a graph of thenetwork topology and a set of firewall rules for eachnode, Santiraveewan and Permpoontanalarp proposed amethodology which can check to see if spoofing ispossible [150].
With all of the proposals seen in this section it maybe confusing as to why spoofing is still a problem.There are many practical and economic reasons of this.Many of the proposals have extra latency, traffic volume,computation, and/or storage overheads. Some are alsoexpensive to implement as they require new hardware orstaff to maintain them. It is also not often understoodhow well the methods will perform with only limiteddeployment [65], and what rewards they offer to earlyadopters [70].
We have also categorized the proposals discussed inthis section in Table III as being either active or pas-sive [58]. Active methods involve some sort of additionalnetwork traffic, e.g., an ICMP message sent to the sourceaddress, or extra markings added to packets. Whilstpassive methods tend to observe network traffic andmake probabilistic decisions.
It is also interesting to note that there are currently noautomated methods to trace attackers without sendingsome sort of additional information through the Inter-net. 3
We have seen that it is not possible to preventspoofing. Moreover, not all of the amplification attacksdescribed in Section II actually use spoofing. Therefore,we have to look for other ways of detecting and mitigat-ing amplification attacks as soon as possible. The nextsection will address this topic in more detail.
3It is possible to obtain traffic logs by physically going to suspectrouters, but this is impractical so we have chosen not to class methodswhich analyze data from multiple routers as passive.
Active Methods Passive Methods
Filtering [39], [63]–[70], [73],[75], [78], [82], [83],[86], [92]–[95], [124]–[127], [130], [132],[151], [152]
[37], [38], [72], [74],[88]
Monitoring [11], [45], [120] [46]
Traceback [40], [60], [71],[76], [77], [79], [81],[96]–[104], [104]–[118], [131], [141],[142], [144]–[148],[153]–[164]
TABLE IIIMETHODS FOR FILTERING SPOOFED PACKETS AND MONITORINGSPOOFING CAN BE CATEGORIZED AS BEING ACTIVE OR PASSIVE.
IT IS CURRENTLY UNKNOWN IF ITS POSSIBLE TO TRACEATTACKERS USING PASSIVE TECHNIQUES.
V. DETECTING AMPLIFICATION ATTACKS
Defending against any kind of DoS attack involvesattack detection and packet filtering [21]. We can adoptthe methods described previously in Section IV to detectand filter the spoofed packets used in many amplificationattacks. However, if we want to defend against ampli-fication attacks specifically we have to take a numberof things into consideration, such as the size differencebetween request and response packets and the rate atwhich packets are received. This section will discuss themethods summarized in Table IV which can be usedto detect ongoing or future amplification attacks, and tofilter packets once attacks have been discovered.
A. Detecting Ongoing Attacks
In 2002 Chang [21] explained that detection of DoSattacks can be performed at four locations between theattacker and victim: (i) the victim’s network, (ii) the vic-tim’s ISP network, (iii) further upstream networks, and(iv) attack source networks. However, since then moremethods have been proposed which attempt to detectamplification attacks at the victim’s host machine [7],[166], or by analyzing vast amounts of data from multi-ple networks at the same time [20], [22]. Therefore, wehave have split amplification attack detection methodsinto the following four different categories: (i) detectionat victims, (ii) detection at individual routers, (iii) mea-suring traffic flows using data from multiple routers, and(iv) detection at amplifiers.
1) Detection At The Victim: Possibly the easiestplace to detect amplification attacks is at the victim’s
12
Detection Method and References Description
Missing request packets [7], [165],[166]
These methods attempt to match incoming response packets with previously sent requests.
Traffic classification [12], [20], [22],[167]
Detecting anomalies in the numbers and size of packets can be used to detect amplificationattacks. This can be done at routers or by analyzing NetFlow data.
TCP connection state [168] This work was aimed at TCP based reflection attacks, but their collaborative approach toimprove the accuracy of detection may be applicable here.
Darknets [20], [169]–[171] Monitoring darknet traffic can detect random scans for amplifiers such as those seenbefore the Spamhaus attack [171].
Honeypots [20] Honeypots are a powerful way of detecting scans and amplification attacks but requirecareful configuration so that they do not cause harm to the victim.
TABLE IVMETHODS FOR DETECTING AMPLIFICATION ATTACKS AND SCANS FOR AMPLIFIERS.
machine. To this end, Kambourakis et al. [7], [166] pro-posed a DNS Amplification Attacks Detector (DAAD)which logs outgoing requests and incoming responsesin lookup tables. Responses are matched to outgoingrequests and erroneous responses flagged as suspicious.In this case the victim can also be a DNS server, andthe authors propose that the DAAD should also be ableto alter upstream firewall rules.
However, countermeasures at the victim’s machinemay be ineffective because its bandwidth may alreadyhave become saturated or the volume of traffic is toomuch for it to process. Therefore, it is much more com-mon to find proposals for detecting amplification attackswhich work by analyzing network traffic at routers oramplifiers.
2) Detection At individual Routers: Tsunoda etal. [172] proposed matching request and response pack-ets at a single point between the amplifier and thevictim, e.g., at the ISP border router. They later extendedtheir work with mathematical analysis and additionalexperimental results [165]. However, in order to correctlyidentify the responses for each request, the router needsto record the source and destination addresses, protocolfield, application headers, etc. for every single packet.
A potentially less expensive approach is to look fortraffic patterns which are out of the ordinary, or whichmatch known attack patterns. Yu et al. proposed usingcorrelation coefficients to detect DoS attacks. Theirmethod can also distinguish attacks from “flash crowds”which are unexpected bursts in legitimate traffic [173].Wei et al. [167] also used correlation to compare traffic tothat of known attacks. One advantage of using traffic cor-relation is that it is protocol independent. However, thesemethods can struggle to distinguish between attacks
using large botnets and legtimate flash crowds [173].Matching individual responses with requests at a sin-
gle point is problematic because of asymmetric routingand the fact that attacks can originate from multiplelocations across the Internet. This means that routers willneed to be near to the victim in order to detect an attack.However, routers near to the victim are susceptible toamplification attacks in the same way as the victimbecause of the increased load on their resources, so oncean attack has been detected it may be too late to defendagainst it.
3) Analysing Traffic From Multiple Routers: Byanalysing data collected by multiple routers it is possibleto do more sophisticated attack detection and mitigation.Huistra showed that amplification attacks can be detectedby monitoring DNS packet sizes as well as the number ofDNS packets across a wide area [22]. Huistra’s methodis split into two parts. The first (which can also be usedto detect attackers) focuses on detecting IP addressesgenerating a suspicious number of similar sized DNSrequests. Suspicion is based on thresholds calculatedusing real data from the GEANT network [22]. Thesecond part can be used to detect the victim, and looksat the number of large DNS packets sent to a single IPaddress.
Rossow’s analysis and detection of amplification at-tacks is similar to Huistra’s but is not limited to a singleprotocol [20]. Instead, he focused on 14 UDP protocolswhich allow amplification. By analyzing traffic samplestaken from a single ISP, Rossow was able to detect 15real life amplification attacks against multiple victims bycomparing sent and received bytes.
Based on the work by Rossow, Bottger et al. [12] de-veloped a more generic approach to detect amplification
13
attacks. They introduce the following detection criteria,which are independent of a specific network service: (i)similar packet size among all requests (and responses),(ii) similar payload among all requests (and responses),(iii) an increased amount of ICMP unreachable mes-sages, and (iv) incorrect TTL values. They found thatonly the first two criteria are stable enough to be used foramplification detection which may mean it is not worthexpanding on the approaches discussed in Section IV-C1to detect amplification attacks as well.
4) Detection At Reflectors/Amplifiers: Rossow andHuistra showed that it is possible to detect open DNSresolvers that have been abused in amplification attacksby analyzing data from an amplifiers perspective [20],[22].
The work of Peng et al. [168] focused on TCP basedreflection attacks but it used some interesting mechanicswhich might also improve the accuracy of amplificationattack detection at amplifiers. Their method monitoredthe cause of packets instead of just counting them. Intheir proposal reflectors monitor incoming TCP RSTpackets and monitor those which have a correspondingSYN/ACK state for the outgoing connection. This isa sign that the reflector was sent a SYN packet byan attacker and the reflector then sent a SYN/ACK tothe victim, at which point the victim has replied witha RST packet. Interestingly Peng et al. also suggestedthat collaboration between reflectors can be used toimprove the accuracy of attack detection. Once an attackhas been detected, their system sends a warning to allother participating reflectors instructing them to stop theattack.
Another way of detecting attacks is to setup honeypotswhich look like amplifiers to attackers. Honeypots aretraps set to detect malicious activity, e.g., an open DNSresolver which should not be found via any legitimatemeans. Honeypots can be used to log scanning activityand may also be used to detect ongoing attacks butshould ensure that they do not cause harm to the vic-tim [20].
B. Detecting Future Attacks
It is also possible to detect scans for amplifiers whichmay act as a warning for future attacks. For example,darknets (also known as blackholes) are unused IPaddress spaces on the Internet. Since the IP addressesin darknets are unallocated, any traffic to or from adarknet is a sign of either scanning, misconfiguration, ormalicious intent. Attackers have previously sent requeststo random IP addresses looking for amplifiers resulting in
TABLE VONGOING PROJECTS
Reference Description
Open ResolverScanningProject [174]
Aims to identify publicaly available recursiveDNS servers and alert system administrators.
Open NTPProject [175]
Searches the internet for NTP servers whichcan be used in an amplification attack.
Open DNSResolverProject [18]
Maintains a list of DNS servers that are knownto serve as globally accessible open resolvers.
MeasurementFactory [176]
Also maintains a list of open resolvers.
a lot of traffic sent to darknets [20], [169]–[171]. In onecase an attack was detected 14 minutes after a scan [20].
Fachkha et al. suggested that requests are sent todarknets during an attack in the hope of finding anamplifier [169]–[171]. However, if an attacker alreadyknows of enough amplifiers to make use of their avail-able bandwidth then it is unlikely the same attackerwill waste resources targeting unknown addresses duringan attack. The authors did notice some traffic duringthe Spamhaus attack (March 18th). However, that traffictargeted 50,257 separate IPs with 1 packet each [171]which is indicative of a scan rather than an attack.
VI. CONCLUSIONS
This paper discusses many proposals for detecting,preventing, and tracing the attacker in amplificationattacks. We have also presented a survey of proposalsfor defending against source IP address spoofing, whichis an essential part of almost all amplification attacks.
We have concluded that preventing source IP spoofingis the effective way of defending against amplificationattacks. However, it is not possible to prevent spoofingin IP and the methods to detect and fitler spoofed packetsare currently impractical or unlikely to be deployed ona large scale. Therefore, Section V deals with ways ofdetecting and mitigating amplification attacks.
More work needs to be done in order to close theattack vectors which are being used in amplificationattacks, e.g, open DNS resolvers, unpached NTP servers,and lack of ingress filtering. A number of ongoingprojects which aim to tackle these threats are summa-rized in Table V.
REFERENCES
[1] M. Handley, E. Rescorla, and IAB, “Internet Denial-of-Service Considerations,” RFC 4732 (Informational), Internet
14
Engineering Task Force, December 2006. [Online]. Available:http://www.ietf.org/rfc/rfc4732.txt
[2] T. Brewster, “Cyber Attacks Strike ZimbabweansAround Controversial Election,” August 2013. [On-line]. Available: http://www.techweekeurope.co.uk/workspace/zimbabwe-election-cyber-attacks-123938
[3] Prolexic, “Prolexic Stops Largest-Ever DNS ReflectionDDoS Attack ,” May 2013. [Online]. Available: http://www.tinyurl.com/prolexic-167gbit
[4] D. Takahashi, “Hackers Attack Dota 2 and Leagueof Legends Servers in Quest For One GameLivestreamer,” December 2013. [Online]. Available:http://tinyurl.com/PhantomL0rd-drdos
[5] I. M. Prince; CloudFlare, “The DDoS That AlmostBroke the Internet,” March 2013. [Online]. Available: http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet
[6] R. Vaughn and G. Evron, “DNS AmplificationAttacks,” March 2006. [Online]. Available: http://crt.io/DNS-Amplification-Attacks.pdf
[7] G. Kambourakis, T. Moschos, D. Geneiatakis, and S. Gritzalis,“A Fair Solution to DNS Amplification Attacks,” 2nd Inter-national Workshop on Digital Forensics and Incident Analysis(WDFIA 2007), pp. 38–47, 2007.
[8] R. Shankesi, M. AlTurki, R. Sasse, C. A. Gunter,and J. Meseguer, “Model-checking DoS Amplification forVoIP Session Initiation,” in Computer Security–ESORICS.Springer, 2009, pp. 390–405.
[9] M. Anagnostopoulos, G. Kambourakis, P. Kopanos,G. Louloudakis, and S. Gritzalis, “DNS AmplificationAttack Revisited,” Comput. Secur., vol. 39, pp. 475–485, Nov.2013.
[10] X. Ye and Y. Ye, “A Practical Mechanism to CounteractDNS Amplification DDoS Attacks,” Journal of ComputationalInformation Systems, vol. 9, pp. 265–272, 2013.
[11] M. Kuhrer, T. Hupperich, C. Rossow, and T. Holz, “Exit fromHell? Reducing the Impact of Amplification DDoS Attacks,”in Proc. of the 23rd USENIX Security Symposium. USENIXAssoc., 2014.
[12] T. Bottger, L. Braun, O. Gasser, F. von Eye, H. Reiser, andG. Carle, “DoS Amplification Attacks – Protocol-AgnosticDetection of Service Abuse in Amplifier Networks,” in 7thInternational Workshop on Traffic Monitoring and Analysis(TMA), vol. 9053. Springer-Verlag, 2015, pp. 205–218.
[13] Prolexic, “Prolexic Quarterly Global DDoS Attack ReportQ4 2013,” Feb 2014. [Online]. Available: http://www.akamai.com/dl/akamai/prolexic-q42013-global-attack-report-us.pdf
[14] A. Welzel, C. Rossow, and H. Bos, “On Measuring the Impactof DDoS Botnets,” in Proceedings of the Seventh EuropeanWorkshop on System Security, ser. EuroSec ’14. ACM, 2014,pp. 1–6.
[15] D. Cornell, “DNS Amplification Attacks,” March 2014.[Online]. Available: https://labs.opendns.com/2014/03/17/dns-amplification-attacks/
[16] S. M. Bellovin, “Security Problems in the TCP/IP ProtocolSuite,” ACM SIGCOMM Comput. Commun. Rev., vol. 19,no. 2, pp. 32–48, Apr. 1989.
[17] M. Prince, “Technical Details Behind a 400GbpsNTP Amplification DDoS Attack,” Feb 2014.[Online]. Available: http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack
[18] “Open Resolver Project,” April 2015. [Online]. Available:http://openresolverproject.org
[19] Y. Li, Q. Wang, F. Yang, and S. Su, “Traceback DRDoSAttacks,” Journal of Information & Computational Science,vol. 8, pp. 94–111, 2011.
[20] C. Rossow, “Amplification Hell: Revisiting Network Protocolsfor DDoS Abuse,” in Proc. of NDSS. Internet Society, 2014.
[21] R. Chang, “Defending against flooding-based distributeddenial-of-service attacks: A tutorial,” Communications Mag-azine, IEEE, vol. 40, no. 10, pp. 42–51, Oct 2002.
[22] D. Huistra, “Detecting Reflection Attacks in DNS Flows,” in19th Twente Student Conference on IT, February 2013.
[23] V. Paxson, “An Analysis of Using Reflectors for DistributedDenial-of-service Attacks,” ACM SIGCOMM Comput. Com-mun. Rev., vol. 31, no. 3, pp. 38–47, Jul. 2001.
[24] AusCERT, “Domain Name System (DNS) Denial of Service(DoS) Attacks,” August 1999. [Online]. Available: http://www.securityfocus.com/advisories/1727
[25] J. Damas, M. Graff, and P. Vixie, “Extension Mechanisms forDNS (EDNS(0)),” IETF, RFC 6891, April 2013.
[26] CERT Advisory, “Smurf IP Denial of Service Attacks,”1998. [Online]. Available: http://www.cert.org/advisories/CA-1998-01.html
[27] S. Kumar, “Smurf-based Distributed Denial of Service (DDoS)Attack Amplification in Internet,” in Proceedings of the SecondInternational Conference on Internet Monitoring and Protec-tion. IEEE, 2007.
[28] A. Householder, A. Manion, L. Pesante, G. Weaver, andR. Thomas, “Managing the Threat of Denial-of-serviceAttacks,” 2001. [Online]. Available: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=52481
[29] US-CERT, “UDP-based Amplification Attacks,” 2014.[Online]. Available: https://www.us-cert.gov/ncas/alerts/TA14-017A
[30] Akamai, “SSDP Reflection DDOS Attacks,”2014. [Online]. Available: http://www.prolexic.com/kcresources/attack-report/attack report q214/Prolexic-Q22014-Global-Attack-Report-A4.pdf
[31] MIT, “2013-05-16 SNMP Amplification Attack,” May 2013.[Online]. Available: http://tinyurl.com/MIT-drdos
[32] US-CERT, “NTP Amplification Attacks Using CVE-2013-5211,” 2014. [Online]. Available: https://www.us-cert.gov/ncas/alerts/TA14-013A
[33] Akamai, “The State of the Internet [security],” September2014. [Online]. Available: http://www.stateoftheinternet.com/resources-web-security-2014-q4-internet-security-report.html
[34] R. Sparks, “Addressing an Amplification Vulnerabilityin Forking Proxies,” 2006. [Online]. Available: https://tools.ietf.org/html/draft-ietf-sip-fork-loop-fix-00
[35] T. Brewster, “Prolexic CEO: Biggest Cyber AttackEver Was Built on Lies,” April 2013. [Online].Available: http://www.techweekeurope.co.uk/workspace/prolexic-ceo-scott-hammack-biggest-cyber-attack-lies-spamhaus-113551
[36] T. Rozekrans, M. Mekking, and J. de Koning, “DefendingAgainst DNS Reflection Amplification Attacks,” University ofAmsterdam, Tech. Rep., February 2013.
[37] W. Chen and D.-Y. Yeung, “Defending Against TCP SYNFlooding Attacks Under Different Types of IP Spoofing,” inInternational Conference on Networking, International Con-ference on Systems and International Conference on MobileCommunications and Learning Technologies. IEEE, April2006.
[38] S. H. D. Nashat, Xiaohong Jiang, “Detecting SYN FloodingAgents under Any Type of IP Spoofing,” in IEEE International
15
Conference on e-Business Engineering. IEEE, October 2008,pp. 499–505.
[39] M. O. H. N. A. Noureldien, “Block Spoofed Packets at Source(BSPS): A Method for Detecting and Preventing all Typesof Spoofed Source IP Packets and SYN Flooding Packets atSource: A Theoretical Framework,” in Second InternationalConference on the Applications of Digital Information andWeb Technologies. IEEE, Aug 2009, pp. 579–583.
[40] L. Kavisankar and C. Chellappan, “A Mitigation Model forTCP SYN Flooding with IP spoofing,” in International Con-ference on Recent Trends in Information Technology (ICRTIT).IEEE, June 2011, pp. 251–256.
[41] Y. Gilad and A. Herzberg, “LOT: A Defense Against IPSpoofing and Flooding Attacks,” ACM Trans. Inf. Syst. Secur.,vol. 15, no. 2, pp. 6:1–6:30, Jul. 2012.
[42] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H.Briggs, and R. L. Braynard, “Networking Named Content,” inProceedings of the 5th International Conference on EmergingNetworking Experiments and Technologies. ACM, 2009, pp.1–12.
[43] J. Meseguer, “Rewriting Logic and Maude: A Wide-SpectrumSemantic Framework for Object-Based Distributed Systems,”in Formal Methods for Open Object-Based Distributed SystemsIV. Springer US, 2000, vol. 49, pp. 89–117.
[44] Valve, “Steam Master Server Query Protocol,” 2015.[Online]. Available: https://developer.valvesoftware.com/wiki/Master Server Query Protocol
[45] R. Beverly and S. Bauer, “The Spoofer Project: Inferring theExtent of Source Address Filtering on the Internet,” USENIXSRUTI: Steps to Reducing Unwanted Traffic on the InternetWorkshop, pp. 53–59, Jul. 2005.
[46] D. Moore, C. Shannon, D. J. Brown, G. M. Voelker, andS. Savage, “Inferring Internet denial-of-service activity,” ACMTrans. Comput. Syst., vol. 24, no. 2, pp. 115–139, 2006.
[47] J. Mauch, “SNMP DDoS: The Vulnerability You Might NotKnow You Have,” http://seclists.org/nanog/2013/Aug/132, Au-gust 2013.
[48] H. Ballani, P. Francis, and X. Zhang, “A Study of PrefixHijacking and Interception in the Internet,” ACM SIGCOMMComput. Commun. Rev., vol. 37, no. 4, pp. 265–276, Aug.2007.
[49] B. Harris and R. Hunt, “TCP/IP Security Threats and AttackMethods,” Computer Communications, vol. 22, no. 10, pp.885–897, 1999.
[50] L. T. Heberlein and M. Bishop, “Attack Class: AddressSpoofing,” in Proc. of the 19th National Information SystemsSecurity Conference, 1996, pp. 371–377.
[51] T. Dunigan, “Backtracking Spoofed Packets,” 2001. [Online].Available: http://www.epm.ornl.gov/∼dunigan/oci/back.ps
[52] L. Soon, M. Othman, and N. I. Udzir, “IP Spoofing Defense:An Introduction,” International Conference on Computing &Informatics (ICOCI09), 2009.
[53] T. Ehrenkranz and J. Li, “On the State of IP SpoofingDefense,” ACM Trans. Internet Technol., vol. 9, no. 2, pp.1–29, May 2009.
[54] A. Belenky and N. Ansari, “On ip traceback,” CommunicationsMagazine, IEEE, vol. 41, no. 7, pp. 142–153, 2003.
[55] A. John and T. Sivakumar, “DDoS: Survey of Traceback Meth-ods,” International Journal of Recent Trends in Engineering,vol. 1, no. 2, pp. 241–245, May 2009.
[56] S. Vincent and J. I. J. Raja, “A Survey of IP Traceback Mech-anisms to Overcome Denial-of-service Attacks,” Proceedings
of the 12th International Conference on Networking, VLSI andSignal Processing, pp. 93–98, 2010.
[57] R. Jain and P. A. Meshram, “A Survey on Packet Markingand Logging,” International Journal of Computer Science andInformation Technologies (IJCSIT), vol. 4, no. 3, pp. 426–429,2013.
[58] S. J. Templeton and K. E. Levitt, “Detecting Spoofed Packets,”in DARPA Information Survivability Conference and Exposi-tion, 2003, April 2003, pp. 164–175.
[59] H.-Y. Chang, R. Narayan, S. F. Wu, B. Vetter, X. Wang,M. Brown, J. Yuill, C. Sargor, Y. F. Jou, and F. Gong, “DecId-UouS: Decentralized Source Identification for Network-BasedIntrusions,” in Integrated Network Management. IEEE, 1999,pp. 701–714.
[60] S. Savage, D. Wetherall, A. R. Karlin, and T. E. Anderson,“Practical Network Support for IP Traceback,” in Proc. ofACM SIGCOMM. ACM, 2000, pp. 295–306.
[61] D. Schnackenberg, K. Djahandari, and D. Sterne, “Infras-tructure for Intrusion Detection and Response,” in DARPAInformation Survivability Conference and Exposition, vol. 2,2000, pp. 3–11.
[62] P. Ferguson and D. Senie, “Network Ingress Filtering: De-feating Denial of Service Attacks which employ IP SourceAddress Spoofing,” IETF, RFC 2827, May 2000.
[63] J. Mirkovic, N. Jevtic, and P. Reiher, “A Practical IP Spoof-ing Defense Through Route-Based Fltering,” University ofDelaware, CIS department, Technical Report, CIS-TR, 2006.
[64] A. Bremler-barr and H. Levy, “Spoofing Prevention Method,”in Proc. IEEE INFOCOM, 2005, pp. 536–547.
[65] K. Park and H. Lee, “On the Effectiveness of Route-basedPacket Filtering for Distributed DoS Attack Prevention inPower-law Internets,” ACM SIGCOMM Comput. Commun.Rev., vol. 31, no. 4, pp. 15–26, Aug. 2001.
[66] Z. D. X. Yuan and J. Chandrashekar, “Controlling IP Spoofingthrough Interdomain Packet Filters,” in Dependable and Se-cure Computing, IEEE Transactions on, vol. 5. IEEE, March2008, pp. 22–36.
[67] T. Ohtsuka, F. Nakamura, Y. Sekiya, and Y. Wakahara, “Pro-posal and Efficient Implementation of Detecting and FilteringMethod for IP Spoofed Packets,” in International Conferenceon Information and Communication Technology. IEEE,March 2007, pp. 327–330.
[68] J. Li, J. Mirkovic, T. Ehrenkranz, M. Wang, P. Reiher, andL. Zhang, “Learning the Valid Incoming Direction of IPPackets,” Computer Networks, vol. 52, no. 2, pp. 399–417,2008.
[69] C. A. Shue, M. Gupta, and M. P. Davy, “Packet Forwardingwith Source Verification,” Comput. Netw., vol. 52, no. 8, pp.1567–1582, Jun. 2008.
[70] H. Lee, M. Kwon, G. Hasker, and A. Perrig, “BASE: AnIncrementally Deployable Mechanism for Viable IP SpoofingPrevention,” in Proc. of the 2nd ACM ASIACCS. ACM, 2007,pp. 20–31.
[71] A. Yaar, A. Perrig, and D. X. Song, “Pi: A Path IdentificationMechanism to Defend against DDoS Attack,” in Proc. of IEEESymposium on Security and Privacy. IEEE, 2003.
[72] Cisco Systems, “Unicast Reverse Path Forwarding Enhance-ments For The Internet Service Provider — Internet ServiceProvider Network Edge,” Cisco, White Paper, 2005.
[73] G.-F. Lv and Z.-G. Sun, “Towards Spoofing Prevention Basedon Hierarchical Coordination Model,” in Proc. of Workshop onHigh Performance Switching and Routing (HPSR’07). IEEE,June 2007, pp. 1–6.
16
[74] H. Wang, C. Jin, and K. G. Shin, “Defense Against Spoofed IPTraffic Using Hop-count Filtering,” IEEE/ACM Trans. Netw.,vol. 15, no. 1, pp. 40–53, Feb. 2007.
[75] A. Yaar, A. Perrig, and D. Song, “StackPi: New PacketMarking and Filtering Mechanisms for DDoS and IP SpoofingDefense,” IEEE Journal on Selected Areas in Communications,vol. 24, no. 10, pp. 1853–1863, 2006.
[76] Z. Gao and N. Ansari, “A Practical and Robust Inter-domainMarking Scheme for IP Traceback,” Computer Networks,vol. 51, no. 3, pp. 732–750, 2007.
[77] R. Chen, J.-M. Park, and R. Marchany, “A Divide-and-Conquer Strategy for Thwarting Distributed Denial-of-ServiceAttacks,” Parallel and Distributed Systems, IEEE Transactionson, vol. 18, no. 5, pp. 577–588, May 2007.
[78] J. Wu, G. Ren, and X. Li, “Source Address Validation: Ar-chitecture and Protocol Design,” in Network Protocols, 2007.ICNP 2007. IEEE International Conference on. IEEE, 2007,pp. 276–283.
[79] D. Dean, M. K. Franklin, and A. Stubblefield, “An AlgebraicApproach to IP traceback,” ACM Trans. Inf. Syst. Secur., vol. 5,no. 2, pp. 119–137, 2002.
[80] G. Taleck, “Ambiguity Resolution via Passive OS Fingerprint-ing,” in Recent Advances in Intrusion Detection, ser. LectureNotes in Computer Science. Springer, 2003, vol. 2820, pp.192–206.
[81] M. Adler, “Trade-offs in Probabilistic Packet Marking for IPTraceback,” J. ACM, vol. 52, no. 2, pp. 217–244, Mar. 2005.
[82] Fyodor, “Remote OS Detection,” 2006. [Online]. Available:http://nmap.org/book/osdetect.html
[83] S. Kent and K. Seo, “Security Architecture for theInternet Protocol,” RFC 4301 (Proposed Standard), InternetEngineering Task Force, December 2005. [Online]. Available:http://www.ietf.org/rfc/rfc4301.txt
[84] R. Beverly, “A Robust Classifier for Passive TCP/IP Finger-printing,” in Proc. of 5th International Workshop on Passiveand Active Network Measurement (PAM). Heidelberg Berlin:Springer, 2004, pp. 158–167.
[85] G. Taleck, “Ambiguity Resolution via Passive OS Fingerprint-ing,” in Proc. of RAID. Springer, 2003, pp. 192–206.
[86] B. Berntein, “SYN Cookies,” 1996. [Online]. Available:http://cr.yp.to/syncookies.html
[87] W. Feng, E. Kaiser, W. Feng, and A. Luu, “Design andimplementation of network puzzles,” in INFOCOM 2005.24th Annual Joint Conference of the IEEE Computer andCommunications Societies. Proceedings IEEE, vol. 4, March2005, pp. 2372–2382 vol. 4.
[88] C. Jin, H. Wang, and K. G. Shin, “Hop-count Filtering: AnEffective Defense Against Spoofed DDoS Traffic,” in Proc. ofthe 10th ACM CCS. ACM, 2003, pp. 30–41.
[89] T. Killalea, “Recommended Internet Service Provider SecurityServices and Procedures,” RFC 3013 (Best Current Practice),Internet Engineering Task Force, Nov. 2000. [Online].Available: http://www.ietf.org/rfc/rfc3013.txt
[90] F. Baker, “Requirements for IP Version 4 Routers,” RFC1812 (Proposed Standard), Internet Engineering Task Force,June 1995, updated by RFC 2644. [Online]. Available:http://www.ietf.org/rfc/rfc1812.txt
[91] F. Baker and P. Savola, “Ingress Filtering for MultihomedNetworks,” RFC 3704 (Best Current Practice), InternetEngineering Task Force, March 2004. [Online]. Available:http://www.ietf.org/rfc/rfc3704.txt
[92] X. Liu, A. Li, X. Yang, and D. Wetherall, “Passport: Secureand Adoptable Source Authentication,” in Proceedings of the
5th USENIX Symposium on Networked Systems Design andImplementation. USENIX Association, 2008, pp. 365–378.
[93] J. Li, J. Mirkovic, M. Wang, P. Reiher, and L. Zhang, “SAVE:Source address validity enforcement protocol,” in IEEE IN-FOCOM, 2002, pp. 1557–1566.
[94] Z. Duan, X. Yuan, and J. Chandrashekar, “Constructing Inter-Domain Packet Filters to Control IP Spoofing Based on BGPUpdates,” in Proc. of IEEE INFOCOM, 2006, pp. 1–12.
[95] T. Ehrenkranz and J. Li, “An Incrementally Deployable Pro-tocol for Learning the Valid Icoming Direction of IP Packets,”University of Oregon, Tech. Rep., October 2007.
[96] R. Stone, “Centertrack: An IP Overlay Network for TrackingDoS Floods,” in Proc. of the 9th conference on USENIXSecurity Symposium. USENIX Association, 2000, pp. 15–15.
[97] H. Burch and B. Cheswick, “Tracing Anonymous Packets toTheir Approximate Source,” in Proc. of the 14th Conferenceon Systems Administration (LISA 2000). USENIX, December2000, pp. 319–327.
[98] S. Bellovin and M. Leech, “ICMP Traceback Messages,”February 2000. [Online]. Available: https://tools.ietf.org/html/draft-ietf-itrace-00
[99] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, “NetworkSupport for IP Traceback,” IEEE/ACM Trans. Netw., vol. 9,no. 3, pp. 226–237, Jun. 2001.
[100] D. X. Song and A. Perrig, “Advanced and Authenticated Mark-ing Schemes for IP Traceback,” in Proc. of IEEE INFOCOM,vol. 2, 2001, pp. 878–886.
[101] A. Belenky and N. Ansari, “Accommodating Fragmentation inDeterministic Packet Marking for IP Traceback,” in Proceed-ings of IEEE Global Telecommunications Conference, 2003,pp. 1374–1378.
[102] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones,F. Tchakountio, B. Schwartz, S. T. Kent, and W. T.Strayer, “Single-packet IP traceback.” IEEE/ACM Trans.Netw., vol. 10, no. 6, pp. 721–734, 2002.
[103] Y. Xiang, W. Zhou, and M. Guo, “Flexible DeterministicPacket Marking: An IP Traceback System to Find the RealSource of Attacks,” IEEE Transactions on Parallel and Dis-tributed Systems, vol. 20, no. 4, pp. 567–580, April 2009.
[104] L. Zhang and Y. Guan, “TOPO: A Topology-aware SinglePacket Attack Traceback Scheme,” in Securecomm and Work-shops. IEEE Press, September 2006, pp. 1–10.
[105] S. Matsuda, T. Baba, A. Hayakawa, and T. Nakamura, “Designand Implementation of Unauthorized Access Tracing System,”in Proceedings of the 2002 Symposium on Applications andthe Internet. IEEE Computer Society, 2002, pp. 74–81.
[106] H. A. Alwis, R. C. Doss, P. S. Hewage, and M. U. Chowdhury,“Topology Based Packet Marking for IP Traceback,” in Proc.of the Australian Telecommunication Networks and Applica-tions Conference (ATNAC). University of Melbourne, 2006,pp. 224–228.
[107] C. Gong and K. Sarac, “A More Practical Approach for Single-Packet IP Traceback using Packet Logging and Marking ,” pp.1310–1324, 2008.
[108] T. W. Doeppner, P. N. Klein, and A. Koyfman, “Using RouterStamping to Identify the Source of IP Packets,” in Proc. of the7th ACM CCS. ACM, 2000, pp. 184–189.
[109] B. Al-Duwairi and M. Govindarasu, “Novel Hybrid SchemesEmploying Packet Marking and Logging for IP Traceback,”IEEE Trans. Parallel Distrib. Syst., vol. 17, no. 5, pp. 403–418, May 2006.
17
[110] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones,F. Tchakountio, S. T. Kent, and W. T. Strayer, “Hash-based IPTraceback,” ACM SIGCOMM Comput. Commun. Rev., vol. 31,no. 4, pp. 3–14, Aug. 2001.
[111] D. Yan, Y. Wang, S. Su, and F. Yang, “A Precise andPractical IP Traceback Technique Based on Packet Markingand Logging.” J. Inf. Sci. Eng., vol. 28, no. 3, pp. 453–470,2012.
[112] A. Belenky and N. Ansari, “IP Traceback With DeterministicPacket Marking,” IEEE Communications Letters, vol. 7, no. 4,pp. 162–164, April 2003.
[113] C. Gong and K. Sarac, “Toward a Practical Packet MarkingApproach for IP Traceback,” International Journal of NetworkSecurity, vol. 8, no. 3, pp. 271–281, 2009.
[114] M. T. Goodrich, “Probabilistic Packet Marking for Large-scaleIP Traceback,” IEEE/ACM Trans. Netw., vol. 16, no. 1, pp. 15–24, Feb. 2008.
[115] X.-J. Wang and X.-Y. Wang, “Topology-assisted DeterministicPacket Marking for IP Traceback,” The Journal of ChinaUniversities of Posts and Telecommunications, vol. 17, pp.116–121, April 2010.
[116] K. Park and H. Lee, “On the Effectiveness of ProbabilisticPacket Marking for IP Traceback under Denial of ServiceAttack,” pp. 338–347, 2001.
[117] T. Baba and S. Matsuda, “Tracing Network Attacks to TheirSources,” IEEE Internet Computing, vol. 6, no. 2, pp. 20–26,Mar. 2002.
[118] A. Mankin, D. Massey, C.-L. Wu, S. F. Wu, and L. Zhang, “OnDesign and Evaluation of ”Intention-Driven” ICMP Trace-back,” in Computer Communications and Networks, 2001.Proceedings. Tenth International Conference on. IEEE, 2001,pp. 159–165.
[119] S. Lee and C. Shields, “Challenges to Automated AttackTraceback,” IT Professional, vol. 4, no. 3, pp. 12–18, May2002.
[120] R. Beverly, “Spoofer project: State of ip spoofing,” November2014. [Online]. Available: http://spoofer.cmand.org/summary.php
[121] P. Biondi, “Scapy,” 2015. [Online]. Available: http://www.secdev.org/projects/scapy/
[122] W. Eddy, “TCP SYN Flooding Attacks and CommonMitigations,” RFC 4987 (Informational), Internet EngineeringTask Force, August 2007. [Online]. Available: http://www.ietf.org/rfc/rfc4987.txt
[123] J. Postel, “Internet Protocol,” RFC 791 (Internet Standard),Internet Engineering Task Force, Sep. 1981, updated byRFCs 1349, 2474. [Online]. Available: http://www.ietf.org/rfc/rfc791.txt
[124] X. Lu, G. L, P. Zhu, and Y. Chen, “MASK: An EfficientMechanism to Extend Inter-domain IP Spoofing Preventions,”pp. 1745–1760, November 2008.
[125] G. Velmayil and S. Pannirselvam, “Detection and Removalof IP Spoofing through Extended-Inter Domain Packet FilterArchitecture,” International Journal of Computer Applications,vol. 49, no. 17, pp. 37–43, July 2012.
[126] F. Guo, J. Chen, and T. cker Chiueh, “Spoof Detection forPreventing DoS Attacks against DNS Servers,” in Proc. ofICDCS. IEEE, 2006.
[127] D. Kuptsov and A. Gurtov, “SAVAH: Source Address Val-idation with Host Identity Protocol,” in Proc. of the FirstInternational ICST Conference on Security and Privacy in Mo-bile Information and Communication Systems (MobiSec’09.Springer, 2009, pp. 190–201.
[128] A. Gurtov, Host Identity Protocol (HIP): Towards the SecureMobile Internet. John Wiley & Sons, 2008, vol. 21.
[129] R. Moskowitz and P. Nikander, “Host Identity Protocol(HIP) Architecture,” RFC 4423 (Informational), InternetEngineering Task Force, may 2006. [Online]. Available:http://www.ietf.org/rfc/rfc4423.txt
[130] H. Ishibashi, N. Yamai, K. Abe, and T. Matsuura, “A Pro-tection Method Against Unauthorized Access and AddressSpoofing for Open Network Access Systems,” in IEEE PacificRim Conference on Communications, Computers and signalProcessing, vol. 1. IEEE, 2001, pp. 10–13.
[131] J. M. Gonzalez, M. Anwar, and J. B. Joshi, “A Trust-basedApproach Against IP-spoofing Attacks,” in Ninth Annual Con-ference on Privacy, Security and Trust (PST 2011). IEEE,July 2011, pp. 63–70.
[132] M. O. H. Noureldien A. Noureldien, “Block Spoofed Packetsat Source (BSPS): A Method for Detecting and PreventingAll Types of Spoofed Source IP Packets and SYN FloodingPackets at Source: A Theoretical Framework,” InternationalJournal of Networks and Communications, vol. 2, no. 3, pp.33–37, 2012.
[133] K. Egevang and P. Francis, “The IP Network AddressTranslator (NAT),” RFC 1631 (Informational), InternetEngineering Task Force, May 1994, obsoleted by RFC 3022.[Online]. Available: http://www.ietf.org/rfc/rfc1631.txt
[134] P. Ferguson and D. Senie, “Network Ingress Filtering:Defeating Denial of Service Attacks which employ IP SourceAddress Spoofing,” RFC 2267 (Informational), InternetEngineering Task Force, January 1998, obsoleted by RFC2827. [Online]. Available: http://www.ietf.org/rfc/rfc2267.txt
[135] K. Butler, T. Farley, P. Mcdaniel, and J. Rexford, “A surveyof BGP security issues and solutions,” AT&T Labs Research,2008.
[136] J. Israr, M. Guennoun, and H. T. Mouftah, “Mitigating IPSpoofing by Validating BGP Routes Updates,” InternationalJournal of Computer Science and Network Security (IJCSNS),vol. 9, no. 5, pp. 71–76, May 2009.
[137] C. L. Abad and R. I. Bonilla, “An Analysis on the Schemesfor Detecting and Preventing ARP Cache Poisoning Attacks,”in 27th International Conference on Distributed ComputingSystems Workshops. IEEE, 2007, pp. 60–60.
[138] R. Atkinson, “Security Architecture for the Internet Protocol,”IETF, RFC 1825, August 1995.
[139] S. Kent, “IP Authentication Header,” IETF, RFC 4302, De-cember 2005.
[140] ——, “IP Encapsulating Security Payload (ESP),” IETF, RFC4303, December 2005.
[141] M. Sung, J. Xu, J. Li, and L. Li, “Large-scale IP Tracebackin High-speed Internet: Practical Techniques and Information-theoretic Foundation,” IEEE/ACM Trans. Netw., vol. 16, no. 6,pp. 1253–1266, Dec. 2008.
[142] T. Korkmaz, C. Gong, K. Sara, and S. G. Dykes, “SinglePacket IP Traceback in AS-level Partial Deployment Scenario,”IJSN, pp. 95–108, 2007.
[143] W. Strayer, C. Jones, F. Tchakountio, A. Snoeren, B. Schwartz,R. Clements, M. Condell, and C. Partridge, “Traceback ofsingle IP packets using SPIE,” in DARPA Information Surviv-ability Conference and Exposition, 2003. Proceedings, vol. 2,April 2003, pp. 266–270.
[144] A. Belenky and N. Ansari, “On Deterministic Packet Mark-ing,” Comput. Netw., vol. 51, no. 10, pp. 2677–2700, Jul. 2007.
[145] Z. Chen and M.-C. Lee, “An IP Traceback Technique AgainstDenial-of-service Attacks,” in Computer Security Applications
18
Conference, 2003. Proceedings. 19th Annual, Dec 2003, pp.96–104.
[146] H. C. J. Lee, V. L. L. Thing, Y. Xu, and M. Ma, “ICMPTraceback with Cumulative Path, an Efficient Solution forIP Traceback,” in Proc. of Information and CommunicationsSecurity, 5th International Conference, ICICS, vol. 2836.Springer, 2003, pp. 124–135.
[147] H.-W. Lee, M.-G. Kang, and C.-W. Choi, “PTrace: Push-back/SVM Based ICMP Traceback Mechanism against DDoSAttack,” in Computational Science and Its Applications -ICCSA 2004, vol. 3043. Springer, 2004, pp. 302–309.
[148] B.-T. Wang and H. Schulzrinne, “An IP Traceback Mechanismfor Reflective DoS Attacks,” in Canadian Conference onElectrical and Computer Engineering, vol. 2, May 2004, pp.901–904.
[149] R. Feiertag, C. Kahn, P. Porras, D. Schnackenberg,S. Staniford-Chen, and B. Tung, “A Common Intrusion Spec-ification Language (CISL),” 1999.
[150] V. Santiraveewan and Y. Permpoontanalarp, “A Graph-basedMethodology for Analyzing IP Spoofing Attack,” in Proc. ofthe 18th International Conference on Advanced InformationNetworking and Applications, ser. AINA ’04. IEEE ComputerSociety, 2004.
[151] K. Ali, M. Zulkernine, and H. S. Hassanein, “Packet FilteringBased on Source Router Marking and Hop-Count,” in LCN.IEEE Computer Society, 2007, pp. 1061–1068.
[152] T. R. C. Manusankar, S. Karthik, “Intrusion Detection Systemwith Packet Filtering for IP Spoofing,” International Con-ference on Communication and Computational Intelligence(INCOCCI), pp. 563–567, 2010.
[153] B.-T. Wang and H. Schulzrinne, “A Denial-of-Service-Resistant IP Traceback Approach,” in Proc. of Ninth Interna-tional Symposium on Computers and Communications (ISCC).IEEE, June 2004, pp. 351–356.
[154] V. Thing, M. Sloman, H. Lee, and J. Zhou, “Enhanced ICMPTraceback with Cumulative Path,” in Proc. of 61st IEEE VTC,May 2005.
[155] R. Shokri, A. Varshovi, H. Mohammadi, and N. Yazdani,“DDPM: Dynamic Deterministic Packet Marking for IP Trace-back,” in 14th IEEE International Conference on Networks,vol. 2. IEEE, September 2006, pp. 1–6.
[156] Q. Dong, M. Adler, S. Banerjee, and K. Hirata, “EfficientProbabilistic Packet Marking,” in 13th IEEE ICNP. IEEE,November 2005.
[157] Y. Xiung and W. Zhou, “A Defense System against DDoSAttacks by Large-Scale IP Traceback,” in Proc. of ThirdInternational Conference on Information Technology and Ap-plications (ICITA), vol. 2. IEEE Press, November 2005, pp.431–436.
[158] M. T. Goodrich, “Efficient Packet Marking for Large-scale IPTraceback,” in Proc. of the 9th ACM CCS. ACM, 2002, pp.117–126.
[159] D. R. W. V. Shyamaladevi, “Analyze and Determine the IPSpoofing Attacks Using Stackpath Identification Marking andFiltering Mechanism,” International Journal of Recent Trendsin Engineering, vol. 1, may 2009.
[160] Y. Chen, S. Das, P. Dhar, A. El-Saddik, and A. Nayak, “De-tecting and Preventing IP-spoofed Distributed DoS Attacks,”I. J. Network Security, vol. 7, no. 1, pp. 69–80, 2008.
[161] G. H. Lai, C.-M. Chen, B.-C. Jeng, and W. Chao, “Ant-basedIP Traceback,” Expert Syst. Appl., vol. 34, no. 4, pp. 3071–3080, May 2008.
[162] N. Arumugam and C. Venkatesh, “A Dynamic Method to
Detect IP Spoofing on Data Network Using Ant Algorithm,”IOSR Journal of Engineering (IOSRJEN), vol. 2, october 2012.
[163] S. S. H. N. Reddy and S. T. Prasad, “Robust IP Spoof ControlMechanism Through Packet Filters,” International Journal ofComputer Trends and Technology, vol. 3, 2012.
[164] J. Yang, Y. Chen, W. Trappe, and J. Cheng, “An EffectiveMethod for Defense against IP Spoofing Attack ,” IEEETransactions on Parallel and Distributed Systems, vol. 24, pp.44–58, Jan. 2013.
[165] H. Tsunoda, K. Ohta, A. Yamamoto, N. Ansari, Y. Waizumi,and Y. Nemoto, “Detecting DRDoS Attacks by a Simple Re-sponse Packet Confirmation Mechanism,” Comput. Commun.,vol. 31, no. 14, pp. 3299–3306, Sep. 2008.
[166] G. Kambourakis, T. Moschos, D. Geneiatakis, and S. Gritzalis,“Detecting DNS Amplification Attacks,” in Workshop on Crit-ical Information Infrastructures Security (CRITIS), vol. 5141.Springer, 2008, pp. 185–196.
[167] W. Wei, F. Chen, Y. Xia, and G. Jin, “A Rank CorrelationBased Detection against Distributed Reflection DoS Attacks,”Communications Letters, IEEE, vol. 17, no. 1, pp. 173–175,January 2013.
[168] T. Peng, C. Leckie, and K. Ramamohanarao, “DetectingReflector Attacks by Sharing Beliefs,” in Proc. of IEEEGLOBECOM, 2003, pp. 1358–1362.
[169] C. Fachkha, E. Bou-Harb, and M. Debbabi, “Towards a Fore-casting Model for Distributed Denial of Service Activities,” in12th IEEE International Symposium on Network Computingand Applications (NCA), August 2013, pp. 110–117.
[170] ——, “Fingerprinting Internet DNS Amplification DDoS Ac-tivities,” in 6th International Conference on New Technologies,Mobility and Security (NTMS), March 2014, pp. 1–5.
[171] ——, “Inferring Distributed Reflection Denial of Service At-tacks from Darknet,” Computer Communications, vol. 62, pp.59 – 71, 2015.
[172] H. Tsunoda, Y. Nemoto, K. Ohta, and A. Yamamoto, “ASimple Response Packet Confirmation Method for DRDoSDetection,” in Proc. of the 8th International Conference onAdvanced Communication Technology (ICACT 2006), vol. 3.IEEE Press, February 2006.
[173] S. Yu, W. Zhou, W. Jia, S. Guo, Y. Xiang, and F. Tang, “Dis-criminating DDoS Attacks from Flash Crowds Using FlowCorrelation Coefficient,” Parallel and Distributed Systems,IEEE Transactions on, vol. 23, no. 6, pp. 1073–1080, 2012.
[174] The Shadowserver Foundation, April 2015. [Online].Available: https://dnsscan.shadowserver.org/
[175] Network Time Foundation, April 2015. [Online]. Available:http://openntpproject.org/
[176] The Measurement Factory, April 2015. [Online]. Available:http://dns.measurement-factory.com
19