 |
|
|
nPatrol is a Network Intrusion Detection System from Bangalore-based nSecure Software (P) Ltd. nSecure refers to its product as an �adaptive Intrusion Detection System�, since it is designed not only to protect systems from known vulnerabilities, but also from new, as yet unknown, modes of attack. nPatrol offers:
nPatrol consists of four main components:
The nPatrol Engine � comprising the Management Server and the Notification Engine - is the central interface for managing, configuring and monitoring the nPatrol components. The Engine usually resides on a dedicated Linux host and communicates with the nPatrol Agents via a dedicated management network, which is completely separate to the LAN being monitored. The nPatrol Management Server provides the framework to configure the nPatrol IDS and to monitor intrusive activity. Alerts are displayed in real-time as they are transmitted from the Notification Engine, and the Management Server can also be used to query the nPatrol database for more detailed reporting purposes. The Management Server provides a graphical interface to the following modules:
The nPatrol Notification Engine is the second major component of the nPatrol Engine. Although a completely separate process to the Management Server, it is intended to run on the same host. It is possible to install the Management Server and Notification Engine on separate hosts if required for performance reasons, although there is no automated installation option to do this. The Notification Engine collects the alerts from the various Agents and is responsible for logging the alerts to disk and notifying the administrator via the real-time alert windows in the Management Server console, e-mail or SMS. As well as logging to disk in plain text log files, the nPatrol Engine provides an interface to popular databases such as ORACLE, Sybase, MS SQL Server and mySQL. This is the promiscuous mode NIDS sensor component that resides on, and monitors all traffic to and from, the internal network. One nPatrol Internal Agent is required for every subnet, each running on a dedicated Linux host. Although the Agent is capable of operating independently of the Engine, no logging is carried out locally in the current release. All alerts are transmitted to the Notification Engine in real time. Signature update is controlled by a parameter set in the Management Console, which can fetch new signature files automatically from the nSecure Web site daily, weekly, monthly, on start-up or on demand. In the current release, only the on demand option is available, but future releases will allow scheduled retrieval of signatures to a centrally stored file. New signature files are transmitted to all Agents automatically over an encrypted link. This NIDS sensor component is similar to the Internal Agent, but is designed to be deployed outside the protection of the firewall, either between the firewall and router, or on a separate DMZ to protect public facing Web servers, for example As with the Internal Agent, External Agent runs on a dedicated Linux host, and all alerts are passed to the Notification Engine in real time. This Agent is one of the more unusual features of nPatrol, in that it is designed to detect anomalous traffic patterns on the network. As with the other Agents, the nPatrol Anomaly agent runs on a dedicated Linux host and one is required for each subnet. When first installed, it runs for a user-defined period of time in �training mode�, during which time it collects data on any combination of the following protocols and metrics: TCP
UDP
ICMP
Once the training period is completed, the Agent generates a pattern file that is deemed to represent the �normal traffic� for the segment on which it is installed. From that point on, it operates in �detection mode�, monitoring the specified metrics for excessive deviations from the normal settings that might indicate intrusion, attack, or other unauthorised behaviour. Unlike most Network IDS systems, nPatrol provides multi-layered protection. To begin with, and in common with many NIDS today, it is a stateful system, combining elements of protocol analysis and pattern matching against a library of attack signatures, together with anti-IDS evasion techniques and full packet reassembly. So far so good. Where it differs significantly, however, is in its use of a policy-based model to detect general misuse of network resources and help protect against as yet unknown attacks. A firewall-like rule-set and definition of allowed services specifies the permitted uses of network resources. As with a typical firewall, the default action is �deny everything�, so if it is not defined, it is not allowed, and nPatrol can either log the infraction or terminate the connection � or both. Finally, there is the Anomaly Engine, which takes this one step further by using statistical analysis to �learn� the profile of what could be described as �typical network activity� on a network. It then continually compares critical parameters against that profile in an attempt to detect anything out of the ordinary. Whilst the thought of installing a pure Linux-based system might send shivers down the spine of any Windows-only administrator, the processes are not that difficult and are well documented. For anyone who is remotely familiar with the Linux basics, installation is simple. After installing the Java Runtime Engine (JRE) which is used for the Management Server, simply mounting the CD-ROM and running the install script is all that is required. The script displays a menu from which the administrator can select which of the four main components is to be installed. The Engine is the first component to be installed, and all that is necessary is to confirm the installation directory, the JRE installation directory, the IP address of the Management Server and the database to be used for logging (if no database is selected, logging will be done to plain text files). Database installation is likely to cause the biggest problem, but full marks to nSecure for at least providing the basics of getting mySQL up and running � most manuals would simply refer you to third party documentation at that point. However, the instructions don�t go quite as far as they could, and there was one mistake in there which had us scratching our heads for a while. That just gave us an excuse to test the nSecure technical support operation, however, which was truly excellent throughout the testing process. The next release of nPatrol will see mySQL installation and configuration completely automated when this is chosen as the database for logging.
Once the Engine has been installed, the Management Server is used to define the Agent details and basic security policy. The Agents are then installed in a similar way to the Engine, except that there is even less to enter at the console: just the installation directory and the address of the Management Server. It is necessary to visit each host to install (and later upgrade) the Agent software - there is no means of distributing and installing/upgrading Agents from a central location. nSecure recommends that all Agents are dual-homed, with one NIC used for sniffing, and one used for the dedicated management network. Documentation is provided in the form of three manuals (four if you count the Quick Installation Guide) in electronic format only: Installation Guide, User Guide, and a very useful Signature Documentation Guide. Overall, the documentation could be described as adequate, with more detail required in the User Guide to make it a useful reference manual. There are also numerous grammatical errors, which are annoying rather than serious. We are promised additional reference material for the next release. Once everything has been installed, all configuration and management is performed via the Java-based Management Server GUI. Because of the policy-based approach, there is much more thought and work involved in configuring an nPatrol system than you might normally expect. Unlike much of the competition, it certainly is not a case of simply activating the sensors and waiting for the alerts to appear. As far as the protocol analysis and pattern matching signatures go, there is nothing to do other than set a few port scan thresholds and specify whether you want to enable packet reassembly and URL decoding on HTTP traffic. It is possible to define custom signatures by specifying the operating system, application (Web server, FTP server, and so on) and a combination of text and binary strings to search for. Also planned for a future release is the ability to access the signature library via a GUI interface to select or deselect individual signatures. The Anomaly Engine, should you wish to use it (it is an additional cost), simply needs to be turned loose to perform its analysis. Following the �training period� it will switch into detection mode and will raise alerts every time a monitored parameter deviates from that determined as normal by more than a user-defined percentage. The policy definition part of the configuration process, however, requires serious consideration. By default, everything is denied, and a default setting in the Management Server specifies whether unauthorised connections should simply be logged, or terminated.
Each entry made in the Policy Manager specifies a source and destination IP address, source and destination port (wildcards can be used), protocol (TCP, UDP, ICMP) and whether the connection is internal, inbound or outbound. Once an entry has been made, that particular type of traffic is allowed - anything else generates a policy violation, and the connection can be terminated immediately thus removing the need for further processing on that packet to match exploit signatures. Used in conjunction with the Policy Manager is the Service definition screen. This is where the administrator defines the services running on remote servers that needs to be monitored for intrusive behaviour. The user can specify the operating system, application (SMTP server, Web server, FTP server), protocol and other details for analysis within the allowed traffic to that server. On detection of intrusive traffic, it is also possible to define if nPatrol should just log the activity, send it via e-mail to the identified people, send SNMP traps to network management systems, or terminate the intrusive traffic.
The session termination is very effective � we attempted a connection to a protected FTP server and were allowed to log in and transfer files as normal. However, as soon as we entered a command such as CWD ~root the attack was logged at the Engine and our connection to the FTP server was lost. This is a very useful mechanism to employ in order to actually prevent intrusions, rather than just detect them, and it worked very well. It is important that the list of Services is as complete as possible, since nPatrol uses it as part of its determination of �state�. For example, if there is no entry for an IIS server running on port 80 of a Windows machine, then all IIS-related attack signatures will simply be ignored during the pattern matching operation. This helps to keep the number of signatures to be matched to a minimum, and thus improve performance, but it also means that there may be attacks on the wire that go undetected. If the Service and Policy definitions are comprehensive and correct, then any such ignored attacks will be unable to cause any damage. But if you are the kind of administrator who likes to know about every attempted attack, not just the ones that can cause you harm, then stateful products such as nPatrol are not for you. Policy violations can be a real nuisance (in terms of false positives) when first configuring the system, but it is worth spending some time in getting this right. For example, if you create a policy entry that allows certain types of traffic, you may unwittingly allow certain attacks through undetected on the back of that traffic unless you define the correct group of services to complement the policy definitions. It is also important to make the policy definitions as specific as possible, however much trouble this may cause with false positives, since � as with firewall rules � implementing generic rules and thus opening up very large holes for the sake of convenience is simply a bad idea. This merely provides an attacker with a means to hide an attack amongst genuine or non-monitored traffic. nSecure has promised to provide some sample default policy and service definitions for different environments out of the box for the next release of the product, and this would certainly be a welcome addition, along with some more detailed documentation on this whole area. Once you have Policies and Services defined correctly, however, they are a powerful tool in detecting potential attacks that are hitherto unknown, or known attacks that are not covered in the signature database. This is because anything that is not specifically defined as authorised traffic � such as an attempted connection from a Trojan to its master, for example - is considered suspicious and flagged as a Policy Violation. Changes can be made to Policies and Services in an off-line mode and then distributed to all Agents in one hit. It is also possible to work on-line, where every change is reflected at the Agents as soon as it is confirmed. There is no interruption in service when applying changes to the Agents, and all communications between Engine and Agents are encrypted.
Once a policy has been activated, then providing both the Notification Engine and the Management Server are active, alerts will be displayed in one of the Alert Windows in real time. The console displays the details of every intrusive activity, and multiple windows can be viewed based on the alert category (Anomaly Detection, Policy Violation, Consolidate Alerts, and Signature/Protocol Misuse). Each Alert Window can be customised to contain specific categories of alerts if required. Each alert generates an entry in the corresponding window (depending on the alert category) comprising date and time of the attack, attack description, source and destination IP address, and the action taken (logged, intrusive or terminated). There is also a column where the administrator can designate the alert as �acknowledged�, and Alert Windows are cleared of old alerts at regular, user-defined intervals. Double clicking on an individual alert brings up a more detailed description box at the bottom of the window. Unfortunately, the detail is not much greater than in the main window, the only additional information being the protocol and source and destination ports. This really needs improving to provide more complete information, such as packet contents (it is always useful to be able to see the URL request that triggers a Web-based alert, for example), a detailed description of the attack and a link to the CVE database. Right-clicking on an alert entry does bring up a window with a link to the appropriate CVE entry where applicable, together with a short description of the attack, though the latter is not as detailed as it could be in most cases. nSecure has promised to improve the level of detail provided via alerts in a future release (the necessary data is already stored in the database). Note that if the Notification Engine is running, but the Management Server is down, then it is not possible to see the alert in the console, though alerts are still written directly to the log file by the Notification Engine. However, if the Notification Engine is unavailable for any reason then all logging and alerting capabilities are lost.
nSecure has made the conscious decision to aim for as light a footprint on the Agent as possible, coupled with minimal traffic across the management network. For this reason, Agents do not perform any logging locally, so alerts detected whilst the Notification Engine is down are simply discarded (although connections will still be terminated immediately if that is a selected action for a given alert). This, we believe, is a flaw in the design of nPatrol, since an attacker who succeeds in severing the link between Agent and Engine can then go about his business undetected. It would be sensible to provide users with the option to have local logging on the Agent in cases where the Engine is unavailable, and we are promised that this feature will be included in a future release. The final monitoring tool within the Management Server is the Activity Monitor. This provides multiple graphical displays of the attempted scans, intrusive activities and anomalies on the target systems. Additionally, it is also possible to display the network resource utilisation based on the target system. The ability to define the time interval for consolidated graphs enables nPatrol to manage the network for long periods of scanning activities and certain types of stealth scans. Graphical views can be customised and new ones defined based on user specifications via the User Graphs option.
All of the operations available within the Management Server can be restricted on a per-user basis via the User Types capability. An unlimited number of user types can be created, each with a specific set of access rights, such as Define Services, Policy Manager, Maintain User, and so on. These User Types are then assigned to each user account as it is created, and applied when the user logs into the Management Server at the beginning of a session. This means that several Management Server consoles can be deployed around an organisation for different levels of user. When a SQL database is used to store alerts, any third party SQL query and reporting tool can be used to produce output in any format required. However, nPatrol does have some basic query and reporting facilities built in to the product. The Query Manager allows simple queries to be built using a screen-based form containing parameters such as IP address, port, protocol, category and date.� It is not able to handle very large queries, but is a quick means for an administrator to group together all alerts of a specific type that occur on a specific day. A number of fixed-format HTML reports can also be produced via the Report Manager:
Each of the reports can be grouped together to provide daily, monthly or yearly totals, and filtered by date or IP address range. Little detail is provided in the reports, since they are effectively limited to the same information displayed in the Alert Window. They would, therefore, benefit from a similar expansion of detail to include comprehensive attack information and packet contents and, once again, this enhancement is promised for a future release, as is the inclusion of graphical output (bar charts and pie charts) for consolidated reports.
nSecure has something that is genuinely different with nPatrol. And not different just for the sake of it � the differences here add to the level of protection offered by an IDS system. Performance was generally very good, nPatrol achieving excellent detection rates even under heavy load. nPatrol even spotted attacks for which it does not have signatures thanks to the policy-based approach. It is, however, vital that some time is spent on making sure that the policy and service definitions are comprehensive and correct, otherwise some attacks (like the DDOS probes in our tests) could go undetected. We would like to see some improvement to the documentation, and the detail provided in the alert windows and on reports, but none of these affects the day to day running or overall effectiveness of the product (and they are promised for a future release). And it is very effective. The multiple layers of protection with stateful protocol analysis, signature matching, policy and service definition, and anomaly detection combine very well to produce a very powerful solution. That power comes at a price, in that nPatrol is one of the more complex products to configure, and errors in configuration could result in some attacks being allowed through undetected. Once the configuration process is complete, however, nPatrol provides extremely broad protection against both known and unknown attacks. Company:
nSecure Software (P) Ltd.
Click here
to return to the nPatrol Results�
|
 |
Send mail to webmaster
with questions or�
|
