Network Protocol Analyzers

How to Perform TCP SYN Flood DoS Attack & Detect it with Wireshark - Kali Linux hping3

2018-10-01T09:01:17+10:00

This article will help you understand TCP SYN Flood Attacks, show how to perform a SYN Flood Attack (DoS attack) using Kali Linux & hping3 and correctly identify one using the Wireshark protocol analyser. We’ve included all necessary screenshots and easy to follow instructions that will ensure an enjoyable learning experience for both beginners and advanced IT professionals.

DoS attacks are simple to carry out, can cause serious downtime, and aren’t always obvious. In a SYN flood attack, a malicious party exploits the TCP protocol 3-way handshake to quickly cause service and network disruptions, ultimately leading to an Denial of Service (DoS) Attack. These type of attacks can easily take admins by surprise and can become challenging to identify. Luckily tools like Wireshark makes it an easy process to capture and verify any suspicions of a DoS Attack.

Key Topics:

There’s plenty of interesting information to cover so let’s get right into it.

How TCP SYN Flood Attacks Work

When a client attempts to connect to a server using the TCP protocol e.g (HTTP or HTTPS), it is first required to perform a three-way handshake before any data is exchanged between the two. Since the three-way TCP handshake is always initiated by the client it sends a SYN packet to the server.

The server next replies acknowledging the request and at the same time sends its own SYN request – this is the SYN-ACK packet. The finally the client sends an ACK packet which confirms both two hosts agree to create a connection. The connection is therefore established and data can be transferred between them.

Read our TCP Overview article for more information on the 3-way handshake

In a SYN flood, the attacker sends a high volume of SYN packets to the server using spoofed IP addresses causing the server to send a reply (SYN-ACK) and leave its ports half-open, awaiting for a reply from a host that doesn’t exist:

In a simpler, direct attack (without IP spoofing), the attacker will simply use firewall rules to discard SYN-ACK packets before they reach him. By flooding a target with SYN packets and not responding (ACK), an attacker can easily overwhelm the target’s resources. In this state, the target struggles to handle traffic which in turn will increase CPU usage and memory consumption ultimately leading to the exhaustion of its resources (CPU and RAM). At this point the server will no longer be able to serve legitimate client requests and ultimately lead to a Denial-of-Service.

How to Perform a TCP SYN Flood Attack with Kali Linux & hping3

However, to test if you can detect this type of a DoS attack, you must be able to perform one. The simplest way is via a Kali Linux and more specifically the hping3, a popular TCP penetration testing tool included in Kali Linux.

Alternatively Linux users can install hping3 in their existing Linux distribution using the command:

# sudo apt-get install hping3

In most cases, attackers will use hping or another tool to spoof IP random addresses, so that’s what we’re going to focus on. The line below lets us start and direct the SYN flood attack to our target (192.168.1.159):

# hping3 -c 15000 -d 120 -S -w 64 -p 80 --flood --rand-source 192.168.1.159

Let’s explain in detail the above command:

We’re sending 15000 packets (-c 15000) at a size of 120 bytes (-d 120) each. We’re specifying that the SYN Flag (-S) should be enabled, with a TCP window size of 64 (-w 64). To direct the attack to our victum’s HTTP web server we specify port 80 (-p 80) and use the --flood flag to send packets as fast as possible. As you’d expect, the --rand-source flag generates spoofed IP addresses to disguise the real source and avoid detection but at the same time stop the victim’s SYN-ACK reply packets from reaching the attacker.

How to Detect a SYN Flood Attack with Wireshark

Now the attack is in progress, we can attempt to detect it. Wireshark is a little more involved than other commercial-grade software. However, it has the advantage of being completely free, open-source, and available on many platforms.

In our lab environment, we used a Kali Linux laptop to target a Windows 10 desktop via a network switch. Though the structure is insecure compared to many enterprise networks, an attacker could likely perform similar attacks after some sniffing. Recalling the hping3 command, we also used random IP addresses, as that’s the method attackers with some degree of knowledge will use.

Even so, SYN flood attacks are quite easy to detect once you know what you’re looking for. As you’d expect, a big giveaway is the large amount of SYN packets being sent to our Windows 10 PC.

Straight away, though, admins should be able to note the start of the attack by a huge flood of TCP traffic. We can filter for SYN packets without an acknowledgment using the following filter: tcp.flags.syn == 1 and tcp.flags.ack == 0

As you can see, there’s a high volume of SYN packets with very little variance in time. Each SYN packet shows it’s from a different source IP address with a destination port 80 (HTTP), identical length of 120 and window size (64). When we filter with tcp.flags.syn == 1 and tcp.flags.ack == 1 we can see that the number of SYN/ACKs is comparatively very small. A sure sign of a TCP SYN attack.

