From owner-freebsd-security Fri Aug 10 4: 1:28 2001 Delivered-To: freebsd-security@freebsd.org Received: from pa169.kurdwanowa.sdi.tpnet.pl (pa169.kurdwanowa.sdi.tpnet.pl [213.77.148.169]) by hub.freebsd.org (Postfix) with ESMTP id 3DAD337B401 for ; Fri, 10 Aug 2001 03:59:00 -0700 (PDT) (envelope-from kzaraska@student.uci.agh.edu.pl) Received: by pa169.kurdwanowa.sdi.tpnet.pl (Postfix, from userid 1001) id B60971C87; Fri, 10 Aug 2001 12:54:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by pa169.kurdwanowa.sdi.tpnet.pl (Postfix) with ESMTP id 0C81D5493; Fri, 10 Aug 2001 12:54:24 +0200 (CEST) Date: Fri, 10 Aug 2001 12:54:24 +0200 (CEST) From: Krzysztof Zaraska X-Sender: kzaraska@lhotse.zaraska.dhs.org To: Tony Landells Cc: freebsd-security@FreeBSD.ORG Subject: Re: distributed natd In-Reply-To: <200108100115.LAA20997@tungsten.austclear.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Fri, 10 Aug 2001, Tony Landells wrote: > The idea is to run two (or more) firewalls in parallel in such a way > that if one failed the other one would pick up the slack without users > noticing. Seems interesting. First, I'd recommend taking at look at IPFILTER. Its nat implementation has few interesting concepts, including restricting outgoing port range and viewing state table. There were however some lincensing problems with this code recently, IIRC. > Obviously, this wouldn't work terribly well with stateful packet > filtering... Could work. I don't see much difference between updating nat dynamic rules and filtering dynamic rules. > I haven't even begun to look at the code for natd, but can anyone > see any fatal flaws in the concept? So I guess that you want to make your firewalls to exchange information about changes in state tables, right? In my opinion both firewalls should communicate over a secure link to avoid fooling them by someone. Theoretically you could use SSL connections but I guess it would consume too much computing power. I would make them communicate over a separate cable (i.e. a small Ethernet connecting only firewalls). Next, I don't know whether they should communicate over TCP or UDP. I would use UDP since it might be faster and it allows broadcasts (one firewall broadcasting changes to all others on the secure network) but is unreliable. A persistent TCP connection may be also considered. Next, I don't know if it is necessary to hack the firewall code. You could probably escape (at least with slow link and fast machines) with an userland daemon watching / updating state table an communicating over secure network. It is however not clean to me how and how often you want to check if firewall is alive. Also it needs to be considered what happens in case one of the firewalls is compromised. I guess this implies compromise of all firewalling machines. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message