I've found that some Bittorrent clients just do. not. give. up. You block a torrent, the clients will try, try again, often changing something in how they send the messages: route over https, exclude certain peers, etc, and eventually they sometimes find a way around the block.
What I've seen that's most effective in really defeating bittorrent is throttling/tarpitting the user's traffic: not just bittorrent itself, but *everything* originating from that internal IP. Send them back to the dial up era. When the bittorrent traffic stops, their connection returns to normal within a few minutes. Students in this situation have figured out pretty quickly that bittorrent was causing their slowness issues. From the student's perspective, bittorrent breaks their computer. The great thing here is that it really does tend to follow that thought process, and the blames tends to be assigned to the protocol or something wrong with their bittorrent configuration, rather than with your network. At this point, the behavior is self-correcting. If a student does complain, you point them to bittorrent as a possible factor, and they'll get it soon it enough. There's some good news/bad news for this approach, though. The good news is that you don't have to detect every packet from every torrent stream for a student to have an effective block. The bad news is that some unwanted traffic still does get through (though usually not enough to offend the copyright gods), and that there is a risk for small false positives creating slow connections for innocent users... especially when there are some legitimate bittorrent uses such as research data, linux distributions, game updates, etc. I tend to not apply this policy to the population at large, but only to those who have already tripped a flag somewhere: log first, find where your torrenters are, and apply the tarpit policy rule to that group. Joel Coehoorn Director of Information Technology 402.363.5603 *[email protected] <[email protected]>* The mission of York College is to transform lives through Christ-centered education and to equip students for lifelong service to God, family, and society On Wed, Oct 8, 2014 at 8:54 AM, Lee H Badman <[email protected]> wrote: > We recently started relying on the 5508 AVC capability to block > Bittorrent, which it seems to do fairly well. But… we are getting an > increasing number of take-down notices where Bittorrent was used to do > something, but drilling into the data in PI shows that nothing was detected > by the WLC for the activity that led to the take-down. In other words, the > system doesn’t see the Bittorrent activity. > > We have all three Bittorrent protocols in use > (Bittorrent/encrypted/network), and can tell that most Bittorrent is indeed > being blocked. But what is getting by is probably sufficient enough that we > may have to abandon the WLC P2P strategy and go back to an appliance. Has > anyone been through this, and found anything else to add to the profile to > help stem the Bittorrent? (We also have the obvious ones like eDonky, etc) > > Thanks- > > Lee > > Lee Badman > Wireless/Network Architect > ITS, Syracuse University > 315.443.3003 > (Blog: *http://wirednot.wordpress.com* <http://wirednot.wordpress.com>) > > > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