We can also view Wireshark’s graphs for a visual representation of the uptick in traffic. The I/O graph can be found via the Statistics>I/O Graph menu. It shows a massive spike in overall packets from near 0 to up to 2400 packets a second.

By removing our filter and opening the protocol hierarchy statistics, we can also see that there has been an unusually high volume of TCP packets:

All of these metrics point to a SYN flood attack with little room for interpretation. By use of Wireshark, we can be certain there’s a malicious party and take steps to remedy the situation.

Summary

In this article we showed how to perform a TCP SYN Flood DoS attack with Kali Linux (hping3) and use the Wireshark network protocol analyser filters to detect it. We also explained the theory behind TCP SYN flood attacks and how they can cause Denial-of-Service attacks.

How to Detect SYN Flood Attacks with Capsa Network Protocol Analyzer & Create Automated Notification Alerts

2018-09-18T22:40:03+10:00

This article explains how to detect a SYN Flood Attack using an advanced protocol analyser like Colasoft Capsa. We’ll show you how to identify and inspect abnormal traffic spikes, drill into captured packets and identify evidence of flood attacks. Furthermore we’ll configure Colasoft Capsa to automatically detect SYN Flood Attacks and send automated alert notifications .

Denial-of-Service (DoS) attacks are one of the most persistent attacks network admins face due to the ease they can be carried out. With a couple of commands, an attacker can create a DoS attack capable of disrupting critical network services within an organization.

There are a number of ways to execute a DoS attack, including ARP poisoning, Ping Flood, UDP Flood, Smurf attack and more but we’re going to focus on one of the most common: the SYN flood (half-open attack). In this method, an attacker exploits the TCP handshake process.

In a regular three-way TCP handshake, the user sends a SYN packet to a server, which replies with a SYN-ACK packet. The user replies with a final ACK packet, completing the process and establishing the TCP connection be established after which data can be transferred between the two hosts:

However, if a server receives a high volume of SYN packets and no replies (ACK) to its SYN-ACK packets, the TCP connections remain half-open, assuming natural network congestion:

By flooding a target with SYN packets and not responding (ACK), an attacker can easily overwhelm the target’s available ports. In this state, the target struggles to handle traffic which in turn will increase CPU usage and memory consumption ultimately leading to the exhaustion of its resources (CPU and RAM). At this point the server will no longer be able to serve legitimate clients requests and ultimately lead to a Denial-of-Service.

Detecting & Investigating Unusual Network Traffic

Fortunately, there are a number of software that can detect SYN Flood attacks. Wireshark is a strong, free solution, but paid versions of Colasoft Capsa make it far easier and quicker to detect and locate network attacks. Graph-oriented displays and clever features make it simple to diagnose issues.

As such, the first point of call for detecting a DoS attack is the dashboard. The overview of your network will make spikes in traffic quickly noticeable. You should be able to notice an uptick in the global utilization graph, as well as the total traffic by bytes:

Click to enlarge

However, spikes in network utilization can happen for many reasons, so it’s worth drilling down into the details. Capsa makes this very easy via its Summary tab, which will show packet size distribution, TCP conversation count, and TCP SYN/SYN-ACK sent.

In this case, there’s an abnormal number of packets in the 128-255 range, but admins should look out for strange distributions under any heading as attackers can specify a packet size to suit their needs. However, a more telling picture emerges when looking at TCP SYN Sent, which is almost 4000 times that of SYN-ACK:

Click to enlarge

Clearly, there’s something wrong here, but it’s important to find the target of the SYN packets and their origin.

There a couple of ways to do this, but the TCP Conversation tab is easiest. If we sort by TCP, we can see that the same 198-byte packet is being sent to our victim PC on port 80:

Click to enlarge

After selecting one of these entries and decoding the packets, you may see the results below. There have been repeated SYN packets and the handshake isn’t performed normally in many cases:

Click to enlarge

The attack becomes most clear when viewing IP Conversation in Capsa’s Matrix view, which reveals thousands of packets sent to our victim PC from random IP addresses. This is due to the use of IP spoofing to conceal their origin. If the attacker isn’t using IP spoofing, Capsa’s Resolve address will be able to resolve the IP address and provide us with its name. If they are, finding the source is likely far more trouble than it’s worth:

Click to enlarge

At this point, we can be certain that an SYN flood attack is taking place, but catching such attacks quickly really pays. Admins can use Capsa’s Alarm Explorer to get an instant notification when unusual traffic is detected:

A simple counter triggers a sound and email when a certain number of SYN packets per second are detected. We set the counter to 100 to test the functionality and Capsa immediately sent us an alert once we reached the configured threshold:

Capsa also lets users set up their own pane in the dashboard, where you can display useful graphs like SYN sent vs SYN-ACK, packet distribution, and global utilization. This should make it possible to check for a SYN flood at a glance when experiencing network slowdowns:

