Analyzing%20Network%20Traffic%20in%20the%20Presence%20of%20Adversaries

1
Analyzing Network Traffic in the Presence of
Adversaries

• Vern Paxson
• International Computer Science Institute /
  Lawrence Berkeley National Laboratory
• vern_at_icsi.berkeley.edu / vern_at_ee.lbl.gov
• October 18, 2004

2
Roadmap

• In todays Internet, attacks are the norm
• Adversaries can create fundamental problems for
  network traffic analysis
• 1 problem evasion by ambiguity
• Active mapping to resolve ambiguities
• Normalization to eliminate ambiguities
• 2 flooding directed at network devices
• How to design robust analysis hardware

3
80 growth/year
Data courtesy of Rick Adams
4
60 growth/year
5
596 growth/year
6
596 growth/year
Courtesy Mark Dedlow
7
In Todays InternetAttacks are the Norm

• Great interest in watching network traffic and
  analyzing what its doing
• Watching monitor traffic at chokepoints, capture
  copy or perhaps intercept
• Analyzing reconstruct protocol layers as seen by
  endpoints, interpret semantics
• How hard can it be?
• Attackers are adversaries they dont want to be
  caught and they want to make it painful for us to
  operate

8
The Problem of Evasion

• Evasion raises fundamental problems
• Network traffic seen from within a network is
  inherently ambiguous.
• Analyzing network traffic at a high semantic
  level requires extensive state which an
  adversary can target.
• Consider a network intrusion detection system
  (IDS Bro) detecting occurrences of the string
  root inside a network connection
• (Lets disregard the wholly separate issue of
  false positives whether this is a good
  signature)

9
Detecting root Attempt 1

• Method scan each packet for r, o, o, t
• Perhaps using Boyer-Moore, Aho-Corasick, Bloom
  filters

But TCP protocol doesnt preserve text boundaries
10
Detecting root Attempt 2

• Method remember match from end of previous
  packet

- Now were managing state
11
Detecting root Attempt 3

• Method reassemble entire byte stream
• Keep track of full TCP connection state
• So much for simple
• What happens if we run out of memory?
• And
• Still evadable

12
Evading Detection ViaAmbiguous TCP Retransmission
13
Evading Detection ViaAmbiguous TCP Retransmission
14
Its Not Just TTL Expiration

• Systematic study (w/ M. Handley C. Kreibich) to
  analyze ambiguous protocol fields
• 73 exploitable ambiguities IP/TCP/UDP/ICMP
• E.g control flags, flow control window, dont
  fragment, old timestamps, service class,
  redundant length field, filtering on unused bits
• Internet protocols not designed for analysis
• Attacker toolkits already exist for exploiting
  these
• Answer alert upon seeing ambiguous traffic?

15
The Problem of Crud

• Unfortunately, ambiguities occur in benign
  traffic, too
• Legitimate tiny fragments, overlapping fragments
• Receivers that acknowledge data they did not
  receive
• Senders that retransmit different data than
  originally
• In a diverse traffic stream, you will see these
• What is the intent?
• Loss of alert precision ? Maybe theres an
  attack

16
Countering Evasion-by-Ambiguity Active Mapping

• Idea (w/ Umesh Shankar, UCB) Probe end-host in
  advance to resolve vantage-point ambiguities
• E.g., how many hops to it?
• E.g., how does it resolve ambiguous
  retransmissions?
• Gray-box testing

17
Mapping Setup
18
Grey-box Inference of Reassembly Policy
19
A Plethora of Inferred Policies
20
Issues for Active Mapping

• Probing for most ambiguities requires eliciting a
  response
• Some hosts wont respond when not actively
  engaged
• For some responses, need to trick host into
  echoing back what it saw
• Have to take churn into account
• At a large site, somethings always changing
• Lack of identity due to NAT, DHCP
• Our implementation takes 5 sec/host

21
Countering Evasion-by-Ambiguity Normalization

• Idea (w/ Mark Handley, Christian Kreibich)
  Introduce network element to rewrite traffic
  passing through it to eliminate ambiguities
• E.g., regenerate low TTLs (dicey!)
• E.g., regularize flags, unused fields
• E.g., trim out-of-window data
• E.g., reassemble streams remove inconsistent
  retransmissions

22
Issues for Normalization

• Effect on end-to-end semantics?
• Some normalizations harmless (e.g., inconsistent
  streams)
• Some actually improve protocol (e.g., reliable
  RSTs)
• Some degrade performance in the presence of cold
  start (e.g., stripping TCP window scaling)
• Performance element is in-line
• Prototype (1.1 GHz) 400 Mbps
• Would like to use custom hardware

23
Robust Hardware for Analyzing Traffic in the
Presence of Adversaries

• Ongoing work w/ Sarang Dharmapurikar (WUSTL)
• Basic building-block for boosting network
  analysis in-line TCP stream reassembly
• If data arrives in-sequence, hand it to analyzer
  module
• If data arrives out-of-sequence, it creates a
  hole
• Buffer for later delivery
• How hard can it be?

24
How Much Buffer for HolesDo We Need?

• Most previous work says Zero
• Skip out-of-sequence packets
• Commercial work says Yes
• Claim out-of-sequence packets buffered, but with
  no details
• Answer for sound operation depends critically on
  whether we consider adversaries

25
Measured Buffer Required Per-Hole
26
Measured Duration of Holes
27
Instantaneous Aggregate Hole Buffer
28
How Much Buffer for HolesDo We Need?, cont

• Trace analysis says a few hundred KB suffices
  even for a large sites access link ...
• But an adversary can maliciously create holes,
  overflowing the buffer. On overflow, we can
  either
• Stop analyzing evicted connection, allowing
  adversary to evade
• Kill unanalyzable connection, allowing adversary
  to inflict collateral damage

29
Adversary-ResistantStream Reassembly

• Trace analysis also says
• Very few connections have concurrent holes
• Can limit adversary to one hole per connection
• No hosts have concurrent connections w/ holes
• Can limit adversary to one hole per Zombie
• Consider randomized eviction
• If buffer size gtgt requirements of legit
  connections, then most evictions evict the
  attackers own holes

30
Zombie Equations

• Let
• M, P total memory (pages) available for holes
• Ml, Pl memory (pages) for legitimate holes
• e tolerable eviction rate for legit.
  connections
• r rate at which a zombie can transmit
  (bytes/sec)
• g page size (granularity) for hole buffer
• Z of zombies required to achieve eviction
  rate
• Then for attacker creating small/large holes

31
Zombie Implications

• If we only terminate connections with gt 2 packets
  buffered allow each connection 10KB of buffer
  and use 512MB DRAM
• then collateral damage rate X of legitimate
  connections terminated per second is

? By throwing memory at the problem, we can
weather a large attack
32
Summary

• The lay of the land has changed
• Ecosystem of endemic hostility
• Adversaries can exploit ambiguity and pressures
  of holding state to evade detection or inflict
  collateral damage
• Internet protocols not designed with wire
  analysis in mind
• But it is possible to design to address these
  issues if they are properly considered

33
Summary, cont

• Network analysis amidst adversaries is a new
  area
• Did not talk about application-level evasion,
  polymorphism, tunneling, compromising passive
  monitors
• In many ways, reminiscent of Internet measurement
  a decade ago
• Low-hanging fruit
• Daunting problems
• Fun!