SAN FRANCISCO (09/26/2003) - True real-time network forensics implementations are generally a rich company's game. The high-performance devices are capable of deep-packet analysis, session recreation, reporting, and auditing -- and that generally comes at a high price.
Sandstorm Enterprises Inc. has taken a slightly different approach, foregoing redundancy and scalability to deliver NetIntercept 2.0 network forensics package on the NI-S95 appliance at a lower cost. The NI-S95 performs well for its size and is significantly cheaper than you might expect.
The NI-S95 analyzes data gathered from network traffic streams, mirrored at a network edge or network core. It then monitors and stores those data streams on a local disk, at which point an administrator may initiate the process of categorizing, parsing, displaying, and reporting findings gathered during analysis. The capture is protocol agnostic and will interpret every known packet type seen on the wire.
A 2U rack-mount appliance, the NI-S95 is based on FreeBSD 4.8. My test unit contained a single P4 2.0GHz processor, 512MB of RAM, and a single 120GB IDE drive. The new generation of the NI-S95 will see a CPU speed boost to 2.4GHz for the same price. Of the 120GB on the nonupgradeable local disk, 95GB is reserved for packet captures. The remainder is used for OS and database files. The NI-S95 uses a single 10/100 Ethernet interface for monitoring and another for management; it is best suited for lower-throughput networks averaging 5Mbps or less.
The single IDE drive is a liability, to be sure, but it also brings the price of the NI-S95 down below $9,000. The NI-S95 does have bigger brothers: the NI-DR300 with 300GB of RAID storage, and the NI-DRG-770 with 770GB of RAID storage. These beefier models also use IDE drives, but include features such as gigabit Ethernet network interfaces, dual CPUs, and multiple network interfaces. And for those needing more throughput, these larger models also offer more horsepower.
As for the NI-S95, initial configuration is a breeze. As soon as the monitoring interface establishes a link, it begins traffic captures, storing every packet seen on the wire. For the management interface configuration, a keyboard, mouse, and monitor are plugged in, and the NI-S95 boots to an XDM (X Display Manager) log-in.
Logging in to the NI-S95 as any valid user presents the X Windows workspace with the Fvwm95 Window Manager, for a Windows 95 look and feel. It is also possible to run the NetIntercept 2.0 UI from the console of the unit itself; and a few other tools, such as a capture interface monitor, are available as well.
Most devices billed as appliances operate with a browser-based interface, using CGI and/or Java to deliver higher functionality to the administrator. Some devices include a client component that interacts with the device through SNMP to provide the administration interface. Sandstorm, however, has taken a different route, relying on X11 to deliver the interface. For those with Unix-derivative workstations, this isn't a big deal. But those who would rather administer the NI-S95 from Windows will need a third-party package to provide an X server on their desktop. As an aside, X11 views clients and servers inversely, so in this case, the NI-S95 is the client and the administrator's desktop is the server.
The application is written in TrollTech's Qt, providing a functional and responsive -- if not altogether aesthetically pleasing -- interface. The responsiveness of the interface is directly related to the network connection of the client, however, and X11 sessions across low-bandwidth links are painful to work with.
Administering the NI-S95 over low-bandwidth links will likely require a thinner transport, such as VNC (virtual network computing), to deliver the workspace, which will reduce usability somewhat. Encryption of the administration interface is handled with standard SSH X11 forwarding.
Although the NI-S95 continuously captures and stores traffic seen on the monitoring interface, it doesn't parse and categorize that data until instructed to do so, either by a scheduled event or a manual intervention. The NI-S95 isn't designed for archival capture storage, overwriting the oldest captures when the storage capacity is reached. Depending on the amount of traffic present on the monitored network, data may be available for a few hours, a few days, or a few weeks. But once the threshold is reached, the oldest data is gone forever. However, if that data has previously been selected for analysis, the database will still exist.
Data selection is based on timeframe, represented as a moving, active graph. Selecting a timeframe in the graph and choosing New creates a database to store that data. Continuing the open source trend, NetIntercept uses the MySQL database to store analysis data. MySQL is a capable database, but its performance suffers due to the single processor and limited RAM when parsing large segments. During periods of high traffic, creating a database for a 60-second timeframe containing 500,000 packets took nearly two minutes. When importing databases with a few thousand packets, however, the NI-S95 performed much better.
A novel feature of the NI-S95 is the SSH and SSL decryption option. The concept is that the NI-S95 can decrypt encrypted traffic between two hosts and store it. To implement this feature, an administrator must generate a header file containing a public and private RSA key, then compile a modified OpenSSH v3.5p1 with that header file. The resulting binaries contain keys that can be decrypted by the monitor.
Poor Lab Performance
In the lab, these tests didn't fare well, as five out of five attempts to decrypt SSH traffic resulted in problems ranging from failed compilations due to syntax errors in the generated header file, to the inability of the NI-S95 to decrypt the traffic with an "Unknown key" error. An updated SSH package exhibited the same behavior. SSL decryption requires that each server's private key be imported into the NetIntercept. Given that SSH and SSL must be as solid as possible, server administrators will likely balk at having to install modified SSH binaries or export SSL private keys for the purpose of decryption unless they absolutely require this function.
Once a capture is running and a timeframe has been selected, the admin is presented with a myriad of analysis options. The recorded traffic can be categorized in a dozen different ways, sorted by protocol at several layers, source and destination host, file format, and so forth. Filters can be defined by selecting portions of the capture or by writing a filter in BPF (Berkeley Packet Filter) format, which shortens the learning curve for many. Additionally, data streams such as Web pages and AIM sessions can be plucked from the pile and recreated and displayed in their native format. Further, it's possible to browse through a display of all the images that are passed by the monitor. Selecting an image will bring up the data on that particular session.
The reporting features of the UI are straightforward, containing prepackaged reports that can be called on any database. The reports are available in either HTML or plain text. The possibilities range from traffic reporting on selected IP addresses to protocol hygiene reports that highlight file transfers that purport to be zip files but are actually EXE files. The reports are satisfactory and the presentation is well done, but they leave room for improvement. Reports are noticeably not customizable, except that both reports and database creation can be scheduled.
Sandstorm has packed a lot of functionality into this code release, but the solution has its limitations. For a reasonable network forensics implementation on a tight budget, however, this may be the answer.