Alternatively, Capsa’s Enterprise Edition lets admins start a security analysis profile, which contains a dedicated DoS attack tab. This will automatically list victims of an SYN flood attack and display useful statistics like TCP SYN received and sent. It also allows for quick access to TCP conversation details, letting admins decode quickly and verify attacks:

Click to enlarge

Together, these techniques should be more than enough to catch SYN floods as they start and prevent lengthy downtime.

Summary

This article explained how SYN Flood Attacks work and showed how to detect SYN Flood attacks using Colasoft Capsa. We saw different ways to identify abnormal traffic spikes within the network, how to drill into packets and find evidence of possible attacks. Finally we showed how Capsa can be configured to automatically detect SYN Flood Attacks and create alert notifications.

Advanced Network Protocol Analyzer Review: Colasoft Capsa Enterprise 11

2018-08-18T12:45:46+10:00

Firewall.cx has covered Colasoft Capsa several times in the past, but its constant improvements make it well worth revisiting. Since the last review, the version has bumped from 7.6.1 to 11.1.2+, keeping a similar interface but scoring plenty of new features. In fact, its change is significant enough to warrant a full re-evaluation rather than a simple comparison.

For the unfamiliar, Colasoft Capsa Enterprise is a widely respected network protocol analyzer that goes far beyond free packet sniffers like Wireshark. It gives users detailed information about packets, conversations, protocols, and more, while also tying in diagnosis and security tools to assess network health. It was named as a visionary in Gartner’s Magic Quadrant for Network Performance Monitoring and Diagnostics in 2018, which gives an idea of its power. Essentially, it’s a catch-all for professionals who want a deeper understanding of their network.

Installing Capsa Enterprise 11

The installation of Capsa Enterprise is a clear merit, requiring little to no additional configuration. The installer comes in at 84 MB, a very reasonable size that will be quick to download on most connections. From there, it’s a simple case of pressing Next a few times.

However, Colasoft does give additional options during the process. There’s the standard ability to choose the location of the install, but also choices of a Full, Compact, or Custom install. It lets users remove parts of the network toolset as required to reduce clutter or any other issues. Naturally, Firewall.cx is looking at the full capabilities for the purpose of this review.

The entire process takes only a few minutes, with Capsa automatically installing the necessary drivers. Capsa does prompt a restart after completion, though it can be accessed before then to register a serial number. The software offers both an online option for product registration and an offline process that makes use of a license file. It’s a nice touch that should appease the small percentage of users without a connection.

Using Capsa Enterprise 11

After starting Capsa Enterprise for the first time, users are presented with a dashboard that lets them choose a network adapter, select an analysis profile, or load packet files for replay. Selecting an adapter reveals a graph of network usage over time to make it easier to discern the right one. A table above reveals the speed, number of packets sent, utilization, and IP address to make that process even easier.

However, it’s after pressing the Start button that things get interesting. As data collection begins, Capsa starts to display it in a digestible way, revealing live graphs with global utilization, total traffic, top IP addresses, and top application protocols.

Users can customize this default screen to display most of the information Capsa collects, from diagnoses to HTTP requests, security alarms, DNS queries, and more. Each can be adjusted to update at an interval from 1 second to 1 hour, with a choice between area, line, pie, and bar charts. The interface isn’t the most modern we’ve seen, but it’s hard to ask for more in terms of functionality.

Like previous versions, Capsa Enterprise 11 also presents several tabs and sub-tabs that provide deeper insights. A summary tab gives a full statistical analysis of network traffic with detailed metadata. A diagnosis tab highlights issues your network is having on various layers, with logs for each fault or performance issue.

In fact, the diagnosis tab deserves extra attention as it can also detect security issues. It’s a particular help with ARP poisoning attacks due to counts of invalid ARP formats, ARP request storms, and ARP scans. After clicking on the alert, admins can see the originating IP and MAC address and investigate.

When clicking on the alert, Capsa also gives possible causes and resolutions, with the ability to set up an alarm in the future via sound or email. An alarm explorer sub-menu also gives an overview of historic triggers for later review. To reduce spam, you can adjust your alarms or filter specific errors out of the diagnosis system.

Naturally, this is a great help, and the ability to define such filters is present in every aspect of the software. You can filter by IP, MAC address, and issue type, as well as more complex filters. Admins can remove specific traffic either at capture or afterward. Under Packet Analysis, for example, you can reject specific protocols like HTTP, Broadcast, ARP, and Multicast.

If you filter data you’ve already captured, it gets even more powerful, letting you craft filters for MAC addresses in specific protocols, or use an advanced flowchart system to include certain time frames. The massive level of control makes it far easier to find what you’re looking for.

After capture is complete, you can also hit the Conversation Filter button, a powerful tool that lets you accept/reject data in the IP, TCP, and UDP Conversations tabs. Again, it takes advantage of a node-based editor plus AND/OR/NOT operators for easy creation. You can even export the filters for use on a different PC.

