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
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.
- 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)
-
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 ...
- Copy the install package to the target hosts.
-
(As root) Untar and make install
tar xzf *-root-encrypt_*.tar.gz
cd root-encrypt/
make install
-
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
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
