Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Oct 2000 14:29:49 -0600 (MDT)
From:      Nate Williams <nate@yogotech.com>
To:        freebsd-hackers@FreeBSD.org
Subject:   IPFW bug/incoming TCP connections being let in.
Message-ID:  <200010192029.OAA25357@nomad.yogotech.com>

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




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