When you begin a capture with conversation filters active, Capsa will deliver a pop-up notification. This is a small but very nice touch that should prevent users wondering why only certain protocols or locations are showing.

Once enabled, the filter will begin adjusting the data in the tab of the selected conversation type. Admins can then analyze at will, with the ability to filter by specific websites and look at detailed packet information.

The packet analysis window gives access to further filters, including address, port, protocol, size, pattern, time, and value. You can also hit Ctrl+F to search for specific strings in ASCII, HEX, and UTF, with the ability to choose between three layout options.

However, though most of your time will be spent in Capsa’s various details, its toolbar is worth a mention. Again, there’s a tabbed interface, the default being Analysis. Here you’ll see buttons to stop and start capture, view node groups, set alarms for certain diagnoses, set filters, and customize the UI.

However, most admins will find themselves glancing at it for its pps, bps, and utilisation statistics. These update every second and mean you can get a quick overview no matter what screen you’re on. It combines with a clever grid-based display for packet buffer, which can be quickly exported for use in other software’s or replays.

Another important section is the Tools tab, which gives access to Capsa’s Base64 Codec, Ping, Packet Player, Packet Builder, and MAC Scanner applications. These can also be accessed via the file menu in the top left but having them for quick access is a nice touch.

Finally, a Views tab gives very useful and quick access to a number of display modes. These enable panels like the alarm view and let you switch between important options like IP/MAC address only or name only modes.

In general, Colosoft has done a great job of packing a lot of information into one application while keeping it customizable. However, there are some areas where it really shines, and its Matrix tab is one of those. With a single click, you can get a visual overview of much of the conversations on a network, with Top 100 MAC, MAC Node, IP Conversation, and IP Node views:

Firewall.cx has praised this feature before and it remains a strong highlight of the software. Admins are able to move the lines of the diagrams around at will for clarity, click on each address to view the related packets, and quickly make filters via a right click interface.

The information above is from a single PC, so you can imagine how useful it gets once more devices are introduced. You can select individual IP addresses in the node explorer on the left-hand side to get a quick overview of their IP and MAC conversations, with the ability to customize the Matrix for a higher maximum node number, traffic types, and value.

Thanks to its v7.8 update, Capsa also has support for detailed VoIP Analysis. Users can configure RTP via the System>Decoder menu, with support for multiple sources and destination addresses, encoding types, and ports.

Once everything is configured correctly, admins will begin to see the VoIP Call tab populate useful information. A summary tab shows MOS_A/V distribution with ratings between Good (4.24-5.00) and Bad (0.00-3.59). A status column shows success, failure, and rejection, and a diagnosis tab keeps count of setup times, bandwidth rejects, and more. While our test environment didn't contain VoIP traffic we still included the screesnhot below to help give readers the full picture.

In addition, a window below keeps track of packets, bytes, utilization, and average throughput, as well as various statistics. Finally, the Call tab lists numbers and endpoints, alongside their jitter, packet loss, codec, and more. Like most aspects of Capsa, this data can be exported or turned into a custom report from within the software.

Capsa Enterprise 11 creates a number of these reports by default. A global report gives an overview of total traffic with MAC address counts, protocol counts, top MAC/IP addresses, and more. There are also separate auto-generated reports for VoIP, Conversation, Top Traffic, Port, and Packet.

You can customize these with logo and author name, but they’re missing many of the features you’d see in advanced reporting software. There’s no option for a pie chart, for example, though they can be created via the node explorer and saved as an image.

Conclusion

Capsa Enterprise 11 is a testament to Colasoft’s consistent improvements over the years. It has very few compromises, refusing to skimp on features while still maintaining ease of use. Capsa comes in two different flavors – Enterprise version or the Standard version, making it an extremely affordable & robust toolset with the ability to reduce the downtime and make troubleshooting an enjoyable process.

Though its visual design and report features look somewhat dated, the layout is incredibly effective. Admins will spend much of their time in the matrix view but can also make use of very specific filters to deliver only the data they want. It got the Firewall.cx seal of approval last time it was reviewed, and we feel comfortable giving it again.

Detect Brute-Force Attacks with nChronos Network Security Forensic Analysis Tool

2016-03-05T19:51:53+11:00

Brute-force attacks are commonly known attack methods by which hackers try to get access to restricted accounts and data using an exhaustive list/database of usernames and passwords. Brute-force attacks can be used, in theory, against almost any encrypted data.

When it comes to user accounts (web based or system based), the first sign of a brute-force attack is when we see multiple attempts to login to an account, therefore allowing us to detect a brute-force attack by analyzing packets that contain such events. We’ll show you how Colasoft’s nChronos can be used to identify brute-force attacks, and obtain valuable information that can help discover the identity of the attacker plus more.

