Presentation is loading. Please wait.

Presentation is loading. Please wait.

Christoph L. Schuba, Ivan V. Krsul, Markus G. Kuhn, Eugene H. Spafford, Aurobindo Sundaram, Diego Zamboni. Purdue University. Appeared in proceedings of.

Similar presentations


Presentation on theme: "Christoph L. Schuba, Ivan V. Krsul, Markus G. Kuhn, Eugene H. Spafford, Aurobindo Sundaram, Diego Zamboni. Purdue University. Appeared in proceedings of."— Presentation transcript:

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

2 About Me Anup Mayank Graduate Student in Department of CS&E, UCR

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 client server 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.a System 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.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

17 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

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

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 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. Firewall as a Relay

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

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 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. Active Monitoring

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: 1. Never seen (NULL). 2. Belonging to correctly behaving(good). 3. Potentially Spoofed addresses( New). 4. 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 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.

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. 1. Address is moved to bad state. 2. RST packets are generated and sent for all SYN packets from the address that were observed while the address was in the new state. 3. 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 ClientServer 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 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 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

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

51 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,RST active ) FDS cannot differentiate between active and passive RST Slide obtained from [3]

52 Discrepancy btw SYN’s and FIN’s Normal Conditions : 1) SYN and RST have a strong correlation 2) 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]

53 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

54 Data Sampling and Detection Mechanism SYN and FIN packets collected over time t 0 Sampling time of FIN(RST) t d later than SYN Recent study : TCP Connections sec t d set to 10 sec and t 0 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]

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

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

57 Questions || Comments

58 References 1. 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 H. Wang, D. Zhang and K.G. Shin, “Detecting SYN Flooding Attacks”, Proceedings of IEEE INFOCOM’ Spring2004/SYN_Flooding.ppt

59


Download ppt "Christoph L. Schuba, Ivan V. Krsul, Markus G. Kuhn, Eugene H. Spafford, Aurobindo Sundaram, Diego Zamboni. Purdue University. Appeared in proceedings of."

Similar presentations


Ads by Google