Network based intrusion detection: A review of technologies

Computers & Security, 18 (1999) 671-682

Network Based Intrusion Detection: A Review of Technologies Kevin Richards

Denmac Systems Inc., 650 Academy Drive, Northbrook, IL 60062, USA.

Intrusion Detection System Overview In its simplest form, an intrusion detection system (IDS) is a burglar alarm. Its purpose is to monitor a resource and notify someone in the event of a specific occurrence. In computer security terms, intrusion detection generally falls into two categories: host based and network based.

l Host based intrusion detection - focuses on a server and monitors specific user and application actions and log entries.

l Network based intrusion detection - monitors network traffic on the wire for specific activities/signatures that represent an attack.

Other forms of intrusion detection include integrated solutions within applications and honey pots. Honey pots are devices used to lure would be attackers - providing an audit trail and potentially the attacker’s identity. This discussion focuses on network based intrusion detection. Why network based? While the most comprehensive strategy is a combination of host and network based technologies, network based intrusion detection provides a strong foundation for the following reasons:

l Server platform independence - network based IDS watches traffic on the wire and is not affected by server platform changes or updates.

l Straightforward deployment - network based

IDS environments are commonly deployed at the access points of a network.

l Wide array of attack identification - network based IDS sensors monitor a wide array of attacks that range from protocol attacks to environment specific attacks.

Now for the “not’s”. . . Network based intrusion detection is not an access control mechanism (like a firewall). Nor is a firewall an intrusion detection device - although firewalls can provide helpful insight on authorized access attempts. Just like an alarm system on a car, network based intrusion detection is also not going to stop an attack. It will alert that an attack is in process.There is a push in the industry to extend the functionality of IDS capabilities to interrupt commu- nication sessions or modify access control lists to dynamically ‘defend’ against an attack. Interestingly enough, this capability actually creates a potential denial of service opportunity for a would-be hacker.

Also like a burglar alarm, network based intrusion detection is commonly deployed at the access points to a network - the Internet, modem pools, VPN connections, and WAN connections. Network based systems are ideal for monitoring for external abuse and reconnaissance attacks. Host based systems are good for the core of your network in which they reside on the server and can monitor for privileged access abuse by people that have already gained access to the systems.The granularity of an IDS deployment needs to match the

0167-4048/99$20.00 0 1999 Elsevier Science Ltd. All rights reserved. 671

Network Based Intrusion Detection/Kevin Richards

requirements of a company’s security policy and security strategy.

Network Based IDS Systems

Why we Tested

In the process of evaluating intrusion detection, it was recognized that there was a large amount of confusion and misinformation on where network based systems fit into an organization’s security strategy. Many product reviews evaluated product feature sets, but not the IDS performance and limitations in a production environment. To provide better value to our customers, it seemed important to get quantitative and reproducible testing results in addition to feature set comparisons. The net result is an objective assessment of the industry’s leading products. In an effort to provide a basis for comparison, a grade was created for each product.

What we Tested l ISS RealSecure version 3.0 l NFR Network Flight Recorder version 4.0 l Cisco NetRanger version 2.2 l Computer Associates SessionWall version 3.1 l Axent NetProwler version 3.0

What we Found

Of all the capabilities and features, the packet processing engine is the key component to an effective IDS environment.An IDS sensor’s job is to watch the network for attacks.To do this, the sensor looks at every packet, and then determines if it is an attack. The busier the network, the more packets there are to watch. If the sensor can’t keep up, it will start to miss (or drop) packets. Some attacks span multiple packets, so the sensor holds the packets, assembles all of them, and then determines if it is an attack. The efficiency and accuracy of these activities determine the effec- tiveness of the sensor’s packet processing engine, and ultimately, its ability to detect attacks.

Surprisingly, some of the IDS products tested did poorly with this critical testing criterion. Ultimately,

672

however, there are some sound architectures and capabilities that make network based intrusion detection an important component of a successful security strategy.

Testing Criteria and Components

How we Tested

Our evaluation consisted of subjecting each IDS system to a variety of qualitative and quantitative tests.

IDS Common Architecture

Product Usability

User Interface O/S vs Appliance Product Maturity Company Focus

