Purpose of the Project

In the FootFall Project we are concerned with determining the origin and route of a packet in the network. IP Traceback is the term used to trace packets through a sequence of routers. In our project, we are also concerned with tracing packets through intermediate, possibly unsuspecting hosts called “stepping stones”. Attackers use stepping stones specifically to thwart tracing by conventional IP traceback means. A picture of a network with stepping stones used to conceal the origin of an attack is shown below. In this figure, the attacker may telnet into stepping stone A. From A he may telnet into stepping stone B, and from B to C. The attack on the victim is then launched from host C. Any results produced by this attack may be propagated on the reverse path from C to B to A to the attacker's machine.

Figure 1. Example of stepping stone attacks.

The difficulty in tracing attack traffic through stepping stones is that most of the traffic characteristics are modified by the stepping stone. This includes the IP and TCP headers, the payload (if the payload is encrypted by the stepping stone), packet sizes, etc. Determining that traffic incoming to a stepping stone is correlated with traffic going out of that stepping stone is therefore a problem; without such correlation, network traceback is stymied by stepping stones.

Previous work on tracing through stepping stones has proposed a variety of techniques. Some of this work requires full access to the log files of the stepping stone. Other methods assume there is no modification of the traffic payloads by the stepping stone. Some methods are based on the particular timing characteristics of interactive applications' traffic, and only perform correlation across a single stepping stone.

In the work funded by this project, we have proposed to also use traffic timing for purposes of correlation of traffic into and out of stepping stones. The attraction of using timing is that it is not dependent on the packet payload or on the packet header (for the most part), which are easily manipulated by the attacker. While the attacker does have some ability to manipulate, or perturb , the packet timing, we also have a defense for that.

Our method is based on actively watermarking the traffic timing, for purposes of correlating traffic across stepping stones and through the network. The basic idea is simple enough: manipulate the traffic timing in such a way that it is uniquely recognizable by an analysis program. By using watermarking techniques, we create a method of traceback which is almost arbitrarily robust to attempts by the attacker to perturb traffic timing to avoid traceability.

The technique itself works as follows, illustrated in Figure 2. First, the parameters dictating the type of watermark to be use are selected, under program (automated) or analyst (manual) control. A watermark generator program then outputs the timing pattern to be embedded in the traffic. The traffic must be intercepted by a watermark embedder , whose sole purpose is to manipulate packet timing in the way specified by the watermark generator. This traffic is then propagated through the network, crossing any number of routers and/or stepping stones, until it arrives at the victim (i.e., traceback in the forward direction), or at the attacker (traceback in the reverse direction). At any point in the network, one or more watermark detectors monitor traffic, looking for the watermark that has been embedded in the timing. When traffic with the specific watermark characteristics has been recognized, a message can be generated indicating the traffic has been successfully traced to that point.

Figure 2. Example of a system for network traceback using timing-based watermarking.

We claim a number of desirable properties for our method:

  • Encryption of the application traffic normally will not interfere with traceback based on timing.
  • The use of stepping stones to substitute new packet headers does not interfere with timing-based traceback.
  • The method is robust to deliberate attempts by the attacker to manipulate timing. Dramatic timing manipulation by the attacker to evade network traceback produces undesirable delays for the attacker, and may make the attack traffic even more easily recognizable and traceable.
  • The method is very subtle and can benefit from all of the known results on concealment of watermarks.
  • The method does not rely on cooperation by intermediate networks or hosts. Once the watermark is embedded the analysis process is completely passive and may be done at any point or points on the attack path.
  • With proper choice of the watermarking parameters the detection (true positive) rate can be made arbitrarily high, and the false alarm (false positive) rate can be made arbitrarily low. The only requirement is that there be a sufficient number of packets available for watermarking purposes.

These properties have been confirmed in our simulations and our experiments across the Internet, across many stepping stones.

The techniques used by attackers to evade traceback are called countermeasures . We group them into 3 categories:

  • Basic : Spoofing IP source addresses, Encryption of packet payload, Use of stepping stones (intermediate hosts), and Perturbation of packet timing characteristics.
  • Enhanced : Dropping, retransmitting, or reordering packets in a flow, Re-packetization of packets data in a flow, Tunneling (VPNs, IP within IP, encryption of header and payload), Mounting slow, long-timescale attacks, and Splitting one flow into multiple flows, then merging them back together at another point in the network.
  • Advanced : Addition of padding traffic (chaff, camouflaging), Use of mixers or anonymizing proxies, and Onion routing.

This project will include development of software, extensive testing on large volumes of traffic, and demonstrations of the effectiveness of the method. We believe that active watermarking of packet timing will be the best single tool available for attack attribution across the Internet. It will also allow “picking up the trail” when the attack traverses networks that do not cooperate in attack attribution.

 

 

 
  last updated September 29, 2004 by reeves at eos dot ncsu dot edu