S 4.47 Logging of security gateway activities

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

It must be defined which events are logged and who evaluates the logs. Logging must comply with the legal provisions applicable in each case. For logged data, the purpose limitation according to § 14 BDSG must be observed in Germany in particular.

The following items should be taken into consideration for the use of the logging function on the security gateway:

• It must be possible to unambiguously allocate the logged data (for example IP addresses) to individual computers (or persons). In so doing, the legal provisions in the field of data protection applicable in each case must be taken into consideration, however.
• The logged data should not only be stored to the individual components of the security gateway, but also additionally to a central logging server (log host) so that the risk of a loss of data as a consequence of a hacker attack or system failure is reduced.
• The logged information must be transmitted from the components to the log host using a secure connection so that the logged information cannot be modified before being stored finally.
• If untrustworthy networks are passed while transmitting the data to the log host, the data must be encrypted.
• The size of the free memory space on the medium used should be checked at regular intervals.
• In the event of a logging failure (e.g. due to a lack of memory space on the hard disk), all functions generating logged data should be blocked. Ideally, the security gateway should block any traffic and provide the administrator with a corresponding message.
• The logged data should be stored to a WORM medium ("Write Once, Read Many").
• The type and extent of logging should depend on the sensitivity of the data to be processed and on the purpose.
• Specific, configurable events, e.g. repeated incorrect password input for the user ID or inadmissible connection attempts, must be highlighted in the logs and should trigger an immediate warning of the firewall administrator.
• The individual components should perform time synchronisation in order to allow for data correlation. For this, see also S 4.227 Use of a local NTP server for time synchronisation.

For small networks where only a simple security gateway is used, an additional log host may not be required.

Extent of logging on the packet filter

Logging on the packet filter should at least include all packets rejected based on a packet filter rule.

Depending on the security requirements, additional classes of packets may be worthwhile:

• "Unusual" packets, for example containing an incorrect combination of TCP flags or packets with incorrect header information.
  
  Such packets should be rejected by a corresponding packet filter rule anyway and therefore already captured before logging, but it is nevertheless advisable to log such packets separately, since they may be indicative of so-called "stealth scans", for example. Furthermore, an accumulation of incorrect packets may be indicative of problems in the network.
• For connection-oriented (for example TCP-based) protocols, it may make sense to also log accepted packets belonging to a connection establishment (for example TCP packets belonging to the 3-way handshake), as well as any additional packets belonging to the disconnection of an established connection.
• Regarding connectionless protocols not used to transmit large amounts of data (for example UDP-based protocols such as DNS), it may make sense to log all packets.

Which classes of packets are logged additionally depends first and foremost on the protection requirements of the trustworthy network. However, logging alone does not increase the security, but the information must also be evaluated according to corresponding criteria.

At least the following information should be logged for the packets for which logging is desirable:

• source and destination IP address
• source and destination port or ICMP type
• date and time
• applicable rule of the packet filter

If an ALG is used in addition, logging the accepted packets is not necessary, since the proxy usually logs sufficient connection information in this case.

Extent of logging on the application level gateway

On the ALG, protected against the majority of inadmissible packets by the outer packet filter, the following data should be logged for every (successful or attempted) connection establishment:

• source and destination IP address
• source and destination port
• service
• date and time
• connection duration
• any authentication data or only the fact that an authentication failed

It must be possible to switch off the logging function for certain users so that important information is not overlooked due to too high a number of log entries. This selection may be made based on the rights profile of individual users, for example.

Moreover, the following settings are recommended for the individual logs:

DNS

• rejection of queries
• acceptance of queries
• (outgoing) zone transfers initiated by other computers
• (incoming) zone transfers initiated by the ALG

Normally, zone transfers are prevented by the operator of the DNS server so that these checks can be dispensed with.

FTP

• destination address (URL)
• rejected PORT commands
• name of the file transmitted
• amount of the data transmitted
• status message

HTTP

• destination address (URL)
• amount of data transmitted
• connection method (e.g. GET, POST, CONNECT)
• note regarding applied filter criteria
• status message

NNTP

• destination address (URL)
• amount of data transmitted
• status message

SMTP

• email address of the sender and recipient of the email
• amount of data transmitted
• note regarding applied filter criteria
• status message regarding successful or failed forwarding

No specific logging is required for the following modules:

Module	Reason for discontinuation of logging
HTTPS	Is connected "in series" with an HTTP proxy which already carries out logging.
Maintenance module	Relevant logged data is not generated.
IDS	Logged data is delivered separately on the IDS. This data should not be stored centrally in order to prevent the modules of the security gateway from being bypassed.

Table: Modules without separate logging

Logging is greatly simplified if the software allows free configuration of the "logging facility" (i.e. identification of the individual log entries). This way, it is possible to assign an unambiguous ID to every service the log host can use in order to distribute the logged data to different files.

If the logged data is sent to a central log host using the network, it must be ensured that the log entries of different computers and services are identified in such a way that they can be assigned unambiguously. Additionally, it makes sense that all services provide their logged data with consecutive numbers. This way, the loss and/or manipulation of logged data can be detected.

Evaluation of the logged data

The evaluation of the logged data may be supported by specific tools (log file analyser). These show the log files in different ways with most tools using regular expressions in order to extract relevant data from the log files. Although there are lists containing reasonable regular expressions for the purpose of logged data evaluation, adaptations are usually required in the individual cases.

Examples for different outputs of the log files include:

• Grouping and highlighting the related logged data (e.g. LogSurfer)
• Indication of relevant logged data, with the option of hiding irrelevant data using regular expressions. This way, the logged data documenting a successful operation (e.g. GET for HTTP) may be hidden, for example (e.g. checksyslog).
• Indication of attacks. In this connection the logged data must be analysed in real time.
• Statistical analysis of the logged data (e.g. the frequency a message occurred).

Along with the pure representation of relevant logged data, there are tools allowing for actions depending on a recognised abnormality (e.g. execution of a command).

Conspicuous log entries include, for example:

• accumulating queries to ports not running any services
• unsuccessful access attempts to components of the security gateway
• packets received from the untrustworthy network containing IP addresses of the trustworthy network (indicative of IP spoofing)
• suspicious, outgoing connections of servers from the trustworthy network. These may be indicative of the attacker, upon a successful intrusion, copying data from the trustworthy network to the outside or uploading data from the outside he/she needs for his/her subsequent activities.

The log files must be evaluated regularly and it should be defined which evaluations should be performed as a minimum. Moreover, at least rough guidelines should be defined as to which steps must be taken if conspicuous entries are found within the framework of the evaluation.

Review questions:

• Has it been defined which events on the components of the security gateway are logged?
• Are the log files evaluated regularly?
• Does logging comply with the applicable data protection regulations?
• Is the logged data stored to a central logging server in addition to local storage?
• Is the logged information of the components of the security gateway transmitted using a secure connection?
• Is an alarm generated and are the functions for logged data generation disabled in the event of a failure of the logging server?
• Is the data traffic at the security gateway blocked in the event of a failure of the logging server?
• Is the logged data protected against modifications?
• Do the manner and extent of logging correspond to the specifications of the organisation's security policies?
• Does logging at packet filters at least include the following information: source and destination IP address, source and destination port or ICMP type, date and time, as well as the applicable rule of the packet filter?
• Are all connections logged on the application level gateway?
• Are there escalation procedures for the case that conspicuous entries are identified within the framework of the evaluation of the security gateway logs?