Just an FYI to the folks here. On Monday, Nov 20th we observed a ton of attempts by several hundred nodes outside of our Network to access port 6346. This of course was stopped by our Firewall, but if other ISPs/Networks saw this traffic they may attempt to contact the xolox makers, or worse block that port. In looking at the syslogs they read as follows:
Nov 20 10:57:54 pix Nov 20 2001 11:56:55: %PIX-3-106010: Deny inbound tcp src outside:xxx.xxx.219.29/45664 dst inside:xxx.xxx.xxx.xxx/6346
Nov 20 10:57:54 pix Nov 20 2001 11:56:55: %PIX-3-106010: Deny inbound tcp src outside:xx.xxx.95.182/31198 dst inside:xxx.xxx.xxx.xxx/6346

(ips hidden to protect the innocent)
Now at first I saw this as an attack or flaw with perhaps the Hostslist (maybe?) but after running the program and watching the firewall, the pattern which the hosts use were much different. Example, the outside nodes were using port 2486 (and other low numbered ones) to port 6346 on my box, but all seemed to use lower ports then the ones seen on Monday (versus 45000). So there might be someone out there spoofing this traffic in an attempt to get that port ACL'd by providers? Don't know but thought it was worth mentioning. Perhaps some exploit??? I can send the syslogs if interested.


Take Care
Joe

This is just the way gnutella works I think. Once a node make a connection it may be in touch with thousands of other peers. These peers will regularly try and contact the host to download files or form new gnutella connections. If your firewall's blocking this they'll never get through.

Most gnutella clients can be set to indicate they're behind a firewall which will prevent much of the inbound traffic, but the user must set it up correctly.

Thanks for the reply.
<Once a node make a connection it may be in touch with thousands of other peers. These peers will regularly try and contact the host to download files or form new gnutella connections. If your firewall's blocking this they'll never get through. >

That could in theory cause a DOS unknowningly. Example, thousands of users start trying to contact a node behind a firewall that identified its IP as a sharer.
After that node shuts off and say later that day the hosts/peers decide to connect to that node and get /dev/null'd by the firewall but they keep retrying until they get a deny or some other form of contact, or perhaps give up after say 4 attempts. While this is fine for less than 100 users, a thousand plus would saturate a T1 easily (luckly we have a DS3). Even though those are small packets of say 1k, when you multiply them by 1300 users = 1.3meg of needless traffic, times the retrys ect. On Monday we calculated (at peek) 150K/sec(about 120 unique IPs some continually attempting) of attempts to contact a broadcast IP on our Net (still don't understand that, lol 255 off of a /24). Anyhow if you were to ask an ISP about that type of traffic it would clearly look like a DOS attempt. But still not sure what was behind the attempts, got over 8meg of syslogs with these attempts. We finally routed the traffic to one of our DMZs and set up a PC just to reply with a FIN then RST and they went away, after several mins. We would have setup a xolox client there, but didn't know what protocol was behind port 6346 till just today.

Take Care
-Joe

You could run into this problem with any type of server really. Even an ordinary web or FTP server serving something popular might have who knows how many people trying to make contact - they're not always aware that the server may be behind a firewall or no longer available for whatever reason (imagine, for example, what would happen a popular domain like microsoft.com suddenly mis-configured to resolve to your firewall's address).

The only difference with a P2P app like gnutella is the peer can make itself known very quickly and create a large sudden demand. Still it depends on which gnutella peer they're using. Some have better firewall support than others, and how well the user understands what they're doing makes a difference too.

The gnutella protocol can work using outgoing connections only and be firewall friendly, but if someone sharing very popular files mis-configured their peer to report your broadcast address as their external firewall address you may see this kind of traffic. Normally this kind of setting would be intended for use with port forwarding on the firewall itself, but perhaps your user didn't understand what it was for.