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

[ reply ]