For an attacker to obtain access to a user account on a website via brute force, he is required to use the site’s login page, causing an alarming amount of login attempts from his IP address. nChronos is capable of capturing such events and triggering a transaction alarm, warning system administrators of brute-force attacks and when the triggering condition was met.

Visit our Network Protocol Analyzer Section for high-quality technical articles covering Wireshark topics, detecting and creating different type of network attacks plus many more great security articles.

Creating A Transaction Analysis & Alarm In nChronos

First, we need to create a transaction analysis to specify the pattern/behavior we are interested in monitoring:

From the nChronos main page, first select the server/IP address we want to monitor from the Server Explorer section.

Next, from the Link Properties, go to the Application section and then the Analysis Settings as shown below:

Figure 1. Creating a Transaction Analysis in nChronos (click to enlarge)

Now click the button of New Web Application (second green button at the top) to set a Web Application, input Name and HTTP Hostname, then check the box labeled Enable Transaction Analysis and add a transaction with URL subpath e.g “/login.html”.

At this point we’ve created the necessary Transaction Analysis. All that’s required now is to create the Transaction Alarm.

To create the alarm, click Transaction Alarms in the left window, input the basic information and choose the parameter of Transaction Statistics in Type, and then set a Triggering Condition as needed, for example, 100 times in 1 minute. This means that the specific alarm will activate as soon as there are 100 or more logins within a minute:

Figure 2. Creating a Transaction Alarm (click to enlarge)

Finally, you can choose Send to email box or Send to SYSLOG to send the alarm notification. Once complete, the transaction alarm for detecting brute-force attack is set. When the alarm triggering condition is met an email notification is sent.

Note that the specific alarm triggering condition does not examine the amount of logins per IP address, which means the alarm condition will be met regardless if the 100 login attempts/min is from one or more individual IP addresses. This can be manually changed from the Transaction Analysis so that it shows the login attempt times of each individual IP address.

Below is a sample output from an alarm triggered:

Figure 3. nChronos Brute-Force alarm triggered – Overall report (click to enlarge)

And below we see the same alarm with a per-IP address analysis:

Figure 4. nChronos Brute-Force alarm triggered – IP breakdown (click to enlarge)

The article shows how nChronos can be used to successfully detect a Brute-Force attack against any node on a network or even websites, and at the same time alert system administrators or IT managers of the event.

Introducing Colasoft Unified Performance Management

2016-01-31T10:52:44+11:00

Colasoft Unified Performance Management (UPM) is a business-oriented network performance management system, which analyzes network performance, quality, fault, and security issues based on business. By providing visual analysis of business performances, Colasoft UPM helps users promote business-oriented proactive network operational capability, ensure the stable running of businesses, and enhance troubleshooting efficiency.

Colasoft UPM contains two parts: Chronos Server as a frontend device and UPM Center as the analysis center.

Frontend devices are deployed at the key nodes of the communication link of business systems, which capture business communication data by switch port-mirroring or network TAP. The frontend collects and analyzes the performance index parameters and application alarm information in real-time, and uploads to the UPM Center via the management interface for overall analysis.

UPM Center is deployed at the headquarters to collect the business performance indexes and alarm information uploaded by frontend devices, and display the analysis results.

The start page of Colasoft UPM is shown below:

Figure 1. Unified Performance Management Homepage (click image to enlarge)

The statistics information of business and alarm in a period of time is shown in this page.

Hovering the mouse over a business sensor (lower left area), we can see there are several options such as “Analyze”, “Query”, “Edit” and “Delete”:

Figure 2. Adding or analyzing a Business logic sensor to be analyzed (click image to enlarge)

We can click “Analyze” to check the business logic diagram and detailed alarm information.

Figure 3. Analyzing a business logic and checking for service alarms (click to enlarge)

Click “Query” to check the index parameters to analyze network performance:

Figure 4. Analyzing performance of a specific application or service (click to enlarge)

We can also click “Intelligent Application” in the homepage, to review the relationship of the nodes in the business system:

Figure 5. The Intelligent Application section reveals the relationship of nodes in the business system

In short, Colasoft UPM helps users easily manage network performance by providing visual analysis based on business, which greatly enhances troubleshooting efficiency and reduces human resource cost.

How to Detect P2P (peer-to-peer) File Sharing, Torrent Traffic & Users with a Network Analyzer

2015-12-09T15:58:35+11:00

Peer-to-Peer file sharing traffic has become a very large problem for many organizations as users engage in illegal (most times) file sharing processes that not only consumes valuable bandwidth, but also places the organization in danger as high-risk connections are made from the Internet to the internal network and malware, pirated or copyrighted material or pornography is downloaded into the organization’s systems. The fact is that torrent traffic is responsible for over 29% of US Internet's traffic in North America, indicating how big the problem is.

