To Filter or to Authorize: NetworkLayer DoS Defense Against Multimillionnode 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 routers 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 routers 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/te
  chnology/handbook/bgp.html
• The Network Simulator ns-2. http//www.isi.edu/n
  snam/ns/
• Autonomous System (Internet). Wikipedia.
  http//en.wikipedia.org/wiki/Autonomous_system_(In
  ternet)
• 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.