 |
|
|
Intrusion Inc SecureNet Pro 4.0 SecureNet Pro is a software-only Network IDS product from Intrusion Inc., which runs on Red Hat Linux 6.2. Other products in the range include the �entry level� SecureNet PDS2345 appliance, high-performance SecureNet PDS5000 series rack mount appliance, the SecureNet Gig gigabit appliance and the SecureNet Provider IDS sensor monitoring system. The basic SecureNet architecture is two-tier, consisting of Sensors and Consoles. The SecureNet Pro Sensor operates in promiscuous mode, monitoring and analysing network traffic looking for evidence of intrusion, and then securely transmitting the information to the Console. Sensors are placed in specific locations at the network perimeter or within the network domain, and perform all core network monitoring, activity decoding, and intrusion detection tasks. Each Sensor is a completely stand-alone monitoring tool, storing all alerts and other recorded information on the local hard drive. Whilst in contact with a central Console, the Sensor will communicate alerts in real time. The Sensor will continue to store events locally when out of contact with a Console, and will synchronise database contents automatically once contact is re-established. The SecureNet Pro Console acts as the graphical user interface for viewing events, generating reports, configuring and administering the Sensors. The Console runs under Red Hat Linux, and Intrusion Inc. can supply a bundled hardware and software Console solution if required. Network and Security Administrators use SecureNet Pro Console to monitor Sensor activity and evaluate the status of the network, determining whether an attack or suspicious activity has occurred. SecureNet Pro was designed from the ground up to use a client-server communications architecture. As a result, virtually all SecureNet Pro administrative tasks can be performed from a remote location. When an administrator performs any administrative task, whether it be monitoring decoded network events, configuring a Sensor, or viewing session logs, a secure connection is established from Console to Sensor. The Sensor host does not make any outgoing connections - instead it sits passively waiting for connections from Console hosts, listening on port 975. Because SecureNet Pro is designed to allow for communication between software components over large distances, special caution has been taken to ensure that such components transmit information securely. All transmissions are protected using a dual-layered encryption and authentication scheme to protect against eavesdropping and session hijacking attacks. In addition to remotely administering multiple Sensors from a single central Console, it is also possible to control the same monitoring host from multiple Consoles. This is useful in situations where multiple network administrators need to monitor the same network simultaneously. There is no means to consolidate information between Consoles, however. In order to provide an enterprise view of the IDS implementation, a third tier is added to the management infrastructure in the form of SecureNet Provider. This adds an enterprise-level data store and more extensive management, reporting and monitoring capabilities across all Consoles and Sensors in an organisation. SecureNet Pro utilises what Intrusion Inc. refers to as �Shared Decision Logic� in order to speed up attack detection. In effect, SecureNet Pro incorporates a stateful IDS engine with protocol decodes to cut down on packet handling and string matching. The use of state tables allows the Sensor to determine which packets can be �ignored�. Only when the state checks determine that a packet is part of an existing session (or is attempting to initiate a new session) will SecureNet Pro attempt to perform the attack recognition process. The first step is to perform a full decode for up to 26 different protocols, and this means that even where string matching techniques are employed on the packet contents, a very much reduced subset of the overall signature database needs to be applied to each packet (i.e. pattern matching for DNS attacks will not be performed on HTTP packets) in order to detect a possible attack. SecureNet Pro also performs multi-path reassembly, which fully reconstructs fragmented datagrams from both Windows and Unix systems simultaneously. This, coupled with the fact that the protocol decode provides a much deeper understanding of attack behaviour than string matching alone, should result in fewer false positives more accurate attack detection. SecureNet Pro also makes use of the TurboPacket kernel modifications for Red Hat Linux which are designed to provide superior performance over the normal libpcap packet capture library. The TurboPacket kernel modifications resolve most of the efficiency problems related to packet capture on the Linux platform, updating the standard Linux capture facilities to improve performance and provide drop statistics.� It is claimed that TurboPacket has several benefits over BSD's capture mechanisms, one of which being that the Berkeley Packet Filter (BPF) is dual copy, whereas TurboPacket is single copy, theoretically allowing faster access to the packet contents by the application. Patches are available for the v.2.2.x kernels, and the modifications are integrated into the v2.4 kernel source (though without the �TurboPacket� naming convention). Note, however, that TurboPacket is implemented slightly differently in the 2.4 kernel, and thus SNP will run only on the 2.2 kernel at present.� We tested under Red Hat Linux 6.2 and found that SNP achieved higher levels of packet capture efficiency than other products we have tested which use standard libpcap. Global Filtering allows the administrator to designate the network packets that he is particularly interested in analysing, while filtering out those packets that are of no importance (for example, the administrator might deem that all packets from a particular subnet can always be considered �safe�, and can thus be ignored). Packet filtering occurs before the packets are analysed by the SecureNet Pro scripts, and thus enabling Global Filtering can help to increase performance of SecureNet Pro by minimising the number of packets the Sensor has to process and send to the Console. Naturally, it also has the effect of streamlining the information that is relevant to the administrator. Network packets can be filtered by MAC address, IP address or port number, and filtering can be either inclusive, exclusive, or a prioritised combination through the use of multiple entries in the filter configuration file. Whereas the appliance products are as close to �plug and play� as you could hope to get, some work is required to get SecureNet Pro 4.0 up and running on your own hardware.
Although the SNP software and signature packs are provided as RPM files to make installation as painless as possible, there is no way to automate the installation of the TurboPacket patch. This requires patching and building a custom kernel, and although the documentation is adequate, some familiarity with Linux is recommended. For those uncomfortable with this idea, Intrusion Inc. also provides fully configured turnkey appliances, of course. The SecureNet Console is an X Windows graphical utility which runs under Red Hat Linux. This too is provided as an RPM file to make installation as straightforward as possible. Once again, for those unhappy about the prospect of installing and using Linux, Intrusion Inc. can supply a turnkey Console appliance with the necessary software pre-installed. With Sensor and Console installed, all that remains is to configure the two to communicate. Authentication records are created on each host and session authentication is performed using a shared secret key. Strangely, the utility to do this is not password protected, and shared secrets are stored in plain text files. Communication between Console and Sensor is tied to specific IP addresses and encrypted using a choice of algorithms ranging from strong to exportable. Documentation is very good, though provided in electronic format only. General administration, configuration and reporting is performed using the SecureNet Console.
The Console software is very easy to use, and provides the means to manage multiple Sensors from a single location. The administrator must provide a user name and password in order to connect to the remote Sensor, and all communications between the two are encrypted securely using DES (56 bit), Triple DES (168 bit) or Blowfish (128 bit). It is not possible to assign roles on a per user basis � all administrators have equal access to the management functions of the GUI. A number of tabs along the top of the screen provide access to the Event Tree, Event List, Engine List, and the Engine(s) (Sensors) currently being monitored. Each Sensor must be defined within the Console, specifying the IP address, Sensor name, communication port, password and encryption algorithm which will be used to make a connection. The Event List is the main real-time monitoring screen, providing an ongoing display of the most recent alerts displayed in three separate panes depending on the alert importance: High, Medium or Low. Individual alerts are displayed as they are transmitted from the Sensor, and each event detected can result in one or more alerts being generated in each pane.
For example, an HTTP-based attack will generate a High priority alert containing details of the attack, a Medium priority alert containing details of the HTTP command that triggered the attack, and a Low priority alert providing details of the TCP session. Careful tuning of the alert parameters can eliminate one or more of these, so that only High priority alerts are generated if required. Lower level alerts are frequently of use, however, particularly in a forensic analysis situation � SecureNet Pro is capable of logging every single FTP or HTTP command which travels across the wire, for example. Double clicking on any alert brings up a separate window containing detailed alert information, including date, time, source and destination IP address, source and destination port and a detailed description of the attack which was detected (if applicable). Alerts can be filtered based on IP address, MAC address, port number, event priority or protocol, thus allowing the administrator to quickly home in on a particular group of events if required. The Event Tree also displays a list of events updated in real time, but this time all the events in the local database are organised into a hierarchical tree which can be sorted and grouped in various ways � by Sensor, by event type, priority, source, destination, and so on. Branches of the tree can be quickly expanded and collapsed, providing a rapid means of viewing event information from different perspectives. Older events can be �expired� automatically, or any particular group of events can be expired manually if they are deemed unimportant, thus allowing the tree display to remain uncluttered. Expiring events merely removes them from the Event Tree display, not from the event database where they are still available for reporting purposes. The Engine List provides an easy way to administer multiple remote Sensors from a graphical interface. It displays all currently configured Sensors, along with their associated status information. New Sensors can be added to the Engine List of the Console, and additions occur in real time, meaning that as soon as a Sensor is added to the Engine List, it can be managed by the Console. By right-clicking on any entry in this list, it is possible to modify the Sensor parameters or connect to it for monitoring or administration. For each Sensor that is currently being monitored by the Console, a tab is added to the Console main window. This window contains the Engine Administration Interface for the selected Sensor, and is split into three sections: Active Connections, Logged Connections and Module Database.
Active Connections is self explanatory, listing all of the currently active connections being monitored by the Sensor. A menu bar contains options that allow the administrator to perform certain actions against a monitored connection, such as toggling logging on or off, terminating connections, and so on. Connection termination is performed through the spoofing of a RST (TCP Reset) packet to both ends of a TCP circuit. The text display area is made up of three scrollable text boxes which display all data being sent from the server end of a TCP connection circuit, all data being sent from the client end of a TCP connection circuit, and SecureNet Pro notification messages, such as logging status indicators and connection termination indication. Any TCP connection being monitored from the Active Connection Viewing Interface can be logged to disk for later review, and certain detection modules can also specify that logging be initiated automatically when they are triggered. When logging is used, all data for a particular TCP connection circuit is recorded on the Sensor host and is available via the Logged Connections tab. Binary logging records the contents of a TCP connection in binary format, storing not only the actual connection data but also the delays between each packet received for the connection. Text logging, on the other hand, records the contents of a TCP connection into a text transcript. Full details of a logged session can be viewed or replayed by doubled clicking on an entry in the Logged Connections window. The final tab in the Engine Management Window is the Module Database tree, which displays all activity decoding modules that are currently loaded into a particular Sensor. This information is displayed in a graphical tree format to provide straightforward navigation of hundreds of loaded modules � each branch represents a module category including FTP, Mail, WWW, Miscellaneous (DNS, DDOS, Trojans, TCP/UDP/ICMP activity, Telnet, SSH, etc), and User Defined.
Individual modules (whether built-in or user defined) can be modified, deleted, toggled on or off, or have their priority changed, and the Module Database tree is divided clearly into Active and Inactive modules. All changes and additions are applied in real time, and it is not necessary to stop and restart the Sensor to activate changes. Although all the modules provided are written in Intrusion Inc.�s SNP-L scripting language (a C-like language used for writing advanced attack definitions) it is still possible for the administrator to add custom user-defined modules to the database via a simple graphical interface within the Console. Each module can be triggered on MAC address, IP address, port number, protocol or packet contents, all of which can be specified in a number of easy-to-use tabbed dialogue boxes. By careful use of the data scanning capability it is possible to define complex pattern matching attack signatures which can be applied to individual packets or complete TCP data streams � we used this capability to add several Web attack signatures for use during our testing, for example.
In addition to being able to search for simple text strings, SecureNet Pro�s data scanning facilities can be used to perform a variety of complex data parsing and analysis tasks. Once a module has been triggered, various actions can be initiated, including terminating the TCP session, logging all session data for later analysis (either as a binary or text log file), logging to the Console or sending an e-mail alert. If a more sophisticated attack detection method is required, it is also possible for the administrator to write custom scripts in the SNP-L scripting language and have these incorporated in the module database (SNP-L scripts must be compiled into byte code before they can be loaded into the Sensor). SNP-L is a very sophisticated pattern detection language which includes support for multiple data types, multi-dimensional arrays, a safe pointer implementation, and full memory protection. SNP-L allows for decoding of various types of network transmissions on a high level, without regard for host packet capture mechanisms, IP fragment reconstruction and TCP session reassembly. The resulting scripts operate within a totally secure and self-contained �sandbox� (similar to a Java implementation) within the IDS Sensor, thus preventing deactivation of the Sensor by careless or malicious programming. All in all, we found SecureNet Pro to provide one of the easiest and most straightforward means to add custom signatures of all the Network IDS products we have examined. Unfortunately, there is no way of grouping together sets of module definitions to make standard �security policies� which can subsequently be applied to multiple sensors (i.e. if you wanted to create a standard policy that omitted all IIS-related signatures). Management of a large number of Sensors is also very difficult with the existing product. There is no means of applying module definitions or signature updates to one or more Sensors in a single operation, and it is therefore necessary to manually log in to each Sensor via SSH in order to apply an updated module database. This does not scale well in large multi-sensor implementations. An enhancement to the existing product to provide centralised policy creation and distribution is planned for Q1 2002. The Linux Console includes a full-featured report generation engine that allows the administrator to create detailed reports regarding events received from Sensors, including information about which SecureNet Sensor generated each displayed alert.
The report generation engine is a stand-alone application, running as a separate process from the graphical Console. This allows the initiation of large report generation tasks (such as those that involve multiple gigabytes of event data) without locking up the Console. In addition, it is possible to run multiple instances of the report generation engine concurrently, allowing small reports to be quickly generated even if large report generation tasks are running in the background. The report generation engine allows the generation of highly customisable reports on events stored in the Console event database. Reports can be sorted, grouped, filtered, and formatted according to a variety of criteria, including date and time, MAC address, IP address, port number, event priority and protocol. Report output can be as HTML, CSV or plain text files, but consolidation of reporting data from multiple Sensors requires the SecureNet Provider component. Report parameters can be saved as templates allowing them to be run repeatedly without having to re-enter the reporting criteria each time, and completed reports are also saved for repeated viewing. The Console includes automated log rotation and archiving capabilities to help make console management easier. When events are received from a Sensor, they are written to the local event database on the disk of the Console host. Event data is organised into a tree hierarchy based on date of occurrence and event priority level, and tree branches are created as directories, with all event data stored in leaf portions. This method of database hierarchy organisation results in a maximum of three database flat files being created each hour; one for each event priority level. Data is stored in multiple flat files to ease the difficulties associated with archiving and deleting old data, and to improve database-searching performance. Various parameters tell the Console how large logs are to be allowed to become, when they are to be archived, and how to archive. By configuring these options properly, it is possible to Reporting and monitoring in a large distributed implementation is made easier by using the SecureNet Provider product. This creates a scalable, three-tier architecture where data is gathered from multiple sensors by a single console for centralised, consolidated reporting and monitoring. This is available as an extra cost option. Overall, SecureNet Pro 4.0 is an excellent product with few problems. The main issues noted were the inability to created logical groupings of signatures as �security policies� and the clumsy manual method of applying signature updates Sensor by Sensor. These could cause problems in large, distributed implementations, and could be addressed by the addition of a central policy and signature management console. This enhancement is planned for a future release. We also noted that on our test system - a Pentium III 1GHz box with 768MB RAM and an Intel EtherExpressPro 10/100 card � SNP 4.0 could not keep up with 148000pps of 64 byte packets. This is unlikely to be a problem in most real-world implementations, since we noted that it could handle up to a 75 per cent load of 64 byte packets, and with a �real world� packet mix it achieved a 99 per cent detection rate at 100 per cent network load. This indicates that the product can handle heavily loaded 100Mbit networks satisfactorily, and with 2GHz Pentium processors now available, a more highly specified host machine would provide even more headroom. In all other respects, it is hard not to be impressed with the SecureNet SNP 4.0 product. The software provides an extremely straightforward management interface, excellent reporting and alerting capabilities, a wide range of detection capabilities and a simple means of adding customised signatures. And, of course, it is possible to run the software on your own hardware, or purchase a highly-specified rack mount appliance from Intrusion Inc. Overall, we found SecureNet Pro to be one of the most intuitive and user friendly Network IDS systems we have tested. Company: Intrusion
Inc. UK Office:
Click here
to return to the Intrusion Inc Questionnaire�
|
 |
Send mail to webmaster
with questions or�
|