Price

Functional Testing

Attack Set Detection Facility Configuration facility

Alerting & Logging Facility Reporting Facility

Architecture

Filter Efficiency Packet Reassembly Packet Throughput

Network Wire

Figure 1

Computers & Securit- Vol. IS, No. 8

These tests were devised to characterize the accuracy, usability, and performance of each system. Each product was evaluated independently, using the same hardware, except for Ciscos NetRanger. NetRanger is packaged as a ‘network appliance’ - it ships with the sensor hardware and software preinstalled. Each product was installed using the product’s end-user documentation provided by the vendor. Support items were handled with the specific vendor’s technical support organization - not through the sales support channel.

Testing Methodology Our engineering team identified a common architecture for network based intrusion detection. From this architecture, the IDS environment was extrapolated into two domains that allowed evaluation by quantitative and qualitative measures. These parameters were weighted to differentiate the items and their relative importance to our overall assessment.

Using the architecture outlined in FQpve 1 (IDS Common Architecture) as a basis for comparison, IDS products can be evaluated very thoroughly The evaluation criteria are divided into three main groups: functional testing, performance testing, and product usability. A more detailed discussion of these groups is as follows:

Generator

Attacker

IDS Lab Setup A - Functional Testing

Figure 2

IDS Lab Setup B - Performance Testing

Figure 3

Functional testing

This suite of tests characterize the IDS system in a typ- ical environment with the attacker placed on a different network than the victim and IDS monitor - such as the Internet.The purpose of this suite is to characterize the IDS product’s capabilities (i.e., attack set detection capabilities, reporting, logging, alerting, etc.). Fiptye 2 (IDS Lab Setup A - Functional Testing), illustrates this environment. A complete discussion of the configuration hardware, operating system, application software, and security tools is located in the Appendix.

Performance testing

In this suite of tests, the routers were removed, and the attacker resided on the same network as the victim and IDS system. This configuration allowed performance testing of the IDS environment by eliminating devices that would restrict packet rates (i.e., the router) .The purpose of this testing is to determine the performance characteristics of the IDS packet processing engine. F@tve 3 illustrates this configuration (IDS Lab Setup B - Performance Testing). The results of this performance testing is detailed in the Appendix.

Product usability evaluation

This evaluation focused on the user interaction with the IDS system - the user interface, ease of use, ease of configuration, ease of filter customization, alerting

673


capabilities, etc. As with all qualitative testing, the rel- evance of this evaluation will depend on specific envi- ronmental requirements.

Functional Testing Criteria The following list outlines the IDS system’s functional testing criteria:

1. Attack set detection

Attacks were broken up into categories based on analysis of different portions of the TCP/IP stack. These categories provide insight on the sensor’s ability to process different styles of attacksThe categories are as follows:

Header attack analysis capabilities - this attack set defines the IDS system’s ability to handle attacks that are conducted in the IP packet header. A common attack of this type is the LAND attack.

The LAND attack sends a SYN packet with the same source and destination IP address and port. This forces the IP stack into a progressive loop that ultimately crashes the stack.

Reassembly attack analysis capabilities - this attack set defines the IDS system’s ability to reassemble multiple fragmented IP packets and identify attacks that occur over multiple packets. A common reassembly attack is the ‘EavDroy, or Ping qffeatk attack.

The TearDrop attack is initiated by sending multiple fragmented IP packets, that when reassembled, have data portions of the packet that overlap.This causes protocol and/or the system to become unstable.

The Ping of Death attack is generated by sending multiple fragmented ICMP packets, which when reassembled, have a data portion of greater than 65535 bytes.As this is a violation of the TCP/IP specification, it causes theTCP/IP stack to crash on vulnerable computers.

Data attack analysis capabilities - this attack set assesses the capabilities of the IDS system to investi- gate attacks that are in the data portion, or payload, of the packet.A common data content attack would be the HTTP pkfattack.

CGI programs are programs that a web server executes to handle complicated requests and to serve dynamic information. One of these programs, called “phf”, provides a web gateway to an online phone book service. Due to a general problem in one of the programs it uses to handle requests, an attacker can force it to execute an arbitrary command. This attack can be used to break into a server, obtain sensitive information, and potentially to compromise the availability of the Web server and the machine on which it runs.

