CSE 4905 Denial of Service Attacks 8 1

CSE 4905 Denial of Service Attacks 8 -1

Denial-of-Service (Do. S) Attack v The NIST Computer Security Incident Handling Guide defines a Do. S attack as: “An action that prevents or impairs the authorized use of networks, systems, or applications by exhausting resources such as CPU, memory, bandwidth, or disk space. ” 8 -2

Denial-of-Service (Do. S) A form of attack on the availability of some service Categories of resources that could be attacked are: Network bandwidth: try to reach the capacity of the network links connecting a server to external Internet System resources: try to overload or crash network handling software (e. g. , buffer, tables of open connections, …) Application resources: try to crash a specific application, e. g. , web server 8 -3

8 -4

Classic Do. S Attacks Flooding ping command overwhelm the capacity of the network connection to the target organization packets are discarded as capacity decreases Source of the attack is clearly identified unless a spoofed address is used Network performance is noticeably affected 8 -5

Source Address Spoofing Use forged source addresses Usually via the raw socket interface on operating systems Makes attacking systems harder to identify Attacker generates large volumes of packets that have the target system as the destination address Lead to congestion in the router connected to the final, lower capacity link Requires network engineers to specifically query flow information from their routers Backscatter traffic Responses to attacks scattered across the Internet 8 -6

SYN Spoofing Common Do. S attack Attacks the ability of a server to respond to future connection requests by overflowing the tables used to manage them Thus legitimate users are denied access to the server Hence an attack on system resources, specifically the network handling code in the operating system 8 -7

8 -8

8 -9

SYN Flooding Attack S SYNC 1 Listening… SYNC 2 Spawn a new thread, store connection data SYNC 3 … and more SYNC 4 SYNC 5 … and more 8 -10

Flooding Attacks Classified based on network protocol used Intent is to overload the network capacity on some link to a server or the server itself Virtually any type of network packet can be used ICMP (e. g. , ping) flooding • Some ICMP packets are filtered by firewall, some have to be kept for normal TCP/IP behavior § § UDP flood TCP SYN flood Normal TCP packets … 8 -11

Sample victim response to attacks 8 -12

