On Sun, 23 May 2004, pmok wrote:

> Its not a DoS...Its from those folks (Windows users) who still are 
> infected with either the Welchia virus (or related) and still don't 

Nope.  That uses ICMP Echo, not ICMP errors.

> You can't really stop it, but to act defensive. Do what Chet Harvey 
> said, don't log it and drop it. 

Dropping ICMP errors is usually a bad idea.  See below.

> This is what ICMP is really used for... 
> http://www.freesoft.org/CIE/Topics/81.htm
> 
> But of course, you can add "for virus spreading". 
> (Thanks to Welchia and similar)...

Not really.  ICMP *errors* are pretty useless for "spreading" anything,
and Welchia only uses ICMP Echo (a.k.a. "ping") to check for the existence
of a system before attacking it, not to perform the actual exploit.  
There are plenty of exploits that attack "blind" and won't be deterred by
blocking pings, and meanwhile blocking pings removes a useful diagnostic
capability.  If you call up your ISP about a connection problem, one of
the first things they'll do is try to ping you.

The infamous Ping o' Death was really a vulnerability in fragment
reassembly, and only coincidentally related to ping due to the original
choice of exploit tools.

> ----- Original Message ----- 
> From: "Matt McGuire" <mmcguire at o1 dot com>
> Sent: Sunday, May 23, 2004 4:13 AM
> 
> 
> > At times I am getting a lot of activity in the firewall logs.  I assume
> > this is a Dos attack with icmp?  Am I correct?  Also what is the best
> > way to stop this from happening?  I do not let this traffic through,
> > however the load on the firewall becomes so high that WAN access is
> > slowed to a crawl. Below is one of many identical entries.

More likely it's the load due to the logging than the bandwidth or
processing of the packets.

> > 11:06:03.544257 sis1 @0:19 b 63.163.92.73 -> 0.0.0.0 PR icmp len 20 56
> > icmp timxceed/transit for 0.0.0.0 - 63.163.92.1 PR icmp len 20 56 icmp
> > 3/2 IN

If the "0.0.0.0" is really correct, then that's a badly formed ICMP error
that should have been discarded anyway.  But one wonders how such a packet
could have gotten routed to you in the first place.  Unless the log entry
is lying, your immediate upstream neighbor (at least) must be
brain-damaged.  Ordinarily I'd use tcpdump to find out the "real story",
but of course that's not an option on a box with no shell access. :-)

It's difficult to use ICMP errors as an attack, since they never provoke a
response, and they get demultiplexed on the basis of the embedded IP
header and partial payload.  In particular, bogus ICMP errors will never
get forwarded by a NAT router, even without filtering, simply because they
don't match any NAT table entries.  Anyone with enough information to
forge a plausible ICMP error can probably also use it in more effective
ways. :-)

Meanwhile, the #1 problem with Path MTU Discovery is the clueless blocking
of ICMP errors, and "MSS clamping" is a Band-Aid fix for it that only
helps in a subset of possible cases.

					Fred Wright