Transcript ppt - The Fengs

CSE 524: Lecture 17
Network security issues
1
Administrative
• Programming assignment due Monday 12/1
– Arrange with TA
• Final project due 12/10
2
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
3
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”.
4
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
5
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 client’s ACK
6
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
7
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
8
Hacking TCP: SYN Flooding Defenses
Attack w/ semitransparent gateway
Legit connection w/ semitransparent gateway 9
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
10
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
11
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
12
Hacking TCP: Congestion control tricks
• Optimistic ACKing
– Send acks for segments not yet received
– Decrease perceived RTT, affecting CW growth.
Segment acks
Segs arrive
13
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
14
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 intruder’s machine
• Impersonates a used host
– All traffic to that host routed to the intruder’s machine
– Intruder inspects packets & resends to host w/ source routing
– Allows capturing of unencrypted passwords, data, etc
15
Hacking routing: RIP attacks
• Defenses
– Paranoid gateway
• Filters packets based on source and/or destination addresses
– Don’t 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 doesn’t address
information from a deceived gateway upstream
16
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 #
– Don’t modify Global Route Table due to ICMP Redirect
messages
– Disallow ICMP Redirects?
– Check to see if multiple ICMPs from a host agree
17
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
Resolver
Local Name Server
(Trusted)
Remote Name Server
(?)
18
*
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
19
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.
20
21
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.
22
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
23
Hacking the stack: TCP reflectors
• Predictable TCP sequence numbers
– If reflector stack has guessable TCP sequence numbers, it’s 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.
24
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 server’s stack has predictable seq. no.
– Amenable to stateless packet filtering.
– T/TCP is not widely deployed.
25
Hacking the stack: UDP reflectors
• UDP
– Application-specific
• Quake Qstat
• Counter-strike clients
• DNS
26
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 needn’t 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 doesn’t help.
• Solution: Provide filtering in name servers so as to serve recursive queries
from local addresses, coupled with ingress filtering.
27
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.
28
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 slave’s location.
• Definitely a major threat if servers running on stacks with
predictable sequence numbers are widely deployed.
29
Hacking the stack: FTP reflectors
• See previous lecture on server-to-server transfers
30
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.
31
32
Analyzing attacks
• D. Moore, G. Voelker, S. Savage “Inferring Internet
Denial-of-Service Activity”
33
Analyzing attacks: Backscatter
• Attackers spoof source address randomly
– Small frequent packets. (packet/sec bottleneck)
– e.g. TCP SYN -> 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
34
35
From caida page
36
From caida page
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_monitorin
g/traffic_char.mpg (1min12s)
• TCP Port Analysis
– http://www.caida.org/outreach/resources/animations/passive_monitorin
g/tcp_port_analysis.mpg (2min15s)
• Backscatter
– http://www.caida.org/outreach/resources/animations/passive_monitorin
g/backscatter.mpg (1min26)
37
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) doesn’t produce backscatter.
38
39
Analyzing attacks: Backscatter platform
40
Analyzing attacks: Results
• 13000 attacks in 3 weeks
• 5000 victim IP addresses on 2000 domains
• 200 million backscatter packets
– *256 < 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)
41
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
42
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”
43
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
44
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
A1
A2
R6
A3
R7
A4
A5
R8
R9
R10
R12
V
45
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
46
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
47
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 can’t turn attacker’s off…Must notify upstream ISP to stop
48
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
A1
A2
R6
A3
R7
A4
A5
R8
R9
R10
R12
V
49
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
50
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)
• < 0.25% of traffic fragmented
– Fixed space regardless of
path length
A1
A2
R6
A3
R7
A4
A5
R8
R9
R10
R12
V
51
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
52
Traceback: IP traceback w/ edge sampling
• Packet received
– R1 receives packet from source or another router
– Packet contains space for start, end, distance
packet
R1
s
e d
R2
R3
53
Traceback: IP traceback w/ edge sampling
• Begin writing edge
– R1 chooses to write start of edge
– Sets distance to 0
packet
R1
R1
0
R2
R3
54
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
packet
R1
R1 R2 1
R2
R3
55
Traceback: IP traceback w/ edge sampling
• Increment distance
– R3 chooses not to overwrite edge
– Distance >0
• Increment distance to 2
packet
R1
R2
R1 R2 2
R3
56
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
ln(d)
p(1-p)d-1
where p is marking probability, d is length of path
E(X) <
Optimal p is 1/d … can vary probability by distance
57
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
R
• Problems
1-p
1-p
1-p
V
d
– Need many packets to infer path order
– Does not work well if many paths
58
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
a+b
a
b
c+d
c
d
d
V
59
Traceback: Where to store the info?
• Identification field
Version
– Used for fragmentation
– Fragmentation is rare
– 16 bits
• Store edge in 16 bits?
Flags
– Break into chunks
– Store start + end
offset distance
0
23
Fragment Offset
Time to Live
Protocol
Header Checksum
edge chunk
78
Header Length
Type of Service
Total Length
Identification
Identification
15
Source Address of Originating Host
Destination Address of Target Host
Options
Padding
IP Data
60
Traceback: IP traceback convergence time
61
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 [Song&Perrig00]
– Compatibility issues (IPsec AH, IPv6)
– Origin laundering (reflectors, tunnels, etc)
62
Traceback: Hash-based logging
R
R
R
A
R
R
R7
R4
R5
R
R
R6
R3
R1
R2
V
63
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
64
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
65
Traceback: Hash-based logging
Hash-input (Invariant Content)
Ver
HLen
TOS
Total Length
D M
F F
Identification
TTL
28
bytes
Protocol
Fragment Offset
Checksum
Source Address
Destination Address
Options
First 8 bytes of Payload
Remainder of Payload
66
Traceback: Bloom filter
h0
hL-1
1
0
Flow insertion
h1
1
2
1
Check entry
0
0
1
N-1
NL
virtual bins out of L*N actual bins
67
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.
68
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.
69
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.
70
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 site’s network for
active slaves.
– Disadvantage: Requires widespread deployment of security technology.
71
Traceback: Other solutions
• Ingress filtering
– Block outgoing packets without appropriate source address
• Backbone filtering
– Use knowledge of BGP to guess if packet’s source address
could have possibly originated from a particular direction
• Routing instability makes this hard
• Lack of resources at routers makes this hard
72
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 Signaturebased 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)
73
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
74
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
75
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
76
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
77
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
78
IDS: Popular problems/attacks
•
•
•
•
TCP/IP Options fields
TCB Creation/Teardown
TCP Stream Reassembly
IP Fragmentation
– overlapping fragments
79
Specific attacks
• Invalid MAC addresses?
• Invalid headers
– Permissive in receiving, frugal in sending?
– Bad IP checksum will be dropped?
– IP options
• IP TTL ambiguity
– Packer received or not?
80
Specific attacks
• Packet size
– Packet too large for downstream link?
• Source-routed packets
– Will destination reject such packets?
• Fragment or TCP handshake time-out
– Will other parts of fragment/TCB still be at destination?
• Overlapping segments
– Rewrite old data or not?
81
Specific attacks
• Weird TCP options
– Destination might be configured to drop
• Old TCP timestamps (PAWS)
– Destination might be configured to drop
• TCP RSTs with weird sequence numbers
– Is connection reset?
• Addition of interpreted characters (“^H”)
– How does OS interpret?
82
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
83
Popular problems/attacks
• Resource Exhaustion
–
–
–
–
CPU, Memory, Network Bandwidth
CPU: Data-structure attack via fragments
Memory: Space attack via fragments
Network: Targeted DoS to disrupt TCP reassembly
• Abusing reactive IDS
– attack to generate false positives
– IDS shuts down valid connections, blocks valid traffic etc.
– Results in IDS triggering a DOS
84
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
85
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
86
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
87
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
88
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
89
IDS: Counter-measures
• Adaption
– changing the signature-matching algorithms rapidly
• State awareness
– make IDS have a “context” which checking packets
90
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
91
IDS: Normalizer
92
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
93
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
94
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
95