To help network professionals in the P2P battle, we’ll show how Network Analyzers such as Colasoft Capsa, can be used to identify users or IP addresses involved the file sharing process, allowing IT departments to take the necessary actions to block users and similair activities.

While all network analyzers capture and display packets, very few have the ability to display P2P traffic or users creating multiple connections with remote peers - allowing network administrators to quickly and correctly identify P2P activity.

One of the main traffic characteristics of P2P host traffic is that they create many connections to and from hosts on the Internet, in order to download from multiple sources or upload to multiple destinations.

Apart from using the correct tools, network administrators and engineers must also ensure they capture traffic at strategic areas within their network. This means that the network analyzer must be placed at the point where all network traffic, to and from the Internet, passes through it.

The two most common places network traffic is captured is at the router/firewall connecting the organization to the Internet or the main switch where the router/firewall device connects to. To learn how to configure these devices and enable the network analyzer to capture packets, visit the following articles:

While capturing commences, data will start being displayed in Capsa, and thanks to the Matrix display feature, we can quickly identify hosts that have multiple conversations or connections with peer hosts on the Internet.

By selecting the Matrix tab and hovering the mouse on a host of interest (this also automatically selects the host), Capsa will highlight all conversations with other IP addresses made by the selected host, while at the same time provide additional useful information such as bytes sent and received by the host, amount of peer connections (extremely useful!) and more:

Figure 1. Using the Capsa Matrix feature to highlight conversations of a specific host suspected of P2P traffic

In most cases, an excessive amount of peer connections means that there is a P2P application running, generating all the displayed traffic and connections.

Next, to drill into to the host's traffic, simply click on the Protocol tab to automatically show the amount of traffic generated by each protocol. Here we will happily find the BitTorrent & eMule protocol listed:

Figure 2. Identifying P2P Traffic and associated hosts in Capsa Network Analyzer

The IP Endpoint tab below provides additional useful information such as IP address, bytes of traffic associated with the host, number of packets, total amount of bytes and more.

By double-clicking on the host of interest (under IP EndPoint), Capsa will open a separate window and display all data captured for the subject host, allowing extensive in-depth analysis of packets:

Figure 3. Diving into a host’s captured packets with the help of Capsa Network Analyzer

Multiple UDP conversations through the same port, indicate that there may be a P2P download or upload in progress.

Further inspection of packet information such as info hash, port, remote peer(s), etc. in ASCII decoding mode will confirm the capture traffic is indeed from P2P traffic.

This article demonstrated how Capsa network analyser can be used to detect Peer-to-Peer (P2P) traffic in a network environment. We examined the Matrix feature of Capsa, plus its ability to automatically identify P2P/Torrent traffic, making it easier for network administrators to track down P2P clients within their organization.

Improve Network Analysis Efficiency with Colasoft's Capsa New Conversation Colorization Feature

2015-09-22T05:20:00+10:00

Troubleshooting network problems can be a very difficult and challenging task. While most IT engineers use a network analyzer to help solve network problems, when analyzing hundreds or thousands of packets, it can become very hard to locate and further research conversations between hosts. Colasoft’s Capsa v8 now introduces a new feature that allows us to highlight-colorize relevant IP conversations in the network based on their MAC address, IP Addresses, TCP or UDP conversations.

This great new feature will allow IT engineers to quickly find the related packets of the conversations they want to analyze emphatically, using just a few clicks.

As shown in the screenshot below, users can colorize any Conversation in the MAC Conversation View, IP Conversation View, TCP Conversation View and UDP Conversation View. Packets related to that Conversation will be colorized automatically with the same color.

Take TCP conversation for example, choose one conversation, right-click it and choose "Select Conversation Color" in the pop-up menu:

Figure 1. Selecting a Conversation Color in Capsa v8.0

Next, select the color you wish to use to highlight the specific conversation:

Figure 2. Selecting a color

Once the color has been selected, Capsa will automatically find and highlight all related packets of this conversation using the same background color:

Figure 3. Colasoft Capsa automatically identifies and highlights the conversation

The relevance between a conversation and its packets is enhanced by colorizing packets which greatly improves analysis efficiency.

How To Detect ARP Attacks & ARP Flooding With Colasoft Capsa Network Analyzer

2015-11-10T21:09:09+11:00

ARP attacks and ARP flooding are common problems small and large networks are faced with. ARP attacks target specific hosts by using their MAC address and responding on their behalf, while at the same time flooding the network with ARP requests. ARP attacks are frequently used for 'Man-in-the-middle' attacks, causing serious security threats, loss of confidential information and should be therefore quickly identified and mitigated.

During ARP attacks, users usually experience slow communication on the network and especially when communicating with the host that is being targeted by the attack.

In this article, we will show you how to detect ARP attacks and ARP flooding using a network analyzer such as Colasoft Capsa.

