“ To Filter or to Authorize: Network-Layer DoS Defense Against Multimillion-node Botnets ”

1. “To Filter or to Authorize: Network-Layer DoS Defense Against Multimillion-node Botnets” Xin Liu, Xiaowei Yang, Yanbin Lu Department of Computer Science, University of California, Irvine Published: SIGCOMM 2008 Conference Presented by: Christopher Daiello Presented on: March 26, 2009 CAP 6135 Malware and Software Vulnerability Analysis (Spring 2009) Professor: Dr. Cliff Zou

2. Outline • Motivation / Strategy • StopIt Summery • StopIt Design • Prototype Experiment • Defense Solution Comparison • Review • References

3. Motivation • Botnets continue to be a rising threat. • In September 2007, the Storm botnet alone reached 50 million compromised hosts. • If each host sends one full packet (1500 bytes), a 10-million botnet would exceed 120 Gbps, enough to take down any site on the internet. • Many solutions have been proposed to combat this problem, however there lacks a consensus on how to build a DoS resistant network.

4. Botnet Defensive Strategies • Capability Approach • Receiver controls the traffic it receives. • Explicitly authorizes the traffic it receives. • Popular capability-based systems: TVA and Portcullis • Filter Approach • Receiver allows all traffic until it detects a problem. • Receiver limits attack traffic by dynamically installing filters. • Popular filter-based systems: AITF and Pushback

5. Which strategy is more effective? • Capability Design vs Filter Design? • Current filter-based solutions have limitations that prevent a fair comparison. • AITF verifies filter install requests with a 3-way handshake. Verification communication may get blocked by attack traffic. • Pushback uses rate limiting (instead of completely blocking) to combat attack traffic.

6. StopIt Summery

7. StopIt • Filter-based approach design. • Closed-control and open-service architecture. • Allows any receiver to block undesirable traffic. • Mitigates link congestion. • Resistant to filter exhaustion attacks. • Resistant to bandwidth flooding attacks that could prevent the installation of filters.

8. StopIt Design Assumptions • Secure Intra-AS Communication – Communication between components within the AS (Autonomous System) is secured. • Attack Traffic Classification – Target systems can identify when they are being attacked. • Feasible – Design is efficient enough to operate on current routers. Public key cryptography is not used at packet forwarding due to high processing costs.

9. StopIt Goals • Effective Filtering – Filters installed to protect a host machine should not prevent other hosts from communicating with legitimate sources. • Secure the defense system itself! • Strategic attacks – Attacks aimed to defeat or abuse the system • Destination Flood Attacks – Flood the system with traffic to suppress communication. • Link Flood Attacks – Congest a link to disrupt communications between systems that share that link.

10. StopIt Goals • Fail-Safe – System should provide degraded service in the event filters fail to mitigate attack traffic. • Incremental Deployment – System should support incremental deployment and give immediate results to early adopters.

11. StopIt Design

12. StopIt Architecture • Infrastructure Service • Open-services : any host co-located with the server may request services. • Hosts request StopIt to block attacking traffic. • Filter-based implementation • Source and destination address used to create the filter. • Attack traffic is blocked for a period of time Tb. • Attack traffic confirmed before the installation of blocking filters. • Filter aggregation – compromised hosts share a common address space.

13. StopIt – Autonomous System (AS) • Is a network or collection of networks that is controlled by one administrative entity. • University Network. • Composed of: • StopIt server • N number of routers/servers • Routers alert StopIt server when a host makes a block request. • StopIt server directs routers as to which filters to install. StopIt Server Host Routers

14. StopIt Communication • StopIt servers communicate with each other to alert of a potential attacking host. • Each StopIt server knows the address of other StopIt servers. • StopIt design uses BGP (Border Gateway Protocol) to publish the address of each StopIt server. • StopIt implements its own IP protocol for communication between servers and AS routers.

15. StopIt Architecture Attacker StopIt Request Hs Sd Ss Rd Rs Hd Target

16. StopIt – Blocking an Attacker • Destination host (Hd) determines it is under attack by source (Hs). • Hd sends a host-router “stop” request to router Rd. • The request includes: • Attack Source MAC • Host MAC • Block Time Tb Sd Rd Hd

17. StopIt - Blocking an Attacker • Router Rd verifies the that Hs is in fact attacking Hd. • Upon confirmation, Rd sends a router-server request to local AS StopIt server (Sd). • Sd sends an inter-domain stop request to the StopIt server in the same AS where Hs is located. Sd Rd Hd

18. StopIt - Blocking an Attacker • Ss locates router Rs and sends a server-router request. • Rs verifies the StopIt request and then installs a filter. • Finally, Rs sends a request to Hs to stop sending traffic to Hd • Compliant hosts will comply to the StopIt request. Hs Ss Rs

19. Securing StopIt • Basic StopIt Architecture Vulnerabilities • Source address spoofing – attacker may spoof address to avoid detection / filtering. • Resource Exhaustion • Flood filtering requests to overload StopIt server and routers • Exhaust router’s filters – no more filters available to block DoS attacks. • Block legitimate traffic – compromised StopIt server requests filters for legitimate traffic.

