 |
|
|
NFR NID v3.0 includes a family of NID Sensors that address a range of network requirements. The NID-320S and NID-320D support gigabit circuits and offer different options for monitoring fail over networks. The NID-315 and NID-310 support 10/100 circuits. The NID-315 and 320D can be configured to monitor dual circuits and full-duplex circuits in both directions, enabling a NID Sensor to maintain complete state information (the same is true in dynamically-routed networks). The NID-310 monitors a single circuit. NID Sensors are generally available as pre-configured appliances - the NID-310 is the only version which is available as a software-only product for those customers who wish to source their own hardware. The product under test is the NFR NID-320S, a Gigabit-capable, plug-and-play Intrusion Detection Appliance (IDA) based on a completely new detection engine, re-architected from the ground up in an attempt to handle the higher volumes of traffic that are found on typical Gigabit networks. The old two-tier management system where each appliance was controlled directly by a separate Administration Interface (AI) has now been completely superseded by a three-tier architecture (previously an option). Although this clearly improves reliability and scalability, it does mean that a separate, dedicated host is now always required for the NFR Central Management Server (CMS) component, possibly making it a less attractive proposition for those who require only one or two sensors. However, this kind of architecture scales much better than the old two-tier implementation, allowing multiple sensors to be configured and managed efficiently from a single console. The AI is a Windows-based application, and can be installed on any Windows 2000/XP host on the network. The NFR AI provides administrator access for querying data, viewing alerts, and configuring the NID Sensor. Multiple Sensors can be managed from a single AI, and in the latest release the AI has been extended to support multiple sensors at all points where policy is applied or data is extracted for reports. It is now, therefore, possible to apply a generic policy change to all sensors administered by a particular AI in a single operation. This makes a large NFR deployment much more manageable than with earlier releases. Access control capabilities allow granting of multiple levels of access to the NFR AI, enabling different administrators to have different capabilities, allowing and preventing access to queries, alerts and configuration. Once again, this has also been extended to allow each administrator to be restricted to specific sensors if required. All communications between AI, the CMS and the NID Sensor are securely encrypted. Central Management Server (CMS) Whereas previously the AI was designed to manage one or more NFR Sensor devices on a one-to-one basis, NFR recognised that it is desirable in a large distributed implementation to be able to fully manage multiple Sensors from a single AI, allowing a single security policy to be rolled out from a central source, or data from multiple NID Sensors to be consolidated into a single report. This is achieved by installing the NFR Central Management Server (CMS), which is the machine that is actually responsible for managing remote Sensors and their data, and which is now a mandatory component of any NFR implementation.
The remote NID Sensors usually all have the same basic configuration � that is, they typically have the same Packages, Backends, and alerts. However, each remote NID Sensor can be individually configured to have different Packages and Backends enabled, if required. For example, it is possible to enable the List of Mail Messages backend within the Mail package on all remote Sensors, or only those monitoring subnets which may carry SMTP traffic. Configurations can thus be managed on a station-by-station basis, or globally. Some elements within the NID Sensor configuration are unique to each station, such as the network interface to monitor, system-wide values, and access control information. For example, if each remote Sensor is monitoring a different network, the system-wide my_network value is different on each remote Sensor. These configuration elements for each individual remote NID Sensor are set on the CMS. In a three-tier implementation, the Administration Interface is used to access the CMS only � it can no longer communicate directly with a sensor. It is the CMS that performs the actual management operations on the remote NFR Sensors, and gathers data from the remote Sensors for centralised reporting purposes. One very important improvement in the latest version is the normalisation of alert data. Instead of providing alerts purely as free-format text descriptions as in previous releases, the CMS now stores structured alert information within its database allowing it to integrate more readily with third-party event correlation systems. The basic function of the NID Sensor engine is to monitor packets as they pass on the network and detect suspicious or malicious content. NID signatures are grouped by monitored protocol or function and distributed as a collection known as a Package. Packages contain one or more Backends which contain related detection signatures and optionally a logging capability known as a Recorder. As their name suggests, Recorders record data of interest to security analysis such as upper level protocol transactions and suspicious activity which can be retrieved using the AI's query capability. Although elements of the operating system and IDS code are stored on bootable CD-ROM to ensure that they remain tamper-proof, the NID Sensor still contains a large hard drive which is used as a repository for the Recorder (i.e. as temporary storage for forensic data and alerts until they are transmitted to the CMS). Once the data has been recorded, it is transmitted to the CMS where it is stored in a central database. The administrator can then use any NFR AI to query the data to look for trends or specific activity, view alerts to see possible intrusions or operational status messages, or view the operational status of any NID Sensor on the network. Queries can be applied against a single sensor or multiple sensors as required. The NID engine (nfrd) is an event driven process that sniffs packets from one or more interfaces on the NID. This has been completely re-architected for the latest release to allow the NID-320 to handle much higher volumes of traffic than its predecessor. Events are defined in N-Code, which is translated to C and compiled as it is written to the Sensor providing a considerable boost in performance over previous versions. Using functions available for N-Code, the engine passes the data from packets to other processes for storage, alerting, or further processing. The NID engine incorporates both protocol and signature-based analysis to provide a stateful architecture. Data streams and individual packets are examined, and fragmented packets are reassembled and sessions reordered with further examination of the resulting content. This ensures that attacks that are split across multiple packets are detected effectively. As is the increasing trend in the IDS industry, NFR signatures do not rely solely on simple pattern matching � they also maintain protocol states for many network-based protocols. This approach vastly decreases false alarm rates, reduces susceptibility to attack obfuscation techniques and provides an element of anomaly detection. For example, in many cases, attacks targeted at previously unknown vulnerabilities can be successfully detected as a result of the anomaly detection capability. The stateful architecture also improves accuracy and performance by being configurable to alert only on events which pose a significant threat (for example, if an IIS attack is directed at an Apache server then no alert needs to be raised). NFR has included the option to turn off such selective alerting in the latest release, providing the ability for administrators to be able to see ALL attacks of a specific type if they so wish, regardless of the potential outcome of the exploit. Note that because security events are defined using N-Code routines, it is possible for end users and administrators to modify the built in �signatures� where required, or even write their own from scratch. This makes NFR NID one of the most extensible and flexible IDS systems on the market. N-Code is now compiled on the sensor as packages are deployed from the CMS in order to make it more efficient. This can make the sensor unresponsive from the CMS for a few minutes during the deployment of a major policy update, but the sensor itself continues to detect and store alerts locally during this period. We found it impossible during testing to force the sensor to miss exploits during this update and compilation period. A Backend is one of the basic components of a NID Sensor, controlling the type of data that is written and how it is recorded. For example, different Backends included gather information about TCP and UDP traffic. Each Backend consists of several components: a Filter, configuration files, and a Recorder.
Backends are stored in logical groups called Packages. For example, the Denial of Service Detection Package included with the NID Sensor includes a variety of Backends that watch for various methods of denying network services. Backends can also share N-Code, which is helpful when there are several Backends that need to process the same data, thus helping to eliminate redundant processing. A large library of signatures is available, and is being enhanced constantly by NFR's Rapid Response Team (RRT). New signatures are placed on a secure NFR support site as soon as they are available and customers are emailed with details of the attack they address and other pertinent information. A secure download process enables administrators to quickly acquire and distribute the new signatures to all NID Sensors in the organisation via the Central Management Server. One point worth noting here is that NFR does not wrap all its Backends and Packages in to a single monolithic signature set, and there is no facility to download and install all new and updated signatures in a single operation. Instead, it is up to the administrator to select, download and install each individual Package. Although this can often be a laborious process, NFR maintains that it prefers to allow the administrator to make the final decision on exactly which packages should be downloaded and installed on his system (i.e. why bother downloading the latest batch of IIS signatures if you only use Apache?) - certainly a valid enough approach. Installation of the NFR NID-320 could not be simpler. The hardware comes pre-configured, and is designed to handle �normally� loaded Gigabit segments, though we did find this claim to be wide of the mark when a sustained load was applied to the network. Inside the 1U rack mount case are two Intel Xeon processors, 4GB RAM, a fast SCSI hard drive, CD-ROM, floppy, two Intel 10/100 network interfaces (one is used for management) and a Syskonnect dual-port Gigabit Ethernet card. NFR can also provide the hardware for the CMS too, although customers are free to source their own management platform. The software is provided on a bootable CD-ROM, and inserting the CD-ROM and powering on the appliance for the first time causes the system to boot into a simple installation routine. After entry of a few basic parameters, the built in disk drive is then initialised, checked and configured, and the IDS code is installed. The initialisation phase has been speeded up considerably in the latest release. The underlying operating system is a hardened FreeBSD with no shell and an absolute minimum of installed drivers and binaries. The kernel continues to reside on the CD-ROM, without which the appliance simply will not run. New versions of the software are also provided on a CD ROM and the upgrade process involves nothing more than removing the old CD and inserting the new one. However, patches and new signatures can be downloaded and applied from a secure support site and do not involve a new CD. The NID-320 comes installed with multiple network cards as standard - one of the two 100Mbps interfaces is used for dedicated management whilst the Gigabit ports are used for monitoring traffic. Once the NID-320 is running, a text-based console screen provides a real-time status monitor (CPU utilisation, packet reception statistics, and so on). There is also a password-protected administration menu, where the administrator can set the date, time and password, re-enter the basic configuration details that were requested during installation, and save the configuration details to (or load from) a floppy disk. The NFR AI is supplied on CD-ROM, and this follows the usual Windows installation routine. Documentation is generally excellent � very comprehensive and easy to read � consisting of a short Getting Started Guide, an extensive User Guide, and an N-Code Guide (for those who wish to program their own filters), all provided in PDF format. The hard copy manuals can still be provided on request - a nice touch. All configuration and monitoring is performed using the Windows-based NFR AI which, for the most part, is reasonably intuitive in use. The AI is password protected, and each user can have a basic set of permissions applied providing differing levels of access. For example, one administrator can be allowed to configure all elements of a NID Sensor, whereas another may be restricted to query operations only. There is also the ability to restrict administrator access on a per-sensor basis.
Once access has been gained to the NFR AI, the administrator is presented with three scrolling toolbars in the left hand pane, each selected by a tab headed Status, Packages or Administration. Selecting a menu option in the left hand pane brings up details relating to that option in the right hand pane. The Status menu provides a graphical version of the real-time status display of the NID Sensor on the AI, providing details of transmission rates, CPU, memory and disk usage, both current and historical. Also available in this menu is the View Alerts window (see later). The Packages menu provides a hierarchical list of the available Packages in the right hand pane. Selecting any package brings up a list of the Backends within that package, from where the administrator can view details of each Backend, including a detailed description of the functionality, a list of the variables used by the Backend, and even the N-Code that is behind it. Without a doubt, this makes NFR NID the most transparent and open system we have come across, with every signature open to the most detailed level of inspection. If a signature is not triggering in the expected manner, it is possible to examine the code to see why, and even alter it to produce results closer to those expected. Note that code cannot be amended within the NFR AI itself, merely examined. The Administrator menu provides four options: User Management, Variable Configuration, Package Configuration and Alert Configuration. The User Management option is used to create authorised AI users, each having a user name, password, and a list of permissions providing or denying access to various capabilities within the AI (Configure, Query, View Alerts and Diagnostics).
The Variable Configuration option is a key point of the system, allowing the administrator to fine tune the operation of the NID by altering various parameters used by each of the signatures. Each filter can have any number of variables associated with it, and these are provided with default values out of the box. For example, there is a BadFiles variable as part of the FTP Backend, which provides a list of files that are considered noteworthy (such as /etc/passwd) should someone try to access them via FTP. The use of variables such as this allows the administrator to add files which may be critical to his own environment, thus customising the operation of the NID Sensor without having to resort to modifying N-Code. This technique is used widely throughout NFR and is another example of the flexibility of the product, although it can cause the occasional problem where an attacker may be able to make subtle alterations to a file name (switching case, perhaps) in order to evade the system - this is the reason why some of our Whisker evasion attempts succeeded, for example. As new Packages and Backends are added to the system, the Variables menu option is updated automatically to reflect the new parameters available. It would be much more efficient and user-friendly, however, if the variables were accessible via the individual Package configuration screens to which they apply, rather than bundled together one place. Finding the particular variable you need can often be a time consuming and frustrating process.
The Package Configuration menu option is the point where the administrator can enable or disable Packages and individual Backends. It is also the point where new Packages and Backends can be installed once they have been downloaded from the Internet (or provided on CD). Applying new Packages is not always easy or intuitive, unfortunately. For example, it is not possible to select a whole group of Packages for installation in one hit, they have to be selected and installed one by one. When a new Backend replaces an older one completely, the upgrade is performed automatically. However, where there is overlapping functionality between old and new Backends, the older modules have to be disabled manually, and omitting this step can result in some rather alarming error messages (as well as have ramifications as far as performance is concerned). Since it is obvious that the engine is capable of spotting these dependencies, it would be nice if they could be determined at install time and superseded Backends disabled automatically. The Package Installer is one of the areas of the NFR product which we felt could do with an overhaul. Finally, the Alert Configuration option. Backends and parts of the NID Sensor system send alerts when something exceptional or noteworthy happens (a SYN flood, or ping flood, for example). Alerts are configurable, and can be sent to the systemlist Recorder (reserved for system-related alert messages), the networklist Recorder (a permanent record of alerts, from where they become available to the Alert Viewer), a pop-up window at the AI, SNMP trap, e-mail, pager, SMS, fax, Tivoli, HP OpenView or an external custom alert handler � each destination is known as an Alert Rule. They can also be compressed over a given time interval to prevent flooding the alert subsystem with repetitive alerts.
NFR has clearly put some thought into how the Alerts are configured out of the box, and the default configuration should suffice for most needs. Where changes are necessary, they are made easier by the use of Alert Groups. These are arbitrary groupings of alerts or alert sources, and although some are automatically created by the NFR system and cannot be modified, it is also possible for the administrator to create his own Alert Groups if necessary. Alert Rules can then be applied at group level, applying the same set of Rules to every alert or alert source within a group. Thus, the administrator could decide that all FTP-related alerts should be recorded only in the networklist Recorder, whereas all DOS attacks should be recorded and appear in the Alert Popup window. Applying Rules at group level makes sense in most circumstances, but NFR also allows the administrator to override the Alert Rules on a per-alert basis, if required. Configuration of alert responses has been well implemented in this system. There is not really a suggested �standard policy� out of the box with the NFR product, and so the administrator would be well advised to study the default configuration carefully. There are quite a few Backends that are disabled by default that some administrators would prefer to be active, though care needs to be taken over which are enabled given that some of them can have quite an impact on performance. Note that we use the term �policy� loosely, since it is not actually possible to define multiple policies and apply them to the appropriate sensors from the AI Console. Entire Packages or individual Backends can be enabled or disabled at the click of a mouse, and this can be accomplished on a per-sensor, multi-sensor or global basis as required. However, it is not possible to create specific policies (i.e. for DMZ operation, or a Web-only or FTP-only policy) and then deploy those to individual sensors. In this respect, the NFR AI is lagging behind in the sensor management stakes, a point of which NFR is only too aware - a new console is currently under development. Alerts can be displayed in the Alert Popup window as they happen (actually after a delay of up to three or four minutes), providing a rapid indication of incoming alerts which can be cleared as often as necessary.
In addition, suspicious events also appear in the Alert View window, which provides a view into the networklist and systemlist Recorders, where a more permanent record of the various alerts is kept. This window allows the administrator to view individual events, or filter them on various criteria such as date, time, IP address, severity, host, and so on. After the sensor has been running for a few days filtering becomes essential due to the sluggish performance of the underlying flat-file storage system used by the CMS - once the number of stored alerts reaches 20,000 or more the response time for queries becomes unacceptable. In fact, it would be quite easy to render the AI console virtually unusable (as happened a couple of times in our tests) by flooding the sensor with a large number of alerts in a short period of time. Once an alert has been acknowledged, a check box provides the capability to view only unread alerts. Another useful feature is the ability to consolidate like alerts, which groups all similar alerts together under sub-headings that include a count of the alerts detected in each category - this is a good way to reduce the on-screen clutter and makes it easier for the administrator to analyse the alerts. All alert data is stored on the NID Sensor itself only as long as is required to transmit it securely to the CMS database. Data is then transferred to the AI when queries are run or, of course, when an alert is raised. This can make retrieval times quite lengthy when there is a significant amount of data to be transferred, but NFR has thoughtfully included a �Stop� button on the AI and Alert Popup windows so that the administrator can interrupt Queries if they look to be transferring too much data. This propensity to move potentially large amounts of data in one hit between multiple NID Sensors and a central AI is another good argument for a dedicated IDS management network. Note that the introduction of the third tier to the architecture has also introduced some significant delays in transmitting alerts to the AI. Alerts are clear and very descriptive, and most of the fine tuning that would be required under normal circumstances can be achieved by amending the system Variables rather than tackling the N-Code source. Signature recognition performance is generally very good, and after an update to the packages (which has already been made available on general release to NFR customers) the NID-320 detected a high proportion of our attacks during testing. We have already mentioned the Alert Viewer, which provides a filtered view into the networklist and systemlist Recorders. NFR records far more than basic alert information, however, since it is capable of recording connection details, URL requests, FTP commands, mail messages � you name it, it can record it. This allows the administrator to:
Using the NFR Administration Interface, the query can be filtered based on any of the data gathered by a particular Backend, such as data type, IP address, port and time. Query specifications can be saved for re-use. In a distributed environment, via the three-tier architecture, it is possible to query data from individual remote NID Sensors or across all remote Sensors. In previous releases (without the CMS) it was only possible to query a single NID Sensor at a time. The latest software thus offers a huge improvement in manageability in large-scale deployments over earlier versions. Queries provide a near real-time view of the data gathered by the NID Sensor system � as soon as the information is written to disk on the CMS it is available for query (this is not instantaneous since data has first to be transferred from sensor to CMS). The NFR AI provides several different formats for the results of the query, from text-based lists to bar graph and pie charts. Each query is restricted to the data gathered by a particular Backend, so it is not possible, for example, to create a combined query that will report on IIS attacks, plus all URL requests made to the target Web servers around the time of the attack.
Another thing that is missing is detail on the vulnerability being reported, together with information on how it might be rectified � NFR reporting is quite basic in its presentation. Both the content and the presentation of the queries is fixed, and plans to incorporate Crystal Reports have so far only produced a set of high-level summary charts. What is desperately needed, given the amount of data that can be collected by NFR, is the ability to produce more customisable and meaningful reports. The NID-320 is an interesting evolution of the NFR product line, representing as it does the first major redevelopment of the underlying detection engine and architecture of the product since its inception. This has undoubtedly led to a significant improvement in performance, though a single sensor is still not capable of handling wire-speed Gigabit traffic. One of the biggest visible improvements in the latest release is the CMS and the resulting three-tier architecture. Although the CMS has been available for some time, this is the first release where it has become a mandatory component and this greatly enhances both the robustness and scalability of the product in enterprise situations. It would have been nice to see the continued inclusion of the ability to directly manage a sensor from the AI console in smaller environments. In larger installations, however � which are probably the target market for NFR, in truth � the three-tier approach, with its much more reliable centralised database, is a welcome step in the right direction. The use of a bootable CD-ROM makes the sensor both very secure and easy to update. Day-to-day management and monitoring tasks are also made easy by the Windows-based GUI, although administrators of larger networks will bemoan the lack of comprehensive policy management capabilities - the current version is far from scalable in this particular respect. Some form of correlation - either automatic or manual - would be welcome, and reporting could also be improved to make it more detailed and useful. There is plenty of data available, but no way to combine queries across multiple Backends, and the recently-added summary charts add little in the way of substance. A new Console is currently under development which will hopefully fix the current shortcomings. Signature coverage has improved considerably in recent releases, and detection capabilities out of the box are good. After an update to the packages (which was made available to NFR customers immediately), detection rates in our tests were improved further, recognising over 90 per cent of our test cases. Of course, the real beauty of NFR is the fact that if there is a signature lacking, or one that does not work quite as you would expect, you can modify or create your own using the N-Code programming language. As with any programming language, N-Code requires time and effort to master, but as a �cross� between C++ and Perl it will feel instantly familiar to exponents of either, and anyone with any programming aptitude at all should be able to get to grips with it in a reasonable amount of time. Whilst mastering N-Code is by no means essential to successful operation of the NFR product, it does make it the most customisable and extensible of all the products we have reviewed. Beware, however - such power can come at a price, since a poorly written piece of N-Code could significantly impact the performance of the sensor. Despite the power and flexibility offered by the customisable system variables and N-Code filters, NFR remains very simple to use for the inexperienced administrator (with the single exception of the Package Installer). The stateful architecture also makes it accurate and fast, and resistant to most currently known IDS evasion techniques. All in all, we found that the NFR NID-320 offers an extremely good balance between ease of use and flexibility. Company
name: NFR
Security, Inc Click here
to return to the NFR questionnaire |
Send mail to webmaster
with questions or
|