2. Protection of IDS against IP Desync

This leverages work previously performed by Secure Networks and published in their white paper, “In- sertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection.” Their test suite is incorporated into the Network Associates CyberCop scanner. The attacks attempt to disguise themselves by initiating attacks with non-standard sequence and size variables.

3. Repetitive attack suppression

This category characterizes the sensor’s ability to handle alarms from an attack that appears multiple times in a short period.The system’s ability to consolidate alarms and avoid sending out duplicate alerts was evaluated.

4. Filter customization

Customization of existing filters, and the ability to create specific filters is very important in an IDS system.This allows the IDS systems to be optimized for any environment. The following list highlights the levels of customization evaluated:

674

Computers & Security; Vol. 18, No. 8

l The ability to modify or tune existing filters. l The ability to create simple string matching filters. l The ability to create complex filters using a script-

ing facility.

5. Alerting

Characterizes the sensor’s ability to handle and process alerts. The alerting functionality evaluated are as follows:

l The ability to signal an alert. l The ability to process the alert internally (i.e., via

pager, E-mail, etc.).

6. Logging

Characterizes the system’s logging capabilities. The logging functionality assessed are as follows:

l The ability to save logs in different formats. l The ability to configure logging for specific

variables.

7. Reporting

Each system was evaluated on its ability to produce reports on the various alerts. The reporting capabilities evaluated are as follows:

l The ability to generate activity reports. l The ability to customize the queries. l The ability to consolidate reports across variables. l The ability to create and save custom reports

(profiles).

8. Distributed architecture

In large environments, a distributed IDS system is very important. Evaluation of the architecture was based on the following:

l The IDS architecture (stand alone or distributed). l The ability of multiple sensors to report to a cen-

tral management console. l The ability to implement a hierarchical model for

both sensors and management consoles (i.e., having multiple sensors and multiple consoles).

Performance Testing Criteria

These tests were conducted under both a 6100 packets per second (3%) and 25 000 packets per second (15%) network traffic load on a 100 Mbps network. All tests used a 64-byte packet. For performance testing, the attack was captured with Network Associates Sniffer Pro and then launched at both wire speed (or as fast as they could be sent by the sender) and at a controlled rate - 100 packets per second. A complete description of the testing architecture and results is in the Appendix.

Throughput engine speed

The goal of this test is to quantify the IDS system’s ability to capture network packets without experiencing packet loss.There was no attack initiated here, and the IDS sensor was configured without any attack signature loaded.

Packet reassembly

The purpose of this test is to evaluate the sensor’s packet reassembly performance.To accomplish this, a Ping qf Death attack is initiated. The sensors were confib~red with only one signature loaded - the Pirzg of Death.

Efficiency of filtering

This test tested the overall efficiency of the filters to handle, process, and alert on attacks. A basic header attack was conducted, the LAND attack.This attack is defined as a packet where the source and destination IP addresses are the same.

Product Usability Criteria The following categories are used to evaluate the qualitative components of an IDS environment:

Interface usability

In this category, the system was evaluated on the usability, completeness, and extensibility of the user interface. Multiple O/S support, ease of use, and stability were factors that were weighed here.

675


Criteria Weight NFR RS SW NP NR

Functional Testing

Attack Set Detection 5 4.0 4.0 2.0 1 .o 4.0

Protection of IDS Against IP Desync 3 4.0 1 .o 0.0 0.0 N/A

Repetitive Attack Suppression 3 1 .o 0.0 4.0 0.0 3.0

Filter Customization 5 4.0 1 .o 2.0 3.0 2.0

Alerting 4 3.0 3.0 4.0 3.0 3.0

Logging 4 4.0 3.0 3.0 3.0 4.0

Reporting 3 2.0 3.0 4.0 3.0 3.0

Distributed Architecture 2 2.0 3.0 1.0 0.0 4.0

Performance Testing

Engine Speed 3 3.0 3.0 1.0 4.0 N/A

Packet Reassembly 5 4.0 4.0 N/A 0.0 N/A

