From owner-freebsd-current Fri Jun 28 04:40:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA27571 for current-outgoing; Fri, 28 Jun 1996 04:40:10 -0700 (PDT) Received: from shogun.tdktca.com ([206.26.1.21]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA27564 for ; Fri, 28 Jun 1996 04:40:07 -0700 (PDT) Received: from shogun.tdktca.com (daemon@localhost) by shogun.tdktca.com (8.7.2/8.7.2) with ESMTP id GAA05727 for ; Fri, 28 Jun 1996 06:41:24 -0500 (CDT) Received: from orion.fa.tdktca.com ([163.49.131.130]) by shogun.tdktca.com (8.7.2/8.7.2) with SMTP id GAA05720 for ; Fri, 28 Jun 1996 06:41:23 -0500 (CDT) Received: from orion (alex@localhost [127.0.0.1]) by orion.fa.tdktca.com (8.6.12/8.6.9) with SMTP id GAA12776; Fri, 28 Jun 1996 06:42:52 -0500 Message-ID: <31D3C53C.617FA781@fa.tdktca.com> Date: Fri, 28 Jun 1996 06:42:52 -0500 From: Alex Nash Organization: TDK Factory Automation X-Mailer: Mozilla 2.0 (X11; I; Linux 1.2.13 i586) MIME-Version: 1.0 To: nate@mt.sri.com CC: current@freebsd.org Subject: Re: IPFW bugs? (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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. You can't get to the bugs -- that's a good thing, right? :) > # 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 If you look in the man page under fine points, it is documented that you should not use all in combination with a port specification. In retrospect this was a mistake, and I'll fix ipfw to reject such entries. > # Trusted hosts for almost everything > ipfw add 20 pass all from 128.180.0:255.255.0.0 to any via $1 I hope you're running up-to-date ipfw code. There was a bug in the previous code that caused the address:mask to always use a mask of 255.255.255.255. > # 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 There's that 'all' problem again... > 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? ipfw (almost) always prints the rule number in the log output. Look this number up in the 'ipfw -l' listing to find out which rule it's 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. I believe DNS/tcp is for zone transfers only. DNS/udp is all you need for standard lookups. > 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. I'm not sure we have a definite cause and effect. Are you sure you didn't do something inbetween that caused the hostname to get cached, thus making it look like it worked. > 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'm not surprised you can't DNS resolve through the NTP port. > 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. :( I don't make any claims that the documentation is perfect. However, the documentation is *better* than what was going to ship. If there are improvements to be made in the documentation, I'd like to hear about it -- but in this message, I don't see one. Alex