ICMP and Traceroute best practices

Does anyone have some good links for modern best practices? Internally we have some disagreement about whether we should allow or block ICMP and traceroute (well, UDP, since the ICMP policy would cover that). The best I can find are policies from 10+ years ago. In 2003, the internet was a much different place, but even then tcptraceroute and hping existed, so I was never comfortable with policies to block icmp/traceroute wholesale. But, I'd like something solid, something external, to help our group make a decision. Who's got better google-fu than I do?

Do NOT block ICMP. Personally, I don't care about UDP tracing, but I see no valid reason to block that either.

The main argument is that certain components of the ICMP suite are need for PMTUD to work...without it, you'll be managing MTU/MSS for the rest of your life. It's much, much easier to simply allow the whole suite than to selectively allow the type codes needed for PMTUD.

Now find someone who can make a cogent argument as to why you WOULD block it/them. If they say "ping of death", or "smurfing", fire them.

I know this, we agree. I am looking for some documentation other than Ars to present to my coworkers (hell, even if it disagrees with me! I want to comply with best practices, not invent them!), and either my google-fu is weak or it does not exist. The best I found was a random SANS document from 2005 saying that blocking icmp ttl expired messages is not a horrible idea.

Many network security devices block all ICMP messages for perceived security benefits,[6] including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection.[7]

Some implementations of PMTUD attempt to prevent this problem by inferring that large payload packets have been dropped due to MTU rather than because of link congestion. However, in order for the Transmission Control Protocol (TCP) to operate most efficiently, ICMP Unreachable messages (type 3) should be permitted. A robust method for PMTUD that relies on TCP or another protocol to probe the path with progressively larger packets has been standardized in RFC 4821.[8]

A workaround used by some routers is to change the maximum segment size (MSS) of all TCP connections passing through links with MTU lower than the Ethernet default of 1500. This is known as MSS clamping.[9]

MI just posted a very comprehensive RFC on the concept (which I was unaware of, good link MI) but again, I don't see much benefit to managing such a huge ACL.

But for traceroute, most (Windows) hosts still use ICMP for it...but of those that use UDP, I still don't see any problem with it. Ergo, if you allow proper ICMP packets, then ICMP traceroute will work. Why would you add a mechanism to defeat UDP traces?

Let's look at this another way, and address the obvious underlying argument.

The argument about filtering ICMP is normally presented as "don't give the bad guys more information." Yes, there are a few deprecated things that you could reasonably filter (like quench) but let's ignore those for the moment, as most modern devices and stacks properly handle things like that.

Essentially, that argument falls flat for a few reasons...the first of which is "security through obscurity, isn't." The second is that I can easily probe your network with devices other than ICMP. Assuming I've breached your border (a much bigger flaw than allowing ICMP) I can now nmap the hell out of you, and blocking ICMP isn't going to stop me. Most likely, I'll be sending out SSH swarms from whatever host I've compromised to see what responds, because those are going to be the juiciest targets. So what are you going to do about that? Well that's why you have IDS/IPS, right? Right?

Now let's think about why we might want to *allow* ICMP/traceroute. One word: troubleshooting. Operationally speaking, these are pretty much the very first tools you ever use when troubleshooting connectivity issues. Do we really need to make the Ops guys' lives any harder than they already are?

Traceroute is just your preference really but why block a useful tool?

I wouldn't! I just want docs to support my stance.

Quote:

I think it's only something like 8 permits for a transit device, assuming you're doing a default deny.

Well, then there's all the permits for non-transit devices. In this case, the device sits on the edge of a few networks so that ACL would get out of hand real easy (add in some vendor limitations and it's truly horrid). I think it would be a constant battle to ensure that each device in the network is put into the proper round or square hole, and for what gain? The negative impact of allowing many of those ICMP types for transit devices is puny to non-existent.

MaxIdiot, that link is awesome, how have I never seen that? And how does it not have an RFC number yet? That's perfect. Although I'm not keen on building an ACL to deny some particular THROUGH messages like they suggest, it very well describes the negatives of blocking the traffic.

Thanks, guys. Hopefully this helps the next person who has to deal with decade old security stances on ICMP and traceroute.

