Audit Log Keeper

About

Audit Log Keeper is a software for buffering incoming messages and delivery
them to the destinations. A destination can be any type of storage or search
index etc as long as they are supported by Audit Log Keeper.

Requirements

- SUSE Linux Enterprise. :-) Works also on any other Linux distribution as well as on BSD systems. Has been also tested on Solaris 11. Potentially works on MS Windows.

- Two network ports. 6868 and 6888 by default, listening only to a localhost.

Before you install

Before the installation, it is important to know that there are three types of
packages available:

1. Audit Log Keeper itself. This is mandatory component.

2. Schema validators for a specific software. At least one validator installed is mandatory.

3. Output plugins. Components are optional as long as output to the STDOUT is enough for you.

What the Schema Validator is?

Schema validators are sanitation filters that rejects inaccurate data from the
client components and assures that the logging events are described in the
same format.

What kind of plugins are?

Output plugins are backend destination adapters to connect Audit Log Keeper with other data storages like databases, search machines, log analyzers etc. Assume there are three destinations log should be delivered: to a remote syslog for quick alerting, EMC Centera for write-only archiving tamper-proof data and maybe just a relational database for search or Novell Sentinell.

When something happens and Audit Log Keeper accepts an event, all those backends will get the same message, but adapted for them in their format that they "understand".

Installation Instructions

The installation procedure described below is possible only on SUSE Linux family (SLE and openSUSE) and expecting that Audit Log Keeper will be used along with SUSE Manager product. Assuming Zypper contains all required repositories, please follow the following steps:

3. Almost optionally (as long as STDOUT is not enough for your audit storage) install an appropriate back-end plugin. For instance, to add the Syslog support, install the syslog plugin:

sudo zypper install auditlog-keeper-syslog

4. Start the service:

sudo /usr/sbin/rcauditlog-keeper start

As of installation, that's all. By default only a local syslog is enabled. It will also will run on machine [re]boot. Next step would be re-initialize internal database with another username and password.

And one more thing. Since Audit Log Keeper is a standalone independent software module, you probably need to manually make it running when your Linux reboots. To let it start automatically, you should issue the following command:

sudo chkconfig auditlog-keeper on

It should enable Audit Log Keeper on lever 3 and level 5.

Post-installation

As of current version 0.1, internal database is connected with user "default" and password "default". No automatic credentials generation yet has been implemented. It is a really good idea to change the default passwords to something else.

In order to reset the credentials and change them, please follow the steps below.

1. Stop the Audit Log Keeper:

sudo /usr/sbin/rcauditlog-keeper stop

1a. SUSE Manager related. Actually, it is a good idea to stop entire SUSE Manager for a while:

sudo /usr/sbin/spacewalk-service stop

2. Remove table file manually (root privileges required):

sudo rm /var/opt/auditlog-keeper/auditlog*

3. Change the password in the config file for the backend.db.auth fields:

sudo /usr/bin/auditlog-keeper --configure

Since the credentials are not meant to be remembered by a human, so anything complicated and non-standard is OK. For example:

Please note that the next version of Audit Log Keeper will deprecate this step necessity.

Configuration

To configure Audit Log Keeper, issue the following command:

sudo /usr/bin/auditlog-keeper --configure

This will just open the /etc/auditlog-keeper.conf file in your $EDITOR.

Configuration file comes already preconfigured and works with a local Syslog by a default. Later you will need only to correct some plugins information.

Main configuration

Option

Description

Choices or default value

backend.db

What embedded database is used. Currently only H2 is supported

h2

backend.db.type

Type of access to the back-end. The value "multiple" will start an embedded server via TCP protocol, while "single" will work in a truly embedded mode. Use "single" only in cases, where system load is little and minimal.

"multi" or "single"

backend.db.port

A port number on which an embedded database is running in case of db.type is set to "multi".

6868

backend.db.auth.user

User name for the embedded database. Make sure you've changed it.

default

backend.db.auth.password

Password for the embedded database. Make sure you've changed it.

default

backend.db.location

Location of the tables of the embedded database. Advice: do not touch it.

/var/opt/auditlog-keeper/auditlog

server.port

XML-RPC port for the log listener. If you are about to change it, you also have to make sure *all* the clients "knows" about the change.

6888

server.pid.filename

A location of the PID file. Advise: do not touch it.

/var/run/auditlog-keeper.pid

Plugin Configuration

To make available a particular plugin among others, use the following syntax:

plugin.available = <TAG>, <TAG>, <TAG> ....

<TAG> in this case can be any single word as a label. Minimum one word and
comma-separated list of more than one. Example:

plugin.available = foo, bar

Each plugin has its own set of config values. They are constructed with the
following structure:

plugin.<TAG>.<VALUE>

To know what <VALUE is for a specific plugin, please refer to the appropriate documentation.

Example

This is an example setting up a local syslog, tagged as "mylocalsyslog":

1. Load a plugin description, pointing to the Audit Log Keeper what class it
should pick up when it starts:

plugin.mylocalsyslog.entry = com.suse.logkeeper.plugins.Syslog

2. Syslog supports three modes: a) local b) remote over TCP and c) remote over
UDP protocol. Let's run it locally, so define protocol as "local":

plugin.mylocalsyslog.proto = local

3. Syslog entry can include time when event happened on the audited
system. This is different time when the entry was actually added to the Syslog
back-end:

plugin.mylocalsyslog.fields.precisetime = on

4. Let the Syslog plugin for the Audit Log Keeper also try to resolve a
hostname out of the IP address and include it into the final message:

plugin.mylocalsyslog.fields.resolveip = on

5. Let the Syslog plugin include extended mapping for the keywords. The extmap
is essential auditing information, where all the sensitive data comes to. In
some cases it might be necessary to mute it for the security reasons, but
still leave only a general messages as a double-confirmation:

plugin.mylocalsyslog.fields.extmap = on

6. Syslog itself is just a text. It will be difficult to reconcile the entries
and filter out what is not required. Signature is just a label that each
message will get as a tag, which will make easier to extract them out of the
general Syslog text:

plugin.mylocalsyslog.fields.signature = spacewalk-audit

7. Add this setup to the available plugins:

plugins.available = mylocalsyslog

And another example

In this example yo will know how to setup a remote syslog via TCP *along* with local. To
achieve this, repeat the steps 1-6 above one more time, just with a different
tag, for example name it as "tcp-syslog". Then do the following changes:

1. Change the protocol to "tcp":

plugin.tcp-syslog.proto = tcp

2. Define a remote host for a Syslog:

plugin.tcp-syslog.host = example.suse.de

3. Define a remote port for a Syslog:

plugin.tcp-syslog.port = 514

4. Add the tag to the list of available plugins:

plugins.available = mylocalsyslog, tcp-syslog

At this point you will have two instances of Syslog plugin running, but one
will deliver messages to the local syslog, another will deliver the same
messages to remote machine.

Audit Log Keeper comes with examples for other plugins in the configuration
file. Please refer there for more information.

Setting up database backend

Since the plugin does support multiple databases (currently only PostgreSQL
and Oracle DB), then tn order to connect any of them, please make sure
appropriate JDBC drivers are also installed on your system. Audit Log Keeper
RDBMS plugin *does not takes care* about driver installation as they can be
used simultaneously and totally independent from each other.

For more information how to setup PostgreSQL or Oracle backend, please refer
to the /etc/autitlog-keeper.conf configuration file and see the examples
there.

Appendix

FAQ and troubleshooting

Frequently Asked Questions as well as Troubleshooting are available here: AuditLogKeeperFAQ