Analysis of a DOS attack on TCP Christoph L. Schuba, Ivan V. Krsul, Markus G. Kuhn, Eugene H. Spafford, Aurobindo Sundaram, Diego Zamboni. Purdue University. Appeared in proceedings of the 1997 IEEE Symposium on Security and Privacy. May 04 - 07, 1997 Oakland, CA

About Me Anup Mayank Graduate Student in Department of CS&E, UCR E-mail : mayank@cs.ucr.edu

Roadmap Synkill FDS Key Principle TCP Handshake and TCP Data Structure SYN Attack Previous Proposals Synkill Algorithm FDS Discrepancy Between SYN and FIN Attack Detection

Key Principle Classification of IP source addresses as falsified or genuine Active Monitoring tool (Synkill) is employed near the server end. Rest of the detail follows…………………..

How Irritating is DOS?

Distributed Dos

Roadmap Synkill FDS Key Principle TCP Handshake and TCP Data Structure SYN Attack Previous Proposals Synkill Algorithm FDS Discrepancy Between SYN and FIN Attack Detection

TCP Handshake server client SYN seq=x SYN seq=y, ACK x+1 ACK y+1 connection established

TCP Data Structure Socket structure (socket) : info of local end Internet Protocol Control Block structure (inpcb) : transport layer info TCP Control Block structure (tcpcb) : TCP specific information Combined size of above 3 memory structure is generally more than 280 bytes

Roadmap Synkill FDS Key Principle TCP Handshake and TCP Data Structure SYN Attack Previous Proposals Synkill Algorithm FDS Discrepancy Between SYN and FIN Attack Detection

SYN Attack Attacker A initiates a SYN flooding by generating many requests with SPOOFED source address. Thus forces ‘D’ to allocate resources. With many such requests destination host can run out of resources. …………. ……DOS…….DOS…..DOS….

SYN Attack contd… TCP connection timeout is typically set to 75 seconds. Backlog queue is built in the system memory of server to maintain all half open connections. Crisis : Backlog queue is of finite size

Parameters & Attack Modes Batch Size:- Number of SYN packets per source address sent in a batch. Delay:- Time interval between two successive batches. Mode of Source Address Allocation by an attacker. Single Address:- Uses single spoofed address. Short List:- Small pool of source addresses. No List:- Randomly generated source address.

Roadmap Synkill FDS Key Principle TCP Handshake and TCP Data Structure SYN Attack Previous Proposals Synkill Algorithm FDS Discrepancy Between SYN and FIN Attack Detection

Previous Proposal –1.a System Configuration Optimization Reduce timeout period. Any Fallacy?? Increase length of backlog queue Disable non-essential services, thus reduce the number of ports which can be attacked.

Previous Proposal –1.b Router Configuration Optimization External interface of router blocks packets which have source address from the internal network Internal interface of the router blocks packets that have source address from outside of the network Effective if all ISPs configure their router. Problematic for mobile IP

Previous Proposal –2 Infrastructure Improvement Clearly define boundary between inside and outside. Difficult due to complex topology of large backbone networks. Trace physical transmission path of IP packet to the source. Internet Infrastructure lacks this mechanism

Previous Related Proposal-3 Better Connection Establishment policy. What is wrong with TCP connection setup? Asymmetric memory and computation requirements on the two endpoints during each connection establishment. Destination host has to allocate large data structures in response to any SYN packet without guarantee of its authenticity. It has to store y for subsequent steps in connection establishment. Else attacker can just send the third message and establish the connection. Again same old solution:- Apply CRYPTOGRAPHY.

Previous Related Proposals-3 One such mechanism is to calculate y (ISN) as a cryptographic hash value of source and destination IP addresses, ports,the source’s ISN & a destination specific secret key. Destination host would calculate in that manner and use it in its SYN+ACK message. At the time D received the third message of the three-way handshake it can recalculate y’ by using the secret key, sequence number, the addresses & ports found in that message. IF y = y’ connection is legitimate else ………

