All known P2P and IM protocols/clients?

November 22, 2005 3:04 PM

I need to begin to secure a network against IP "theft" liability and security breaches. Please help me compile a list of every known IM and P2P/filesharing protocol and/or client.

However, I don't need to list every single IRC client, simply naming the protocol of IRC is sufficient.

Yeah, it's a terrible task. But it needs to be done. Thanks in advance.

posted by loquacious to computers & internet (22 comments total)

To be honest, you probably don't want to attack this from an exclusionary angle. You probably want to tackle this from an inclusionary angle. The list of "known" varies daily and there are just too many ways to get around it.

Block everything and then allow just the protocols you need.
posted by johannes at 3:08 PM on November 22, 2005

do I get M/N of your salary too if I give you M names and you make N lira? I also second what he said, and wonder if you might want to hire a consultant experienced in security - since that's the most basic of network lockdown paradigms.
posted by kcm at 3:09 PM on November 22, 2005

you can access infringing software on most any port and using almost any protocol. If you just need to mostly cover your companies ass, do as everyone else is saying and lock down everything except the ports necessary for employees to get their jobs done, and then monitor the rest.

Even if you need that list for a different reason (ie, just to show your boss or something, rather than to use as a security guideline) it's gonna be real long and necessarily incomplete.

do I get M/N of your salary too if I give you M names and you make N lira?

plenty of people use askme to get advice for their work, particularly if they've been asked to do something outside their normal job description. If you don't want to help, don't. there you go.
posted by fishfucker at 3:16 PM on November 22, 2005

I don't make any Lira. Sorry, this is AskMe. I trade answers for answers.

I'm not looking for details on how to lock the network down, I'm just looking to discover as many types of P2P and IM programs/clients as I can to help discover and document a few things.

Refined secondary question for optional use: What are the most popular P2P/IM programs at the moment? What's next? What's now dead, but once was popular?

On preview: Fishfucker: Yeah, I agree. I know the list won't be comprehensive. What I would like to have happen in this thread, in an ideal world and all, is for people to just list whatever they've heard of and/or used. I can remember lots and lots of clients/protocols off the top of my head, but I know I'm missing plenty and forgetting lots of them, too.
posted by loquacious at 3:23 PM on November 22, 2005

Oh, if it helps any: Keep in mind this question has a double-edged utilitarian purpose. Sure, it may be used to lock down a local network. But it'll also be available for people to use as a list for sharing participants elsewhere. Information is often double-edged, y'know?
posted by loquacious at 3:26 PM on November 22, 2005

From one hivemind to 'nother, perhaps?

List of well-known ports.
posted by AwkwardPause at 3:45 PM on November 22, 2005

I'm not looking for details on how to lock the network down

no, that's exactly what you are looking to do.

what johannes said. security is about policy not technology.
posted by dorian at 3:59 PM on November 22, 2005

zeropaid is the site that keeps up with this stuff
posted by pyramid termite at 4:02 PM on November 22, 2005

Well, i think the reason people are confused is that you don't really lock down a network by figuring out what clients people are using -- you lock it down by blocking ports/hosts; so a network administrator who isn't working on a desktop level isn't going to have any real use for a list of clients. It's almost like saying "what brand of TVs are going to be watching this signal?" I mean, essentially we are going to start making a list of every client that can transfer information, because any protocol/client that transfers information can conceivably be used to transfer infringing information

that said, here's some p2p and IM clients i can think of off the top of my head.

p2p (some of these are basically identical, ie use the same network/protocol but I'm just listing clients i've heard of/remember/etc here.):

