Simulation of Adaptive Network Reconfiguration Under Overwhelming Denial of Service Attack (OUTPACE)

1. Will Lefevers 29 Oct 2010 UCCS Master of Engineering in Information Assurance Thesis Defense Simulation of Adaptive Network Reconfiguration Under Overwhelming Denial of Service Attack (OUTPACE)

2. Outpace Agenda Introduction and Motivation Review of Autonomous Network Defense Research Advances Goals, Inspiration, and Scope Critical Design Elements Outpace Design Design Issues and Sample Metrics Simulation Results Next Steps Conclusions References Demo Outpace/Will Lefevers

3. Introduction Problem Domain: Distributed Denial of Service Attacks (DDoS) Focus: Autonomous Network Defense Assumptions: Attacks are Centrally Controlled Attacks Focus on Consuming Bandwidth Attack Payload is Large and Asymmetric Attacks are Protocol Conforming (i.e., Distributed Reflector DOS)  the hard part Outpace/Will Lefevers

4. Motivation Hard Problem. Commercial Solutions are Expensive and Somewhat Ineffective Require massive infrastructure investment Take over/control your backbone network Still can’t tell which traffic is “bad” for your site Arbornet/Akamai-class Vendors Outpace/Will Lefevers Is there a cheaper/easier alternative? Can we use the infrastructure we already have in place?

5. Taxonomy of DDoS Defenses Outpace/Will Lefevers Mirckovic Et Al, 2002

6. Early Network Reconfiguration Methods Traffic  Intrusion Detection System  New Firewall Rule Requires accurate and timely feedback IDS signatures out of date and easily bypassed Single Point of Failure: Firewall Load Balancing / High Availability Clusters More resources to absorb the attack Could be used with IDS/Firewall systems Single Point of Failure: Coordinator Outpace/Will Lefevers

7. A Few Steps Beyond Clustering The XenoService (proposed) ISPs subscribe to a service which replicates their content to other sites when attacked Multiple copies of your site would keep your content available throughout the attack Sort of an on-demand Edge Network / CDN Only effective for static content May require a backchannel network to notify of attacks or send status updates Outpace/Will Lefevers …Does resource replication really solve the problem?

8. Can We Hide Our Resources? Roaming Honeypots Approach Unused servers in the server pool become a honeynet: part of our IDS/IPS system If we aren’t advertising them for use, any traffic that hits them must be attack traffic Unpredictable to attacker! How many are real? Still requires the use of a firewall to filter inbound traffic More effective than clustering or firewalling alone – early network self-reconfiguration Outpace/Will Lefevers

9. Can We Control What Traffic Reaches Us? Resilient Overlay Networks (RON) Essentially a VPN mesh on top of the internet Owner controls the entry and exit points Direct your own traffic, shape it, filter it Entry/Exit Nodes become the failure point Dynamic Internet Overlay Deployment and Management using the X-Bone RON with resilience and some security features “Dis-Invite” participants and Entry/Exit Nodes Huge Resource Outlay For Marginal Benefit Outpace/Will Lefevers Overlays push the defense boundary closer to the attacker

10. Changing Gears: Detecting the Attacker An Architecture for Intrusion Detection with Autonomous Agents(AAFID) Autonomous sensors inside our network report behaviors back to the owner/operator No defined response actions, redundancy issues Fixed location agents can be bypassed Distributed Network Defense (DND) Fixed and Roving Agents have roles like Data Gatherer, Investigator, and Defense Unable to define appropriate responses to attack indications: “Ok, now what?” Outpace/Will Lefevers

11. How Intelligent Can Detection Get? CONFIDANT: Collaborative Object Notification Framework for Insider Defense using Autonomous Network Transactions Sophisticated defense strategy for identifying suspect systems and quarantining them Sensor, Control, and Alarm elements form a collaborative network-wide IDS Relies on signatures or behaviors to inform the operator which systems/files are compromised Not quite autonomous; signatures have to come from somewhere Outpace/Will Lefevers

12. Autonomous Network Defense Design of an Autonomous Anti-DDoS Network (A2D2) Class-Based Queuing rules get modified by IDS input: Rules will reflect the type of attack Rules expire when the attack subsides No ramp-on/Ramp-off penalty Can be overwhelmed by large ramp-up Fully integrated anomaly detection, response, and recovery actions Multiple single points of failure Outpace/Will Lefevers

13. What Should Autonomous DDoS Defense Do? Recognize Attack Traffic Quickly/Accurately Like AAFID, DND, CONFIDANT Drop Traffic As Far From Us As Possible Like RON, X-BONE, Others No Single Point of Failure Like Xenoservice Make Defense Strategy Hard To Side-Step Like Roaming Honeynets Make Roll-On and Roll-Off Seamless Like A2D2 Outpace/Will Lefevers

