S 5.71 Intrusion detection and intrusion response systems

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Administrators

One of the key tasks of a firewall administrator is to analyse the accruing logging data so as to be able to detect attacks soon after the event. In view of the wealth of data and the multitude and complexity of the various possible means of attack, this results in a considerable amount of work. Intrusion detection (ID) and intrusion response (IR) systems can help in this.

The aim of an ID system must be to provide assistance to an average administrator to the extent that he or she is able to detect an attack in a large number of logging files without the need for in-depth knowledge of the field of Internet security. IR systems, on the other hand, serve the purpose of initiating countermeasures automatically as soon as an attack has been detected.

In an ideal situation these programs will have as much information at their disposal as a good administrator, and will therefore be able not only to detect an attack in any logging data but also to provide indication of the severity of the threat and what countermeasures are necessary. Currently, however, this field is still the subject of intensive research, so 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 logging data. One example is the technique known as port scanning. In advance of an attack, the intruder first establishes which services on the attacked computer are addressable, i.e. to which TCP ports it is possible to set up a connection. This involves using a program to send a connection setup packet to all TCP ports one after the other. If a connection is established, a service is installed there and can be attacked. The corresponding signature, i.e. distinctive feature, of this attack is simple: connection setup packets which are successively sent to all TCP ports.

The problems with this type of intrusion detection also become immediately apparent, however: in what order do the ports have to be addressed and at what time intervals, if an attack is to be distinguished from 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 variant of port scanning involves sending individual packets from different source addresses. Used in conjunction with the time-staggered initiation of the packets 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 period of time within which a user is normally logged in at her computer. If she almost always works from Monday to Friday within the period from 8 a.m. to 5 p.m. with deviations of no more than 2 hours, any activity on Saturday or at midnight can be classified as an attack. The problem with anomaly detection is how to determine what is normal behaviour. Some conclusions can be drawn on the basis of threshold values or probability considerations. It appears questionable, however, whether it makes sense to immediately classify an activity by user A on Monday at 7.10 p.m. as an attack. Also, a user's normal behaviour usually changes, meaning that adaptations have to be made. Who tells the ID system, though, that this change in behaviour is OK 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 the normal logging functionality on one of the connected computers (host-based ID systems). There are advantages and disadvantages to both. It has to be said that it is easier for network-based systems to detect a wide-ranging attack that affects various computers at the same time. It is considerably more difficult, however, to detect complex attacks (e.g. via other intermediate stations) on one computer. Over and above this, network-based systems cannot analyse encrypted data. As for the host-based ID systems, extensive changes may have to be made to the logging functions for the computers before they can be used.

Because data privacy stipulations or staff agreements also have to be observed even when logging information is evaluated automatically, it may be necessary in some circumstances to store the data under a pseudonym.

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

- Is it possible to deliberately initiate an attack on the firewall which is erroneously interpreted by the ID system as a genuine attack? If the IR system subsequently triggers the disabling of certain services across the firewall, this can have considerable consequences for availability.

- The interaction between the ID system, the IR system and the firewall should be sufficiently transparently documented. Otherwise it is not possible to assess at any one time who the firewall is administered by: by the IR system or by administration staff. If there is any doubt, decisions by the administration staff should take priority.

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