Filtering Bittorrent

[minimike]

Hi

I have found a script for Linux http://www.lowth.com/rope/BlockingBittorrent for how to keep out Bittorrent out of the Network. Is there something for IPFW what can do the same?

 

[SIFE]

The only solution i know is to block the Bittorrent port range, Bittorrent uses UDP protocol.
Its range between 6881-6999 and 6881-6889, depend in the version of Bittorrent, the rule you have to add it will be like so:

block drop in inet proto udp from any to any port 6881<>6889
block drop in inet proto udp from any to any port 6881<>6999

 

[graudeejs]

The only solution i know is to block the Bittorrent port range, Bittorrent uses UDP protocol.
Its range between 6881-6999 and 6881-6889

That is highly subjective

 

[phoenix]

The only solution i know is to block the Bittorrent port range, Bittorrent uses UDP protocol.

Its range between 6881-6999 and 6881-6889, depend in the version of Bittorrent, the rule you have to add it will be like so:

Every torrent client I've used allows you to select the ports to use for torrent, dht, etc. It's very rare to actually find port 6881 in use anymore, due to generic firewall blocks on that port.

For example, none of my torrent clients use those ports.

block drop in inet proto udp from any to any port 6881<>6889
block drop in inet proto udp from any to any port 6881<>6999

OP asked for IPFW rules, not PF.

ipfw add deny udp from any to any 6881-6999

 

[SIFE]

Every torrent client I've used allows you to select the ports to use for torrent, dht, etc. It's very rare to actually find port 6881 in use anymore, due to generic firewall blocks on that port.

I was talk in general .

OP asked for IPFW rules, not PF.

I didn't note that, may be I am tired.

 

[minimike]

Is there no any pendant for ROPE with IPFW or PF? If not I have to use Linux for Firewall To close a port for outgoing Bittorrent or Kazaa is stupid. Clients could change their working ports and use that garbage again.

 

[terminus]

Try your luck with solution from nuclight:
http://nuclight.livejournal.com/125747.html

It is based on detection of torrent peers addresses by cutting them from tracker announces using divert sockets and ipfw tee rules. Article is in Russian, but script is in perl and sh

 

[goshanecr]

Up! Is there working way to block|shape|detect torrent traffic with ipfw()?

 

[SirDice]

Yeah, block everything outgoing. Really. It's rather futile to only block specific ports because all bittorrent clients can be configured to run on any port. So the only way to block it is to block everything.

 

[goshanecr]

Maybe blocking based on protocol analyzing? On mikrotik there is existing firewall rules with packet inspection.

 

[SirDice]

Maybe blocking based on protocol analyzing?

Then I'll run a bittorrent client over a VPN or SSH tunnel. Good luck trying to analyze encrypted packets.

For everything you can think of trying to prevent it I can find several ways of circumventing it. The only thing I can't circumvent is a total block of everything. Which is what's typically done on larger networks, no workstation will ever get a direct connection to the outside world.

 

[goshanecr]

SirDice, my users not so IT professionals like you

Also I'm found such netgraph solution (not tests it yet) HERE:

#!/bin/sh

ngctl mkpeer ipfw: bpf 2 main
ngctl name ipfw:2 utp_filter
ngctl msg utp_filter: setprogram { thisHook=\»main\» ifMatch=\»\» ifNotMatch=\»main\» bpf_prog_len=12 bpf_prog=[ { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=8 k=64 } { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=6 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=4 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=20 } { code=21 jt=0 jf=1 k=2147483647 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] }

ipfw add 180 netgraph 2 udp from any to any iplen 0-128

With following refinement for bpf program:

{ thisHook=\»main\» ifMatch=\»\» ifNotMatch=\»main\» bpf_prog_len=18 bpf_p rog=[ { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=14 k=64 } { code=48 jt =0 jf=0 k=9 } { code=21 jt=0 jf=5 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=3 jf=0 k=8191 } { co de=177 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=20 } { code=21 jt=6 jf=0 k=2147483647 } { code=32 jt=0 jf=0 k=49 } { code=21 jt=4 jf=0 k=1114207316 } { code=32 jt=0 jf=0 k=52 } { code=21 jt=2 jf=0 k=1114 207316 } { code=32 jt=0 jf=0 k=41 } { code=21 jt=0 jf=1 k=1114207316 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] }

 

[leebrown66]

I've used security/snort on a linux box for this to drop packets. The detection is suprisingly simple (/announce in plaintext I think), but yes you have to inspect the payload, so raw IPFW can't do this. I like that netgraph aproach though, I'll have to look into that as I'm building a new version of our IPS's with FreeBSD to replace linux.

As SirDice says it's possible to circumvent, but all I care about is protecting our public IP address from DCMA notices.