Passive Network Analysis | Vulnerability Management

Passive network analysis involves installing a piece of equipment on a network switch to listen to a copy of the traffic and analyze it for vulnerabilities. This is similar in functional design to an intrusion detection system (IDS) or a sniffer. A piece of hardware with a network port is connected to the network switch carrying the traffic to be examined. A command on the network switch sends a copy of much of the switch traffic to that physical port where the analyzer can read it. Alternatively, a network tap can be used to inspect traffic in a single physical network connection. That connection may carry large amounts of consolidated traffic from multiple networks.
The analyzer looks for several things that can reveal vulnerabilities. The IP addresses, network, application protocols, and general communication patterns are all checked for anomalies or attributes that reveal an exploitable flaw. Table 1 shows what the passive vulnerability scanner might get to see when a network tap or port mirror feature is applied compared to what is seen by a vulnerability scanner. Notice that the active scanner has access to information that is not found on the network, whereas the passive scanner possibly has access to information for which the active scanner does not scan.
Table 1: Active and Passive Scanner Comparison 
From single VLANs
From multiple VLANs, including remote ones
TCP.IP of target
From actively scanned target
From multiple targets, any talking on monitored VLANs
VLAN tags
From connected VLANs
From multiple VLANs
Protocols observed
Only those in the parameters specified for the scan
Any and all protocols used by the host
Applications discovered
Those which the scanner knows to find, including non-network applications
Any applications that use the network connection
Port mirroring, also called a switched port analyzer (SPAN) by Cisco, is a very commonly available technology in modern network switches. Figure 1 explains how SPAN works. This is a basic SPAN configuration where the contents of a pair of VLANs are copied to a physical port on the switch. The network administrator has the option of specifying ingress traffic only, egress traffic only, or both ingress and egress traffic; typically, both are desirable so that the analyzer can see each side of the conversation. There are complications and limitations to the SPAN function that will vary by model, brand, and features installed on the switch. Some simple switches can only copy traffic that is coming in via a physical port and not off the backplane of the switch. Some can see traffic on a single VLAN, and others can look at trunked VLANs.

