Jump to content

Blocking Bittorrent Traffic

Mr-Protocol

By Mr-Protocol
in Security

 Share

Recommended Posts

Mr-Protocol Grand Master

Mr-Protocol

Posted
Posted (edited)

You may say: "OMGz y block torrentz¿"

Here is my situation:

I am running a tor relay on Ubuntu VM (VirtualBox) and noticed a LOT of traffic of the BitTorrent nature. The point of running tor is not to hide yourself from your ISP so you can download pirated movies/music/software/etc.

So I went off looking for a solution to identifying and blocking BitTorrent activity through my tor relay. A few people suggested ipp2p, ROPE, IPCop, or many other addons. Another suggestion was buying some high end corporate router to detect and block.

I did some reading from SANS and what their methods were on detecting BitTorrents from a forensic standpoint. The material I read was good but a little out-dated. That and it was how to detect it with snort. Well I didn't want to have to setup snort just to block BitTorrents. Seems like there should be an easier way. AND there is :D!

iptables

Yup plain ol iptables.

My blocking methods:

Google Doc Link To My Script.

With that script posted above, I have only seen BitTorrent handshake packets come in. Which is normal but they are dropped as soon as they hit my machine. It has eased the bandwidth of my network and the tor relay isn't being abused by a bunch of BitTorrent connections.

I'm not sure how many others would benefit from this script/commands so i figured I would share. If nothing else when you MITM you can cut back the number of packets you are looking at by eliminating BitTorrent traffic. Supposedly ~65% of internet traffic is BitTorrent related. Possibly can add this as an option in Jasager or Interceptor so they don't get bogged down either? I'm no master of iptables so if you have any comments on what I have here, feel free to post your thoughts.

Edited by Mr-Protocol
Link to comment
Share on other sites
Infiltrator Newbie

Infiltrator

Posted
Posted

I don't mind torrents but apart from that good work.

Link to comment
Share on other sites
Mr-Protocol Grand Master

Mr-Protocol

Posted
  • Author
Posted (edited)

I'm not sure why the link for the router, but cool. I just got the Cisco/Linksys E2000 wireless router. It has a lot of features but nothing that can block BitTorrent (by default).

I am a BitTorrent user myself. And some of the things I download might possibly be questionable, but when I'm giving my bandwidth for people to use as a proxy for IM, web, whatever they want; I refuse to want them to run BitTorrents.

An after thought was using those filters to thwart all the traffic generated by BitTorrent in MITM. I guess it could be used if you are a parent and tech-savvy, to add those to the iptables of your home router (openWRT/DDWRT) to stop kids from using them? Whatever fits the purpose I suppose.

If nothing else it is a great example of using string matching (the last one being hex-string matching) with iptables. The iptables MAN page will go more in detail with functions.

string

This modules matches a given string by using some pattern matching strategy. It requires a linux kernel >= 2.6.14.
--algo bm|kmp
    Select the pattern matching strategy. (bm = Boyer-Moore, kmp = Knuth-Pratt-Morris) 
--from offset
    Set the offset from which it starts looking for any matching. If not passed, default is 0. 
--to offset
    Set the offset from which it starts looking for any matching. If not passed, default is the packet size. 
--string pattern
    Matches the given pattern. --hex-string pattern Matches the given pattern in hex notation.

The only changes I would make pertain to adding a --to offset. I may have to play with it more but adding a --to offset would limit it searching full packets. Which also the ability to use --from and --to makes it so you can match very specifically what you want to search for.

I will update the first post and make note of changes with offsets here when I allow tor to run with no blocking to re-gather BitTorrent traffic to properly identify.

Edited by Mr-Protocol
Link to comment
Share on other sites
Infiltrator Newbie

Infiltrator

Posted
Posted

What about blocking the ports that Torrent uses for making connections.

Link to comment
Share on other sites
Mr-Protocol Grand Master

Mr-Protocol

Posted
  • Author
Posted (edited)

Ok I have tried to make offsets for the matching based off packet location but it didn't work out so well. There was some requests that put HTTP in front to thwart the more advanced filter. So using just the filters to hit key items without offset limitations works the best.

With those filters, I let the tor node run for most of a day. I did not find any identification of BitTorrent activity other than remote computers trying to send to my tor node a BitTorrent handshake which is dropped as soon as my Ubuntu gets it.

There was some encrypted packets which I could not identify, but from what I have seen on the packets I have looked at while making these filters; some of the data would be unencrypted and the rest could be encrypted. I'm not sure if the BitTorrent handshake must be sent unencrypted but I will try it on my system and see what I find. So I would like to say this script blocks a good ~99%-ish of BitTorrent activity.

Script:

http://docs.google.com/Doc?docid=0ARW_kKn3...qc2dq&hl=en

you can assign any port number for torrent

Utorrent can randomize the port on every startup...

I have installed Utorrent on my Ubuntu box now, Forcing encryption and finding a means of filtering those packets as you read...

Wow... what a pain in the ass... BUT some data is readable... Mostly it's in UDP packets...

UDP%20torrent%20traffic.JPG

The packet data (minus the UDP header info) starts either with d1:ad2 or d1:rd2 I think dependent on if it is an answer or request?

The first packet has string "ping" recognizable which can be used to filter. Filter UDP packets matching a string "ping". There is also the string "find_node" and "target".

Another string which I think might be the encryption type for Utorrent: 1:v4UT or 1:v4UTL depending on sent or received yet again. Not sure but it seems to be constant in at least this stream.

Incoming packets has the Hex(13)BitTorrent Protocol string in it. (Should be dropped by PREROUTING filter)

UDP%20torrent%20traffic2.JPG

d1:ad2:id20:..'..7U.=0".,....E..9:info_hash20:gz..kk.=..@..6..JTlye1:q9:get_peers1:t8:....&>.R1:y1:qe

d1:ad2:id20:..'..7U.=0".,....E..9:info_hash20:gz..kk.=..@..6..JTlye1:q9:get_peers1:t8:....&>.R1:y1:qe

So there is some identifiable data there I could use for more filters to stop encryption as well. I will work on this more tomorrow pending time, and the desire to look through 100's of packets manually.

Edited by Mr-Protocol
Link to comment
Share on other sites
IOSys Newbie

IOSys

Posted
Posted (edited)

You have successfully blocked the tracker-communications and DHT .

However, the actual data-exchange is "encrypted" if the client is set up to require encrypted transport .

Bit-torrent uses 2 flavours of RC4-"encryption" :

"Plain" where only the packet-header is encrypted and "Full" (sometimes just called "RC4" in the client )

where the entire packet is encrypted. On top, many torrent-clients are switching from TCP to UDP for the peer-"connection" . And inside those encrypted packets you also have "PEX" running .

"Peer EXchange" lets clients share info about peers directly with each other ...

So, there's a good chance the unknown encrypted packets you see ARE bit-torrent .

Even Sandvine can't reliably block bit-torrent .

PS : I still don't get why they run torrents over TOR, just browsing over it is a royal PITA ..

And who trusts a system made by the US Navy and MIT anyways ?

I realise it's probably a lost cause but it would be a lot better to try and educate people about why using TOR for torrents is a real bad idea. The least dumb will probably understand this :

https://blog.torproject.org/blog/bittorrent...-isnt-good-idea

Edited by IOSys
Link to comment
Share on other sites
Mr-Protocol Grand Master

Mr-Protocol

Posted
  • Author
Posted (edited)

Very valid points. The encrypted data I found later was in TCP packets. I know they are torrent because I was running one. But essentially if I block DHT and tracker communications as well as finding the UDP packets to filter. There will be no initial handshake so no traffic in theory. I'm not sure what Sandvine is but I'm at work right now so I can't really start googling.

But SOMETHING has to be un-encrypted to make the initial communication I would think. If nothing else i can stop tracker communications and that will waterfall to other torrent packets not working.

socks proxies such as Tor only support the TCP protocol

According to the link, Tor does not allow UDP so filtering UDP is pointless?

I will keep working on it to get at least a 90% or better solution. I still refuse to run a tor node and allow people to torrent off of it.

Edited by Mr-Protocol
Link to comment
Share on other sites
Infiltrator Newbie

Infiltrator

Posted
Posted

Hi Mr-Protocol

Take a look at this forum, there are some good discussions on blocking torrents

https://forum.openwrt.org/viewtopic.php?pid=42623

Link to comment
Share on other sites
Mr-Protocol Grand Master

Mr-Protocol

Posted
  • Author
Posted
Hi Mr-Protocol

Take a look at this forum, there are some good discussions on blocking torrents

https://forum.openwrt.org/viewtopic.php?pid=42623

That link has good info but nothing new to me or stuff I've looked at. I haven't had much time to work on this more but the script I have currently stops a LOT of it. Eventually when I get time from Tekken 6 or hanging out with friends will I continue to work on blocking encrypted BitTorrent traffic.

Link to comment
Share on other sites
Infiltrator Newbie

Infiltrator

Posted
Posted
That link has good info but nothing new to me or stuff I've looked at. I haven't had much time to work on this more but the script I have currently stops a LOT of it. Eventually when I get time from Tekken 6 or hanging out with friends will I continue to work on blocking encrypted BitTorrent traffic.

No problems!

Link to comment
Share on other sites
Mr-Protocol Grand Master

Mr-Protocol

Posted
  • Author
Posted (edited)

I will not be working on this any further. My ISP is angry and sent me an angry letter. In this letter it says to read the TOS and this and that blah blah multiple complaints. F**K them. I know it is probably from running the Tor node due to I caught some email spammers using it to send spam. And this is why when people try and use Tor for good, people gotta screw it up.

Edited by Mr-Protocol
Link to comment
Share on other sites
  • 2 weeks later...
NetworkPro Newbie

NetworkPro

Posted
Posted

Angry letter?

No ISP would take legal action agains each and every customer.

What if you would just ignore the letter?

Do you have other ISPs in your area?

What if you talked with them to arrange a "business class" service :)

Link to comment
Share on other sites
Mr-Protocol Grand Master

Mr-Protocol

Posted
  • Author
Posted
Angry letter?

No ISP would take legal action agains each and every customer.

What if you would just ignore the letter?

Do you have other ISPs in your area?

What if you talked with them to arrange a "business class" service :)

Yes an angry letter. My modem went on a quarantine list. My IP was reported spamming emails of spoofed WoW emails. Did my best to prevent this crap but yeah oh well.

If I would have ignored that letter and continued to run my Tor node with these reports happening I would have my service turned off.

Regardless of other ISPs in the area or a business class service. It was the being reported thing that got me the letter.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...