20. Source Authentication • StopIt utilizes Passport to prevent source address spoofing. • Passport uses symmetric key cryptography. • Authentication overhead is equivalent to the authentication used in capability-based system. • Border routers at the destination AS verify the source AS before the packet enters the network. • Pair-wise keys between two AS are exchanged during the BGP announcement.

21. Closed Control • Routers receive StopIt requests from: • Local nodes to the AS • Another StopIt server. • This prevents stop request floods from unknown sources. • If the request is ultimately classified as attack traffic, the router can make a stop request.

22. Packet Floods • Flooding a common link between two domains could potentially suppress StopIt requests from being received. • Routers have knowledge of StopIt server addresses via BGP. • Routers Separate StopIt requests from other traffic • Fair Queuing • Hierarchical Rate Limiting

23. Confirming Attacks • What happens when a destination is compromised? • Host may initiate filters to block legitimate traffic to other co-located hosts. • Exhaust a source router’s filters so that attack traffic can successfully suppress hosts. • Who needs to be verified? • Destination Router • Source Router • Source

24. Confirming Attacks • Destination Router Confirmation • Router, Rd checks internal flow cache upon receiving a stop request from Hd • If Hd received traffic recently from Hs the router will install a local filter. • Router sends a StopIt request directly to Hs • If Hs does not comply, Rd notifies the local StopIt server of the attacking traffic.

25. Confirming Attacks • Source Router Confirmation • Source Routers Rs also use a flow cache to confirm a legitimate stop request • Rs installs filters to block the misbehaving host. • Verification protects the source from invalid filter requests from a compromised Hd or another StopIt server.

26. Non-StopIt Enabled Sources • StopIt can only block attack traffic at a source when the source implements StopIt. • Attack traffic blocked at the destination router. • Attack mitigated with queuing or rate limiting. • Sources using Passport only. • Destination AS can confirm source of attacking traffic. • Passport prevents source from using address spoofing. • Sources have incentive to implement StopIt to isolate possible congestion from compromised hosts.

27. Deploying StopIt • Upgrade routers to use Passport for source authentication. • Upgrade routers to utilize the StopIt protocol. • Add StopIt server to AS. • Enable per-AS and per-host resource allocation scheme at congested network links. StopIt Server Host Routers

28. Prototype Experiment

29. Proof of Concept Implementation • Access Router Prototype • Linux • Click modular router software architecture • User-level application for source logic. • Authentication for Inter-Domain StopIt requests or filter replacement requests use, UHASH, AES, and UMAC. • StopIt protocol built on top of UDP. (Liu et al, 8)

30. Proof of Concept Implementation (Liu et al, 8)

31. Stopping DoS Attacks • Scenario Inputs • Destination router filters : 256K • End-to-End StopIt requests : 3 • For confirming an actual attack • Attacker host simulates 1 to 10 million attackers • Each attack repeats 10 times.

32. Stopping DoS Attacks Time it takes for the victim to block N attackers. (Liu et al, 9)

33. Defense Solution Comparison

34. Comparing Anti-DoS Solutions • StopIt design implemented in ns-2 : The Network Simulator • StopIt tested against: • AITF, Pushback (capability-based) • TVA, TVA+, and Portcullis (filter-based) • Scenario topology created from BGP table dump. • Used 1/20 of topology due to ns-2 limitations. • 2/3 AS have attacking hosts, non-uniformly distributed.

35. Comparing Anti-DoS Solutions • Test three types of attacks: • Destination Flooding • One-Way Link Flooding • Two-Way Link Flooding • Testing Metric • TCP Transfer performance • Legitimate user sends one 20KB transfer to the designated victim. • TCP transfer is aborted after 25 seconds.

36. Destination Flooding Test (Liu et al, 10)

37. One-Way Link Flood Test (Liu et al, 10)

38. Two-Way Link Flood Test (Liu et al, 11)

39. Comparison Summery • StopIt design outperforms many of the currently existing DoS defense architectures. • StopIt does not outperform capability based solutions in all types of DoS attacks. • Neither solution, filter or capability, has shown a definitive edge over the other. • The best solution maybe a hybrid design.

40. Contributions • A thorough analysis of the DoS problem domain. • A complete high level design to a potential solution for destination and link flood DoS attacks. • A convincing comparison between StopIt and other currently available filter/capability solutions.

41. Weaknesses • Description of prototype implementation was fairly brief. • Prototype testing only utilized one host to simulate multiple attackers. Larger scale testing should be conducted. • Internet wide deployment will make updating software challenging. Software must remain backwards compatible with earlier versions. • Full deployment of solution required to fully realize the benefits of the StopIt design.

42. Future Enhancements • Complete another iteration of prototype development. • Implement the StopIt protocol as intended, as an IP protocol. • Test on a larger network infrastructure.

43. References • Border Gateway Protocol (BGP). Cisco. http://www.cisco.com/en/US/docs/internetworking/technology/handbook/bgp.html • The Network Simulator – ns-2. http://www.isi.edu/nsnam/ns/ • Autonomous System (Internet). Wikipedia. http://en.wikipedia.org/wiki/Autonomous_system_(Internet) • Liu, Xin; Yang, Xiaowei; Lu, Yanbin; “To Filter or to Authorize: Network-Layer DoS Defense Against Multimillion-node Botnets”. SIGCOMM ’08. August 17-22, 2008.