Analysis of a DOS attack on TCP

1. 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, 1997Oakland, CA

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

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

4. 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…………………..

5. How Irritating is DOS?

6. Distributed Dos

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

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

9. 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

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

11. 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….

12. 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

13. 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.

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

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

16. Previous Proposal –1.bRouter 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

17. Previous Proposal –2Infrastructure 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

18. 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 storey for subsequent steps in connection establishment. Else attacker can just send the third message and establish the connection. Again same old solution:- Apply CRYPTOGRAPHY.

19. 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 ………

20. 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?

21. 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.

22. 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

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

24. 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.

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

26. Synkill

27. “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.

28. “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.

29. 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.

30. “Synkill” – finite state diagram

31. “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.

32. Synkill-Observed TCP packets • SYN • TCP packets with the SYN bit set are the initial message of any TCP connection establishment attempt. The state machine is designed to ignoreSYNs 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.

33. “Synkill” – finite state diagram

34. 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.

35. “Synkill” – finite state diagram

36. “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.

37. “Synkill” – finite state diagram

38. “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.

39. 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.

40. State Machine

41. 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?

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

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

44. FDS

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

46. 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.

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

48. 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]

49. Slide obtained from [3]

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