How can one block, or severely slow down, BitTorrent and similar peer-to-peer (P2P) services on one's small office network?
In searching Server Fault I wasn't able to find a question that served as a rallying point for the best technical ideas on this. The existing questions are all about specific situations, and the dominant answers are social/legal in nature. Those are valid approaches, but a purely technical discussion would be useful to a lot of people, I suspect. Let's assume that you don't have access to the machines on the network.
With encryption use increasing in P2P traffic, it seems like stateful packet inspection is becoming a less workable solution. One idea that seems to make sense to me is simply throttling down heavy users by IP, regardless of what they're sending or receiving -- but it doesn't seem many routers support that functionality at the moment.
How can you throttle P2P/BitTorrent traffic?
I think most approaches that ask "How do I lock down X" are just plain wrong. It's badness enumeration.
Now go downvote me but I think that you should (as you do with "normal" firewalls) just allow the traffic that matches known good traffic. But now you have a problem, SSL encrypted HTTP traffic isn't as easy to allow. There are solutions to it that are effectively a man in the middle attack so if you don't have total control over the clients and signed contracts where people accept being snooped on you might face legal charges (in some countries that is totally forbidden by law, some countries allow such terms in contracts).
To me the only sane level where you want to differentiate between P2P and normal traffic is an application firewall. There's no way for a firewall at the IP or transport layer to sanely make decisions on wether the actual payload is a valid request or not.
Been there, tried that. Just won't work. In a SOHO environment, such as where I work, there is no way to tell what is P2P and what is "legitimate" traffic, as the gear we have just isn't that sophisticated. The only way I have found that's worth anything at all is a more "manual" way.
My monitoring system (Nagios) alerts me when the traffic on the external interface of the firewall stays above a preset point for more than two consecutive check periods, which are 5 minutes apart. When this happens I have a look at the live traffic display on the firewall (Smoothwall) management interface and if I see a particular machine with a fairly continuous traffic flow to or from the Internet I have a remote look to see what's running on that machine. If I see something that I know is a P2P client I'll pay that user a visit.
This is pretty crude but, and this is a pretty important point, it's the best I can do with what I have available to me.
My preferred method is to configure the client to throttle itself. This seems to be the most simple and effective method. Almost every client supports it; I use the ancient ctorrent client and even it support dynamically configurable throttling via the CTCS extension.
If the client or managing user refuses to do so, and social engineering fails, I run straight for QFQ or WF2Q. No most $50 SOHO routers don't support it, this is a technical and complicated operation, you get what you pay for. I build my own Alix or Soekris powered routers (cost is typically around $100 each with used parts off eBay) so I can run m0n0-wall, pfSense, or straight FreeBSD (my OS of choice, though no reason Linux couldn't be used). Lately I've been looking into the RouterStation as a cheaper alternative to these SBCs.
The smart people at ResTek at my old employer, who were managing a large University Dorm network, had to deal with this one a lot. They ended up with a packet-shaper that de-prioritized BT traffic relative to normal HTTP traffic. Packets still got through and sharing still happened, but it took a dogs age1. According to them, it worked really well.
Even with encryped payloads, BT traffic is recognizable by its shape; lots of somewhat persistent connections to lots of other nodes. It's still circumventable, so isn't perfect.
1: So what did they do? Schlep over to the campus WLAN to BT things. So when the DMCA notices came in, the captive portal had already recorded their login and IP information so we knew just who to speak to.
In a SOHO environment?