Security Monitoring and Enforcement with Cfengine 3

Cfengine is well known as a powerful system configuration management tool, but did you know you also can use it to secure your systems?

Cfengine, from the start, has had security as a key part of its design and use scenarios. Here, I demonstrate how Cfengine 3 can be used to increase the security of a Linux system by monitoring file checksums, monitoring filesystems for suspicious filenames, monitoring running processes, monitoring open ports and managing sshd.conf.

Because Cfengine 3 is under active development, I suggest you install the latest version from the Cfengine Source Archive (see Resources).

The purpose of this article is to give practical examples of how you can use Cfengine to increase security on a Linux system. See the Quick Start Guide in the Resources section of this article for help in learning the Cfengine language. (I don't provide a tutorial on the Cfengine language here.) This article is based on Cfengine version 3.1.5a1.

Monitoring File Checksums

Cfengine 3.1.4 shipped with 214 unit tests that can double as examples of Cfengine's functionality. They are installed to /usr/local/share/doc/cfengine/. I've adopted into (Listing 1).

Run this with:

cf-agent -KIf

cf-agent is the component of Cfengine that actually makes changes to the system. (There are other components to serve files, monitor system activity and so on. cf-agent is the piece that makes changes to the system, and the one you'd use to start learning Cfengine.) In the command above:

  • -K — tells cf-agent to ignore time-based locks and allows you to run cf-agent repeatedly (no “cool-off” period, which might otherwise kick in to prevent system overload).

  • -I — tells cf-agent to inform you of its actions and any changes made to the system.

  • -f — specifies the policy filename.

On the first pass, cf-agent builds a file information database containing file timestamps and inode numbers and builds an MD5 hash for each file. You should see something like this:

# cf-agent -KIf
  !! File /etc/hosts.allow was not in MD5
     database - new file found 
  I: Made in version 'not specified' of
     '' near line 22

There are two messages here, alert and info.

Cfengine prefixes its output to help you understand what kind of output it is (in other words, metadata):

  • Informational messages start with “I”.

  • Reports start with “R”.

  • Alerts start with !! or ALERT.

  • Notice of changes to the system starts with ->.

In the above case, the alert message is accompanied with an info message about the policy that was in effect when the alert was produced, its version number (if supplied) and the line number.

I didn't specify the version number, but the line number is useful. Line 22 is:

changes      => detect_all_change,

This is the line responsible for Cfengine adding /etc/passwd to the MD5 database. It tells Cfengine what to do about changes—to detect them.

Now, I run cf-agent again, and it runs quietly. The contents of /etc match the MD5 sum database:

# cf-agent -KIf

Next, I edit /etc/hosts.allow to add “sshd: ALL” to simulate an unauthorized change. Watch cf-agent scream:

# cf-agent -KIf
ALERT: Hash (MD5) for /etc/hosts.allow changed!
 -> Updating hash for /etc/hosts.allow to
I: Made in version 'not specified' of
'./' near line 22
ALERT: inode for /etc/hosts.allow changed
38901878 -> 38901854
ALERT: Last modified time for /etc/hosts.allow
changed Sat Jan 29 17:09:26
2011 -> Mon Jan 31 08:00:02 2011

There are three alerts:

  1. MD5 hash changed (because the contents changed).

  2. The inode number changed (when vi saved the file).

  3. The modification time changed (when vi saved the file).

Reminder: messages about actions that Cfengine takes are prefixed with “->”:

 -> Updating hash for /etc/hosts.allow to

You can set up Cfengine to complain via e-mail or syslog, so even if the intruder tampers with the MD5 database, the alarm will sound. In commercial versions of Cfengine (Nova), you can set up multiple Cfengine nodes to share their MD5 databases and monitor and cross-check each other.

You can run this check fairly often—every five minutes, if you like and if your hardware will sustain it. (Computing lots of MD5 sums can be expensive on CPU and disk I/O.) Is the added security worth it to you?


Aleksey Tsalolikhin has been a UNIX/Linux system administrator for 14 years.