Efficiency of Filtering 5 3.0 3.0 N/A 2.0 N/A

Quantitative Assessment Weighted GPA: 3.26 2.64 2.41’ 1.79 2.902

Product Usability

Interface Usability 3 3.0 3.0 4.0 2.0 2.0

Appliance/OS Implication on IDS 4 4.0 1 .o 1 .o 1.0 3.0

Maturity of Product 2 3.0 4.0 4.0 1.0 3.0

Product Concept 1 3.0 3.0 4.0 4.0 4.0

Company Focus 3 4.0 4.0 2.0 3.0 2.0

Price 4 4.0 3.0 2.0 3.0 1 .o

Overall System Weighted GPA: 3.37 2.69 2.43’ 1.90 2.842

,.Tr_ ,.T 1 -7. 1 _ 1 1 _ ~ rurK = r\erwork rngnt Kecoraer v4.u RS = RealSecure ~3.0 SW = SessionWall ~3.1 NP = NetProwler ~3.0 NR = NetRanger ~2.2

Grading Scale: 0.0-4.0, N/A = not able to obtain the results (see notes below) Weight Scale: 1.0-5.0

Weighted GPA = Score *Weight

CWeight

NOTES:

1. SessionWall Packet Reassembly and Efficiency of Capture & Filtering performance results could not be obtained due to the product’s architecture. SessionWall did correctly identify attacks that require packet reassembly, however, we were not able to retrieve any performance data of its process. (See Appendix for further details on SessionWall’s architecture) The GPA reflects the absence of these tests by not including these tests in the final weighted calculation. 2.The NetRanger evaluation unit from Cisco was not available for the full duration of testing. Consequently, a number of quantitative tests were not performed, including the following: IP Desync, and Capture & Filtering Efficiency.The GPA reflects the absence of these tests by not including these tests in the final weighted calculation.

676

Computers & Security Vol. 18, No. 8

Appliance / operating system implication on IDS

In this category, the system was evaluated based on its integration into the operating system for ease of maintenance and support. Appliance type devices with their own O/S weighed better than systems that were supported on existing general-purpose operating systems.

Maturity of product

The product was reviewed based on its stability, implementation, completeness and accuracy of what it is intended to do, and the length of time on the market.

Product concept

The systems were compared based on their strengths and unique feature sets.

Company focus

This evaluation centered on the company focus and their investment in security technologies, in general, and intrusion detection, specifically. Additional con- sideration included the company’s commitment to research and development for security technologies.

Price

This category defines and grades the systems on product and implementation costs.

Report Card In an effort to provide a granularity of comparison for the IDS products, a grading of the different testing criteria was created. The grading matrix includes two components: a score for the specific criteria on a scale of 0.0 to 4.0 (4.0 is the best score), and a weight of rel- evance (or importance) of the criteria on a scale of 1 to 5 (5 being the most relevant). For example, the IDS’ attack set detection capabilities (weight = 5) rated more heavily than the user interface (weight = 3).The result is a weighted grade point average (GPA).

ISS RealSecure 3.0 - Lab Notes

Our testing showed RealSecure 3.0 to be a mature release, with a stable sensor and management console that supports a distributed environment.

Strengths

l The user interface is well designed and easy to navigate.

l RealSecure’s packet-processing engine performed very efficiently during each phase of the quantitative testing.

Weaknesses

l There is no apparent support for filter customization in RealSecure beyond tuning parameters in certain signatures.

l Update of new signatures requires waiting for a new release of code and reinstallation of the product.

l Attack alert suppression is poor. If multiple identi- cal attacks are detected, the sensor will identify each one and forward each alert to the console. The only way to clear the console of the alerts is to shut it down and restart it.

Deployment notes

RealSecure is a good product for a company who does not have a lot of internal technical security expertise. Companies that require customization of-signatures would product.

NFR Network - Lab Notes

not benefit as well from this

Flight Recorder 4.0

Network Flight Recorder 4.0 provides strong, enterprise-class IDS capabilities.The architecture provides a wide array of customization for advanced packet analysis. NFR is a software appliance, meaning it contains its own operating systems and application code that installs on any standard Intel based system.

