Some things that go wrong don’t necessarily mean your system has experienced an intrusion, but are nonetheless suspicious. The daily security check looks for a whole slew of misconfigurations and problems that arise from either malice or incompetence. You can read the list of checks in security(8), but they break down into fairly broad categories:

Note that the security check is not an intrusion-detection system. The changes it checks for are the sort that script kiddies and newbie intruders are most likely to make, but skilled intruders familiar with OpenBSD could get around it. They could even replace the security check with a shell script that sends a daily email message that looks like an innocuous security check.

Fortunately, competent intruders are relatively rare. Just keep in mind that receiving a security check with no mention of problems is encouraging, but it’s not proof that your server is secure.

The daily security check tests for changes in the files listed in /etc/changelist and rotates their backups, since these files are generally critical system files, such as /etc/master.passwd, /etc/boot.conf, and /var/cron/tabs/root. It also checks for changes to disk partitioning and mounted filesystems, as well as changes to device nodes.

Look in /var/backups, and you’ll see files like this:

…
etc_fstab.backup
etc_fstab.current
etc_ftpchroot.current
etc_ftpusers.current
…

The files ending in .current are copies of these files as they existed when the daily maintenance job was last run. The files ending in .backup are the previous version of those files.

The first time the security script runs, it copies all of these files to /var/backup. Following that initial setup, the security script checks the original file against the current copy for changes. If the file changes, the previous version of the file is copied to the .backup filename, and the new version is copied to the .current file.

In the preceding example, the list shows that I edited my /etc/fstab at some time, prompting the security script to move its copy of the old filesystem table to a .backup file. I have never edited /etc/ftpchroot or /etc/ftpusers, so there is no .backup version of these files, but only the .current one.

The security script doesn’t copy all of the files that it watches. For example, files containing private keys or that might contain private keys are not copied, but the security script does take a checksum. (Files monitored by checksum have a plus sign before their name in /etc/changelist.) There’s no reason to manually edit /etc/ssh/ssh_host_ecdsa_key, and if the file changes, either you know why or you need to restore from a trusted backup.

/etc/changelist is itself listed in /etc/changelist. This seems recursive, but the system backs up the list of files you want backed up, and also notifies you when someone adds or removes a file in /etc/changelist.

You can add files to the change list and even use wildcards to back up all the files in a directory. But note that if you did use wildcards in /etc/changelist, you won’t be notified when a file is removed.

Consider this example of using wildcards. In Chapter 13, I added the apache2 port to one of my machines. I put the configuration files in /etc/apache2. I could add a line like this to the change list:

/etc/apache2/*

This would automatically copy all files in the apache2 configuration directory to /var/backup and test them for changes. However, I would not be notified when files are removed from this directory. If you’re using a configuration mechanism that says, “include all the .conf files in such-and-such directory,” this might not be desirable. A better option would be to list each file individually and update the list when you add critical files.

One of the most convenient things about the file-integrity check is that it automatically creates a local backup of critical system files. That means that if you decide to learn how to use vipw(8) and utterly trash your user database in doing so, you can grab yesterday’s copy out of /var/backups, install it, and no one will be the wiser. The same applies to every other critical system file.

You can’t run a full-on Unix File System (UFS) check while a system is in multiuser mode, but you can have fsck(8) perform filesystem integrity checks to try to identify problems before they’re serious. Doing so won’t fix any problems, but it will notify you that they exist so you can schedule downtime for repairs.

To enable these checks, set CHECKFILESYSTEMS to 1 in /etc/daily.local.

The rdist(1) program is used to copy files to other servers, letting you maintain identical copies of critical files on many servers. If you’re interested in using it, see rdistd(8).

Some of us have monitoring systems that track a server’s disk, network, and other basic information. If you don’t need this sort of information to appear in your daily status mail, set VERBOSESTATUS to 0 in /etc/daily.local. This turns off these parts of daily maintenance, reducing the amount you need to read.

If the remaining daily maintenance doesn’t generate any output, the server should not send a status email that day. In environments where you don’t trust the monitoring system, you could use the daily status messages to assure you that the system is running as expected. OpenBSD gives you the choice.