Distributed Denial of Service Attacks - Cornell University · 2004-11-02 · Distributed Denial of Service Attacks ... A Brief Introduction What is a DoS Attack? A explicit attempt

Distributed Denial of Service Attacks

Grant GoodaleCornell UniversityNovember 2004

A Brief IntroductionWhat is a DoS Attack?

A explicit attempt by attackers to prevent the legitimate use of a service.

Targets include both end hosts and infrastructure

Distributed DoS: use of multiple machines to execute a DoS attack

Long history (~1996), many techniques* http://www.cert.org/tech tips/denial of service.html

A Short History of DDoS

Up to 1996: point to point

SYN flooding, PoD, fragmentation attacks

1997-1998: combined attacks

smurf, fraggle, teardrop, winnuke

Increasing sophistication in deployment, ease of use


1999-2000: Flooding, IRC

ip-proto-255, TCP NULL flood

Encrypted custom C&C channels, IRC

payload includes remote shell, auto-update

rootkits start including DDoS toolkits


2001-2002: Reflection attacks, worms, Countermeasures

Code Red, l10n

Scan, infect, repeat

IRC channel hopping

A Short History of DDoS2003-2004: Blended threats, sophisticated delivery

Windows vulnerabilities (RPC DCOM, etc.) provide easy attack vector for worms (Slammer)

More valid traffic (non-spoofed source IP, randomized valid payload

Hard to distinguish between attack and ‘Flash Crowd’

A Growing Problem

Estimates of “hundreds of attacks a day” - in 2001

New trend: networks of machines for hire

Send spam during the day, attack your competitors at night

Toolkits require almost zero skill to use - just download and start 0wning machines

The DDoS Arms RaceOn one side: Solution Providers, ISPS, Academia

On the other:

Defense Techniques

Axes of comparison:

Passive (detection) vs. active (prevention)

Edge-deployed vs. target-deployed

Common approaches:

Packet filters at the edge

Traffic characterization

The Papers

Riverhead Networks’ Traffic classification and filtering system

Riverhead Networks’ Long Diversion method of centralized DDoS protection

Firebreak - routing/trusted intermediary solution

Why these papers? Practical, not theoretic solutions

Riverhead NetworksTechnical Note DDoS Mitigation

Riverhead Networks Page 5

Figure 3: When a DDoS attack is launched (Step 1, top) and detected (Step 2), traffic destined for

the targeted device !! and only that traffic !! is diverted to the Riverhead Guard (Step 3). Traffic

flowing through the Guard (Step 4, bottom) is subjected to a rigorous multi-verification process to remove bad packets (Step 5) while allowing legitimate traffic to pass unimpeded (Step 6).

Riverhead Guard

VictimNon-victimized servers

BGP announcement

DDoS Detector(Riverhead, Cisco IDS,

Firewall, etc.)

1. At tack i s

L a u n c h e d

2. At tack i s

d e t e c t e d

3. T r a f f i c d e s t i n e d f o r

t a r g e t d e v i c e d i v e r t e d

t o R i v e r h e a d G u a r d

Non-victimized servers

Riverhead Guard


BGP announcementBGP announcement


Firewall, etc.)

1. At tack i s

L a u n c h e d

2. At tack i s

d e t e c t e d





Riverhead

Guard


4. Traffic destined for victim

flows through Guard

6. Legitimate traffic continues to victim

Non-victim traffic

flows freely


5. Guard removes

bad traffic

Riverhead

Guard



flows through Guard


Non-victim traffic

flows freely


5. Guard removes

bad traffic

DDoS attack results in BGP announcement diverting traffic away from the target to the Riverhead Guard

Riverhead Networks

Traffic is filtered based on several criteria; “good” traffic then sent back to target

Technical Note DDoS Mitigation

Riverhead Networks Page 5

Figure 3: When a DDoS attack is launched (Step 1, top) and detected (Step 2), traffic destined for

the targeted device !! and only that traffic !! is diverted to the Riverhead Guard (Step 3). Traffic

flowing through the Guard (Step 4, bottom) is subjected to a rigorous multi-verification process to remove bad packets (Step 5) while allowing legitimate traffic to pass unimpeded (Step 6).

Riverhead Guard


BGP announcement


Firewall, etc.)

1. At tack i s

L a u n c h e d

2. At tack i s

d e t e c t e d





Riverhead Guard


BGP announcementBGP announcement


Firewall, etc.)

1. At tack i s

L a u n c h e d

2. At tack i s

d e t e c t e d





Riverhead

Guard



flows through Guard


Non-victim traffic

flows freely


5. Guard removes

bad traffic

Riverhead

Guard



flows through Guard


Non-victim traffic

flows freely


5. Guard removes

bad traffic

Riverhead Networks

Five-step pipeline

Heuristic analysis based on traffic modeling

WFQ rate limiting as last step


Page 2 Riverhead Networks

The Riverhead MVP Architecture Before describing how the Riverhead solution mitigates the impact of DDoS attacks, it is first important to

understand the Riverhead philosophy of maintaining business continuity. That means, in contrast to other DDoS

solutions, Riverhead is equally committed to ensuring good packets make their way through the system as they are

to blocking malicious traffic.

To achieve that objective, the Riverhead solutions focus on three things: detect, divert and defeat. When a DDoS

attack is detected, suspicious traffic is immediately diverted to a Riverhead Guard that resides off the critical path

but is connected to key routers upstream from the targeted device. The Guard then subjects the diverted traffic to a

rigorous, multi-level evaluation and analysis process designed to remove bad packets while allowing legitimate

traffic to pass, defeating the attack with no impact on the business.

That filtering process, based on Riverhead’s Multi-Verification Process (MVP) architecture, is what makes the

Riverhead solution so unique. All DDoS prevention tools apply some level of filtering to suspicious traffic when an

attack is identified. The problem with those solutions is that the thresholds designed to block malicious traffic also

block a lot of legitimate traffic. Only Riverhead passes traffic through a detailed, five-step process that thoroughly

separates good packets from bad, delivering a granular level of protection that no other solution can provide.

Five-step DDoS Mitigation The MVP architecture features five separate and distinct enforcement and verification modules that, working

together, provide unprecedented protection against DDoS attacks (see Figure 1). Deployed in the Riverhead Guard

DDoS Defender, each module applies different technology designed to ferret out malicious traffic while allowing

legitimate requests to continue through the system. The modules are tightly integrated and work in a closed-loop

fashion, constantly communicating with and updating each other. The result: a highly dynamic solution that is

constantly evolving and adapting to the changing landscape, offering the most advanced and impenetrable DDoS

protection available.

Figure 1: Riverhead Guard’s Multi-Verification Process (MVP) Architecture

The five Riverhead MVP architecture modules include:

Packet Filtering: The packet-filtering module performs simple packet inspection, enforcing a basic set of rules on

traffic destined for the target device. This set of rules includes two types of filters: static and dynamic. The Static

filters, which are configurable, are designed to simply block non-essential traffic from reaching the victim. These

are activated only in response to an attack condition.

Riverhead Networks

Heuristic analysis applied traffic after spoofed packets are removed

Results are fed back into the initial packet filters

Analysis at network and application layer


Page 4 Riverhead Networks

Critical Sequence While the protocol analysis module plays an important role in the overall traffic scrubbing process, it is really more

an extension of the anomaly recognition module, looking for protocol-specific deviant behavior. When broken

down to its critical base elements, the Riverhead DDoS mitigation process really consists of four major steps, as

shown in Figure 2.

Figure 2: The Riverhead Guard Protection Diagram

The order in which these functions occur is critical to the way the Riverhead solution operates. For instance, it is

important that anomaly recognition occurs after spoofed traffic has been removed from the stream by the anti-

spoofing module. Anomaly recognition determines if any single source is behaving differently from a normal

baseline; if a compromised or hacked source is utilizing IP address spoofing, it is trying to hide this abnormal traffic

flow from a single source by making it look as if it is coming from many sources. The anti-spoofing module will

defeat this evasion technique. Additionally, if this is not done, a hacker could use spoofed packets to skew the input

to the anomaly recognition module and cause it to identify innocent sources as malicious. In other words, anti-

spoofing removes the ability of attack sources to evade detection by anomaly recognition, and anomaly recognition

removes the ability of any non-spoofed attack source from utilizing a volume attack.

After having passed through the filter, anti-spoofing and anomaly recognition modules, packets reaching the

weighted fair queuing stage are assumed to be legitimate. However, because it is impossible to recognize a “bad”

traffic flow without monitoring it for a few seconds, the WFQ module may still encounter misbehaving flows, and it

is that module’s responsibility to carefully regulate the flow of traffic released back into the network to avoid

overwhelming the victim.

Riverhead DDoS Mitigation: How It Works So far, this technical note has described the overall Riverhead MVP architecture, the five components of the

architecture, and what each component does.

This section will describe in greater detail how each of those modules work, providing unique insight into what

makes Riverhead DDoS prevention solutions so unique.

Packet

Filtering

Anti-

Spoofing

Anomaly

RecognitionWFQ

New Rules

Packet

Filtering

Anti-

Spoofing

Anomaly

RecognitionWFQ

New Rules

Difficulties

Effective filtering requires non-noisy training data

How ‘human’ can attack traffic be made to look?

Deployment does not reduce traffic on network upstream from target

Scalability issues - not clear what server/Guard ratio is necessary

Riverhead Long Diversion

4251725

-3485

-85

0


Use MPLS to create a LSP from peering point to Guard when attack is detected

One Guard can interface with several peering points

Billed as a cost-effective solution for ISPs to sell to SMB market


Riverhead Guard sends iBGP announcement to peering routers

prefixes are longer than previously advertised prefix for target

!"#$%&#'()*+,") -+%.)/&0"12&+%)3",$+4)52&%.)36-7)-76)

6'.")8! ! 9&0"1$"'4)*",:+1;2) )

!"#$%&"'()*%+,,"-)&.)&/$)0"#$%/$+1)23+%1)!"#$%&$%&''&()%*&+$("#,%&-&.$/'%&%/0#(.1.(%2.('.3%"&/%4##$%,#'#('#,5%,.2#6/.7$%./%&(".#2#,%48%'"#%

9.2#6"#&,%:+&6,%/#$,.$-%7+'%&$%.;:<%&$$7+$(#3#$'%/'&'.$-%'"&'5%.$%76,#6%'7%6#&("%'"#%2.('.35%'"#%'6&11.(%

/"7+*,%4#%67+'#,%'7%'"#%=&4#*%>?.'(".$-%<67'7(7*%@=><A%0&'"%'"&'%#$,#,%&'%'"#%:+&6,B/%*7704&()%.$'#61&(#C%

%

D7%#$/+6#%'"&'%'"#%;:<%&$$7+$(#3#$'/%?.**%$7'%0670&-&'#%.$'7%&**%'"#%4&()47$#%67+'#6/B%67+'.$-%'&4*#/5%

