IP Spoofing

CIS 610

Week 2: 13-JAN-2004

Definition and Background

Def’n: The forging of the IP Source Address field in an IP packet

First mentioned by Morris in 1985 in his paper A Weakness in the 4.2BSD Unix TCP/IP Software

First CERT advisory on an attack using IP Spoofing in 1995

Attacks: DoS

TCP SYN flooding: attacker spoofs the IP address of unavailable host(s) to initiate multiple connections to the victim

smurfing/fraggling: attacker spoofs IP address of victim in a ICMP (smurf) or UDP (fraggle) echo request to a broadcast address

more...

Attacks: Usurpation

Session hijacking: attacker determines TCP seq number, attacker takes over send part of one end of TCP session.

Man-in-the-middle: as above but attacker sniffs traffic & can usurp one end (send and receive) of session

Routing redirect: redirects victim from original host to attacker’s machine

Valid uses of IP Spoofing

Mobile IP NAT Encapsulation (tunneling) Unidirectional link technologies (e.g.,

satellite link)

Solutions

Two basic approaches: preventive and reactive

Reactive includes traceback (discussed later)

Preventive includes source address filtering and ingress filtering/firewalling

Discussion: which is better?

Reactive Solutions

“Practical Network Support for IP Traceback,” S. Savage et al., SIGCOMM ‘00

“Hash-Based IP Traceback,” A. Snoeren et al., SIGCOMM ‘01

Practical Network Support for IP Traceback Problem: how to determine the real

source of an IP packet Solution: allow for routers along a path

to probabilistically mark packets along the way

Practical Network Support for IP Traceback (cont) Current work on the subject includes

ingress filtering, link testing (input debugging and controlled flooding), logging and ICMP traceback

Each of these has its own benefits as well as drawbacksex: logging is accurate, but takes LOTS of storage

Practical Network Support for IP Traceback (cont) Solution is packet marking-embedding

routing information in an unused field in the IP header with some probability

When victim receives enough packets, the probability that it can recreate the attack path is very high

Practical Network Support for IP Traceback (cont) Assumptions:

- an attacker may generate any packet

- multiple attackers may conspire

- attackers may be aware they are being traced

- packets may be lost or reordered

- the route between attacker and victim is fairly stable

- routers are both CPU and memory limited

- routers are not widely compromised

Practical Network Support for IP Traceback (cont) Marking algorithm used is edge

sampling; edge’s start,end addresses and distance from victim are conveyed

Without encoding, size of mark is 72 bits; where to put it?

Practical Network Support for IP Traceback (cont) Mark is compressed using 3 techniques:

– XOR IP addresses that comprise the edge– Sub-divide the above into k non-overlapping

fragments, and send randomly-selected fragment and offset

– Bit-interleave IP addresses (used above) with random hashes of themselves to enforce uniqueness of fragments

Practical Network Support for IP Traceback (cont) Encoded mark, 16 bits, put into the IP

Identification field Problems when packet is fragmented (ID field

identifies fragments); studies show <.25% of packets are fragmented

Set don’t fragment flag on marked packets, and prepend ICMP “echo reply” header to mark already-fragmented packets

Practical Network Support for IP Traceback (cont) Authors simulated marking; graph mean,

median and 95th percentile for number of packets required to reconstruct paths of varying lengths over 1000 runs

Most paths can be resolved with between 1K and 2K packets, max ~4K. By comparison, DoS attacks frequently send hundreds or thousands of packets per second

Practical Network Support for IP Traceback (cont) Limitations/Future work:

– Backwards compatibility: incompatible with IPSec, negatively impacts users who require IP fragmentation, and IPv6 does not have an ID field

– Distributed attacks: the greater the number of attack paths, the greater the probability of misattributing an edge

– Path validation: Attacker can insert false edges into previously unmarked packet

– Attack origin detection: Traceback IDs the most immediate router, not host, from which attack was launched

Practical Network Support for IP Traceback (cont) Conclusions/contributions:

– Explore traceback algorithms based on packet marking

– Edge sampling enables traceback and can be incrementally deployed, efficiently implemented

– Encoding edges and overloading packet’s ID field provides tracing information while not forcing modifications to existing infrastructure