Colasoft Capsa has one great advantage – the ability to identify and present suspicious ARP attacks without any additional processing, which makes identifying, mitigating and troubleshooting much easier.

The Diagnosis tab provides real-time information and is extremely handy in identifying potential threats, as shown in the screenshot below:

Figure 1. ARP Scan and ARP Storm detected by Capsa's Diagnosis section.

Under the Diagnosis tab, users can click on the Events area and select any suspicious events. When these events are selected, analysis of them (MAC address information in our case) will be displayed on the right as shown above.

In addition to the above analysis, Capsa also provides a dedicated ARP Attack tab, which is used to verify the offending hosts and type of attack as shown below:

Figure 2. ARP Attack tab verifies the security threat.

We can extend our investigation with the use of the Protocol tab, which allows us to drill into the ARP protocol and see which hosts MAC addresses are involved in heavy ARP protocol traffic:

Figure 3. Drilling into ARP attacks.

Finally, double-clicking on a MAC address in the ARP Protocol section will show all packets related to the selected MAC address.

When double-clicking on a MAC address, Capsa presents all packets captured, allowing us to drill-down to more useful information contained in the ARP packet.

Figure 4. Drilling-down into the ARP attack packets.

By selecting the Source IP, in the lower window of the selected packet, we can see the fake IP address 0.136.136.16. This means that any host on the network responding to this packet will be directed to an incorrect and non-existent IP address, indicating an ARP attack of flood.

If you're a network administrator, engineer or IT manager, we strongly suggest you try out Colasoft Capsa today and see how easy you can troubleshoot and resolve network problems and security threats such as ARP Attacks and ARP Flooding.

How to Reconstruct HTTP Packets/Data & Monitor HTTP User Activity with NChronos

2015-10-20T23:05:50+11:00

HTTP reconstruction is an advanced network security feature offered by nChronos version 4.3.0 and later. nChronos is a Network Forensic Analysis application that captures packets/data around the clock. With HTTP reconstruction, network security engineers and IT managers can uncover suspicious user web activity and check user web history to examine specific HTTP incidents or HTTP data transferred in/out of the corporate network.

Now let's take a look at how to use this new feature with Colasoft nChronos.

The HTTP reconstruction feature can be easily selected from the Link Analysis area. We first need to carefully select the time range required to be examined e.g 9th of July between 13:41 and 13:49:15. Once the time range is selected, we can move to the bottom window and select the IP Address tab to choose the IP address of interest:

Figure 1. Selecting our Time-Range, and IP Address of interest from Link Analysis

nChronos further allows us to filter internal and external IP addresses, to help quickly identify the IP address of interest. We selected External IP and then address 173.205.14.226.

All that's required at this point is to right-click on the selected IP address and choose HTTP Packet Reconstruction from the pop-up menu. Once HTTP Packet Reconstruction is selected, a new tab will open and the reconstruction process will begin as shown below:

Figure 2. nChronos HTTP Reconstruction feature in progress.

A progress bar at the top of the window shows the progress of the HTTP Reconstruction. Users are able to cancel the process anytime they wish and once the HTTP Reconstruction is complete, the progress bar disappears.

The screenshot below shows the end result once the HTTP Reconstruction has successfully completed:

Figure 3. The HTTP Reconstruction process completed

As shown in the above screenshot, nChronos fully displays the reconstructed page in an easy-to-understand manner. Furthermore, all HTTP requests and commands are included to ensure complete visibility of the HTTP protocol commands sent to the remote web server, along with the user's browser and all other HTTP parameters.

nChronos's HTTP reconstruction feature can prove to be an extremely important security tool for network engineers, administrators and IT Managers who need to keep an eye on incoming/outgoing web traffic. This new feature surpasses web proxy reporting and other similar tools as it is able to completely reconstruct the webpage visited, data exchanged between the server and client, plus help identify/verify security issues with hijacked websites.

How to Use Multi-Segment Analysis to Troubleshoot Network Delay, Packet Loss and Retransmissions with Colasoft nChronos

2015-08-10T20:58:04+10:00

Troubleshooting network problems can be a very intensive and challenging process. Intermittent network problems are even more difficult to troubleshoot as the problem occurs at random times with a random duration, making it very hard to capture the necessary information, perform troubleshooting, identify and resolve the network problem.

While Network Analyzers help reveal problems in a network data flow, they are limited to examining usually only one network link at a time, thus seriously limiting the ability to examine multiple network segments continuously.

nChronos is equipped with a neat feature called multi-segment analysis, providing an easy way for IT network engineers and administrators to compare the performance between different links. IT network engineers can improve network performance by enhancing the capacity of the link according to the comparison.

Let’s take a look how we can use Colasoft nChronos’s multi-segment analysis feature to help us detect and deal effectively with our network problems.

