Catching the torrent guy
December 10th, 2008 | by Andraz Piletic |It had been months since the NIL Monitor group first noticed that a customer’s remote location was experiencing suspiciously high traffic every night. The traffic started every day at around 8 p.m. and stopped twelve hours later, at 8 a.m. Due to high traffic in both inbound and outbound directions, my first guess was that the traffic had to be connected to some sort of P2P activity. The customer was notified about the detected anomaly in the network, but responded that this traffic pattern was normal for this location because backups were being made every night.
Despite my dissatisfaction with this explanation, I was forced to move on to other, more important cases, but I couldn’t really forget about it. After successfully dealing with a PC that had become a spammer, my attention was brought back to the location when high traffic was detected throughout the day on a work-free holiday. I decided to inspect the traffic characteristics further.
The traffic appeared from a LAN PC for which port forwarding was really configured on a router. But the traffic didn’t appear on that port. More than 2,000 network address translations were in place, most of them using unfamiliar high ports. Still suspicious about P2P protocols, I filtered the output with the P2P protocol’s default ports. The output from the command #show ip nat translations | include :6881 displayed (out of those 2,000 entries) only 12 connections that matched my filter criteria—but that was enough for my predictions to be proved accurate.
By using built-in schedulers, users can quickly set traffic to appear only in non-work hours
Most of today’s BitTorrent clients support advanced schedulers that enable users to configure at what time of the day traffic should be present. Although the LAN user was also using a randomly chosen high port, the BitTorrent client made some connections to other users, which used the protocol’s default ports. That gave me solid proof about what type of traffic was really passing the router.
Though the BitTorrent user didn’t interrupt daily workflow, such network behavior is not acceptable for most companies. Therefore, the company was notified once again; to their delight (and my satisfaction), the torrent guy was cut off from the network. How do you fight against such users in your network?
3 Responses to “Catching the torrent guy”
By danail.petrov.gmail.com on Dec 17, 2008 | Reply
And how exactly did you do that? I mean, what techniques have you used? Have you defined well-known ports within some port-range interval or just using nbar (which actually does the same) to achieve this?
Kind regards,
Danail Petrov
By Andraz Piletic on Dec 17, 2008 | Reply
In most cases, our attention is brought to certain location by triggered alarms, when high CPU utilization or RAM instability appears due to higher network utilization. After that, manual analysis reveals what is really going on.
In the described example, the user running torrents was caught by manual observation of ip nat translations. As described above, the command output was filtered with well know default ports for peer-to-peer protocols and few matched.
If you’re looking for a method how to scan hundreds of locations for illegal peer-to-peer activities, key is not only to block connections attempt to default ports but to detect such attempts and then use such information for further measures.
Although NBAR is not my specialization, as far as I can tell, you could match traffic destined for default ports using class-map. But simply dropping it is not enough since such connections represent just a small part of all p-2-p connections. But even if you successfully configure alerting when you classify such traffic, I am pretty sure it’s only a matter of time when torrent clients will have build in function to avoid connections on default ports.
After that you’re left with nothing but to monitor your network and search for anomalies among other parameters. I’ll describe one of them in the following post, so make sure you stay tuned.