CSE 524: Lecture 17

1
CSE 524 Lecture 17

• Network security issues

2
Administrative

• Programming assignment due Monday 12/1
• Arrange with TA
• Final project due 12/10

3
Optional material

• Hacking the stack Network protocol attacks
• Hacking TCP
• Hacking routing
• Hacking ICMP
• Hacking DNS
• Reflector attacks
• Analyzing attacks
• Estimating DoS activity
• Tracing the source of attacks
• Traceback via traffic injection
• Traceback via packet marking
• Traceback via logging
• Intrusion detection and response
• Network IDS
• Attacking the detectors

4
Hacking the stack Network protocol attacks

• C. Schuba, I. Krsul, M. Kuhn, E. Spafford, A.
  Sundaram, D. Zamboni, "Analysis of a Denial of
  Service Attack on TCP"
• S. Bellovin, "Security Problems in the TCP/IP
  Protocol Suite"
• S. Bellovin, "Defending against sequence number
  attacks"
• S. Bellovin, "Packets Found on an Internet"
• R. Morris, "A Weakness in the 4.2BSD Unix TCP/IP
  Software
• B. Cheswick, S. Bellovin, A DNS Filter and
  Switch for Packet-filtering Gateways.
• S. Savage, N. Cardwell, D. Wetherall, T.
  Anderson, TCP Congestion Control with a
  Misbehaving Receiver.

5
Hacking TCP SYN Flooding

• Attacker sends many connection requests w/
  spoofed source addresses to victim
• Victim allocates resources for each request
• Finite half-open connection requests supported
• Connection requests exist for TIMEOUT period
• Once resources exhausted, all other requests
  rejected

Normal connection est.
Syn Flooding attack
6
Hacking TCP SYN Flooding Defenses

• System Configuration Improvements
• Reduce timeout period
• Increase length of backlog queue to support more
  connections
• Disable non-essential services to make a smaller
  target
• Router Configuration Improvements
• Configure router external interfaces to block
  packets with source addresses from internal
  network
• Configure router internal interfaces to block
  packets to outside that have source addresses
  from outside the internal network
• TCP SYN cookies
• Make handshake stateless on server end
• Server makes ISN a function of a secret nonce it
  keeps and pieces of the SYN connection ID
• Only create TCB and establish connection upon
  verifying clients ACK

7
Hacking TCP SYN Flooding Defenses

• Firewall as a Relay
• Firewall answers on behalf of Destination
• Once connection established, firewall predicts
  seq and establishes 2nd connection to
  Destination
• Disadvantage Adds delay for every packet

8
Hacking TCP SYN Flooding Defenses

• Firewall as a Semi-transparent Gateway
• Forges the 3rd handshake (ack) from the client to
  the destination
• This moves connection out of backlog queue,
  freeing resources
• If this is attack, no real ack will happen
• Destination will send RST packet terminating
  connection
• If this is actual connection request the eventual
  ack will be ignored as a duplicate
• Disadvantages
• Large illegitimate open connections if system
  under attack
• Must very carefully choose timeout periods

9
Hacking TCP SYN Flooding Defenses
Attack w/ semi-transparent gateway
Legit connection w/ semi-transparent gateway
10
Hacking TCP SYN Flooding Defenses

• Active Monitor
• Program that promiscuously monitors and injects
  network traffic to/from machines it is protecting
• Monitors net for SYN packets not acknowledged
  after a certain period of time
• If it detects problems with a half-open
  connection it can
• Send RST packets to the sender to release
  destination resources
• Complete the TCP connections by sending the ACK
  message
• Similar to Semi-Transparent gateways

11
Hacking TCP Congestion control tricks

• ACK Division
• Receiver can acknowledge segments multiple times
  (up to bytes acks)
• Leads Sender to grow cwnd faster than normal.
• Solution to ACK Division
• Modify congestion control to guarantee
  segment-level granularity
• Only increment MSS when a valid ACK arrives for
  the entire segment.

Bunch of acks
Burst 1 RTT later
12
Hacking TCP Congestion control tricks

