Flow Analytics P2P Monitor serves up humble pie

Posted in NetFlow Analyzer, Network Health Report, Network Problem Resolution, Network Traffic Monitor, Scrutinizer on June 29th, 2009 by Raul J Duran
flow-analytics-p2p-monitor-serves-up-humble-pie

A common problem for network administrators is when end users get in the habit of blaming the network for slowness on their workstations. For this reason it’s important for network administrators to not only prove, but sometimes disprove, issues with the network. Sometimes the issue is a combination of both.

Read more »

Tags: , , ,

P2P users can run but they can’t hide from Flow Analytics

Posted in Network Problem Resolution, Network Traffic Analysis, Scrutinizer on April 6th, 2009 by Raul J Duran
p2p-users-can-run-but-they-cant-hide-from-flow-analytics

As a field engineer for Plixer I do my fair share of training customers. I’ve found that the most effective and entertaining way of teaching the use of Scrutinizer is by getting right into the network and showing customers how I look for anything that appears out of place.

While reviewing the Flow Analytics Threats Overview gadget, I decided to drill into the P2P Monitor algorithm. As the customer is a well-known college  I had a feeling I would see something interesting here.

flow-analytics-threats-overview

When a user clicks on the P2P Monitor link, a new Scrutinizer alarm window pops up showing a list of hosts that are involved in network behavior resembling P2P traffic.

p2p-alarm1

One of the administrators said: “Hey… That right there is a workstation…” We immediately clicked on the user to see what kind of traffic this host was generating.

p2p-using-voip-ports1 What surprised me wasn’t the fact that this guy was abusing the college’s bandwidth by taking up about 1.5% of a gigabit link by himself, but how he was able to conceal his abuse by using a port range commonly used for VoIP, in an environment where VoIP isn’t out of the ordinary. This technique allowed the user to circumvent packet shapers and an ASA firewall with an IPS module. To add insult to injury, QoS has been implemented to give priority to VoIP so that others would have to take a back seat to this user’s illegitimate traffic use.

We have to remember that Flow Analytics is analyzing behavior, not just what ports are being used. What gave it away is that although VoIP traffic is not out of the ordinary on this link, the behavior of this VoIP traffic was.

If you look at the bottom of the list, you’ll see conversations using ports commonly reserved for VoIP being used in a way that is not consistent with normal end user VoIP traffic. For practical blogging purposes I had to cut off the report at 100 conversations, but there were several hundred conversations that were too small for real VoIP traffic.

I have to admit I got a kick out of this one. You can run, but you can’t hide from Scrutinizer and Flow Analytics.

Raul J Duran

Tags: , , , , ,