Issues-3 Solution requires change in existing TCP standard and in fact every TCP implementation. Increases complexity. As a result may ask for more processing time which is dependant on cryptography system deployed. Will people AGREE?

Previous Related Proposals-4.a Firewall as a Relay Firewall answers to the SYN sent by the attacker, as final ACK never arrives, connection is reset by the firewall. For a legitimate connection after final acknowledgement is received it creates a new connection with the internal host. It keeps acting as a middle agent and does all the translation work. Good in a way that internal host never receives SPOOFED packets.

Previous Related Proposals-4.b Firewall as a Semi Transparent Gateway No delays. But large number of illegitimate open connections. Assumption:- Servers have enough resources to entertain these open connections. Legitimate request Illegal request

Firewall Approach - Issues Extra processing and transaction management by firewall induces delay for legitimate connections. Firewall can be subjected to SYN flooding.

Previous Related Proposals-5 Active Monitoring Software Solution. Monitor TCP/IP traffic. Watch out for certain conditions and react appropriately. Idea seems to be a cool one. Low costs and high flexibility. Does not require any new hardware. It does not demand software modifications to the protected end systems.

Roadmap Synkill FDS Key Principle TCP Handshake and TCP Data Structure SYN Attack Previous Proposals Synkill Algorithm FDS Discrepancy Between SYN and FIN Attack Detection

Synkill

“Synkill” – A software approach Synkill monitors incoming packets and classify them into Null, Bad, Good & New states. Synkill sends RST packets whenever it detects “BAD” IP addresses or networks. Thus releases the allocated resources.

“Synkill” – A software approach Synkill completes TCP connections by generating third message of handshake. This is done to move the connections from SYN received to connection established state.

Synkill Algorithm Classify source IP addresses of arriving TCP packets as: Never seen (NULL). Belonging to correctly behaving(good). Potentially Spoofed addresses( New). Most certainly Spoofed addresses(Bad). Above classification is based on observed network traffic.

“Synkill” – finite state diagram

“Synkill” The source address of each TCP packet is examined to determine the set membership of the address (null, new, bad, or good). Null addresses are not saved explicitly, because it is not practical to keep data structures for all possible IP addresses.

Synkill-Observed TCP packets TCP packets with the SYN bit set are the initial message of any TCP connection establishment attempt. The state machine is designed to ignore SYNs for addresses that are in the new, good, or perfect states. For addresses in the bad or evil states, a RST packet is generated and sent. The very first packet received from an address with its SYN bit set is moved into the new state to indicate suspicion. As soon as further valid TCP traffic from that address is observed (ACK, RST) the address is moved into the good state.

“Synkill” – finite state diagram

Synkill- Observed TCP packets ACK, RST If synkill receives a valid ACK or RST packets from an address, it means that the host generates valid packets and the address can be considered good. The address is moved into the good state.

“Synkill” – finite state diagram

“Synkill” – timer events Expiry event occurs if the timer associated with the state expires. Meaning:- Synkill hasn't observed any valid TCP traffic from that address. Address is moved to bad state. RST packets are generated and sent for all SYN packets from the address that were observed while the address was in the new state. Expiry timer should be smaller as compared to current timeout.

“Synkill” – finite state diagram

“Synkill” – timer events (contd) If chosen value is smaller the legitimate connections may be denied as RSTs are sent after the SYN was observed. SYN+ACK, then trigger the third message of the three-way handshake. An ACK will cause Synkill to reclassify the observed address as good.

Synkill- notion of Staleness Staleness mechanism allows addresses in the good state to leave the good state after no TCP traffic was observed from that address for a period of time, i.e. the staleness period. Synkill correctly classifies spoofed IP addresses as “bad” even if they were once good, now became stale. Implementing Timer mechanisms or Timestamps can be used to determine staleness.

State Machine

Discussion Synkill seems to work perfectly. Is it?? Number of source addresses is very large. Is it possible to maintain state information for such large number of source addresses?

Roadmap Synkill FDS Key Principle TCP Handshake and TCP Data Structure SYN Attack Previous Proposals Synkill Algorithm FDS Discrepancy Between SYN and FIN Attack Detection

