Date: Mon, 26 Nov 2001 11:54:01 -0800 From: "Crist J. Clark" <cristjc@earthlink.net> To: Darren Henderson <darren@nighttide.net> Cc: ipfw@FreeBSD.ORG Subject: Re: oddities or misunderstandings? Message-ID: <20011126115401.D232@gohan.cjclark.org> In-Reply-To: <Pine.BSF.4.40.0111261007400.53152-100000@localhost>; from darren@nighttide.net on Mon, Nov 26, 2001 at 10:55:33AM -0500 References: <Pine.BSF.4.40.0111261007400.53152-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 26, 2001 at 10:55:33AM -0500, Darren Henderson wrote: > > 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. Sounds like it. > 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. Hrm. > Also, they have > occured when the only systm on our lan that was powered up was the > firewall itself. Hrm^2. > 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. How have you checked this? > 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? Was the first rule that did catch them also after you check-state? > Fragments perhaps? No, unless you've really set your firewall up in a strange way, reassembleable datagrams should not be getting through. > 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. How are you doing the scan? Are there networks which you do not control between the scanner and the firewall? It has actually come to the point where some ISPs filter some of the most common trojan ports. -- Crist J. Clark cjclark@alum.mit.edu 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?20011126115401.D232>