Securing /etc/puppet on CentOS

I’ve recently delved in to the world of Puppet to manage some CentOS servers. In the process I noticed something. The /etc/puppet directory is owned by root:root but puppet runs as the user puppet. What does this mean? A couple of things:

  • To edit the manifests or modules I either have to be root or constantly be typing sudo (annoying).
  • For the puppetmaster process, which runs as puppet:puppet to access the files, the manifest and modules must be world readable.  This means a lot of information is visible to the world, encrypted or not.
  • I can’t use my favorite editor to edit files over ssh. (I know, a personal gripe, but valid in my books.)

So I’m trying an experiment that I hope will secure the data a bit more and make editing the files more hastle free.

  • Recursively changed the group of /etc/puppet to puppet.
  • Put myself in the puppet group.  I can now edit the files without being root.  (See newgrp(1).)
  • I’ll slowly begin to set the Other permission bits to 0, hiding the files and their contents from prying eyes.

 

 

 

FreeBSD Release End of Life Table

Buried on the FreeBSD Security Information page is a useful little table.  It shows the estimated end of life of the currently active FreeBSD releases.

Installing OSSEC

After reading and hearing about OSSEC I decided to give it a try.

The installation process is a simple untar, run install.sh process.   You are asked a couple of questions (enable yes/no, email address, etc) and that’s it.  This time around, I installed OSSEC 2.0 on an up to date CentOS 5.2 x86_64 installation.

One of the key questions is the type of installation you will be performing.   There are three types of installation:

  • Local
  • Server
  • Agent

This time around I was performing a local installation.  In brief,  local is what most home users will want to use.  For those who want to monitor more than one system, a server installation and multiple agent installations will be the way to go.  A document describing the types of installation available on the OSSEC site.

In my case it is a local install so the installer installs everything.

One think you will want to make sure of, is the from email address OSSEC uses.  In my case it was using ossecm@localdomain which my mail server was rejecting because the the source address was not a full domain name (somedomain.com).  You can see the email values your installation is using by looking at the /var/ossec/etc/ossec.conf file.  There may be a more “proper” way of correcting it, but I just went a head and edited the email  address in the ossec.conf file.