For the most part, that is correct and really put the brakes on a default class. The only problem is with the new port surfing P2P apps. If it can't get out through the default defined class, it may think it cannot get out on that port at all and move to another port used by a higher priority app (e.g. 80, 21, etc).
I suppose the way I've done it forces a lot of unnecessary work. Todd David Blood wrote: > > 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 -- Todd MacDougall Technical Project Lead - IKON Image Systems Solutions IKON The Way Business Gets Communicated 10 King Street East Suite 900 Toronto, Ontario M5C 1C3 Phone: 416-363-8945 Ext 209 Fax: 416-363-2195 Email: [EMAIL PROTECTED] Website: http://www.ikon-iss.com ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ------------------------------------------------------------------------ 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
