S 4.225 Use of a logging server on a security gateway

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Complex security gateways often produce large amounts of different logged information of the different components. In order to facilitate the process of analysing the logs, it is recommendable to operate a logging server (log host) at a central location receiving the logged data of the components connected to the security gateway. This way, the data can be easily related to each other and therefore facilitates regular, event-independent analysis and allows for finding the person responsible in the event of a failure (see also S 4.47 Logging of security gateway activities).

The position of the centralised log host is problematic, because it must be available from all components of the security gateway on the one hand and, on the other hand, it must not allow for any unauthorised access from the untrustworthy network.

If the log host is compromised, compromising the other components is significantly easier due to the central position within the security gateway. Therefore, a centralised log host in the security gateway should only assume this function and should not be used for any further tasks (for example as administration computer).

In connection with logged data, the following should be observed:

The generation of alarms in the event of defined, critical events is another important logging element. It must also be observed in this regard that forwarding the alarm messages to a central instance must be possible.

For positioning a log host, the most important criterion is that no additional vulnerabilities are created, e.g. the option of bypassing security components. Moreover, it must be taken into consideration that the logged data must cross as low a number of components of the security gateway as possible when being stored on a centralised log host. If logged data is sent using proxies, the data is displayed together with the IP address of the proxy in the log files so that the actual sender can no longer be discerned directly, unless the logging functions on the individual components allow for the data to be identified accordingly.

Ideally, log hosts are positioned in a separate administration network. In this case, the log host is exclusively accessed from the administration network.

Positioning the log host in the administration network
Figure 1: Positioning the log host in the administration network

If no separate administration network is available, the log host must be operated in the productive network. Depending on the structure of the security gateway, the aforementioned results in two recommended positions for a centralised log host:

Positioning for simple security gateways

For a simple security gateway only consisting of an individual packet filter, it is recommendable to position the log host in a separate DMZ of the packet filter. Normally, packet filters offer a sufficient number of network interfaces or can be extended easily so that a specific log host DMZ can be used.

Positioning the log host for simply structured security gateways
Figure 2: Positioning the log host for simply structured security gateways

Positioning for complex security gateways

For more complex structures of security gateways, it is normally necessary to direct the logged data to the log host using a proxy.

As a matter of principle, a differentiation between positioning the log host in a separate DMZ and positioning the log host in a common DMZ with other modules of the security gateway must be made.

The following figure shows a solution where a centralised host was positioned in a separate DMZ and is used jointly by two separate security gateways.

Positioning the log host in a dedicated DMZ.
Figure 3: Positioning the log host in a dedicated DMZ.

Positioning the log host in a separate DMZ provides the advantage that the attacker only has a few further attack options if the log host is compromised, since the only directly available modules of the security gateway are the ALGs. However, these are normally provided with special protection against attacks.

For the solution shown, it must furthermore be noted that the integration of the log host created a "cross connection" between the two trustworthy networks that would not have existed without the integration of the log host. For this, a separate risk assessment is required. If necessary, the cross connection must be relinquished resulting in the use of two separate log hosts, the logged data of which may need to be merged for analysis purposes.

Within the framework of the solution shown in the figure below, further modules of the security gateway are located in the same DMZ as the log host. These modules may constitute further points of attack upon log host integration, because these are not necessarily specifically developed security products. Therefore, these modules may possibly be integrated particularly easily.

Positioning the log host in a DMZ containing further components of the security gateway.
Figure 4: Positioning the log host in a DMZ containing further components of the security gateway.

Therefore, the solution where the log host is positioned in a separate DMZ must be preferred over this solution.

Positioning the log host in a DMZ containing further components is only recommendable if the ALG does not provide a sufficient number of network interfaces.

The following table summarises the recommendations:

Structure of the security gateway Protection requirements Position of the log host
Only packet filters Normal Log host in a separate DMZ of the packet filter
Complex security gateway (P-A-P) Normal Log host acceptable in a common DMZ containing other components.Separate DMZ recommended for the log host.
Joint use of a log host by several security gateways High Log host in a separate DMZ

Table: Recommendations

Review questions:

© Federal Office for Information Security. All rights reserved.