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.
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.
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:
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.