From owner-freebsd-security@FreeBSD.ORG Thu Sep 2 07:32:08 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 3438216A4CE for ; Thu, 2 Sep 2004 07:32:08 +0000 (GMT) Received: from smtp.customer.uunet.se (smtp.customer.uunet.se [195.129.12.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 448D743D48 for ; Thu, 2 Sep 2004 07:32:07 +0000 (GMT) (envelope-from freebsd-security@ust.dk) Received: from [195.24.31.210] (port=45008 helo=[129.181.247.38]) by smtp.customer.uunet.se with esmtp id 1C2m4j-0000Hl-Kr for freebsd-security@freebsd.org; Thu, 02 Sep 2004 07:32:05 +0000 Message-ID: <4136CCF5.2080707@ust.dk> Date: Thu, 02 Sep 2004 09:34:13 +0200 From: Laust Jespersen User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <20040901203202.U31170@metafocus.net> <64a8ad980409012057321aea0c@mail.gmail.com> <20040902063720.GB20448@straylight.m.ringlet.net> In-Reply-To: <20040902063720.GB20448@straylight.m.ringlet.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 07:32:08 -0000 Peter Pentchev wrote: > On Wed, Sep 01, 2004 at 11:57:38PM -0400, chip wrote: > >>On Wed, 1 Sep 2004 20:37:52 -0700 (PDT), Dave wrote: >> >>>I'm not a master of the internet RFCs, but I do believe icmp messages have >>>different types. >>> >>>Now to enable traceroute for IPFW, I might put in a rule like this: >>> >>>ipfw add pass icmp from any to me >>> >>>However, how would I make a rule to limit icmp messages to just those used >>>by traceroute? Can the messages be distinguished as such? >>> >>>A dynamic rule that exists only for the duration of a traceroute execution >>>would be even better. I take it 'setup' or 'check-state' would follow in >>>that case? >> >>Dave, >> >> 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: >> >>http://www.cisco.com/warp/public/105/traceroute.shtml >> >>>From a quick google search however, I find the following from: >>http://lists.freebsd.org/pipermail/freebsd-security/2004-February/001585.html >> >># 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 > Apart from Peter's excellent clarification, let Me recommend reading Dru Lavigne's great article series on ipfw located at onlamp: http://www.onlamp.com/pub/a/bsd/2001/04/25/FreeBSD_Basics.html http://www.onlamp.com/pub/a/bsd/2001/05/09/FreeBSD_Basics.html http://www.onlamp.com/pub/a/bsd/2001/06/01/FreeBSD_Basics.html I found them very helpful when I started with ipfw. Med venlig hilsen / Best Regards Laust Jespersen http://www.ust.dk ====================================================================== Viking Rule of Acquisition 1: Remember where you beached the long ship