Security Monitoring and Enforcement with Cfengine 3

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.

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 unit_change_detect.cf into detect_changes_in_etc.cf (Listing 1).

# GNU GPL 3

###################################################
#
# Change detect
#
###################################################

body common control

{
bundlesequence  => { "detect_changes_in_etc"  };
}

###################################################

bundle agent detect_changes_in_etc

{
files:

  "/etc"

   changes      => detect_all_change,
   depth_search => recurse("inf");
}

###################################################

body changes detect_all_change

{
report_changes => "all";
update_hashes  => "true";
}

###################################################

body depth_search recurse(d)

{
depth        => "$(d)";
}

Run this with:

cf-agent -KIf detect_changes_in_etc.cf

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:

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 detect_changes_in_etc.cf
  !! File /etc/hosts.allow was not in MD5
     database - new file found 
  I: Made in version 'not specified' of
     'detect_changes_in_etc.cf' 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):

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 detect_changes_in_etc.cf
# 

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

# cf-agent -KIf detect_changes_in_etc.cf
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ALERT: Hash (MD5) for /etc/hosts.allow changed!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 -> Updating hash for /etc/hosts.allow to
MD5=2637c1edeb55081b330a1829b4b98c45
I: Made in version 'not specified' of
'./detect_changes_in_etc.cf' 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:

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

 -> Updating hash for /etc/hosts.allow to
MD5=2637c1edeb55081b330a1829b4b98c45

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?