26 Nov
2013
26 Nov
'13
5:08 p.m.
For people using mikrotik gear in HSMM networks like HAMNET etc
currently testing these rules to block all P2P and more specifically
bittorrent;
/ip firewall layer7-protocol
add name=p2p_dns
regexp="^.+(torrent|thepiratebay|isohunt|entertane|demonoid|btjunkie|mininova|flixflux|torrentz|vertor|h33t|btscene|bitunity|bittoxic|thunderbytes|entertane|zoozle|vcdq|bitnova|bitsoup|meganova|fulldls|btbot|flixflux|seedpeer|fenopy\
|gpirate|commonbits).*\$"
add name=ssl
regexp="^(.\?.\?\\x16\\x03.*\\x16\\x03|.\?.\?\\x01\\x03\\x01\?.*\\x0b)"
add name=bittorrent2 regexp="^(\\x13bittorrent protocol)"
add name=directconnect regexp="^(\\\$mynick |\\\$lock |\\\$key )"
add name=p2p_www regexp="^.*(get|GET).+\\\r\
\n(torrent|thepiratebay|isohunt|entertane|demonoid|btjunkie|mininova|flixflux|torrentz|vertor|h33t|btscene|bitunity|bittoxic|thunderbytes|entertane|zoozle|vcdq|bitnova|bitsoup|meganova|fulldls|btbot|flixflux|seedpeer|fenopy|gpirate|commonbits).*\
\\\$"
/ip firewall mangle
add action=jump chain=prerouting comment="all p2p"
jump-target=p2p-service p2p=all-p2p
add action=jump chain=prerouting comment="l7: directconnect"
jump-target=p2p-service layer7-protocol=directconnect
add action=jump chain=prerouting comment="encrypted (ssl) on other
then https port" connection-state=new dst-port=!443
jump-target=p2p-service layer7-protocol=ssl protocol=tcp
add action=jump chain=prerouting comment="l7: bittorrent2"
jump-target=p2p-service layer7-protocol=bittorrent2
add action=jump chain=prerouting comment="bittorrent: announce_peers"
content=announce_peers jump-target=p2p-service
add action=jump chain=prerouting comment="bittorrent: info_hash"
content=info_hash jump-target=p2p-service
add action=jump chain=prerouting comment="bittorrent: getpeers"
content=getpeers jump-target=p2p-service
add action=jump chain=prerouting comment="bittorrent: torrent"
content=torrent jump-target=p2p-service
add action=jump chain=prerouting comment="bittorrent: tracker"
content=tracker jump-target=p2p-service
add action=jump chain=prerouting comment="dns: block torrentsite
resolving" dst-port=53 jump-target=p2p-service layer7-protocol=p2p_dns
protocol=udp
add action=jump chain=prerouting comment="http: block torrentsite GET"
dst-port=80 jump-target=p2p-service layer7-protocol=p2p_www
protocol=tcp
add action=jump chain=prerouting comment="download van .torrent files"
content="\\r\\nContent-Type: application/x-bittorrent"
jump-target=p2p-service protocol=tcp src-port=80
add action=jump chain=prerouting comment="DHT magnet links"
content=d1:ad2:id20: dst-port=1025-65535 jump-target=p2p-service
packet-size=95-190 protocol=tcp
add action=mark-connection chain=p2p-service comment="markeer alle
bovenstaande p2p rules voor firewall" new-connection-mark=p2p
passthrough=no
/ip firewall filter
add action=drop chain=forward comment="drop p2p marked packets"
connection-mark=p2p
WARNING: This is mostly layer 7 packet inspection and will put a lot
of load on your CPU depending on the bandwith.
Currently running this on a CCR16 with 10mbit load and 1% cpu usage.
To compare, on an RB1200 this would push the cpu to 100%
Also note this will effectively block all traffic containing the word
"torrent" and "tracker" and so on and might not be what you want (eg
in a chat session or email)
And ofcourse this does not distinct between legal p2p (like
downloading debian via torrents) and illigal p2p (like the example
from brian)
Why block this at all ? On our HSMM network in Belgium several
hamclubs have a 5ghz link to the HSMM and DHCP running on indoor
secured wifi ap's. People bring their own laptops and sometimes one of
them has a bittorrent client running minimized (in the systemtray) on
it, but forgets to disable it before connecting. Ofcourse the
bittorrent client does what it is designed to and starts to transfer
data.
We have our own connection to the internet for 44.144 and experiment
with using them as public ip's on the internet, so no outbound traffic
passes through UCSD and inbound traffic should not pass through UCSD
since our announcement is more specific then 44/8.
We also use a traffic shaper to cap all 44.144 internet traffic to
1mbit up & down per user, since it is not meant to be used as a
replacement for commercial internet.
We are currently also thinking of putting up a portal page where they
are warned to disable all p2p clients and such and an "I Agree"
button, and maybe even a form where people should enter their
callsign, however this is easily "spoofed".
More firewall rules, additions or adjustments are always welcome.
73s
Robbie ON4SAX
On Tue, Nov 26, 2013 at 10:35 PM, Brian Rogers <n1uro(a)n1uro.ampr.org> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> Greetings;
>
> On Tue, 2013-11-26 at 12:55 -0800, Brian Kantor spake:
>
> [snip]
>
>> Date: Tue, 26 Nov 2013 20:19:33 +0000
>> From: IP-Echelon Compliance <notices.warner(a)ip-echelon.com>
>> To: bk29(a)ucsd.edu
>> Subject: Notice of Claimed Infringement - Case ID 1335xxxxx
>> Type: BitTorrent
>
> Actually this shows a very possible 2-fold issue:
>
> 1) Use of Torrent = need for IP Security 101 class again.
>
> 2) Routing issue may be occuring by the end 44-net user. A properly
> configured 44-net system hitting a commercial IP should source as their
> commercial IP, not their 44-net IP. Not only does that keep traffic at
> UCSD down but most likely would improve the speed at the users end as
> well.
>
> There is a third issue but that's too obvious and I don't need to point
> that out. :)
>
>
>