'.4+1#$%&"5$%&$,%'.4$67.%&%;:<%./%&00*.#,%7$%'"#%(733+$.'8%/'6.$-/C%%E/%&%6#/+*'5%7$*8%9F5%9G%&$,%9H%

?.**%6#(#.2#%'"#%;:<%&$$7+$(#3#$'%&47+'%'"#%2.('.3%@?.'"%*7$-#6%06#1.I#/A5%?.'"%$#I'%"70%'7%'"#%

(766#/07$,.$-%:+&6,/%*7704&()%.$'#61&(#C%

%

829):''.3'-$;$'&)D"#%:+&6,%/#$,/%7+'%&$%.;:<%&$$7+$(#3#$'%@?.'"%'.4+1#$%&"5$%&$,%'.4$67.%&A%'7%67+'#6/%9F5%9G%&$,%9H%

'#**.$-%'"#3%'"&'%'"#%$#I'%"70%'7%'"#%2.('.3B/%,#/'.$&'.7$%./%'"#%:+&6,B/%*7704&()%.$'#61&(#C%%D"./%067(#//%./%

&(".#2#,%+/.$-%67+'#%3&05%?".("%3&$.0+*&'#/%'"#%$#I'%"70%&''6.4+'#%.$%'"#%;:<%&$$7+$(#3#$'C%%D"#%

&$$7+$(#3#$'%?7+*,%+/#%&%*7$-#6%06#1.I%'"#$%'"#%76.-.$&*%2.('.3%&$$7+$(#3#$'5%&$,%'"#6#176#%?7+*,%

-#'%06.76.'8%72#6%'"#%76.-.$&*%;:<%&$$7+$(#3#$'C%

%

%

!"

!"!"

9< 9= 98

9>

#$%&

'())*+),-.-)/0

?&#,&@

9&0"1$"'4

AB'14

6""1&%.

)9+B,"12

9C

D6E

D+1" D+1"

F7GF7 F7GF7

"1!12361+HI

-79

9J

!

)

!"#$%&'()''"*+,'-../$.0&1&.2'2/'23&'4&&%".#'%/$2&%56'

%

%

%

%


Traffic for target host is diverted to to Guard via newly created LSP

Guard performs traffic analysis and forwards valid traffic on to original destination

!"#$%&#'()*+,") -+%.)/&0"12&+%)3",$+4)52&%.)36-7)-76)

8&0"1$"'4)*",9+1:2) ) 6'.");)

!"#$%#$"%

!"#$%&#'$&()*+&,--./-0$1$-#&%$,0'$2&#'$&3$$%(-4&%./#$%25&#'$&%./#$%2&%$%./#$&#'$&6(0#(172&#%,""(0&#.&#'$&

89+&3,#'&:$,;(-4&"%.1&#'$&3$$%(-4&3.(-#2&#.&#'$&<(6$%'$,;&*/,%;72&:..3=,0>&(-#$%",0$?&

&

&

!"

!"!"

8< 8= 8>

8;

?@A!@3

8&0"1$"'4

BC'14

6""1&%.

)8+C,"12

8D

A6E

A+1"

A+1"

@7F@7

@7F@7

"#!#$%

"#!#$%61+GH

-76

/&0"12&+%

)-76

61+GH

-76

@7F@7

A+1"

!

!

!"#$%&'()''*+,-',-+'.%/0'12&'3&&%"4#'%/$1&%5'6789'7(9'7:;'1/'12&'<$=%>?'

&

@'(:$&#'$&*/,%;&(2&,#&#'$&$-;&."&#'$&89+&3,#'5&(#&(2&-.#&%$A/(%$;&#.&%/-&B+89C&(#&.-:D&%$0$(6$2&3/%$&E+&;/$&

#.&#'$&",0#&#',#&<F&(2&#'$&$4%$22&3%.GD&89+&3,#'&".%&#'$&*/,%;?&&E-&.#'$%&H.%;25&<F&3$%".%12&3$-/:#(1,#$&

'.3&3.33(-4&.-&#'$&B+89&3,0>$#2&#',#&,%%(6$&,#&#'$&*/,%;72&:..3=,0>&,-;&2'..#2&#'$1&;(%$0#:D&#.&#'$&

*/,%;&.6$%&#'$&2#,#(0&%./#$?&

&

I'$&*/,%;72&:..3=,0>&2'./:;&=$&%./#,=:$&6(,&E*+&(-&#'$&$-#(%$&-$#H.%>?&&E-&.%;$%&#.&,0'($6$&#'(25&<F&(2&

0.-"(4/%$;&H(#'&,&2#,#(0&%./#$&#.&#'$&:..3=,0>&."&#'$&*/,%;5&H'(0'&H(::&%$;(2#%(=/#$&#'(2&2#,#(0&%./#$&H(#'&

#'$&E*+&3%.#.0.:&JE9KE9&(-&#'$&$G,13:$L?&&M.#$&#',#&#'$&*/,%;&;.$2&-.#&%/-&E9KE9?&

&

N,0'&."&#'$2$&;$#$0#.%2&1.-(#.%2&#'$&3,0>$#&%,#$&,-;&0.13,%$2&(#&#.&#'$&3$,0$K#(1$&%,#$&J3%."(:$2&."&-.%1,:&

.%&#D3(0,:&=$',6(.%&=/(:#&=D&#'$&<(6$%'$,;&3%.;/0#2&;/%(-4&-.-K,##,0>&3$%(.;2L&.%&#.&,&#'%$2'.:;&2$#&

1,-/,::D&=D&#'$&/2$%?&

&

Difficulties

Again, upstream provider(s) still have to carry attack traffic

Now have to maintain n traffic models (or come up with a global representation for ‘normal’ traffic

Customers’ DDoS protection is now interrelated (More complex SLA and assurance necessary)

Firebreak

Fabulous!

Wonderful.

Have a good night. Drive safe.

Look, a bird!

But seriously...

Firebreak

Targets protected by group of boxes deployed near the edge - firebreaks

ISPs deploy firebreaks in POPs - as close to the customer as possible

Target’s IP address is not routable except from firebreak machines

How do clients connect?

Firebreak

Firebreak hosts map anycast firebreak addresses for each protected target to reachable target addresses (IP-level indirection)

Only packets from firebreak machines are routable to protected targets

Firebreaks are themselves firebreak-protected

Firebreak

Target is also protected by DDoS detector

Feedback is provided to firebreak nodes in the event of attack (handling is TBD and probably application-specific)

Target’s outbound traffic is a problem - how does the target communicate with other hosts (both protected and unprotected)?

FirebreakTwo possibilities:

Spoof source IP with firebreak anycast address

Could cause problems if edge routers are configured to drop spoofed packets

Tunnel all outbound traffic through a nearby firebreak

potential bottleneck / single point of failure

Firebreak

Client (S) addresses packets to nearby firebreak (FS) using anycast address for server T1

FS maps anycast address to privately address for T1.

T1 responds using anycast address as source, or routes response through firebreak

!"#$%&%

'()%'*+$,-.'/0%")$%1')$%2)"#1"-.,3% %454%6789%:";<";%

