S 5.71 Intrusion detection and intrusion response systems

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

One of the key tasks of a firewall administrator is to analyse the log data generated in order to be able to detect attacks promptly. In view of the wealth of data and the huge variety and complexity of possible attacks, this entails a considerable amount of work. Here, intrusion detection (ID) and intrusion response (IR) systems can help.

The aim of an ID system must be to support an average administrator so that they are able to detect an attack amongst a large volume of log data without needing in-depth knowledge in the field of Internet security. IR systems, on the other hand, are a means of ensuring that countermeasures are automatically initiated as soon as an attack has been detected.

Ideally, these programs will have as much information at their disposal as a good administrator and will be therefore able not only to detect an attack in any log data, but also to provide an indication of the severity of the threat and what countermeasures are necessary. Currently, however, this field is still the subject of intensive research so that significant improvements to existing programs are possible at any time.

Intrusion detection systems can essentially be divided into two classes: signature analysis and anomaly detection.

Signature analysis is based on the assumption that many attacks can be detected on the basis of a certain sequence of log data. One example is the technique known as port scanning. A would-be intruder establishes in advance of an attack which services on the attacked computer are addressable, i.e. with which TCP ports it is possible to establish a connection. This involves using a program to send a connection setup packet to all the TCP ports one after another. If a connection is established, a service is installed there and can be attacked. The typical signature, i.e. distinctive feature, of this attack is simple: connection setup packets which are sent successively to all TCP ports.

The problems with this type of intrusion detection are immediately apparent, however: In what order do the ports have to be addressed and at what time intervals in order to distinguish between an attack and normal operation? The latest port scanning programs operate in such a way that they do not scan port 1, port 2 through to port n, but do this in a random order. It is also possible for the packets not to be sent directly one after the other, but at random intervals (e.g. 1 s, 100 ms, 333 ms, 5 s ...). This makes it difficult to determine the signature.

A subtle version of port scanning involves sending individual packets from different source addresses. Used in connection with the time-staggered initiation of the packets, as described above, the probability that an attack will remain undetected is currently very high.

In the case of anomaly detection, on the other hand, the assumption is that the normal behaviour of users or computers can be statistically recorded, and deviations from this are judged to be attacks. One example of this is the time period during which a user is normally logged in at his/her computer. For example, if a user almost always works from Monday to Friday from 8 a.m. to 5 p.m. with deviations of no more than two hours, any activity on a Saturday or at midnight can be classified as an attack. The problem with anomaly detection is how to determine what normal behaviour is. For this purpose, some conclusions can be drawn on the basis of threshold values or probability considerations. Whether it makes sense to immediately classify an activity by the user A on Monday at 7.10 p.m. as an attack appears questionable. Also, the normal behaviour of a user is subject to change, meaning that adjustments have to be made. But who tells the ID system that this change in behaviour is normal and not an attack?

It also makes sense to subdivide ID systems according to the type of data acquisition involved. This can be done either with the aid of a dedicated sniffer somewhere in the network (network-based ID system), or it can be part of normal logging functionality on one of the connected computers (host-based ID systems). There are advantages and disadvantages to both. It may be easier for network-based systems to detect a wide-ranging attack that affects multiple computers at the same time. However, it is a lot more difficult to detect complex attacks (e.g. via other interim stations) on a single computer. In addition to this, network-based systems cannot analyse encrypted data. In the case of host-based ID systems, on the other hand, extensive changes may have to be made to the logging functions of the computers before they can be used.

As data protection stipulations or personnel agreements also have to be observed even when log information is evaluated automatically, it may become necessary under certain circumstances to store this data under a pseudonym.

The following aspects should be taken into account before coupling ID system, IR system and firewall:

In order to rule out attacks against an ID system itself, this should be invisible from the network as far as this is possible. The simplest safeguard is to assign an IP address that is not routed on the Internet. In addition, it is recommended to deactivate the ARP protocol for the corresponding interface so that there is no response to either ARP or IP packets.

Review questions:

© Federal Office for Information Security. All rights reserved.