From owner-freebsd-security Mon Nov 26 20:36:53 2001 Delivered-To: freebsd-security@freebsd.org Received: from rfnj.org (rfnj.org [216.239.237.194]) by hub.freebsd.org (Postfix) with ESMTP id 1B3C937B405 for ; Mon, 26 Nov 2001 20:36:32 -0800 (PST) Received: from megalomaniac.biosys.net (megalomaniac.rfnj.org [216.239.237.200]) by rfnj.org (Postfix) with ESMTP id B79CC136F3 for ; Mon, 26 Nov 2001 23:40:34 -0500 (EST) Message-Id: <5.1.0.14.0.20011126232315.00a8fce0@rfnj.org> X-Sender: asym@rfnj.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 26 Nov 2001 23:38:01 -0500 To: freebsd-security@freebsd.org From: Allen Landsidel Subject: Re: Best security topology for FreeBSD 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 06:58 PM 11/26/2001 -0500, The Anarcat wrote: >No. You have a 50/50 chance of strengthening you network. I don't think >you can *weaken* (sp?) it since the machine are placed in serie, not in Spelling is correct, conclusion incorrect. Imagine : You have Firewall_A letting packet X through. Firewall_B is also letting packet X through, because X matches the rules on both that say the packet is safe. Uh-oh, X was actually a malicious packet that (pardon a contrived example) crashes Firewall_B after running some code that it inserted before smashing the stack. Now Firewall_B is open, and Firewall_A may as well be, because any packets that Firewall_A would have blocked can simply be tunneled through a connection to compromised Firewall_B. >So we here have a case where the network is actually strenghten and no >case where it is weaker. --snip-- No reply here. Read above. > > Consider this, however: The DMZ is used to contain normally "insecure" > > services such as web, ftp and mail servers. The area past the firewall(s) > > would ideally contain machines to which no incoming connections are > allowed > > to be initiated. The flip side of this is that the machines furthest to > > the inside are those that are most often operated by unclued users who are > > historically very good at running trojans, viruses, and other malicious > > code on their machines without proper investigation. In any event, the > > first configuration, with the DMZ hanging off the firewall (or more > likely, > > off the same switch/hub that the firewall is connected to) is likely more > > secure than the two firewall option with the DMZ in the middle. > >Why? Because traffic will be exposed that normally wouldn't be; In a one firewall suggestion with the DMZ being just some ethernet ports hanging off the same device that the firewall plugs into, you'll be forced to assume that everything going on outside the firewall is fair game for sniffing, spoofing, whatever. A two machine system gives you a false sense of security inside the DMZ. >Not. Some services are internal, some are external. And the firewall >should control that, not the server. So your answer is to leave every insecure piece of junk server listening on all the machines, and just block them with the firewall. Pardon me while I fire you. > > So, > > the question is, would you rather have a machine compromised inside one of > > your firewalls, or outside of it? > >Er... You're going to put this machine where then? Outside your >firewall? I'm not following you. Now I'm not following you.. put what machine? The compromised machine? Assuming one does get compromised, would you rather have it : A) Inside one of your firewalls you thought was secure. or B) Outside your firewall, where even if it -is- compromised, the security of the interior is not breached along with it. > > Personally, I'd rather have it on the > > outside, where the chances of a compromise affecting the security of the > > other machines in the DMZ is negligible, and the chance of compromising > the > > security of machines inside the firewall is no higher than it was before > > the attack took place. > >You'll have to define your "firewall"'s definition, I guess, because it >is imprecise. Wether you have the single or dual configuration, you >always have the machine "inside the firewall"... No, in the single-firewall method there is only one firewall, and all the untrusted servers hang off the DMZ on the outside. >Having a dual firewall setup is easier to setup, IMHO. Another advantage I >see: if a machine is broke or DOS'd, you pull the plug and cut off only >a *part* of the services. In other words, you don't have performances >penalties for oustide and inside services. :) I don't follow this logic at all. Let N = Number of machines you currently have, and W = Work required to set up and maintain. your network; L = Labor required to set up just one machine. Most of us know pretty much that W = N * L. Are you saying that with N + 1, W is suddenly not only less than (2 * N * L), but also less than the original N * L? The "performance penalties" part of it was utter gibberish to me. >The 2 firewalls are still independant services and an attack that >affects the first one *might* affect the second one, but not necessarly. >And in order to do this, it must get to it in the first place, which >means breaking into it. If you have a single firewall, it can be DOS >attacked and the 2 functionalities (services) are affected. You missed the point. Say you do (what most people will do when setting up this configuration) is buy two identical machines, install the identical OS onto them, and set up identical services.. minimal as they may be for a firewall. At this point, the differences enter, entirely in the firewall rulesets. If someone can compromise the first firewall through some bug or vulnerability, chances are near 100% that they can compromise the second one the exact same way. How would the packets reach the second one you say? Well.. um.. they've already circumvented the first one, so what's stopping them? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message