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...
> 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 126.96.36.199 -> 0.0.0.0 PR icmp len 20 56
> > icmp timxceed/transit for 0.0.0.0 - 188.8.131.52 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
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.