As the Internet becomes increasingly important as a business infrastructure, the number of attacks on it, especially denial of service (DoS) attacks grows. A DoS attack is an attempt by a person or a group of persons to cripple an online service. Consequen

College of Information Technology

done in the handshake. Fortunately the TCP handshake requires the host sending the initial SYN wait for the returned SYN-ACK prior to sending its first ACK packet. By setting the window size in the SYN-ACK to zero, we can we can determine if the sender is receiving (and responding to) our packets. If the sender sends an ACK-packet with any data, we know the true source is not responding to our packets, and were likely a spoofed packet.

Packet Retransmission

TCP uses sequence numbers to determine which packets have been acknowledged. An ACK-packet communicates to the recipient that all packets it has sent, up to and including the packet with the sequence number in the packet have been successfully received. When a packet is received with an ACK-number that is less than the minimum expected, or greater than the max expected, the packet is dropped and as a way to resynchronize the connection, a reply with the minimum expected ACK-number is sent. We can exploit these replies to probe for spoofed packets. By sending a probe packet, spoofed to be from the internal host, with an ACK number greater than the minimum expected, we can induce a resynchronization ACK from the host being probed. If the probe receives a RST in reply, we can infer the connection was spoofed. A concern with this method is that it may lead to an ACK-storm as both sides attempt to resynchronize. This method is best performed on a firewall where the probe reply could be captured. This will prevent the internal host from seeing the reply, and will prevent an ACK-storm.

Traceroute

Traceroute is a widely used network tool to discover the route from the site traceroute is executed on to another. When used to detect spoofed packets, it may tell you the number of hops to the true source. Unfortunately it is very slow and generally fails when the site being checked is behind a firewall. If the firewall blocks the probing UDP packets (or the ICMP replies), the traceroute program will know only the number of hops to the firewall. However, when the firewall is more hops away from the monitored site than the true site, traceroute will return a hop count greater than expected of the questionable packet. In this case, traceroute can be useful as a detector. Because of its performance, traceroute is a poor general technique for spoofed packet detection. However, in cases where the attacker is nearer the target than the true source site’s firewalls, and the firewall will not allow probes to succeed, traceroute or similar techniques should be considered.

The issues with traceroute introduce a different method of spoofed packet detection base only on previously observed packets. Because the TTL and ID fields are set by the true source, we can learn the expected values for a particular host. Such passive methods are discussed in the next section.

3.4 Passive Methods

Passive methods are a logical extension of the reactive methods discussed earlier. Where observed data will have a predictable value, not relative to some prior packet, we can learn what values are to be expected and consider packets with unexpected values suspicious. Because TTL values are a function of a host’s OS, the packet’s protocol, and the network topology, all which are reasonably static, TTLs can be used as a basis for passive detection. Conversely, IP ID numbers, which generally have a strong relation to prior packets, do not make good candidates for the basis of a passive system. The next section describes several different passive methods and how they could be used to detect spoofed packets.

Passive TTL Methods

By recording, over a period of time, the TTL values of distinct source IP address/protocols we can learn which values are expected from particular hosts. We believe that these are reliable, predictable values of a given IP address/protocol. (See section 7 for experimental validation of this.) This will give us a reasonable basis for identifying suspicious packets from previously observed hosts. Our implementation of this compares observed packets to the expected TTL values for that packet. If the values were anomalous, the packet would be flagged as suspicious. In many cases, we will receive packets from hosts not previously encountered. These will have no entry in the table. Without further information we will not be able to know if the packet’s TTL values are suspicious. How to flag such packets should be left up to the particular application.

However, by taking advantage of the fact that similar IP addresses are commonly the same number of hops away from a monitoring point, we can expand the above method to predict values for previously unseen packets. In addition to learning IP address/protocol to TTL relations we can also learn IP subnet to TTL relations. The predictability based on subnets is not expected to be as high as specific IP address/protocols, but will provide additional information. Rather than use passive methods alone, by using them in

CIT - 104 The Sixth Annual U.A.E. Research Conference