Denial of Service - PowerPoint Presentation

Slide1

Denial of ServiceSlide2

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 stopsSlide3

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 approachSlide4

High-level Attack Categorization

Floods

Congestion control exploits

Unexpected header values

Invalid content

Invalid fragments

Large packets

Impersonation attacksSlide5

Simple Denial of Service

5Slide6

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

serverSlide7

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 effectSlide8

DDoS “Solves” That Problem

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 machineSlide9

Distributed

Denial-of-Service

Slide10

Typical Attack Modus OperandiSlide11

Is DDoS a Real Problem?

Yes, attacks happen every day

One study reported ~4,000 per week

1

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, 2002Slide12

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

NetworksSlide13

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 affectedSlide14

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” movieSlide15

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 attackSlide16

Who Is Vulnerable?

Everyone connected to the Internet can be attacked

Everyone who uses Internet for crucial operations can suffer damagesSlide17

But My Machines Are Well Secured!

17

Doesn’t matter!

The problem isn’t your vulnerability, it’s everyone

elses

’Slide18

But I Have a Firewall!

Doesn’t matter!

Either the attacker slips his traffic into legitimate traffic

Or he attacks the firewallSlide19

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 workSlide20

But I’m Heavily Provisioned

Doesn’t matter!

The attacker can probably get enough resources to overcome any level of resources you buySlide21

Attack Toolkits

Widely available on the net

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 codeSlide22

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 slavesSlide23

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 playSlide24

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 recruitmentSlide25

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 cheatsSlide26

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 itSlide27

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 deploySlide28

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 simpleSlide29

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 properSlide30

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 usersSlide31

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 discoveredSlide32

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 securitySlide33

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 wellSlide34

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 machinesSlide35

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 machineSlide36

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 callSlide37

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 advantageSlide38

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 zombiesSlide39

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 secrecySlide40

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 techniquesSlide41

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 Slide42

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 everythingSlide43

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 littleSlide44

Where Do You Filter?

Near the target?

Near the source?

In the network core?

In multiple places?Slide45

Filtering

Location Choices

Near target

Near source

In coreSlide46

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 coreSlide47

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 coreSlide48

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 attackSlide49

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 specificationSlide50

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 behaviorSlide51

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 targetSlide52

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 memorySlide53

TCP SYN Cookies

Effective defense against TCP SYN flood

Victim encodes connection information and time in ACK number

Must be hard to

craft values that get encoded into the same ACK 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 repeatedSlide54

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 loadSlide55

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 changedSlide56

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 usersSlide57

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 attackSlide58

Sample Research

Defenses

Pushback

Traceback

SOS

Proof-of-work

systems

Human behavior modelingSlide59

Pushback

1

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

1

”Controlling high bandwidth aggregates in the network,”

Mahajan, Bellovin, Floyd, Paxson, Shenker, ACM CCR, July 2002Slide60

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 trafficSlide61

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

separableRequires modification of existing core

routers61Slide62

Traceback

1

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

1

“Practical network support for IP Traceback,” Savage, Wetherall, Karlin, Anderson,

ACM SIGCOMM 2000Slide63

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 trafficSlide64

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 damageSlide65

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

expensiveSlide66

SOS

1

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

66

1

“ SOS: Secure Overlay Services

,

” Keromytis, Misra, Rubensteain, ACM SIGCOMM 2002Slide67

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

firewallFirewall 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 servletsIf a node fails, other nodes can take its role

67Slide68

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

68Slide69

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

69Slide70

Client Puzzles

1

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

70

1

“Client puzzles: A cryptographic countermeasure against connection depletion attacks

,

” Juels, Brainard, NDSS 1999Slide71

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

71Slide72

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)

72