Motivation

Especially for server's which are required to run 24/7 it is absolutely crucial that one stays updated on the machine's status. E.g. using programs like the smartd daemon of smartmontools provides a good method to detect ageing hard disk long before failures actually occur. Like many other daemons smartd primarily logs its findings to syslog. So in order to detect possible problems in advance we need to crawl through tons of lengthy logfiles each day, right? — Fortunately not.

A script library called logcheck is built to solve exactly this problem. It looks through the syslog and auth.log (and in principle many more) logs, filters and summarises the entries and sends off hourly reports to an email address. As these emails usually contain sensitive information about the system's internals it is a good idea to encrypt these using gnupg and public-key cryptography. As it turns out this process is fully automatable and — if implemented right — does not only encrypt logcheck emails but in fact all other emails sent to the root user as well.

Prerequisites

On the servers on which we finally want to use the package, we need the programs

• make
• mime-constuct
• gnupg

Futhermore a mail delivery agent(MDA) that understands and interprets sendmail-style .forward files is required. The recommended MDA/MTA system is postfix. Others were not tested.

The machine which is used for the preliminary steps (see below) should have your public key in the current user's gnupg keyring. make is also required on this machine.

Setup guide

The preliminary steps bundle your public key with the encrypt_mail.sh script and produce a tarball which can be copied to and installed on as many systems as you want via pretty much a simple make install.

1. Find the long keyid of the key you want to use. The long keyid consists of the last four 2-byte blocks of the fingerprint. E.g. for my key this would be 3887DB6744A9DF9F. (Note the omitted spaces)

2. Download, untar and run make install-package:

   wget https://github.com/mfherbst/root-encrypt/archive/05603e08705e10a493541911dbb27ed7a67e9555.zip -O root-encrypt_dist.zip
   unzip root-encrypt_dist.zip
   make install-package
   

   In the process of creating the install package, the script will ask you for the email address you want to deliver the mails to and the long keyid you determined above:

   Please enter the email address to forward root mail to: mail@example.com
   Please enter the long key id of the key used for encryption: 3887DB6744A9DF9F
   

The resulting install package contains both the current date as well as your long keyid in its name.

To finish the installation ...

1. Copy the install package to the target hosts.

2. (As root) Untar and make install

   tar xzf *-root-encrypt_*.tar.gz
   cd root-encrypt/
   make install
   

3. Test setup by sending a mail to root:

Detailed description

The installation creates a new user root-encrypt with home directory /var/lib/root-encrypt and adds the selected public key to this users gpg keyring. Whenever mail is sent to this user, the forward file /var/lib/root-encrypt/.forward instructs the MDA to pipe this mail to encrypt_mail.sh. The latter script takes this message, encrypts it with gnupg and your key and sends it off to your email address. Internally this script buffers the emails in temporary files and uses a very simple queue-like system to ensure that mails do not get lost if e.g. power outages or something else happens during processing: Whenever the next message is sent to root-encrypt all older messages are processed as well. Note, that this can lead to duplication of messages if the MDA also re-sends the messages after an error. In short the user root-encrypt serves as a encrypt-wrapper for mail sent to it.

The missing link to achieve our goal is that all mail sent to root is forwarded to root-encrypt. Exactly this is achieved by adding the line

root: root-encrypt

to the /etc/aliases file.

Finally one might wonder why it is even necessary to add an extra user. At first sight it seems more direct to have root's /root/.forward file instruct the MDA to pipe all mails to encrypt_mail.sh straight away. As it turns out this does not quite work as intended. For security reasons the MDA runs scripts given in /root/.forward not as the root user, but as nobody instead. And since the nobody user tends to be used by other services as well for low-privilege work, I figured it was a wiser choice to add a different user for processing root's emails.

Attachments