677


Strengths

NFR is delivered as a software appliance. It installs on standard Intel based hardware. The installation process is very easy and straightforward. The filter customization capabilities are exception- al. This product has an advanced customization feature set wrapped around its own packet processing programming language, Ncode. NFR has a very good architecture for packet analysis and logging. The new Win32-based interface in version 4.0 provides for straightforward usability. NFR packs a lot of performance and customization for its price tag.The cost of initial installation and deployment are minimal when compared to other products.

Weaknesses

Customization, if needed, is robust - but at a cost. It is complex and increases a company’s support burden and commitment to the product. While NFR has some advanced log control capabilities, the reporting on these logs is limited. Currently a report can only be generated across a single signature, summary reports spanning multiple signatures are not currently supported.

Deployment notes

NFR is a product that is well suited to many environments, particularly those that require customization of filters or to monitor specific network transactions.

Cisco NetRanger 2.2 - Lab Notes

NetRanger is a ‘network appliance’ device developed for intrusion detection, with the hardware and software ‘bundled’ into one package. Based on our testing and understanding of the product’s architecture, it appears to be a very scalable solution, potentially supporting a large enterprise with distributed consoles. The management console application is installed on a Unix-based HP OpenView platform.

Strengths

l NetRanger is a hardware/software appliance device that bundles the hardware and software.The sensor hardware runs Solaris x86 as its operating system.

l The industry leader in data networking, Cisco Systems, backs the product.

l It has a very strong architecture for packet capture and analysis.

l The distributed capabilities lend it to larger environments. Multiple sensors can report to multiple consoles, which in turn can report to other consoles - thus supporting a very distributed hierarchical model.

Weaknesses

l NetRanger comes with a sizable price tag - both for the sensor hardware and the OpenView requirement.

l It is complex to install, integrate, and manage. l Signature customization is limited to simple string

matching.

Deployment notes

NetRanger is an enterprise class solution that requires a commitment in both financial and personnel resources due to the integration and management of both NetRanger and HP OpenView. While the unit was unavailable for performance testing, the sensor and management unit appeared to perform in line with the NFR and RealSecure.

Computer Associates SessionWall- 3.1 - Lab Notes

While SessionWall is not the best choice for a product solely focused on network intrusion detection, it is one of those applications that should be in every security administrator’s tool kit. SessionWall is primar- ily a real-time, network conversation monitoring tool.

Strengths

l SessionWall has an advanced, highly customizable reporting engine.

678

Computers & Security, Vol. 18, No. 8

l It has the ability to consolidate multiple, duplicate alarms into a single alarm. This reduces the number of redundant alarms to the management console and associated security staff.

l Customization and configuration is simple and easy to manage.

l The user interface is very mature, stable, is simple to navigate and provides a lot of information.

Weaknesses

l Intrusion detection is not the primary purpose of the product, so its ability to capture and analyze packets is far less than the other products tested.

SessionWall does a wonderful job at real-time moni-

Deployment notes

toring and auditing which allows administrators the ability to oversee user’s Internet usage, categorize the URLs, read email being sent, watch Telnet sessions, and be alerted of suspicious activity.

l NetProwler does not support a distributed environment. Each sensor currently has to be configured and maintained individually. Each sensor has its own alerting mechanism with no central con- solidation of alerts.

Deployment notes

This product, while great in concept, currently needs more time to mature before it can be practically implemented in a production environment.

Appendix

The evaluation laboratory was configured as follows:

Attacker - the attacker is an Intel-based system

Evaluation Laboratory Setup

running Windows NT 4.0 (Service Pack 4), and used Network Associates CyberCop scanner to launch the attacks. If an attack could not be launched accurately from CyberCop’s default configuration, it was created with CyberCop CASL scripting language.

Axent NetProwler 3.0 - Lab Notes

NetProwler 3.0 approaches network based intrusion detection with a different perspective. It profiles the network and only monitors for attacks that are relevant for that environment.

Strengths

l NetProwler is customizable and supports custom filter creation through a graphical interface.

l NetProwler’s packet capture engine performed extremely well in the performance testing.

Weaknesses