Multi-segment analysis provides concurrent analysis for conversations across different links, from which we can extract valuable information on packet loss, network delay, data retransmission and more.

To being, we open nChronos Console and select a portion of the trend chart in the Link Analysis window, then from the Summary window below, we right-click one conversation under the IP Conversation or TCP Conversation tab. From the pop-up menu, select Multi-Segment Analysis to open the Multi-Segment Analysis window:

Figure 1. Launching Multi-Segment Analysis in nChronos

In the Multi-Segment Analysis window, select a minimum of two and maximum of three links, then choose the stream of interest for multi-segment analysis:

Figure 2. Selecting a stream for multi-segment analysis in nChronos

When choosing a conversation for multi-segment analysis, if any of the other selected network links has the same conversation, it will be selected and highlighted automatically. In our example, the second selected link does not have the same data from the primary selected conversation and therefore there is no data to display in the lower section of the analysis window.

Next, Click Start to Analyze to open the Multi-Segment Detail Analysis window, as shown in the figure below:

Figure 3. Performing Multi-Segment analysis in nChronos

The Multi-Segment Detail Analysis section on the left provides a plethora of parameter statistics (analyzed below), a time sequence chart, and there’s a packet decoding pane on the lower right section of the window.

The left pane provides statistics on uplink and downlink packet loss, uplink and downlink network delay, uplink and downlink retransmission, uplink and downlink TCP flags, and much more.

The time sequence chart located at the top, graphically displays the packet transmission between the network links, with the conversation time displayed on the horizontal axis.

When you click on a packet on the time sequence chart, the packet decoding pane will display the detailed decoding information for that packet.

Using the Multi-Segment Analysis feature, Colasoft’s nChronos allows us to quickly compare the performance between two or more network links.

How to Detect Routing Loops and Physical Loops with a Network Analyzer

2015-07-28T01:31:04+10:00

When working with medium to large scale networks, IT departments are often faced dealing with network loops and broadcast storms that are caused by user error, faulty network devices or incorrect configuration of network equipment. Network loops and broadcast storms are capable of causing major network disruptions and therefore must be dealt with very quickly.

There are two kinds of network loops and these are routing loops and physical loops.

Routing loops are caused by the incorrect configuration of routing protocols where data packets sent between hosts of different networks, are caught in an endless loop travelling between network routers with incorrect route entries.

A Physical loop is caused by a loop link between devices. A common example is two switches with two active Ethernet links between them. Broadcast packets exiting the links on one switch are replicated and sent back from the other switch. This is also known as a broadcast storm.

Both type of loops are capable of causing major network outages, waste of valuable bandwidth and can disrupt network communications.

We will show you how to detect routing loop and physical loop with a network analyzer such as Colasoft Capsa or Wireshark.

Note: To capture packets on a port that's connected to a Cisco Catalyst switch, users can also read our Configuring SPAN On Cisco Catalyst Switches - Monitor & Capture Network Traffic/Packets

If there are routing loops or physical loops in the network, Capsa will immediately report them in the Diagnosis tab as shown below. This makes troubleshooting easier for network managers and administrators:

Figure 1. Capsa quickly detects and displays Routings and Physical Loops

Further examination of Capsa’s findings is possible by simply clicking on each detected problem. This allows us to further check the characteristics of the related packets and then decide what action must be taken to rectify the problem.

Drilling Into Our Captured Information

Let’s take a routing loop for example. First, find out the related conversation using Filter (red arrow) in the MAC Conversation tab. MAC addresses can be obtained easily from the notices given in the Diagnosis tab:

Figure 2. Obtaining more information on a Routing Loop problem

Next, Double-click the conversation to load all related packets and additional information. Click on Identifier, to view the values of all packets under the Decode column, which in our case are all the same, This effectively means that the packets captured in our example is the same packet which is continuously transiting our network because its caused in a loop. For example, Router-A might be sending it to Router-B, which in turn sends it back to Router-A.

Figure 3. Decoding packets caught in a routing loop

Now click on the Time To Live section below, and you’ll see the Decode value reduces gradually. It is because that TTL value will decreased by 1 after transiting a routing device. When TTL reaches the value of 1, the packet will be discarded, to help avoid ICMP packets travelling indefinitely in case of a routing loop in the network. More information on the ICMP protocol can be found in our ICMP Protocol page:

Figure 4. Routing loop causing ICMP TTL to decrease

The method used to analyze physical loops is almost identical, but the TTL values of all looped packets remain the same, instead of decreasing as we previously saw. Because the packet is trapped in our local network, it doesn’t traverse a router, therefore the TTL does not change.

Below we see a DNS Query packet that is trapped in a network loop:

Figure 5. Discovering Network loops and why their TTL values do not decrease

Advanced network analyzers allows us to quickly detect serious network problems that can cause network outages, packet loss, packet flooding and more.