• Duplicate Ack Spoofing
• Receiver sends multiple acks/sequence
• no way to tell what segment is being acked
• Causes sender to enter fast-recovery mode and
  inflate cwnd
• Solution to Duplicate Ack Spoofing
• Add new fields to TCP headers.
• nonce nonce-reply random values sent with
  segments and replies
• Only increment cwnd for ACKs with previously
  unseen nonces

Burst of dup acks
Sender enters Fast Recovery and bursts 1 RTT later
13
Hacking TCP Congestion control tricks

• Optimistic ACKing
• Send acks for segments not yet received
• Decrease perceived RTT, affecting CW growth.

Segment acks
Segs arrive
14
Hacking TCP Congestion control tricks

• Solution to optimistic acking Cumulative Nonce
• Sender sends random number (nonce) with each
  packet
• Segment size slightly randomized
• Receiver sends cumulative sum of nonces
• if receiver detects loss, it sends back the last
  nonce it received
• Why cumulative?
• Requires modifications to stack

15
Hacking routing RIP attacks

• Attack
• Intruder sends bogus routing information to a
  target and each of the gateways along the route
• Impersonates an unused host
• Diverts traffic for that host to the intruders
  machine
• Impersonates a used host
• All traffic to that host routed to the intruders
  machine
• Intruder inspects packets resends to host w/
  source routing
• Allows capturing of unencrypted passwords, data,
  etc

16
Hacking routing RIP attacks

• Defenses
• Paranoid gateway
• Filters packets based on source and/or
  destination addresses
• Dont accept new routes to local networks
• Messes with fault-tolerance but detects intrusion
  attempts
• Authenticate RIP packets
• Difficult in a broadcast protocol
• Only allows for authentication of prior sender
  and doesnt address information from a deceived
  gateway upstream

17
Hacking ICMP

• Attack
• Targeted Denial of Service (DoS)
• Attacker sends ICMP Redirect message to give a
  bogus route
• Attacker sends Destination Unreachable or TTL
  exceeded messages to reset existing connections
• Attacker sends fraudulent Subnet Mask Reply
  messages
• Blocks communication with target
• Defenses
• Verify ICMP packet contains a plausible sequence
  
• Dont modify Global Route Table due to ICMP
  Redirect messages
• Disallow ICMP Redirects?
• Check to see if multiple ICMPs from a host agree

18
Hacking DNS

• DNS Domain Name System
• BSD r
• rlogin, rcp, rsh use address based authentication
  (reverse lookup)
• The problem
• No authentication
• Responses can contain entries that should not be
  trusted but are
• Responses are cached
• Attacks
• Inject bogus DNS responses
• Attach additional bogus entries in valid DNS
  responses (especially for internal names)

Firewall

Application
Remote Name Server (?)
Local Name Server (Trusted)
Resolver
19
Hacking DNS

• Solution DNS Proxy
• Filter
• Drop malformed packets
• Verify
• Does the answer, really answer the query made?
• Was the answer received from the appropriate
  server?
• Proxy performs checks on the answers from outside
  DNS servers
• Located within the firewall on a trusted host
• Intercepts DNS queries, filters, modifies and
  forwards in appropriate direction

20
Hacking the stack Reflector attacks

• A reflector is any IP host that will return a
  packet or more if sent a packet.
• Reflector cannot easily locate the slave because
  of IP spoofing.
• Examples
• Web servers return SYN ACKS or RSTs in response
  to SYN or other TCP packets.
• DNS servers return query replies in response to
  query requests.
• Routers return ICMP Time Exceeded or Host
  Unreachable messages in response to particular
  IP packets.

21
(No Transcript)
22
Hacking the stack ICMP reflectors

• ICMP echo, timestamp, address mask, router
  solicitation, information request/reply.
• ICMP echo is widely used.
• Smurf attacks
• ICMP source quench, unreachable, time exceeded,
  parameter problem, and redirect.
• Important ICMP messages
• Host unreachable.
• Time exceeded.
• Need fragmentation.

23
Hacking the stack TCP reflectors

• TCP stack can be made to reflect via
• SYN ACK by sending an initial SYN.
• Filtering leads to no-remote access.
• RST by sending a FIN.
• Filtering RST results in clogging of stale
  connections state

24
Hacking the stack TCP reflectors

• Predictable TCP sequence numbers
• If reflector stack has guessable TCP sequence
  numbers, its a DISASTER for the victim.
• Attacker can drive the Reflector TCP state
  machine, making it send ACKs, data segments.
• Attack can be amplified by transmitting large
  items and exploiting ACK splitting techniques.

25
Hacking the stack TCP for Transactions (T/TCP)
reflectors

• Spoof initial SYN packet with acceptable seq. no.
• Make an expensive request.
• Factors that limit the T/TCP attack
• T/TCP server will begin in slow start.
• Unless the servers stack has predictable seq.
  no.
• Amenable to stateless packet filtering.
• T/TCP is not widely deployed.

26
Hacking the stack UDP reflectors

• UDP
• Application-specific
• Quake Qstat
• Counter-strike clients
• DNS

27
Hacking the stack DNS reflectors

• DNS
• Reflector sending DNS reply in response to a
  spoofed DNS request.
• Victim can configure its local DNS servers so as
  to filter out unknown DNS server responses.
• If the victim is a name server
• Attacker can query a large number of DNS servers
  which in turn recursively query the Victim.
• Victim server gets bombarded due to multiple
  queries.
• DNS queries neednt even be spoofed.
• Send valid queries to a large set of known DNS
  servers
• Arbitrary names not just the ones responsible for
• Caching at the reflector server doesnt help.
• Solution Provide filtering in name servers so as
  to serve recursive queries from local addresses,
  coupled with ingress filtering.

28
Hacking the stack SNMP reflectors

• SNMP (UDP-based request/reply)
• Sites that fail to block off-site access to SNMP
  provide a large number of reflectors.
• SNMP attack is sourced at port 161.
• Filtering out the external SNMP messages leads to
  major problem for service providers.
• Configure the filter to receive SNMP messages
  from interested hosts.

29
Hacking the stack HTTP reflectors

• HTTP proxies
• HTTP proxy caches provide a way that an HTTP
  client can manipulate a proxy server into
  initiating a connection to a victim web server.
• HTTP proxy servers act as reflectors for the DDOS
  attacks.
• HTTP - Limitations
• Proxies can be configured to serve a restricted
  set of clients.
• There are not enough proxy caches to constitute a
  large pool of possible reflectors.
• Connection between slave and the reflector cannot
  be spoofed unless the reflecting proxy has
  predictable sequence numbers. Logging helps in
  identifying the slaves location.
• Definitely a major threat if servers running on
  stacks with predictable sequence numbers are
  widely deployed.

30
Hacking the stack FTP reflectors

• See previous lecture on server-to-server transfers

31
Hacking the stack Gnutella

• Gnutella attack
• Provides a push facility that instructs the
  server to connect to a given IP address and port
  in order to deliver the Gnutella item.
• Gnutella connection to the IP host is separated
  from the initial client making it impossible to
  trace back to the slave.
• Fix
• Modify the protocol to include path information
  with push directives
• Gnutella could be a major problem for DDOS
  reflector attacks.

32
(No Transcript)
33
Analyzing attacks

• D. Moore, G. Voelker, S. Savage Inferring
  Internet Denial-of-Service Activity

34
Analyzing attacks Backscatter

• Attackers spoof source address randomly
• Small frequent packets. (packet/sec bottleneck)
• e.g. TCP SYN -gt victim allocate data structure
  for arriving packets (for unmatched to existing
  connections)
• Victims, in turn, respond to attack packets
• Remotely controlled Zombies for DDoS
• Unsolicited responses (backscatter) equally
  distributed across IP space
• Received backscatter is evidence of an attacker
  elsewhere

35
From caida page
36
From caida page
37
Analyzing attacks Backscatter

• Backscatter analysis provides quantitative data
  for a global view on DoS activity using local
  monitoring
