utorrent not being blocked

[dmorris]

I think we just got trolled.

[sky-knight]

Too bad my post was a minute late... it would have been so much better if all three of us were a nice 2min apart.

[Specialsit]

how do i upload a image?

[Specialsit]

heres a screenshot of my untangle with utorrent running its not being blocked

[sky-knight]

It will not block it, the bittorrent signature has been unable to block all torrent traffic in forever. All modern torrent clients mask their traffic using a variety of techniques.

The protocol control module for this purpose is only useful for logging internal clients with running torrent software. If you want to halt the torrents from that device, create a firewall rule to block all traffic.

[RatKnight]

So, basically the problem comes down to the fact that there are no recent additions to the Protocol database? I noticed from the L7 sourceforge page that the most recent database is from July of last year, does anyone know if it is even developed anymore?

[jcoehoorn]

No. Protocols just don't change as much relative to the software that's built on top of it. The issue is that bittorrent is adaptive. If the first attempt is blocked, it will adapt and try something. And if that's blocked, it will adapt and try again. The entire protocol is designed to evade this kind of thing.

[RatKnight]

Okay, that makes sense, especially considering what I saw while I was testing yesterday.

I blocked the protocols, and initially utorrent could not get out. However, after about 3 minutes, it started to get 5 kb/s, then dramatically started climbing. I am trying to figure out a way to block 2 things:

Trackers
DHT

Anyone have a thought about this? I will probably start a new topic in the firewall area, so plz disregard.

Thanks

[jcoehoorn]

For the trackers, there actually aren't that many out there (relatively speaking), they need to be relatively stable, and even when they aren't your users still have to be able to find them. So it's not that hard to just play whack-a-mole with the block list in web filter or esoft.

But our strategy here revolves more around a honey-pot scheme. We use protocol control to log, but not block, all the p2p protocols. We also set the common p2P ports for the low priority QoS queue. So the traffic will get through on the first try, but we'll know about it and it's running slower.

From there, examination of the reports each day tells me who my offenders are. Depending on what I see, these people either have all their traffic set for the low priority QoS queue, get restricted in the firewall app to only pass traffic on ports 80, 53, 443, 993, 995, 465, 587, and 1935, get called to my office (or a dean's office), or some combination of the above.

This has mostly worked. The only problem is that the low priority QoS queue prior to 8.0 is not restrictive enough. We're holding off on the 8.0 upgrade until semester break, but I'm looking forward to the new enhanced QoS features.

I'm also looking into using Captive Portal to help augment this strategy. The plan is to start using it next semester with a 1 day timeout period for authentication. But I'm hoping to have a script ready that will run as a cron job periodically and break the authentication for users I've identified as file sharers. Then all their traffic, including bittorrent/p2p, will be blocked unless they are physically present at their computer to re-authenticate every hour or so. But my concern here is that it will have the same result as using protocol control-- the client will keep trying again so much it ends up as an effective local denial of service attack on the untangle server.

[RatKnight]

I considered using the captive portal in the same way, the issue with that is that it is forcing this on university computers, as well as personal computers plugged into the wall, or on our wireless.

I might give the "log and nuke" (which is what I am calling the packet shaping idea) a go. Log the ports they are going out on, and nuke em as I find them.

Thanks