PingDirectory

Centralized logging

By default, the PingDirectory server logs to files on the server filesystem. This provides the best option for performance and reliability of the logging mechanism itself.

However, this also has the following disadvantages:

  • If the system crashes in an unrecoverable manner, such as if the storage becomes corrupted, then the log data might be lost.

  • If an attacker is able to gain access to the underlying system, they might be able to alter or delete log files to cover their tracks. Even if the log files are signed so that you can tell that log files have been modified, that doesn’t help you determine what the original content was.

  • It requires more effort to analyze log files and aggregate results when they are spread across multiple systems.

  • In some cases, such as when running in a container like Docker, it might not be easy or possible to get direct access to the instance filesystem.

These issues can be addressed by centralizing log content, and PingDirectory software offers several options to assist with this.

Because PingDirectory server allows you to define multiple loggers of the same type, you can both log to local files and to one or more centralized locations. This can provide the best combination of usefulness and availability.

The UnboundID Server SDK provides support for creating custom access, error, and HTTP operation loggers. If necessary, you can create a custom logger that handles these log messages in whatever way you want.

Logging to a shared filesystem

One simple option for centralizing log content is to have the server log to a shared filesystem.

This is the simplest option, but it only addresses some of the issues outlined previously. While a shared filesystem reduces the need for access to the instance filesystem, it does not necessarily help prevent attackers from altering the files. If attackers gain access to the underlying system and that system has access to files from other instances, they might be able to cause greater disruption than if the content had been kept local to each instance.

Copying files to a centralized system

Another option to centralize logging is to continue to write log files to the local filesystem, but to periodically copy them to a centralized system.

For greater security, the centralized system can pull the files from the instances rather than having the instances push the content, which avoids allowing the server instances to write data to the centralized system.

However, this option still has some security risk associated with it. If an attacker is able to alter log files, then those altered versions will be copied to the centralized system. This can be mitigated to an extent by copying the content more frequently and using versioning when the same copy is copied multiple times, but there is still a window of time in which an attacker can alter the file before it is copied.

Ingesting logs into a log management system

Many organizations use a centralized log management system, such as Splunk or DataDog. In these cases, product log messages can be ingested into that system to make them accessible from a common location, and to provide improved support for analytics and taking other actions upon log content.

There are several ways that log content can make it into the log management system. Some of these options include:

  • Most log management software provides agent software that can read data from log files and send it to the centralized system. In some cases, the agent can stream log data as it is written, which reduces the chance that an attacker has a chance to alter it. In other cases, it can copy the data at configured intervals.

  • For cases in which the target application is running in a container like Docker, a common practice is to have that application write log messages to standard output or standard error, and to forward those streams to the log management software. To help support this, the PingDirectory server provides an option to write access and error log messages, with each message formatted as a JSON object for greater parsability, to standard output or standard error. For more information about logging to standard output or standard error, see the config/sample-dsconfig-batch-files/enable-console-based-logging.dsconfig batch file.

  • The log management software can provide an API that applications can use to write log messages directly to that service. Although the PingDirectory software does not provide support for this out of the box, it is possible to use the Server SDK to write a custom log publisher to take advantage of this API.

Logging with syslog

The PingDirectory server can write log messages using the syslog protocol for both access and error logs.

This allows messages to be aggregated at the system level and potentially forwarded to a centralized system. The messages are written to syslog as they are generated, so attackers do not have a chance to alter these log messages.

If you want to use syslog-based logging, configure the server to log to a syslog server running on the local server over the loopback interface. The local syslog server can then forward the messages to a remote server over a secure connection.

Logging over TCP for improved reliability is supported.

UDP-based communication is in the clear, so a network observer can see all of the log messages. You should only use syslog to log to a local syslog server and have it forward messages to a remote server in a secure manner. TLS encryption for TCP-based communication is optionally supported, so you can safely configure the server to log directly to a remote syslog server.

UDP does not provide any feedback about whether messages are successfully delivered, but TCP does provide this feedback. When using TCP-based logging, you can optionally specify information about multiple syslog servers. If the primary syslog server becomes unavailable, the logger can fail over to an alternative syslog server.

Logging access and error log messages can be logged as JSON objects or in legacy space-delimited text format.

In addition to access and error logging over syslog, loggers that can write JSON-formatted audit and HTTP operation log messages are also provided.

Logging to a remote database

The PingDirectory server can write log messages to a relational database.

This should work with any database that provides a driver that allows it to integrate with the Java Database Connectivity (JDBC) framework. As with syslog, these log messages are written to the database as they are generated in the server, so attackers do not have a chance to alter them before they are written.

Communication with the database can be secured using whatever facilities are provided by the JDBC driver. In most cases, this includes support for TLS encryption.