IDABench uses a pair of installation scripts (install_sensor and install_analyzer) to check for required and optional dependencies, prepare the system, install the IDABench components and start the various processes. To install a basic one-sensor system, configuration requirements are minimal, the majority of which can be accomplished before installation. The configuration files, idabench.conf and sensor.conf, instruct the install utilities where to place the components, account names to use, and most other settings. After installation, a simple crypto key exchange will enable the sensor/analyzer communications. If both the sensor and analyzer are to occupy the same physical machine, although this is not recommended, one of these key exchanges is taken care of by the analyzer installer. See the Installation sections for the nitty gritty.
IDABench was designed with customization in mind. Different analysts will want to twist and turn their data in different ways, so we tried to make it a fairly simple task to modify and extend the capabilities of this workbench. There are two primary means to this end:
First, when the IDABench analyzer pulls raw tcpdump files from each sensor site, it passes this data through analysis tools to produce hourly reports. You can add IDABench Hourly Analysis plugin tools which will process this stream to produce additional or alternative reports or report sections.
Second, IDABench allows you to run search tools on tcpdump data from any range of hours and view the result on a web page. It is easy to incorporate search and analysis tools of your own as IDABench search plugins. Examples have been provided for tcpdump, ngrep, and tethereal. A uniform, table driven method of specifying search forms is used to create the form which will be displayed to analysts. The submitted values can be validated by your plugin script and passed as arguments to your search tool, with the results piped to a web page in tabular, chart or libpcap binary form.
By adding plugin capabilities, we hope to realize the following advantages:
The only plugins that are shipping right now are ngrep, tcpdump, findscan (hourly only) and tethereal (search only). You will need the associated binaries installed to use them, though. If a site has filters configured for a plugin that is not properly installed, the search tabs and hourly sections will appear in the webpages, but let you know something is wrong.
The Plugins section has details on writing your own hourly and search plugins.
The default output from IDABench is textual, presented as HTML pages served by an httpd on the analysis system. This textual output is organized with each plugin's output appearing in an easy to identify section. Navigation links are provided at the top and bottom of each page for convenient movement through the hourly output. The default search output is also text, but other output forms are available. When a custom query is processed by a search plugin, the text is returned to the analyst's browser with the search form reappearing at the end of her results, pre-populated with the field selections that yielded that result. Subsequent, modified queries are then easily entered by changing only those fields that need to be refined to produce the next query.
Search results can also be returned in either pcap binary or graphical chart form. Binary output is a new pcap binary dumpfile containing ONLY those packets which matched your query specification. This new, single, dumpfile is then presented for download so that the analyst can perform follow-on analysis on his local system, without ever needing a shell account on the IDABench analysis machine. Tools that may be of use locally may include graphical analyzers such as etherape, ethereal, etc.
Graphical output of queries, via gnuplot, provides the analyst with a view of the query that may reveal visual patterns of activity otherwise missed. For example, fluctuations in the rate of a denial of service attack may provide insight into the techniques used by the attacker. Query results can be plotted using several different graph types, and can be scaled in packets per second, minute, hour or day. Be aware that counting packets per unit time across a range of hours, days or weeks can take quite some time. Big queries require patience as well as horsepower. There is no substitute for RAM and CPU speed. See the Hardware Requirements sections for recommendations.
The sensor component of IDABench is a pair of Perl scripts that manage packet capture operations for later retrieval by an analyzer. It is suitable for use alone or in conjunction with the IDABench Analyzer, which automates the retrieval and access to this packet data.
Sensor installation is designed to be as painless as possible, allowing you to
rapidly deploy usable sensors with minimal configuration. The install_sensor
script and sensor.conf provided contain sensible defaults for most settings,
and, unless overridden by sensor.conf settings, will attempt to locate the
dependencies during the installation process.
Previous hourly tcpdump capture mechanisms would overwrite partial hour dumpfiles if restarted within that hour. Others would abort, rather than overwrite. With IDABench sensor, if a dump session is aborted and then resumed within the same hour, the partial dumpfile will be renamed and IDABench sensor will resume capturing. At the end of the hour, these partial files will be merged into one before the analyzer retrieves it, if either mergecap or tcpslice is available.
Myriad security issues have been considered, many of which pertain to the sensor/analyzer/analyst trust model:
IDABench does not make any efforts to harden your sensor and analyzer computer systems. It is the responsibility of the installation team or individual to adequately prepare these computers to operate in a potentially hostile environment, and must recognize that the IDABench components will likely be actively targeted by any attacker who has knowledge of their presence. Guy Bruneau has prepared an excellent secure SHADOW deployment package that could be adapted to support IDABench (http://www.whitehats.ca).
Additional resources to aid in system hardening include: Bastille Linux (http://www.bastille-linux.org), The SANS Institute Security Reading Room (http://www.sans.org/rr), AusCERT Unix Security Checklist (ttp://www.auscert.org.au/render.html?cid=1920)
IDABench is self-contained in an internal file system hierarchy that generally
adheres to the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/). By
this, we hope that anyone wishing to install IDABench in a chroot jail will
encounter few headaches; perhaps in our spare time (hehehe) we'll have a go at
it ourselves. The IDABench root directory can be anywhere on the system by
simply specifying the target location in the idabench.conf file prior to
installation. The target directory will be created and all necessary components
moved into it by the install_analyzer and install_sensor scripts. Common
locations are /usr/local/idabench and /opt/idabench.
The <IDABench root>/doc> directory contains specific documentation for the various
components, including a subdirectory, "historical", which holds docs specific
to the NSWC/DD SHADOW releases as well as some general analysis guidance.
Analyzer configs are in <IDABench root>/etc, with a separate directory for each
"site", then separate directories in that site for each tool that you want to
use. Read the comments in etc/idabench.conf and
etc/site0/site.ph
The <IDABench root>/lib directory contains shared modules, plugins, and headers
used by the various analyzer scripts.
<IDABench root>/bin contains the actual Perl scripts that do the bulk of the
analyzer work.
The <IDABench root>/var directory contains logs, a tmp directory for certain
volatile content, and a www directory. The www contents may be installed
elsewhere on the analyzer, if desired.
Finally, the sensor, if installed, gets its own subdirectory, to easily differentiate it in cases where both sensor and analyzer are installed on the same machine. These single-host installations, although perfectly legitimate, are not recommended for performance reasons.