Date: Thu, 12 Sep 2002 13:16:59 -0400 From: dfolkins <dfolkins@comcast.net> To: freebsd-security@FreeBSD.ORG Subject: Re: ipfw, natd, and keep-state - strange behavior? Message-ID: <001401c25a80$346cbb50$0a00a8c0@groovy3xp> References: <24EBAED8-C671-11D6-90D4-000A27D85A7E@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Chuck Swiger" <cswiger@mac.com> > On Thursday, September 12, 2002, at 01:53 PM, Pierre-Olivier Fur wrote: > > I agree dfolkins stateful packet filtering is really cool :) and having > > stateful and stateless enable at the same time like David is non usefull. > > I have nothing against ipfw cause it's FreeBSD made, but if you really > > want to use statefull packet filtering at its best I recommend you to use > > a native statefull packet filter. > > Let me note that the whole intent of dynamic filtering is to permit return > connections only in response to internal requests, and it presumes that > such connections are somehow "safer". I'm not so confident about that > assumption as some people seem to be. how's that? could you please elaborate? > > Frankly, I'd prefer to use static rules with aggressive ingress *and* > egress filtering, but wont that actually result in an overly permissive firewall? e.g., if you want to allow outgoing http connections, you have to allow packets from any external server port 80 to a whole bunch of tcp ports on internal ips. which would allow anyone to send you packets from port 80, and they wont be dropped by firewall. whereas in the stateful case all you have to do is allow tcp out from any to any 80 keep-state setup, and in this case the dynamic rules would open specific holes in the firewall for just that particular response to an http connection request? > which also avoids the DoS potential involved with > overflowing the number of dynamic connections permitted by a given system, > thus causing the stateful firewall to lose track of older legitimate > connections. (*) true, there is that, but having a short enough syn_ udp_ and short_ lifetime, and high enough number of allowed dyn rules would be pretty safe, no? also, i think you forgot to add the footnote that you implied would be forthcoming by the (*). :) > > Excluding TCP sequence-# based attacks, a static rule forbidding new > external connections (ie, with the SYN bit set and ACK clear) to any but > explicitly permitted services gives you about the same level of security > without the overhead of dynamic firewall rules. YMMV, but in practice it > seems to be fairly hard to perform a man-in-the-middle attack when you can' > t see any of the internal traffic, source routing is blocked, and internal > addresses aren't permitted inbound (ie, anti-spoofing). well, it is not so much for the _incoming_ services that stateful rulesets are useful, but for the outgoing ones. i agree with you that for incoming services it does not seem to matter much if you use stateful rules. but as you may remember in my original inquiry about firewall rules, i was trying to allow _outgoing_ ssh connections, not incoming ones. -- dfolkins 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?001401c25a80$346cbb50$0a00a8c0>