• Videos
• Traffic Characterisation (How Data Gathered)
• http//www.caida.org/outreach/resources/animations
  /passive_monitoring/traffic_char.mpg (1min12s)
• TCP Port Analysis
• http//www.caida.org/outreach/resources/animations
  /passive_monitoring/tcp_port_analysis.mpg
  (2min15s)
• Backscatter
• http//www.caida.org/outreach/resources/animations
  /passive_monitoring/backscatter.mpg (1min26)

38
Analyzing attacks Assumptions

• Address Uniformity
• Reliable delivery
• Backscatter not lost
• Backscatter hypothesis
• Unsolicited packets represent backscatter
• In fact any server can send
• Reflector attack may not be detected
• Not random IP-forgery
• Some attacks (e.g. TCP-RST) doesnt produce
  backscatter.

39
(No Transcript)
40
Analyzing attacks Backscatter platform
41
Analyzing attacks Results

• 13000 attacks in 3 weeks
• 5000 victim IP addresses on 2000 domains
• 200 million backscatter packets
• 256 lt Real attack packets
• Most attacks short, some longer persistent ones
• Mostly TCP (90-94)
• Some large ICMP storms (43 of all packets)
• Attacks cover most ports, but HTTP and IRC
  singled out
• How serious is this?
• 500 packets enough to overwhelm server
• 38-46 of attacks (unif.-all)
• 14000 packets enough to overwhelm firewall
• 0.3-2.4 of attacks (unif.-all)

42
Analyzing attacks Victim characterization

• Entire spectrum of sites and businesses
• Yahoo!, Amazon, CNN, etc.
• Small attacks from personal vendettas
• 10-20 targeted towards home machines
• Attacks on infrastructure
• 5 directed towards routers and root DNS servers

43
Traceback

• H. Burch, B. Cheswick, "Tracing Anonymous Packets
  to Their Approximate Source
• S. Bellovin, M. Leech, T. Taylor, "ICMP Traceback
  Messages"
• A. Mankin, D. Massey, C. Wu, S. Wu, L. Zhang, "On
  Design and Evaluation of "Intention-Driven" ICMP
  Traceback
• A. Snoeren, C. Partridge, L. Sanchez, C. Jones,
  F. Tchakountio, S. Kent and W. Strayer,
  Hash-Based IP Traceback

44
Traceback Motivation

• DoS attacks
• IP spoofing
• No one checks source IP address to drop spoofed
  packets
• TCP SYN floods, Smurf (ICMP echo to broadcast
  addresses)
• Difficult to get the help of upstream ISP
• Lack skill
• Lack resources (might be 6pm on Friday)
• In a different country (speak different language,
  etc)
• Require automatic way of identifying where the
  traffic is coming from without human intervention

45
Traceback Problem

• Goal
• Given set of packets
• Determine path
• Assumptions
• Most routers remain uncompromised
• Attacker sends many packets
• Route from attacker to victim remains relatively
  stable

A4
A5
A1
A2
A3
R6
R7
R8
R9
R10
R12
V
46
Traceback schemes

• Record Route
• Traffic injection
• ICMP Trace (ITRACE)
• Probabilistic packet marking
• Logging and query
• Source Path Isolation Engine (SPIE)
• Reverse ITRACE
• Subverting Traceback schemes

47
Traceback Record Route

• Record path
• Each router adds IP address to packet
• Victim reads path from packet

• Problem
• Requires space in packet
• Path can be long
• No extra fields in current IP format
• Changes to packet format are not practical

48
Traceback Traffic injection

• Create a map of routes from victim to every
  network
• Burst TCP/UDP packets to each and see if you are
  affected
• TCP/UDP chargen service
• Generates continuous data to anyone who connects
  to service
• If DoS stream perturbed, you have a candidate
• Problems
• Finding open chargen service
• Asymmetric routing
• Must generate sufficient load to perturb stream
  especially when there are multiple attacking
  hosts
• Easy to thwart
• Vary source of attack by altering frequency of
  packets
• Attack from many sources
• Still cant turn attackers offMust notify
  upstream ISP to stop

49
Traceback Leverage volume of attack (Part 1)

• Many packets
• DDoS involves many packets on same path
• Have routers periodically send message to victim
• Each router sends message to Victim for every X
  packets it forwards to victim

A4
A5
A1
A2
A3
R6
R7
R8
R9
R10
R12
V
50
Traceback ICMP trace

• ICMP traceback messages
• Routers periodically issue traceback ICMP
  messages to destination
• Send 1 message for every 20000 packets forwarded
  to destination
• 0.1 overhead
• Similar to RouteRecord, collects intermediate
  hops along the way to destination
• Over time, leaves a trail of where packets are
  being sourced from
• Problems
• Skilled attacker spoofing traceback messages to
  conceal the real source of attack
• Requires some signature and trust management
• Skilled attacker uses zombies to flood each other
  along with victim to reduce the amount of
  traceback messages sent
• Background noise
• Only want traceback messages from far away

51
Traceback Leverage volume of attack (Part 2)

• Many packets
• DDoS involves many packets on same path
• Store one link in each packet
• Probabilistically store your own address or edge
  in packet using unused IP header fields (IP
  identifier)
• lt 0.25 of traffic fragmented
• Fixed space regardless of path length

A4
A5
A1
A2
A3
R6
R7
R8
R9
R10
R12
V
52
Traceback IP traceback w/ edge sampling

• Data fields
• Edge start and end IP addresses
• Distance number of hops since edge stored
• Marking procedure for router R
• with probability p
• write R into start address
• write 0 into distance field
• else
• if distance 0 write R into end field
• increment distance field

53
Traceback IP traceback w/ edge sampling

• Packet received
• R1 receives packet from source or another router
• Packet contains space for start, end, distance

R1
R2
R3
54
Traceback IP traceback w/ edge sampling

• Begin writing edge
• R1 chooses to write start of edge
• Sets distance to 0

R1
R2
R3
55
Traceback IP traceback w/ edge sampling

• Finish writing edge
• R2 chooses not to overwrite edge
• Distance is 0
• Write end of edge, increment distance to 1

R1
R2
R3
56
Traceback IP traceback w/ edge sampling

• Increment distance
• R3 chooses not to overwrite edge
• Distance gt0
• Increment distance to 2

R1
R2
R3
57
Traceback IP traceback w/ edge sampling Path
reconstruction

• Extract identifiers from attack packets
• Build graph rooted at victim
• Each (start,end,distance) tuple is an edge
• Eliminate edges with inconsistent distance
• Traverse edges from root to find attack paths
• packets needed to reconstruct path
• E(X) lt
• where p is marking probability, d is length of
  path

ln(d) p(1-p)d-1
Optimal p is 1/d can vary probability by
distance
58
Traceback IP traceback w/ node sampling

• Less data than edge sampling
• Each router writes own address with probability p
• Infer order by number of packets
• Router at distance d has probability p(1-p)d of
  showing up in marked packet

p
1-p
1-p
1-p
R
V
d

• Problems
• Need many packets to infer path order
• Does not work well if many paths

59
Traceback Reduce Space Requirement

• IP identifier is 16 bits
• Distance, node addresses, larger
• Solution
• Break into chunks
• XOR edge IP addresses
• Store edge as start end
• Work backwards to get path
• (start end) end start
• Sample attack path

b c
c d
d
a b
a
b
c
d
V
60
Traceback Where to store the info?

• Identification field
• Used for fragmentation
• Fragmentation is rare
• 16 bits
• Store edge in 16 bits?
• Break into chunks
• Store start end

Identification
offset
distance
edge chunk
0 2 3 7 8 15
61
Traceback IP traceback convergence time
62
Traceback IP traceback w/ edge sampling

• Benefits
• Practical algorithm for tracing anonymous attacks
• Can reduce per-packet space overhead (at a cost)
• Potential encoding into current IP packet header
• Weaknesses
• Path validation/authentication
• Robustness in highly distributed attacks
• Both addressed nicely in SongPerrig00
• Compatibility issues (IPsec AH, IPv6)
• Origin laundering (reflectors, tunnels, etc)