As the guy who has to troubleshoot when things don't work, I hate it when ICMP is blocked. I'm not a supporter of security through obscurity. Block it at the edge if you must but you can safely assume that any malevolent insider is going to be in a position to do much worse than basic discovery.

As the guy who has to troubleshoot when things don't work, I hate it when ICMP is blocked. I'm not a supporter of security through obscurity. Block it at the edge if you must but you can safely assume that any malevolent insider is going to be in a position to do much worse than basic discovery.

This is my view as well. And as Frennzy has said, I see absolutely no point whatsoever in blocking it to begin with, every time I've seen this and asked why it's just "It's for security..." with no further clarification.

This is my view as well. And as Frennzy has said, I see absolutely no point whatsoever in blocking it to begin with, every time I've seen this and asked why it's just "It's for security..." with no further clarification.

In my admittedly limited experience, ICMP is blocked for a) compliance reasons and b) to prevent hostile outsiders from easily mapping your network. Bad guys do have many other methods of scanning or attacking your network, but why leave the door unlocked? If you make them scan the whole range, that increases the time it takes and thereby the odds of detection. Depending on the organization it may be trivial to temporarily unblock ping for troubleshooting purposes.

Credit card payment processors would be my guess. Some of the ones I've dealt with (indirectly, through the individual businesses themselves) are pretty picky about what's open and what's not.

If that is the case, you are complying with your auditor, not with PCI-DSS requirements. With any audit, but especially with PCI-DSS, always feel free to point the auditors back to the standard to show them where they are wrong.

Additional FYI: On page 13 of this PDF (of which google won't show me the full URL so deal with the referrer), the standard requires that audits attempt to identify live devices that do not respond to ICMP anyway.

Credit card payment processors would be my guess. Some of the ones I've dealt with (indirectly, through the individual businesses themselves) are pretty picky about what's open and what's not.

If that is the case, you are complying with your auditor, not with PCI-DSS requirements. With any audit, but especially with PCI-DSS, always feel free to point the auditors back to the standard to show them where they are wrong.

Additional FYI: On page 13 of this PDF (of which google won't show me the full URL so deal with the referrer), the standard requires that audits attempt to identify live devices that do not respond to ICMP anyway.

Pretty much, though in all fairness fighting shitty QSA's can be a very uphill battle in my experience. I should know, we've been doing it for a while now. Also, what Frennzy said, I figure if an attacker is significantly slowed down by ICMP being blocked it probably isn't a particularly dangerous attacker to begin with, more likely just yet another idiot doing a drive by scan looking for unpatched web servers or whatnot.Of course if the attacker is already inside the network that's obviously not "not particularly dangerous", but in that case ICMP would be the least of my worries.

Some Juniper gear considers anything over 10 ICMP packets from the same source to different destinations in .005 seconds to be an attack.

As can SIEMs and NGFWs. But there's no way for them to distinguish between legitimate pings and malicious pings, so if your attacker runs a slow ping scan, it's not going to be as obvious an attack as if you make him port scan vacant IP addresses.

I don't think even DISA requires that all ICMP and traceroute be shut down, but you do have to shut a lot of it down to stop redirects and, yes, smurfs and floods, which are less effective today because many networks no longer respond to ICMP. Cisco's best practices guide recommends that ICMP only be allowed from trusted IPs, redirects should be blocked, and unreachables should be rate limited. http://www.cisco.com/en/US/tech/tk648/t ... 0f48.shtml

Seriously though, it all depends on your network, your security requirements, and your organization. Maybe you can easily unblock/reblock ping when you need it. Maybe it's not a really vital network. Maybe you work at a bank and your network gets a lot of attempted connections from China.

so if your attacker runs a slow ping scan, it's not going to be as obvious an attack as if you make him port scan vacant IP addresses.

Do you not have IDS/IPS? Because any attack from non-whitelisted (read: network analyst/engineers or monitoring equipment) should trigger an event if it's constantly pinging...even at a slow rate.

Quote:

yes, smurfs and floods, which are less effective today because many networks no longer respond to ICMP.

This is simply not true. The main reason smurfing no longer works is that modern routers disable directed broadcast by default. This was not the case in the mid-late 90s. I'm not sure what you mean by "floods"...but PoDs are mitigated at the host stack, not in the network.