From owner-freebsd-current Thu Jun 27 22:37:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA08289 for current-outgoing; Thu, 27 Jun 1996 22:37:16 -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 WAA08282; Thu, 27 Jun 1996 22:37:09 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id XAA13666; Thu, 27 Jun 1996 23:37:05 -0600 (MDT) Date: Thu, 27 Jun 1996 23:37:05 -0600 (MDT) Message-Id: <199606280537.XAA13666@rocky.mt.sri.com> From: Nate Williams To: Poul-Henning Kamp Cc: Nate Williams , current@freebsd.org Subject: Re: IPFW bugs? In-Reply-To: <1236.835939525@critter.tfs.com> References: <199606280455.WAA13473@rocky.mt.sri.com> <1236.835939525@critter.tfs.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > ># 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 > > >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? ^^^^^^^^ sendmail -> sending. > > biff/comsat Biff/comsat is at 512, not at 125/127, and sendmail isn't even running. The line above should have read: If I enable the below lines, I get LOG messages that are caused by something sending packets from port 125-127 on my box. Why are they matching? > DNS: port 123 is NTP, DNS is port 53 (duh! <:-) Yeah, and your point is? See the comments above the lines, it explains that 123 is NTP. The problem is that DNS/udp wasn't enabled, yet one I enabled NTP/all DNS worked, and when I disabled NTP/all DNS quit working. Why is that? > >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. :( > > Hey, lets teach the pilot a bit first, shall we ? The pilot has a pretty good idea what he's doing. I'm also pretty sure that the bug is not limited only to UDP packets. Given the following output. nec# ipfw list FireWall chain entries: 2200 0 00010 deny log all from 127.0.0.1 to any in via ep0 00011 deny log all from 192.168.0.0/16 to any in via ep0 00011 deny log all from 172.16.0.0/12 to any in via ep0 00011 deny log all from 10.0.0.0/8 to any in via ep0 00012 deny log udp from any to any 513,514 via ep0 00013 deny log udp from any 513,514 to any via ep0 00020 allow tcp from any to any 22,25,110 via ep0 00020 allow tcp from any 22,25,110 to any via ep0 00020 allow all from any to any 53 via ep0 00020 allow all from any 53 to any via ep0 00020 allow all from 128.18.0.0/16 to any via ep0 00030 allow tcp from any to any via ep0 established 00040 deny log tcp from any to any via ep0 setup 00060 deny log tcp from 205.216.146.201 to any via ep0 00060 deny log tcp from 205.216.146.202 to any via ep0 00060 deny log tcp from 205.216.146.231 to any via ep0 00070 deny log tcp from 198.80.37.97 to any via ep0 00070 deny log tcp from 198.80.37.107 to any via ep0 00070 deny log tcp from 198.80.37.184 to any via ep0 00070 deny log tcp from 198.80.37.185 to any via ep0 nec# I can telnet/login/ftp/etc.. *from* non-local machines to this box. Why is that? As I see it, it should only unlimited TCP connections to ssh(22),smtp(25),pop3(110) [ rule 20 ], unlimited *any* connections to 53(dns) [ rule 20 ], connections from any machines in SRI-Menlo [ rule 20 ], and established TCP connections (this is for a rule I've commented out for testing ]. However, rule 40 shouldn't allow setup/SYN packets in, so normal TCP connections shouldn't be allowed to connect. Note, this is a TCP bug I'm seeing now, so either I'm completely mis-understanding the documentation re: setup/established and/or we have some bugs in the implementation. Nate