1 / 8

0x1A Great Papers in Computer Security

CS 380S. 0x1A Great Papers in Computer Security. Vitaly Shmatikov. http://www.cs.utexas.edu/~shmat/courses/cs380s/. D. Bernstein SYN cookies (1996). TCP Handshake. C. S. SYN C. Listening…. Spawn a new thread, store data (connection state, etc.). SYN S , ACK C. Wait. ACK S.

vito
Télécharger la présentation

0x1A Great Papers in Computer Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 380S 0x1A Great Papers inComputer Security Vitaly Shmatikov http://www.cs.utexas.edu/~shmat/courses/cs380s/

  2. D. BernsteinSYN cookies(1996)

  3. TCP Handshake C S SYNC Listening… Spawn a new thread, store data (connection state, etc.) SYNS, ACKC Wait ACKS Connected

  4. SYN Flooding Attack S SYNC1 Listening… Spawn a new thread, store connection data SYNC2 SYNC3 … and more SYNC4 … and more … and more SYNC5 … and more … and more

  5. SYN Flooding Explained • Attacker sends many connection requests with spoofed source addresses • Victim allocates resources for each request • New thread, connection state maintained until timeout • Fixed bound on half-open connections • Once resources exhausted, requests from legitimate clients are denied • This is a classic denial of service attack • Common pattern: it costs nothing to TCP initiator to send a connection request, but TCP responder must spawn a thread for each request - asymmetry!

  6. Preventing Denial of Service • DoS is caused by asymmetric state allocation • If responder opens new state for each connection attempt, attacker can initiate thousands of connections from bogus or forged IP addresses • Cookies ensure that the responder is stateless until initiator produced at least two messages • Responder’s state (IP addresses and ports of the con-nection) is stored in a cookie and sent to initiator • After initiator responds, cookie is regenerated and compared with the cookie returned by the initiator

  7. SYN Cookies [Bernstein and Schenk] C S SYNC Listening… Compatible with standard TCP; simply a “weird” sequence number Does not store state SYNS, ACKC sequence # = cookie F(source addr, source port, dest addr, dest port, coarse time, server secret) Cookie must be unforgeable and tamper-proof (why?) F=Rijndael or crypto hash 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. Anti-Spoofing Cookies: Basic Pattern • Client sends request (message #1) to server • Typical protocol: • Server sets up connection, responds with message #2 • Client may complete session or not - potential DoS! • Cookie version: • Server responds with hashed connection data instead of message #2 • Client confirms by returning hashed data • If source IP address is spoofed, attacker can’t confirm • Need an extra step to send postponed message #2, except in TCP (SYN-ACK already there)

More Related