The torrent file download is not the torrent traffic.
I don’t really mind about downloading torrent files: they can be a few megs, even a dozen, and then it’s done.
Torrent traffic is about large movies (from a few gigas to a hundred), mostly all pirated contents.
And you can bring torrent files into the network with (s)ftp, email, chat, https and so on, not just HTTP.
The L7 matcher can be defied by E2E cryptography, so only TCP and UDP ports remain to be used.
I still think my approach is the one that can reliably give some results. Even if they won’t really block torrent and other p2p traffic.
Hi!
I followed your tutorial and it’s perectly work on my router ! Thank you a lot !
(I work for a small french ISP and we receive letters from Hadopi, so we are searching a solution to limit the illegal download ^^ )
I have a question, maybe it will sounds stupid for you, but this code :
Can we complete it with another “keyword”, another website name ?
Is it this ? A sort of list of torrent sites names ?
This will only block the download of a torrent file, not the torrent traffic itself.
Try to first download the torrent file, then enable the rules and finally ask your torrent client to load the torrent file to start the p2p exchange.
You will see the p2p traffic bidirectionally flowing unimpeded!
P.S.
I am even more sorry for my english: I am Italian!
Hi!
I don’t want to block it (we can’t ! Because gaming used p2p, for example, and it’s perfectly legal) !
I just want to identify the customers who try to download and then, limits their bandwhidth, send them an email, things like that !
Well, the OP titled this thread as “Block Torrents & p2p Traffic 100% working” so I thought the topic was still sticking.
Anyway, blocking the download of torrent files alone from a selected set or URLs sounds to me like a waste of time as you can download them throug POP3, IMAP4, FTP and so on. Those won’t be blocked.
Anyway, you are right. P2P (DHT) is being used for a number of purposes that cannot easily be told apart from each other.
I think now this thread title is misleading for two reasons:
you cannot block (real) P2P traffic based upon specific usage (lawful vs unlawful)
the proposed solution doesn’t “Block Torrents & p2p Traffic” at all.
Yep ! This is why I used this topic to mark people who have visited torrent website.
I will make a blacklist of torrent website, with a web proxy in MK. (I mean, I will try ! I know that it will not work at 100%)
And, finally, I am searching of how to see who is using the most bandidth, to then limit only him, get his IP address, send him an email… etc !
(And I take the opportunity to ask you if you have any idea of how to manage that )
Why would you want to block torrents? It is often legitimate traffic. Perhaps torrents are sometimes used to copy copyrighted content without appropriate license, but that is on the person making the illegal copy.
The ISP cannot know if a torrent is legal or illegal without confronting the customer to check their license for the content.
Blocking can also be shaping (or queueing in mikrotik lingo).
P2P traffic creates sustained loads in both directions and can be overkilling for most WANs.
I cannot and don’t want to tell legitimate from unlegitimate content access: no sane net admin would.
Being able to tell P2P traffic from other things would be interesting. It seems it’s impossible at the moment.
What I can do at the moment is to shape high TCP/UDP port traffic, but that’s neither enough nor proper.
It seems to me if an ISP offers a customer bandwidth, say 1M up and 10M down for example, then the ISP is obligated to deliver 1M up and 10M down 99% of the time. After all, that’s what the customer was sold.
If an ISP can’t deliver promised bandwidth in aggregate due to oversubscription, overutilized gear, or any other cause, then the ISP needs to establish more bandwidth at the point of congestion. Sure, it can be expensive, but lying to the customers about the service an ISP is capable of providing can also be expensive.
I have 100mbps symmetrical.
One or two clients doing BitTorrent with a few files to be shared are enough to eat 50+% of the available bandwidth.
This is why I mind about p2p!
I’ve managed networks for a few small ISPs over the years. I admit I don’t know your environment at all, so I’m just making uninformed opinions here. It seems to me with 100Mbps symmetric, why not offer the customers something like 1M up and 5M down or something similar? Depending on the number of subscribers, that might be a reasonable balance of bandwidth offering, and oversubscription could be more reasonably managed. The queues could even be set up in such a way that users exceed the max subscribed bandwidth when it’s available if you wanted.
You’re right! But we receive letters from Hadopi and I think it will be temporary ! Just the time to send an email to the customers, or something like that, we will limit his bandwidth. Basically, my boss want me to directly send an email to the customers, to make him confirm that he might be do something illegal and if it is, he have risk consciousness.
We will not blocking p2p, it’s impossible and we know
But this letters…
Checking the legitimacy of any traffic falls far beyond the responsibilities and the capabilities of a network manager.
Being her an ISP or not is irrelevant here.
If you limit your customer bandwidth at large, you will end breaking the relationship: you’ll be slowing down your customer bandwidth for everything, not just P2P.
This is why I aim at identifying the P2P traffic (BitTorrent, DHT-based protocols and the likes).
If I succeed I can do something: blocking, limiting …
If I cannot, then I have little to discuss.
Again, downloading a torrent file is NOTHING.
Have you tried to use a recent BitTorrent client with “KAD support”?
It doesn’t need any torrent file but just the hash value, a string you can get by email or on the web.
The DHT will make the “rest of the magics”, by just requiring some more time to “look” for a list of suitable peers.
So you won’t be able to block or shape anything as even the torrent file is not needed any more.
You can only block everything, as they can be using “low ports” and apply a “light disguise” to the traffic as P2P can use any TCP and UDP ports from 1 to 65535!
What I see doable here is to allow “low ports” and a few “high ports” and block or limit the bandwidth to anything else.
It’s more like “traffic containment” than “traffic control”, but I see no option here.
I have thinking about port mirroring and wireshark to check if the customers is downloading something.
What do you think about this solution ?
Anyway it’s impossible to identify if the customers is doing something illegal…
(And I don’t know DHT ! Thanks for this information ! I found on the forum a guy who block this type of traffic by using DNS static and some things like that. )
Almost all P2P traffic is encrypted, thus inspecting the content wouldn’t help much.
Moreover, even if is wasn’t encrypted but just “compressed” with your favorite tool, it would require you to first download all the stuff, uncompress it and then check.
In that case the download wouldn’t be blockable as it had already happened.
Wireshark on a mirrored port is a very powerful tool. But only if you know what you are looking for.
I know a large company that stores for a few weeks all traffic (but not the payloads) coming from mirrored ports for late analysis and statistics.
They can look for specific events.
But, yet, you need to know what to search for.
If you do know, than you don’t need Wireshark.
It could make some sense to use nTop or a similar tool to analyze the actual traffic in real-time.
While you wouldn’t still be able to see the payloads themselves, you could have a rather precise idea of the type of traffic and its endpoints and, with some training, be able to tell a good P2P from a bad one.
You could then decide to block or slow down that type of traffic based upon IPs and TCP/UDP ports.
If you want to have a precise real-time idea about your traffic, then you really need nTop.
Finally whatever solution is based on the DNS, it is trying to block the download of torrent files.
Which isn’t required any more with “KAD” enabled: the torrent file di retrieved from the P2P network itself.
I’d like you to test the BT+KAD download with your favorite client.
For example, the official Ubuntu 16.04 server ISO file is also available on BitTorrent.
Its hash (as in DHT=distributed hash tables) is a49cd0d5abc633e1ee2ad1fee8ced66614415ceb.
Try using this string to download the file.
It takes just a few minutes more than a regular download with a torrent file.
Once the download is started it will have very same speed as a regular BitTorrent download.
DHT is really a P2P protocol (actually a technology) where now server is needed.
The regular BitTorrent requires a torrent file to be downloaded from a server and there are dozens of “torrent caches” from which you can download them.
The point is that those caches don’t (because they cannot) check for the legitimacy of each single torrent.
With the DNS you block the access to those caches and think you are blocking BitTorrent.
But you are not.