From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 17:48:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79BD837B401; Wed, 2 Jul 2003 17:48:36 -0700 (PDT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84B2A43F85; Wed, 2 Jul 2003 17:48:35 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([141.149.47.46]) by out005.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030703004834.BQYB20032.out005.verizon.net@mac.com>; Wed, 2 Jul 2003 19:48:34 -0500 Message-ID: <3F037D5B.9070908@mac.com> Date: Wed, 02 Jul 2003 20:48:27 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com> <3F036571.8030609@mac.com> <3F036DEE.8010408@tenebras.com> In-Reply-To: <3F036DEE.8010408@tenebras.com> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [141.149.47.46] at Wed, 2 Jul 2003 19:48:34 -0500 cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 00:48:36 -0000 Michael Sierchio wrote: > Chuck Swiger wrote: [ ... ] > Security is an ill-defined concept. I prefer to think in terms > of mitigating risk. Sure, that works for me. > In any case, deny_incoming offers some extra measure of security. Does it? Serious question, as none of the connections deny_incoming may block would be permitted in the absence of natd and the divert socket, or ipf/ipnat, if you prefer. From "man natd": If you specify real firewall rules, it is best to specify line 2 at the start of the script so that natd sees all packets before they are dropped by the firewall. Wrong order, if you prioritize security-- you worry about NAT'ing traffic that is permitted by the security policy and firewall rules. Most people implementing NAT who follow this advice effectively circumvent egress filtering that may have otherwise applied. [ ... ] >> Let me pull out a couple of quotes from various people: > > You were better off when invoking "science" -- now you're > invoking the mob ;-) If I quoted the opinions of a bunch of chemists about the relative security, or lack thereof, of NAT-- it would be entirely valid to criticise the relevance or expertise those people have with regard to the subject. :-) However, if one were to ask these chemists about acid-base titration, solutions chemistry, and the like, their responses would not be "mere opinion" or "invoking the mob". Their comments would be that of professionals discussing their chosen field, and include real-world observational data from experiments they themselves have performed. >> "Since NAT actually adds no security, > > You're of the school that sez "what I tell you three times is true?" It worked for Dorothy, right? :-) -- -Chuck