13

I have referenced an old external Cisco article on how to block Bit torrent traffic referenced on-line Here

This procedure I have found only works 50% of the time.

I find blocking bit torrent specific ports, and doing the regex do work, it just does not catch all the traffic.

object-group service bit-torrent-services tcp-udp
port-object eq 6969
port-object range 6881 6999

and

regex bit-torrent-tracker ".*[Ii][Nn][Ff][Oo]_[Hh][Aa][Ss][Hh]=.*"

Does anyone have more up to date regex for finding bit torrent traffic? Or does is this the limits of the ASA at this time?

  • I believe this would be the limit of ASA at this time. Other UTM appliances use "an application module (based on IPS)" and can successfully block it. Nevertheless I am sure you can do it too but using an IPS module attached to the ASA. – laf Jun 27 '13 at 5:10
14

<joke>Unplug it</joke>

Bittorrent clients can (and do) use random ports. Blocking the common ports will only encourage users to move to different ports. Also, the inter-client traffic has supported encryption for some years now -- originally as a means to limit ISP interference -- making the actual p-t-p traffic unrecognizable.

Looking for "info_hash" in the client-tracker communication, while somewhat effective, is also easily defeated. (tor, ssl, vpn, etc.) It also does nothing to stop tracker-less swarms (DHT), peer-exchange (PEX), UDP tracker protocol...

If you've managed to kill 50%, count yourself lucky. This is a game of whack-a-mole you cannot win.

| improve this answer | |
9

Configure it in transparent proxy mode for all supported application protocols and only allow proxified connections. Any unknown protocol would fail including BitTorrent. SSL tunneling for BitTorrent is unfeasible so HTTPS isn't too big a hole. Basically letting through any routed connection which hasn't been L7 approved will let BitTorrent slip through.

| improve this answer | |
  • I bet a lot of things will break with this method. What about limiting connection number, once connection number from one host x hits x , kill all of its connections for y seconds. This is an effective way to discourage users from using p2p file transfer. There are security/auditing software/appliances that can do this. Not sure about ASA tho. – sdaffa23fdsf Jun 27 '13 at 7:08
  • There are other solutions which go to extremes such as querying the tracker and blacklisting all the peers. If it's an office environment, only trusted users should have access to anything other than HTTP(s). For the rest of them, the transparent HTTP proxy will have no ill effect and routed/NATed access can be granted on a case-to-case basis. – Monstieur Jun 27 '13 at 7:35
  • How exactly is SSL tunneling "unfeasible"? You do realize many VPNs are just an SSL connection. Users hellbent on using BT will find a way through your attempts to block them. – Ricky Beam Jul 21 '16 at 18:45
  • High bandwidth TCP tunnelling over SSL will quickly melt down to the point where it's no longer a bandwidth hog. The external tunnel endpoint would be the IP address visible as the Torrent client and not your company's address. – Monstieur Jul 22 '16 at 6:43
-1

One of the workaround for this is to rate limit Torrent traffic by making specific set of Control list. Soure Port and Destination IP ( your IP Pools).

Exclude ports for common services like RDP ( Remote Desktop 3389), VNC, HTTP 8080 (subsitute to 80)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.