[65641] in North American Network Operators' Group
Re: Firewall stateful handling of ICMP packets
daemon@ATHENA.MIT.EDU (Jeff Kell)
Wed Dec 3 22:50:13 2003
Date: Wed, 03 Dec 2003 22:33:55 -0500
From: Jeff Kell <jeff-kell@utc.edu>
To: Jamie Reid <Jamie.Reid@mbs.gov.on.ca>
Cc: sean@donelan.com, nanog@merit.edu
In-Reply-To: <sfce5f61.046@imail.mbs.gov.on.ca>
Errors-To: owner-nanog-outgoing@merit.edu
Jamie Reid wrote:
> Personal view:
>
> This was a problem when filtering Nachi while it pinged networks
> to their knees.
Well, it was at least the "last straw".
> Sometimes I wonder if there is any legitimate reason to allow
> pings from users at all. If the user really needed to use
> ping, that is, if they were in a position to do anything about the
> results of the ping tests, then they would know enough to
> use traceroute in UDP mode or some other tool.
Personally, I like Rob Thomas (cymru) stance on ICMP filtering as given
in http://www.cymru.com/Documents/icmp-messages.html. This allows pings
and PMTU-relevant unreachables. Granted there have been a few hacker
toys that use ICMP echo-reply or other esoteric ICMP type codes to
communicate with their "slaves", but this could be alleviated to some
extent with "stateful" ICMP (almost an oxymoron).
The Nachi pings can be stopped by vendor C using policy routing but has
a side effect of grabbing some unintended packets (Windows traceroute, I
think). If you can devise a method to see if the ICMP payload is a load
of 0xaa's then you've narrowed it down to a science, but AFAIK vendor C
can't do that (well, maybe an IDS appliance with a custom signature).
You can gain "some" additional protection by rate-limiting ICMP (in the
Nachi ping case) and/or UDP (SQL Slammer, etc), and TCP intercept for
synflooding. Not perfect, but every little bit helps.
Jeff Kell
University of Tennessee at Chattanooga
