Security Basics mailing list archives
Re: Removing ping/icmp from a network
From: Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>
Date: Fri, 28 Mar 2008 00:29:32 +0100
On 2008-03-27 Jason wrote:
I don't see any ICMP messages that are a MUST for network operation.No, they're not a MUST. Connections can also just silently fail, leaving you as a network admin at a total loss as to *why* they're failing. Brilliant idea, really.You can limit ICMP. It doesn't have to be everything on or everything off. And I did say, as well as others, allow from trusted sources. The issue is whether strong limits could be set on ICMP without destroying the network and the answer is: yes.
If you ping or traceroute outbound, the "echo reply" or "time exceeded" messages are not coming from trusted sources. If I'm running public servers (in a DMZ, of course) I do allow some ICMP messages to/from those servers to not inhibit troubleshooting of connections to the servers. Those packets are not coming from trusted sources either. I'm not saying that one should allow all ICMP in a LAN (that would be pretty silly), but "allowing only from trusted sources" is nonsense.
That being said, if network monitoring is being done via SNMPv1 or v2 which isn't secure at all, ICMP is the least of your problems. I agree with a few here that you allow ICMP from trusted to untrusted, but not vice versa. And definitely NO ICMP from the Internet.What the heck is so freakin' scary about inbound echo requests? (to public IP addresses, that is) ICMP is not "teh evil(tm)". It's a part of the Internet Protocol suite, and it's there for a reason.ICMP tunneling,
Any kind of packet can be (mis-)used for tunneling. That's not limited to ICMP. To prevent that you'd have to whitelist outbound connections, which is simply not feasible in most scenarios.
host discovery to see if a device is active
So, what if the device is active? If it shouldn't be accessible from the outside: don't make it accessible from the outside. If it shouldn't be accessible from parts of your network: do proper segmentation, so those who should have access are inside the segment and those who shouldn't have access are not. However, if the device should be accessible, there's no point in suppressing ICMP.
are two of the issues with ICMP from the Internet. Flooding, though more rare now, is still possible.
That's what rate-limiting at the network perimeter is for. For floods originating from inside your network I suggest to apply a cat5 o' nine tails to the culprit.
The idea is to limit your Internet footprint to make it as difficult as possible for an attacker.
Nonsense. What you really want to do is to separate your publicly accessible servers from your internal network (in a DMZ) and do proper firewalling between your network segments. Snake-oil like dropping ICMP packets is *not* helping.
There is no need for a web server to respond to ping from the Internet for example.
Of course there is. ping is the easiest (or rather: the appropriate) way to determine if the server is online. And yes, that is relevant information when someone runs into problems accessing your webserver.
I realize that some net admins are getting rather defensive on this topic but there is no need. I believe a balance is required between security and functionality and am not saying that ICMP should be killed. Just limited.
Even limiting can be done in a sensible or a senseless manner.
This is a security forum after all?
This is a mailing list, not a forum, and yes, it is about security. Snake-oil does not qualify as such, though.
Try to remember, there is NO security built into the Internet Protocol suite, which was developed in the 60's. Just because something is there for a reason, doesn't mean it should not be subject to scrutiny.
Last time I checked "scrutiny" was not defined as "ignoring the reason why something was invented to begin with". Regards Ansgar Wiechers -- "All vulnerabilities deserve a public fear period prior to patches becoming available." --Jason Coombs on Bugtraq
Current thread:
- R: Removing ping/icmp from a network, (continued)
- R: Removing ping/icmp from a network Vega - Brunello Ivan (Mar 27)
- Re: Removing ping/icmp from a network Jason (Mar 27)
- Re: Removing ping/icmp from a network Michael Painter (Mar 27)
- Re: Removing ping/icmp from a network Razi Shaban (Mar 28)
- Re: Removing ping/icmp from a network Michael Painter (Mar 28)
- Re: Removing ping/icmp from a network Ansgar -59cobalt- Wiechers (Mar 28)
- Re: Removing ping/icmp from a network Michael Painter (Mar 31)
- RE: Removing ping/icmp from a network Ric Messier (Mar 28)
- RE: Removing ping/icmp from a network Adewale, Akin (IT Services - Infosec Team) (Mar 28)
- RE: Removing ping/icmp from a network Craig Wright (Mar 28)
- Re: Removing ping/icmp from a network Ansgar -59cobalt- Wiechers (Mar 28)
- Re: Removing ping/icmp from a network Jason (Mar 28)
- Re: Removing ping/icmp from a network Ansgar -59cobalt- Wiechers (Mar 31)
- Re: Removing ping/icmp from a network Jon R. Kibler (Mar 26)
- Re: Removing ping/icmp from a network Jason (Mar 26)