[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: icmp: type-#69



On Sun, 15 Sep 2002, Tim Haynes wrote:

> Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com> writes:
>
> > I noticed (among the more common icmp: echo request) these odd icmp
> > types. The external net, my firewall is connected to, is plagued by
> > smurf-attacks from various sources. So I have tcpdump watching.
> >
> > Of what I gather, this icmp-type should not exist. Can anyone shed some
> > light on this:
> >
> > | 11:49:16.273069 62.211.198.163 > x.y.z.255: icmp: type-#69
> > | 11:54:58.078683 62.211.198.163 > x.y.z.255: icmp: type-#69
> [snip]
>
> Could you include a complete `tcpdump -X' on one or two of the
> packets, maybe make a series of them available for download in
> libpcap form so I can oogle them in ethereal?

I missed that opportunity. Did not expect to see anything like that. I
would have liked to oogle that stuff in ethereal myself.

> Preferably, also, can you provide an iptables firewall log entry as
> well so we can see more relevant fields?

See, problem is the firewall to my private net is just an old i386
with a processor + ram + nics + floppy (no hard drive or other fancy
stuff). Everything runs out of a ram disk. So there's not enough space
for all that. Logging goes to a virtual console. So it's just a
fullscreen I'm able to see.

> You're right, ICMP type 69 is pretty darn' invalid - a quick
> `ipchains -h icmp' makes it obvious that the highest valid ICMP type
> is 18.

There actually seem to be a few more. See:

  http://again.net/cidr

> Are you filtering outgoing icmp-parameter-problem types? Because if
> not, I think you probably want to be rate-limiting them (and
> probably all outgoing ICMP and, for that matter, UDP) seriously.

Yes, I do that and drop everything that goes to the broadcast address,
among other things. These (probably) smurf-attacks are really a plague.

> The above does smell like someone attempting to DoS either you, or
> some poor sod in Italy, by sending invalid ICMP to your broadcast
> address to see who responds.

Most of them (the vast majority) are valid icmp: echo requests.
During the passed 75 days uptime, the firewall box dropped:

  34M   18G DROP   icmp --  eth0   0.0.0.0/0    x.y.z.255
1556K  195M DROP   udp  --  eth0   0.0.0.0/0    0.0.0.0/0  udp dpts:137:139
44279   13M DROP   udp  --  eth0   z.y.z.0/24   255.255.255.255

It's the 18G that worries me a bit. The ISP folks (incompetent
winblows admins, I guess) don't know/want/care doing anything about
it.

> (There's no guarantee that 62....163 is the real source of the
> packets here;

If my guess is right, and these are smurf-attacks, they're trying to
take down those boxes. I know that some of them are known spam
sources, and taking them down is the maybe right ting to do ;-)

> that's why I want a firewall log so you can check for
> (a) consistent TTLs and (b) realistic TTLs given a comparison
> against traceroute to that IP# - if the TTLs don't match, then you
> know the source IP# has been spoofed so it's an attempt by a *third*
> party to get *you* to DoS *them*.)

I'll try to find a way to get some traces off my firewall box and, if
I see more funny stuff, I'll get back.


Cheers,
Cristian



Reply to: