 |
|
|
Originally known as Network Flight Recorder, NFR Security was founded in 1996 by Marcus Ranum, well known �firewall guru�. The eponymous Network Flight Recorder product spent its first few iterations as a software-only IDS (it is currently on Version 5.0). It was notable for its use of a bootable CD-ROM containing the operating system and IDS code to provide the most secure operating environment possible for a software-based product. The latest product to be produced by the company is the NFR NID-200 (the software-only version is the NID-100), a plug-and-play Intrusion Detection Appliance (IDA) based on the same basic NFR 5.0 code, but bundled with high-performance hardware designed to provide high levels of performance on heavily loaded fast networks. Most of the information in this evaluation that is not hardware-specific will apply to both the NID-200 and NID-100 products. In simple installations, the NFR system consists of two components: the NID sensor and the NFR Administration Interface (AI). In a distributed environment, where multiple sensors are managed via a single AI, a third component � the NFR Central Management Server (CMS)�� is introduced to form a three-tier management system. The AI is a Windows-based application, and can be installed on any Windows host on the network.
It is recommended that each sensor has two network cards installed, one in promiscuous mode for sniffing the wire, and one which is connected to a dedicated management network on which the AI host is also installed. This ensures that management and monitoring functionality is not affected by excessive activity on the live network, as well as allowing the sniffing interface to exist without an IP address. 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, though without the Central Management Server (see below) it is possible neither to apply a single security policy nor consolidate alert data across all Sensors. 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. All communications between AI and NID Sensor are securely encrypted. Central Management Server (CMS) Whereas the AI is designed to manage one or more NFR Sensor devices on a one-to-one basis, 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 an NFR Central Management Server (CMS), which is the machine that is actually responsible for managing remote Sensors and their data. 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. The configuration files on the remote NID Sensors are kept in sync with a process called �mirroring�, an automated process that runs once an hour (although the administrator can apply changes instantly when required using the Start Mirror option). 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 actually used to access the CMS. 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. All communications between the various components are securely encrypted. The basic function of the NID Sensor engine is to note packets as they pass on the monitored network. Backends (i.e. signatures) loaded into the Sensor engine then determine which data is interesting, and this is sent to the Recorder, which tabulates the data. When appropriate, Backends also prompt the Sensor engine to send an alert. Although the operating system and IDS code is stored on bootable CD-ROM to ensure that it remains tamper-proof, the NID Sensor still contains a large hard drive which is used as a repository for the Recorder (i.e. as storage for all forensic data and alerts). Once the data has been recorded, the administrator can 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 the NID Sensor. Behind the scenes, other processes manage the data and system. For example, the space management process manages disk space, whilst the access control process manages access to data, alerts, and configuration. The NID engine (nfrd) is an event driven process that sniffs packets from one or more interfaces on the NID. Events, such as the passage of time, arrival of a packet, or command and control messages from other parts of the system, tell the NID engine to take some sort of action. Events are defined in N-Code, which is processed by an interpreter in the NID engine. 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. Both 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). A large library of signatures is available, and is being enhanced constantly by NFR's Rapid Response Team (RRT). The size of the signature library was increased significantly mid-2001 via the acquisition of Anzen Computing�s technology and the gradual incorporation of the Anzen Flight Jacket signatures and reports into the NFR product.� 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. If the CMS is not installed, new signatures must be distributed to each NID Sensor individually from the AI. 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 IDS systems on the market. 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. Filters - The Filters are written in N-Code, NFR�s proprietary event-driven language (N-Code training is available), and list the events that cause the NID engine to begin gathering data. For example, the N-Code for the UDP Backend begins recording data from packets if the packet contains a UDP header. The Filter also tells the engine what to do with the data, and functions available in N-Code tell the engine what kind of data to record and then pass that data on to the Recorder. For example, the Pingflood Detector Backend tells the NID engine to track source and destination IP addresses, the number of packets sent, and the elapsed time since the last packet. All of this information is sent to the Recorder. Other functions in N-Code tell the engine what data should be sent as an alert. For example, the Pingflood Detector backend includes N-Code that tells the NID engine to send an alert to the alert manager when more than a certain number of ping packets are sent to a certain IP address in a certain time. Configuration files - The configuration files provide information about the title of the Backend and other information displayed via the NFR AI. More importantly, the configuration files detail the types of data that are being examined. For example, the configuration files for the UDP backend indicate that the first column of data recorded is a source port and should be labelled as �Source Port� on the NFR AI display. Recorders - The Recorder writes the information gathered by the Backends to files. NFR NID Sensor includes two different types of Recorders: the List Recorder and the Histogram Recorder. The List Recorder tabulates information about individual events, while the Histogram Recorder stores statistical data. For example, NID Sensor includes two Backends that examine e-mail traffic. The Mail Messages Backend uses a List Recorder, storing information about each mail message as a separate record. The Mail Sender / Recipient Backend, on the other hand, uses a Histogram Recorder, storing the number of times that e-mail was exchanged between two users. 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. Each package consists of several different components: Backends, shared N-Code, and configuration files. New Backends and Packages produced by the NFR Rapid Response Team (RRT) can be downloaded and applied to remote NID Sensors automatically via the Package Updater utility. Installation of the NFR NID-200 could not be simpler. The hardware comes pre-configured, and is designed to handle heavily loaded 100Mbps segments with ease. Inside the 1U rack mount case are two Pentium processors, 1GB RAM, a fast hard drive, CD-ROM, floppy, and two Intel 10/100 network interfaces. A Gigabit version is planned for the future. 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. All that is required is to enter the administrator password, IP address of the management interface and the mail gateway details (for SMTP alerts). The built in disk drive is then initialised, checked and configured, and the IDS code is run directly from the CD-ROM (the hard drive is used only to store configuration information, custom code and alert/forensic data). The underlying operating system is a hardened FreeBSD (preferred over OpenBSD for the NID-200 because of the SMP support) with no shell and an absolute minimum of installed drivers and binaries. No executable programs are stored on the hard drive at all, and without the CD-ROM in place the appliance simply will not run, making it extremely secure. 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, updates and new signatures can be downloaded and applied from a secure support site and do not involve a new CD. The NID-200 comes installed with two network cards as standard. As we mentioned in the Architecture section, it is recommended that the NID Sensor be installed in �stealth mode�, which means that the sniffing interface does not have an IP address. In order to accomplish this, the second interface is used for dedicated management and monitoring traffic. Once the NID-200 is running, a text-based console screen provides a real-time status monitor (CPU utilisation, packet reception statistics, and so on) and a real-time alert display. 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 (and the optional Perl Query Add-on) is supplied via download from the NFR support website, and this follows the usual Windows installation routine. Once it is installed, it is possible to add extra users (one default administrator is created during installation), and configure the three parameters that are necessary to enable the NID Sensor to start scanning � the network address of the network to be scanned, the broadcast address, and the router MAC list. 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 only. It is a shame that the excellent hard copy manuals are no longer provided. All configuration and monitoring is performed using the Windows-based NFR AI, which 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. 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. Although alerts can be displayed in the Alert Popup window as they happen, this window 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 alerts, or filter them on various criteria such as date, time, IP address, severity, host, and so on. Once an alert has been acknowledged, a check box provides the capability to view only unread alerts. 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 way you expect, 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, the FilesToWatch variable is part of the TFTP Backend, and provides a list of files that are considered noteworthy (such as /etc/passwd) should someone try to access them via TFTP. 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. Another example of the flexibility of the NFR product. As new Packages and Backends are added to the system, the Variables menu option is updated automatically to reflect the new parameters available. 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.
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 few 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.
As with many IDS systems, NFR does implement a default �policy� out of the box, and 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, and since even with all Backends active we did not notice any significant impact on performance (an advantage of the powerful hardware platform) that might be a good place for the less experienced administrator to start. All alert data is stored on the NID Sensor itself and is only 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. In terms of day-to-day use, the NID-200 is very simple to manage. Entire Packages or individual Backends can be enabled or disabled at the click of a mouse, 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. Indeed, despite the underlying flexibility, the NID-200 is one of those IDS products that is almost plug and play, requiring very little knowledge of intrusion detection technology in order to make good use of it. It is nice to know, however, that more fundamental changes can be made to the operation of the NID Sensor by resorting to a bit of custom programming. NFR seems to offer the best of both worlds, striking an excellent balance between ease of use and flexibility. Performance is excellent too, the inclusion of the Anzen Flight Jacket signatures allowing the NID-200 to detect an extremely high proportion of our attacks during testing (one of the highest of all the products we have tested), as well as maintaining extremely high detection rates even on a 100Mbps network loaded to 100 per cent with 64 byte packets. Under more realistic loads, and with a �real world� mix of traffic, the NID-200 copes with 100Mbps networks with ease. 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, it is possible to query data from individual remote NID Sensors or across all remote Sensors � without the CMS it is only possible to query a single NID Sensor at a time. 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 Sensor it is available for query (this is not always instantaneous in a distributed system). 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, although there are plans to incorporate Crystal Reports into a future release to provide the means to produce more flexible, attractive and readable output.
One worrying factor with reporting � particularly with regard to forensic analysis capabilities � is that there does not appear to be any control over permanent archival of recorded data. Disk usage is controlled automatically on a per Backend, per-NID Sensor basis, and old data is simply cleared out once pre-defined allocation limits have been reached. Distributed systems offer the ability to export data to external ODBC-compliant databases, but this does not appear to be available in implementations that do not use the CMS. It�s not being too harsh to say that earlier versions of the NFR product line majored more on the collection of data for forensic analysis than typical intrusion detection capabilities � after all, that is where the product has its roots. However, the acquisition of Anzen Computing�s technology in June 2001 has provided a wealth of pure intrusion detection signatures to be incorporated into the product. At the time of writing, that integration project is ongoing, and we needed to be careful to ensure that the required signatures were included in our test system. Once the absorption of the Anzen Flight Jacket is complete, it will eventually provide NFR with an incredible array of detection capabilities out of the box. Hopefully, by the time you read this the integration will be well advanced � but you would be wise to ensure that the signatures cover all your requirements. 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. 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). However, reporting could be improved to make it more detailed and useful � there is plenty of data available, but not much in the way of explanation. The stateful architecture also makes it accurate and fast, and highly resistant to all currently known IDS evasion techniques. The turnkey approach makes it incredibly simple to install, and the hardware supplied provides extremely high levels of performance, the NID-200 achieving very high detection rates in our tests even under the heaviest network loads. The use of a bootable CD-ROM to hold the OS and code makes it very secure. Day-to-day management and monitoring tasks are also made easy by the Windows-based GUI. All in all, we found that the NFR NID-200 offers an extremely good balance between ease of use and flexibility. Company: NFR
Security, Inc Click here
to return to the NFR NID-200 V1.1 questionnaire
|
 |
Send mail to webmaster
with questions or�
|
