Safe and Sound

The SecureNet sensors, positioned in the first tier, inspect network traffic and store events based on signature policies on the sensor. These Red Hat Linux hardened devices use a Linux CLI (command-line interface) and the SecureNet sensor packet-inspection engine. SecureNet sensors can forward their intrusion-event data to the Tier 2-positioned SecureNet Provider Manager, a Microsoft Windows 2000 server application that makes extensive use of SQL2000 data-mining tools. The manager application inserts records into a relational database for later analysis and can filter data before sending it to the client's real-time monitoring module. The interface to the entire system is in Tier 3 of the SecureNet Provider client and its associated tools (see diagram).

Intrusion shipped beta versions of its products--SecureNet Provider 2.1, SecureNet WBI (Web-based interface) 1.4 and SecureNet Sensor 4.5--to Network Computing's Real-World Labs® at Syracuse University. An Intrusion engineer spent about three hours configuring the equipment--a service available to all customers. The engineer removed triggers for erroneous NNTP and SMTP events particular to our network; performance-tuned the SQL data-transformation service-replication frequency; and gave me a quick overview of the manager's and client's features.

The SecureNet 7145 sensor was connected to a gigabit fiber link from a NetOptics passive regeneration tap, mirroring the university's OC-3 Internet link, which averages 225 Mbps (60,000 packets per second). The Intrusion engineer connected the sensor to the SecureNet Provider Manager 7345 server via crossover cable and loaded the manager software and signatures.

Powerful Functionality

I gave the sensor 48 hours to get familiar with our network traffic. It populated the various SQL databases with the IDS events, giving me some historical data to work with. I started my tests in Tier 1 using only the sensor features. Linux-savvy administrators will feel very comfortable with the CLI available via SSH (Secure Shell) or serial console to gain an unlimited amount of information from standard Linux commands. The new Web interface is another option.The Web interface separates basic and advanced configuration options with onscreen help that explains functions, performs input validation on form fields and shows input samples for global filters, a welcome cap-ability for novice users. Global filters let the sensor exclude matching packets against its signature event database, and consequently trigger events based on items such as source and destination IP or MAC (Media Access Control) address. Post-signature event filters allow SNMP and

e-mail notification on triggered events so sensors alert administrators. The interface is powerful enough to activate and deactivate various IDS signatures, change classifications on those signatures, and apply and signature filtering. However, the Web interface has a major flaw: It gives all rights to all users, rather than designating variable rights based on role.

This version of the sensor engine builds on previous versions, but it's unbuffered, which, according to Intrusion, should let the sensors approach gigabit-speed packet matching. The sensor contained very few unbuffered protocol-decode signatures, so I did not see the performance gains Intrusion promises. In fact, the sensor could not handle the traffic I was sending it and dropped about 1 percent.

Custom Tuning

While I was evaluating the sensor and Web interface, the Tier 2 provider manager was receiving events from the sensor and storing them in the manager's SQL databases. The stored data is used by the forensics and reporting modules--part of the client application.The Tier 3 SecureNet Provider Policy Editor lets you create customized signature policies that can be deployed to each sensor. You can custom-tune any default Intrusion signature. You also can create new signatures to address immediate threats based on priority, string matching, payload size or IP/MAC destinations. These signatures can be grouped into policies.

The Tier 3 Nexus product provides a management interface into your sensors that lets you upgrade signature databases, install new sensor engines and other sensor software, reboot or connect via SSH to each sensor, and track changes made to each device.

I fired up the Tier 3 SecureNet client from my desktop machine. The real-time monitoring module connected to the manager and immediately started displaying IDS events. To increase performance, these events were cached from the manager to the desktop's Microsoft SQL Desktop Engine database. As the events populated the three severity levels, I could drill down into particular events with a double-click.

The event display provided a detailed description of potential attacks, IP/MAC and other address-like information, how the signature was triggered and possible solutions to the threat. Using the tree-builder function, I created different views of the events sorted by signature name, source or destination address information, sensor location or name, and priority.The Forensics module let me query and analyze past events stored on the provider manager's SQL databases. Using the same interface and similar tree-builder application as the monitoring module, I quickly constructed queries that let me make sense of the 5-million-row SQL database. The queries run in parallel against the manager's database, and return results in 10 to 15 seconds. I was able to store "case files," or groups of related events with comments, by dragging and dropping IDS events, which allows for long-term research and collaboration.

The Reporting module uses Microsoft Excel pivot tables and Access to query the database and create graphs of the associated data. The software provides canned reports and the drill-down reports can be customized and pasted into other applications for presentations.

Christopher T. Beers is a Unix systems engineer at Syracuse University. Write to him at [email protected].

Post a comment or question on this story.