Normally HR and blocking would resolve it yes. But we have some R&D business requirements that prohibit me from strictly blocking it on the network. We do have a policy but HR needs a report with evidence that an offense occured.
This used to not be a problem. But as bittorrent evolves my tracking and reporting is becoming harder. And lets face it - A policy never stops bad behavior, it just gives you a tool to addres it. There is always one in the crowd....
I agree with Andy about this being a HR problem, but if you need to find the traffic with your Cisco routers, the easiest way would be with NBAR. I haven't tested it, but something like this should work:
class-map match-all CM_BITTORRENT
match protocol bittorrent
drop <-- note that this drops it, which I guess isn't what you want
ip nbar protocol-discovery
service-policy output PM_DROP_BT
You could also use the same technique to rate limit it (use the "police" feature in the policy-map).
Or if you just want to make it visible to NetFlow you could mark it with some special DSCP value ("set ip dscp af11" or something similar in the policy-map) and then use that DSCP to report on it in NTA. In this case, you would need to mark the traffic before it reaches the NetFlow export process. You might be able to do this by changing the service policy direction to "input" on the inbound interface; I don't know whether NetFlow export or marking comes first in the interface process chain.
Note that NBAR will increase your CPU utilization somewhat on your routers; test first, don't blow up your network, etc.
I just realized I should add an explanation of why plain vanilla NetFlow won't work:
Because BitTorrent uses lots of different port numbers, NetFlow doesn't have a way to classify it and report on it natively. Some high-end NetFlow collectors (Plixer, Lancope) have heuristic analysis that claims to be able to identify BitTorrent post hoc based on meta-analysis of flow data, but NTA doesn't have this.
The Cisco IOS NBAR feature, on the other hand, does deep-packet inspection to identify applications that can't be identified solely on layer 3 and layer 4 information. You can then use policy-map logic to manipulate the traffic as shown above, and you can use the "show ip nbar protocol-discovery ?" suite of commands at the CLI to get details on what it figures out.
To get data from NBAR into NetFlow, you have to add a marker that NetFlow understands: the DSCP value. Just make sure you use a DSCP that's not assigned to something else in your network.
Depending on what other applications are running on your network you may be able to get some level of visibility by creating a report which looks at any local clients connecting to external hosts on high destination port numbers. Protocols like BitTorrent typically use high port numbers.
Failing that you could look at doing deep packet inspection on your Internet gateway. The output of your DPI tool could be displayed within Orion. You can see an example of this by following this link. Look at the element on the bottom right of the dashboard. http://demo2.netfort.com/Orion/SummaryView.aspx?viewid=31
Coincidently I am also running a three part series on BitTorrent on my blog and part III coming up next week looks at ways for detecting it on networks http://blogs.computerworld.com/delaney
Have you given languardian a go? After a long battle with torrents, Languardian from netfort was the only solution that had a report showing the torrent transactions.
So i could see who downloaded or uploaded what, and use that information as evidence.
We are getting those violations as well, and all we have to do is feed languardian the hash, and we get the internal IP of the abuser. I beleive if you integrate it with you LDAP (which we did not do) then you would get the username.
It also integrates nicely with Orion.
I hope this helps.