14. The Confluence High Availability Servers can detect when they’re overwhelmed DNS can be used instead of a coordinator to direct traffic to specific servers Attack traffic can be dropped at the backbone if customer-driven Border Gateway Protocol Sinkholes are configured Protocol-conforming DDoS attacks could be mitigated autonomously if these elements are carefully coordinated to work in concert Outpace/Will Lefevers

15. Scope of the Work Design the Proof of Concept (“outpace”) Simulate the System, not a full implementation Aim for reasonably high fidelity of architecture and equipment simulated Attempt to define the coordination required to make this system both autonomous and effective Define the success and failure conditions of the integrated system design Outpace/Will Lefevers

16. Network Topology Assumptions Outpace/Will Lefevers

17. Design Elements Attack Detection Internal Web Servers Attack Mitigation BGP Routers on the Backbone Service Advertisement External DNS Servers Defense Coordination Agents within each of the other elements Outpace/Will Lefevers

18. Attack Detection How do we know we’re being attacked? Reliable Metrics Individual Servers’ Load Metrics TCP Queue/Drop Counts External Traffic Monitoring Equipment Measures of Simulation Success/Failure What proportion of total traffic is sinkholed? What proportion is getting serviced? What proportion of legitimate web clients are getting service? Outpace/Will Lefevers

19. Attack Mitigation What do we do when we’re overloaded? Send new traffic to an unused server Advertise a new server via DNS Require short expiration on DNS A-Records New DNS lookups resolve to the next server in the pool Stop advertising the overloaded server, but allow connections in progress to complete (more on this later…) Outpace/Will Lefevers

20. Attack Mitigation (2) How do we kill traffic when a server has been overwhelmed? Add a BGP Sinkhole route for the dead server’s IP address Keep track of which IPs are in the “dead” pool Change the IP address of the dead server to any open IP in our block Add the server’s new IP into the “available” pool while keeping its’ old IP in the “dead” pool When we run out of “available” IPs, delete the oldest “dead” IP’s sinkhole route and mark it “available” Outpace/Will Lefevers

21. Defense Coordination Where does the coordinator live? Agents must exist in: Web Servers to tell us they’re overloaded DNS Servers to maintain timing and rate-limit the changes Our BGP Router to add and delete sinkhole routes for our AS (Autonomous System) Note: An AS may only advertise routes within its’ Advertised IP Blocks Attackers, Legitimate Clients, other DNS servers are unwitting players in the game Outpace/Will Lefevers

22. Design Walkthrough Outpace/Will Lefevers Time: 1 www.mysite.com  Server1 (4.3.2.1) Attackers and Web Clients are intermixed on the same networks BGP Routers are configured to sinkhole, but have no rules Startup Phase: Server1 is overwhelmed

23. Design Walkthrough (2) Outpace/Will Lefevers Time: 2 www.mysite.com  Server2 (4.3.2.2) New requests go to server2. Server1 is working old requests Startup Phase: Server1 and Server2 are overwhelmed

24. Design Walkthrough (3) Outpace/Will Lefevers Time: 3 www.mysite.com  Server3 (4.3.2.3) New requests go to server3 Server1 and Server2 are working old requests Startup Phase: Traffic is starting to spread out.

25. Design Walkthrough (4) Outpace/Will Lefevers Time: 4 www.mysite.com  Server4 (4.3.2.4) New requests go to server4 Servers 1, 2, 3 are working old requests Browser connections get a new server, get service, finish. Attackers connect, send or receive huge payloads, stay connected...

26. Design Walkthrough (5) Outpace/Will Lefevers Time: 5 www.mysite.com  Server5 (4.3.2.5) New requests go to server5 Our BGP Router adds a sinkhole route for server1's old IP. Peer Routers will route 4.3.2.1 --> /dev/null. We now have a sinkhole! Attackers were still connected to 4.3.2.1. It appears to be down. No clients should still be connected. Success?

27. Early Observations The longer someone is connected, the likelier they are to be sinkholed Most attackers will be pointed at sinkholes Most clients will continue to get serviced Given enough IP addresses, it'll be a while before a sinkholed address is recycled Ramp-off handles itself When servers stop getting overwhelmed, we stop changing the DNS entries. Clients are happy. Outpace/Will Lefevers

28. Design Issues Connection Timing We have to allow clients to be connected long enough to get service and complete their request We have to allow for clients on slower connections We have to allow for local delays (DNS, LAN Latency, CPU/RAM, etc) Server Exposure Window How long can we leave a server exposed? Do we have to wait until the next server is overwhelmed? Outpace/Will Lefevers

