1. Denial of Service

2. Denial of Service Attacks
Unlike other forms of computer attacks, goal isn’t access or theft of information or services
The goal is to stop the service from operating
To deny service to legitimate users
Slowing down may be good enough
This is usually a temporary effect that passes as soon as the attack stops

3. How Can a Service Be Denied?
Lots of ways
Crash the machine
Or put it into an infinite loop
Crash routers on the path to the machine
Use up a key machine resource
Use up a key network resource
Deny another service needed for this one (DNS)
Using up resources is the most common approach

4. High-level Attack Categorization
Floods
Congestion control exploits
Unexpected header values
Invalid content
Invalid fragments
Large packets
Impersonation attacks

5. Simple Denial of Service

6. Simple Denial of Service
One machine tries to bring down another machine
There is a fundamental problem for the attacker:
The attack machine must be “more powerful” than the target machine to overload it OR
Attacker uses approaches other than flooding
The target machine might be a powerful server

7. Denial of Service and Asymmetry
Sometimes generating a request is cheaper than formulating a response e.g. sending a bogus packet is cheaper than decrypting this packet and checking that it’s bogus
If so, one attack machine can generate a lot of requests, and effectively multiply its power
Not always possible to achieve this asymmetry
This is called amplification effect

8. DDoS – Distributed DoS Use multiple machines to generate the workload
For any server of fixed power, enough attack machines working together can overload it
Enlist lots of machines and coordinate their attack on a single machine

9. Distributed Denial-of-Service

10. Typical Attack Modus Operandi

11. Is DDoS a Real Problem? Yes, attacks happen every day
One study reported ~4,000 per week1
On a wide variety of targets
Tend to be highly successful
There are very few mechanisms that can stop certain attacks
There have been successful attacks on major commercial sites
1”Inferring Internet Denial of Service Activity,” Moore, Voelker, and Savage, Usenix Security Symposium, 2002

12. DDoS on Twitter August 2009, hours-long service outage
44 million users affected
At the same time Facebook, LiveJournal, YouTube and Blogger were under attack
Only some users experienced an outage
Real target: a Georgian blogger
Image borrowed from Wired.com article. Originally provided by Arbor Networks

13. DDoS on Mastercard and Visa
December 2010
Parts of services went down briefly
Attack launched by a group of vigilantes called Anonymous
Bots recruited through social engineering
Directed to download DDoS software and take instructions from a master
Motivation: Payback to services that cut their support of WikiLeaks after their founder was arrested on unrelated charges
Several other services affected

14. DDoS on US Banks September 2012
BofA, Chase and Wells Fargo were among those attacked
Services were interrupted
Attack claimed to be launched by a Muslim group Izz ad-Din al Qassam Cyber Fighters
Motivation: outrage about “Innocence of Muslims” movie

15. DDoS on SpamHaus March 2013 attack on spam blacklisting service
Flood SpamHaus servers using DDoS reflector attack with amplification (explained later)
SpamHaus used CloudFlare to distribute its content – attackers attacked CloudFlare, and then their peers
From 10 to 300 Gbps, lasted several days, knocked out SpamHaus and created congestion in the Internet
Motiv: attackers claimed that Spamhaus

16. DDoS on BBC Web site Xmas Eve 2015 attack flooding with 600 Gbps
At the same time Donald Trump’s Web site was attacked
Brought down with much smaller vlume
New World Hacking claimed responsibility
Proof of concept attack “to show we can”
Site offline at least 3 hours
Allegedly used Amazon’s machines

17. Potential Effects of DDoS Attacks
Most (if not all) sites could be rendered non-operational
The Internet could be largely flooded with garbage traffic
Essentially, the Internet could grind to a halt
In the face of a very large attack
Almost any site could be put out of business
With a moderate sized attack

18. Who Is Vulnerable? Everyone connected to the Internet can be attacked
Everyone who uses Internet for crucial operations can suffer damages

19. But My Machines Are Well Secured!
Doesn’t matter!
The problem isn’t your vulnerability, it’s everyone elses’

20. But I Have a Firewall!
Either the attacker slips his traffic into legitimate traffic
Doesn’t matter!
Or he attacks the firewall

21. But I Use a VPN! Doesn’t matter!
The attacker can fill your tunnel with garbage
Sure, you’ll detect it and discard it . . .
But you’ll be so busy doing so that you’ll have no time for your real work

