Date: Thu, 16 Jun 2005 23:57:55 +0100 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: Joe <josepha48@yahoo.com> Cc: freebsd-questions@freebsd.org Subject: Re: SMP and networking under FreeBSD 5.3 Message-ID: <42B203F3.6080502@dial.pipex.com> In-Reply-To: <20050616165840.64703.qmail@web41009.mail.yahoo.com> References: <20050616165840.64703.qmail@web41009.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42B203F3.6080502>