ICMP, the Internet Control Message Protocol, was originally designed (RFC 792, 1981) to convey error conditions back to the sender of an IP packet. In today's Internet, ICMP is somewhat of an anachronism, since pretty much all programs and protocols contain their own error detection and recovery logic. ICMP packets don't use port numbers like UDP and TCP do, but have a message type and message code field in the header instead. Ping packets can also have a data portion (payload). This triggered a big hunt for "covert channels" more than a decade ago, when an article on "Project LOKI: Arbitrary information tunneling" appeared in Phrack Magazine. Today, most firms and institutions keep "ping" blocked across their perimeter firewall, but primarily since the impact of blocking it is marginal, and not because of "covert channel" concerns. It has been a long time since mal-code authors last effectively used ping for communication. And why should they - http and https are working just fine across most corporate firewalls. Another attack, the "smurf", relied on ICMP's ability to respond to a broadcast packet. Basically, a single "ping" sent to the broadcast address of a subnet was answered by all the active hosts on that subnet. Very neat to quickly map what's out there, but also a really good "amplifier" in a denial of service attack. This non-feature of ICMP has therefore long since been fixed: All current Operating Systems have broadcast ICMP either off by default, or support a configuration parameter to turn it off.
ICMP/3 One of the cool features of ICMP Type 3 is that the error messages actually contain the first few bytes of the original packet that triggered the error. Firewalls unfortunately tend to ignore this information, and only display a useless information like "Denied ICMP type=3, code=3 from 88.1.2.3 on interface outside". A good old tcpdump or decent IDS will tell you more: 18:12:34.068212 IP 88.1.2.3 > 173.2.3.4: ICMP 88.1.2.3 udp port 53 unreachable, length 65 At offset 0x001C (marked in blue), you can see the start of the original datagram. In this case, the system at 88.1.2.3 responded with an ICMP/3:3 "Port unreachable" because 173.2.3.4 apparently sent a DNS request for "www.ibm.com" to 88.1.2.3, and the latter does not seem to be running a DNS service. If you ever find your firewall under a deluge of ICMP/3 packets, sniffing them to determine the embedded original packets could help to tell you more. ICMP/3 Type 4, "Fragmentation Needed but Don't Fragment Bit Set" is used to determine the maximum size per IP packet that a path between source and destination can support. This so-called "PMTU Discovery" helps to ensure that packets are sent at the maximum size that can squeeze through, which avoids fragmentation and reduces the bandwidth used for packet headers as compared to actual payload. In the frenzy to ban all ICMP through firewalls a decade ago, the rather useful ICMP 3/4 messages got blocked along with everything else. PMTU discovery is largely defunct today. ICMP/11
The IETF started work on a paper that lists both the "threat" of ICMP and "impact" caused when an ICMP message is blocked at the perimeter. Today, a lot of firms block everything ICMP, and accept that doing so can lead to delays and time-outs in some UDP based applications. A less paranoid and equally well accepted practice is to permit ICMP/11:0 and ICMP/3:4 error replies from the outside, but to rate-limit these packets to prevent flooding. But this is the Cyber Security Awareness Month. So ... time to improve your awareness: If you currently have all ICMP blocked on your perimeter, sniff the ICMP traffic on the outside of the firewall for a day to see what you are missing. If you currently permit ICMP through your perimeter, sniff the ICMP traffic for a day to see what it is that you are letting through. There's no telling what you might find, in either case :)
|
Daniel 377 Posts ISC Handler Oct 19th 2009 |
Thread locked Subscribe |
Oct 19th 2009 1 decade ago |
Of course, tunneling through ICMP has been a favourite at hotels and coffee shops.
http://hackaday.com/2009/08/21/tunneling-ip-traffic-over-icmp/ I did a very similar thing, but using ppp back in the day. |
Anonymous |
Quote |
Oct 19th 2009 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!