02/25/02ddos/traceback-characterisation ozgur ozturk 1 ddos/traceback paper group # 23:...

02/25/02 DDoS/Traceback-Characterisation Ozgur Ozturk

1

DDoS/TracebackPaper Group # 23: Characterization

Ozgur OzturkCSE 581 - W02

Internet Technologies

Instructed by Wu-chang Feng


2

Paper List

• “Inferring Internet Denial-of-Service Activity” [MOORE]– D. Moore @ CAIDA– G. Voelker, S. Savage @ UCSD – 2001 USENIX Security Symposium


3

• Underlying Mechanisms of DoS Attacks

• The Backscatter Analysis Technique

• Techniques for classifying attacks

• Validation

• Observations and Results

• Conclusions

Moore

Outline


4

Moore

Abstract• Backscatter analysis provides quantitative data for a

global view on DoS activity using local monitoring• Videos

• Traffic Characterisation (How Data Gathered)– http://www.caida.org/outreach/resources/animations/passive_monit

oring/traffic_char.mpg (1min12s)

• TCP Port Analysis – http://www.caida.org/outreach/resources/animations/passive_monit

oring/tcp_port_analysis.mpg (2min15s)

• Backscatter– http://www.caida.org/outreach/resources/animations/passive_monit

oring/backscatter.mpg (1min26)

http://www.caida.org/outreach/resources/animations/passive_monitoring/traffic_char.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/traffic_char.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/tcp_port_analysis.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/tcp_port_analysis.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/backscatter.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/backscatter.mpg


5

Moore

DoS Attacks Background

• Logic Attacks– Exploit Software Flaws– e.g. Ping of Death

• Flooding Attacks– Overwhelm CPU, Memory, Bandwidth– e.g. SYN flood, ICMP flood


6

Flooding Attacks- Backscatter

• Attackers spoof source address randomly– Small frequent packets. (packet/sec bottleneck)– e.g. TCP SYN -> victim allocate data structure

for arriving packets (for unmatched to existing connections)

• Victims, in turn, respond to attack packets

• Remotely controlled “Zombies” for DDoS


7

Randomness in IP addresses

• Unsolicited responses (backscatter) equally distributed across IP space

• Received backscatter is evidence of an attacker elsewhere


8

From caida page


9

From caida page


10

Assumptions

• Address Uniformity• Reliable delivery

– Backscatter not lost

• Backscatter hypothesis– Unsolicited packets represent backscatter

• In fact any server can send

– Reflector attack may not be detected• Not random IP-forgery

– Some attacks (e.g. TCP-RST) doesn’t produce backscatter.


11

• Cluster packages– TCP- ICMP Single attack- multiple attacks – start and end times of attacks

• small number of longer attacks

• or many short attacks


12


13

Platform


14

Results

• 13000 attacks

• 5000 victim IP addresses on 2000 domains

• 200 million backscatter packets– *256 < Real attack packets


15


16


17


18


19


20

How threatening

• 500 packets enough to overwhelm server– 38-46 % of attacks (unif.-all)

• 14000 packets for firewall– 0.3-2.4 % of attacks (unif.-all)


21


22


23


24

Autonomous Systems


25


26


27


28

Paper#2

Characteristics of Network Traffic Flow Anomalies

• A project focused on precise characterization of anomalous network traffic behavior.

• anomalous traffic• Outages

• Configuration changes

• Flash crowds

• Abuse


29

Paper#2

Introduction

• Step 1 – Gather passive measurements of network traffic

at the IP flow level.

• Tool– FlowScan open source SW

• Focus:– Precisely identify similarity and differences

among each anomaly group


30

Paper#2

Related Work• Network traffic properties

– time series techniques– wavelet analysis– isolating failures in networks – papers on clustering methods, neural networks

and Markov models to recognize intrusions. – flash crowd behavior not well treated– New mechanisms involving cooperative

pushback are being proposed


31

Paper#2

FlowScan• FlowScan collects Netflow data exported by Cisco

routers in a network. • Netflow data includes source and destination

AS/IP/port pairs, packet and byte counts, flow start and end times and protocol information.

• FlowScan maintains a set of counters based upon the attributes of each flow reported by a router.


32

Paper#2

Anomaly Identification• Three general categories

– Network Operation Anomalies• device outages, configuration changes

• traffic reaching environmental limits