22. But I’m Heavily Provisioned
Doesn’t matter!
The attacker can probably get enough resources to overcome any level of resources you buy

23. Attack Toolkits Widely available on the net Automated code for:
Easily downloaded along with source code
Easily deployed and used
Automated code for:
Scanning – detection of vulnerable machines
Exploit – breaking into the machine
Infection – placing the attack code
Rootkits
Hide the attack code
Restart the attack code
Keep open backdoors for attacker access
DDoS attack code

24. DDoS Attack Code Attacker can customize: Type of attack
UDP flood, ICMP flood, TCP SYN flood, Smurf attack (broadcast ping flood)
Web server request flood, authentication request flood, DNS flood
Victim IP address
Duration
Packet size
Source IP spoofing
Dynamics (constant rate or pulsing)
Communication between master and slaves

25. Implications Of Attack Toolkits
You don’t need much knowledge or great skills to perpetrate DDoS
Toolkits allow unsophisticated users to become DDoS perpetrators in little time
DDoS is, unfortunately, a game anyone can play

26. DDoS Attack Trends
Attackers follow defense approaches, adjust their code to bypass defenses
Use of subnet spoofing defeats ingress filtering
Use of encryption and decoy packets, IRC or P2P obscures master-slave communication
Encryption of attack packets defeats traffic analysis and signature detection
Pulsing attacks defeat slow defenses and traceback
Flash-crowd attacks generate legitimate (well-formed) application traffic
Social-network recruitment

27. How Come We Have DDoS?
Natural consequence of the way Internet is organized
Best effort service means routers don’t do much processing per packet and store no state – they will let anything through
End to end paradigm means routers will enforce no security or authentication – they will let anything through
It works real well when both parties play fair
It creates opportunity for DDoS when one party cheats

28. There Are Still No Strong Defenses Against DDoS
You can make yourself harder to attack
But you can’t make it impossible
And, if you haven’t made it hard enough, there’s not much you can do when you are attacked
There are no patches to apply
There is no switch to turn
There might be no filtering rule to apply
Grin and bear it

29. Why Is DDoS Hard to Solve?
A simple form of attack
Designed to prey on the Internet’s strengths
Easy availability of attack machines
Attack can look like normal traffic
Lack of Internet enforcement tools
Hard to get cooperation from others
Effective solutions hard to deploy

30. 1. Simplicity Of Attack Basically, just send someone a lot of traffic
More complicated versions can add refinements, but that’s the crux of it
No need to find new vulnerabilities
No need to worry about timing, tracing, etc.
Toolkits are readily available to allow the novice to perform DDoS
Even distributed parts are very simple

31. 2. Preys On Internet’s Strengths
The Internet was designed to deliver lots of traffic
From lots of places, to lots of places
DDoS attackers want to deliver lots of traffic from lots of places to one place
Any individual packet can look proper to the Internet
Without sophisticated analysis, even the entire flow can appear proper

32. Internet Resource Utilization
Internet was not designed to monitor resource utilization
Most of it follows first come, first served model
Many network services work the same way
And many key underlying mechanisms do, too
Thus, if a villain can get to the important resources first, he can often deny them to good users

33. 3. Availability Of Attack Machines
DDoS is feasible because attackers can enlist many machines
Attackers can enlist many machines because many machines are readily vulnerable
Not hard to find 1,000 crackable machines on the Internet
Particularly if you don’t care which 1,000
Botnets numbering hundreds of thousands of hosts have been discovered

34. Can’t We Fix These Vulnerabilities?
DDoS attacks don’t really harm the attacking machines
Many people don’t protect their machines even when the attacks can harm them
Why will they start protecting their machines just to help others?
Altruism has not yet proven to be a compelling argument for for network security

35. 4. Attacks Resemble Normal Traffic
A DDoS attack can consist of vast number of requests for a web server’s home page
No need for attacker to use particular packets or packet contents
So neat filtering/signature tools may not help
Attacker can be arbitrarily sophisticated at mirroring legitimate traffic
In principle
Not often done because dumb attacks work so well

36. 5. Lack Of Enforcement Tools
DDoS attackers have never been caught by tracing or observing attack
Only by old-fashioned detective work
Really, only when they’re dumb enough to boast about their success
The Internet offers no help in tracing a single attack stream, much less multiple ones
Even if you trace them, a clever attacker leaves no clues of his identity on those machines

