Recognizing and responding to potential threats at an early stage is essential for companies of all sizes. Sometimes, strange behavior of your network indicates the need for an investigation. In the root cause analysis process, you may see some traffic flows like high bandwidth patterns that seem suspicious, but you don’t know if it is normal behavior or an attack pattern.

At this point, network baselining comes into play. With network baselining, you capture network traffic over a period of time in a normal situation in your network. You can only verify if there is an anomaly if you know the baseline. In baselining, we define profiles of the characteristics of a communication network. These profiles are based on the traffic metrics collected on the network with the IOTA network traffic capture and analysis solution.

Traditional methods of capturing network traffic, such as legacy hardware and software like a notebook with Wireshark, are not practical for network baselining due to the extensive timeframes required to collect all specific traffic patterns in the network. The sheer volume of traffic and the need for appropriate interfaces further complicate the process.

Moreover, capture performance is a critical challenge when collecting traffic for network baselining. Legacy tools and approaches often struggle to keep up with high speeds and high volumes of network traffic, resulting in dropped packets, incomplete captures, and unreliable data. This can significantly impact the accuracy and completeness of the baseline, leading to false positives or missed issues.

Once captured, the network data needs to be analyzed efficiently. Graphical interfaces with dashboards give you a quick overview, and the ability to drill down into specific flows.

Specialized capture and analysis appliances like Profitap IOTA help tackle all these challenges.

To start a network baseline, you must decide if you want to baseline a whole network, a specific endpoint, or a particular application. You also need to define a timeframe for baselining. There’s no “one size fits all” for the correct timeframe. It depends on your applications. You need to capture every possible situation in your network. So if you have continuous traffic flows, like web and e-mail traffic, as well as Voice over IP and file server access in your daily traffic, but also weekly backup jobs, you need to capture the whole week to see all the patterns in your network.

As a next step, you need to define where to capture. Where you place IOTA depends on what kind of baselining you're doing. If you want to baseline only one client or server in your network, you can place IOTA directly between the switch and the client or server.

You can capture whole networks at central switches or try a SPAN port from VLANs to your IOTA. You can place IOTA in-line between your switches and the WAN router to baseline your WAN traffic.

Figure 1: IOTA placement in-line between client and switch.

We can use the Overview dashboard in IOTA to get a global overview of network traffic patterns. We get a first look at our IP-based traffic patterns. Lines between IP addresses mean that at least one communication flow exists between these two IP addresses.

Figure 2: Overview dashboard with IP-based communication patterns.

We can hover over the IP addresses to highlight corresponding communication patterns.

Figure 3: Hover over the IP addresses to highlight corresponding communication patterns.

A filter of the hovered address can be applied with a simple mouse click on the IP address. This filter is applied as an “IP” filter at the top of the dashboard.

Figure 4: Filtered IP relationships based on a specific IP address.

The Overview dashboard also provides a flow list with layer 4 protocol information like UDP or TCP and client and server port information in conjunction with recognized applications. We can click on the magnifying glass in the inspect column if we need to go deeper into a suspect flow for more flow details.

If we need to look at payload data in Wireshark or another packet analysis application, we can download the corresponding flow as a filtered PCAPNG file by clicking the arrow button in the download column for further analysis.

Figure 5: List of Flows on the Overview dashboard.

Network utilization is also an important metric in baselining to get a feel for abnormal utilization. We should know the average and normal peak values in our network. In specific situations, we need to know them as a whole for our network, but in other situations, we need them for specific clients or servers and some specific applications.

Some high-volume patterns we can see as peaks are expected because of backup traffic or file transfers. To help analyze network utilization, IOTA provides a specific Bandwidth dashboard. To get there, we click the “Navigate” button in the upper right corner and select “Bandwidth”.

Figure 6: Navigate to the Bandwidth dashboard.

On this dashboard, we can see the average bandwidth usage per direction. The red line represents outbound traffic, and the blue line represents inbound traffic. On the upper right side, we get information about the total byte and packet count in the selected timeframe. Just below, we can find peak bandwidth usage per direction. In conjunction with security, this can help us evaluate if we are experiencing a volumetric DoS or DDoS attack.

Figure 7: Global Average and Peak Bandwidth values on Bandwidth dashboard.

To differentiate normal application behavior from resource exhaustion attacks, we need bandwidth per application, normal flow count, and transmitted bytes in a specific timeframe. A high flow count can point to a resource exhaustion attack, like attempting to reach maximum packets per second on a firewall.

Here, we need to switch to the Application Overview dashboard.

Figure 8: Navigate to the Application Overview dashboard.

This dashboard shows a graphical overview and sorted bandwidth usage per application. To investigate a specific application further, we can click the download button to the left of the application in the Application Overview table to download all related traffic known for this application type.

Figure 9: Bandwidth and flow count by application.

Under DoS or DDoS attacks, the network latency increases before services become unreachable. This means we need to know normal server latencies to differentiate normal latency values from higher values under attack conditions. We can find the Latency overview by Server IP under the Application Overview dashboard with the minimum, average, and maximum values.

