Date: Tue, 27 Nov 2001 00:40:31 -0500 From: The Anarcat <anarcat@anarcat.dyndns.org> To: Allen Landsidel <all@biosys.net> Cc: freebsd-security@freebsd.org Subject: Re: Best security topology for FreeBSD Message-ID: <20011127054030.GB5828@shall.anarcat.dyndns.org> In-Reply-To: <5.1.0.14.0.20011126232315.00a8fce0@rfnj.org> References: <5.1.0.14.0.20011126232315.00a8fce0@rfnj.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon Nov 26, 2001 at 11:38:01PM -0500, Allen Landsidel wrote: > At 06:58 PM 11/26/2001 -0500, The Anarcat wrote: >=20 >=20 > >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 >=20 > Spelling is correct, conclusion incorrect. >=20 > Imagine : You have Firewall_A letting packet X through. Firewall_B is al= so=20 > letting packet X through, because X matches the rules on both that say th= e=20 > packet is safe. Uh-oh, X was actually a malicious packet that (pardon a= =20 > contrived example) crashes Firewall_B after running some code that it=20 > inserted before smashing the stack. >=20 > Now Firewall_B is open, and Firewall_A may as well be, because any packet= s=20 > that Firewall_A would have blocked can simply be tunneled through a=20 > connection to compromised Firewall_B. Yes. But a single firewall design is also vulnerable to this attack. The same way. > >So we here have a case where the network is actually strenghten and no > >case where it is weaker. >=20 > No reply here. Read above. Same here. ;) > >> Consider this, however: The DMZ is used to contain normally "insecure" > >> services such as web, ftp and mail servers. The area past the=20 > >firewall(s) > >> would ideally contain machines to which no incoming connections are=20 > >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= =20 > >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=20 > >likely, > >> off the same switch/hub that the firewall is connected to) is likely m= ore > >> secure than the two firewall option with the DMZ in the middle. > > > >Why? >=20 > Because traffic will be exposed that normally wouldn't be; In a one=20 > firewall suggestion with the DMZ being just some ethernet ports hanging o= ff=20 > the same device that the firewall plugs into, you'll be forced to assume= =20 > that everything going on outside the firewall is fair game for sniffing,= =20 > spoofing, whatever. A two machine system gives you a false sense of=20 > security inside the DMZ. So you say it is more secure because it doesn't give you a false sense of security? Interesting. I guess it's a good point. > >Not. Some services are internal, some are external. And the firewall > >should control that, not the server. >=20 > So your answer is to leave every insecure piece of junk server listening = on=20 > all the machines, and just block them with the firewall. Pardon me while= I=20 > fire you. No. You misunderstood. And you snipped the context of my answer.. This was the context: > If you run your DMZ servers with only things listening on the port > that you=20 > configured to listen on the port, and there are vulnerabilities in > said=20 > servers, then they will be accessible no matter which side of the=20 > firewall(s) the server is on; If not, what's the point in the service? I say, no. They will not be accessible all-round, first because they have host-restrictions algorithms such as host.access and second because the firewall will block some traffic accessing illegitimate port/address combinations.=20 > >> So, > >> the question is, would you rather have a machine compromised inside on= e=20 > >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. >=20 > Now I'm not following you.. put what machine? The compromised=20 > machine?=20 Yes. > 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=20 > security of the interior is not breached along with it. I am confused here. If it is in the DMZ, it is still "in" the firewall, no? Wether the design of the firewall is single or dual, the DMZ is still "in" the firewall. > >> Personally, I'd rather have it on the > >> outside, where the chances of a compromise affecting the security of t= he > >> other machines in the DMZ is negligible, and the chance of compromisin= g=20 > >the > >> security of machines inside the firewall is no higher than it was befo= re > >> 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"... >=20 > No, in the single-firewall method there is only one firewall, and all the= =20 > untrusted servers hang off the DMZ on the outside. Then we have a definition problem. I consider a firewall as not a single piece of soft/hardware, but as a set of it. It's basically an implementation detail to choose a single or dual firewall setup. I'm just saying that one does not weaken the system's security, apart from the "false sense of security" you mentionned that I consider solvable with proper education. :) The firewall wether it is single or dual, have the same functionality, in the presence of a DMZ: (2 designs of dual fw): (and a single fw design): out out out | | | fw1 fw1----+ | | | | | dmz | dmz fw ---- dmz | | | | fw2 fw2----+ | | | | in in in In the second one, you setup a private line between the 2 fws to have direct traffic let through unsniffable directly by the dmz. That is, even if you let direct traffic, where you might prefer having proxies somewhere to avoid direct traffic. =46rom my point of view, the "firewall" in these drawings, is composed of fw1 and fw2 in the dual design, and just fw in the second one.=20 So the dmz is always "within" the firewall, since the single fw design wraps the functionality of fw1 and fw2 within itself to allow access to the dmz: out | +---+ |fw1|---+ +---+ dmz |fw2|---+ +---+ | in > >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. :) >=20 > I don't follow this logic at all. Let N =3D Number of machines you curre= ntly=20 > have, and W =3D Work required to set up and maintain. your network; L = =3D=20 > Labor required to set up just one machine. Most of us know pretty much= =20 > that W =3D N * L. Are you saying that with N + 1, W is suddenly not only= =20 > less than (2 * N * L), but also less than the original N * L? If you want to get into this...=20 Could I modify the equation to say: W =3D N * L * C where C is a variable mesuring the similarity between the machines? :) Given that, L: labor to setup single firewall in single-firewall-design L': labor to setup a single fw machine in a dual-firewall-design W: work to maitain the single firewall network W': work to maintain the dual firewall network In single setup: W =3D 1 * L In dual setup: W' =3D c * 2 * L' where c is a variable mesuring the similarity of the 2 firewalls. If the 2 firewalls are completely different, c =3D=3D 1. If they are the same, c approaches 0.5, so maintaining the 2 firewalls approaches the cost of maintain a single one because they are similar. A single firewall handling everything is (arguably) harder to setup than 2 more simple firewalls. So L >=3D L'. Is L >=3D 2 * L'? Arguable. In other words, you have a few variables you missed. Mainly, the fact that L is not uniform. > The "performance penalties" part of it was utter gibberish to me. Too bad then.=20 > >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. >=20 > You missed the point. Say you do (what most people will do when setting = up=20 > this configuration) is buy two identical machines, install the identical = OS=20 > onto them, and set up identical services.. minimal as they may be for a= =20 > firewall. At this point, the differences enter, entirely in the firewall= =20 > rulesets. Agreed. > If someone can compromise the first firewall through some bug or=20 > vulnerability, chances are near 100% that they can compromise the second= =20 > one the exact same way. How would the packets reach the second one you= =20 > say? Well.. um.. they've already circumvented the first one, so what's= =20 > stopping them? Hmm.. Agreed. But I still maintain this doesn't make the dual firewall design *weaker*. Comparable with the other one, yes. Let's not kill each other over this. ;) A. --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEUEARECAAYFAjwDJ00ACgkQttcWHAnWiGejPACYgkLdnLiMoeOmq9gwiEBiJifY SACgijOZkPn1lozO/HXgEl9z1lYBd24= =LfNy -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- 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?20011127054030.GB5828>