37. What Is the Internet Lacking?
No validation of IP source address
No enforcement of amount of resources used
No method of tracking attack flows
Or those controlling attack flows
No method of assigning responsibility for bad packets or packet streams
No mechanism or tools for determining who corrupted a machine

38. 6. Poor Cooperation In the Internet
It’s hard to get anyone to help you stop or trace or prevent an attack
Even your ISP might not be too cooperative
Anyone upstream of your ISP is less likely to be cooperative
ISPs more likely to cooperate with each other, though
Even if cooperation occurs, it occurs at human timescales
The attack might be over by the time you figure out who to call

39. 7. Effective Solutions Hard To Deploy
The easiest place to deploy defensive systems is near your own machine
Defenses there might not work well (firewall example)
There are effective solutions under research
But they require deployment near attackers or in the Internet core
Or, worse, in many places
A working solution is useless without deployment
Hard to get anything deployed if deploying site gets no direct advantage

40. Resource Limitations
Don’t allow an individual attack machine to use many of a target’s resources
Requires:
Authentication, or
Making the sender do special work (puzzles)
Authentication schemes are often expensive for the receiver
Existing legitimate senders largely not set up to handle doing special work
Can still be overcome with a large enough army of zombies

41. Hiding From the Attacker
Make it hard for anyone but legitimate clients to deliver messages at all
E.g., keep your machine’s identity obscure
A possible solution for some potential targets
But not for others, like public web servers
To the extent that approach relies on secrecy, it’s fragile
Some such approaches don’t require secrecy

42. Resource Multiplication
As attacker demands more resources, supply them
Essentially, never allow resources to be depleted
Not always possible, usually expensive
Not clear that defender can keep ahead of the attacker
But still a good step against limited attacks
More advanced versions might use Akamai-like techniques

43. Trace and Stop Attacks Figure out which machines attacks come from
Go to those machines (or near them) and stop the attacks
Tracing is trivial if IP source addresses aren’t spoofed
Tracing may be possible even if they are spoofed
May not have ability/authority to do anything once you’ve found the attack machines
Not too helpful if attacker has a vast supply of machines

44. Filtering Attack Streams
The basis for most defensive approaches
Addresses the core of the problem by limiting the amount of work presented to target
Key question is:
What do you drop?
Good solutions drop all (and only) attack traffic
Less good solutions drop some (or all) of everything

45. Filtering Vs. Rate Limiting
Filtering drops packets with particular characteristics
If you get the characteristics right, you do little collateral damage
At odds with the desire to drop all attack traffic
Rate limiting drops packets on basis of amount of traffic
Can thus assure target is not overwhelmed
But may drop some good traffic
You can combine them (drop traffic for which you are sure is suspicious, rate-limit the rest) but you gain a little

46. Where Do You Filter? In multiple places? In the network core?
Near the source?
Near the target?

47. Filtering Location Choices
Near target
Near source
In core

48. Filtering Location Choices
Near target
Easier to detect attack
Sees everything
May be hard to prevent collateral damage
May be hard to handle attack volume
Near source
In core

49. Filtering Location Choices
Near target
Near source
May be hard to detect attack
Doesn’t see everything
Easier to prevent collateral damage
Easier to handle attack volume
In core

50. Filtering Location Choices
Near target
Near source
In core
Easier to handle attack volume
Sees everything (with sufficient deployment)
May be hard to prevent collateral damage
May be hard to detect attack

51. How Do You Detect Attacks?
Have database of attack signatures
Detect anomalous behavior
By measuring some parameters for a long time and setting a baseline
Detecting when their values are abnormally high
By defining which behavior must be obeyed starting from some protocol specification

52. How Do You Filter?
Devise filters that encompass most of anomalous traffic
Drop everything but give priority to legitimate-looking traffic
It has some parameter values
It has certain behavior

53. DDoS Defense Challenges
Need for a distributed response
Economic and social factors
Lack of detailed attack information
Lack of defense system benchmarks
Difficulty of large-scale testing
Moving target

54. TCP SYN Flood Attacker sends lots of TCP SYN packets
Victim sends an ack, allocates space in memory
Attacker never replies
Goal is to fill up memory before entries time out and get deleted
Usually spoofed traffic
Otherwise patterns may be used for filtering
OS at the attacker or spoofed address may send RST and free up memory