Figure 10: Latency Overview per Server IP.

We can scroll down on the Bandwidth dashboard to get a feel for bandwidth usage per client and server. We get information about bandwidth usage per client and can sort by top talkers on the right side. In the table below, we can also see naming information corresponding to these clients and transmitted payload data in the selected timeframe.

Figure 11: Bandwidth usage by client.

To recognize new clients or servers in the network, we need a baseline with known good or trusted hosts. We also need to correlate correct IP addresses to their MAC addresses to find possible IP spoofing attacks when they occur.

In some organizations we can find this data in inventory databases or Network Access Control systems, but if we don’t have this data, we can get it by baselining with IOTA. To accomplish this, we can navigate to the Local Assets dashboard.

Figure 12: Navigate to the Local Assets dashboard.

This dashboard displays a client and server inventory list with their IP and MAC addresses as well as DHCP hostnames and OS names if DHCP service is used and OS is recognized by IOTA.

Figure 13: Local Assets dashboard.

Some attackers try so-called downgrade attacks to transport encrypted traffic like TLS. IOTA allows to baseline used TLS versions per server and evaluates ciphers, and categorizes them as safe, weak, and unsafe per server.

First, we need to navigate to the SSL/TLS Overview dashboard.

Figure 14: Navigate to the SSL/TLS Overview dashboard.

By baselining the TLS version and cipher category data and comparing them later, we can easily find possible downgrade attacks by looking for switches from a safer to a weaker TLS category. This can be from TLS 1.3 with DHE ciphers to TLS 1.1 without forward secrecy.

Under SSL/TLS Servers, we can see the used TLS version in the Versions column and the category of cipher under the configuration column. We can also see the Alerts ratio to recognize potential attacks to TLS handshakes.

Figure 15: SSL/TLS Overview Dashboard, including TLS versions and cipher categories.

When conducting network baseline analysis, detecting patterns of anomalous connection attempts is essential. As discussed in the “IP-based flows and protocol usage” section, we can baseline communication patterns in the Overview dashboard. This enables us to detect port scanning activity by finding a host that communicates to all other hosts in a specific subnet or multiple subnets.

Port scanning can be a precursor to more advanced cyber-attacks by identifying vulnerable services or systems within a network. So, in baselining, we need to identify hosts that normally communicate with a lot of other hosts, like domain controllers, DNS, or backup servers.

We should also identify failed TCP handshakes in baselining. At first, this can help us to see wrong behavior in our typical network and correct it. In the second stage, we can differentiate them from malicious actors, which try to exhaust resources like maximum sessions in firewalls with so-called SYN flood attacks, which lead to TCP half-open states.

Half-open means that the three-way handshake is not completed. We can see incomplete three-way handshakes in the TCP Analysis dashboard. We can see them in the right column called “TCP Analysis” with the statement “Incomplete 3-way” and under TCP-Events as “Unanswered SYN”.

Figure 16: TCP Analysis dashboard with an abnormality.

We should baseline the number of connection attempts or new flows in a specific timeframe. In the Overview dashboard, we can see spikes in connection attempts in the New Flow/s graph. Seeing spikes exceeding normal behavior could indicate a potential attacker trying to access a lot of systems, such as trying to distribute malware. This also can indicate botnet activity.

Figure 17: Number of connection attempts.

IOTA provides several filters, which can be combined using “AND” and “OR” relations. From a security perspective, filtering on long-lived flows to other countries can be interesting because it could be command-and-control traffic. In our example below, we filtered on flows with more than 1000000 milliseconds duration and which destination IP address is outside of the Netherlands. IOTA allows us to combine it with a logical “or” filter.

Figure 18: Combination of Flow Duration and Destination Country filter.

Our simplest but most effective filters are IP-based filters on a single IP address, regardless of source or destination. We can simply type them next to “IP” on our dashboards. If we want to filter specifically on the source or destination IP address, we can filter on “ip_src” or “ip_dst”.

Figure 19: Filter on simple IP addresses, regardless of source or destination.

If we take a deeper look at our security, we can filter on TLS versions offered by Client or Server lower than the current recommended version TLSv1.2 with “tls_client_version” or “tls_server_version” with a lower than filter and version “TLSv1.2”.

Figure 20: Filter based on TLS Client Version lower than version 1.2.

It’s also possible to filter specific TCP Analysis behavior in the TCP Analysis dashboard. We can filter on incomplete three-way handshakes based on the “TCP Analysis” filter and value “Incomplete 3-way”.

Figure 21: Filter based on incomplete three-way handshakes.

Baselining networks helps differentiate malicious from normal behavior. IOTA makes time-consuming tasks, such as understanding traffic patterns in a network, easy and provides the necessary high capture accuracy. IOTA helps capture all traffic patterns over a specific period of time as needed and effectively and graphically analyze them with flexible filters.