Date: Mon, 26 Nov 2001 10:55:33 -0500 (EST) From: Darren Henderson <darren@nighttide.net> To: ipfw@freebsd.org Subject: oddities or misunderstandings? Message-ID: <Pine.BSF.4.40.0111261007400.53152-100000@localhost>
next in thread | raw e-mail | index | archive | help
I have a couple of issues with which I'm not quite clear as to whats going
on, any enlightenment would be appreciated. This is on a 4.4-STABLE last
cvsup'd and rebuilt on 11/20.
For a while now I've been seeing a dozen or so kernel messages like this:
Connection attempt to TCP 209.222.117.162:1230 from 65.203.157.142:80
They come from a couple of different class c's and may be directed to a
number of my /28's or my internal 10/8 on various ports. My first thought
was that perhpas they were just responses to outstanding browser requests
that had timed out etc. See a bit of that with my name server. However
some of the addresses that it hits are aliases on the external interface
and those addresses wouldn't be generating any requests. Also, they have
occured when the only systm on our lan that was powered up was the
firewall itself.
They don't appear to be coming in through the dynamic rules yet my default
final rule (deny ip from any to any) doesn't catch them.
If I block it with a rule such as:
ipfw add deny log logamount 1000 ip from 65.203.157.0/24 to any
ipfw does in fact stop them, at least from that class c. Since I've seen
it from at least 2 class c's
I thought I would put in a rule like this instead:
ipfw add deny log logamount 1000 tcp from any 80 to any in via dc1
which I place after my check-state rule. This doesn't work. It doesn't
catch anything and kernel messages still show up so the packets are
getting through the firewall.
Why would these be getting through ipfw, the final rule should be
catching them regardless? Fragments perhaps?
On a similar note, playing with nmap, scanning a number of my systems,
things seem fine yet for some reason, when it scans port 12345, the
firewall doesn't seem to catch it. I realize nmap plays some games and
uses various stealth techniques yet scans on that port behave differently
then other scans on the other ports. nmap reports it as being open though
everything I've looked at indicates otherwise, behaved the same way right
after a cvsup and doing a new world and kernel, so I don't suspect
anything nefarious.
Most likely this is all a failing of my understanding of ipfw even though
I've been using it or years. Any thoughts/explanations would be
appreciated.
______________________________________________________________________
Darren Henderson darren@nighttide.net
Help fight junk e-mail, visit http://www.cauce.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.40.0111261007400.53152-100000>