63
Traceback Hash-based logging
R
R
A
R
R
R
R
R7
R4
R6
R5
R
R3
R1
R2
V
64
Traceback Logging

• Each forwarding decision is recorded
• Traceback request queries upstream routers to ask
  if the router forwarded a particular packet
• Difficulties
• Attack path reconstruction is difficult
• Packet may be transformed as it moves through the
  network
• Full packet storage is problematic
• Memory requirements are prohibitive at high line
  speeds (OC-192 is 10Mpkt/sec)
• Extensive packet logs are a privacy risk
• Traffic repositories may aid eavesdroppers

65
Traceback Logging

• Compute packet digest
• Compute hash(p)
• Invariant fields of p only
• 28 bytes hash input, 0.00092 WAN collision rate
• Fixed sized hash output, n-bits
• Store in Bloom filter (more later)
• Compute k independent digests
• Increased robustness
• Reduced collisions, reduced false positive rate
• Flush filter every time interval, t

66
Traceback Hash-based loggingHash-input
(Invariant Content)
Total Length
Ver
TOS
HLen
Identification
Fragment Offset
M F
D F
Checksum
TTL
Protocol
28 bytes
Source Address
Destination Address
Options
First 8 bytes of Payload
Remainder of Payload
67
Traceback Bloom filter
NL virtual bins out of LN actual bins
68
Traceback Reverse ITRACE

• R-ITRACE routers send ICMP messages to the source
  of the just-processed packet rather than its
  destination (unlike ITRACE).
• Routers on the path between slave and the
  reflector will send ICMP messages to Victim to
  enable trace back to the slaves.
• Efficacy does not depend on Nr but only on Ns.

69
Traceback Subversion via reflectors

• Major advantage to attackers
• Protection from trace back mechanisms.
• Traceback mechanisms fail since they cannot trace
  back directly to slave
• Reflector operator must be involved
• Administratively cumbersome.
• Source Path Isolation Engine (SPIE) helps.
• Note reflectors need not serve as amplifiers.
• Non-spoofed reflector attacks will expose the
  slave to quick traceback.

70
Traceback Defense against Reflectors

• Prevent spoofing source address by ubiquitous
  deployment of ingress filtering.
• Application level reflectors such as recursive
  DNS queries or HTTP proxy requests can still be
  used.
• Disadvantage Not feasible.
• Heavy-duty filtering at victim or at reflector
• Disadvantage Requires widespread deployment of
  filtering.

71
Traceback Defense against Reflectors

• Deploy traceback mechanisms that incorporate the
  reflector end-host software itself in the scheme,
  allowing traceback through the reflector back to
  the slave.
• Disadvantage Enormous deployment difficulties.
• Intrusion Detection Systems (IDS) monitor a
  sites network for active slaves.
• Disadvantage Requires widespread deployment of
  security technology.

72
Traceback Other solutions

• Ingress filtering
• Block outgoing packets without appropriate source
  address
• Backbone filtering
• Use knowledge of BGP to guess if packets source
  address could have possibly originated from a
  particular direction
• Routing instability makes this hard
• Lack of resources at routers makes this hard

73
Intrusion Detection Systems

• T. Ptacek, T. Newsham, Insertion, Evasion and
  Denial of Service Eluding Network Intrusion
  Detection (Jan 98)
• B. Sanford, IP Fragmentation and fragrouter
  (Dec 00)
• S. Patton, W. Yurcik, D. Doss, An Achilles Heel
  in Signature-based IDS Squealing False Positives
  in SNORT (01)
• G. Malan, D. Watson, F. Jahanian, P. Howell,
  "Transport and Application Protocol Scrubbing"
• M. Handley, V. Paxson, C. Kreibich, Network
  Intrusion Detection Evasion, Traffic
  Normalization and End - End semantics (01)

74
IDS

