From owner-freebsd-ipfw Tue Oct 31 0: 5:33 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 3647037B4CF for ; Tue, 31 Oct 2000 00:05:29 -0800 (PST) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 31 Oct 2000 00:04:02 -0800 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e9V85L707659; Tue, 31 Oct 2000 00:05:21 -0800 (PST) (envelope-from cjc) Date: Tue, 31 Oct 2000 00:05:21 -0800 From: "Crist J . Clark" To: Peter Brezny 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> Reply-To: cjclark@alum.mit.edu References: <001701c042b8$e7f54340$47010a0a@fire.sysadmininc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <001701c042b8$e7f54340$47010a0a@fire.sysadmininc.com>; from peter@sysadmin-inc.com on Mon, Oct 30, 2000 at 04:32:28PM -0500 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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