From owner-freebsd-current Thu Jun 27 21:55:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA06407 for current-outgoing; Thu, 27 Jun 1996 21:55:28 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA06402 for ; Thu, 27 Jun 1996 21:55:24 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id WAA13473; Thu, 27 Jun 1996 22:55:10 -0600 (MDT) Date: Thu, 27 Jun 1996 22:55:10 -0600 (MDT) Message-Id: <199606280455.WAA13473@rocky.mt.sri.com> From: Nate Williams To: current@freebsd.org Subject: IPFW bugs? Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is really weird. I'm trying to setup my firewall using all the documentation I can get a hold of. Unfortunately, there are 'bugs' in the documentation which I unfortunately can't get to right now. In any case, I'm trying to make my system 'fairly' secure to the outside world, but let everyone on the inside not even be aware of the firewall. In the below context, $1 is the network address for our internet connection, which could be one of ppp[0123] depending on conditions. --- CUT HERE ------- # Spoofing our internal machines ipfw add 10 deny log all from 204.182.243.0/24 to any via $1 in ipfw add 10 deny log all from 127.0.0.1 to any via $1 in # RFC 1918 unroutable hosts ipfw add 11 deny log all from 192.168.0.0/16 to any via $1 in ipfw add 11 deny log all from 172.16.0.0/12 to any via $1 in ipfw add 11 deny log all from 10.0.0.0/8 to any via $1 in # Deny chargen,tftp,sunrpc #ipfw add 12 deny log all from any to any 19,69,111 via $1 #ipfw add 13 deny log all from any 19,69,111 to any via $1 # Who,syslog #ipfw add 12 deny log udp from any to any 513,514 via $1 #ipfw add 13 deny log udp from any 513,514 to any via $1 # Allow SSH/SMTP/DNS/POP3 connections to/from anywhere ipfw add 20 pass tcp from any to any 22,25,53,110 via $1 # Trusted hosts for almost everything ipfw add 20 pass all from 128.180.0:255.255.0.0 to any via $1 ipfw add 20 pass all from trust.laptop.com to any via $1 # allow outgoing TCP connections to be established ipfw add 30 pass tcp from 204.182.243.0/24 to any via $1 setup # Allow 'established' connections to get in ipfw add 30 pass tcp from any to any via $1 established # Deny incoming TCP connections ipfw add 40 deny log tcp from any to any via $1 setup # Allow NTP stuff through ipfw add pass all from any 123 to any via $1 ipfw add pass all from any to any 123 via $1 # Deny incoming TCP connections ipfw add 40 deny log tcp from any to any via $1 setup ipfw add 50 deny log tcp from really.bad.isp.net to any via $1 --- CUT HERE ------- Here's the weird thing. If I enable the If I enable the below lines, I get LOG messages that are caused by something sendmail packets from port 125-127 on my box. Why are they matching? # Deny chargen,tftp,sunrpc #ipfw add 12 deny log all from any to any 19,69,111 via $1 #ipfw add 13 deny log all from any 19,69,111 to any via $1 Next, there is a bug in the above. I'm enabling DNS/tcp, but not DNS/udp, so things don't work. However, I can get DNS to work if I add the NTP stuff. The reason I noticed is that I'm using a hostname for a trusted host which can't be resolved, so I can get an error. However, if I stick the line: ipfw add pass all from any to any 123 via $1 ipfw add 20 pass all from trust.laptop.com to any via $1 above the line which has the hosts, it will be resolved with no problem *EVEN* THOUGH I haven't enabled DNS/udp. And, if I add the lines: ipfw add pass tcp from any to any 123 via $1 ipfw add pass udp from any to any 123 via $1 ipfw add pass icmp from any to any 123 via $1 I still can't do DNS resolution. Weird, huh? I suspect a pretty significant bug somewhere, and it appears to be related to UDP packets. That being said, I don't trust implementation, while the old implementation was *solid* for me. Because I didn't setup a default route to the internet until *AFTER* I put my IPFW entries in place and the box I connected to is a portmaster (so the chance of getting bogus data initiated from it is effectively *zero*), the previous implementation was almost 100% safe. I'll go look at the code, but shipping this in -stable seems to be a big mistake, because both the code and documentation is broken. :( Nate