From owner-freebsd-security Thu Sep 12 14:30:35 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 2E0BC37B400 for ; Thu, 12 Sep 2002 14:30:29 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCDDA43E42 for ; Thu, 12 Sep 2002 14:30:28 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from smtp-relay01.mac.com (smtp-relay01-en1 [10.13.10.224]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id g8CLUFxD006113 for ; Thu, 12 Sep 2002 14:30:15 -0700 (PDT) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtp-relay01.mac.com (8.12.1/8.12.1/1.0) with ESMTP id g8CLUSVw020722 for ; Thu, 12 Sep 2002 14:30:28 -0700 (PDT) Received: from bust ([12.38.161.88]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H2CH2R00.D46 for ; Thu, 12 Sep 2002 14:30:27 -0700 Date: Thu, 12 Sep 2002 17:30:26 -0400 Subject: Re: ipfw, natd, and keep-state - strange behavior? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Chuck Swiger To: freebsd-security@FreeBSD.ORG Content-Transfer-Encoding: 7bit In-Reply-To: <001401c25a80$346cbb50$0a00a8c0@groovy3xp> Message-Id: X-Mailer: Apple Mail (2.482) 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 On Thursday, September 12, 2002, at 01:16 PM, dfolkins wrote: > From: "Chuck Swiger" : [ ... ] >> 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? Sure. What happens if a local user opens a connection to a popular site which has been trojaned or redirected to malware via DNS hijacking? The fact that you're using dynamic filtering doesn't help a bit when the originating connection was local. >> 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. Nope. While I prefer to use a proxy to centralize web access to the outside via my interior firewall, you can also do something like: add pass tcp from $INET $HIPORTS to any 80,443 add pass tcp from any 80,433 to $INET $HIPORTS established Without performing the TCP 3-way startup (starting with a packet with SYN= 1 and ACK=0), the TCP sequence numbers won't match and the client being scanned from some random external IP will simply drop the invalid connection attempt. >> 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? Not that I have seen, although I've never had a firewall which could do syncookies hit by a DoS. Without that, denial-of-service attacks can pretty easily overflow the connection database, thus causing all pre-existing connections to drop, make creating new connections problematic, and that was as true of a firewall on a multihomed x86 box running FreeBSD 4.1 (now 4.5), as it was of Cisco hardware running IOS. > also, i think you forgot to add the footnote that you implied would be > forthcoming by the (*). Sort of-- my PostScript ("PS:") was the footnote, but I wasn't consistent in labelling it as such. :-) [ ... ] > but as you may remember in my original inquiry about firewall rules, i was > trying to allow _outgoing_ ssh connections, not incoming ones. Ok. Here are the equivalent static rules: allow tcp from $INET to any 22 setup allow tcp from any 22 to $INET established -Chuck Chuck Swiger | chuck@codefab.com | All your packets are belong to us. -------------+-------------------+----------------------------------- "The human race's favorite method for being in control of the facts is to ignore them." -Celia Green To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message