– Flash Crowd Anomalies• Software release (e.g. UW is a RedHat Linux mirror site)

• or External interest in a site (national publicity)

• Rapid rise in traffic flows of particular type (eg. FTP flows)

– Network Abuse Anomalies


33

Network Operation Anomalies Example: network outage which occurred just after 1:00am, a Napster server outage which occurred at 2:00pm, and three instances of turning on/off rate limiters on Napster traffic for the network.


34


35

Paper#2 3rd anomaly type:

Network Abuse Anomalies

• DoS flood attacks and port scans

• Different from network operation and flash crowd anomalies– not always readily apparent in bit or packet rate

measurements– flow count measurements clearly indicate abuse

activity


36

Five minute averages for flows per second into and

out of our network broken out by protocol.

The anomalous

behavior is clearly evident in the spike of flows into

the network during a half hour period just before noon.


37

Paper#2

Anomaly Characteristics - Analysis Process• 1st step: isolate each of the anomalies in

data sets & group them into the three general categories mentioned.

• 2nd Step: apply time series analysis– analyzing stationarity, correlation structures

and testing various time series models to see if any are accurate statistical representations of anomaly data model developing

• final step: apply wavelet analysis


38

Paper#2

Future Work

• Various directions– Evaluate 1 min VS 5 min.s

• Accuracy VS dataset size

– anomaly data collection process across multiple sites

• larger datasets

• correlations of behavior across sites


39

Paper#3

An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks

• Overview– Definition of DDOS attack.– Different Trace back schemes.– Reflectors.– Defenses against Reflectors.– Filtering out Reflector Replies.– Implications of Using Reflector for Trace back.


40


41

Trace back schemes

– Trace back schemes for spoofed packets• ITRACE (ICMP Trace)

– Volume based

• Probabilistic packet marking.– Computational difficulties – scaling.

• Source Path Isolation Engine (SPIE).– Does trace back information help?


42

Reflectors• A reflector is any IP host that will return a

packet or more if sent a packet.

Examples:– Web servers: return SYN ACKS or RSTs in

response to SYN or other TCP packets.– DNS servers: return query replies in response to

query requests.– Routers: return ICMP Time Exceeded or Host

Unreachable messages in response to particular IP packets.


43


44

Using Reflectors• Reflector cannot easily locate the slave

because of the IP spoofing.• If there are Nr reflectors, Ns slaves and a

flooding rate F from each slave– Flooding rate at each reflector

F’=F * Ns/Nr

– So, individual reflectors send at a much lower rate than the slaves.

– Local detection mechanism at each reflector fails to detect, based on volume.


45

Reflectors contd…

• Trace back mechanisms based on larger volumes of traffic such as ITRACE, probabilistic packet marking etc. fail.

• Using reflectors provides attackers, protection against trace back mechanisms.

• Source Path Isolation Engine (SPIE) helps.

• Reflectors need not serve as amplifiers.


46

Defense against Reflectors1. Prevent spoofing source address by

ubiquitous deployment of ingress filtering.

Application level reflectors such as recursive DNS queries or HTTP proxy requests can still be used.

Disadvantage: Not feasible.

2. Traffic generated by reflectors can be filtered or classified by the victim.

3. Deploying filters to prevent serving as reflectors.Disadvantage: Requires widespread deployment of filtering.


47

Defense against Reflectors …4. Deploy trace back mechanisms that

incorporate the reflector end-host software itself in the scheme, allowing trace back through the reflector back to the slave.

Disadvantage: Enormous deployment difficulties.

5. Intrusion Detection Systems (IDS) monitor a site’s network for active slaves.Disadvantage: Requires widespread deployment of security technology.


48

Filtering out Reflector replies

• IP packets– Type of service (TOS/DSCP). (for scenarios in

future)• Difficult for the attacker to manipulate a reflector

into having a particular DSCP attached traffic.

• If the traffic in general is premium then it will be difficult for the attacker to force the premium marking, given the financial motivation to secure use of the premium traffic.


49

IP packets– IP Fragments

• Make it difficult for the victim to filter the protocol header information.

• Victim can filter out all fragmented traffic.– Because of limited use of fragments in Internet. – Suffer little degradation.– Other than protocols like NFS, AFS etc.

– IP protocol field• Filter out uninteresting protocol traffic.

– IP source and destination address• Filter out the unknown or suspicious sourced traffic.