6=89%"/<%4.>%6?&8%"@@%)$A(.)$%(0$)0%-'%-)"B$)0$%"/%'B$)@";%

-C"-% 2)'B.<$0% 0'1$% D')1% 'D% 2)'-$,-.'/3% % E(-% -C$0$%

"22)'",C$0% )$A(.)$% $.-C$)% -C"-% -C$% -")#$-% F!% "<<)$00%

)$1"./%0$,)$-9%')%-C"-%-C$)$%.0%)'(-$)G*"0$<%2)'-$,-.'/%./%

-C$% B.,./.-;% 'D% -C$% -")#$-% -'% <$D$/<% "#"./0-% "--",H$)03%%

ID-$)% "@@9% "--",H$)0%C"B$%/'%1'-.B"-.'/% -'% -);% -'% )$",C%

-C$% -")#$-%B."% -C$%'B$)@";% J')%B."%K$*%2)'L.$09%"0%K.-C%

-C$% MNO% "22)'",CP3% % QC$;% ,"/% *;2"00% -C$% 'B$)@";%

J2)'L.$0P%*;%0$/<./#%2",H$-0%<.)$,-@;%-'%-C$%F!%"<<)$00%

'D% -C$% -")#$-3% % QC$% ")#(1$/-% -C"-% 454% "/<% :";<";%

1"H$% .0% -C"-% 0(,C% )'(-$)% D.@-$)./#% ,"/% *$% @.#C-K$.#C-%

"/<% -C$)$D')$%<$2@';$<% ./%C.#CG02$$<%,')$%)'(-$)09%*(-%

K$% )$1"./% 0'1$KC"-% 0H$2-.,"@% 'D% -C.0% ")#(1$/-3%%

R'(-$)0% ")$% C.#C@;% ,'/0-)"./$<% -'% <'% "% 1./.1(1%

"1'(/-% 'D% 2)',$00./#9% 0'% $B$/% )$@"-.B$@;% 0.12@$%

D.@-$)./#% .0% "% C")<% 0$@@3% % F/% "<<.-.'/9% -C$0$% 0,C$1$0%

)$A(.)$% ,C"/#$0% -'% @$#.-.1"-$% $/<C'0-0% -'% (0$% -C$%

'B$)@";03% % 6?&8% 0(##$0-0% "/% "@-$)/"-.B$% (0./#% F!G@$B$@%

./<.)$,-.'/%-'%"B'.<%,C"/#$0%-'%$/<C'0-09%"/<%.0%0.1.@")%

-'%D.)$*)$"H%./%-C.0%)$#")<3%%S'K$B$)9%-C$%"22)'",C%-C$;%

'(-@./$% )$A(.)$0%2$)GD@'K%0-"-$% "/<%OIQ%'2$)"-.'/0% ./%

$L.0-./#%$<#$%)'(-$)03%

!" #$%&'%&()"*%+,$-&+-.%&"

I0%0C'(@<%*$%"22")$/-%D)'1%-C$%"*'B$%<.0,(00.'/9%'/$%

'D%-C$%2).1");%#'"@0%'D%T.)$*)$"H%.0%-'%<$0.#/%"%NN'4%

<$D$/0$% -C"-% .0% <$2@';"*@$% ./% *'-C% "% -$,C/.,"@% !"#%

$,'/'1.,%0$/0$3%%Q'K")<0%-C.0%$/<9%K$%K"/-%"%0'@(-.'/%

-C"-% )$A(.)$0% /'% ,C"/#$0% -'% $/<C'0-0% ')% ,())$/-% )'(-$)%

0'D-K")$3% % % U$% K"/-% "% 0'@(-.'/% D')% KC.,C% "% B."*@$%

*(0./$00%1'<$@%$L.0-0%"/<%,"/%0(22')-%KC"-$B$)%./.-."@%

./D)"0-)(,-()$% ./B$0-1$/-0% ")$% /$,$00");3% % U$% "@0'%

)$,'#/.V$%-C"-%NN'4%.0%"/%")10%)",$!K$%<'/W-%$L2$,-%

