Evaluating Intrusion Detection Systems

Intrusion Detection Systems

Snort

Team: Darren

RealSecure

Team: Hao and Fredrik

Bro

Team: Steve and Michael

EVENT STREAM

Bro is a NIDS that runs on top of libpcap. Therefore, its event stream is network traffic, or a tcpdump log file.

OUTPUT

Once an attack is recognized by Bro, events can be generated to output real-time logging via syslog, to output a record of events to the disk, or to modify Bro's internal state to be used by subsequent event handlers (possibly to detect multi-stage attacks?)

RULESET

Bro 0.8a18 ships with 66 policy files (located in bro/example-attacks/) written in the BRO language for detecting attacks for http, finger, ftp, icmp, and several other applications/protocols.

RULE LANGUAGE

The rules are written in BRO, which is described in the paper [bro-CN99]

TCP STATE

Bro maintains TCP state by recording events named:

and recording their timestamps.

For applications that Bro knows about, all packets are allowed past libpcap, not just the 4 described above. For general tcp packets (not associated with a protocol Bro is aware of), Bro filters these packets through libpcap which allows Bro to only have to process on the order of 4 packets per stream. From these 4 packets, Bro can determine start time, duration, hosts involved, ports (and associated protocol), and # of bytes transferred.

FRAGMENTATION

One of Bro's primary goals was to avoid attacks on the monitor (Bro) itself. One method of doing this is by keeping track of all fragmented packets, ensuring they are not being used to accomplish "insertion" or "evasion" or some other kind of subterfuge.

ATTACK STATES

We are currently unsure of Bro's ability to keep state in the sense of detecting multiple-stage attacks. The description of the possible outputs (see above) implies that Bro has this ability, but we have not found that ability to be mentioned again.

MULTIPLE MONITORS

Bro does not have the ability to communicate between monitors, so it cannot detect complex multiple-host attacks. This concept is mentioned in the paper as being potential future work.

Prelude

Team: Swami, Sumit, and Kavitha

Current Status

Installed and configured Prelude Network-based IDS. We are using the 279 Testbed for our IDS testing. Prelude is a distributed IDS consisting of Sensors and Managers. Currently we have one Manager and Sensor in place. The Prelude code and plugins are in C.

Plugins

Prelude has its own plugins. The plugins are written in C too. It is also capable of importing Snort plugins.

Alerts

The alerts are generated by the sensors and then sent to the Manager which maintains the logs of the alerts. The alerts can be generated in both the IDMEF format or in human-readable text format. All logs are generally made in the /var/log/prelude.log file.

Testing

We tested the IDS against some tcpdumpfiles of some standard attacks and were able to observe the logs of the alerts detected.

Dragon

Team: Rahul and Tirth

We have the Dragon HIDS running on Windows and Linux. In Windows, we have alerts for some signatures which we wrote when Dragon reads the Windows Security Event log. However, we have not been able to read an already existing log file. The Linux HIDS has been installed on Redhat 7.3 which is its minimum requirement. We can have file monitoring turned on, but we need to figure out some signatures for log files to alert on.

Test Data

Intrusion Detection Testing Documents

Class Notes

A reference data set will be defined. Typically the data set will include different types of event streams:

This data set will be gathered using the existing public data sets and the ones that have been collected by the RSG.

The data set will contain a number of intrusions, say T

The hit count H will be calculated, as well as the false positive rate F.

The coverage will be calculated as H/T

The precision will be calculated as H/H + F

The effectiveness will be calculated as (H/T)*(H/H + F)

To evaluate the performances of an intrusion detection system the reference streams should be replayed against the IDS using the appropriate tools (e.g., tcpreplay for tcpdump files) and the CPU/Memory usage should be plotted against the timeline of the experiments.

Extensive testing/research should be performed to find ways to overload or evade the intrusion detection system.

Systems that should be covered in class. If they are already taken, who is going to evaluate them: