History. Attacks on Availability (1) Attacks on Availability (2) Securing Availability

(1)

Securing Availability

¾ Distributed Denial of Service (DDoS) Attacks

¾ Mitigation Techniques ¾ Prevention

¾ Detection

¾ Response

¾ Case Study on TRAPS

Securing Availability © Vrizlynn Thing 2

History

z Summer 1999, new breed of attack on

availability developed – Distributed Denial of Service

z First tool developed was Trinoo

z Trinoo network of at least 227 systems used on August 17, 1999 to flood a single system at University of Minnessota

z Swamped the target network with an

approximate capacity of 90 Mbps rendering it unusable for over 2 days

Attacks on Availability (1)

Recent years, high profile attacks over the Internet focused on disrupting availability.

z Feb 2000, Yahoo down for 3 hrs (losses:

~US$500k); Amazon 10 hrs (losses: US$600k); Buy.com availability dropped to 9.4%;

Zdnet.com and E*Trade.com virtually unreachable

z July 2001, Code Red worm infected > 250k

systems in 9 hrs and carried out flooding attacks

z Oct 2002, attack on the 13 DNS root servers (7 down

and 2 badly ‘crippled’)

Attacks on Availability (2)

- Feb. 2004, Hacker threats to bookies probed, BBC Technology News

- Mar. 2005, Duo charged over DDoS for hire scam, The Register

- Mar. 2005, Dutch hackers sentenced for attack on government sites, The Register

- Apr. 2005, Rootkit Web sites fall to DDoS attack, IDG News Service

- May 2005, Extortion via DDoS on the rise, Network World

- Sept. 2005, Hackers Admit to Wave of Attacks, Wired

- Dec. 2005, Man admits to eBay DDoS attack, The Register

- Jan. 2006, Blackmailers try to black out Million Dollar Homepage, CNET News

- Jan. 2006, 'Botmaster' pleads guilty to computer crimes, Reuters

(2)

Attacks on Availability (3)

z By extortionists and business rivals

z On websites of banking and financial companies, online

gambling firms, web retailers, government, etc.

z Worldwide ISP survey by Arbor Networks, in 2005,

shows DDoS is most significant operational security concern of 36 worldwide ISPs

z CSI/FBI survey, in 2004, shows virus and DDoS are the

most costly cyber-crime

What is Denial-of-Service

z Availability – ensure that

resources can be

accessed by people who should have access

z Denial-of-Service (DoS) attack – attacks

launched to disrupt and deprive legitimate

access to resources

Internet Attacker

Target

Distributed Denial-of-Service Attack

Zombie N Zombie 3 Zombie 2 Attacker Target ... ... Zombie 1 z Multiple compromised machines, “Zombies” z Coordinated attack z More powerful z More difficult to mitigate

DDoS Attack Models (1)

Handler M Handler 3 Handler 2 Attacker Target ... ... Handler 1 Attacker ... ... Agent 1 Agent N Agent N-1 Agent 5 Agent 4 Agent 3 Agent 2 ... ...

Agent - Handler Attack Model

Attackers communicate with attack network through handlers Agents are compromised system to carry out attack

(3)

DDoS Attack Models (2)

Attacker ... ... Attacker Agent N Agent N-1 Agent 5 Agent 4 Agent 3 Agent 2 ... ... IRC Network Target Agent 1

IRC-Based Attack Model

Attackers communicate with attack network through IRC channels Advantages: Legitimate port no. and large volume of IRC traffic allow camouflaging

Classifications of DDoS Attacks

Resources – Directed at end target/victim

Routes to resources – Indirect, disrupts paths to end target/victim Network layer – Targets design or implementation flaws of protocols Network link – Bandwidth depletion on end target/victim’s link/s End-Host – Targets victim’s system resources

TCP SYN Flood

z Exploit TCP handshaking procedure

z Attack hosts “Zombies” spoof source IP addresses

z Server’s resources tied up while waiting for ACK

packet Client A Server B SYN A SYN B + ACKA ACK_B X TCP 3-Way Handshake Zombie +1 +1

UDP Flood

z User Datagram Protocol

z Connectionless

z Attack by sending large number of UDP packets to random ports of target

z Spoof source IP addresses in attack packets

z For each packet, target checks what services is listening on the destination port

z If nothing, returns message notifying destination unreachable

(4)

ICMP Flood

z Internet Control Message Protocol

z ICMP Echo Request Message = “ping” packet

z Send large number of them to target

z Spoof source IP addresses

z Target handles requests by sending replies

z Overwhelm processing and bandwidth resources

z Prevention? Mitigation?

z Spoofed addresses + replies = further exploit?

Reflection attack (1)

z Make use of request/reply protocols

z Spoof victim’s source IP address in legitimate requests to servers (e.g. TCP SYN or DNS)