Detecting SYN Flooding Attacks Published in IEEE INFOCOM 2002 Haining Wang, Danlu Zhang & Kang G. Shin EECS Department, The University of Michigan

FDS

Roadmap Synkill FDS Key Principle TCP Handshake and TCP Data Structure SYN Attack Previous Proposals Synkill Algorithm FDS Discrepancy Between SYN and FIN Attack Detection

Key Principle SYN and FIN packets are related. In normal TCP sessions the difference between number of SYN and FIN packets is small. In SYN Flooding attack the difference increases dramatically. If attack is detected, apply counter attack mechanisms e.x. Syn Cache, Syn Cookies, Synkill.

Data (reply) + ack of request Client Server Socket, Connect (blocks) (active open) SYN_SENT socket,bind,listen (passive open) accept( blocks) SYN j, mss =1460 SYN K, ack j+1, mss =1024 SYN_RCVD ESTABLISHED Connect returns ack K+1 ESTABLISHED accept returns read (blocks) write read (blocks) Data (request) read returns Data (reply) + ack of request write read (blocks) read returns ack of reply Close (active close) FIN_WAIT_1 FIN M CLOSE_WAIT (passive close) read returns 0 ack M+1 FIN_WAIT_2 FIN M Close LAST_ACK TIME_WAIT ack M+1 CLOSED Slide obtained from [3]

Placement of Detection Mechanism FDS is installed at the first-mile and last mile router First-mile is more likely to catch flooding detection due to proximity to sources. Last-mile quickly detects the flooding but cant provide hint about flooding sources FDS is not installed at core due to a) it is close to neither flooding sources not the victim b) packets of the same flow could traverse different paths Slide obtained from [3]

Slide obtained from [3]

Roadmap Synkill FDS Key Principle TCP Handshake and TCP Data Structure SYN Attack Previous Proposals Synkill Algorithm FDS Discrepancy Between SYN and FIN Attack Detection

Discrepancy btw SYN’s and FIN’s Single RST packet can terminate a TCP session Passive RST transmitted in response to the packet destined for closed port. Active RST transmitted in response to abort a TCP connection and associated with a SYN Normal behavior of TCP:(SYN,FIN), (SYN/ACK,FIN) and (SYN,RSTactive) FDS cannot differentiate between active and passive RST Slide obtained from [3]

Discrepancy btw SYN’s and FIN’s Normal Conditions : SYN and RST have a strong correlation Difference between SYNs and FINs is equal to RSTs Threshold is set at 75%, i.e., 3 out of 4 RSTs are active Slide obtained from [3]

Roadmap Synkill FDS Key Principle TCP Handshake and TCP Data Structure SYN Attack Previous Proposals Synkill Algorithm FDS Discrepancy Between SYN and FIN Attack Detection

Attack Detection Data Sampling and Detection Mechanism SYN and FIN packets collected over time t0 Sampling time of FIN(RST) td later than SYN Recent study : TCP Connections 12-19 sec td set to 10 sec and t0 is set to 20 sec The CUSUM algorithm {∆n,n=0,1,..} Number of SYNs-FINs. {∆n} is Normalized by average number of F of FINs(RSTs) Slide obtained from [3]

Attack Detection Xn = ∆n / F. Xn denoted as C and ranges between 0 and 1. - {yn} large value indicates of an attack. Slide obtained from [3]

Discussion Very Neat Idea. No state maintenance. Doesn’t face problem in differentiating between genuine burst of packets and SYN flood attacks. Any problem ????

Questions || Comments

References C. L. Schuba, I. V. Krusl, M.G. Kuhn, E. H. Spafford, A. Sundaram and D. Zamboni, “Analysis of a Denial of Service Attack on TCP” , Proceedings of IEEE Symposium on Security and Privacy, May 1997 H. Wang, D. Zhang and K.G. Shin, “Detecting SYN Flooding Attacks” , Proceedings of IEEE INFOCOM’ 2002 www.cs.wpi.edu/~rek/Adv_Nets/ Spring2004/SYN_Flooding.ppt