From owner-freebsd-security Thu Sep 12 19:38:38 2002 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 98D3537B400 for ; Thu, 12 Sep 2002 19:38:32 -0700 (PDT) Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAEF243E3B for ; Thu, 12 Sep 2002 19:38:31 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id VAA00195; Thu, 12 Sep 2002 21:38:30 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from mke-24-167-197-76.wi.rr.com(24.167.197.76) by peak.mountin.net via smap (V1.3) id sma000173; Thu Sep 12 21:38:11 2002 Message-Id: <4.3.2.20020912211509.02e4cb20@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 12 Sep 2002 21:36:27 -0500 To: Jason Stone , From: "Jeffrey J. Mountin" Subject: Re: ipfw, natd, and keep-state - strange behavior? In-Reply-To: <20020912152423.M3276-100000@walter> References: <12908E71-C69D-11D6-90D4-000A27D85A7E@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 03:42 PM 9/12/02 -0700, Jason Stone wrote: > > > Having the firewall permit such packets and counting on the client to > > > correctly discard them is probably a bad idea - after all, if you trust > > > the clients to run a properly configured and non-broken OS, why have a > > > firewall at all? > > > > Defense in depth. > >Yes, that's exactly my point - you are advocating that we have the >firewall permit more than we need to and trust the clients. I'm saying >that of course you try to do as good a job securing the clients as you >can, but you also have the firewall be as restrictive as possible so that >you're trusting the clients as little as possible. >We are not presuming anything of the kind - obviously, any packets that >you mean to deny you set up deny rules for. We are talking about >a situation where you want to allow a particular outbound service. With >your ruleset, you are allowing packets back into the internal network that >should never be allowed in there. With a ruleset that involves >keep/check-state, you have the same semantics in terms of what you mean to >allow, but you deny more packets that shouldn't be allowed. And if you're >only setting keep-state on the rules allowing the outbound setup packets, >you probably don't have to worry about DoS. RIght. One can DOS a stateful firewall if any inbound connections are allowed. This is something to consider when making the choice. Also if you alter the timeouts, which should be just long enough for normal operation with some extra for sanity's sake. Once the limit of stateful rules is reached there should be some sort of clean-up to reduce the impact on legitimate connections. Not sure if IPFW or IPFilter do this, but Cisco's PIX handles this by killing off embryonic connections (ie SYN flood). >We're replacing: > > allow tcp from $INET to any 22 setup > allow tcp from any 22 to $INET established > >with > > check-state > allow tcp from $INET to any 22 setup keep-state Should add in the deny and log for established packets. Rather than unconditionally allow them we can now check them and determine if they are due to an incomplete rule set caused by outbound connections or something less benign. Unless you just want protection. For those doing stateless filtering the idea of only allowing established connections for ports that are opened, rather than a blanket allow, is a good idea. Open the door just enough and no more. That is the whole point of stateful rules. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message