From owner-freebsd-security@FreeBSD.ORG Thu Sep 2 06:37:06 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A31716A4CE for ; Thu, 2 Sep 2004 06:37:06 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 57BC443D48 for ; Thu, 2 Sep 2004 06:37:04 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 4743 invoked from network); 2 Sep 2004 06:35:34 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 2 Sep 2004 06:35:34 -0000 Received: (qmail 45920 invoked by uid 1000); 2 Sep 2004 06:37:20 -0000 Date: Thu, 2 Sep 2004 09:37:20 +0300 From: Peter Pentchev To: chip Message-ID: <20040902063720.GB20448@straylight.m.ringlet.net> Mail-Followup-To: chip , freebsd-security@freebsd.org References: <20040901203202.U31170@metafocus.net> <64a8ad980409012057321aea0c@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <64a8ad980409012057321aea0c@mail.gmail.com> User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org Subject: Re: IPFW and icmp X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 06:37:06 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 01, 2004 at 11:57:38PM -0400, chip wrote: > On Wed, 1 Sep 2004 20:37:52 -0700 (PDT), Dave wrot= e: > >=20 > > I'm not a master of the internet RFCs, but I do believe icmp messages h= ave > > different types. > >=20 > > Now to enable traceroute for IPFW, I might put in a rule like this: > >=20 > > ipfw add pass icmp from any to me > >=20 > > However, how would I make a rule to limit icmp messages to just those u= sed > > by traceroute? Can the messages be distinguished as such? > >=20 > > A dynamic rule that exists only for the duration of a traceroute execut= ion > > would be even better. I take it 'setup' or 'check-state' would follow = in > > that case? >=20 > Dave, >=20 > I can't comment much on how to build the exact rules you need, but > you should be made aware that different implementations of traceroute > achieve the results in different ways. Cisco routers and most *nix > boxen use UDP packets while Microsoft stuff uses ICMP. A good guide > to the difference: >=20 > http://www.cisco.com/warp/public/105/traceroute.shtml >=20 > >From a quick google search however, I find the following from:=20 > http://lists.freebsd.org/pipermail/freebsd-security/2004-February/001585.= html >=20 > # TRACEROUTE - Allow outgoing > ${fwcmd} add pass udp from any to any 33434-33523 out via ${oif} I think Dave was a bit more interested in setting up his rules for *incoming* packets, not the outgoing ones :) No matter which favor of traceroute is used, they all depend on receiving 'Time exceeded' ICMP responses (type 11) - usually 'time exceeded in transit' (type 11, code 0), but allowing all of type 11 should put you on the safe side. Also, when blocking incoming ICMP requests and replies, please, please, *please* take care to NOT block type 3 (destination unreachable) - blocking 'need to fragment' packets (type 3, code 4) is a way to instant gratification, if your idea of gratification is being a blackhole router which breaks the Path MTU discovery for any poor soul who decides (or simply has to) route through you, and for your own outgoing connections, too. Other useful ICMP types are 0 (echo/ping reply), 4 (source quench, for throttling down (usually) TCP connections if some device further down the path cannot handle the packet rate), 8 (echo/ping request), 30 (Windows traceroute), but you *could* block those without much harm to the TCP/IP protocol stack, the only thing harmed would be functionality - e.g. blocking types 0 and 8 would deprive you of pings, blocking type 30 would stop Windows traceroute from working, blocking type 4 would mean that TCP connections going over a much slower link somewhere down the line would be additionally slowed down by lots of retransmissions instead of simply bringing down the packet rate. However, whatever you block, please don't block type 3 code 4, and better not block any of the type 3's :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wou= ldn't be false. --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBNr+g7Ri2jRYZRVMRAufiAKCK5+vZRdZoVulPyHxsLrIchuwPzACfUTB0 +DazyfzZWOi2Q40Fr4Io03k= =364A -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC--