Download “To Filter or to Authorize: Network

“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
Outline







Motivation / Strategy
StopIt Summery
StopIt Design
Prototype Experiment
Defense Solution Comparison
Review
References
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 10million 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.
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
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.

StopIt Summery
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.
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.
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.
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.
StopIt Design
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.
StopIt – Autonomous System (AS)

Is a network or collection of
networks that is controlled by
one administrative entity.


Composed of:




University Network.
StopIt Server
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.
Host Routers
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.

StopIt Architecture
Attacker
StopIt Request
Hs
Ss
Rs
Sd
Rd
Hd
Target
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
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
StopIt - Blocking an Attacker

Hs

Ss

Rs

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.
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.
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.
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.
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

Confirming Attacks

What happens when a destination is compromised?



Host may initiate filters to block legitimate traffic to other colocated 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
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.

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.

Non-StopIt Enabled Sources

StopIt can only block attack traffic at a source when the
source implements StopIt.



Sources using Passport only.



Attack traffic blocked at the destination router.
Attack mitigated with queuing or rate limiting.
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.
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
Prototype Experiment
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)
Proof of Concept Implementation
(Liu et al, 8)
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.

Stopping DoS Attacks
Time it takes for the victim to block N attackers.
(Liu et al, 9)
Defense Solution Comparison
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.
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.

Destination Flooding Test
(Liu et al, 10)
One-Way Link Flood Test
(Liu et al, 10)
Two-Way Link Flood Test
(Liu et al, 11)
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.
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.
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.
Future Enhancements

Complete another iteration of prototype
development.
Implement the StopIt protocol as intended, as an IP
protocol.
 Test on a larger network infrastructure.

References
1.
2.
3.
4.
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.