Thursday, March 15, 2012

Reasons for Abnormal ICMP errors

[Orginially posted in the MD2600 newsletter. February 2001]

Continuing the reasons for abnormal packet series, we explore the presence of ICMP Host Unreachable" (Type 3 Code 3) packets. The normal reason for a host unreachable error to occur is that for some reason the host is not online. As stated in the last article. When a packet destined for a network reaches a router attached to the network, the router sends an arp request for the destination host. If the reply does not return, the router will generate an ICMP "Host Unreachable" error back to the sender. However, this is the textbook example on what generates the error.

Now we place a packet filtering firewall in our picture of the network. packet filters have a few things they can perform on a packet. Generally it is Pass, Deny, or Drop. If the filter rule has Pass selected, then the firewall will allow the packet to transverse. If the filter rule has Drop selected, then the packet will be destroyed and forgotten. However if Deny is the action of choice, the firewall will destroy the packet and return the wonderful ICMP "Host Unreachable" error.



The fact that these errors occur as result of connecting to a machine that's off, or the wrong port, is of no great concern. It is when you receive these errors when nothing from your network was sent to the complaining host that should alert you. You might also find TCP packets originating from the complaining network that contain SYN-ACK or RST flags. These are all evidence that a port scan is underway. However it is the network which is generating the ICMP errors which is the target. Your network is merely being used as a decoy to hide the source of the port scan.

A decoy scan is when the port scanner generates multiple port scans with spoofed source addresses that are sent along with the genuine port scan. The purpose of this is that if the scan is detected, it becomes difficult for the target to trace the port scan with certainty. In order to insure successful obfuscation, the attacker will use non-responsive hosts (i.e. down, or heavily firewalled). The reason being is that if the host is responsive its replies can be used to single out the non decoy, via process of elimination. However as we will see this requirement becomes his downfall.

Here's a typical scenario. Jay Random Hacker wants to port scan Top Security Inc. Knowing that a port scan may be spotted, he chooses the decoy technique. He needs to find a few non responsive host (8 is ideal), so he starts off by performing a scan of different networks not related to Top Security Inc. At this point you probably noticed a ping sweep that was not accompanied by a port scan (or it might just to stake out more victims). Then using you're unused ip's as well as others he is able to port scan Top Security without them knowing where it came from. However Top Security has a firewall or two which is replying to most of the scans with ICMP type 3 on all ports blocked using Deny rules. These ICMP replies will be sent to the attacker as well as all the decoys including you. This is when you'll notice the ICMP type 3 traffic coming from Top Security Inc.

To aid in the forensics, gather the logs of all traffic between you and Top Security Inc. during this ICMP type 3 traffic, as well as ping sweeps or port scans in recent history (around a month). Notify Top Security Inc., that you suspect they have been port scanned and have some logged data that could be of use. Depending on the attacker, most likely the ip address in the earlier port scan or ping sweep, will match one of the ip's scanning Top Security. Also if Top Security did not notice the scan (and/or following break-in) you may have given them some timely warning.

No comments:

Post a Comment