S 4.205 Logging on routers and switches

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Routers and switches usually offer logging options. The analysis of this information makes it possible to judge whether the equipment is functioning correctly and to detect attack attempts. With the help of the log information, the type of attack attempted can also often be determined, and the configuration can then be modified accordingly.

Hence, the logging options should always be used and configured carefully. The careful configuration is particularly important, because it is only possible to extract the relevant data from the mass of information generated when appropriate filters are used. Above all, this includes the detection of rejected access attempts and changes to the configuration.

As log files usually contain personal data, steps must be taken to ensure that this data is only used for the purposes of monitoring adherence to data protection requirements, data backup or ensuring that operations are being carried out in the proper manner (see S 2.110 Data protection guidelines for logging procedures). The scope of logging and the criteria used in evaluating log files should be documented and agreed on within the organisation. If necessary, any other committees having a say in this matter should become involved early on.

The following information should be logged if possible:

The last item in particular should be activated for each ACL in order to record all failed attempts and to be able to detect any rules that were configured wrongly or incorrectly.

Depending on the manufacturer, there may be some aspects that cannot be recorded by logging. Examples include the following:

In this case, other types of check should be considered in order to be at least able to establish the fact that changes have been made.

In general, the information to be logged is assigned to different classes. Thus, it is possible to filter the logged data specifying the log class to be output in the configuration.

In addition to suitably storing the information, it is important to evaluate it as promptly as possible. Here, there are a number of different output possibilities which can be tailored to individual requirements and also be used in combination with each other:

User session

The log information can be shown in an existing user session. This requires that the logging and session are configured appropriately.

Memory

Log information can be stored in local RAM. The amount of memory required for this will depend heavily on the type and application scenario of the device so that it is not possible to make any specific suggestions at this point. Storing the log information on a central server (Syslog) is to be preferred to storing it in the RAM.

SNMP

Depending on the manufacturer, SNMP messages can be generated on routers and switches for a number of events. They can then be recognised, displayed and processed by an existing network management system. This enables automated evaluation.

Output at the console

The output of the log information at the console does not allow permanent storage and can therefore only serve to supplement other methods.

Central authentication server

When using a central authentication server, for example TACACS+ or RADIUS, the logging (Accounting) implemented there can be used to document user activities.

Syslog

The log information can be transmitted to a separate Syslog server (for example, on a Unix computer) via the network. This server is then used to collect and archive the log information at a central location, since there are usually not enough resources available for this purpose on the network components. This means that relevant information can be captured and evaluated at a central location. In addition, this offers the advantage that an attacker will not be able to directly change or delete any log information already transmitted when a device becomes compromised.

In most cases, the data is transmitted to the Syslog server in unencrypted form via TCP or UDP so that the possibility that it could be read by an unauthorised party en route cannot be excluded. As a result of sending information from the internal network, the confidentiality of the information available in the internal network can be endangered. It is therefore worth considering whether the information should be transmitted using a separate network (administration network).

NTP

A correct time stamp should be applied to all log information, if possible. This is the only way to ensure the effective evaluation of this data, especially when analysing attempted or successful attacks. For this reason, a corresponding server should be installed in the internal network that provides all systems with the correct time. For example, this can be done on the basis of the NTP service. To this end, consideration should be given to the possibility of setting up a separate time server in the internal network, which, for example, is located on a separate computer that is connected to a radio-controlled clock. Alternatively, a suitable computer can serve as a NTP proxy and obtain the time information by NTP from a time server on the Internet (for example, from the Physikalisch-Technische Bundesanstalt (PTB)). In case of doubt, the first solution (internal time server with radio clock) should be preferred, especially in networks with high protection requirements. Under no circumstances should all the devices be allowed to send individual NTP requests directly to time servers on the Internet.

Review questions:

© Federal Office for Information Security. All rights reserved.