From owner-freebsd-hackers Thu Oct 19 13:29:55 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4CF7937B4D7 for ; Thu, 19 Oct 2000 13:29:51 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA25843 for ; Thu, 19 Oct 2000 14:29:49 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id OAA25357; Thu, 19 Oct 2000 14:29:49 -0600 (MDT) (envelope-from nate) Date: Thu, 19 Oct 2000 14:29:49 -0600 (MDT) Message-Id: <200010192029.OAA25357@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-hackers@FreeBSD.org Subject: IPFW bug/incoming TCP connections being let in. X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had blocked incoming TCP connections coming into my network using IPFW, and I noticed that my brother was able to establish a Napster connection, even though I had blocked it earlier. I thought, no worries, I'll just block it at the port level. I read a couple of articles, and noted that connections from 8888 to the server should be blocked. Easy enough, I'll just block my clients from establishing connections to port 8888. Unfortunately, that doesn't work. Looking at tcpdump output, the 'server' appears to initiates a TCP connection from 8888 -> some random port. My firewall rules do *NOT* allow incoming TCP connections to be made to internal machines, since they only allow 'setup' packets to go out. So, how can Napster work? What happened to the 3-way handshake? I could see an issue if the OS's were hacked to get around this and not require a 3-way handshake, but the client in this case in a Win98 box. I'm *really* confused, and more than a little concerned, since it appears that somehow Napster is getting around the 3-way handshake. Does Napster create 'raw' sockets that emulate TCP traffic? In an attempt to attempt to debug what was going on, I stuck the following rules in place; 00016 allow log tcp from ${client} to any out xmit ep0 setup 00017 allow log tcp from any to ${client} in recv ep0 setup 00018 allow log tcp from ${client} to any out xmit ep0 established 00019 allow log tcp from any to ${client} in recv ep0 established 00020 allow log tcp from ${client} to any out xmit ep0 00021 allow log tcp from any to ${client} in recv ep0 Then, I started up Napster and logged what showed up. It was suprising (to me at least). One would think that rules 16 or 17 *must* be hit first, because the connection has to be initially established. However, it doesn't work that way. ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER:8888 out via ep0 ipfw: 19 Accept TCP NAPSTER:8888 CLIENT-IP:1897 in via ep0 ipfw: 19 Accept TCP NAPSTER:8888 CLIENT-IP:1897 in via ep0 ipfw: 19 Accept TCP NAPSTER:8888 CLIENT-IP:1897 in via ep0 ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER:8888 out via ep0 ipfw: 19 Accept TCP NAPSTER:8888 CLIENT-IP:1897 in via ep0 ipfw: 19 Accept TCP NAPSTER:8888 CLIENT-IP:1897 in via ep0 ipfw: 19 Accept TCP NAPSTER:8888 CLIENT-IP:1897 in via ep0 ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER:8888 out via ep0 ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER:8888 out via ep0 ipfw: 19 Accept TCP NAPSTER:8888 CLIENT-IP:1897 in via ep0 .... No 'setup' packets are sent at all. Confused and concerned.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message