Date: Tue, 31 Oct 2000 00:05:21 -0800 From: "Crist J . Clark" <cjclark@reflexnet.net> To: Peter Brezny <peter@sysadmin-inc.com> Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: rc.firewall by default does not allow nat of private internal addresses? Message-ID: <20001031000521.E75251@149.211.6.64.reflexcom.com> In-Reply-To: <001701c042b8$e7f54340$47010a0a@fire.sysadmininc.com>; from peter@sysadmin-inc.com on Mon, Oct 30, 2000 at 04:32:28PM -0500 References: <001701c042b8$e7f54340$47010a0a@fire.sysadmininc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 30, 2000 at 04:32:28PM -0500, Peter Brezny wrote:
> Could someone explain to me why the default configuratoin of rc.firewall
> using the 'simple' configuration does not allow privat ip's to be used on
> the internal network?
>
> I was assuming that since the natd rule is _above_ the
>
> deny ip from 10.0.0.0/8 to any via ${oif}
>
> ipfw would not 'realize' that the packet originated on 10.0.0.0/8 and would
> pass it (since natd should have already translated the packet to the
> external ip before it leaves via the ${oif}...right?
Wrong. The packet comes in the internal interface, goes through the
firewall once, and presumably is accepted. The packet is routed by the
kernel and then runs through the firewall rules as it passes out of
the external interface. A packet will not be processed by natd(8)
until it hits the divert rule. If it reaches the above rule before
being diverted to natd, it still has a 10.0.0.0/8 source address and
is associated with ${iof} so the packet would indeed match the above
rule and be dropped.
> but as written, it appears to me that the rc.firewall provided with 4.1 is
> useless unless you pull out the limits of RFC1918 or at least change them to
>
> deny all from 10.0.0.0/8 to any in via ${oif}
Yep, that should fix it. Many people, including myself, have offered
this solution new firewall users over and over on -ipfw and
-questions, but it never seems to get propagated to the default
/etc/rc.firewall.
Personally, I have decided that its not really terribly important to
block RFC1918 addresses. If you block those, do you add the other
manning-draft ones? How about the whole 192.0.0.0/16? Block multi-cast
and experimental nets (class D and class E)? Recently at SANS 2000, a
speaker in the intrusion detection course threw up a list including
a bunch of other nets including 65.0.0.0-95.255.255.255. Unfortunately,
although those blocks _were_ IANA reserved when she made her slides a
few months ago, the 65/8 and 66/8 blocks have been allocated for use
since. (I should add that she was very responsive when I pointed this
out to her via email.) It's also another place to make silly
mistakes. I was just reviewing some configurations on our border
routers last week when I noticed someone had blackholed incoming
172/8. Now, the fact that we just cut off a big chunk of AOL addresses
does not bother me too much, I think there are others at the company
who would not be too pleased.
Again, IMHO, if you are using RFC1918 nets on a NAT'ed internal net,
it is important to add an anti-spoofing rule like,
deny all from ${net} to any recv ${oif}
Before the divert rule. Adding anything else is superflous. If someone
wants to SYN flood you, for example, they can spoof routable addresses
just as easily as RFC1918 ones. (If I were to SYN flood someone, I
would never use RFC1918 addresses just because people do sometimes
block them). I don't see what blocking them adds.
--
Crist J. Clark cjclark@alum.mit.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001031000521.E75251>