IntruShield thwarts cyberthreats

An intrusion-detection system alone will not keep every intruder from sneaking into your network. For a truly effective defense, you must combine intrusion detection with a capable firewall, an antivirus system and a network configuration that capitalizes on best practices.

Until recently, intrusion- detection systems have mainly been used to interpret network transactions, much like a protocol analyzer. Most often, such systems did nothing about offensive traffic; they merely reported what was happening on the network and, at best, sent alerts to network administrators about suspected problems.

IntruVert Networks Inc.'s IntruShield is a next-generation intrusion-detection system with intelligence capable of not only detecting offensive traffic, but also blocking it before it enters your networks.

We evaluated the IntruShield 2600, which is a sensor appliance capable of real-time detection at speeds of up to 600 megabits/sec. Its big brother, the IntruShield 4000, can work with traffic speeds of up to 2 gigabits/sec.

The sensor appliance is the first part of the system. The second part is management software that runs on a separate PC. We used IntruShield Global Manager, which is capable of managing several hundred sensors. There is also a lighter-weight IntruShield Manager that supports up to three sensors.

Installing the IntruShield system took less than an hour. We began, as most customers will, by using the default settings and policies. However, we soon realized that the system was reporting several network events that were not related to intrusions. Some Microsoft Corp. Windows 2000 workstations were unsuccessfully attempting directory access, and some packets had invalid IP addresses. IntruShield clearly explained these errors and also gave us references to further information.

With a bit of manual tweaking to the IntruShield sensor, we were able to disable those alarms, but this solution was not optimal because the alerts could have resulted from a real attack. With the aid of IntruShield's Help function we were able to find the malfunctioning hosts and fix them so that the alarms could be enabled again.

Because the manager server can be operated via a Web interface, we decided to move our observation post to a location across town. We logged into the server using a virtual private network over a Secure Sockets Layer-encrypted cable modem. The performance was so good it was almost like sitting in front of the management server.

Much of this good performance must be attributed to the management server PC that we borrowed from IntruVert. It was a generic dual processor, 1.13 GHz host with 4G of RAM and uses the Apache Software Foundation's Web server and Tomcat for the JavaServer Pages application server. We applaud IntruVert for using these open-source components.

From our remote PC, we began exploring the many pages in the management server's Web interface. Because each page presented only a small set of information on the screen, we realized only gradually the immense number of features and extraordinary amount of control that we had over the system.

The Alert Viewer is where most of the excitement takes place. It is the administrator's one-stop information shop when someone screams, "We've been hacked!" In the past, when a system was under attack, the systems administrator had to rely on educated guesswork and painful experience. With this product, the administrator can drill down from the Alert Viewer to see events as they happen in real time. He or she can even access a long history of packet-level information.

We began our simulated attacks with a "vanilla," or unmodified source, port scan against our test host using Insecure.org's Network Mapper (www. insecure.org/nmap). This scan, which opens a full TCP connection to many well-known ports, was detected immediately by the IntruShield sensor's default exploit policies.

Then we performed a "half-open" TCP synchronization scan to simulate the start of a denial-of-service attack. Such scans do not fully complete the normal TCP connections, thus leaving the target server waiting for responses. Our test scan was not detected. We discovered that the "reconnaissance" filters that detect such activity must be enabled for each interface, and they are not included in the global policy that governs exploit detection. However, it was easy to turn the filters on, and in a few moments, the sensor was reporting our scans.

With some experimenting, we found that by increasing the timing intervals on our port scans, we were able to avoid detection by the sensor's default timing policy. This is an excellent example of a setting that must be tuned for each individual network. You may elect to make policies more sensitive on publicly exposed interfaces but allow a more liberal timing policy on trusted inside interfaces. We were impressed by the extraordinary degree to which you can manage policies throughout the system.

Nessus (www.nessus.org) and SAINT from SAINT Corp. (www.saint corporation.com) are security-auditing tools that launch a variety of sophisticated attacks on servers or workstations. We first ran Nessus and then SAINT against our test workstation protected by IntruShield. IntruShield issued an alert when the programs executed their attacks. In real time, IntruShield gave us instant access to a general description of each attack.

IntruShield's reporting features are excellent. If an Internet service provider requires logs to prove an incident, IntruShield provides the evidence, clearly presented in PDF files.

It is easy to see how IntruShield could earn its keep in a crisis. The system identified a wide variety of attacks. With a few clicks of the policy editor, we were able to drop offensive traffic, thereby hiding the network's vulnerability from the attacker. If it is too risky to deny a certain kind of traffic, you can choose to watch certain IP addresses. When you determine that you are being probed by a particular IP address, you can create a user-defined attack signature that will alert you when that IP address sends traffic to your network.

How IntruShield detects so many attacks is confidential information. But we do know that the company uses a combination of signature detection, stateful traffic inspection (a firewall technology that matches inbound packets with the sources of previous outbound requests), anomaly detection and denial-of-service detection. Their signature files can be downloaded manually or automatically sent to the user as needed. Their signature files are large and include detection of a number of Internet worms.

In high-stakes environments that deal with sensitive or valuable data, IntruShield can add a critical extra layer of protection against the bad guys. Too often, network administrators find out after the fact that their network has been probed. With a tool like IntruShield, the administrator will be alerted immediately of attacks or hostile reconnaissance.

Greer and Bishop are network analysts at a large Texas state agency. They can be reached at Earl.Greer@dhs.state.tx.us.

***

At a glance

Intrusion protection

IntruVert Networks Inc.'s IntruShield intrusion-detection sensors offer:

* Flexible deployment — Allows administrators to deploy sensors in several modes to suit their network security architectures.

* Stateful analysis — Provides protocol analysis and thorough analysis of network traffic at multigigabit rates.

* Comprehensive intrusion detection — Detects known, first-strike and denial-of-service attacks using a combination of signature, anomaly and denial-of-service detection techniques.

* Real-time intrusion prevention — Provides proactive capability for stopping in-progress attacks, coupled with a set of alert and response actions.

* Virtual intrusion detection — Gives administrators the ability to set multiple, customized intrusion policies within a single sensor.

* Interoperability — Works with leading firewalls and enterprise management applications.