29. Design Issues Bow-Wave Effect When the DDoS hits, each server will be overwhelmed and drop traffic until we can start aging out the first servers Clients will probably not get service during the startup period Some may be serviced intermittently and have to keep re-DNSing for a fresh server Some clients will leave the site entirely Service continues to get better as a larger and larger proportion of attackers are sinkholed Outpace/Will Lefevers

30. Outpace2, 3, and 4: Improvements Added controls for: Number of servers and attacker/clients Attacker to client ratio Number of servers exposed/dead at one time DNS check interval Random wait-to-start times Max start time Server Queue Limits Disabling Outpace all together Max DNS updates per period (Throttling) Outpace/Will Lefevers

31. Sample Browser Success Metrics Outpace/Will Lefevers Dirty Browser Connections: One or more retransmit For stable simulations they converge Failed Browser Connections: Browser gave up

32. Sample Failure Cases Outpace/Will Lefevers Attackers are ramping up steadily Clients are getting choked off Sinkholes aren't catching anything

33. Sample Success Cases Outpace/Will Lefevers Traffic to sinkholes climbs over time Browser traffic steadily gets service Attackers are still there... still trying

34. Outpace Compared To The Baseline Outpace/Will Lefevers High Stress Scenario: More Attackers Every Round Baseline Failed Connections Baseline Dirty Connections Outpace Dirty Connections Outpace Failed Connections

35. Results Highly effective in mitigating Protocol-Conforming Distributed Denial of Service Attacks (Larger Attack: Better Performance) Best performance was achieved when: Significantly more IP addresses than servers Attacker-Client Ratios are high (>100:1) 1/3 servers exposed, 2/3 dead, Low DNS TTL Adding servers resulted in diminishing returns beyond 16-32 servers Optimal rate found when only the advertised server can advance DNS forward Outpace/Will Lefevers

36. Next Steps Statistical analysis of optimal “exposed” time as a function of: Rate of DNS changes while under attack Average client service time Average client connection size (total data) Feedback function based on number of DNS new requests (ie, project future load) Implement realistic BGP in GTNetS Implement Outpace Agents and test on production quality network equipment Outpace/Will Lefevers

37. Conclusions “Network Intelligence” still has a long way to go Autonomous network defense by collaborative agents shows promise BGP sinkholes, rapid DNS updates, and tight coordination are not a panacea Network Simulation platforms cannot replace real implementations Outpace/Will Lefevers

38. Selected References AND01. Andersen, D. and Balakrishnan, H. and Kaashoek, F. and Morris, R. 2001. Resilient Overlay Networks. ACM. BAL98. Balasubramanian et al. 1998. Architecture for Intrusion Detection with Autonomous Agents. CER02. Cerns, Angela. 2002. Design Of An Autonomous Anti-DDOS Network (A2D2). FRI01. Frincke, D and Wilhite, E. 2001. Distributed Network Defense. GRE02. Greene, Barry Raveendran. 2002. Remote Triggering Black Hole Filtering Supplement to the Existing Section on Black Hole Filtering. CISCO. KHA04. Khattab, Sherif M. and Sangpachatanaruk, Chatree and Moss, Daniel and Melhem, Rami and Znati, Taieb. Roaming Honeypots for Mitigating Service-level Denial-of-Service Attacks. MIR02. Mirkovic, J and Martin, J and Reiher, P. 2002. A Taxonomy of DDoS Attacks and DDoS Defense Mechanisms. OPP06. Oppleman, V. 2006. Network Defense Applications using IP Sinkholes. Hakin9 Magazine. PIN06. Pingali, V. K. and Touch, J. D. 2006. Protecting Public Servers from DDoS Attacks Using Drifting Overlays. ROC05. Rocke, A J and DeMara, R F. 2005. CONFIDANT: Collaborative Object Notification Framework for Insider Defense using Autonomous Network Transactions. TOU02. Touch, Joe. 2000. Dynamic Internet Overlay Deployment and Management Using the X-Bone. VAU06. Vaughn, R. and Evron, G. 2006. DNS Amplification Attacks. WAN03. Wang, Ju and Lu, Linyuan. 2003. Tolerating Denial-of-Service Attacks Using Overlay Networks - Impact of Overlay Network Topology. UCSD. WEN04. Wensong. 2004. LVS defense strategies against DoS attack. YAN00. Yan, Jianxin and Early, Stephen and Anderson, Ross. 2000. The XenoService – A Distributed Defeat for Distributed Denial of Service. Outpace/Will Lefevers

39. Demo! Outpace/Will Lefevers