"% 0.@B$)%*(@@$-3% %R"-C$)%K$%$L2$,-% -'%1"H$% -C$% ,'0-% 'D%

<$D$/<./#% "#"./0-% )$"0'/"*@$% "--",H0% "0% 01"@@% "0%

2'00.*@$% J"/<%,$)-"./@;%1(,C% 01"@@$)% -C"/% -C$%<"1"#$%

,"(0$<%*;%0(,C%"/%"--",HP3%%%

E$;'/<% -C.09% K$% -"H$% .-% "0% "% #.B$/% -C"-% -C$% 2'./-% 'D%

<$D$/0$9% -C"-% .0% -C$% *'L$0% KC$)$% "--",H% 2",H$-0% ")$%

D.@-$)$<9% 0C'(@<% *$% "0% /$")% -C$% 0'(),$% "0% 2'00.*@$3%%

QC$)$%")$%-K'%)$"0'/0%D')%-C.03%%T.)0-9%-C$%D()-C$)%"K";%

-C$% <$D$/0$% .0% D)'1% -C$% -")#$-9% -C$% 1')$% *"/<K.<-C%

-C$)$% .0% -'% "*0')*% -C$% "--",H3% %4$,'/<9% -C$%,@'0$)% $",C%

*'L%.0%-'%-C$%0'(),$9%-C$%D$K$)%0'(),$0%$",C%*'L%C"0%-'%

D.@-$)%"#"./0-3%%Q'K")<0%-C.0%$/<9%-C$%0'@(-.'/%0C'(@<%*$%

<$2@';"*@$%",)'00%1(@-.2@$% F4!03% %QC.0% ./% -()/0%1$"/0%

-C"-% 1./.1"@% ')% /'% ,'')<./"-.'/% *$% )$A(.)$<% *$-K$$/%

F4!0%<$2@';./#%-C$%0'@(-.'/3%%%

QC$%H$;%,'/,$2-%*$C./<%D.)$*)$"H%.0%-C$%(0$%'D%F!G@$B$@%

./<.)$,-.'/3% % QC$% *"0.,% .<$"% .0% -C"-% 0'(),$% $/<% C'0-0%

JD).$/<% "/<% D'$% "@.H$P% 0.12@;% ,"//'-% 0$/<% F!% 2",H$-0%

<.)$,-@;% -'% -")#$-%C'0-0% J$3#3% ./%T.#()$%?9%2",H$-0% D)'1%

C'0-% 4% "<<)$00$<% -'%Q?P3% % F!% )$",C"*[email protected];% 0.12@;% <'$0%

/'-% $L.0-!F!% 2",H$-0% "<<)$00$<% -'% -C$% -")#$-% ")$%

<)'22$<% *;% @$#",;% )'(-$)0% B$);% /$")% -C$% 0'(),$3%%

F/0-$"<9% 2",H$-0% 1(0-% *$% "<<)$00$<% -'% ./-$)1$<."-$%

*'L$09% ,"@@$<% $%&'(&'!)* (+,'-% J')% 1')$% -;2.,"@@;% +(0-%

$%&'(&'!)-P% <$2@';$<% /$")% -C$% $<#$3% % QC$% D.)$*)$"H0%

1"2% -C$0$% $%&'(&'!)* !##&'--'-% ./-'% -C$% .!&/'.*

!##&'--'-9% "/<% -(//$@% -C$% 2",H$-0% -'% -C$% -")#$-3% % T')%

./0-"/,$9%./%T.#()$%?9%4%"<<)$00$0%2",H$-0%-'%T?&9%KC.,C%

#$-0% <[email protected]$)$<% -'% "% /$")*;% D.)$*)$"H% JT4P3% % QC$%

D.)$*)$"H% 1"20% T?% ./-'% -C$% -")#$-% "<<)$00% Q?9% "/<%

-(//$@0% -C$% 2",H$-% -'% -C$% -")#$-% (0./#% .-0% 'K/% (/.,"0-%

"<<)$00%T4(%"0%-C$%0'(),$%"<<)$00%'D%-C$%'(-$)%C$"<$)3%%

FD% -C$% -")#$-% .-0$@D% .0% ./,"2"*@$% 'D% <$G-(//$@./#% -C$0$%

2",H$-09% "% 2)'L;% 2@",$<% ./% -C$% 2C;0.,"@% 2"-C% /$")% -C$%

-")#$-% ,"/% <'% .-% J')9% .D% /$,$00");9% -C$% D.)$*)$"H% ,'(@<%

OIQ% -C$% 2",H$-P3% % R$B$)0$% 2",H$-0% ",-("@@;% -"H$% "%

<.DD$)$/-%2"-C%*",H9%"0%$L2@"./$<%./%4$,-.'/%>3&3%

!"#$%"&'()

*) +*) ,-)

*.+-)*.)+-))+*/.,-)

+,)

+-.*)+-.*),-.0+10)

!23'42#)-()

+-.*)!23'42#)5()

!"#$%&'()'*+,-&./'0&.1&&2'23245%3.&,.&6'73/.'8'+26'

95%3.&,.&6:'.+%#&.';(<''=5."32'('"/'17&%&';(',+223.'

/533>'"./'/3$%,&'+66%&//?'35."32'@'"/'17&%&'".',+2<%

NN'4% 0+"%.+&% D(/,-.'/0% $L.0-0% "-% -C$% -")#$-% J-C'(#C%

D.)$*)$"H0% 1";% D$$<% 0-"-.0-.,0% -'% -C$% 1'/.-')0% -'% ".<%

