Date: 22 Aug 2000 11:17:25 -0400 From: Lowell Gilbert <lowell@world.std.com> To: freebsd-security@freeBSD.org Subject: Re: icmptypes Message-ID: <rd6r97htjei.fsf@world.std.com> In-Reply-To: billf@chimesnet.com's message of 22 Aug 2000 00:18:46 %2B0200 References: <20000821180351.H57333@jade.chc-chimes.com> <20000821181825.I57333@jade.chc-chimes.com>
next in thread | previous in thread | raw e-mail | index | archive | help
billf@chimesnet.com (Bill Fumerola) writes: > On Mon, Aug 21, 2000 at 03:16:03PM -0700, Rodney W. Grimes wrote: > > > > example from memory: > > > # ipfw add unreach filter-prohib icmp from any to any icmptypes 0,8 > > > > The 8 case would be okay, but returning an icmp unreach for an icmp echo > > reply would be a violation of the protocol spec. I would recomend > > against it. > > Yes, unreaching 0 would be nonsense I suppose. > > On a side note, RFC and protocol blah blah is nice, but sometimes you > just have to drop packets and break spec if the machine is a target. Dropping packets is never a violation of the protocol spec. Returning ICMP "unreachable" errors in response to other ICMP packets would be. This is an important distinction. [It's also what Rodney Grimes actually said.] > If this is being used as a border firewall or some such, then I would > certainly heed Rod's advice on being careful what to break. For a single > machine, I'd be less worried. The gains, however, are fairly small. And some things *will* break. At a very minimum, allow echo replies (possibly via stateful tracking), dest unreachable, TTL exceeded, and header error. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?rd6r97htjei.fsf>