[kwlug-disc] Blocking Bittorrrent

B.S. bs27975 at yahoo.ca
Sat Nov 21 00:30:54 EST 2015


Good info here, thank you.

Seems like if anyone has some 'best network management practices' links, they would be useful.

There is a business principle that you can't manage what you can't measure.

For net admins this points out the basic back end infrastructure need for things like mrtg, common log amalgamation / automatic processing, rsyslog, vlans / subnetting (points of segregated analysis /control - e.g. I.T. needs less restrictions to be able to enforce restrictions on others), and a seemingly endless number of additional fiddly bits that must somehow come together into a coherent whole. And a seemingly constantly moving target. While introducing the least number of road blocks possible to avoid angry mobs of users coming after you. Just remember the explanation of the big, bad, nefarious world out there forces you into this. Nobody wants to do it - we all have better things to do.

In the end, you can choose not to throttle anything, but you can't throttle something if the infrastructure isn't present in the first place. And you can't know what to throttle, or even be able to, without the monitoring infrastructure (which inherently provides a control infrastructure) present in the first place.

Never mind that inherently you are forced into having to establish even more service redundancy that has to be commonly established. e.g. Multiple pfsense boxes (points of ingress/egress / monitoring / control points) for failover when something fails or a control attempt doesn't work out as hoped. Common configurations sucked up by multiple boxes that can be segregated off / switched to when something doesn't go as planned.

Let us know how it goes - we all face this, even in our own homes, if to a lesser extent that you do. Particularly as you are dealing with multiple disparate sites.

I suspect your first step is a proxy server. Implementation won't be easy or fun, but none of this is. Nor is it 100%, and the 80/20 rule applies. For every element you'll forever be chasing down exceptions.

But at least it will establish a control / monitoring point of the majority of the non-well known ports usage. And allow you to restrict vast swaths of ports at the firewall. Yes, torrent can also be tcp (but many other ends refuse to do tcp), but things like sip udp tend to occur in well known bands - letting you restrict all other udp. In essence the whitelisting and exception managing approach nobody wants to do, but I'm not sure there's much choice. At least at such point broad bands of ranges can be set, rather than each and every moving target of individual ip or port numbers.

The real advantage of the proxy is that it is more optimized for layer 4 evaluation, and in a less time sensitive situation, than most typical network points (firewalls, switches, routers).  It takes a lot of horsepower to keep up at those points == expensive. Letting you cordon off broad bands of ip / tcp / udp ranges in that equipment, while letting you decide which tcp/udp packets are acceptable for the smaller subset of traffic, at a less time sensitive point optimized for such processing.

- yes, there is browser torrent functionality out there, but I expect that those are still the exception, not the norm. And 80/20 applies. At least when you find such exceptions, users will have had to knowingly employ such avoidance measures - rendering any excuses much less valid. Taking even more of the technical out of what is ultimately a social issue. Leaving it up to those responsible for managing such issues, and not on your plate. Let them be the bad guys, not you.



----- Original Message -----
> From: Paul Nijjar <paul_nijjar at yahoo.ca>
> To: KWLUG discussion <kwlug-disc at kwlug.org>
> Cc: 
> Sent: Thursday, November 19, 2015 11:43 PM
> Subject: Re: [kwlug-disc] Blocking Bittorrrent
> 
> 
> To (belatedly) answer this question: We use social solutions to try
> and make sure people understand not to torrent traffic, or at least
> not to saddle the organization with Rogers EUAs. We had a particular
> user whom we could not identify, but who was getting us in trouble. My
> primary goal was to identify this person so this person would have a
> conversation with us. My secondary goal is to be evil by identifying
> torrents easily and either blocking them or blocking the people
> running the torrents from our network, so that they can get their own
> Internet connections and get Rogers EUA notices in their own name and
> not our organization's. 
> 
> My preference is not to take a whitelisting approach, but in the worst
> case this is what we might have to do. The immediate problem has been
> dealt with, but I know it will come up again, and it is frustrating
> that finding a way to block this traffic is so difficult.
> 
> Some people feel that the notice-and-notice system means that there
> are no consequences if people torrent on our network. I disagree.
> 
> Firstly there is the stress of getting the notices (and the danger of
> somebody clicking a link inside them, which will establish the
> connection between our organization and the would-be plaintiffs).
> 
> Secondly we are a bigger target than an individual illegally
> downloading seasons of Linux ISOs. 
> 
> Thirdly our VPN traffic has gotten mysteriously unreliable since these
> EUA notices. It is only a conspiracy theory at this point, but for all
> I know Rogers is engaging in some retaliatory traffic shaping and
> slowing down all our encrypted traffic now. That has big consequences
> and is a huge source of stress for me, because I cannot pinpoint what
> the problem is or how to fix it. That in turn makes other people grumpy.
> 
> 
> - Paul 
> 
> 
> On Mon, Nov 16, 2015 at 09:26:57PM -0500, Raymond Chen wrote:
>>  What is the purpose of doing this? To enforce fairness on bandwidth usage?
>>  Can you apply bandwidth limit for each IP? Or even make it smarter, enforce
>>  it only when bandwidth usage is almost full.





More information about the kwlug-disc mailing list