how to block kazaa ?

how to block kazaa ?

[inghau]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

hello 

i have some problems in my lan environment. most of my clients using kazaa to dowmload mp3 and mpg files.
these progams eating most of my small bandwidth so can i put some rules to "block" these kazaa and other p2p program ?

right now my linux boxes is just act as very simple NAT router using iptables


thank you very much

[-- Attachment #2: Type: text/html, Size: 1017 bytes --]

Re: how to block kazaa ?

[Joel Newkirk]

On Tuesday 25 February 2003 09:44 pm, inghau@perkom.co.id wrote:
> hello
>
> i have some problems in my lan environment. most of my clients using
> kazaa to dowmload mp3 and mpg files. these progams eating most of my
> small bandwidth so can i put some rules to "block" these kazaa and
> other p2p program ?
>
> right now my linux boxes is just act as very simple NAT router using
> iptables
>
>
> thank you very much

If you want simply to keep them from working, then the answer is to DROP 
traffic in FORWARD chain to/from the ports used for server or peer 
communication.  For Gnutella/Limewire/Morpheus and kin, this means:

iptables -A FORWARD -p tcp --dport 6346:6347 -j DROP
iptables -A FORWARD -p udp --dport 6346:6347 -j DROP

for EDonkey & Overnet:

iptables -A FORWARD -p tcp --dport 4660:4666 -j DROP
iptables -A FORWARD -p udp --dport 4660:4666 -j DROP

for older Kazaa apparently this suffices:

iptables -A FORWARD -p tcp --dport 1214 -j DROP
iptables -A FORWARD -p udp --dport 1214 -j DROP

But newer implementations apparently support port-hopping, so it seems 
that the only confirmed way to stop it with iptables is with the STRING 
match from patch-o-matic, and block anything with the string "kazaa" 
(don't recall case requirements) in it.  Compiling a custom 
kazaa-blocking kernel may be more than you want to do, though.

If you want to be 'polite' then use the REJECT target instead of DROP, at 
least for connections initiated from the LAN.  If you want to be 
thorough, then LOG the traffic, find out who it is, and beat the kazaa 
out of them with a keyboard... :^)

Also, if the primary bottleneck is outbound, you might find that using 
the mangle table in prerouting to set TOS for certain desirable traffic 
and enacting pfifo queuing discipline will help a great deal - IE change 
TOS to a favorable value (0x10 perhaps) for specific traffic like HTTP 
SMTP POP3 IMAP or any VNC or such and then setting TOS to a 'bulk 
traffic' value (0x02 for example) for the remainder, or for the P2P 
traffic if it is identifiable.  The pfifo qdisc will always send the 
0x10 traffic, and send 0x02 only if there is nothing else waiting to be 
sent.

j

Re: how to block kazaa ?

[Nimit Gupta]

hello,
	Just going thru the thread so that i could learn form others
problem. One thing I could not understand is, how to custom compile a
kazaa-blocking kernel?

>
> But newer implementations apparently support port-hopping, so it seems
> that the only confirmed way to stop it with iptables is with the STRING
> match from patch-o-matic, and block anything with the string "kazaa"
> (don't recall case requirements) in it.  Compiling a custom
> kazaa-blocking kernel may be more than you want to do, though.
>

	Thanks a lot.

with regards,
Nimit.

Re: how to block kazaa ?

[Joel Newkirk]

On Wednesday 26 February 2003 12:07 am, Nimit Gupta wrote:
> hello,
> 	Just going thru the thread so that i could learn form others
> problem. One thing I could not understand is, how to custom compile a
> kazaa-blocking kernel?

Sorry, what I was referring to was using Patch-O-Matic to add newer 
features to netfilter, like the string match and Arnt Karlsen's favored 
TARPIT target, and then recompiling the kernel to incorporate the 
patches.  It's not really a 'kazaa-blocking' kernel, just in this case 
one compiled especially because of the desire to block kazaa.

j

> > But newer implementations apparently support port-hopping, so it
> > seems that the only confirmed way to stop it with iptables is with
> > the STRING match from patch-o-matic, and block anything with the
> > string "kazaa" (don't recall case requirements) in it.  Compiling a
> > custom kazaa-blocking kernel may be more than you want to do,
> > though.
>
> 	Thanks a lot.
>
> with regards,
> Nimit.

Re: how to block kazaa ?

[hare ram]

Hi

there is no such tool for specifically for kazaa
but you can add up string module from POM

check netfilter.org... extensions how to
http://www.netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO.htm
l

hare
----- Original Message -----
From: "Nimit Gupta" <nimit@deeproot.co.in>
To: "Joel Newkirk" <netfilter@newkirk.us>
Cc: <inghau@perkom.co.id>; <netfilter@lists.netfilter.org>
Sent: Wednesday, February 26, 2003 10:37 AM
Subject: Re: how to block kazaa ?


>
> hello,
> Just going thru the thread so that i could learn form others
> problem. One thing I could not understand is, how to custom compile a
> kazaa-blocking kernel?
>
> >
> > But newer implementations apparently support port-hopping, so it seems
> > that the only confirmed way to stop it with iptables is with the STRING
> > match from patch-o-matic, and block anything with the string "kazaa"
> > (don't recall case requirements) in it.  Compiling a custom
> > kazaa-blocking kernel may be more than you want to do, though.
> >
>
> Thanks a lot.
>
> with regards,
> Nimit.
>
>
>

Re: how to block kazaa ?

[Scott Lamb]

Joel Newkirk wrote:
> But newer implementations apparently support port-hopping, so it seems 
> that the only confirmed way to stop it with iptables is with the STRING 
> match from patch-o-matic, and block anything with the string "kazaa" 
> (don't recall case requirements) in it.  Compiling a custom 
> kazaa-blocking kernel may be more than you want to do, though.

This strikes me as a pretty bad idea; it'll block more than just kazaa
packets. For one thing, it would block a description of how to implement
the block, unless it were obfuscated to get past itself, which seems
silly to me. And maybe people talking about kazaa also. And even random
binary sequences aren't that unlikely to have problems. The odds of a
given seven random bytes matching are only 1/2^(5*8)=1/2^40. But if you
transfer 1GB/day, multiply that by (2^30)/5. Then you're talking about
odds of 5 in 1024 that you'll have at least one random packet blocked
per day. I predict emails, compressed files, etc. that won't transfer
for no apparently reason because part of it consistently won't transfer.

> Also, if the primary bottleneck is outbound, you might find that using 
> the mangle table in prerouting to set TOS for certain desirable traffic 
> and enacting pfifo queuing discipline will help a great deal - IE change 
> TOS to a favorable value (0x10 perhaps) for specific traffic like HTTP 
> SMTP POP3 IMAP or any VNC or such and then setting TOS to a 'bulk 
> traffic' value (0x02 for example) for the remainder, or for the P2P 
> traffic if it is identifiable.  The pfifo qdisc will always send the 
> 0x10 traffic, and send 0x02 only if there is nothing else waiting to be 
> sent.

I like this much more. It solves the real problem of bandwidth usage
while still allowing them to do it. And I'll guess that the port hopping
only moves on if it doesn't work, not if it has a less favorable TOS
value. So it will stay on the easily-identifiable ports. Or like you
said, you could increase the TOS for packets you're sure aren't P2P
stuff if that doesn't work out.

Scott

Re: how to block kazaa ?

[Arnt Karlsen]

On Wed, 26 Feb 2003 09:44:33 +0700, 
<inghau@perkom.co.id> wrote in message 
<003d01c2dd40$fe922030$210aa8c0@sabirin>:

> hello 
> 
> i have some problems in my lan environment. most of my clients using
> kazaa to dowmload mp3 and mpg files. these progams eating most of my
> small bandwidth so can i put some rules to "block" these kazaa and
> other p2p program ?
> 
> right now my linux boxes is just act as very simple NAT router using
> iptables
> 
> 
> thank you very much
> 

..'iptables -A FORWARD -p tcp -m tcp -i eth1 --dport $kaaza-ports \
-j REJECT', or expand it to 'iptables -A FORWARD -p tcp -m tcp -m \
multiport- d$destination -i eth1 -j REJECT --dports $kaaza-ports'

..ditto for other protocols.  Instead of "REJECT", there is also 
DROP, MIRROR, and my favorite, TARPIT, in Patch-o-matic.


-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: how to block kazaa ?

[Joel Newkirk]

On Wednesday 26 February 2003 12:27 am, you wrote:
> Joel Newkirk wrote:
> > But newer implementations apparently support port-hopping, so it
> > seems that the only confirmed way to stop it with iptables is with
> > the STRING match from patch-o-matic, and block anything with the
> > string "kazaa" (don't recall case requirements) in it.  Compiling a
> > custom kazaa-blocking kernel may be more than you want to do,
> > though.
>
> This strikes me as a pretty bad idea; it'll block more than just kazaa
> packets. For one thing, it would block a description of how to

True, as described it does.  I kept searching old emails for the actual
string that appears in the header of kazaa requests and couldn't find
it.  The message misspelled kazaa, but I finally found it.

iptables -I FORWARD -p tcp -m string --string "KazaaClient" -j REJECT
--reject-with tcp-reset

 "KazaaClient" is a fairly distinct string to search for, but again
 would then catch this email.  You'd have to ACCEPT tcp port 25,80,110
 then drop anything with the string, then handle the remainder of your
 rules to be safest with this approach.  Apparently V1 and V2 Kazaa both
 use this string in every connection attempt.

> implement the block, unless it were obfuscated to get past itself,
> which seems silly to me. And maybe people talking about kazaa also.
> And even random binary sequences aren't that unlikely to have
> problems. The odds of a given seven random bytes matching are only
> 1/2^(5*8)=1/2^40. But if you transfer 1GB/day, multiply that by
> (2^30)/5. Then you're talking about odds of 5 in 1024 that you'll have
> at least one random packet blocked per day. I predict emails,
> compressed files, etc. that won't transfer for no apparently reason
> because part of it consistently won't transfer.
>
> > Also, if the primary bottleneck is outbound, you might find that
> > using the mangle table in prerouting to set TOS for certain
> > desirable traffic and enacting pfifo queuing discipline will help a
> > great deal - IE change TOS to a favorable value (0x10 perhaps) for
> > specific traffic like HTTP SMTP POP3 IMAP or any VNC or such and
> > then setting TOS to a 'bulk traffic' value (0x02 for example) for
> > the remainder, or for the P2P traffic if it is identifiable.  The
> > pfifo qdisc will always send the 0x10 traffic, and send 0x02 only if
> > there is nothing else waiting to be sent.
>
> I like this much more. It solves the real problem of bandwidth usage

I'm using it as we speak, I have a p2p session with edonkey running, and
a few minutes ago 4 players on the UT server (both are actually hosted
on the firewall box itself) and we had some of the best connection
speeds in-game ever, while I had 5k/s up and 20k/s down connections in
P2P.  (the 20k was actually limited by the source, not my system)

> while still allowing them to do it. And I'll guess that the port
> hopping only moves on if it doesn't work, not if it has a less
> favorable TOS value. So it will stay on the easily-identifiable ports.
> Or like you said, you could increase the TOS for packets you're sure
> aren't P2P stuff if that doesn't work out.

Only for outbound traffic though - if all the downlink bandwidth is
 being consumed then at the firewall is far too late to help.  You can
 play around with ingress policing and other approaches to try to slow
 the incoming data, but the most effective solution really seems to be
 the keyboard-upside-the-head approach.  Nevertheless, just lowering p2p
 outbound traffic to 'bulk' rating will actually help apparent downlink
 speeds, since interactive tasks like browsing will be able to send
 requests and control messages and such out without getting buried in
 the p2p flood.

The pfifo qdisc sets up three priorities for traffic.  Basically
priority, normal, bulk.  If you lower something to bulk then anything
unmodified will take precedence, since normal is the default.

> Scott

j

Re: how to block kazaa ?

[lawrence Of Arabia]

Well,

i do know the kazaa client can be run on different ports, by default 1214.

NONETHELESS:

it also runs on port 80 something ... i first started using apache for file 
swapping with friends ...

but ... when i ran kazaa ... and started apache ... i had an error.

"port 80 is already in use"

you may verify this by yourself (open a browser with http://localhost ... or 
localhost:1214 ... youll get a file listing with odd numbers next to it. it 
list every single file youve got from you shared folder. (it also does the 
same thing on port 1214)

i dont really know how kazaa works but we could assume when someone searches 
for a file, it could search through that web server, and if it finds its 
sends the searcher a found file.

but ... i also noticed that the webserver it creates is not accessible  
remotly by an immediate browser request. so thats where the --string 
`KazaaClient` must come in ...

i dont know any technical things, all of this are just presumptions ...

anyway ... just giving my two cents ...


>From: Joel Newkirk <netfilter@newkirk.us> (by way of Joel Newkirk 
><netfilter@newkirk.us>)
>Reply-To: netfilter@newkirk.us
>To: netfilter@lists.netfilter.org
>Subject: Re: how to block kazaa ?
>Date: Wed, 26 Feb 2003 01:07:53 -0500
>
>On Wednesday 26 February 2003 12:27 am, you wrote:
> > Joel Newkirk wrote:
> > > But newer implementations apparently support port-hopping, so it
> > > seems that the only confirmed way to stop it with iptables is with
> > > the STRING match from patch-o-matic, and block anything with the
> > > string "kazaa" (don't recall case requirements) in it.  Compiling a
> > > custom kazaa-blocking kernel may be more than you want to do,
> > > though.
> >
> > This strikes me as a pretty bad idea; it'll block more than just kazaa
> > packets. For one thing, it would block a description of how to
>
>True, as described it does.  I kept searching old emails for the actual
>string that appears in the header of kazaa requests and couldn't find
>it.  The message misspelled kazaa, but I finally found it.
>
>iptables -I FORWARD -p tcp -m string --string "KazaaClient" -j REJECT
>--reject-with tcp-reset
>
>  "KazaaClient" is a fairly distinct string to search for, but again
>  would then catch this email.  You'd have to ACCEPT tcp port 25,80,110
>  then drop anything with the string, then handle the remainder of your
>  rules to be safest with this approach.  Apparently V1 and V2 Kazaa both
>  use this string in every connection attempt.
>
> > implement the block, unless it were obfuscated to get past itself,
> > which seems silly to me. And maybe people talking about kazaa also.
> > And even random binary sequences aren't that unlikely to have
> > problems. The odds of a given seven random bytes matching are only
> > 1/2^(5*8)=1/2^40. But if you transfer 1GB/day, multiply that by
> > (2^30)/5. Then you're talking about odds of 5 in 1024 that you'll have
> > at least one random packet blocked per day. I predict emails,
> > compressed files, etc. that won't transfer for no apparently reason
> > because part of it consistently won't transfer.
> >
> > > Also, if the primary bottleneck is outbound, you might find that
> > > using the mangle table in prerouting to set TOS for certain
> > > desirable traffic and enacting pfifo queuing discipline will help a
> > > great deal - IE change TOS to a favorable value (0x10 perhaps) for
> > > specific traffic like HTTP SMTP POP3 IMAP or any VNC or such and
> > > then setting TOS to a 'bulk traffic' value (0x02 for example) for
> > > the remainder, or for the P2P traffic if it is identifiable.  The
> > > pfifo qdisc will always send the 0x10 traffic, and send 0x02 only if
> > > there is nothing else waiting to be sent.
> >
> > I like this much more. It solves the real problem of bandwidth usage
>
>I'm using it as we speak, I have a p2p session with edonkey running, and
>a few minutes ago 4 players on the UT server (both are actually hosted
>on the firewall box itself) and we had some of the best connection
>speeds in-game ever, while I had 5k/s up and 20k/s down connections in
>P2P.  (the 20k was actually limited by the source, not my system)
>
> > while still allowing them to do it. And I'll guess that the port
> > hopping only moves on if it doesn't work, not if it has a less
> > favorable TOS value. So it will stay on the easily-identifiable ports.
> > Or like you said, you could increase the TOS for packets you're sure
> > aren't P2P stuff if that doesn't work out.
>
>Only for outbound traffic though - if all the downlink bandwidth is
>  being consumed then at the firewall is far too late to help.  You can
>  play around with ingress policing and other approaches to try to slow
>  the incoming data, but the most effective solution really seems to be
>  the keyboard-upside-the-head approach.  Nevertheless, just lowering p2p
>  outbound traffic to 'bulk' rating will actually help apparent downlink
>  speeds, since interactive tasks like browsing will be able to send
>  requests and control messages and such out without getting buried in
>  the p2p flood.
>
>The pfifo qdisc sets up three priorities for traffic.  Basically
>priority, normal, bulk.  If you lower something to bulk then anything
>unmodified will take precedence, since normal is the default.
>
> > Scott
>
>j


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus