Traffic Analyzers: What do they do and how are they used?

When we are faced with a performance problem related to those responsible for the applications and those responsible for the network platform, we usually think about how useful it would be to have a traffic analyzer that clarifies the real origin of the problem.

Now, many times we see network analysts who after installing the tool feel overwhelmed by the amount of information it offers them.

Since an analyzer can capture an enormous quantity of packets, it can show us their headers, it can offer us facilities, it can make multiple filters, it can show us graphs about the most referenced elements, statistics about total traffic, quantity of errors and so on.

At that point it is logical to ask ourselves: “And now what should I do?”

The answer is: “Now it’s time to do traffic analysis.” And we realize that analyzers make analysis possible, but we must do the analysis.

In this article we invite you to review how a traffic analyzer works, and how you can make the captures and then plan a series of strategies for the following steps.

What do traffic analyzers do?

Traffic analyzers can do many things. including:

Capturing and storing layer 2 frames and packages associated with higher levels. In this article we will use the term package to refer to both frames and packages.
They allow to define parameters that will govern the capture of packages; for example, they allow us to capture only the packages that have the same destination IP address, the same source MAC address, the same protocol, etc.
They allow undertaking a data capture when a given condition arises. For example, you start capturing when you observe packets with a specific destination MAC address.
They identify the protocol associated with each packet and carry out the decoding of the packet headers according to the corresponding protocols.
They offer an interface by means of which the traffic analyst will be able to visualize and manipulate the decoded packets.
They present as errors those packages with unusual characteristics: too small, too large, with erroneous FCS (Frame check sequence) or CRC (cyclic redundancy check), etc.
They generate statistics that they extract from the captured packages. For example, list of the 10 computers with the most network traffic, list of protocols organized by the amount of traffic, list of the conversations with the greatest amount of traffic, identifying the source address and the destination address, etc.
They offer search facilities within a packet capture; we can do searches by destination IP address, by protocol, by subprotocol, by a specific sequence of bytes, etc.

Clarifying the subject of the capture

In hub-based networks, the analyzer was connected through a network card that only allowed it to capture the packets that were addressed to all the computers in the network or all the computers in a segment, that is, the Broadcast and Multicast packets. .

How could we capture all the packets that passed through the hub? For this, network cards were developed that could work in “promiscuous mode”.

However, this solution did not work if the network was implemented with a switch computer.

The problem was then finished by creating mirror or SPAN ports in the switches, which copy all the packets that pass through a port or group of ports and copy them to another port that was reserved for the packet analyzer.

The SPAN ports are an interesting solution, but they have some disadvantages:

At the performance level, they mean an additional workload for the switches.
At the operational level, they can filter some packages with errors and they are not relevant if at the point where we want to capture a switch is not found or the switch does not support the creation of SPANs ports.

Another option is represented by hardware devices known as TAPs (Terminal Access Point), which access traffic between two network points and copy it in a port where the traffic analyzer should be integrated.

We invite the reader interested in the topic of the TAPs to review this post.

Clarifying the issue of data security

Anyone can assume that traffic analyzers can show the data of the package and with it sensitive information of the user and the organization.

At this point we must clarify that traffic analyzers usually do not decode the part of the packet that corresponds to the data, but decode only the headers.

The dark side of the analyzers

The technology associated with traffic analyzers can be used by intruders to detect:

Vulnerabilities of the platform that can explode when perpetrating an attack; things like a list of applications and services, including their versions.
The way to extract sensitive information from the company or private users; data such as user profile, credentials, location, web pages visited, etc.

Other attackers can get traffic through other means (by applying a man-in-the-middle technique, spying on wireless networks, applying scripting or with fake Proxys and VPN) and then using traffic analyzers to extract the desired information.

Deep packet inspection

The terms package analysis, traffic analysis and protocol analysis present subtle differences between each other. However, in practice these differences end up being diluted.

