Couldn't you just make you default group throttle way back then give other services high bandwidth? Then you don't have to know every port that a P2p could be on rather just the ports that your other higher priority applications use like ssh or http.
David Blood Matraex, Inc -----Original Message----- From: [EMAIL PROTECTED] [mailto:leaf-user-admin@;lists.sourceforge.net] On Behalf Of Todd MacDougall Sent: Wednesday, October 30, 2002 9:01 AM To: Jon Clausen Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] How to deal with P2P-apps? [was; What's this guy trying?] I'm quite a bit behind on adding my 2 cents. My first thought regarding your ICMP messages was your local P2P apps determining if they can connect (or are still connected) to remote (peer) workstations. Those damn P2P apps can be a real pain. The combination of basic functionality, spyware, advertising and lord knows what else, makes them a real pain for administrators. P2P bandwidth throttling is straight forward to capture majority of users however P2P apps are getting much smarter however, it only takes a one or two users to bypass your throttling mechanisms and consume a large portion of your pipe. Simple application throttling based port works in most cases but the tides are turning an this won't last long in the P2P world. There already exists P2P apps (e.g. iMesh) which port surf until it finds usable ports for data transmission. The only real way to throttle these apps (so I've read) is with more sophisticated inspection of the packets found in commercially supported stand alone units. My suggestion would be to *block* apps which port surf and *throttle* apps that don't - this way, you're not blocking all P2P traffic rather only the P2P traffic you cannot control. I'm sure this tacktic will be circumvented in the near future so you'll have to stay on top of things. After reading all the shaping documentation I could find I eventually went with Bering and HTB. Lots of people use CBQ because it is standard with most Linux distros but I was influenced from what I read. With regard to port usage, you'll find most of the P2P app ports on the web. You'll likely have to do a lot of surfing since P2P apps become available faster than the IANA port list gets updated (http://www.iana.org/assignments/port-numbers). I found that after doing a couple searches on download.com, I had only a fraction of P2P ports being monitored. I had to download a lot of them, start them up on my Windows machine and use netstat to determine the ports being used. Here is a link as a good starting point http://www.practicallynetworked.com/sharing/app_port_list.htm Hope some of that was useful. Todd Jon Clausen wrote: > > I'm not at all sure but I suspect there might be *some* connection > between the hordes of denied icmp-messages discussed before (see quote > below), and the fact that one of the kids on the lan is running > "Morpheus" (a P2P filesharing app). > > Quick ascii reminder: > > Inet---Dachstein---LAN---(host running Morpheus) > | > DMZ > | > Linux server > > On Mon, Oct 14, 2002 at 11:15:11PM -0700, Ray Olszewski wrote: > > At 07:24 AM 10/15/02 +0200, Jon Clausen wrote: > > >O.K. full log entry: > > >Oct 14 14:46:06 skilderhus kernel: Packet log: input DENY eth0 PROTO=1 > > >10.131.224.1:3 62.243.222.62:1 L=56 S=0x00 I=41957 F=0x0000 T=243 (#9) > > > > OK. It's what I guessed above ... an icmp "host unreachable" message. > > There's probably a secret decoder ring for this stuff online somewhere, but > > I use a book. Here's the pieces: > > > > PROTO=1 protocol 1 is icmp > > 10.131.224.1:3 10.131.224.1 is the source IP, of course; > > the "port" is the icmp message type, 3=Destination > > unreachable > > 62.243.222.62:1 62.243.222.62 is the destination IP, as usual; > > the "port" is the icmp message code, 1=host > > unreachable > > > > Without seeing the content of the packet (which does not get logged), we > > have no way to know what host this is about. > > > > >As I said, there are a bunch of this kind of entries, all > > >PROTO=1 <some-ip>:3 62.243.222.62:1 L=56 S=0x00 I varying T varying (# > > >varying) > > > > > >It starts at 11:36:39 continues through the day to 21:11:20 > > Which *could* fit with: > > 11:36 kid opens windows/morpheus, dumdedum all day to > 21:11 kid shuts down, goes to bed > > Now, why morpheus on the lan should result in incoming martian icmp > messages on eth0, I haven't any idea...(?) BUT > > More generally; > > This being a residential network, I have no authority to block P2P apps > outright. So I would like some opinions/advice WRT the following: > > P2P being the potential security hazard it is, would it make sense to > place a P2P "proxy" in the dmz? (And try to beef up security on it) > > Bandwidth. This stuff needs to be throttled. This is something I've been > wanting to get into, but since the documentaion on Morpheus amounts to > "This is the best P2P app... ever!" I've no idea where to begin. > > Does anyone have links to docs on the ports/protocols used for these > types op apps? (Morpheus/Kazaa/Gnutella/whathavewe) > > These are more of conceptual/conversational questions, since I've done > little research of my own yet. I thought it'd be nice to get some > pointers ideas on *what* to research first... > > TIA > > Jon Clausen > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
