Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Using Netflow to catch an office pirate

I have a serial pirate downloader. I'm getting the DMCA notificaitons from the industry guns weekly. I can't completely block torrent traffic at my firewall for business reasons. My web filter isnt reporting on the traffic because I believe the user has a client installed. The IP port its using is all over the place.

Ive changed my ASA firewall syslog setting to report details (5-notifications) but based on trafffic usage my syslog is enormous and basically unreadable so this option isnt working well.

The traffic traverses through the routers with netflow so can I use netflow to catch this traffic and report it somehow?

Find more posts tagged with

Accepted answers

All comments

mcbridea

Is this in violation of your company policy? Typically a memo for management letting the office know that we are detecting this activity and it must stop immediately works. Tracking port hopping is very difficult. In other words, attack the issue at layer 8.

jswan

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

policy-map PM_DROP_BT
class CM_BITTORRENT
drop <-- note that this drops it, which I guess isn't what you want

interface outbound_interface_here
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.

jswan

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.

witkopstaub

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....

witkopstaub

Thats a really good explanation - thanks! Makes a bit more sense to me now. I am looking at what NBAR might do for me and the policy you sent.

darragh.delaney

Hi There,

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. demo2.netfort.com/.../SummaryView.aspx

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 blogs.computerworld.com/delaney

bkattan

Hello,

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.