50

Types of ICMP reflector replies:1. ICMP echo, timestamp, address mask, router

solicitation, information request/reply.1. ICMP echo is widely used.

2. Smurf attacks.

2. ICMP source quench, unreachable, time exceeded, parameter problem, and redirect.

Important ICMP messages:1. Host unreachable.

2. Time exceeded.

3. Need fragmentation.


51

TCP

• Reflector can only be made to send– SYN ACK by sending an initial SYN.

• Filtering leads to no-remote access.

– RST by sending a FIN.• Filtering RST results in clogging of stale

connections state.

• During flooding, the victim can eliminate TCP-based reflectors by filtering port 80 sourced traffic.


52

TCP

• Predictable TCP sequence numbers– If reflector stack has guessable TCP sequence numbers,

it’s a DISASTER for the victim.

– Attacker can drive the Reflector TCP state machine, making it send ACKs, data segments.

– Attack can be amplified by transmitting large items and exploiting “ACK splitting” techniques.


53

TCP for Transactions (T/TCP)

• Spoof initial SYN packet with acceptable seq. no.– Make an expensive request.

• Factors that limit the T/TCP attack– T/TCP server will begin in slow start.

• Unless the server’s stack has predictable seq. no.

– Amenable to stateless packet filtering.

– T/TCP is not widely deployed.


54

• UDP– Filter out based on port numbers.– Not a major threat.

• DNS– Reflector sending DNS reply in response to a

spoofed DNS request.• Victim can configure its local DNS servers so as to

filter out unknown DNS server responses.

– If the victim is a name server• Attacker can query a large number of DNS servers

which in turn recursively query the Victim.

• Victim server gets bombarded due to multiple queries.


55

DNS

• The DNS queries needn’t even be spoofed.

• Caching at the reflector server doesn’t help.

• DNS reflection appears to be a serious threat for DDOS attacks on name servers.– Solution: To provide filtering in name servers

so as to serve recursive queries from local addresses, coupled with ingress filtering.


56

• SNMP (UDP-based request/reply)– Sites that fail to block off-site access to SNMP provide

a large number of reflectors.– SNMP attack is sourced at port 161.– Filtering out the external SNMP messages leads to

major problem for service providers.• Configure the filter to receive SNMP messages from interested

hosts.

• HTTP– HTTP proxy caches provide a way that an HTTP client

can manipulate a proxy server into initiating a connection to a victim web server.

– HTTP proxy servers act as reflectors for the DDOS attacks.


57

• HTTP - Limitations– Proxies can be configured to serve a restricted set of

clients.

– There are not enough proxy caches to constitute a large pool of possible reflectors.

– Connection between slave and the reflector cannot be spoofed unless the reflecting proxy has predictable sequence numbers. Logging helps in identifying the slave’s location.

• Definitely a major threat if servers running on stacks with predictable sequence numbers are widely deployed.


58

Gnutella • Gnutella includes a “push” facility that instructs

the server to connect to a given IP address and port in order to deliver the Gnutella item.

• Gnutella connection to the IP host is separated from the initial client making it impossible to trace back to the slave.

• Only fix is to modify the protocol to include path information with “push” directives

• Gnutella could be a major problem for DDOS reflector attacks.


59


60

Summary of different reflector threats

• Major threats– TCP predictable seq. no.– Recursive DNS queries.– Gnutella “push”.

• Difficult to filter– ICMP request/reply.– ICMP problem.– HTTP proxy caches.


61

Implications of Reflector attacks for Trace back.

• Major advantage to attackers– Protection from trace back mechanisms.– Cannot trace back directly to slave so one of

reflector operator should do.• Administratively cumbersome.

• Trace back schemes such as SPIE can help.• Non-spoofed reflector attacks will expose

the slave to quick trace back.


62

Reverse ITRACE• R-ITRACE routers send ICMP messages to

the source of the just-processed packet rather than its destination (unlike ITRACE).

• Routers on the path between slave and the reflector will send ICMP messages to Victim to enable trace back to the slaves.

• Efficacy does not depend on Nr but only on Ns.

02/25/02ddos/traceback-characterisation ozgur ozturk 1 ddos/traceback paper group # 23:...

Documents

backscatter packets

attacks unif

arriving packets

all14000 packets

ip spacereceived backscatter

sendreflector attack

data gatheredhttp

data structure