55. TCP SYN Cookies Effective defense against TCP SYN flood
Victim encodes connection information and time in SEQ number for the server
Must be hard to craft values that get encoded into the same SEQ number – use crypto for encoding
Memory is only reserved when final ACK comes
Only the server must change
But TCP options are not supported
And lost SYN ACKs are not repeated

56. Small-Packet Floods Overwhelm routers
Create a lot of pps
Exhaust CPU
Most routers can’t handle full bandwidth’s load of small packets
No real solution, must filter packets somehow to reduce router load

57. Shrew Attack
Periodically slam the victim with short, high-volume pulses
Lead to congestion drops on client’s TCP traffic
TCP backs off
If loss is large back off to 1 MSS per RTT
Attacker slams again after a few RTTs
Solution requires TCP protocol changes
Tough to implement since clients must be changed

58. Flash-Crowd Attack
Generate legitimate application traffic to the victim
E.g., DNS requests, Web requests
Usually not spoofed
If enough bots are used no client appears too aggressive
Really hard to filter since both traffic and client behavior seem identical between attackers and legitimate users

59. Reflector Attack
Generate service requests to public servers spoofing the victim’s IP
Servers reply back to the victim overwhelming it
Usually done for UDP and ICMP traffic (TCP SYN flood would only overwhelm CPU if huge number of packets is generated)
Often takes advantage of amplification effect – some service requests lead to huge replies; this lets attacker amplify his attack

60. Sample Research Defenses
Pushback
Traceback
SOS
Proof-of-work systems
Human behavior modeling
SENSS

61. Pushback1
1”Controlling high bandwidth aggregates in the network,” Mahajan, Bellovin, Floyd, Paxson, Shenker, ACM CCR, July 2002
Goal: Preferentially drop attack traffic to relieve congestion
Local ACC: Enable core routers to respond to congestion locally by:
Profiling traffic dropped by RED
Identifying high-bandwidth aggregates
Preferentially dropping aggregate traffic to enforce desired bandwidth limit
Pushback: A router identifies the upstream neighbors that forward the aggregate traffic to it, requests that they deploy rate-limit

62. Can it Work?
Even a few core routers are able to control high-volume attacks
Separation of traffic aggregates improves current situation
Only traffic for the victim is dropped
Drops affect a portion containing the attack traffic
Likely to successfully control the attack, relieving congestion in the Internet
Will inflict collateral damage on legitimate traffic

63. Advantages and Limitations
Routers can handle high traffic volumes
Deployment at a few core routers can affect many traffic flows, due to core topology
Simple operation, no overhead for routers
Pushback minimizes collateral damage by placing response close to the sources
Pushback only works in contiguous deployment
Collateral damage is inflicted by response, whenever attack is not clearly separable
Requires modification of existing core routers

64. Traceback1 Goal: locate the agent machines
1“Practical network support for IP Traceback,” Savage, Wetherall, Karlin, Anderson, ACM SIGCOMM 2000
Goal: locate the agent machines
Each packet header may carry a mark, containing:
EdgeID (IP addresses of the routers) specifying an edge it has traversed
The distance from the edge
Routers mark packets probabilistically
If a router detects half-marked packet (containing only one IP address) it will complete the mark
Victim under attack reconstructs the path from the marked packets

65. Traceback and IP Spoofing
Traceback does nothing to stop DDoS attacks
It only identifies attackers’ true locations
Comes to a vicinity of attacker
If IP spoofing were not possible in the Internet, traceback would not be necessary
There are other approaches to filter out spoofed traffic

66. Can it Work?
Incrementally deployable, a few disjoint routers can provide beneficial information
Moderate router overhead (packet modification)
A few thousand packets are needed even for long path reconstruction
Does not work well for highly distributed attacks
Path reassembly is computationally demanding, and is not 100% accurate:
Path information cannot be used for legal purposes
Routers close to the sources can efficiently block attack traffic, minimizing collateral damage

67. Advantages and Limitations
Incrementally deployable
Effective for non-distributed attacks and for highly overlapping attack paths
Facilitates locating routers close to the sources
Packet marking incurs overhead at routers, must be performed at slow path
Path reassembly is complex and prone to errors
Reassembly of distributed attack paths is prohibitively expensive

68. SOS1
1“ SOS: Secure Overlay Services,” Keromytis, Misra, Rubensteain, ACM SIGCOMM 2002
Goal: route only “verified user” traffic to the server, drop everything else
Clients use overlay network to reach the server
Clients are authenticated at the overlay entrance, their packets are routed to proxies
Small set of proxies are “approved” to reach the server, all other traffic is heavily filtered out

69. SOS
User first contacts nodes that can check its legitimacy and let him access the overlay – access points
An overlay node uses Chord overlay routing protocol to send user’s packets to a beacon
Beacon sends packets to a secret servlet
Secret servlets tunnel packets to the firewall
Firewall only lets through packets with an IP of a secret servlet
Secret servlet’s identity has to be hidden, because their source address is a passport for the realm beyond the firewall
Beacons are nodes that know the identity of secret servlets
If a node fails, other nodes can take its role

70. Can It Work?
SOS successfully protects communication with a private server:
Access points can distinguish legitimate from attack communications
Overlay protects traffic flow
Firewall drops attack packets
Redundancy in the overlay and secrecy of the path to the target provide security against DoS attacks on SOS

71. Advantages And Limitations
Ensures communication of “verified user” with the victim
Resilient to overlay node failure
Resilient to DoS on the defense system
Does not work for public service
Traffic routed through the overlay travels on suboptimal path
Brute force attack on links leading to the firewall still possible

72. Client Puzzles1 Goal: defend against connection depletion attacks
1“Client puzzles: A cryptographic countermeasure against connection depletion attacks,” Juels, Brainard, NDSS 1999
Goal: defend against connection depletion attacks
When under attack:
Server distributes small cryptographic puzzles to clients requesting service
Clients spend resources to solve the puzzles
Correct solution, submitted on time, leads to state allocation and connection establishment
Non-validated connection packets are dropped
Puzzle generation is stateless
Client cannot reuse puzzle solutions
Attacker cannot make use of intercepted packets

73. Can It Work?
Client puzzles guarantee that each client has spent a certain amount of resources
Server determines the difficulty of the puzzle according to its resource consumption
Effectively server controls its resource consumption
Protocol is safe against replay or interception attacks
Other flooding attacks will still work

74. Advantages And Limitations
Forces the attacker to spend resources, protects server resources from depletion
Attacker can only generate a certain number of successful connections from one agent machine
Low overhead on server
Requires client modification
Will not work against highly distributed attacks
Will not work against bandwidth consumption attacks (Defense By Offense paper changes this)

75. Human Behavior Modeling1
1“Modeling Human Behavior for Defense Against Flash Crowd Attacks”, Oikonomou, Mirkovic 2009.
Goal: defend against flash-crowd attacks on Web servers
Model human behavior along three dimensions
Dynamics of interaction with server (trained)
Detect aggressive clients as attackers
Semantics of interaction with server (trained)
Detect clients that browse unpopular content or use unpopular paths as attackers
Processing of visual and textual cues
Detect clients that click on invisible or uninteresting links as attackers

76. Can It Work? Attackers can bypass detection if they
Act non-aggressively
Use each bot for just a few requests, then replace it
But this forces attacker to use many bots
Tens to hundreds of thousands
Beyond reach of most attackers
Other flooding attacks will still work

77. Advantages And Limitations
Transparent to users
Low false positives and false negatives
Requires server modification
Server must store data about each client
Will not work against other flooding attacks
May not protect services where humans do not generate traffic, e.g., DNS

78. SENSS: Security as a Service1
1“Software-Defined Security Service”, Yu, Zhang, Mirkovic, Alwabel, 2014.
Goal: enable victim networks to request monitoring and traffic/route control from remote network
ISPs already support this through human channels
Software-Defined Networking (SDN) enables automated support
Networks can only ask about their prefixes
ISPs can charge for service

79. Can It Work? Attackers cannot forge queries or replies
Misbehaving ISPs cannot do anything worse than they can today
Small deployment ( core networks) can protect a large number of victims
Attacks handled:
DDoS-with-signature
DDoS-without-signature (spoofed traffic)
Crossfire DDoS
Route blackholing
Route diversion

80. Advantages And Limitations
Easily supported by today’s router capabilities
Can handle a variety of attacks
Good economic model
Requires inter-network collaboration
Requires deployment at Internet core
Requires minor changes at routers