Presentation is loading. Please wait.

Presentation is loading. Please wait.

Protecting Web Servers from Content Request Floods Srikanth Kandula ▪ Shantanu Sinha ▪ Dina Katabi ▪ Matthias Jacob CSAIL –MIT.

Similar presentations


Presentation on theme: "Protecting Web Servers from Content Request Floods Srikanth Kandula ▪ Shantanu Sinha ▪ Dina Katabi ▪ Matthias Jacob CSAIL –MIT."— Presentation transcript:

1 Protecting Web Servers from Content Request Floods Srikanth Kandula ▪ Shantanu Sinha ▪ Dina Katabi ▪ Matthias Jacob CSAIL –MIT

2 The Attack GET LargeFile.zip DO LongDBQuery www.foo.com Hard to detect or counter because malicious requests look normal! Want to protect DB and disk bandwidth, socket buffers, processes, …

3 User Filter A Fairness Problem – Filters Humans Machines Server Resources Solution – Ensure that each human gets equal share Problem – Each machine gets equal share ●●●

4 Establishing Fairness Use Reverse Turing Test Suspected attack! To access www.foo.com enter the above letters:

5 Under attack. Come back later. Give Me www.foo.com Establishing Fairness Use Reverse Turing Test Suspected attack! To access www.foo.com enter the above letters: Under attack. Come back later. BTW, can solve test to access now. Existing SolsOur Solution

6 2 Modes Common case: Server behavior unchanged Normal UnderAttack

7 Solution Overview Verify SYN Cookie SYN Cookie Ignore! SYN HTTP Request SYNACKACK SYN Cookie TCP RST Send Test Server Unchanged Client Other Characteristics:   One test per session   Tests generated offline   Test expires   Replay attacks are harmless   Each answer grants up to 4 TCPs   Can’t attack by duplicating answers No connection until test answered

8 Solution Overview SYN RECV State Establish Connection SYNACKACK HTTP Request HTTP Response SYNACK SYN Client Server N/W StackApp Server Vulnerable to SYN Floods

9 Solution Overview Create Cookie Establish Connection SYNACKACK HTTP Request HTTP Response SYN Cookie SYN Client Server N/W StackApp Server Common Case Verify Cookie RST SYNACKACK HTTP Request Send Test SYN Cookie SYN Create Cookie Ignore Server N/W StackApp Server Client Send out a test from memory

10 Solution Overview Create Cookie Establish Connection SYNACKACK HTTP Request HTTP Response SYN Cookie SYN Client Server N/W StackApp Server Verify Cookie & Answer SYNACKACK Test Answer SYN Cookie SYN Create Cookie Ignore Client Server N/W StackApp Server HTTP Response Common CaseGrant access if answer is correct Tests are generated offline

11 Verify Cookie RST SYNACKACK HTTP Request Send Test SYN Cookie SYN Solution Overview Server behavior unchanged (Common case)   Create session after a correct answer   Up to 4 TCP connections per answer   One test per browsing session   Tests generated offline Create Cookie Ignore Client Server N/W StackApp Server

12 Solution Overview Server behavior unchanged (Common case)   Create session after a correct answer   Up to 4 TCP connections per answer   One test per browsing session   Tests generated offline Verify Cookie & Answer SYNACKACK Test Answer SYN Cookie SYN Create Cookie Ignore Client Server N/W StackApp Server HTTP Response

13 Extra – What If? User doesn’t want to solve the test? Attacker distributes a few answers to all worms? Each test allows access to limited resources Give Me www.foo.com Under attack. Come back later. BTW, solve the test to access now. Under attack. Come back later.

14  None when there is no attack  Under attack, per new-client overhead Two hashes In-kernel HTTP header parse Fetch two data packets from memory and transmit Extra System Overhead

15  Time constraints  Harder resource constraints Even a TCP connection cannot be established before test is answered  Other Preserve TCP / HTTP semantics Maintain HTTP sessions Support caches and web farms Yahoo/Hotmail method is not sufficient! Extra – Requirements

16 Extra Fairness  Problem – A single human attacker uses more server resources than a human user  Insight – Each machine gets equal share  Solution – Each human user gets a fair share DB Query Large File

17 Extra - Our Approach Reverse Turing Test to distinguish humans from machines Limits an attack to the number of human attackers [screenshot of yahoo image test] used by yahoo to prevent hard disk space utilization

18  Attacker spreads a worm  Worm floods server with requests for large files or database queries worker processes/threads, socket buffers database and disk bandwidth Hard to detect or counter because malicious requests look normal! Extra - The Attack

19  Cryptographic Client puzzles Computation power is cheap in DDoS attacks  IP source filtering AOL clients use same IP address pool Extra - Better than

20 Extra - Our Objective  Build a practical system to mitigate these attacks Unmodified clients Unmodified server software Deployable today

21 Establishing Fairness Use Reverse Turing Test Suspected attack! To access www.foo.com enter the above letters: Different from Prior Work   Crypto puzzles are easy since computation power is cheap   Yahoo! only protects disk space during account creation   We want to receive requests, deliver puzzles, validate answers before establishing a TCP connection

22 Establishing Fairness Use Reverse Turing Test Suspected attack! To access www.foo.com enter the above letters: Give Me www.foo.com BTW, solve the test to access now. Under attack. Come back later. BTW, solve the test to access now. Users who Solve a Test can access the server Under attack. Come back later. Yahoo uses RTT to protect disk space We receive requests, serve tests, validate answers before establishing a TCP connection


Download ppt "Protecting Web Servers from Content Request Floods Srikanth Kandula ▪ Shantanu Sinha ▪ Dina Katabi ▪ Matthias Jacob CSAIL –MIT."

Similar presentations


Ads by Google