2.0 Type = 0 (Echo Reply)
The sender is responding to a ping from your address. This could be because:
Someone's ping that person
Somebody behind the firewall is sending pings to the target.
Lots of applications use pings for various purposes, such as to see if their communication partner is alive, or to measure the response time. A big cause of this is VitalSign's Net.Medic, which sends pings of various sizes in order to measure link speed.
Decoy Ping Sweep
This is even better if you know that BOB trusts ALICE. IP addresses are often used as part of authentication. Let's say the firewall has a rule allowing all traffic from ALICE into the network. By forging all IP packets to be from ALICE (but being source routed through your own machine), then you get free access to the victim network.
More and more core Internet routers are disabling source routed packets. They slow down routing anyway, but they are a huge security risk. There is also no real need for them. Managers should do the same and disable source routing everywhere: on firewalls, on routers, and even on end-nodes so that they won't even accept incoming source routed packets.
See Microsoft Knowledge Base article Q217336 for setting the "DisableIPSourceRouting" on WinNT SP5 systems
2.3 Type = 3 (Destination Unreachable)
The exact code is important in the Unreachable packet.
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
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
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
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:
- UDP Source Port = 2215
May be dynamically allocated, so no always important.
- UDP Destination Port = 31001
This is very important, it meant the person was originally attempting to contact a service
on port 31001.
- UDP Length = 51
The length of the original UDP data might be important.
- UDP Checksum = 0xB836
The checksum may or may not be important
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.
- 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
- 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
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.
2.4 Type = 4 (Source Quench)
These packets are supposed to be transmitted by routers/destination when traffic level
exceeds a certain threshold. Many systems today, however, do not generate them. The reason
is that we now believe that simple packet loss is the best indication of congestions
(since the only reason packets are dropped, in practice, is congestion).
the rules for source quenches are now (RFC
- 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.
These are ping request packets. They are used all over the place; it may indicate
hostile intent of someone trying to scan your computer, but it may be part of the normal
network functionality. See Type = 0 (Echo Response) above for more info.
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 Type = 11 (Time Exceeded In Transit)
This probably doesn't indicate an attack from a hacker/cracker.
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
2.12 Type = 12 (Parameter Problem)
This probably indicates an attack. There are a number of fingerprinting
techniques that will generate these packets.