simulation of adaptive network reconfiguration under overwhelming denial of service attack (outpace)...

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


Taxonomy of DDoS Defenses

Mirckovic Et Al, 2002

10/29/20105


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


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


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


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


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


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


Network Topology Assumptions


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


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…)


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”


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


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


Time: 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


New requests go to server3


Server1 and Server2 are working old requests

Startup Phase: Traffic is starting to spread out.


Time: 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...


Time: 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?


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.


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?


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)


Sample Browser Success Metrics

Dirty Browser Connections: One or more retransmit

Failed Browser Connections: Browser gave up

For stable simulations they converge


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


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


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.


Demo!


simulation of adaptive network reconfiguration under overwhelming denial of service attack (outpace)...

Documents

outpacewill lefevers

backbone network

backchannel network

inbound traffic

traffic unpredictable

controlled attacks

asymmetric attacks

attack sort