Note that Unreachables sometimes play a part in defeating SYN floods. This means that if a host you are talking to is under SYN flood attack, you will not be able to reach them if you block incoming Unreachables.

In some cases, you will receive destination unreachable packets from hosts you have never heard of. The most common cause of this is a "decoy scan". An attacker is sending spoofed packets a target using possibly hundreds of source addresses, including one that is the real address. The hacker's theory is that the victim won't wade through all the decoys in order to pin them down.

The best way to solve this is to examine the actual packets as described below. Try to discover is the pattern looks like what one would see in a decoy scan. For example, look for alternating port numbers in TCP or UDP headers contained within the ICMP portion of the packet.

2.3.0 Type = 3, Code = 0 (Destination Net Unreachable)

No route to host A router tells the client that it does not know how to route to anything at all in the network range that includes the host the client is talking to. This indicates either the client chose the wrong IP address, or that routing tables are misconfigured somewhere. Note that sometimes you see the message "No route to host" on your own UNIX machine when your own routing tables are messed up, which is especially common when configuring point-to-point links.

2.3.3 Type = 3, Code = 3 (Destination Port Unreachable)

This packet is sent by a SERVER when a CLIENT tries to connect to a UDP port that isn't running. For example, if you try to send an SNMP packet to port 161, but the machine doesn't support the SNMP service, you will get back an ICMP Destination Port Unreachable packet.

Protocol Decode

The first thing to debug this problem is to check the port numbers within the packet. You probably need to use a sniffing utility as firewalls tend not to log the information. This technique relies upon the fact that ICMP messages include the IP and UDP headers of the original packet. Here is a hex dump of an ICMP unreachable:

 00 00 BA 5E BA 11 00 60 97 07 C0 FF 08 00 45 00
 00 38 6F DF 00 00 80 01 B4 12 0A 00 01 0B 0A 00
 01 C9 03 03 C2 D2 00 00 00 00 45 00 00 47 07 F0
 00 00 80 11 1B E3 0A 00 01 C9 0A 00 01 0B 08 A7 
 79 19 00 33 B8 36                              

Where the bytes 03 03 are the type/code for the ICMP packet. The last 8 bytes of the packet are the original UDP header, which decodes as:

08A7

UDP Source Port = 2215
May be dynamically allocated, so no always important.

7919

UDP Destination Port = 31001
This is very important, it meant the person was originally attempting to contact a service on port 31001.

0033

UDP Length = 51
The length of the original UDP data might be important.

B836

UDP Checksum = 0xB836
The checksum may or may not be important

Analysis

Here are some reasons why you may be seeing this:

Decoy UDP Scans

Somebody may be scanning the person who sent you the ICMP packet. They are forging the source as one of your IP addresses. They will in reality forge lots of different source addresses so that they victim can't be sure who it really is. If you receive large numbers of these packets from the same source in a short time frame, then this is a likely bet. Check the UDP Destination Port field. If it is constantly changing, then this is a very likely scenario.

Stale DNS

A client may send a DNS request to your server, which takes a long time to resolve. By the time your DNS server responds, the client has already forgotten about you and closed the UDP port assigned to receive your response. Check the UDP Source Port field to see if it equals 53. If so, then this is a likely occurrence. Why does this happen? The server may be resolving a recursive query, but its own query packet was lost, so it had to time out and try again. By the time it gets back to the client, it has timed out. Many client applications (especially on Windows) do their own DNS resolution, meaning that they must create their own socket to do so. If they passed the request onto the OS, it is likely the OS would simply have left the socket open.

Multi-response DNS

Another variation is when the client receives multiple responses to the same request. It receives the first response, then closes the socket. Subsequent responses will be dropped. There other variations on this problem. A Sun machine connected with multiple NICs on the same Ethernet will assign both NICs the same MAC address, causing it to receive two copies of every frame, then send multiple responses. Likewise, a poorly written client program (it has been claimed that some DNS resolvers are multi-threaded, but not thread safe) sometimes send out multiple requests, then close the socket on the first response. However, there may be an attempt at DNS spoofing, where a hacker is attempting to corrupt the resolver's cache by sending both a recursive query and a response.

NetBIOS Resolution

