From owner-freebsd-questions@FreeBSD.ORG Thu Jun 16 22:57:59 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org 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 3522516A41C for ; Thu, 16 Jun 2005 22:57:59 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from smtp-out6.blueyonder.co.uk (smtp-out6.blueyonder.co.uk [195.188.213.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86D7143D5E for ; Thu, 16 Jun 2005 22:57:57 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from [82.41.37.55] ([82.41.37.55]) by smtp-out6.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Jun 2005 23:58:37 +0100 Message-ID: <42B203F3.6080502@dial.pipex.com> Date: Thu, 16 Jun 2005 23:57:55 +0100 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7.8) Gecko/20050530 X-Accept-Language: en, en-us, pl MIME-Version: 1.0 To: Joe References: <20050616165840.64703.qmail@web41009.mail.yahoo.com> In-Reply-To: <20050616165840.64703.qmail@web41009.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 22:58:37.0123 (UTC) FILETIME=[EDF45130:01C572C6] Cc: freebsd-questions@freebsd.org Subject: Re: SMP and networking under FreeBSD 5.3 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2005 22:57:59 -0000 Joe wrote: >Thanks Alex, > > Below are my rules. I have removed the IP addresses and >replaced with x.x.x.x in most cases. Also some ports have been >turned to y's instead of the actual port. > > I don't want to go into the details of your firewall; all I can offer is general advice for you to apply if you wish. There are plenty resources out there from the various man pages to the handbook. Firewalls can be trickier than they look and NAT makes them significantly more complicated to fathom correctly. I don't claim to be any kind of expert and everything I know started life being written by someone else :-) Any mistakes are most likely my own! I will say that it is worth making sure you understand your own firewall. At one point you suggested that you wanted to make your firewall script start later so that you had access to your IP address. I think you are on to a loser there because there is not particular time when DHCP finally gets the IP address. If your provider is down, it might take minutes, hours or even days. You could keep polling in some way to see if you had an IP address and not running your rules script until you did, but it would seem better to just write rules which work even without the IP address. Plus, that would also not work if you ever had a second external interface (e.g. an old-fashioned modem) which needed firewalling irrespective of the status of your ethernet interface. Although a firewall often need to know the actual addresses of hosts other than itself there is, as far as I can figure out, no logical reason for it to need to know it's own IP address if you have the "me" construct. (If, like my machine, your firewall is just another computer on a small network that is allowed to do exactly the same things as any other host on that network, then it needn't even use "me". This makes life much easier because it interferes less with NAT). If you have "me" then you can always distinguish between your firewall and the rest of your network. Take the non-NAT case first: allow all from me to any out xmit ext_if allow all from any to me in recv ext_if These rules could only be triggered by packets addressed directly to your firewall. If you follow it with e.g. deny all from any to any out via ext_if deny all from any to any in via ext_if then you close off your internal network. NAT makes things more complicated, because before or after NATing (depending on the direction) packets from your network can look like they originate on your machine or are destined for it. E.g. allow all from me to any out xmit ext_if must come before the NAT rule because after NAT-ing all your internal packets are going out ext_if. whereas allow all from any to me in recv ext_if must come after the NAT rule to be sure that it is actually your firewall which is the recipient. If all you have is a small network, then there may be no reason to differentiate your firewall from any other machine. In this case, it is perfectly sufficient to write rules based on the ext_if alone. So I have rules like: # Allow connections initiated from internal network ipfw add allow tcp from any to any out xmit ext_if setup # Allow TCP through if setup succeeded ipfw add pass tcp from any to any via ext_if established The only IP addresses in my whole firewall are the limited number of hosts which can initiate some kind of connection into my network e.g. ipfw add allow tcp from x.x.x.x to any ssh setup (x.x.x.x not because I need to hide the IP but because I can't be bothered to find it in the firewall script :-)) NB that rule says any for recipient because it was written before me existed. But since my network is NATed, it would always be a packet header for my firewall and could only get elsewhere if I explicitly forwarded it. There's no mention of the interface because a prior rule has already allowed internal connections which would match. Looking at it now, I might get picky and put an interface spec in there just to be completist. It's often said that there is no security in obscurity, and while I don't always agree, I do think that if you actually have to hide the IPs in your firewall for it be secure, then it isn't secure. Since my firewall never mentions my IP address, I can publish the whole thing and even if it has flaws it won't help since you don't know where I am :-) A bit long-winded, but I hope it helps, --Alex