-C$1P3% % O')1"@@;% D.)$*)$"H0% 0.12@;% 2"00% "@@% -)"DD.,% -'%

-C$% -")#$-3% % UC$/% "% 1'/.-')% <$-$,-0% "/% "--",H% ')% "/%

'B$)@'"<9% C'K$B$)9% .-% 0$/<0% ,'/-)'@% 1$00"#$0% -'% -C$%

"22)'2)."-$% D.)$*)$"H0% J$3#3% -'% "<<)$00% T(P% )$A($0-./#%

-C$%"22)'2)."-$%<$D$/0.B$%",-.'/%J@"-$)%K$%<.0,(00%KC"-%

-C.0%1";% *$P3% % F-%1";% -()/% '(-% D')% ./0-"/,$% -C"-% 0'1$%

D.)$*)$"H0% <'% /'-% C"B$% "/;% ')% 1"/;% "--",H$)0% *$C./<%

-C$19%"/<%-C$)$D')$%<'/W-%/$$<%-'%*$%-'@<%"/;-C./#3%

5D% ,'()0$9% K$% <'/W-% $L2$,-% -'% 0$$% D.)$*)$"H0%

.11$<."-$@;% <$2@';$<% "-% $B$);% $<#$% )'(-$)% ./% -C$%

F/-$)/$-9% 0'% K$% /$$<% "% 0-)"-$#;% D')% ./,)$1$/-"@%

<$2@';1$/-% 'D% D.)$*)$"H0% J",,$2-./#% -C"-% -C$% ./.-."@%

<$2@';1$/-% ./% "/;% $B$/-% 1(0-% *$% *.#% $/'(#C% "/<%

<.02$)0$% $/'(#C% -'% "*0')*% "% 0.V"*@$% "--",HP3% % T')% -C.09%

F!% "/;,"0-% .0% 2)'2'0$<% 6?X83% % I@@% D.)$*)$"H0% "<B$)-.0$%

-C$%,'12@$-$%0$-%'D%D.)$*)$"H%"<<)$00$0%./-'%-C$%)'(-./#%

D"*).,3%%I0%"%)$0(@-9%2",H$-0%"<<)$00$<%-'%"/;%D.)$*)$"H%

"<<)$00%")$%)'(-$<%-'%"%/$")*;%D.)$*)$"H3%%FD%"%D.)$*)$"H%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%&%S'0-%4%1";%C"B$%'*-"./$<%"<<)$00%T?% -C)'(#C%NO49%

D')%./0-"/,$3%

Firebreak

How do two protected hosts communicate? Via each other’s firebreak addresses

Neither side needs to know whether the other is protected

Requires firebreak handling of all traffic between protected hosts

!"#$%&%

$'()*+*,%-./0"/1*2#%,"3)$%$2,/*$4%-./%,5$%,"/#$,%(/$-*'$46%

37,% ,5$%("+8$,4% "/$% -./0"/1$1% ,.% "%3)"+8%5.)$9% %:*,5$/%

0";6% 4*2+$% ,5$% 2./<")% -./0"/1*2#% -72+,*.2% *4% 74$1% ,.%

(/$=$2,%"++$44% ,.% ,"/#$,46% ,5$%"++$44% /.7,$/4%.($/",$%",%

2./<")%-7))%4($$19%

>2% ,5$% ,5*/1% .(,*.26% -./0"/1*2#% /7)$4% "/$% 74$1% "4%

1$4+/*3$1% *2% ,5$% (/$=*.74% ("/"#/"(56% 37,% /",5$/% ,5"2%

",,"+5% ,5$% -*/$3/$"84% ,.% ,5$% +./$% /.7,$/46% ,5$;% "/$%

",,"+5$1%",%,5$%)*28%)";$/%,.%5*#5%4($$1%40*,+5$4%74$1%,.%

*2,$/+.22$+,% ,5$% ="/*.74% /.7,$/4%0*,5*2% ,5$%!?!9% %@5$%

"1="2,"#$% 5$/$% *4% ,5",% ,5$% -*/$3/$"84% +"2% 4$$% 05*+5%

"++$44% /.7,$/% 5"21)$1% ,5$% ("+8$,6% "21% 4.% 5"=$% 3$,,$/%

4.7/+$% 1*4+/*<*2",*.29% % A7),*()$% -*/$3/$"84% <";% 3$%

1$().;$1% ",% "% 4*2#)$% 40*,+5% ,5/.7#5% "2;% 27<3$/% .-%

,$+52*B7$4% C<"2*(7)",*2#% DEF!G% ,"3)$4% *2% ,5$% "++$44%

/.7,$/46%%,5/.7#5%HIEJ46%./%0*,5%"2%IK%)."1%3")"2+$/L9%%%

!"#$%&'"()*+,)-*./01*

M5*)$% ,5*4% ("($/% *4% (/*<"/*);% 0/*,,$2% 0*,5% >!=&% *2%

<*216% *,% *4% 0./,5% <$2,*.2*2#% ,5",% ,5$/$% *4% "% <.1$% .-%

.($/",*.2%0*,5% >!=N% C2.2% 4,"21"/1L% ,5",%0.7)1%#/$",);%

4*<()*-;% ,5$% -*/$3/$"89% % O($+*-*+"));6% ,5$% >!=N% "11/$44%

4("+$%+.7)1%3$%4()*,%*2%,0.6%5")-%-./%,"/#$,4%"21%5")-%-./%

