- 1 Audit Log Keeper
- 1.1 About
- 1.2 Requirements
- 1.3 Before you install
- 1.4 Installation Instructions
- 1.5 Post-installation
- 1.6 Configuration
- 1.7 Plugin Configuration
- 1.8 Setting up database backend
- 1.9 Appendix
Audit Log Keeper
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.
- Java Runtime 1.6 from the following major vendor: IcedTea, OpenJDK, Oracle Java, IBM Java.
- 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".
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:
1. Install the Audit Log Keeper itself:
sudo zypper install auditlog-keeper
2. Choose a validator. For example, for SUSE Manager choose "Spacewalk Validator":
sudo zypper install auditlog-keeper-spacewalk-validator
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.
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:
$ date | sha256sum 3ef35cb7feda37abfa9b4501d54d14ef17efab16b8d9831a1131386f81f8b438
4. Start Audit Log Keeper:
sudo /usr/sbin/rcauditlog-keeper start
4a. You followed the better idea, right? Then do this instead:
sudo /usr/sbin/spacewalk-service start
Please note that the next version of Audit Log Keeper will deprecate this step necessity.
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.
|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|
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:
To know what <VALUE is for a specific plugin, please refer to the appropriate documentation.
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.
FAQ and troubleshooting
Frequently Asked Questions as well as Troubleshooting are available here: AuditLogKeeperFAQ
1. Syslog plugin AuditLogKeeperSyslogPlugin
2. XML plugin AuditLogKeeperXMLPlugin
3. RDBMS plugin AuditLogKeeperRDBMSPlugin
About validators configuration
1. Spacewalk validator AuditLogKeeperSpacewalkValidator