z Overwhelm victim with replies

Reflection attack (2)

Diagram source from www.grc.com

DNS attack

z Domain Name System

z Distributed database system for mapping hostnames to IP addresses

z Attack involves sending bogus requests to flood servers

z In Oct. 2002, DNS attack against all 13 root servers

(5)

Border Gateway Protocol (BGP)

z Inter-autonomous system routing protocol (e.g.

for ISPs)

z Apr. 1997, AS7007 incident – Misconfigured router flooded Internet with incorrect

advertisements announcing AS7007 as origin of best route to essentially the entire Internet

z AS7007 becomes major traffic sink, disrupted reachability to many networks for hours

z Similar events in Apr. 1998 and Apr. 2001

z DoS but not attack?

z How easy is it to compromise a BGP router? And BGP session hijacking?

DDoS Mitigation

z Prevention – Guard against attacks from having any effect on the target

z Detection – Trigger alarm for an on-going attack

z Response – Take actions to alleviate damaging effects caused by attack and identify attackers to institute accountability

DDoS Prevention (1)

z Egress filtering: Prevent source address spoofing by filtering on traffic from Internet to customer sites with “illegitimate” source addresses

z Ingress filtering: Removes any traffic from customer sites to Internet with invalid source addresses

z Foolproof?

z Proposed in year 2000 but study by MIT last year shows spoofing remains a serious security concern. Why?

DDoS Prevention (2)

z Block access to all non-service ports (e.g. unallocated port numbers, services deemed potentially harmful or not used)

z Examples: ICMP echoes, ports used for propagation by known attacks, etc.

(6)

SYN cookies

z Server returns SYN/ACK packet with sequence number,

n, computed as follows:

z First 5 bits: t mod 32 (t is a counter incremented every 64 secs)

z Next 3 bits: encoded value representing m (m is the Maximum segment size value stored by the server in the SYN queue entry)

z Final 24 bits: s, result of secret cryptographic function computed over server IP address and port, client IP address and port and t

z Server reconstructs needed information from client’s

ACK sequence number, n+1, to establish connection

DDoS Prevention (3)

DDoS Detection (1)

TCP SYN Flood Detection

z Based on protocol behavior of TCP SYN-FIN (RST) pairs

z Anomaly detected when abrupt rise occurs between the difference in counts of SYN and FIN/RST packets

Diagram source from “Detecting SYN Flooding Attacks” paper by H. Wang et. Al.

D-WARD

z Detect outgoing DDoS attacks

z Source end deployment

z Per-destination and per-connection statistics gathering at exit routers of own network

z Observe and detect non-responsive foreign hosts (aggressive sending rate coupled with low response rate)

z Define thresholds for TCP, ICMP and UDP applications

z Attack detected if threshold exceeded

DDoS Detection (2)

DDoS Detection (3)

MULTOPS

z Monitors disproportional packet rates to or from hosts and subnets

z Uses tree-shaped data structure to collect statistics

z 4-level (256 entries per table) tree to cover entire IPv4 address space

z Each entry contains 3 fields (to rate, from rate and pointer to node in next level of tree)

(7)

DDoS Detection (4)

MULTOPS

Diagram source from “MULTOPS: a data-structure for bandwidth attack detection” paper by Thomer M. Gil et. al.

Traceback

z 2 addresses in IP packets: Source and Destination

z Destination address: used by routing architecture to deliver packet

z Source address: used by destination to determine from whom the packet is from

z Problem: No entity responsible for verifying

correctness of source address (similar to postal service)

Responses to DDoS (1)

Traceback: IP Marking

Responses to DDoS (2)

Attack Path Encoding path information in identification field

Diagram source from “Practical network support for IP Traceback” paper by Stefan Savage et. al.

z Intermediate routers mark IP packets with information on path they traverse

z Probabilistic approach

z Uses 16-bit IP Identification field

z Encode path information using hashing schemes

z Target of attack collects information and

compute to identify source of attack by decoding

z Disadvantages?

(8)

Traceback: IP Marking

Diagram source from “Practical network support for IP Traceback” paper by Stefan Savage et. al.

Traceback: IP Marking

z

Each router computes a 32-bit hash of its

address

z

64-bit “Bit-Interleave”: odd = original,

even = hash

z

With a probability, a router marks a packet

with a fragment and set distance to 0

z

Next router, xor its corresponding

fragment to the edge id field if distance is

0, and increment distance

Example

z R3 (IP address is 211.126.2.59, and hash address is 136.41.5.89) decides to mark the packet with its 3rd _fragment

Traceback: IP Marking

211.126.2.59 = 11010011.01111110.00000010.00111011 136.41.5.89 = 10001000.00101001.00000101.01011001 Bit-interleave = 11100010.01001010.00101110.11101001. 00000000.00011001.00011011.11001011 R3’s 3rd_{fragment is 00101110}