However, the termdeep packet inspection” is a different case and is well worth a brief clarification.

This technique differs from traffic analysis in two crucial points:

Unlike those made by traffic analyzers, a deep inspection contemplates the decoding of the data portion.
While traffic analyzers try not to affect or minimize network traffic, tools that do deep packet inspection aim to exercise an action on traffic.

We can think of deep inspection tools as a mix between a firewall and a traffic analyzer.

Strategies to do traffic analysis

With regard to traffic analysis there are two ways to assume it; One of them is the verification of the general state of the platform and the other is the monitoring of specific problems.

Although the reader may find them obvious, we bring them up because these positions have generated a debate among traffic analysts, even reaching a division.

On the one hand, there are those who consider that reviewing the general state implies an excessive expenditure of resources that is not compensated by the benefits in terms of optimization of the platform.

On the other hand, there is another group that does give importance to this type of review and promotes it.

Personally, I am one of those who promote the revision of the general state because I believe in its benefits; in fact, in this blog I published an article about the optimization of platforms eliminating Broadcast traffic, activity that can and should be done whether or not we have a performance problem.

The reader can read the article following this link.

Also, I think we should use traffic analysis to solve those technical cases that are recurrent, that face the group of applications with the platform group or that involve data security risks.

I let the reader choose a side, and integrate a good traffic analyzer in his/her tool kit to do both one thing and the other.

In any case, below we present a list of strategies that can be applied and that cover both forms of work:

Review your monitoring scheme: and the platform has a monitoring platform based on a tool such as Pandora FMS, the idea is to integrate the traffic analysis to the activities of monitoring, optimization and resolution of problems.Keep in mind that Pandora FMS has an extensive set of facilities like network monitoring, monitoring of applications and, crucially, an entire alarm system.
To understand the scope of these facilities les we invite you to review the following link.

In any case, the integration could be like this:

The traffic analysis processes can be motivated by an error condition identified by the monitoring system.

All learning about the platform that can be extracted from the traffic analysis can be used to adjust the settings of the monitoring scheme.
Establish general review procedures and audit activities: andlimit all surplus protocols, minimize the amount of Broadcast and Multicast traffic, evaluate deviations, such as physical errors that generate surplus traffic.Include in your daily activities all preventive evaluations using the traffic analyzer, how to estimate the traffic that will be generated over the network by including a new application, for example.
Integrate traffic analysis into your regular network audit activities.
Choose support cases: andit’s obvious to say, but not all support cases merit traffic analysis; therefore, it is necessary to choose well.We recommend those that are recurrent, that face the development group with the platform group, those that revolve around the overall performance of the platform or the particular performance of an application or service.
Evaluate the symptoms of the given problem: Sometimes, when choosing a problem and beginning to evaluate it, we usually come across a group of symptoms or conditions for which, in general, it is difficult to obtain a common cause that justifies them.To avoid dispersion, we recommend that you choose one of the symptoms, if possible the main one, and concentrate on the research associated with that single symptom.
Identify the traffic you want to evaluate: identifying the packages you want to evaluate can become a challenge, since:
1. No matter how accurate our catches are, they will usually bring more traffic than we’re interested in.
2. Many error cases are difficult to reproduce.
To face this challenge there are some techniques to specify the traffic that interests.

One of them is to install, in the user’s computer that suffers the symptom that we are evaluating, a script with a continuous ping command to a server and ask the user to execute the command during the time that the failure occurs.

Thus we will have a mark of the spectrum of traffic that we must evaluate.
Matching the clocks: animportant point is to match the clocks of all the elements involved in the research that is being madeor. In this way we can, for example, correlate the traffic with entries in the logs files of a server.
It is good practice to conserve catches and document the analysis process, its results and key catches so that the case can be consulted in future research.In addition, it is interesting to report their findings and the corrections implemented to the related groups and to the group that manages the monitoring platform, so that an intonation of the same can be made if necessary.