Ok, here's the situation:

I work for a county IT department.  We, along with some sponsors, set up a free wireless network that covers most of our downtown area.  Its use is relatively unrestricted.  We pretty much only log MAC addresses, make them click through a startup page with the terms of use info, and throttle them to 512kb.  Not super-fast, but better than dialup.

This program has been in place for a few years and has been a phenomenal success.  We do not monitor who and what goes on via that service, preferring to just leave it alone unless it breaks.

Fast forward to today.  It seems some assholes have been BitTorrenting via our free service.  First off, I dunno who in their right mind would try to BitTorrent over a 512kb link, but, ok whatever.  Our ISP has gotten some nasty-grams from the RIAA/MPAA and other folks and may pull the internet feed for our free service if we cannot get a handle on stopping BitTorrent traffic.

Here is a basic diagram of our free wireless network system:



The Cisco BBSM server is basically a hardened Windoze 2000 server box that controls the wireless network and functions as a basic firewall and router.  The WAP side is private IP, the outside is public IP.  The BBSM cannot do port blocking or content filtering.  Its feature set is very limited.

As I see it, we have two options:

1. Put a router/firewall between the BBSM and the ISP and limit traffic to only specific ports (20/21, 80, 443, RDP, etc.).

2. Figure out some free or low-cost layer 7 packet filtering that can recognize BitTorrent traffic and snuff it out.

So, what are your thoughts on this?  Can anyone recommend some other tactics or a low-cost solution to this?  I cannot just block the basic range of BitTorrent ports, as the new BitTorrent clients can use damn near any port they find open.

Thanks for any help.

Limiting the ports may or may not help, since you can always port forward and tunnel to a torrent site (though I don't torrent much so I'm not sure how the P2P works in their case.)

An IPS in between either the switch and the router, or the router and your isp could prob. do it.

ETA: Not sure if Snort can act as an IPS or only an IDS.  But TippingPoint makes IDS/IPS appliances.  Not sure what your budget it like though.

Good Luck!

Bittorrent is a remarkably adaptable protocol, that can function in very hostile environments.  It can be configured to run on just about any port, and doesn't require specific Port forwarding back over the NAT to the local hosts.  (Well, it is vastly more efficient and effective with port forwarding, but it will work without it.)

Today, you could use an IPS as the previous poster noted, to perform SPI (stateful packet inspection), or as it is known Deep Packet Inspection.  This allows the IPS to look at not just the source or destination of a packet, but actually look at the contents and say 'this is part of an ftp download of an image and is OK' or 'this is part of a bittorrent protocol handshake and should be dropped'.

HOWEVER, SPI and Deep Packet tools utterly fail on Encrypted traffic.  The payload is encrypted, so you can't look at it and make any meaningful conclusions.  It might be part of a Word document someone is uploading to a website, or a part of an MP3 they are sending to another BT client.  You can't tell.  All of the modern BT clients support Encryption now, so most of your 'abusers' would simply turn this on (if it isn't turned on already) and your IPS would have no choice but to let the traffic pass.

You can't block all encrypted traffic, btw, since that is quickly becoming very standard for many websites.  Any time you see SSL or HTTPS, that traffic would be encrypted.

There are some 'fuzzy' intelligent sensors that claim to detect the 'flow' of traffic to identify BT sessions, vs. other uses.  You can imagine this like standing by the highway and picking a funeral procession out of the mass of cars.  The pattern is distinctive.  However, these are by no means foolproof, they are in the early stages, and the BT clients are already implementing 'countermeasures' to alter their traffic patterns to bypass these devices' logic.

All in all, it is a serious problem.  The most common tactic I see these days is simply to cripple the Upload bandwidth.  The RIAA and MPAA are less concerned with people Downloading the files, than they are with the folks who are Uploading them and Actively Sharing content.  Most people using your WLAN network for average uses, could get by with a 512K DL, 128K UL, or even a 64K UL.  But this would make the link virtually useless for anyone looking to UL large quantities of RIAA/MPAA content.  They would probably look elsewhere for their connection.

Again, Good Luck!

FluxPrism

If you are logging MAC addresses, can you enhance your log to track applications use? port use? What additional information can you glean about your users?

You might also experiment with what ports you open at specific times of day.

TRG

So does/did AOL IM.

Good luck with that. It is almost impossible.

pfSense (free freebsd-based network security device software) has some really attractive traffic shaping features, and the price is right (free). it has a "penalty box" feature that allows people to operate normally at full speed, but if they consume too much tx/rx bandwidth within a given period of time they have their bandwidth severely crippled. even though they can switch ports and use encryption, block typical bittorrent ports. log all traffic and look for trends, what MAC addresses consume large amounts of bandwidth over time that is not genuine HTTP/VoIP/etc/etc traffic. i know they can spoof mac addresses, but at least they will be having to work at it.

many folks leave their bit torrent client running all the time, so when they wake their laptop to check mail, the torrent seeds and resumes any downloads...

Well, the BBSM has very limited capabilities in this regard.  Right now, I am exploring two options:

1. Using a pFsense box I built and see if I can use traffic shaping to deter BitTorrenting miscreants.

or:

2. Eliminate the BBSM and use an old Bluecoat content manger to handle all the logging, bandwith throttling, terms-of-use page, and content filtering.

Thanks for all your help, guys and gals.

Tag since I'm studying networking.

you could study the false torrent packets that comcast used to seed their network with...

Your options have pretty much been laid out. BT is a hardy protocol. Your best bet is to use BSD and prioritize normal and easily recognized traffic and put anything else on the "bandwidth leftovers" group.

Years ago I was part of a group trying to build layer 7 filtering into linux. It worked but sucked system resources pretty bad. It would inspect the first (by default) 8 packets of a connection and attempt to match it against a regex. From there you could perform whatever iptables functions on the connection or QoS it.

-Foxxz

That's interesting stuff.  Apparently it forges reset packets and inserts them.

Of course, the problem is that for any technology like this, an effective countermeasure will likely be developed.

The problem is identifying the BT traffic to begin with. If you could do that you could QoS it or whatever. That's exactly why the encryption was included to begin with.

-Foxxz