• Introduction to IDS
• Some popular IDSs
• Problems with IDSs
• Insertion, evasion, denial-of-service
• IP Fragmentation fragrouter
• Squealing in SNORT
• Counter-measures
• Protocol scrubbing
• Traffic normalization

75
IDS What do they do?

• Detect intrusion attempt or a threat potential
  possibility of a deliberate unauthorized attempt
  to access/manipulate information, or render a
  system unreliable or unusable.
• Types of IDS
• Host-based
• Network IDS
• Example IDSs
• ISS RealSecure, WheelGroup NetRanger, Network
  Flight Recorder, Snort

76
IDS Principles

• Passive monitoring
• Signature Analysis
• Need for reliable ID
• accuracy false positives and false negatives
• fail-open if an attacker disables the IDS,
  entire network is still accessible
• forensic value of information

77
IDS Fundamental problems

• Deployed on a different box and/or different
  network
• Protocol implementation ambiguities
• Different protocol stacks have different behavior
• NIDS could see a different stream of packets than
  host
• Inaccuracies
• False positives
• incorrectly identify an intrusion when none has
  occurred
• False negatives
• incorrectly fail to identify an intrusion that
  has actually occurred

78
IDS Attacks

• Insertion
• IDS thinks packets are valid end system rejects
  these
• Evasion
• end system accepts packets that IDS rejects
• Denial of Service
• resource exhaustion
• Examples

79
IDS Popular problems/attacks

• TCP/IP Options fields
• TCB Creation/Teardown
• TCP Stream Reassembly
• IP Fragmentation
• overlapping fragments

80
IDS IP Fragmentation

• Allows IP traffic over different network media
  with different max packet sizes
• IP stacks do not handle reassembly well
• can lead to DOS (teardrop, jolt2)
• Fragrouter
• NIDS testing tool
• accepts IP packets routed from another system
• fragments these packets according to various
  schemes

81
IDS Popular problems/attacks

• Resource Exhaustion
• CPU, Memory, Network Bandwidth
• Abusing reactive IDS
• attack to generate false positives
• IDS shuts down valid connections, blocks valid
  traffic etc.
• Results in IDS triggering a DOS

82
IDS False positives

• Abuse by generating loads of false positives
• Squealing Noise made by pigs during periods of
  distemperment
• Boy cried wolf too many times
• additionally, boy may not recognize the wolf when
  it actually appears!
• Example using Snort
• open-source, free, lightweight NIDS

83
IDS Attacking Snort

• Limitation is not in correctly identifying
  attacks, but in the ability to suppress false
  positives
• PCP
• Tool for generating false positives
• packet writing and argument parsing

84
IDS Squeal attack types

• Noise-masked attacks
• diverts attention from a covert attack
• Attack misdirection
• source of attack is spoofed
• Evidence Reputability
• Target Conditioning
• Statistical Poisoning
• when training an IDS

85
IDS Counter-measures

• Adaption
• changing the signature-matching algorithms
  rapidly
• State awareness
• make IDS have a context which checking packets

86
IDS Counter-measures

• Problem
• IDSs are vulnerable to attacks
• fundamental problems
• IDS sees different streams than target host
• protocol implementation ambiguities
• Solutions
• Transport and application layer protocol
  scrubbing
• Generalized traffic normalizer
• Modify packets to erase ambiguity

87
IDS Normalizer
88
IDS Normalizer

• Sits directly in path of traffic into a site
• Patch up or normalize the packet stream
• Result same traffic and unambiguous behavior for
  NIDS and host
• Differs from a firewall
• Other approaches
• host-based IDS, details of intranet, bifurcating
  analysis

89
IDS Normalization Tradeoffs

• Protection
• not meant to but can act as a firewall
• Need to preserve End-End Semantics
• Impacts end-end performance
• Stateholding attack
• create excess state than Normalizer can handle
• Inbound vs Outbound traffic

90
IDS Other Considerations with Normalizer

• Cold Start
• is a real world requirement
• what happens to existing connections?
• Initiate state for connections from trusted
  network
• Attacking the normalizer itself