l The product is currently immature and did not detect basic attacks accurately. It required a significant amount of configuration to detect some of the attacks launched during testing.

l The user interface is inconsistent and difficult to navigate.

Victim - the victim is a Windows NT 4.0 server running IIS version 4.0. All attacks were destined for its IP address.

IDS Monitor - the IDS monitor is the sensor piece of the IDS system that analyzes the packets on the wire and alerts if it senses an attack.

IDS Manager - in some configurations the monitor and manager were the same system, however, those IDS systems that supported distributed management were deployed on separate servers to evaluate the full functionality of the environment. The manager software is the component that handles the alerts from the monitors and notifies the end user.

Load Generator - the load generator was a Windows NT 4.0 server running Shomiti Surveyor 2.4. This was used during the performance testing phase of the evaluation.

679


Figure 4: IDS Performance Testing Lab Setup.

Performance Testing Approach and Results

We created a test environment to evaluate the performance characteristics of each IDS product.The infras- tructure was implemented in a manner that eliminat- ed devices that could restrict packet rates, and thus mask the performance of the IDS sensor. Each device was connected into a Nortel Networks BayStack 100 Base-T hub. F@ve 4 illustrates this configuration (IDS Performance Testing Lab Setup).

The tests were conducted under both a 3% (6100 packets per second) and 15% (25 000 packets per second) network traffic load on the 100 Mbps network. All packets were 64-bytes in size. Shomiti Surveyor (version 2.4) generated the network load. The attack was then captured with Network Associates Sniffer Pro and launched at both wire speed and 100 packets per second.

Throughput Engine Speed - the goal is to quantify the IDS system’s ability to capture each packet without experiencing packet loss.There was no attack initiated, and the IDS sensor was configured without any attack signature loaded.

Packet Reassembly - this test evaluates the sensor’s packet reassembly performance. To accomplish this, a Pirlg sf Dr~th attack is initiated. This attack is generated by sending multiple fragmented ICMP packets, that when reassembled, have a data portion of greater than 65535 bytes. As this is a violation of the Ethernet specification, it causes the TCl’/IP stack to crash on vulnerable computers.The sensors

were configured with only the Ping of Death signature loaded.

Efficiency of Filtering - this tested the overall efficiency of the filters to handle, process, and alert on attacks. A basic header attack was conducted, the LAND attack. This attack is defined as a packet where the source and destination II’ addresses are the same.

F@Y~ 5 illustrates the location of the tests within an IDS architecture.

Performance Testing Results Packet engine performance is a critical component of an effective IDS environment. If the engine has diffi- culty capturing, reassembling, or identifying attacks, the attacks will go unnoticed - thus defeating the purpose of having an intrusion detection system. Since most production networks are generally very busy, the next challenge is determining how much traffic the sensor can handle before it begins to drop packets.

To assess each sensor’s performance capabilities, a test suite was developed to assess the packet processing

AleflIng & Loggmg Factlily

Figure 5

680

Computers & Securit- Vol. 18, No. 8

engine at both a low and high network load. Furthermore, the attacks were launched at two speeds: at wire speed (or as close to wire speed as the Sniffer could send it) and at a controlled rate of 100 packets per second.

Within this environment, 1000 instances of each attack were launched at the victim.The attacks were as follows:

l Empty packets - while not a true attack, this allowed a characterization of the packet capture engine.

l LAND attack - this single packet attack allowed assessment of the sensor’s capture and attack detection capabilities.

l Ping ofDe&z - this multiple packet attack allowed evaluation of the sensor’s ability to capture and reassemble packets, and then identify an attack.

This test suite was performed five times, and the results averaged.The following tables show the results of the performance testing. The data in each cell represents the number of attacks the sensor detected (out of a potential 1000). For example, under a 3% network load, the NFR sensor detected 987 of 1000

Ping of Death attacks delivered at wire speed. (*Note: NetRanger was not available for this analysis.)

NOTES:

* - The NFR architecture requires a filter be loaded to identify

and capture basic packets (with or without an attack signature).

This provided a higher processing requirement as compared to the

other sensors tested, and should assessed accordingly.

** - The Pitiy of Death attack was not tested at 100 packets per ‘ . second.

