 |
|
|
Cisco IDS-4235 V4.0 Cisco IDS (formerly known as NetRanger) is a network-based IDS, which means that it monitors all traffic on a subnet and compares individual packets, or groups of packets, against known attack signatures in an attempt to identify illegal activity. Cisco IDS was one of the first to be supplied as a dedicated network appliance, with all hardware and software necessary to get you up and running. The Cisco IDS is a hybrid protocol decode and network grep (pattern-matching) IDS, and the latest software release sees a move from the �traditional� OS of choice - Solaris - to Linux. The sensor appliance comes in four flavours, each running a heavily modified version of Red Hat Linux, hardened and complete with a familiar Cisco Command Line Interface (CLI) and customised packet drivers written to cope with extreme traffic loads on network interfaces in promiscuous mode:
For the purposes of this test, Cisco provided the IDS-4235. In something of a departure for Cisco, the hardware is manufactured by Dell � a PowerEdge 1650 server in a 1U chassis. This chassis houses three drive bays (a single IDE drive is installed), dual redundant power supplies (one is installed by default), and two on-board copper Gigabit network interfaces (auto-sensing 10/100/1000Mbps). The general build quality of the sensor appliance appears to be excellent, and accessibility for maintenance or upgrades is extremely good, the top of the chassis hinging open in two sections at the press of a single button. Management is designed to be performed over a dedicated network using one of the two built-in network interfaces in the sensor. Management of IDS Sensors is available via two products:
Also available is Cisco Threat Response (CTR), which has been incorporated into Cisco's product line through the acquisition of Psionic Software. CTR uses a just-in-time investigation of the targeted host to determine if the attack was successful. A three-phase approach is used to accomplish this:
Installation tasks are minimal thanks to the turnkey appliance approach. However, it is necessary to log in at the sensor console and work through a text-based installation routine in order to set up the initial communication parameters of the sensor so that it can communicate with the management console. Cisco has done a good job of implementing the Cisco CLI on the Linux platform so that the IDS sensor has a familiar look and feel to anyone with Cisco experience. Whichever management console is being used - Cisco IDS Device Manager (IDM) or CiscoWorks VMS - then all that is required is to define the communication parameters for each sensor to begin managing and monitoring. All documentation is supplied on CD-ROM and is also available on-line. As usual, the quality of the documentation is more than adequate, though we still mourn the loss of the wonderfully detailed hard-copy manual that used to accompany the earliest versions of the IDS product (back when it was known as NetRanger). For remote management functions, Cisco bundles the IDS Device Manager (IDM) with the sensor, along with the IDS Event Viewer (IEV) for monitoring events and alerts. In addition, those Cisco diehards will be pleased to learn that there is a full-featured Cisco CLI environment available when logging into the sensor locally. Everything that can be configured via the GUI utilities can also be configured via the command line. The IDS Device Manager is a web-based Java application that resides on the sensor and is accessed via a secure, encrypted TLS link using standard Netscape and Internet Explorer web browsers to perform various management and monitoring tasks.
The IDM user interface is very intuitive and easy to use, the main focus of which is the tabbed tool bar along the top of the screen. This contains tabs for Device, Configuration, Monitoring, and Administration, each of which brings up a different hierarchical menu in a panel down the left hand side of the screen. The main window or Content Area is in the right-hand panel, and any changes made are not written to the sensor until the Apply Changes option is selected. It is possible to restrict access to the sensor to specified hosts, though all allowed hosts have equal access. It is not possible to provide granular access to discrete functions of the IDM on a per user or per group basis. By default, the most critical signatures are enabled when the IDS Device Manager is first installed, representing a useful starting point for policy definition. Signatures are grouped according to their �microengine�, each microengine representing the implementation of a different type of detection technology. Some may be concerned with single packets, others with groups of packets (to detect floods and sweeps). Some may perform protocol decodes whilst others focus in pattern matching. This architecture makes the Cisco IDS very flexible and readily extensible - custom signatures can be created which make use of the capabilities of each engine. However, when searching for built-in signatures to tune it can make life difficult unless you know exactly what they do and in which engine they reside. Some form of search and filter capability would be useful in the signature editing section of IDM, especially since it is so slow to recall large numbers of signatures at a time.
The Signature Configuration screen provides the means to enable or disable signatures, change the severity level or action associated with a signature, and add new signatures. Unfortunately, it is not possible to apply a parameter change across a number of signatures at once. For example, if it is required to change the Severity Level of all Finger signatures from Low to Medium, this would entail editing every signature individually. Even though IDM is designed for single device management only, this would be a useful feature to add (it is available within CiscoWorks, however). From the Signature Group screen it is possible (although painfully slow) to display all the individual signatures at once by clicking on All Signatures, or the signature list within a group can be displayed by clicking on the appropriate group name. At the group level, a clear circle indicates that no signatures in that signature group are currently enabled, a solid circle indicates that all signatures are enabled, and a partial circle indicates that at least one signature in that group is enabled. It is possible to enable or disable all signatures in a group with a single click.
Selecting a signature group displays a list of signatures within that group. Once again, a clear circle indicates that the signature is currently disabled, whilst a solid circle indicates that the signature is enabled. The signature display within each group informs the administrator which are built in and which are custom signatures, the signature IDs and names, severity levels and actions (block, IP log or TCP Reset). The sensor can be configured to block an attack by generating ACL rules for publication to a Cisco IOS router. Each individual signature can be edited from here, and even built-in signatures can have their parameters amended, allowing the administrator to adjust such settings as the threshold level, severity level, action, alarm interval and alarm throttle (fire every time, fire only the first time, or summarise). Naturally the parameters change from signature type to signature type. False positives can be reduced by defining filters for a sensor to enable and disable alarms that have specific hosts and networks as their source or destination. Cisco IDS includes both TCP session and IP fragment reassembly capabilities, and these are now switched on by default (unlike earlier versions). User-defined reassembly options allow fine tuning in an attempt to ensure that the sensor does not allocate all of its resources to datagrams that cannot be completely reassembled, either because the sensor missed some frame transmissions or because an attack has been launched that is based on generating random fragment datagrams. As you would expect, the Cisco sensor is also stateful, and the number of open sessions that can be tracked has been increased by an order of magnitude from the previous release of the software (although there is currently a parameter that requires adjusting in order to achieve this). It works well, reducing the incidence of false positives and flooding caused by attack scripts and replay tools such as Stick and Snot. When testing the Cisco sensor, we noted relatively low incidences of false positives during Stick and Snot floods. The IDS-4235 also proved itself to be resistant to almost all of the IDS evasion techniques we used against it.
When an attack is detected, the sensor generates an alarm, which is sent to the event monitoring host, where the IDS Event Viewer (IEV) writes it to an ASCII event log and to a MySQL database. Once in the database, it can be viewed using the IEV. Event throttling is employed to ensure that a flood of identical events does not cause a Denial of Service situation, and all alerts are stored locally on the sensor�s hard drive in case of communications failure between sensor and console. This throttling mechanism worked well in our tests. Various logging capabilities are built into the Cisco IDS software, including:
It is possible to specify an FTP server to receive event logs at regular intervals. When an attack is noted, as well as logging to file and alerting to the IEV console, the sensor can instantly cut TCP sessions, and dynamically manage a Cisco router�s access control list to �shun� intruders, thus preventing further attacks from that source. This feature can be temporary, if desired, or maintained indefinitely. The rest of the network traffic will function normally - only the unauthorised traffic from internal users or external intruders will be removed. Clearly this feature needs to be managed carefully, particularly where there is the chance of false positive alerts � you don�t want to accidentally cut off your entire accounts department from their network just because someone typed a password incorrectly. The IDM does not provide any means to push updates and signature packs to multiple sensors across a network. However, it is possible to configure sensors to perform their own automatic signature and service pack updates, so that when the updated files are loaded on a central FTP server, they will be automatically downloaded and applied to each sensor. The sensor can be scheduled to check the FTP server at regular intervals, or can be forced to perform an immediate update via the IDM interface. SCP can also be used for secure transfer of update files. CiscoWorks VMS is the extra-cost �umbrella� management system for a range of Cisco devices such as firewalls, VPN and, of course, IDS. For those organisations who find the included IDM/IEV combination to be too limited, then CiscoWorks provides enterprise-level IDS management, monitoring and alerting capabilities. Login to the CiscoWorks console is controlled by a user name and password combination. User accounts are created within CiscoWorks (or can be managed by ACS) and each account can have different levels of access to the system, providing granularity of administrative function. Once logged on, a hierarchical menu down the left of the screen provides access to CiscoWorks� administrative functions (security settings, logging options, server configuration, user account maintenance, and so on), and the Management and Monitoring Centre. This contains modules for the IDS sensor that provide very similar functionality to IDM and IEV, but which offer more flexibility in some of the configuration functions together with the ability to manage multiple sensors across the corporate network. Sensors can be logically grouped together - perhaps according to location or function - and an Object Selector window allows the administrator to select either an individual sensor or an entire group to which all subsequent administrative operations will be applied. Parameters such as port mappings, event logging and attack blocking can then be set globally, or at group level, and can be made mandatory at either of those levels, thus preventing them from being overridden on the individual sensors. Clearly, not all admin functions are available at group level, since some are tied closely to the operation of the individual sensor. However, there are some - such as filters, signatures and reassembly options - that it would be preferable to be able to set on a global or group basis and then override (if allowed) at the sensor level.
Unfortunately, that capability will have to wait for a future release. There is a workaround, however, since CiscoWorks includes a Copy Wizard function, that allows the administrator to copy certain key parameters from one sensor to another, or to a whole group. Whilst not quite as slick a means of deploying signature changes as setting them at group level, it is still a powerful feature. Unlike with the basic IDM utility, signatures are arranged in six groups within CiscoWorks:
Although all the built-in signatures are gathered together under a single menu option it is much easier to find and edit them here than it is in IDM because of the excellent search capability. Any one of a number of search fields can be selected - signature ID, engine name, enabled/disabled, tuneable, severity or action - and a value specified in order to bring up the signature, or group of signatures, required.
Thus it is possible to search for all signatures whose description contains the phrase �Back Orifice�, or all signatures that have a severity setting of �High�. Each signature can then be tuned or edited individually, or as a group. This is a very powerful feature that allows the administrator to alter a setting for an entire group of signatures on one operation. For example, it would be possible to search for all signatures in the SERVICE.FTP engine and set the severity to �High�. You can only search on one parameter at a time, however, which is a shame - it would be nice to be able to search of all signatures with a severity of �Medium� in the SERVICE.FTP engine, for instance. It would also be nice if the keyword being searched for appeared in a drop-down menu where applicable, since some parameters - such as the list of engine names - are not easy to remember. In addition to changing the severity and alert actions (Log, Reset Connection or Block), it is also possible to tune the microengine that underpins the signature. Here there is a huge number of parameters to choose from allowing very fine-grained control over the operation of the signature. New signature packs can be obtained from a central location and applied via the CiscoWorks GUI.
As with IDM, the CiscoWorks interface allows the creation of filters to include or exclude specific alerts based on signature ID, source or destination IP address. Whenever changes are made to a particular sensor configuration directly, a �Pending� flag is set awaiting confirmation by the administrator that the changes can be applied to the sensor. Changes can be deleted from the Pending screen if they are no longer required, and a full change history is recorded, with every configuration file that has ever been applied saved as an audit trail. It is also possible to roll back a change to a previous configuration if required. When changes are applied at the global or group level, there is a two-stage process to deploying the updated configuration files - these operations are accessed via the Workflow tab. Firstly, the configuration file is generated to reflect the changes made. Then the configuration file is deployed to one or more sensors. Both of these operations are �one click�, allowing updates to be deployed to multiple sensors around the organisation quickly and easily. As with configuration, two utilities were provided for this test: CiscoWorks 2000 and the IDS Event Viewer (IEV). The IDS Event Viewer (IEV) is a Java-based application that enables the administrator to view and manage alarms for up to three sensors. It utilises the following applications (all of which are installed by default):
With the IDS Event Viewer it is possible to view alarms in real time or via imported log files, and customised filters and views can be created to help manage the data. Event data can be exported for further analysis, if required, and the IEV also provides access to the Network Security Database (NSDB) for detailed signature descriptions.
Unless the administrator specifies otherwise, the sensor will publish its audit event stream to the host on which the IDS Device Manager has been installed. It is also possible to identify additional hosts to which the sensor can publish its audit event stream. The IDS Event Viewer user interface consists of a main menu, toolbar, left-hand configuration pane, and a right-hand view pane. Filters enable the administrator to customise and refine the view of event data by specifying alarms to be excluded. Any number of custom filters can be stored in the Filters folder and applied to any default or user-defined view. Events can be viewed in �real time�, with a user-configurable refresh interval, or retrieved from the local database for later analysis. It is also possible to view alarm data stored in log files that are imported into the IDS Event Viewer, as well as to export data from the IDS Event Viewer tables to an ASCII file for analysis via third party applications. Views enable the administrator to analyse filtered event data from a specified source. The IDS Event Viewer ships with five default views (by source address, destination address, sensor ID, signature name, or severity), and the IEV provides the View Wizard allowing the administrator to create and store user-defined views in the Views folder. Multiple views can be opened at the same time, the IDS Event Viewer placing one view behind the other and displaying a tab for each. Once a view is active, it is possible to expand an event to view all the details, such as signature name and severity level, associated with that event. When viewing individual alarms associated with an event the administrator can review detailed alarm and signature information, add notes, or set a status for the alarm indicating what action should be taken by the IDS Event Viewer or by someone else in the organisation. Notes can be up to 255 characters in length, and are stored as part of the alarm entry in the database.
Certain alarms may have context data associated with them. Context data provides a snapshot of the incoming and outgoing binary TCP traffic (up to a maximum of 256-bytes in both directions) that preceded the triggering of the signature. This provides the means to view the URL or the entire FTP session that may have triggered an event, for example. The IDS Event Viewer includes a database archival feature that ensures available disk space for incoming events. Two thresholds control the archival process � the first is a time interval and the second is a maximum number of records. Crossing either threshold triggers the archival processes. CiscoWorks does not provide a real-time dashboard facility, but the Security Monitor Event Viewer is very similar in appearance and operation to IEV, except that it can handle events from more than just IDS devices. Once the devices to be monitored have been defined to the Security Monitor in the Device tab, the Monitor tab can be used to monitor both the status of each device, and the events that are raised. Unlike IEV, there is no facility to define custom views, but the default view is extremely comprehensive, including the signature name, ID, severity, source and destination, and brief details of what triggered the alert. If more detail is required, it is possible to select a single alert or a group, and view complete context data, host names, NSDB entries (for detailed alert information) and statistics (such as how many times a particular alert has been seen). Although custom views cannot be defined as such, it is possible to drag and drop columns of data to re-order and resort the entries. For example, dragging Source IP to the left of the screen sorts and groups (and counts) by source IP. Dragging Severity to the left of the screen creates a new view sorted and grouped by the severity code. The entire contents of the database can be expanded or collapsed using menu options to the left of the screen, providing a quick way to switch between detail and summary views. As with IEV, it is possible to view the full context buffer for an alert - unlike IEV, the CiscoWorks Event viewer is capable of showing context data for an entire group of alerts in the same window. On selecting any of the alerts, menu options provide the capability to block the host that perpetrated the exploit, or the entire network from which it came. Although it may appear simple at first glance, and although it is not the most intuitive interface when it comes to resorting, expanding and collapsing the entries, the Event Viewer is actually a very flexible and powerful tool.
One final option worth mentioning is the Event Rule capability. Event Rules allow the administrator to specify related criteria, thresholds and actions in order to provide some very basic - if completely manual - correlation. For example, a rule could be created to watch for a particular type of port scan from three sensors. If the scan is detected on all three sensors within a given time frame then an alert is generated, an e-mail is sent to the administrator and a script is run to reconfigure the firewall. Although detailed reporting out of the box is limited to the capabilities of the IEV, CiscoWorks provides both the Event Viewer and a reporting tool - a huge improvement over previous releases.
Reporting is fairly basic, with no means to customise the built in reports or create your own. Six audit reports are included (mainly concerned with audit logs and sensor configuration changes) alongside 15 IDS alert summaries, including:
On choosing a report, the administrator is presented with an extensive set of filtering options including severity, date, source, destination, signature and category. The report can then be scheduled to run immediately or at a later time. If scheduled for a later time it can also be made to repeat at regular intervals, and the finished report can be e-mailed to one or more recipients. The completed report is viewed on-screen in a browser window and can be printed out using the standard browser print function. No other print or export options are offered. The summary reporting is adequate, and more detailed forensics reporting is offered via the Security Monitor Event Viewer we mentioned earlier. This provides the ability to enter a date and time range in order to filter a particular set of alerts from the database - the drag and drop columns coupled with the capability to expand and collapse groups of entries provides a useful means to �slice and dice� data in different ways in order to drill down to events that are of interest. It is not possible to annotate events or tag them as resolved or under investigation, however - strange, given that this feature is available from within IEV.
The biggest worry with regard to forensic investigation is the automatic database pruning operation, which is set to remove old alerts from the database once it reaches 2 million records in size. Cisco has determined this as the optimum size to provide the best performance in terms of insertion rate. Unfortunately, old records are not archived, and are thus lost forever. Clearly if more extensive forensics reporting is required, then third party products are the way to go. Cisco has struggled in the past to produce enough functionality out of the box to make the product attractive in its own right without the use of third party management and reporting tools. That may be about to change with the release of 4.0. IDM and IEV have improved tremendously since the last release, and whilst they do not (and are not designed to) offer enterprise-class centralised management and monitoring capabilities for multiple sensors, they do provide the means to manage a limited number of sensors (three at the time of writing, shortly to be increased) on a one-to-one basis, and do an excellent job of it. IDM can be slow when making changes to signatures, but the new IEV is a real triumph, providing a nice real-time monitoring and historical analysis tool. CiscoWorks is where it steps up a gear into true centralised management, monitoring and reporting, and although there are still one or two enhancements we would like to see, the product shows real promise. As it stands, there is centralised policy management and deployment (still with some rough edges), real time monitoring, forensic analysis and summary reporting all from the same console. Signature editing, tuning and creation are well catered for, and the interface makes it simple to search for and make changes to large groups of signatures in one hit. A two stage config generation and deployment feature makes it as safe as possible to work on policies without accidentally wiping out production sensors, and yet if something was to go wrong, there is the ability to roll back to a previous configuration. We would like to see some further slight improvements in terms of signature search in the editor, modification of signatures at a global or group level as well as at sensor level, and the ability to annotate alerts from within CiscoWorks. Some means of accessing older alerts that have been pruned from the database for complete forensic analysis would also be extremely useful, as would more extensive cross-sensor correlation capabilities. Performance was very good across the board. The recognition rate was excellent both in terms of absolute coverage and accuracy, with very few misidentified events or false positives. Tracking of open connections has been improved significantly for this release, although there is still some work to do on memory management to prevent failure of the sensor when pushed significantly beyond the supported connection limits of 500,000 (this should have been resolved by the time you read this). Detection rates are also very high, as you would epxect from a 200Mbps device. Although only validated to 100Mbps in our tests, all of the performance tests were handled with headroom to spare. Company
name: Cisco
Systems, Inc. Cisco
Systems Click here
to return to the Cisco questionnaire |
Security Testing |
Send mail to webmaster
with questions or
|