NTP Amplification Attack [Vitaly Shmatikov x 206 amplification “Give me the addresses of the last 600 machines you talked to” Spoofed Src. IP: Do. S target (234 bytes) Do. S Source 600 addresses (49, 000 bytes) NTP (Network Time Protocol) server Do. S Target December 2013 – February 2014: 400 Gbps DDo. S attacks involving 4, 529 NTP servers Reflection attack/Amplification: small query large response 8 -13

DNS Amplification Attack [Vitaly Shmatikov x 50 amplification DNS query Src. IP: Do. S Target (60 bytes) Do. S Source EDNS response (3000 bytes) DNS Server Do. S Target EDNS: DNS extension that allows large DNS messages, or using or DNSSec to increase message size 8 -14

Distributed Denial of Service (DDo. S) Attacks Use multiple systems to generate attacks Attacker uses a flaw in operating system or in a common application to gain access and installs their program on it (zombie) Attacker can control large collections of such compromised systems, forming a botnet 8 -15

DDo. S attack programs v Tribe Flood Network (TFN) § By Mixter, 1990 s exploited in Sun Solaris v Tribe Flood Network 2000 (TFN 2 K) § Rewritten from TFN § Can run on Unix, Solaris, Windows NT v Attack architecture: 2 -layer § Agent: Trojan program copied to and run on compromised systems § Handler: command-line program that run compromised systems § Communication between handler and agent: encrypted, intermixed with decoy packets, using TCP, UDP or ICMP 8 -16

DDo. S attack architecture Handler zombies 8 -17

Prevalence of DDo. S v How prevalent are DDo. S attacks in the Internet? v v v Reports from Computer Emergency Reponse Team (CERT) 1989 – 1995 CERT AIR-CERT News reports: only major incidents Service providers and content providers consider data sensitive and private Surveys from security personnels Other approaches? 8 -18

D. Moore, G. Voelker, S. Savage Inferring Internet Denial-of-Service Activity (USENIX Security 2001) 8 -19

Backscatter [Moore, Voelker, Savage] u. Attacker uses spoofed, randomly selected source IP addresses u. Victim replies to spoofed source IP u. Results in unsolicited response from victim to third-party IP addresses 8 -20

How a Network Telescope Works [Moore, Voelker, Savage] 8 -21

Backscatter Analysis [Moore, Voelker, Savage] v v m attack packets sent n distinct IP addresses monitored by telescope Assume attacker chooses source addresses uniformly, expectation of observing an attack: R’ = measured rate of attack (pkts per second), R = extrapolated attack rate (pkts per second) 8 -22

Analysis Assumptions v Address uniformity § Spoofed addresses are random, uniformly distributed v Reliable delivery § Attack and backscatter traffic delivered reliably v Backscatter hypothesis § Unsolicited packets observed represent backscatter 8 -23

Data Collection /8 network 2^24 addresses 1/256 of Internet address space 8 -24

Attack classification v Flow-based analysis § Classifying individual attacks (how many, how long, what kind) § Flow: series of consecutive packets that share the same target IP address and IP protocol § End of flow: no packet within 5 minutes § Only consider flows that is at least 60 seconds long with at least 100 packets v Event-based analysis § Understand severity of attacks on short time scales § Attack event: a victim emitting at least 10 8 -25

Flow-based analysis (more details) v Extract info from each flow § § § TCP flag settings (e. g. , SYN/ACKs, RSTs) ICMP payload Address uniformity: Port settings: fixed, uniform, or not DNS information: DNS address of source address (or victim address) § Routing info: prefix, mask, or orign AS as registered in local BGP table 8 -26

Summary results [Moore, Voelker, Savage] 8 -27

Rate of attacks 8 -28

Response protocols [Moore, Voelker, Savage] 8 -29

Victims by Port [Moore, Voelker, Savage] 8 -30

Victims by Top-Level Domain [Moore, Voelker, Savage] 8 -31

Victims by Autonomous System [Moore, Voelker, Savage] 8 -32

Repeated Attacks [Moore, Voelker, Savage] v v 65% victims attacked once, 18% victims attacked twice One attacked 102 times in one week 8 -33

Conclusions of the [MSV 01] study [Moore, Voelker, Savage] v v Observed 12, 000 attacks against more than 5, 000 distinct targets. Distributed over many different domains and ISPs Small number of long attacks with large % of attack volume Unexpected number of attacks targeting home machines (based on DNS names), a few foreign countries, specific ISPs 8 -34

Defense against Do. S attacks v v These attacks cannot be prevented entirely High traffic volumes may be legitimate § High publicity about a specific site § Activity on a very popular site v Four lines of defense § Attack prevention and preemption (before attack) § Attack detection and filtering (during attack) § Attack source traceback and identification (during and after attack) § Attack reaction (after attack, eliminate or curtail the effects of attacks) 8 -35

Preventing Do. S attacks v Block source § On routers as close to source as possible § e. g. , by ISP that knows that address block assigned to customers v Use filters to ensure path back to the claimed source address is the one being used by the current packet v SYN cookies § simple defense again SYN flooding and SYN spoofing attacks § D. Bernstein, 1996 8 -36

SYN Flooding Attack S SYNC 1 Listening… SYNC 2 Spawn a new thread, store connection data SYNC 3 … and more SYNC 4 SYNC 5 … and more 8 -37

SYN cookie: main idea v Do. S is caused by asymmetric state allocation § server opens new state for each connection attempt § attacker can initiate thousands of connections from bogus IP addresses to exhaust server resources v Cookies: make server stateless until initiator produced at least two messages § Server’s state (IP addresses and ports of the con-nection) is stored in a cookie and sent to initiator 8 -38

[Bernstein and Schenk] SYN Cookies C S SYNC Compatible with standard TCP; simply a “weird” sequence number SYNS, ACKC Listening… Does not store state sequence # = cookie F(source addr, source port, Cookie must be unforgeable dest addr, dest port, F=Rijndael or crypto hash coarse time, server secret) and tamper-proof (why? ) ACKS sequence # = cookie+1 Recompute cookie, compare with the received cookie, only establish connection if they match More info: http: //cr. yp. to/syncookies. html 8 -39

Preventing DDo. S attacks (II) v Block suspicious services and combinations v Manage application attacks with a form of graphical puzzle (captcha) § distinguish legitimate human requests and automated requests v Good general system security practices v Use mirrored and replicated servers when high-performance and reliability is required 8 -40

Responding to DDo. S attacks v Good Incident Response Plan § Details on how to contact technical personnel in ISP § Details of how to respond to the attack v Should implement antispoofing and rate limiting filters v Ideally have network monitors and IDS to detect and notify abnormal traffic patterns v Identify type of attacks to decide best response strategies v Have ISP trace packet flow back to 8 -41

Summary v Denial-of-service (Do. S) attacks § Classical Do. S attacks § Flooding Do. S attacks v Measuring prevalence of Do. S attacks in the Internet using network “telescopes” v Defenses against Do. S attacks 8 -42