Hash-based IP Traceback

Problem: current IP traceback methods rely on large streams of packets, cannot track individual packets

Solution: hash-based technique for IP traceback that can track even a single IP packet

Hash-based IP Traceback (cont)

Challenges: which packets to trace, privacy, minimizing cost (storage space as well as CPU cycles)

Paper presents SPIE (Source Path Isolation Engine), enables IP traceback

Bloom filters (discussed later) reduce memory requirements associated with packet storage; packet digests, not packets, stored

Hash-based IP Traceback (cont)

Assumptions:– Packets may be addressed to more than one physical host– Duplicate packets may exist in the network– Routers may be subverted, but not often– Attackers are aware that they are being traced– The routing behavior of the network may be unstable– The packet size should not grow as a result of tracing– End Hosts may be resource constrained– Traceback is an infrequent operation

Hash-based IP Traceback (cont)

Goal: should be able to identify source of any piece of data

Source defined as one of: ingress point to traceback-enabled network; actual host or network of origin; or one or more compromised routers within the enabled network

Want to build an attack graph built of >= 1 attack paths along which attack packets are sent

Hash-based IP Traceback (cont)

Hashes must be resilient to normal network transformations (i.e., decrement of TTL) as well as packet modification

>3% (not including NAT) of IP traffic undergoes common transformation

Hash-based IP Traceback (cont)

Packet Digesting:– 32-bit packet digests stored, not packets;

protects confidentiality– Hash input includes (relatively) nonvolatile

fields of IP Header (20 bytes) and first 8 bytes of payload

– Results in a very low collision domain, that gets worse as traffic tends towards homogeneity, as on LANs.

Hash-based IP Traceback (cont)

Bloom filters– Compute k distinct packet digests for each packet,

use n-bit results to index into a 2n –sized bit array– Bit array initialized to all zeros, bits set to 1 when

packet digest indexing them received– To check if packet has traversed the router, look at

Bloom filter and elements at each of the k indexes for that packet. If any of them are 0, then packet has not traversed the router

Hash-based IP Traceback (cont)

Hash Functions– 3 restrictions:

• Each function must distribute highly correlated set of input values uniformly

• Hash function collisions independent of one another

• Functions must be straightforward to compute

Hash-based IP Traceback (cont)

Architecture:– Data Generation Agent (DGA) produces digests

and digest tables, page them out– SPIE Collection and Reduction (SCAR) agent,

upon receiving traceback request, pulls digest tables from DGA and builds attack graphs

– SPIE Traceback Manager (STM) interfaces with IDS, sends requests to SCARs and aggregate SCARs’ attack graphs for reporting to IDS

Hash-based IP Traceback (cont)

Transformations:– SPIE maintains Transformation Lookup Table

(TLT) which stores digest of transformed packet (29 bits), type of transformation (3 bits), and packet data (32 bits)

– If >32 bits, can use first bit of transformation as indirect flag, indicates that packet data is a pointer to data

– Some transformations not recoverable (I.e., NAT); these will be looked at as special-purpose gateways, out of scope of the paper

Hash-based IP Traceback (cont)

Graph construction done by recursively checking along reverse path for routers with packet digests corresponding to attack packet

Resource requirements expressed in terms of k and the amount of memory used to store packet digests.

Performance characterized by length of time for which packet digests are kept and the accuracy of candidate attack graphs

Hash-based IP Traceback (cont)

Timing– Note that the window of time in which one

must detect an attack shrinks with the increase of the number of packets processed; fast links suggest smaller windows

– The above can be tempered by allotting more fast storage to maintenance of SPIE-related information

Summary

Traceback methods– Reactive; don’t prevent, for instance DoS

attacks– End-user-triggered; performed upon the

request of a victim—victim must know he/she’s being attacked

– Network-maintained

Hash-based IP Traceback (cont)

Discussion– Tracebacks will often be requested when network

is having problems; may influence the accuracy of said traceback unless requested out-of-band

– Incremental deployment can severely limit the scope of the attack graph

– Occasionally, the victim may not want to send the attack packet needed by SPIE to traceback

– Transformations can be costly to invert and/or recover from