Date: Thu, 16 Jun 2005 20:06:57 -0700 (PDT) From: Joe <josepha48@yahoo.com> To: Alex Zbyslaw <xfb52@dial.pipex.com> Cc: freebsd-questions@freebsd.org Subject: Re: SMP and networking under FreeBSD 5.3 Message-ID: <20050617030657.26824.qmail@web41007.mail.yahoo.com> In-Reply-To: <42B203F3.6080502@dial.pipex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm still learning the firewall thing. I didn't understand the 'me' clause until recently. I'm using it on my UP box. My router actually runs off a cdrom. Its hard to make changes to it :-). Its an SMP box. It wouldn't help telling you my ip addresses anyway, because my system is internet IP -> nat(dsl modem) -> nat(lan). I have no idea what my real ip address is on the internet. In any case, thanks for the advice. I've been thinking of redoing these rules for 2 years now. So how would your rules look if nat were in the picture? Thanks, Joe --- Alex Zbyslaw <xfb52@dial.pipex.com> wrote: > 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 > > > > > > > ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050617030657.26824.qmail>