-*/$3/$"846%0*,5% "% 4*<()$%<"((*2#% 3$,0$$2% ,5$<% C*9$9%

,5$% -)*((*2#% .-% "% 4*2#)$% 3*,L9% % @5*4%<"((*2#%0.7)1% 3$%

1$-*2$1% "4% "% 4,"21"/16% "21% +.1$1% *2,.% ,5$% -"4,% (",5% .-%

"++$44% /.7,$/49% % >2% ,5*4% <.1$)6% ,5$% 2$,0./8%

"1<*2*4,/",./%0.7)1%.2);%2$$1%,.%*1$2,*-;%,5$%+74,.<$/%

*2,$/-"+$4% .2% ,5$% "++$44% /.7,$/6% 05*+5% 0.7)1% ,5$2% 1.%

,5$%(/.($/%-*),$/*2#9%

!"#$ %&'()*$+,-.&*/$

J.0% 0$% #*=$% "% <./$% +.<()$,$% 1$4+/*(,*.2% .-% 5.0%

("+8$,4% "/$% -./0"/1$1% ,5/.7#5% -*/$3/$"849% % M$% 5"=$%

4$=$/")% /$B7*/$<$2,4% -./% .7/% "((/."+59% % P*/4,6% ,5$%

/$+*(*$2,%.-%"%("+8$,%<74,%82.0%,.%4$21%"%/$,7/2%("+8$,%

-/.<% *24($+,*2#% .2);% ,5$% +.2,$2,4% .-% ,5$% /$+$*=$1%

("+8$,9% %Q)$"/);% )$#"+;%5.4,4%<74,%3$%"3)$% ,.%1.%4.% *2%

,5$% 4,"21"/1%0";9% %O$+.216%"%(/.,$+,$1% ,"/#$,%<74,%3$%

"3)$% ,.% *2*,*",$% +.22$+,*.24% "21% 4,*))% /$<"*2%(/.,$+,$19%%

@5*/16% ,5$% /$+*(*$2,% .-% "% ("+8$,6% *-% "% (/.,$+,$1% ,"/#$,6%

<74,% )$"/2% ,5$% 72*+"4,% "11/$44% .-% ,5$% ,/"=$/4$1%

-*/$3/$"86% 4.% ,5",% *,% <";% 4$21% +.2,/.)% <$44"#$4% *-%

2$+$44"/;9%%P*2"));6%05$/$%(.44*3)$%,5$%"11/$44$4%.-%,5$%

*22$/% >!%5$"1$/%<74,%2.,%+5"2#$%:R:9% %@5$%$'+$(,*.2%

,.%,5*4%*4%05$/$%,5$%(/.,$+,$1%5.4,%*4%"%)$#"+;%5.4,6%"21%

"2% *2S,5$S(",5% (/.';% ,/"24)",$4% ,5$% 5$"1$/49% % @5$%

/$<"*2*2#%1$4+/*(,*.2%"447<$4%2.%47+5%(/.';9%

@.% "++.<()*45% ,5$4$% #.")46% (/.,$+,$1% 5.4,4% ")0";4%

,/"24<*,4% ("+8$,4% 0*,5% ,5$*/% -*/$3/$"8% "11/$44% "4% ,5$%

4.7/+$% "11/$449% % >-% ,5$% (/.,$+,$1% 5.4,% *4% 2.,% "3)$% ,.%

4(..-% *,4%4.7/+$%"11/$44%C-./% *24,"2+$%3$+"74$%"2%$1#$%

/.7,$/% 1/.(4% 4.7/+$% 4(..-$1% ("+8$,4L6% ,5$2% *,% <74,%

,722$)% *,4% ("+8$,4% ,.% "% 2$"/3;% -*/$3/$"8% C.(,*.2% T% *2%

3.,5% P*#7/$% T% "21% P*#7/$% KL9% % >,% +"2% 1.% ,5*4% 3;%

,/"24<*,,*2#% ,5$% ,722$)$1%("+8$,% ,.%"%#$2$/*+%-*/$3/$"8%

"11/$44%C45.02%"4%DPUGL9%

!"#$%"&'()

*+) ,+) *-),+.),-)),+/.*-)

,-)

,-.),+)*-.0,10)

!23'42#)-()

,+.),-)*+.0,10)

,-.),+),-/.*+)

,-.),+)!23'42#)+()

,-.),+),-/.*+)

2,345"* 67* * /89:");* <")+""(* )+%* #5%)"9)"=* -%;);>**

?#),%(* @* ,;* +-"5"* A@* 98((%)* ;"(=* ;%459"* ;#%%B"=*

#89:");>* * ?#),%(* C* ,;* +-"5"* ,)* 98(>* * DA-"* ;8'"*

8##$,";*)%*AC>E*

M5$2% "% -*/$3/$"8% /$+$*=$4% "% ("+8$,% -/.<% "% (/.,$+,$1%

5.4,%-./%"%2.2S(/.,$+,$1%5.4,6%*,%4*<();%4,/*(4%,5$%.7,$/%

5$"1$/% "21% -./0"/14% ,5$% ("+8$,% CP*#7/$% TL9% % M5$2% "%

-*/$3/$"8% ,/"24<*,4% "% ("+8$,% ,.% "% (/.,$+,$1% 5.4,6% ,5$%

*22$/% 5$"1$/% *4% ,5$% 4"<$% "4% ,5",% /$+$*=$19% % @5$%

1$4,*2",*.2%>!%"11/$44%*2%,5$%.7,$/%5$"1$/%*4%,5",%.-%,5$%