If the receiver of the ICMP packets is a Windows machine, look to see if the UDP Destination Port is 137. In this case, the cause of this is the Windows system trying to execute the 'gethostbyaddr()' function, which attempts to resolve the IP address into a name using both DNS and NetBIOS. The DNS request gets sent to a DNS server somewhere (and not sent to the target), but the NetBIOS request gets sent directly to the target. If the target doesn't support NetBIOS, then it will send back an ICMP unreachable.

Traceroute

Most traceroute programs (with the exception of Windows tracert.exe) send UDP packets to closed ports. This causes a sequence of back-to-back ICMP Port Unreachable packets to be sent back to the machine doing the traceroute. Thus, if you are seeing these ICMP packets on your firewall, then somebody inside might be doing a traceroute. You may also see TTL exceeded as well.

2.3.4 Type = 3, Code = 4 (Fragmentation Needed and Don't Fragment was Set)

These are sent by routers attempting to forward IP datagrams that are marked "DF" (Don't Fragment).

Why? Both IP and TCP fragment data, but in different ways. TCP is vastly more efficient at fragmentation than IP. Therefore, stacks attempt to find the "Path MTU (Maximum Transmission Unit)". This ICMP message is sent during that process.

Let's consider ALICE talking to BOB. Both are on Ethernets (max frame size = 1500 bytes), but some intervening link limits the maximum IP packet size to 600 bytes. This means all IP packets sent will be fragmented by the routers on that link into 3 fragments. Since it is much more efficient to fragment at the TCP layer, the TCP stack will attempt to discover the MTU. It does this by setting the "DF" (Don't Fragment) bit in all its packets. As soon as it hits a router than cannot forward a packet that large, the router will send back this ICMP error message. From that, the TCP stack will know how to fragment correctly.

You should probably let these packets through the firewall. Otherwise, the intended recipient will have a hung connection as small packets get through to set up the connection, but the large packets are mysteriously dropped. A common result from this are people who see web pages that are only halfway returned.

Path MTU Discovery is becoming more and more integrated into communication. For example, IPsec needs this functionality.

In general, the rules for source quenches are now (RFC 1122):

• Routers SHOULD NOT generate them.
• Hosts MAY generate them.
• Hosts SHOULD honor them.
• Firewalls SHOULD discard them.

However, hosts still react to Source Quenches by slowing communication, so they can be used as a denial of service. Firewalls should filter these out. If a DoS is suspected, the source address of the packets will be meaningless, because the IP addresses are spoofed.

Source quenches have been known to be sent by some SMTP servers.

Lots of network management "scanners" will precede a scan using a special ping packet. These include ISS scanner, WhatsUp monitor, and others. This will be visible in the payload of the scanner. Most firewalls don't log this payload, so you may need to use some sort of sniffer to capture them or some time of Intrusion Detection System to flag them.

Note that blocking incoming PINGs does not mean a hacker can't scan the network. There are many other ways of doing this. For example, TCP ACK scanning becoming popular -- they usually get through the firewall, and they illicit a response from the target system.

Pings sent to broadcast IP addresses like x.x.x.0 or x.x.x.255 are probably attempts to use your network as a smurf amplifier.

2.11.0 Type = 11, Code = 0 (TTL Exceeded In Transit)

This can be caused by a number of things. If somebody from your site is doing traceroutes out to the Internet, you will see lots of TTL exceeded responses from routers. This is how traceroute works: forces the routers to generate TTL exceeded messages in order to find them.

Another common reason firewall administrators see this is due to routing loops developing in the Internet. Route flapping (constant route changes) is a common problem, and will often briefly result in a loop. This means that while a IP packet is heading towards it destination, the packet gets misrouted to a router that it previously visited it. The packet then gets routed in a circle infinitely -- or it would be, if the routers didn't decrement the TTL field each time and discard the packet once that value hit zero.

Another cause of this is distance. Many machines start with a default TTL of 127 (Windows) or even lower. Routers will often decrement the TTL more than by one in order to reflect slow lines like dialups or transcontinental links. Therefore, a site might not be reachable with a low initial TTL. In addition, some hackers/crackers like to make their site unreachable through this method.

2.11.1 Type = 11, Code = 1 (Fragment Reassembly Time Exceeded)

When sending fragmented IP datagrams, the sender of this message never received all the fragments. Normally, most TCP/IP traffic shouldn't even be fragmented. You will only see this if the traffic is both fragmented AND there congestion somewhere between you and the target.