Transmitting Auditable Events to Remote Machines HowTo

About

This document provides a description how the system can be configured to transmit the auditable events that are generated by the system to a remote machine, using syslog.

Introduction

The system produces a great number of auditable events, to provide detailed and traceable information about the system’s operation. For more details about auditable events, see the Auditable Events.

This document describes how to configure the system to ensure that auditable events are transmitted to remote machines, such as a central logging server. By default, every time an auditable event is generated by the system, it is also logged as a syslog message. Therefore, to send the auditable events to a remote machine, simply configure the system to transmit the generated syslog messages to the remote machine. In other words, sending the auditable events to a remote machine is the same as sending any other syslog message to a remote machine.

This entire HowTo expects the base configuration to be based on the configuration and setup described in the Logging to Remote Machines HowTo. Because of this, we will not repeat the configuration steps that are already described in that document. What we will detail here is simply the minor addition that is required to ensure that the auditable events are transmitted to the remote machine. Therefore, it is recommended that you read the Logging to Remote Machines HowTo first and base your initial configuration on that document.

Configuration

Essentially the only thing that differs from the configuration described in the Logging to Remote Machines HowTo is that the specific local source type audit should be set for the logging source that is used to log the auditable events.

In the above mentioned HowTo the configuration of a source called local is described. The configuration of the local source can be adjusted to also include the audit log messages:

S1:/#> configure
S1:/config/#> logging
S1:/config/logging/#> source local
S1:/config/logging/source-local/#> audit
S1:/config/logging/source-local/#> end
S1:/config/logging/#>

Or a new a new source can be created, that only specifies the audit log messages, if those are the only log messages that should be transmitted to the remote machine. So in this case, lets simply name it audit:

S1:/#> configure
S1:/config/#> logging
S1:/config/logging/#> source audit
S1:/config/logging/source-audit/#> type local
S1:/config/logging/source-audit/#> no userspace
S1:/config/logging/source-audit/#> no kernel
S1:/config/logging/source-audit/#> audit
S1:/config/logging/source-audit/#> end
S1:/config/logging/#>

If a new source is created, ensure that this is also attached to the relevant sink configuration, mapping the source, destination and the optional filter together, as described in the other HowTo’s Step 3: Sink Configuration. If the new source audit should be added to the existing sink remote:

S1:/#> configure
S1:/config/#> logging
S1:/config/logging/#> sink remote
S1:/config/logging/sink-remote/#> source audit
S1:/config/logging/sink-remote/#> end
S1:/config/logging/#>

Where the configuration should now look something like this:

S1:/config/logging/#> show
example:/config/logging/#> show
Console syslog   : Disabled
External logging : Disabled
Secure mode      : Enabled

╒ Sources ═══════════════════════════════════════════════════════════════════╕
│NAME                                                                        │
│Type: local      USERSPACE  KERNEL  AUDIT                                   │
│local            Yes        Yes     No                                      │
│audit            No         No      Yes                                     │
└────────────────────────────────────────────────────────────────────────────┘

╒ Destinations ══════════════════════════════════════════════════════════════╕
│NAME                                                                        │
│Type: remote     TRANSPORT  TO-HOST       PORT   FORMAT                     │
│remote           udp        192.168.1.99  514    rfc5424                    │
└────────────────────────────────────────────────────────────────────────────┘

╒ Filters ═══════════════════════════════════════════════════════════════════╕
│NAME             INVERT        TYPE  FILTER                                 │
├────────────────────────────────────────────────────────────────────────────┤
│No filter(s) currently configured...                                        │
└────────────────────────────────────────────────────────────────────────────┘

╒ Sinks ═════════════════════════════════════════════════════════════════════╕
│NAME             SOURCES       DESTINATIONS   OP FILTERS                    │
│remote           local         remote                                       │
│                 audit                                                      │
└────────────────────────────────────────────────────────────────────────────┘

example:/config/logging/#>

By Default From Factory Configuration

From the factory configuration, a specific logging source named audit should exist, that simply specifies a type local that only provides the auditable events log messages. This is in addition to the default logging source local, that simply takes all regular log messages from userspace and the kernel. The audit source is used to separate the auditable events from the regular log messages, so that they can be treated differently, if needed.

Verification

For verification refer to the Logging to Remote Machines HowTo. The exact same steps can be used to verify that the auditable events are transmitted to the remote machine.

Conclusion

This document described how to configure the system to transmit the auditable events that are generated by the system to a remote machine, using syslog, with the same basic logging setup as described in the Logging to Remote Machines HowTo. Essentially the only thing that differs is that the specific local source type audit should be set for the logging source that is used to log the auditable events.