From owner-freebsd-questions Sun Mar 4 17:56:28 2001 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id EDF0137B718 for ; Sun, 4 Mar 2001 17:56:23 -0800 (PST) (envelope-from mwm@mired.org) Received: (qmail 83880 invoked by uid 100); 5 Mar 2001 01:56:22 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15010.62022.322907.484797@guru.mired.org> Date: Sun, 4 Mar 2001 19:56:22 -0600 To: Chris Cc: questions@freebsd.org Subject: Re: FreeBSD Firewall vs. Black Ice In-Reply-To: <111621377@toto.iv> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris types: > Why two seperate firewalls, some guy on securityportal just wrote this > horrid 'howto' on firewall 'placement' that made this mistake as well. > His actually showed diagrams that recommended proxying all internal > traffic through a webserver before it hit another firewall and got > out...a DMZ server no less... you have to see the diagram to get it. Too > funny. > > Unless traffic is so high it will crush the CPU of the fw box, there is > no reason to not simply segment the network and add ruleset groups. Add a > third nic to make one external, one DMZ net, and one internal. This > actually makes it simpler to manage the DMZ rules anyway. It's called "defense in depth". As you've described it, if an attacker breaks into your fw box, the attacker now has access to your internal network, which is a bad thing. With two firewalls, no box on your internal network can be accessed from the internet, so someone has to break into at least two boxes to get to your internal network. Ideally, your monitors alert you about the first breakin and you shut them off before they get that far. To carry things one step further - the two firewalls should be as different as possible. If they're both tracking the same open source OS, then a security problem showing up in that OS means your security just went to pot. Using a proxy in the DMZ for outbound traffic is the correct approach if you want tight control over outgoing connections as well. It's pretty much what Vixie set up for Digital in Palo Alto that they later bundled as a product (DECSEAL?). I'd recommend checking out the Chapman & Zwicky book listed in /etc/rc.firewall for more information, except I might get flack for "pimping" on -questions. > If anything if the traffic is sufficiently high, stick a bridge device > fw 'outside' everything to do any screening that would apply to all of > the nets 'inside'. Good place for an IDS box as well. > > I don't mean this as an attack on your opinion, just that I've seen so > much lately of the 'put another server here, put another one over > there...' personally I want the least amount management that I have to > do and still maintain as much fault tolerance as needed. That's an important consideration as well - and I agree with it. But by rolling two boxes into one, you're trading less management for less security, as the box is only as secure as the least secure server on it. For servers that actually run on the system in question, that's not a major concern. But in merging a firewall - which may well have no servers listening on external ports - with something providing an external service, you're seriously lowering the security of the firewall. I think the MacDonald's approach to server setup ("Here a server, there a server, everywhere a server") is part of the Windows approach to network computing. Since an application crashing the OS isn't an OS bug,putting each application on a separate server makes the OS more stable. Oddly enough, it's identical to the DOS servers that RadioMail used to use. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message