bittorrent (any listen port, def. 6881-6999, depends on who you're connecting to)
carracho (is this still around?)
hotline (ditto)
waste
gnutella
limewire
kazaa
edonkey
soulseek
bearshare


IM:
trillian
yahoo
msn
aim
irc
posted by fishfucker at 4:03 PM on November 22, 2005

Securing against IP theft? Removable media (ie sneakernet) and webmail (or any site that allows browser upload of files) are the most likely vectors.

I am in love with bittorrent. It is the way the truth and the light for big files.
posted by i_am_joe's_spleen at 4:16 PM on November 22, 2005

personally i dont see any reason to block bittorrent. there are just as many legitimate reason to keep it around than there are to block it.

if your that worried about people abusing the network, why dont you just restrict access to the internet to those nodes that require it?
posted by a. at 4:37 PM on November 22, 2005

I'm just looking to discover as many types of P2P and IM programs/clients as I can to help discover and document a few things.

What things? What do you hope to learn from listing this stuff? The answer to your first question, as has been said, is default-deny firewall rules with exceptions for the things that are permissable. If you're still entertaining hopes of a comprehensive list of blocks with default approval of traffic, prepare for a lot of work that will be largely ineffective to determined users and even less so against hackers.
posted by moift at 5:11 PM on November 22, 2005

The list in the Wikipedia entry for Peer-to-peer looks pretty comprehensive to me.
posted by IshmaelGraves at 5:15 PM on November 22, 2005

fishfucker: trillian's not an IM protocol or service, it's just a client.

A longer, but still not comprehensive, list of IM services would read:

aim
icq
irc
jabber (includes google talk)
msn
skype
yahoo

and these lesser known services:

bitwise
gadu gadu
qq

Also, take a look at wiki's list of instant messaging protocols and the associated pages. (instant messaging, list of instant messaging clients, etc, all linked from previous link.)

Don't forget that if a user can ssh from your network, that user can tunnel *anything*. There are plenty of methods of proxying ssh over http (which is easy to spot via monitoring) and over https (which is not).
posted by cactus at 5:37 PM on November 22, 2005

no, that's exactly what you are looking to do.

Err, no. That's not what I'm looking to do. "They" are already using ISA and some packet/port inspection/filtering as well as other known methods. As you can imagine it's not working out as well as they'd like it to. "They" are looking at investing in some behavior-based filtering appliances or contract services as well.

What I'm personally being charged with is trying to compile a list of likely packages/apps/clients and helping to determine the installation/configuration specifics that these apps use, in an effort to lock up future approved distributions/images of our rolled out software to prevent further installation of these applications.

So yeah, it's policy, not technology. In this particular environment we (should) have full control of what the userbase can and cannot install both in the forms of written policy and system access.

You're free to surmise or suppose about whether or not they're doing it correctly from this information. It's just my first day on the job, y'know?

I realize it's a kind of touchy subject. It was even a little frustrating trying to pose the question in a way that actually described what I was trying to do and what it was I wanted answered - and it has shown a little in some of my followup comments. Apologies if you've been ruffled, I just haven't been in sociable language-space for a few hours.

Hell, my GF just called me an asshole for being so apparently gung ho about willingly helping lock down the network and installed desktop userbase against this kind of use.

Hey, it's policy, and it's not just about filesharing. It's also about closing vulnerabilities and preventing virus/worm infections on the network and client machines, and so on and so forth - as well as making sure the userbase (students, primarily) are doing what they're supposed to be doing on campus in class and not just faffing off and misusing a decidedly limited amount of bandwidth at this location, and so on.

Plus, I find the problem interesting and challenging. As a user - of P2P apps and otherwise - I'm well aware of the futility of locking down everything. Computer security is really mainly just varying degrees of convincing illusions of security, just as mechanical locks are.

personally i don't see any reason to block bittorrent. there are just as many legitimate reason to keep it around than there are to block it.


As i_am_joe's_spleen said, I too love BitTorrent. When it's working the download speeds are absolutely stupendous and the getting of things is incredibly painless. It's a wonderful tool. Fantastic. I don't relish being in the position of having to be the one to help crack the whip. I'm enjoying the challenge and stimulation in the process, and in an ideal world I'd be helping find better ways to enable such behavior in a more open and efficient manner, but this world is seemingly rarely ideal.

However, there's no valid reason I can think of that would be a valid argument for this particular and very specialized userbase to have access to it. There's a very limited application set. The desktop environment is homogenized. There's no need for linux ISOs, distribution packages, legitimate audio or video or other to be downloaded in the day-to-day on-campus use. People on this campus don't bring in their own machines. We own the machines. Valid atypical usage can be addressed easily on a case by case base as the userbase is relatively small, and such needs can easily be anticipated and prepared for in such a manner that renders BitTorrent moot. (EG, everything that's actually needed is localized, anyway.)
posted by loquacious at 5:54 PM on November 22, 2005

Many modern p2p clients use random ports.
posted by signal at 6:15 PM on November 22, 2005

Depending on your hardware/provider you could always offload this task to those who are paid to do it daily.

A lot of support contracts include black/white list updates to either firewalls or other in line packet inspection utilities that will deal with the variable nature of the industry while all you would have to do it set the specific rules.

The caveat though is that if they inadvertently block access to a specific port/packet and it is being used by an application that you use within the organization you could be held accountable. Most of these types of "solutions" give you the ability for you to remove the offending entries while notifying the provider to include/exclude them in future updates.

It's not perfect, but it's the best solution that I've seen.

One specific provider that I've seen firsthand (and seems to work quite well) is Fortinet.
posted by purephase at 6:39 PM on November 22, 2005

Sorry, I thought you wanted to prevent your users from sending sensitive data offsite. I see now that we're really talking about stopping the kids from breaking your local copyright laws.
posted by i_am_joe's_spleen at 6:48 PM on November 22, 2005

Hah, y'know, I didn't even stop to consider my own question from that angle.

Yeah, copyright infringement liability. And security, and bandwidth concerns. (The latter two reasons are and have been documented problems.)
posted by loquacious at 10:39 PM on November 22, 2005

I'd block every port except the ones you need. Makes sure you also search for web-based IM services and specifically block those websites, for example webmessenger.msn.com, meebo.com, e-messenger.net, www.aim.com, aimexpress.aol.com. Many of my friends in locked-down corporate settings are able to IM through these web-based services because they go through port 80.
posted by exhilaration at 6:22 AM on November 23, 2005

skype, which is p2p based, will use port 80 if necessary.
posted by andrew cooke at 9:32 AM on November 23, 2005

Welcome to Eichmannhood, loquacious.

The question isn't what to block, but what do you want to leave open? And block traffic types, not ports.
posted by blasdelf at 11:28 AM on November 30, 2005