nPatrol is a Linux-based network intrusion detection system (IDS) from Bangalore (India)-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 protocol analysis, including packet analysis, full packet reassembly and neutralization of anti-IDS techniques; signature-based analysis with implementation of over 800 signatures (CVE compatible) categorized by application and operating system; anomaly detection based on previously 'learned' usage statistics to detect abnormal usage of bandwidth and misuse of resources; policy-based detection, helping to detect even new modes of attack; and direct response to intrusions for 'intrusion prevention.'

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.

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. It 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 requires serious consideration. By default, everything is denied, and a default setting in the Management Server specifies whether unauthorized 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 need to be monitored for intrusive behavior. 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 email to the identified people, send SNMP traps to network management systems, or terminate the intrusive traffic.

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. Once you have policies and services defined correctly, 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 authorized 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 online, 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 customized to contain specific categories of alerts if required.

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 into 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 occurred on a specific day.

A number of fixed-format HTML reports can also be produced via the Report Manager and 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.

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, and the product 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 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.  

SC On-Line
SC Magazine
www.scmagazine.com