Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Jun 1996 23:37:05 -0600 (MDT)
From:      Nate Williams <nate@mt.sri.com>
To:        Poul-Henning Kamp <phk@freebsd.org>
Cc:        Nate Williams <nate@mt.sri.com>, current@freebsd.org
Subject:   Re: IPFW bugs? 
Message-ID:  <199606280537.XAA13666@rocky.mt.sri.com>
In-Reply-To: <1236.835939525@critter.tfs.com>
References:  <199606280455.WAA13473@rocky.mt.sri.com> <1236.835939525@critter.tfs.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> ># 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606280537.XAA13666>