1 / 22

Protecting Commercial and Government Web Sites: The Role of Content Delivery Networks

This article discusses the importance of content delivery networks (CDNs) in protecting commercial and government web sites from various attacks, including large-scale DDoS attacks and SQL injection attacks.

youngs
Download Presentation

Protecting Commercial and Government Web Sites: The Role of Content Delivery Networks

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. Protecting Commercial and Government Web Sites: The Role of Content Delivery Networks • Bruce Maggs • VP for Research, Akamai Technologies

  2. Attacks on Akamai Customers • Typical Attack Size • 10 Gbps 510 Large Attack Size 100+ Gbps 220 Attacks are originating from all geographies and are moving between geographies during the attack 14

  3. The Akamai Platform Provides a Perimeter Defense Origin Server End User Akamai Traffic Origin Traffic 10000 10000 1000 1000 100 100 10 10 1 1

  4. Count the number of Forward Requests Block any IP address with excessive forward requests Defeating HTTP flooding attacks – Rate Controls AkamaiEdge Server Customer Origin Forward Request Client Request X Custom Error page Forward Response

  5. Filtering Out Malformed Requests • SQL injection attacks • Cache busting attacks

  6. Relational databases Relational databases store tables consisting of rows and columns. (image from http://support.sas.com)

  7. Structured Query Language (SQL) Example Query: SELECT * FROM Employees WHERE LName = ’PARKER’; IdNumLNameFNameJobCode Salary Phone 1354 PARKER MARY FA3 65800 914/455-2337

  8. Example SQL Injection Suppose a program creates the following SQL query, where userName is a variable holding input provided by an end-user, e.g., through a form on a Web page. SELECT * FROM Employees WHERE LName = ’” + userName + ”’;” But instead of entering a name like PARKER the user enters ’ or ’1’=’1 Then the query becomes SELECT * FROM Employees WHERE LName = ’’ or ’1’=’1’; This query returns all rows in the Employees table!

  9. A More Destructive Injection Same code as before: SELECT * FROM Employees WHERE LName = ’” + userName + ”’;” But now suppose the user enters a’; DROP TABLE Employees Then the query becomes SELECT * FROM Employees WHERE LName = ’a’; DROP TABLE Employees; This query might delete the Employees table! (Not all databases allow two queries in the same string.)

  10. bobby-tables.com: A guide to preventing SQL injection (from the comic strip xkcd)

  11. Filtering SQL Injection Attacks The CDN filters suspicious-looking inputs, not because the content provider can’t filter them correctly, but because the content provider should not expend resources processing bad inputs.

  12. Cache Busting Idea: The attacker sends multiple requests for the same large object, but with different query strings attached, e.g., http://www.xyz.com/downloads/large_file.pdf?value=asjdfw3be http://www.xyz.com/downloads/large_file.pdf?value=cjsjxassj2 If the CDN cache treats every distinct URL as a unique object, it will have to fetch a new copy of the object from the content provider each time it receives a request with a new query string. Even worse, as Triukose, Al-Qudah, and Rabinovich observe, the CDN might pull the entire object from the content provider at high speed even if the attacker is downloading the object slowly or not at all – thus using the CDN to leverage the client’s attack.

  13. Query String Filtering Solution: At the content provider’s request, the CDN can ignore the query string when identifying the object, i.e., only fetch and cache one copy of the object. (Available for many years.) The CDN can also filter out multiple requests by the same client for a single object with different query strings. The CDN can limit the rate it which it fetches an object from the content provider to the rate at which the client is downloading the object.

  14. Operation Ababil “none of the U.S banks will be safe from our attacks” Phase 1 Phase 3 Phase 2 Dec 12, 2012 – Jan 29 Sep 12 – Early Nov 2012 Late Feb 2013 – Now • DNS packets with “AAAAA” payload • Limited Layer 7 attacks • Early-mid Oct 2012 announced names of banks where attacks succeeded • (Did not announce bank names if attacks were unsuccessful) • Began use of HTTP dynamic content to circumvent static caching defenses • Incorporate random query strings and values • Addition of random query strings against PDFs • Additions to bot army • Burst probes to bypass rate-limiting controls • Addition of valid argument names, random values • Multiple probes • Multiple targets • Increased focus on Layer 7 attacks • Target banks where attacks work • Fraudsters take advantage A layer 7 attack is also known as an application layer attack.

  15. Phase 1 Attack – Sept 2012 Attack Traffic: 23 Gbps (10,000X normal) Duration: 4.5 Hours  DNS Traffic Handled by Akamai 1.8 M 1.6 M • High volume of non-standard packets sent to UDP port 53 • Packets did not include a valid DNS header • Packets consisted of large blocks of repeating “A”s • The packets were abnormally large • Simultaneously, a SYN-Flood was directed against TCP port 53 1.4 M 1.2 M 1.0 M 0.8 M 0.6 M 0.4 M 0.2 M 0.0 s Tues 12:00 Wed 00:00 Wed12:00 Total eDNS

  16. Phase 2 Attacks - January 2nd, 2013 Bank #1 Bank #2 Bank #3 Bank #4 Bank #5 QCF targeted PDF files Akamai Dynamic Caching Rules offloaded 100% of the traffic No Origin Impact

  17. Phase 2 Attacks - January 2nd, 2013 Bank #1 Bank #2 Bank #3 Bank #4 Bank #5 QCF targeted marketing web pages Rate controls automatically activated Attack was deflected, far from bank’s datacenter No Origin Impact

  18. Phase 2 Attacks - January 2nd, 2013 Bank #1 Bank #2 Bank #3 Bank #4 Bank #5 QCF targeted SSL Akamai offloaded 99% of the traffic No Origin Impact

  19. Phase 2 Attacks - January 2nd, 2013 NOT on Akamai Bank #1 Bank #2 Bank #3 Bank #4 Bank #5 Gomez agents in 12 cities measuring hourly 12:03 PM 9:00 AM Error/Outage—site not responding

  20. Phase 2 Attacks - January 2nd, 2013 NOT on Akamai Bank #1 Bank #2 Bank #3 Bank #4 Bank #5 Gomez agents in 12 cities measuring hourly 6:21 PM 12:44 PM Error/Outage—site not responding

  21. Phase 3 Attack Example • Attack started at March 5, 2013 morning • Peak Attack Traffic > 126 thousand requests per second • 70x normal Edge Bandwidth (29Gbps) • Origin Traffic stayed at normal levels • ~2000 Agents participated in the 20 minute assault • 80% of the agents were new IP addresses that had not participated in earlier campaigns

  22. Attack Tactics - Pre-attack Reconnaissance • Attackers test the site with short burst high speed probes • Short bursts of attack requests on non-cacheable content every 10 minutes • Peak of 18 million requests per second • If the site falters, they announce that they will attack that bank and return later with a full scale attack • If the site is resilient they move on

More Related