Re: IPFW bug/incoming TCP connections being let in.
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. *sigh* Thanks to Guy Helmer for being patient with me as I fretted about this. I just found out that Napster leaves a client running in the background, and even though I had added firewall rules to block new connections to the server, the old 'established' connection was still up and running. I didn't realize that was the case, so that everytime I 'restarted' Napster the packets were getting through. In fact, what had happened was that the 'GUI' was being stopped/restarted, but the network portion was running the entire time. Once Guy walked me through and showed me that things were indeed working correct, we rebooted the box and my rules worked fine. Sorry for the false alarm! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Blocking Napster (WAS: IPFW bug/incoming TCP connections being let in.)
Nate Williams wrote: 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. *sigh* Thanks to Guy Helmer for being patient with me as I fretted about this. I just found out that Napster leaves a client running in the background, and even though I had added firewall rules to block new connections to the server, the old 'established' connection was still up and running. This might be helpful to you and others. Since napster uses what ever ports it can find the best way is to block the servers. # Napster $fwcmd add deny tcp from any to 208.178.163.56/29 via tun0 $fwcmd add deny tcp from any to 208.178.175.128/29 via tun0 $fwcmd add deny tcp from any to 208.49.239.240/28 via tun0 $fwcmd add deny tcp from any to 208.49.228.0/24 via tun0 $fwcmd add deny tcp from any to 208.184.216.0/24 via tun0 Jim -- [EMAIL PROTECTED] http://www.FreeBSD.org The Power to Serve [EMAIL PROTECTED] http://www.TheHousleys.net - Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Blocking Napster (WAS: IPFW bug/incoming TCP connections being let in.)
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. *sigh* Thanks to Guy Helmer for being patient with me as I fretted about this. I just found out that Napster leaves a client running in the background, and even though I had added firewall rules to block new connections to the server, the old 'established' connection was still up and running. This might be helpful to you and others. Since napster uses what ever ports it can find the best way is to block the servers. # Napster $fwcmd add deny tcp from any to 208.178.163.56/29 via tun0 $fwcmd add deny tcp from any to 208.178.175.128/29 via tun0 $fwcmd add deny tcp from any to 208.49.239.240/28 via tun0 $fwcmd add deny tcp from any to 208.49.228.0/24 via tun0 $fwcmd add deny tcp from any to 208.184.216.0/24 via tun0 I had these rules in place, but it appears that there are new servers in place. I also had to to add $fwcmd add deny tcp from any to 64.124.41.0/24 via tun0 (I'm guessing it's a class C, I just had hit two addresses in that block, so I blocked the entire class C.) The above is the reason I was trying to do a 'port' block of the Napster servers, because trying to keep up with IP addresses is a real pain in the butt... Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPFW bug/incoming TCP connections being let in.
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 to the
server should be blocked.
Easy enough, I'll just block my clients from establishing connections to
port .
Unfortunately, that doesn't work. Looking at tcpdump output, the
'server' appears to initiates a TCP connection from - 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: out via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
No 'setup' packets are sent at all.
Confused and concerned
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW bug/incoming TCP connections being let in.
On Thu, 19 Oct 2000, Nate Williams wrote: 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 to the server should be blocked. Easy enough, I'll just block my clients from establishing connections to port . Unfortunately, that doesn't work. Looking at tcpdump output, the 'server' appears to initiates a TCP connection from - 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. The remote napster client sends a message through the central Napster server, which relays the message to your Napster client to tell your machine to make a connection to the remote machine. This is so that, as long as one of the two Napster clients are not behind a firewall, the two clients can communicate directly. The client behind the firewall makes the connection to the client that isn't behind a firewall, since most firewalls are configured to allow internal machines to make connections to any outside machine. The regular 3-way handshake is occurring. It's just not initiated by the machine you would expect. You'd have to block outgoing SYNs to any outside host at port (but anyone who knows anything about ports could change their port number and get around your block). Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Dept. of Computer Science --- [EMAIL PROTECTED] http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW bug/incoming TCP connections being let in.
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 to the server should be blocked. Easy enough, I'll just block my clients from establishing connections to port . Unfortunately, that doesn't work. Looking at tcpdump output, the 'server' appears to initiates a TCP connection from - 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. The remote napster client sends a message through the central Napster server, which relays the message to your Napster client to tell your machine to make a connection to the remote machine. This much I undertand. However, I'm not making any downloads, so my client isn't (yet) connecting to another client. I'm trying to block connections to the server. How is the client connecting to the server? I don't see *any* TCP setup packets being sent out by my client, so how is the client communicating with the server via TCP? (I *AM* seeing TCP packets being sent out, but they are being sent as 'established' connections, before a setup packet is being sent.) The regular 3-way handshake is occurring. It's just not initiated by the machine you would expect. The only way my client can work is if it initiates the connection, but I don't see it initiating a connection to port . So, how then is the Napster server at port communicating with my client? You'd have to block outgoing SYNs to any outside host at port (but anyone who knows anything about ports could change their port number and get around your block). That was what I did, but the rule is never being hit. However, there appears to be a connecting from my client to port on the server. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