,"/#$,% 5.4,6% "4% <"(($1% -/.<% ,5$% /$+$*=$1% -*/$3/$"8%

"11/$449% %@5$%4.7/+$% >!%"11/$44% *2% ,5$%.7,$/%5$"1$/% *4%

,5$% 72*B7$% 72*+"4,% "11/$44% .-% ,5$% -*/$3/$"89% % @5*4% *4%

4,./$1% 3;% ,5$% ,"/#$,% 5.4,% C./% "% <.2*,./% "+,*2#% .2% *,4%

3$5")-L%,.%)",$/%4$21%+.2,/.)%<$44"#$4%,.%,5$%-*/$3/$"89%%

J.,$% ,5",% -*/$3/$"84% +"2% "21% (/$47<"3);% 0.7)1% 3$%

,5$<4$)=$4%(/.,$+,$1%3;%,5$%-*/$3/$"86%4.%,5$%>!%"11/$44%

,5$;% 74$% *4% "+,7"));% ,5$*/% 72*B7$% "2;+"4,% -*/$3/$"8%

"11/$449%

I..8*2#% ",% P*#7/$% T% "21% P*#7/$% K6% *,% 45.7)1% 3$% +)$"/%

,5",%$*,5$/%$21%+.7)1%5"=$%*2*,*",$1%,5$%("+8$,%$'+5"2#$%

0*,5% ,5$% 5$"1$/4% 45.029% % J.,$% ")4.% ,5",% "% (/.,$+,$1%

5.4,6% "4% "2% *2*,*",./6% 1.$4% 2.,% 2$$1% ,.% 82.0% *-% ,5$%

1$4,*2",*.2% *4% "% (/.,$+,$1% 5.4,% ./% 2.,9% % @5$% -*/$3/$"8%

<74,%82.06%37,% -*/$3/$"84%"/$% /$B7*/$1% ,.%82.0%$=$/;%

<"((*2#%*2%"2;%$=$2,9%

P*2"));6% 0$% 2.,$% ,5",% ,5*4% 4,;)$% .-% $2+"(47)",*.2%

/$B7*/$4%,5",%"))%.-%"%(/.,$+,$1%5.4,V4%,/"--*+%#.%,5/.7#5%

2$"/3;% -*/$3/$"84 ! "% (.,$2,*")% 3.,,)$2$+89% % P./%

+.<<72*+",*.24% 0*,5% 2.2S(/.,$+,$1% 5.4,4% CP*#7/$% TL6%

,5*4% +"2% 3$% "=.*1$1% *2% +"4$4% 05$/$% ,5$% ,"/#$,% +"2%

,/"24<*,%("+8$,4%0*,5%4(..-$1%4.7/+$%"11/$44$46%05*+5%

*2%<"2;%37,%($/5"(4%2.,%"))%+"4$4%+.7)1%3$%"//"2#$19%%%

!"!$ 01-)2-)&($3,4*-,5$

E4% 1*4+744$1% (/$=*.74);6% -*),$/*2#% /7)$4% *2% -*/$3/$"84%

"/$%+.2,/.))$1%3;%<.2*,./4%",%,5$%,"/#$,9%%O($+*-*+"));6%"%

#*=$2% ,"/#$,% @T% 5"4% ,5$% "7,5./*,;% ,.% *24,"))% -*/$3/$"8%

/7)$4%,5",%/$)",$%,.%*,4$)-6%37,%1.$4%2.,%5"=$%,5$%"7,5./*,;%

A Few IssuesAll minor. Really!

Two addresses per target (not a problem with IPv6)

Anycast isn’t widely deployed - significant infrastructure to design/test/implement

(and/or convince Akamai)

Scaling issues (esp. with outbound traffic tunneling)

A Few IssuesHigh degree of complexity

Many moving parts over WAN

Interactions between multiple firebreaks, targets, DDoS detectors, &c.

Do ASes interact with each other’s firebreak systems?

Isolation of DDoS sources still difficult

Compare and ContrastBoth solutions use routing to protect the target from attack

Riverhead approach still makes server IP public

Does not require extra processing of outbound traffic

Non-flooding attacks may not be detected

Firebreak can protect from all IP attacks

Compare and Contrast

Riverhead attempts to put prevention logic close to the destination; Firebreak pushes it out (near) to the source

Firebreak is better for overall network utilization

Both solutions have separate detection and control components

Other Solutions: AkamaiOrigin server IP address kept secret

Security through obscurity!

Two tiers of DNS

Dozens (?) of top tier servers, reached by IP anycast. Large TTL.

Thousands (?) of second tier servers. Small TTL.

This is “quite good” protection ** http://www.cs.cornell.edu/People/francis/firebreak/firebreak-june-04-v2.pdf. All conclusions theoretic.

Other Solutions: Akamai

Potential problems:

Attack origin servers by discovering IP address(es)

“Static” content cached at Akamai proxies ok

Akamai could reconfigure those addresses...

Other Solutions: Akamai

Potential Problems (cont.):

Sustained attack on top tier of DNS

But ISPs can traceback attackers and install filters on timescale of hours

But if this attack succeeds, all Akamai customers are denied service!

Questions?

Sources

http://sfs.poly.edu/presentations/Crash_Course_in_DDoS.ppt

http://staff.washington.edu/dittrich/I2-ddos.ppt

http://www.cs.cornell.edu/people/francis/firebreak/firebreak-june-04-v2.pdf

Documents

Distributed Denial of Service Attacks - Cornell University · 2004-11-02 · Distributed Denial of Service Attacks ... A Brief Introduction What is a DoS Attack? A explicit attempt