- 1 Audit Log Keeper FAQ
- 1.1 General
- 1.1.1 Q: Where is the default location of the log?
- 1.1.2 Q: What /var/opt/auditlog-keeper/ is for?
- 1.1.3 Q: What happens if Audit Log Keeper crashes?
- 1.1.4 Q: How Audit Log Keeper prevents log tampering?
- 1.1.5 Q: What happens if the embedded database will get out of space?
- 1.1.6 Q: Why not AMQP or other messaging protocol?
- 1.1.7 Q: Why not just another log appender?
- 1.1.8 Q: A standalone daemon?
- 1.1.9 Q: Why it is not written in $LANGUAGE?
- 1.1.10 Q: How fast the thing is?
- 1.1.11 Q: Does Audit Log Keeper takes care of being tamper-proof?
- 1.2 Syslog
- 1.3 Troubleshooting
- 1.1 General
Audit Log Keeper FAQ
Q: Where is the default location of the log?
A: Audit Log Keeper does not keeps anything actually. It only prevents the log message to get lost before delivered. Depending on your setup, in case of standard configuration of the default local Syslog it might be in a /var/log/messages. But might be elsewhere.
Q: What /var/opt/auditlog-keeper/ is for?
A: This is a buffer database that always supposed to be empty. It is encrypted with the password and user ID that is defined in Audit Log Keeper configuration and best for you would be to never touch this directory.
Q: What happens if Audit Log Keeper crashes?
A: Then your client won't connect to its XML-RPC listener. :) At this point it is better than the whole application would panic and stop working, because the audit is not working at all.
Q: How Audit Log Keeper prevents log tampering?
A: It does not prevents tampering, because it does not stores anything. If you need a tamper-proof storage, you should consider either remote RDBMS database (install a plugin for it) or look for EMC Centera product or similar.
Q: What happens if the embedded database will get out of space?
A: Then your admin should be fired. :) The embedded database should be always empty actually. If it grows, it means that messages are still not delivered and one of your destinations is not working. This is easily noticeable, since something supposed to monitor the log.
The database itself is always compressed and encrypted. Therefore in order to grow the tablespace of the embedded database to the size that it will outgrow the entire free space with only change messages (we are talking about tenth of gigabytes here), no one needs to pay attention to anything for a good half a year under pretty heavy load.
Q: Why not AMQP or other messaging protocol?
A: AMQP is only a protocol and the messaging is just the way things are delivered. XML-RPC is a web service and AMQP is a messages through the broker. AMQP will be supported (maybe) in a future.
Q: Why not just another log appender?
A: Auditing is not just logging. And Audit Log Keeper is still sort of appender, just very reliable one. :)
Q: A standalone daemon?
A: Yes. A daemon, because it should not depend on other components that might be faulty and might hose everything.
Q: Why it is not written in $LANGUAGE?
A: Because among "$LANGUAGEs" we also love Java. :-)
Q: How fast the thing is?
A: 1000 messages linearly per 0.42 sec per node. How many nodes? Depends on your hardware and network bandwidth. And your one single machine cannot provide up to 1 kilochanges/second.
Q: Does Audit Log Keeper takes care of being tamper-proof?
A: Not by itself, since Audit Log Keeper does not stores anything anywhere (except inside the encrypted database for a short time, usually less than a fraction of a second). But after the messages delivered to the back-ends like the enterprise archive, for example EMC Centera, then there it becomes tamper-proof.
If you want to have a tamper-proof solution, please take a look at Novell Sentinel.
Q: Why messages has a strange big number in front of each message that is even incomplete?
A: The message is absolutely complete, just too long. Therefore the message gets chopped into the pieces. Here is an example:
Sep 20 16:13:13 ix64ph023 logger: spacewalk-audit 1316527993927 30(wwwrun) at Tue, 20 Sep 2011 16:13:13 CEST ix64ph023.qa.suse.de (10.11.138.23) queue.get_future_actions(1000010060, 24) ('REQ.DOCUMENT_ROOT=/srv/www/htdocs', 'REQ.SCRIPT_URI=https://ix64ph023.qa.suse.de/XMLRPC', 'EVT.SRC=BACKEND_API',
Sep 20 16:13:13 ix64ph023 logger: spacewalk-audit 1316527993927 'REQ.REMOTE_ADDR=10.11.138.1', 'REQ.SCRIPT_FILENAME=/usr/share/rhn/wsgi/xmlrpc.py', 'REQ.SERVER_PORT=443')
As you can see, the message has a common ID, in this case it is "1316527993927". So the message is not incomplete, but just chopped to a two of them.
Q: What was the reason to chop the messages?
A: The reason is that a Syslog, which is working through UDP protocol does not supports more than 1K symbols per a packet. If the message is bigger, than the rest of it will be simply lost. For auditing this is not acceptable behavior.
Q: How do I join chopped messages together?
A: It depends of what kind of software you use to look at the messages. You can parse a syslog file and join the messages by the ID in Perl or other programming languages and then search for what you need in particular.
Q: Syslog is too difficult to work with. How it can be indexed better?
A: Normally, syslog is just as it is: a text file. So it has its own limitations and drawbacks. However, it can be improved with a different implementations of a syslog, like rsyslog or syslog-ng. On top of that, you might try using Splunk search engine (http://www.splunk.com).
But to get full advantage of the audit logging, we strongly suggest not to use Syslog as a whole, but switch to much more sophisticated products, for example Sentinel.
I cannot see messages are appearing
There could be several cases for this.
First, test if the Audit Log Keeper is running at all. To do so, please run the following command:
If you get other than "running" result, then you need to figure out why the Audit Log Keeper is not running on your system.
Second, look if you have installed plugins correctly and they are not failing during Audit Log Keeper run, and you enabled them in the Audit Log Keeper configuration file.
Third, look if your partricularapplication actually has audit logging enabled.
List of applications, that supports Audit Log Keeper
1. SUSE Manager 1.2. Add audit.enabled = 1 to the /etc/rhn/rhn.conf
2. RedHat Spacewalk. Add audit.enabled = 1 to the /etc/rhn/rhn.conf
The service auditlog-keeper does not starts after reboot
By default, Audit Log Keeper comes turned off and does not starts. In order to enable it, please run the following commands:
1. Check if service is really turned off:
$ sudo /sbin/chkconfig auditlog-keeper auditlog-keeper off
2. Turn on the service:
sudo /sbin/chkconfig auditlog-keeper on
3. Verify if the service is now turned on:
$ sudo /sbin/chkconfig auditlog-keeper auditlog-keeper on
These instructions does not affects currently running daemon.