R3 writes 010.00000.00101110 into ID field

Assuming R2’s 3rd_{fragment is 11101111, R2 changes the}

ID field to 010.00001.11000001

If R1 decides not to mark, it would just increment distance Victim sees ID field as 010.00010.11000001

Traceback: IP Marking

z Victim collect all the fragments for the edges

z Edge ID with 0 distance away carries R1’s address

z Performs hash of odd bits of edge id and compare with even bits to check marking info was not corrupted

z XOR the edge id with the next uplink’s to get the previous router’s address

(9)

Traceback: ICMP Traceback

z New ICMP message type, “ICMP Traceback – ITrace”

z Out-of-band messaging (no modification to original data packets)

z Probabilistic generation of ITrace message for data packets at intermediate routers

z ITrace messages sent to the target of the attack (i.e. victim)

Responses to DDoS (3)

Responses to DDoS (5)

Traceback: ICMP Traceback

z Contents of ITrace message include information of the back and forward links of the intermediate router and signature of the original data packet

z Victim reconstructs attack path based on the ITrace messages received

z Disadvantages?

Filtering

z Drop all attack packets

z Used when it is possible to differentiate between attack and legitimate packets

z Else will result in self-inflicted DoS

Rate Limiting

z Decrease traffic suspected to be malicious to prevent victim from being totally overwhelmed

z Ease the impact of damage

Responses to DDoS (6)

Buffer Server

Client Service requestR

O.K. Client Puzzles

Responses to DDoS (7)

(10)

Client Puzzles

z Server assigns

unique client puzzles to each client making a connection request z Resources allocated to clients with correctly solved puzzles only z Attacker forced to commit considerable resources z Constructing puzzles?

Responses to DDoS (8)

Diagram source from “Client Puzzles as a Defense Against Network Denial of Service” by Deanna Koike

Traffic Redirection Attack Protection System (TRAPS)

Case Study

z Attack detection based on resource usage pattern monitoring with threshold levels to indicate severity

z Suspicious traffic rate limited based on current attack severity level

z Victim performs ‘virtual’ relocation and informs suspicious users (i.e. virtually moves to a new address)

TRAPS

2. At Gateways (GWs, i.e. entrance points to network) and intermediate Routers, filter off incoming packets with no knowledge of victim’s new configuration. GWs Attackers Legitimate Clients Victim Attackers using spoofed source addresses to attack Victim Routers 1. Reconfigure at Victim. Since traffic is coming from “clients”, inform them to send

subsequent traffic based on Victim’s new configuration.

Traffic Redirection Attack Protection System (TRAPS)

TRAPS

z No changes to Internet infrastructure due to usage of IP mobility protocols

z Zero false positive when using filtering

z Ensure ability to handle services for legitimate users during attacks

z Guarantee communication of signals required for mitigation during attacks

(11)

TRAPS

A1 - A50 A101 - A150 R8 R7 R6 R5 R4 R3 R2 R1 R9 ₁₀R V N1 - N25 N26 – N50 _{N51 – N75} N76 - N100 A51 - A100 A151 - A200 Attack traffic redirected to and filtered off

at proxy

Summary

z Attacks on availability escalate to become one of the most serious and expensive network security problems of today

z Main reasons due to flaws in protocol and software designs and implementations, wide spread availability of attack tools, and

monetary gains for extortionists and business rivals

z Successful attack mitigation requires efficient and effective prevention, detection and

response techniques

References

Haining Wang, Danlu Zhang, and Kang G. Shin, "Detecting SYN flooding attacks", IEEE INFOCOMM, 2002.

Jelena Mirkovic, "D-WARD: DDoS Network Attack Recognition and Defence", PhD Thesis, Computer Science Department, University of California, Los Angeles, Jun. 2003. Thomer M. Gil and Massimiliano Poletto, "MULTOPS: a data-structure for bandwidth attack

detection", 10th USENIX Security Symposium, Feb. 2001.

Stefan Savage, et al., "Practical Network Support for IP Traceback", ACM Sigcomm, Aug. 2000.

Steve Bellovin, Marcus Leech, and Tom Taylor, "ICMP Traceback Messages", IETF Internet Draft, Version 4, Feb. 2003 (Work in progress).

Ari Juels and John Brainard, "Client puzzles: A cryptographic countermeasure against connection depletion attacks", Networks and Distributed Security Systems, Feb. 1999. Vrizlynn L. L. Thing, Henry C. J. Lee, and Morris Sloman, "Traffic Redirection Attack

Protection System (TRAPS)", IFIP International Information Security Conference (SEC), May 2005, Makuhari-Messe, Chiba, Japan, Springer-Kluwer.