Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Joel Newkirk <netfilter@newkirk.us>
To: inghau@perkom.co.id, netfilter@lists.netfilter.org
Subject: Re: how to block kazaa ?
Date: Tue, 25 Feb 2003 22:42:25 -0500	[thread overview]
Message-ID: <200302252242.25175.netfilter@newkirk.us> (raw)
In-Reply-To: <003d01c2dd40$fe922030$210aa8c0@sabirin>

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



  reply	other threads:[~2003-02-26  3:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-26  2:44 how to block kazaa ? inghau
2003-02-26  3:42 ` Joel Newkirk [this message]
2003-02-26  5:07   ` Nimit Gupta
2003-02-26  7:00     ` Joel Newkirk
2003-02-26  7:21     ` hare ram
2003-02-26  5:28   ` Scott Lamb
2003-02-26  4:20 ` Arnt Karlsen
  -- strict thread matches above, loose matches on Subject: below --
2003-02-26  6:07 Joel Newkirk
2003-02-26  6:41 lawrence Of Arabia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200302252242.25175.netfilter@newkirk.us \
    --to=netfilter@newkirk.us \
    --cc=inghau@perkom.co.id \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox