From owner-freebsd-questions@FreeBSD.ORG Tue Jan 20 22:07:18 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1958A16A4CE for ; Tue, 20 Jan 2004 22:07:18 -0800 (PST) Received: from lakemtao08.cox.net (lakemtao08.cox.net [68.1.17.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13F4F43D2D for ; Tue, 20 Jan 2004 22:07:16 -0800 (PST) (envelope-from micheal@tsgincorporated.com) Received: from dredster ([68.12.79.37]) by lakemtao08.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040121060714.UCBQ2412.lakemtao08.cox.net@dredster> for ; Wed, 21 Jan 2004 01:07:14 -0500 Message-ID: <034301c3dfe4$e336c1e0$0201a8c0@dredster> From: "Micheal Patterson" To: References: Date: Wed, 21 Jan 2004 00:07:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: ipfw/nated stateful rules example X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 06:07:18 -0000 ----- Original Message ----- From: "fbsd_user" To: "Micheal Patterson" ; Sent: Tuesday, January 20, 2004 8:18 PM Subject: RE: ipfw/nated stateful rules example > You are doing keep-state on both the Lan interface and the public > interface and it only works because the returning public packet is > being matched to stateful table entries posted by the Lan interface > keep-state rules and not the stateful table entries posted by the > external interface. Yes you are making it work, but not work > correctly. In the true security sense, this is un-secure and > invalidates the whole purpose of using keep-state rules at all. This > would never be allowed by an real firewall security professional. > > If you fell secure in using this method, be my guest. But know it's > not really providing you protection for packets inserted by an > attacker. It nullifies the benefits of keep state on the interface > facing the public internet. It's working because my fbsd box is in router mode and I don't want people to communicate with it's serial ip unless I request it. That's why there are two stateful entries. One to protect the serial and one to protect my lan. NAT sits happily in the middle. Let's take this to a more real world scenario though. You have the following: Cisco 3745 connected to a Sprint ATM circuit. Serial IP's: 62.121.1.2 Your side / 62.121.1.1 Sprint side. Cisco LAN: 10.0.0.1/30 Firewall WAN: 10.0.0.2/30 Firewall LAN: 64.1.1.1 The above is a generic dmz setup. Since this is on Sprint, the routers serial IP is not accessible either unless you specifically request it via their NOC so they can remove their default filters. I'm assuming that we're in agreement here. In this scenario, where would you put stateful? On the LAN side. Now, assume that this is a nat'd network with 128 IP's and you've got 200+ systems behind it. Cisco 2620 connected to Sprint DS1: Serial IP's: 62.121.1.2 Your side / 62.121.1.1 Sprint side Cisco LAN: 64.1.1.1 Firewall WAN w/NAT: 64.1.1.2 Firewall LAN: 192.168.1.0/24 In this scenario, you have NAT running on the firewall and doing the translations for the internal range. NAT sits on your WAN interface and does it's merry little thing. If I understand you correctly, you're saying that "Private > NAT > WAN Keep-State > World" is the accepted manner of a network security professional and is secure. Whereas what I'm doing "Private LAN Keep-State > NAT > World" is not secure and would not be accepted by a security professional? How do you figure that either method is more or less secure than the other? If stateful is breached in either method, the underlying network is compromised. Sorry, it's late and I may be missing something but I just don't see it. -- Micheal Patterson Network Administration TSG Incorporated 405-917-0600