Direct Sniffing or Netflow

When deploying the Log Correlation Engine (LCE), Tenable's support group often is asked which is better for network monitoring: using netflow from a router or performing some sort of direct network monitoring. This blog entry will help users choose a strategy and discuss some of the technical and political aspects associated.

Netflow and Direct Sniffing

If you only have access to netflow or direct network sniffing, you should not feel as if your monitoring is lacking because you are doing one or the other.

Both of Tenable's LCE agents, the Tenable Network Monitor (TNM) and the Tenable Netflow Monitor (TFM), produce a record of each network session. This record includes ports, source and destination IP addresses and total number of bytes transfered. Each of these records is consumed by the LCE for normalization, statistical profiling and for event correlation by many different TASL scripts.

There are minor differences between the TFM and the TNM. The TNM uses the libpcap library and can accept any type of valid "pcap" packet filter. The TFM also performs filtering, but it is not as sophisticated as the TNM. The TFM, as of release 2.0.2, also differentiates client and server bandwidth, whereas the TNM logs aggregate bandwidth for each session.

The TFM is available for RedHat ES3 and ES4 and it can receive netflow records from multiple sources. The TNM is available for RedHat ES3, Fedora and FreeBSD, and must be deployed on a system that has a network interface exposed to network traffic.

Leveraging "Sniffing Platforms"

If you have deployed the Passive Vulnerability Scanner (PVS) on RedHat ES3 or ES4, you should consider deploying the TNM on the same system. Tenable has monitored many large networks with servers that ran both the PVS and the TNM with very good results. Compared to the PVS, the performance requirements for the the TNM are negligible.

If your organization has deployed UNIX based NIDS such as Snort, Dragon, Bro or even dedicated network monitoring applications such as TCPDUMP or NTOP, these may also be a candidate to deploy the TNM on.

Leveraging Netflow

The TFM supports netflow records (version 5 and 9) from Cisco devices. A single TFM can accept records from multiple devices.

Since netflow is a UDP based protocol, any CPU contention at the TFM or network congestion between the routers and the TFM could cause some session loss. The TFM does have logic to reconstruct full session data if some netflow records have been missed.

The Business Case for Network Monitoring

As a security auditor or network security monitor, considering network sessions alongside system logs and NIDS events is relevant for a variety of "compliance violation" and "compromise alerting" activities.

If the organization providing access to the network (such as a routing, infrastructure or backbone group) does not have a security component, presenting them with data through the Security Center and the Log Correlation Engine may be very useful to them. If they are already collecting netflow data, perhaps for performance and availability monitoring, sending an addition stream of network session information to a TFM may not be difficult.

If direct sniffing of a data center or network is desired, you will likely need to use switch span ports, network taps or tap concentrators. This is very dependent on your network architecture, the technology of your routers and switches and how reliable your monitoring must be. For more information on this topic, readers should consider the TaoSecurity blog which discusses various aspects of this in depth as well as vendors such as NetOptics.

Filtering for Performance

As with any log aggregation and analysis exercise, you should consider the purpose of the monitoring and what sort of traffic is required. If not, you will likely over-log and record data that isn't relevant. You may also dramatically increase your storage requirements.

If the purpose of network monitoring is to identify hosts, where they connect to, which ports they browse on and what ports are being served, the LCE can tell you this, but you may be better off with the Passive Vulnerability Scanner (PVS).

For example, let's say a new application listens and browses on TCP port 7003. A user of the Log Correlation Engine may run a report for all sessions on port 7003 and then sort by IP address or network. All network sessions would need to be stored by the LCE for it to perform these tasks. However, with the PVS, it maintains a list of all ports that are both open and browsed. The application may have made 1,000,000 network connections on port 7003, and the PVS will only log this once, whereas if the LCE is tracking these, then all 1,000,000 sessions will be stored.

For More Information

Readers who would like to learn more about log analysis should consider the Tenable paper "Security Event Management" as well as the "Network and Behavioral Anomaly Detection" webinar.