What about those times where someone plugs in a thumb drive and copies a malicious file to your client? What happens when a trusted partner is compromised and a piece of malicious code is uploaded to your web server from the compromised host at that trusted partner? Clearly we need some type of file integrity solution. My servers primarily run FreeBSD, RHEL and Ubuntu, but I use a Mac and run Windows 7 at home, so where is the sweet spot for cross-platform monitoring?
OSSEC to the rescue.
OSSEC, or Open Source SECurity, has been around for a while - I have been a happy user since about 2007. It provides File Integrity Monitoring (FIM), registry monitoring on Windows, rootkit detection, log anomaly detection and more, meaning you can use it to satisfy monitoring requirements for PCI and various other regulated environments.
The VM Prep - Clone and System Update
The bulk of my servers run FreeBSD. Since I already have a FreeBSD template available (FBSD_8_3_i386_101, if you're following from the beginning of my posts), I'll clone it out as FBSD_105_ossec_server. As with the others this is a Full clone, with interfaces in the "psql_test" and NAT networks
Because of how the interfaces are presented to FreeBSD, "Adapter 1" (the psql_test network) appears as em1 and "Adapter 2" (the NAT network) appears as em0. So networking works in my VM, I edited /etc/rc.conf to reflect the proper network setup and rebooted:
It has been several months since I created that FreeBSD template so the operating system, the ports tree and anything installed from the ports tree are probably out of date and I want to make sure my VM is up-to-date when I build and install OSSEC, so I've used the freebsd-update utility to update the operating system to the latest patch level and rebooted:
sudo freebsd-update fetch
sudo freebsd-update install
sudo shutdown -r now
To update the ports tree, and any installed ports, I've used portsnap and portmaster. The options I've passed to portmaster tell it to recurse dependencies, create a package for the newly updated port, remove the downloaded distfiles for each port and update all out-of-date ports. The FreeBSD project has incredible documentation, much better than I was used to in the Linux world, and the man page for portmaster is very informative:
sudo portsnap fetch update
sudo portmaster -t -g -d -a
OSSEC Server - The Installation
I know already that the port for the OSSEC server is security/ossec-hids-server, but if you want to find a particular port, you can change directory to /usr/ports and do a search by name. For example, to find any port with "ossec" in the name, you could do:
cd /usr/ports
make search name=ossec
Since I know the name is ossec-hids-server, this makes a very clean example. Doing a search for that yields:
To install the OSSEC server, I'll use portmaster:
sudo portmaster -g -d security/ossec-hids-server
The default options for the port are fine for my example but if you want to push your OSSEC output to a database, be sure to add support for the one you want to use.
OSSEC Server - Minimal Tweaks for New Installation
There are some nice things enabled by OSSEC "out-of-the-box", and the generic configuration is a pretty good place to start getting your feet wet. That said, there are a few necessary edits to start getting data from OSSEC.
OSSEC has its configuration at /usr/local/ossec-hids/etc/ossec.conf. I'm a vi/vim person so I edited it with:
sudo vi /usr/local/ossec-hids/etc/ossec.conf
If you're really a glutton for punishment, and want to see how it alerts "out-of-the-box", you only need to make one change under the "global" section, where email gets handled. I'll leave email notification on but I'll have it sent to localhost. In a production environment I'd use my organisation email address and SMTP servers but in this case I'll keep it local and use the following:
<global>
<email_notification>yes</email_notification>
<email_to>demo@localhost</email_to>
<email_from>ossecm@localhost</email_from>
<smtp_server>127.0.0.1</smtp_server>
</global>
To tell FreeBSD to start OSSEC on boot, add the following line to /etc/rc.conf:
ossechids_enable="YES"
Then you can start OSSEC with:
sudo /usr/local/etc/rc.d/ossec-hids start
To get a VERY quick sample of an alert, use sudo to edit something. To double-check something for this post, I edited the ossec.conf file after starting OSSEC - since it was the first time I had used sudo since OSSEC had started watching my logs, it should have alerted me. Most flavours of Unix and some Linux distributions include the "mail" utility by default so I'll use it to check email on the local VM. I would highly recommend you read the mail man page ("man mail"), particularly the section on reading mail.
Keep in mind this is a VERY vanilla installation. There are a TON of rules that get loaded by default and a lot are going to be extraneous for simple environments, so it's important to go through and comment out or remove the items you don't want to load.
OSSEC Server - Some More Options
Even more important than removing what you do NOT want is adding what you DO want. For example, if you look in the ossec.conf file, under the section for "syscheck", you'll find that the default FreeBSD OSSEC installation monitors for changes in the following directories:
/etc
/bin
/sbin
/usr/bin
/usr/sbin
But I like to add the other common directories for configuration files and binaries on a FreeBSD system - /usr/local/etc, /usr/local/bin and /usr/local/sbin, so I add a line that looks like:
<directories check_all="yes">/usr/local/etc,/usr/local/bin,/usr/local/sbin</directories>
If you are hosting web content then you can use OSSEC to audit the stored files under, e.g., /usr/local/www, by adding that as a directory to watch.
If you want to monitor a specific file for changes, you can use the <localfile> option. This is how I specify locations/log files on different systems. For example, a lot of Unix systems use /var/log/messages, because that is a common syslog log file for the system, but some Linux distributions use /var/log/syslog.
If there are files you know will change often, like an application log, you can ignore that file with <ignore>. There are several examples of monitoring directories and files, excluding files and OSSEC's "active response" in ossec.conf.
It's possible to run each system as a stand-alone entity but in a larger environment I much prefer the simplification of centralised management and a shared configuration file, so in part two I'll dive into adding agents and shared configurations.
