Blocking Kazaa Connections

Greetz all, been a while...

I've been looking around for different ways to keep users on a network from using Kazaa. Most of the users are knowledgable enough that if I manipulate the stations themselves, they'd change it back or work around it. I'm looking for the silver bullet, so to speak. I want to block it at the gateway (OpenBSD box).

Although I've seen quite a few threads here and there on the subject, no one seems to have come up with a difinative answer on the matter, and I was wondering if any of you have figured this out. Pray tell! :brickwall

Thanx a mill!

Rev

Yes,

Kazaa places peer info in a registry key. This means that anything you try with a firewall will ultimately fail in blocking the traffic. The *only* way that I have been able to block this traffic has been with Websensehttp://www.websense.com. The problem here is that Websense costs a few bucks and requires at least two beefy servers.

Other than that, restricting installation of software on the workstation would be your last resort.

Kazaa also sends out it's initial SYN on port 1214. Upon failure it switches down 80 I believe which you can't block. However if you have your firewall alert you on port 1214 connections then you can determine which computer and then deal appropriately with the keyboard to seat interface, (the (L)user)...... ;) It works for me..... only had one attempt...... then the word went out..... "Tiger Shark gets real pissy if you......." <snikker>

peer nfo as in IP addresses, right? When the software is installed does it place random addys, or is it something that the software remembers as it goes along and makes the connections? What I'm getting at is this... I have a weekend where I'll be cleaning out all the stations. If I remove all the instances of Kazaa, and their registry keys, is there a small list of servers it will try and connect to initially after it's install? If that can be stopped, then surely it won't be able to connect and the registry list can't grow, right? (/me hopes?) :)

Yes, we too employ the "deskside visit". The word does spread and we do see much less attempts, however, I deal with 10k users so there is always some clown who thinks he can beat the system - how sadly mistaken they are ;)

Anyway, the predefined peers in the registry key, to date, have not been posted here on AO. I looked at the key briefly and it wasn't as simple as a list in a REG_SZ key. The Kazaa key is a binary entry, which after looking at it, is nothing more than crypto babble (on the surface ofcourse). So the answer is, to date, no one here knows exactly what peers are listed statically or if there is some type of calculation that is performed to come up with a peer.

Again, you'll need a solution at your gateway which is able to block specific protocols, you'll need to set triggers in whatever you use to monitor firewall logs (or IDS logs) or you have to prevent users from installing software on the workstations (via group policy or local security policy). That about sums it up.
:)

The option which springs to mind, aside from using things like "Layer 7 packet classifier"

http://l7-filter.sourceforge.net/

Or commercial alternatives, would be:

- Set up a transparent proxy
- Discover what URL patterns Kazaa uses
- Add rules to the proxy configuration to block requests for URL patterns known to be used by Kazaa
- Block all outgoing connections not going through the transparent proxy

Slarty

Argh! And I thought I was going to be able to relax today... Oh well... Time to get at it. I'll play with it and let you know what I come up with. Thanx for the ideas.

Rev

Jazz: If you come up with a workable, "generic" fix for Kazaa I would be interested in seeing your solution..... I don't have a problem with it but I would like to stop it period rather than have to wander down to someone's desk and hurt my hand on the side of their head..... ;)

Muhwahahahaa! Isn't the act of showing up with a perma-scawl on your face part of the fun of being a network nazi??!! Well, that's what we've been labled as anyway...

We built rules based on Kazaa traffic patterns but it seems that each new release of Kazaa comes with distinct changes in how it interoperates with other peers. We got tired of chasing end users around and coming up with reliable rulesets so we installed Websense and have had no issues to date even with the new releases of Kazaa.

Quote:

---

Originally posted here by thehorse13
Muhwahahahaa! Isn't the act of showing up with a perma-scawl on your face part of the fun of being a network nazi??!! Well, that's what we've been labled as anyway...

---

Look Hoss..... I'm knocking on a bit now...... The perma-scowl is perma through so many years of it being there and I'm getting arthritis from too many nights out crawling through cold, wet mud to make a living...... So..... Anything I can do to preserve this stunning body of mine I will....... ;)

Quote:

---

We built rules based on Kazaa traffic patterns but it seems that each new release of Kazaa comes with distinct changes in how it interoperates with other peers. We got tired of chasing end users around and coming up with reliable rulesets so we installed Websense and have had no issues to date even with the new releases of Kazaa.

---

Yeah.... and the more the RIAA/MPAA screw with the system the harder this is going to be to detect let alone stop..... They are really shooting themselves in the foot by making it consistently harder for us nice, law-abiding sysadmins from helping them to minimize the traffic......

Bad newx, Tiger...

There just aint no way to do it without setting up a major proxy service, and my poor 300mhz gateway just don't got the juice to manhandle it (without causing a serious bottleneck problem)... :rolleyes:

At any rate, If you're interested in knowing, you CAN use a proxy service that will scan the contents of each passing packet, and drop the kazaa junk... But like I said, it's weighs heavy on the heart... (and it's a real arse to set up, too... :killcompu )

From where I'm sitting, it's just not worth the trouble... I'll just start kicking butt... :3pow:

Thankx for the helpz

Rev

We take about three different tacks on this. KaZaa, Morpheus and other P2P systems must execute, so we can grab a signature from the executable and add it to our Key server (license keys) and award that signature a grand total of zero, zip, nadda licenses. Renaming the executable doesn't defeat this. Of course, you have to have all the signatures for all the different versions.

We also add the executable name (and/or the installer package name) to the "do not run" list in AD. That has limited effectiveness.

Otherwise, we monitor bandwidth at the router. The P2Ps have a "signature" that we can identify quickly. Kinda like the spikes for SETI@Home. P2P's start taking a percentage of the available pipe, and hold it at that level. Sniff the packets and find the offender. Nail the turkey to the wall and watch 'im or 'er squirm.

Oh, yeah, make sure you have a copy of the corporate AUP (acceptable use policy) that indicates those activities which result in termination. :-)

http://www.lowth.com/p2pwall/

This may be overly simplistic, but how about a little app that detects when Kazaa starts up, then immediately shuts down the system, or beeps incessantly, or just blacks out the screen until a combination of keys is pressed....

On the cheap you can get the pstool kit from systernals

bastard.bat
---------------------------
echo. >stations.txt
echo. >running.txt
echo. >results.txt
net view >>stations.txt
for /F "tokens=1" %%X in (stations.txt) do pslist -t %%X >>running.txt
find /I /C "kazaa" running.txt >>results.txt
notepad results.txt
---------------------------


if you get a number in results.txt open running.txt and do a find for kazaa to see who it is

or you could use fscan (foundstone) instead of pslist if its not an nt network

fscan -bp 80,1214 10.0.0.1-10.0.1.200 >>running.txt

what i like to is open a terminal using psexec \\station -s cmd and rename all the dlls in the kazaa folder D one one, net send 127.0.0.1 file sharing is against company policy, then pskill \\station kazaa although id like to say ive been lucky because ive only come accross one instance of bear share, but i get a charge out of doing this with IMs which i get allot of

Tedob... I thought about implementing something like that where I have a doze box set up on a spare port just for this sort of thing, but I'd rather not ($$$)... Besides... I prefer the idea of traffic control rather than remote application control (I'm against any type of wide-open, backdoor service like that - "justified" or not... It's simply bad practice from a security standpoint...

Besides the potential security mess... It doesn't take a lot of brain to figure out ways around it. I'd rather have the WinIdiots come to me asking my why they can't get any traffic through... :D If I lock down their system after they installed/ran an app under a "nazi" environment, they'll know they've messed up and it's the Clinton dance all over again... I say, "Build the filter... They will come..." :lildevil:


Seabass...

Yer my new hero... That's the kind of thing that keeps me coming back for more... :) I can't believe I never came across the link... Now if I can just figure out how to get it setup on OpenBSD, I'll be good to go...

Thanx, all. Been real...

Rev

agreed this is no where near as good as what your talking about but i would like to point out that if your running an nt network your already wide open for these kind of tools. they use WMI and are not backdoors but run from your computer. there's nothing needed on the workstation side but nt. and as far as finding ways around it...they dont even know whats happening... i want them to know they're being watched

Rev: There's another way to do it using iptables string matching. I've just started messing with it. Similar stuff (above layer 3) has been discussed ealier in this thread.

Seabass

hmmm....

I agree with you on the point that any NT environment (doze environment) is wide open... My point is that WMI is just MS' proprietary name for a backdoor client (NT, XP, etc... are backdoors in and of themselves, but I hope we can simply agree to disagree here if nothing else). I'm too *NIX to care, anyway ... :)

I just don't want to have to use MS as a temporary solution... It's too expensive and it's against my religion...

I'm going to play with p2pwall and see what I can come up with... I'll let you all know how it turns out.

Thanx again for the inputs.

Cheers,

Rev

im sorry if i sounded disagreeable wasn't meant that way. i just didn't want you to think i was suggesting trojaning your workstations :] mr bill has already done a fine job of that!

no problems, tedob... Yer wheel in my group. I just don't like the idea of remote application control at that kind of scale... It's just too "grey area" for my taste...

Another reason I don't want to do it is because I'm proposing a program that will switch the stations over to some flavor of Linux (maybe I can even get a few FreeBSD boxes installed to prove to them that once the GUI and a few apps are setup, there's almost no difference to the user). So long as there's no glitches, I might actually get a haircut and have a REAL job! :) I'd just look kind of dumb telling them to spend money on something they're going to chunk anyway, especially if I can figure out how to do it with just a ./config,make install.

peace,

Rev