N/A -While it did correctly identify the LAND and Pin,q of&ah attacks, the SessionWall architecture suppresses alerting of redun-

dant attacks. The result is the sensor did not register multiple

attacks, and thus did not allow the performance data to be

captured.

IP De-synchronization Testing Results It is important for IDS solutions to address attacks that may be launched by non-traditional methods. Secure Networks published a white paper, “Insevtion, Evusion,

and Denial of Service: Eluding Network Intrusion

Detection.” Their test suite is incorporated into the CyberCop scanner.

A @fattack is launched using several variations.Table 3 shows the results of each IDS sensor’s ability to identify attacks under these circumstances. Sensors able to correctly identify the attack are noted with “Y” in the

Packet Capture*

LAND

Ping of Death

NFR RealSecure SessionWall- NetProwler

3% 15% 3% 15% 3% 15% 3% 15%

1000 929 995 335 999 88 1000 1000

1000 697 998 814 N/A N/A 1000 475 ** ** ** ** ** ** ** **

Table 1. Packets delivered at 100 packets per second

!

NFR RealSecure SessionWall- NetProwler

3% 15% 3% 15%

576 47 1000 1000

N/A N/A 1000 441

N/A N/A 0 0

Table 2. Packets delivered at wire speed

681


Type of Test

Single Out-of-Order TCP Segment Test Baseline (Single-Segment) TCB De-synchronization Test (RST) All Out-of-Order TCP Segment Test TCP Sequence Number Verification Test (Jump-Up) TCP Sequence Number Verification Test (Interleave) IP Checksum Verification TCP Checksum Verification TCB De-synchronization Test (Data) TCP Data-in-SYN Test IP Fragment Replay IP Fragmentation Test (8-byte tiny frags.) IP Fragmentation Test (24-byre Packets) IP Fragment Out-of-Order Test IP Fragmentation Overlap Test TCP Three-Way-Handshake Test TCP ACK Flag Verification IP Fragmentation Test (Out-of-Order Fragments) TCP Segment Retransmission (Inconsistent) TCP Segment Retransmission TCP Second-SYN Test TCP Reset Test Baseline (Multiple Segments) TCP Sequence Number Wrapping TCP Overlap Test

Table 3. IP De-synchronization Testing results

appropriate column, and thus those unable to detect the attack are noted “N.” Some sensors detected an attack, however identified it incorrectly The table notes the attack the sensor ‘thought’ it identified.

(*Note: NetRanger was not available for this analysis.)

A full discussion on the details of these tests can be found in the white paper entitled “Insertion, Etmion,

and Denial of Service: Eluding Network Intrusion Detection” by Secure Networks.

“Network Based Intrusion Detection - A Review of Technologies” is published by Denmac Systems, Inc. Denmac

Systems, Inc. is independent of the products evaluated, and in no

NFR RealSecure

Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

N N N N N N N N N Y

IPFrag I PFrag

N IPFrag IPFrag

Y IPHalfScan

IPFrag N N N N N N N

NetProwler

NT_Telnet_DOS N N N N N N N N N N N N N N N N N N N N N N N N

SessionWall

N N N N N N N N N N

Teardrop N N N

~ N Teardrop

N N N N N N N N N

way should any party construe this information as an endorse-

ment.The information contained herein is believed to be reliable.

The reader assumes sole responsibility for the selection of these

materials to achieve the intended results. The opinions expressed

herein are subject to change without notice.

Based in Northbrook, IL, USA, Denmac Systems is a network consulting and integration firm. Established in 1988, Denmac has

engineered networking solutions for some of the most demand-

mg customers in the world. By maintaining expert-level knowl-

edge, Denmac engineers solutions in the following areas: network

security, LAN/WAN design and optimization, networking plat- forms and applications and network management. Denmac

Guardian, Denmac’s security solution suite, provides companies

with technologies and procedures to fortify the security of their

network. Ilenmac can be reached the following ways,Tel: +l 847-

291-7760; Fax +l 847-291-7763; Web: http://www.denmac. corn; E-mail: [email protected].

682

Documents

Network based intrusion detection: A review of technologies