Date: Fri, 28 Jun 1996 06:42:52 -0500 From: Alex Nash <alex@fa.tdktca.com> To: nate@mt.sri.com Cc: current@freebsd.org Subject: Re: IPFW bugs? (fwd) Message-ID: <31D3C53C.617FA781@fa.tdktca.com> References: <Pine.BSI.3.91.960628054649.20070C-100000@Venus.mcs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31D3C53C.617FA781>