Figure 1: A basic SPAN configuration where the contents of a pair of VLANS are copied to a physical port on the switch.
One interesting aspect of SPANs that you might notice is that it seems that the analyzer must be connected to the physical switch carrying the traffic to be analyzed. But, there is a modification of SPANs that addresses this issue to limited extent. Remote SPAN (RSPAN) is available on some switch models that allow SPAN results from remote switches to be forwarded to another switch to which the analyzer can be connected. Some of the capabilities for SPANs can become quite exotic at this point. Your network administrator will have to evaluate the requirements carefully and determine the most efficient way to provide the appropriate information to the analyzer. Figure 2 shows an RSPAN implementation where targets A and B are monitored on a remote switch (#1). The copy of the traffic is sent to the local switch (#2), where the passive analyzer is connected.

Figure 2: An RSPAN implementation where targets A and B are monitored on a remote switch (#1).
Generally, the traffic that is copied is referred to as being “flooded” onto a special VLAN shared between two or more switches. On Cisco products, this approach requires the creation of an RSPAN VLAN. This is a special VLAN that the switch understands is designed for remote monitoring. With this technique, it is possible to assess vulnerabilities using multiple devices in multiple locations.
It is also possible to include this RSPAN VLAN connection in a WAN configuration where the remote switch is 100 miles away. This would be an atypical configuration with some bandwidth risks. This leads us to a key disadvantage of the passive approach to vulnerability scanning. You cannot necessarily target remote locations for vulnerability assessment cost-effectively using the SPAN technique. Passive vulnerability analyzers are expensive. Remote locations with 20 to 30 targets talking to each other at 100 Mbps or even 1000 Mbps are difficult and expensive to monitor since it is necessary to provide sufficient hardware to analyze a large traffic volume. Since it is unlikely to have a WAN link installed at 1 Gbps for monitoring purposes, and purchasing a unit to install locally is impractical, the use of a passive device is not always optimal.
Problems can occur with SPANs and RSPANs that must be assessed by a qualified network administrator. The monitor port, the one to which the analyzer is connected, can become oversubscribed. That is to say, more traffic is going to that port than the port can sustain. Much of that traffic is saved in a buffer that is shared with the networks being monitored. If that buffer becomes full, traffic will slow down for all the ports involved in the SPAN operation. This is easy to see if an analyzer is connected to a 100-Mbps port and is monitoring four other physical network ports with utilization exceeding 40 Mbps each. The total monitored is 160 Mbps. That means there is an additional 60 Mbps that the switch has to save until it can be delivered to the passive analyzer’s port. To avoid this scenario, careful analysis of the peak traffic of each target/monitored port must be assessed. If there is an existing IDS/IPS implementation, these SPAN ports can be shared to economize.
An alternative approach to SPAN is a tap, which is precisely what it sounds like: a physical installation into a network connection that allows a passive analyzer to see the traffic. The tap can be electrical in the case of Ethernet, or optical in the case of fiber. The Ethernet tap is a little more complex because it requires that power be supplied to theunit. Some taps even have built-in batteries to keep the tap operating should the power supply fail. The optical taps do not typically require any electricity but instead employ a prism known as a beam splitter.
A tap has the disadvantage of managing duplex. Since most networks today are built to send and receive data simultaneously, the analyzer must be able to do the same. In a 100-Mbps Ethernet example, a single cable connected to the analyzer can only listen to either the sending or receiving traffic among the monitored targets. Between two targets, there could be transmission and reception each occurring at up to 100 Mbps. So, the total throughput is 200 Mbps, which exceeds the capability of the single analyzer port connection. This problem is addressed by the tap by breaking the conversation up into two separate cables connected to the analyzer. The analyzer then bonds these two sides of the conversations together internally in order to analyze them accurately.

Agents Advantages and Disadvantages

A significant advantage of this agent approach is the scalability gained from its distributed nature. Since the number of agents deployed is only limited by the number of compatible hosts and licensing costs, it is theoretically possible to perform an audit of every machine without generating any network activity except to configure the agent and report results. Although the audit is not performed over the network, the communication between the agent and the server is not always minimal. Depending on the complexity of the host and vulnerabilities, considerable reporting traffic can be generated. Nevertheless, the scan does not take place over a network link.
Some obvious advantages are that there need be little concern for deploying additional hardware, and there is less concern that sufficient bandwidth and scanner resources are available.
Agents are encumbered, however, by a few basic problems:
  • They may conflict with other applications running on the target. This is a common problem for all software running on complex computer systems today. Testing is the only solution.
  • They may not have sufficient privileges in local security policy to audit every configuration item.
  • They may have errors that cause them to terminate and notification of failure may not come to the management server for some time, during which an audit window could be missed.
  • Agents may not be available for the OS maker and version in use. Almost everyone makes an agent for Microsoft Windows®, but far fewer will support Linux®, FreeBSD®, or Solaris.
  • Imbedded systems such as cash registers and other point-ofsale devices are tightly built and leave no accommodation for agents. Yet, payment card industry (PCI) security standards require file integrity monitoring on these systems.
  • Given the limited size, space, and performance of an agent, it will not likely have the ability to cover the thousands of possible vulnerabilities.
  • On virtual machines, there can be many agents running simultaneously, which can adversely impact the performance of the underlying hardware and host OS.
  • The agent itself can become a target of an attacker as a result of a vulnerability. Since agents typically listen on the network for instructions from a server, an opening is available for exploitation.
The vulnerability audit agent has many advantages over other methods:
  • It sees all vulnerabilities, some of which are not available over the network unless the scan is authenticated.
  • The agent can run even when the system is not connected to a network.
  • It does not actively engage with the software installed on the system to find a vulnerability, thus minimizing the chance of disrupting operations.
  • Since it does not operate over the network, it will not draw the attention of a network intrusion prevention system (IPS), nor will it create excessive network traffic. In fact, the total traffic load is likely far less than typical Web surfing activity.
  • As locally running software, it can extend functionality into more active end point security functions.

Popular Posts