From owner-freebsd-security Sun Nov 25 17: 5: 0 2001 Delivered-To: freebsd-security@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 68A2437B416 for ; Sun, 25 Nov 2001 17:04:53 -0800 (PST) Received: from user-33qtmct.dialup.mindspring.com ([199.174.217.157] helo=gohan.cjclark.org) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 168ACV-0006J5-00; Sun, 25 Nov 2001 17:04:50 -0800 Received: (from cjc@localhost) by gohan.cjclark.org (8.11.6/8.11.1) id fAP6mwb00339; Sat, 24 Nov 2001 22:48:58 -0800 (PST) (envelope-from cjc) Date: Sat, 24 Nov 2001 22:48:58 -0800 From: "Crist J. Clark" To: Cy Schubert - ITSD Open Systems Group Cc: Fernando Germano , security@FreeBSD.ORG Subject: Re: Best security topology for FreeBSD Message-ID: <20011124224858.B228@gohan.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011122031739.A226@gohan.cjclark.org> <200111231250.fANCoha19105@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111231250.fANCoha19105@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Nov 23, 2001 at 04:49:46AM -0800 X-URL: http://people.freebsd.org/~cjc/ 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, Nov 23, 2001 at 04:49:46AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > In message <20011122031739.A226@gohan.cjclark.org>, "Crist J. Clark" writes: > > It is sad to see this poor design, > > > > Internet > > | > > | > > Firewall--"DMZ" > > | > > | > > Internal > > > > Used so very, very much these days (I think thanks to several firewall > > vendors pushing this as a standard design). > > > > A much better design, is > > > > Internet > > | > > | > > Firewall1 > > | > > | > > DMZ > > | > > | > > Firewall2 > > | > > | > > Internal > > > > (This design is actually where the term "DMZ" comes from since it > > actually looks like one here.) > > Given the capability of today's firewalls, packet filtering software > and packet filtering capabilities within routers, I don't see what > the advantage of the second design would be in 2001. Defense in depth. Examples: A glitch/security breach in Firewall1's ruleset/software does not necesarily expose the internal network. Any vulnerabilities in Firewall2 are harder to exploit when protected by Firewall1. > Actually today (2001), the second design is quite dangerous. Sure it > protects your internal network, however it is more difficult to > contain compromised systems from being used as a launching point to > elsewhere on the Internet. I don't see why this is true. > If you want the additional protection of security through depth, try > this: > > Internet > | > | > Firewall1 -- DMZ > | > | > Firewall2 > | > | > Internal > > What does this give you? Well, your DMZ can be easily configured to > protect not only you but make it difficult to launch attacks from your > DMZ. The second firewall is a redundant firewall. If you see any > messages in the second firewall's logs, you might want to investigate > a possible compromise of your first firewall. Many organisations do > this. For example, firewall 1 could be a packet filtering router while > firewall 2 could be firewall with various proxy services, e.g. IP > Filter's FTP proxy, or a firewall with NAT capability. Of course all > of this depends on what you're trying to protect and how much you're > willing to spend to protect whatever you're trying to protect. For > many applications one firewall should be enough. This is not as good, IMHO. One typically allows special access between DMZ hosts and the internal network. Putting these rules on Firewall1, which also faces the hostile network, potentially weakens security. > Also, one could set up other firewalls within an internal network to > control which hosts within your internal network have access to your > most sensitive data, e.g. your financial records. Yep, access controls between different "areas" (for a business: finance, HR, marketing, engineering, etc., for a university: student housing, public machines, academic departments, the registrar, other administrative groups, etc.) of your internal networks is always a good idea when the security benefits balance against the costs. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message