Post on 21-Dec-2015
Simulation of Adaptive Network Reconfiguration
Under Overwhelming Denial of Service Attack (OUTPACE)
Will Lefevers29 Oct 2010
UCCS
Master of Engineering in Information AssuranceThesis Defense
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
10/29/20102
Outpace/Will Lefevers
Introduction
Problem Domain: Distributed Denial of Service Attacks (DDoS)
Focus: Autonomous Network DefenseAssumptions:
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 part10/29/2010
3Outpace/Will Lefevers
MotivationHard 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
Is there a cheaper/easier alternative?
Can we use the infrastructure we already have in place?
10/29/20104
Outpace/Will Lefevers
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
10/29/2010 6Outpace/Will Lefevers
A Few Steps Beyond ClusteringThe 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 contentMay require a backchannel network to
notify of attacks or send status updates…Does resource replication really solve the problem?
10/29/20107
Outpace/Will Lefevers
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
10/29/2010 8Outpace/Will Lefevers
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 BenefitOverlays push the defense boundary closer to the attacker
10/29/20109
Outpace/Will Lefevers
Changing Gears: Detecting the AttackerAn 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 DefenseUnable to define appropriate responses to
attack indications: “Ok, now what?”10/29/2010 10Outpace/Will Lefevers
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 compromisedNot quite autonomous; signatures have to
come from somewhere10/29/2010 11Outpace/Will Lefevers
Autonomous Network DefenseDesign 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 failure10/29/2010 12Outpace/Will Lefevers
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
10/29/2010 13Outpace/Will Lefevers
The ConfluenceHigh Availability Servers can detect when
they’re overwhelmedDNS can be used instead of a coordinator
to direct traffic to specific serversAttack 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
10/29/2010 14Outpace/Will Lefevers
Scope of the WorkDesign the Proof of Concept (“outpace”)Simulate the System, not a full
implementationAim for reasonably high fidelity of
architecture and equipment simulatedAttempt to define the coordination required
to make this system both autonomous and effective
Define the success and failure conditions of the integrated system design
10/29/2010 15Outpace/Will Lefevers
Design ElementsAttack 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
10/29/2010 17Outpace/Will Lefevers
Attack DetectionHow 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?10/29/2010 18Outpace/Will Lefevers
Attack MitigationWhat do we do when we’re overloaded?
Send new traffic to an unused serverAdvertise a new server via DNS
Require short expiration on DNS A-Records New DNS lookups resolve to the next server in
the poolStop advertising the overloaded server, but
allow connections in progress to complete (more on this later…)
10/29/2010 19Outpace/Will Lefevers
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”
10/29/2010 20Outpace/Will Lefevers
Defense CoordinationWhere 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
10/29/2010 21Outpace/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
Design Walkthrough
Startup Phase: Server1 is overwhelmed
10/29/2010 22Outpace/Will Lefevers
Time: 2
www.mysite.com Server2 (4.3.2.2)
New requests go to server2.
Design Walkthrough (2)
Server1 is working old requests
Startup Phase: Server1 and Server2 are overwhelmed10/29/2010 23Outpace/Will Lefevers
Time: 3
www.mysite.com Server3 (4.3.2.3)
New requests go to server3
Design Walkthrough (3)
Server1 and Server2 are working old requests
Startup Phase: Traffic is starting to spread out.
10/29/2010 24Outpace/Will Lefevers
Time: 4
www.mysite.com Server4 (4.3.2.4)
New requests go to server4
Design Walkthrough (4)
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...
10/29/2010 25Outpace/Will Lefevers
Time: 5
www.mysite.com Server5 (4.3.2.5)
New requests go to server5
Design Walkthrough (5)
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?
10/29/2010 26Outpace/Will Lefevers
Early ObservationsThe longer someone is connected, the
likelier they are to be sinkholedMost attackers will be pointed at sinkholesMost clients will continue to get servicedGiven enough IP addresses, it'll be a while
before a sinkholed address is recycledRamp-off handles itself
When servers stop getting overwhelmed, we stop changing the DNS entries. Clients are happy.
10/29/2010 27Outpace/Will Lefevers
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?
10/29/2010 28Outpace/Will Lefevers
Design IssuesBow-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 sinkholed10/29/2010 29Outpace/Will Lefevers
Outpace2, 3, and 4: ImprovementsAdded 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)
10/29/2010 30Outpace/Will Lefevers
Sample Browser Success Metrics
Dirty Browser Connections: One or more retransmit
Failed Browser Connections: Browser gave up
For stable simulations they converge
10/29/2010 31Outpace/Will Lefevers
Sample Failure Cases
Attackers are ramping up steadily
Clients are getting choked off
Sinkholes aren't catching anything10/29/2010 32Outpace/Will Lefevers
Sample Success Cases
Traffic to sinkholes climbs over time
Browser traffic steadily gets service
Attackers are still there... still trying10/29/2010 33Outpace/Will Lefevers
Outpace Compared To The Baseline
High Stress Scenario: More Attackers Every Round
Outpace Failed Connections
Baseline Failed Connections
Baseline Dirty Connections
Outpace Dirty Connections
10/29/2010 34Outpace/Will Lefevers
ResultsHighly 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 forward10/29/2010 35Outpace/Will Lefevers
Next StepsStatistical 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 GTNetSImplement Outpace Agents and test on
production quality network equipment10/29/2010 36Outpace/Will Lefevers
Conclusions“Network Intelligence” still has a long way to
goAutonomous network defense by
collaborative agents shows promiseBGP sinkholes, rapid DNS updates, and
tight coordination are not a panaceaNetwork Simulation platforms cannot
replace real implementations
10/29/2010 37Outpace/Will Lefevers
Selected ReferencesAND01. 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.
10/29/2010 38Outpace/Will Lefevers