Protocol analyzers restore network health

Every IT department with mission-critical computer operations tries to implement security measures to protect its network from data loss, performance degradation or other damage, but such damage inevitably occurs in even the best-defended environments. Most network performance and security products report specific threats as they occur or after they have occurred; but to gain optimum network security and performance, IT departments must find ways to proactively monitor, troubleshoot and repair potential problems before they affect productivity.

Network protocol analyzers are a fundamental weapon for monitoring and troubleshooting security and performance problems. With proper use, they can help IT engineers identify and fix problems before they affect user productivity. Even in an era of increasingly sophisticated network-management and threat-detection systems, protocol analyzers are an important part of a network engineer's tool kit.

Protocol analyzers display network traffic at the packet level, while other, more widely used network-troubleshooting tools generally attempt to perform automatic analysis based on traffic statistics or rule-based alarms. For example, Simple Network Management Protocol (SNMP) consoles rely on statistics that are calculated by remote agents, while intrusion-detection systems (IDS) only report attacks based on predefined rules.

IDS, SNMP and other such tools thus attempt to insulate the engineer from the dirty details of the network traffic by automatically detecting and reporting problems. While this is a valuable technique for certain types of problems, the abstraction forces the engineer to infer what is actually happening on the network. These tools may inform the network engineer that there is a problem, but they may not offer enough information about what exactly is happening for the engineer to take action and address the problem. In addition, pattern-recognition products such as IDS can only report problems for which an attack signature has been identified, which is rather like trying to drive by looking in the rear-view mirror.

With a protocol analyzer, the engineer can monitor and analyze network activity to proactively discover and address developing problems. The key strength of a protocol analyzer is that it shows, at the packet level, exactly what is being transmitted on the network. The drawback is that the user has to understand network operations at the packet level.

Difficult to automate

Fundamentally, protocol analysis requires a level of sophistication and intuition that is difficult or impossible to automate. For example, problems often manifest themselves periodically, and attacks often cause periodic traffic (as a worm tries to "phone home" or scans the subnet for stations to infect, for example). To handle such problems, the engineer must analyze repetitive events and ask whether an event is normal or possibly signals a problem.

To make sense of the packet-level information offered by a protocol analyzer, however, the engineer must know what applications are running on the network, the normal behavior patterns of those applications, when users are expected to be using the applications, the tolerance of the users and applications to performance degradation, and so on. Finding repetitive traffic and then judging its normality or abnormality is more art than science. Consider the factors that would go into answering the question, "This station is attempting to open a TCP conversation every 30 seconds but the connection is always refused. Is this an attack, a performance issue, a harmless inefficiency or normal behavior?" Currently, only a human can effectively make a judgment like that.

Fundamentally, a protocol analyzer captures and displays packets, with minimal processing occurring between those steps. Although this low-level, "unsanitized" perspective is valuable, it also creates one of the major challenges in rapid and accurate troubleshooting: Today's switched networks contain so many segments and are so distributed that it can be difficult to capture the necessary packets to troubleshoot the problem.

Early protocol analyzers could only capture traffic from a single segment, to which they had to be directly attached. Today's switched networks contain many segments (each switch port is a single segment), with very few stations per segment. In this type of network, the analyzer sees much less of the network's traffic from a single connection point. Analyzers address the single-segment limitation in three main ways: support for multiple simultaneous captures from different network interface cards (NICs), dedicated remote-capture agents and capture from third-party remote agents.

The right-click menu is used to make a filter that will isolate traffic coming from a suspicious station.

Through multiple-NIC support, the analyzer can be simultaneously attached to two or more segments (limited only by the number of cards in the station and the number of simultaneous captures that the analyzer supports). In the case of a dedicated remote-capture agent, the analyzer vendor builds a remote agent that listens on a given segment and then transfers packets back to the analyzer, sometimes in real-time. With multiple agents distributed throughout the network, the engineer can widen his or her perspective. Finally, some analyzers support captures from third-party agents, most likely remote-monitoring agents, and thus leverage an existing management infrastructure.

The other main challenge in protocol analysis is the sheer volume of traffic that is carried on even a single segment of today's high-speed networks. At 100-Mbit/second line speeds, it is difficult to manually scan and separate the relevant traffic from irrelevant; in the realm of Gigabit or 10-Gbit data rates, it is effectively impossible. A protocol analyzer must have robust packet-filtering capabilities to help an IT engineer handle this volume. For example, upon noticing suspicious traffic coming from a particular station, the engineer might use an address-based filter to view all traffic coming from that station, to better see if the pattern repeats itself. Other typical filter criteria include protocol and TCP or UDP port number.

Protocol analyzers vary widely in the types of filters they support, and this should be a major consideration, since filtering is probably the most common and useful task that the engineer will perform with the analyzer. In addition, filters should be easy to create and apply, because filters that require the user to navigate a complicated interface will slow the analysis. Ideally, the analyzer will make it possible to create and apply filters with something as simple as a right click on a certain packet or protocol.

Finally, the analyzer's interface plays a major role in its effectiveness as a troubleshooting tool. A good interface lowers the learning curve for a beginner and enhances the efficiency of an experienced user. Some interface considerations include:

• Presenting traffic-summary and packet-decode views at the same time to simplify correlation between the two views.
• Opening multiple capture buffers and providing adequate window-management functions so the user can compare two captures side by side. (Comparing "known good" to "trouble" scenarios is a basic technique.)
• Rapid access to common functions such as filtering and entering station names from the right-click menu, a button, a command key or some combination of those.
• Being able to quickly filter a capture without having to spend time actually making a filter.
• Ready availability of common statistics for each window, and the ability to filter the statistics in the same manner that one can filter the packets.
• Transparent capture from a remote agent-ideally, the remote capture should look the same as capturing from a local network interface card.

As networks become faster and more sophisticated, it will become increasingly important for protocol analyzers to incorporate some level of expert-system functionality. For example, an expert system could identify problem network conversations and suggest ways to use the analyzer to determine the cause of the problem. Such automated helpers go far to make protocol analysis a mainstream IT tool, rather than something used only by a handful of packet gurus. And by distributing analysis capabilities more broadly across an IT department, protocol analyzers with expert systems enable broader monitoring of network activity, faster problem identification and less network downtime.

When combined with an integrated, sophisticated automatic problem-detection (or "expert") system, a protocol analysis tool represents the ideal in network troubleshooting. The expert system makes it possible to quickly locate problems and detect intrusions on fast, distributed networks, while the packet-level detail makes it possible to troubleshoot those problems when they're found. Automatic troubleshooting will become more and more valuable (and expert systems in protocol analyzers will become correspondingly more sophisticated), but packet-level analysis will always be important.

Joshua Bardwell (joshuab@wildpackets.com) is senior technical instructor/network engineer at WildPackets Inc. (Walnut Creek, Calif.).