Slashdot Mirror
Blocking Kazaa 2.0?
coder_ asks: "Has anyone had success blocking the latest versions of this annoying P2P application in a network-wide context? Previously, people have been told to block a specific port, etc, yet as expected, Kazaa has found an easy solution to this. Apparently, when a connection via default port is not available, Kazaa makes encrypted http requests through port 80, making it rather difficult to now block. If anyone has had success in doing so, I would love to hear from you."
Just block all connections to the authorisation/logon server. Problem solved?
Free Java games for your phone: Tontie, Sokoban
If you're adminning a corporate environment where the only things that the employees should have access to is email and browsing, you could cap their bandwidth. If you're at a school, you might want to try blocking access to the login websites (there's a username/pass system in KaZaA, right?), and forget the bandwidth cap entirely, since students may want to download monster .iso files or something.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Just upgrade you packeteer packetshaper to version 5.3.0. This image has new code to specifically handle KaZaA 2.0.
That said, there are *plenty* of approaches to the problem of killing KaZaA (and KaZaA Lite), but they rather depend on the network infrastructure. You certainly need to filter the standard ports used by the program, and forcing all port 80 traffic through a filtering proxy server nay be of use. Also, P2P in general seems to need a fair amount of UDP traffic - depending on your setup it might be possible to restrict that to just those ports you require.
UNIX? They're not even circumcised! Savages!
There's not much reason for most people to have any other net access than Web via proxy.
If you've got every box in the company NATd then you are being hoisted by your own petard really.
Giving Lusers software installation rights on terminals may save you some annoying "but I need MSN" bullshit but when they cram Bonzi Buddy and whatever other crap they can find in there you are risking your network and pushing your support costs up.
I'd rather be seen as some sort of network nazi than have to try and use ssh into a remote site at 1 second per character. I found who was running Napster and since that day I'm the annoying guy that curtails people's "rights" and "freedoms".
If you want a compromise let one machine be a p2p client. You can get Gnutella clients with a web front end so anyone on the LAN can submit queries on the same box and then throttle that box's bandwith during working hours & let it roam free when the bandwith is underutilized.
If people kick up a fuss, sack them.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Three suggestions:
NOTE: I am not a SysAdmin, but these options are from a layman's POV.
clue not required this end
web services are being built on HTTP *because* of proxies.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I just set up a NAT box for a room full of students with their own laptops. I cant control the software on them, but I can control the network. I let through webproxy and ssh ports, which is all they can really ask for in order to do their work.
But the traffic is large and constant. Are they streaming radio, Kazaa'ing? I dont know. But they do want IMAP access to mailservers - doing SSH to a unix box and running 'pine' isn't enough for them - they want clicky clicky. So here's the deal. If that constant traffic goes, and it just looks like you are browsing, I'll enable IMAP access. Streaming traffic disappears.
All I need do is keep an eye on the packet counts. And save a stick for later - they're bound to want to use our printers at thesis-delivery time...
If your in a corporate environment, get management to lay down an internet usage policy. Fire people who break it. They did that at one place I was working and the network traffic dropped by 75% in about 2 days. Fired 6 people, for playing online games and using P2P nets. With management on your side, fear is a strong weapon.
"I kill you! You no good 56'ing!"
write a decent AUP, periodically scan for mp3s and *bitchslap* anyone who breaks them.
Fear, uncertainty and doubt will cut it's usage.
One person or team has to take responsibility of software installations, otherwise you are wide open to virus, trojans and to have not copyrighted software installed without your knowledge.
IANAL but write like a drunk one.
A lot of posters are suggesting allowing Kazaa on the author's network, but ratelimiting it. This question is really to you. Have you received complaints from the DMCA 'police' yet? If so, how have you responded--if at all--to the complaint?
:(
/pointer
Typically, I've heard of ISPs sending notices to customers asking them to remove the offending material. If the customer continues to download/share copyrighted material most ISPs will terminate the customers account. If the bandwidth isn't an issue and the customers business is valuable, it would make more sense to block Kazaa (for that customer; if you can't get them to stop sharing copyrighted content).
I did some googling in mid-November of last year and came across some interesting usenet posts relating to the topic. One poster went through all the normal ports that Kazaa used and blocked each one. Then s/he noticed that it used port 80. Later I ran into some docs where someone was using iptables (there was a post on one of the snort mailing lists about this as well) to block Kazaa traffic using '-m' and the 'X-Kazaa' header that it uses. I haven't had time to play with this though.
Good luck and please let us know what you find.
[%- PROCESS life -%]
There's (sadly) not an easy way to do this with most OSS tools or a way to do this on (most) routers.
The hard way: you could do it with a firewall, policy based routing or a L4 switch, and a transparent web proxy, but setup would be a bitch and if you are an ISP, you're going to have a lot of other headaches with a web proxy other than kazaa 2.
The easiest way to successfully bandwidth-limit or block kazaa 2 clients as far as I have seen is by using one of the commercial traffic shaping hardware or software solutions that have the capability of looking at stuff higher than L4. packeteer, et/bwmgr for linux or freebsd, etc. are software tools that do this, and there is hardware such as L7 switches that can accomplish similar feats also.
I haven't looked in a while at the new/upcoming Linux and BSD OS's ip matching rules. It's possible that there is now enough matchers to successfully block or bandwidth kazaa 2 on them, so it may still be worth investigating in lieu of paying big bucks for shaper hardware/software.
~GoRK
Just use a transparent HTTP proxy. Only normal, unencrypted connections on port 80 will be handled. Others just stop dead.
:-)
Of course, this is yet another stopgap solution, just like blocking the original port. When Kazaa 3 or whatever moves to 443, you're going to be pretty much SOL. That's just the way the Internet works. Information tends to move around.
That's kind of too bad -- I'd love nothing more than to see Kazaa, the last of the major closed P2P protocols, go belly-up. I'm definitely rooting for the RIAA/MPAA on this one. Once it dies, people will be using open protocols.
My attitude is pretty much that you're better off throttling the bajeezus out of their traffic -- they exceed a quota, you clamp down on their rate. Trying to *block* something simply makes people try more solutions until they get around it, whereas data trickling in or out will usually keep them happy enough not to cause too many problems. The human side of things kind of has to be considered here.
I'd also like to say that I really loathe transparent proxies (nothing wrong with opaque proxies -- I run one myself -- but *forcing* the user to do something just causes problems). I also hate people that firewall *anything* outgoing, and most things incoming. Causes lots of pain to the user, and not a lot of long term benefit. Eventually, everything except 80 outbound and 443 outbound are going to be firewalled. Then everything will end up using SOAP or tunneling over 443 to communicate just to get by. As a result, in a few years the Internet will be slower and less reliable, and security and ability to "control" what users do will be less there.
My interests and work tend to lie in security, and I *still* think that most security-oriented admins have their heads up their asses. What's needed is a *good* fix, not a slapdash thing like firewalling off a port or two. Kazaa uses too much bandwidth? Provide an alternative that costs you less (a la the school that wanted to reduce P2P bandwidth -- they made a P2P filesharing app that only talked to other machines on the school network). Trying to perfectly control human behavior hasn't been practical since the dawn of time, and the introduction of the computer isn't going to make it suddenly feasible.
May we never see th
blocking kazaa or the file trading program of the day doesn't equal removing the copyrighted media, does it?
Need a Catering Connection
Yay man, hve you ever heard about newsgroups archives? Or did you try to search a bit before asking /.?
Solution was invented while ago. Just block/trafshape any packets with X-Kazaa string. Like that:
iptables -t mangle -I FORWARD 1 -i eth0 -m recent --update --seconds 60 --rdest --name kazaa -j kazza-out
iptables -t mangle -I FORWARD 2 -i eth1 -m recent --update --seconds 60 --rsource --name kazaa
iptables -t mangle -I FORWARD 3 -i eth1 -m string --string "X-Kazaa" -m recent --name kazaa --set --rsource
iptables -t mangle -I FORWARD 4 -o eth1 -m string --string "X-Kazaa" -m recent --name kazaa --set --rdest -j kazza-out
(You may want to change "Kazaa" into mixed-case version. But you KNOW that. You have analized Kazaa packets, you know how kazaa's headers look like. You are netadmin, don't you?)
:wq