After looking at various types of intrusion detection systems lately, I’ve started to use OSSEC, the open source, host-based intrusion detection system (HIDS), which I reviewed in a recent post.

To summarise, OSSEC uses various strategies to detect a breach of security or even give early warning of failed attempts using:

Rootkit detection – This uses a set of public signatures of known ‘rootkits’ (http://www.ossec.net/rootkits/) which it attempts to find on the host system.
Integrity checking – This approach checks for changes to important files such as binaries, libraries, and configuration files; upon installation, all of these files are scanned and a checksum created. If a subsequent scan detects that one of these files has been altered and no longer matches its checksum, then an alert is generated. Of course OSSEC must be installed on a system known to be clean for integrity checking to be of any use!
Log analysis – OSSEC uses rules to scrutinise logs looking for irregularities or signs of inappropriate activity.

After initially installing and testing OSSEC, I was impressed enough to look into deploying it on my network alongside Snort. I decided that it would be best to use the agent/server framework rather than running a local installation on each host. Using this approach means that I have one machine (I decided to opt for a virtual machine as the system resources it requires are quite modest) that receives events from the agents installed on my other systems. The server machine then correlates these events, generates alerts, and if necessary, prompts the agent to take defensive action.

Isn’t this like putting all of my eggs in one basket? Not really. I specifically chose to run my server on a dedicated internal machine rather than simply installing the server on one of the perimeter servers and having agents to report back to that. OSSEC should report (and hopefully block) any suspicious activities long before there is any chance of an internal machine being compromised. By running one central server I also get to keep the majority of rules and configuration files in one place. This greatly simplifies administration.

Installation was a breeze. For the server, it’s pretty much the same as the local installation I detailed in my previous blog, the only difference being that an additional option of listening for syslogs is given. I haven’t used this option yet but it may allow a whole host of devices such as routers, access points, and appliances to be monitored by OSSEC. Has anyone played with this yet?

The agent installation is very lightweight and couldn’t be more straightforward. I found a very good guide to agent/server installation over at techtarget.com, so I won’t go in to too much detail here. Agents connect to the server via UDP port 1514–communications are encrypted using a 192-bit Blowfish algorithm; a pre-shared key generated on the server whilst adding new clients is used to authenticate the two. In theory, agents could communicate with the server via a public Internet connection, but I still prefer to tunnel the connection and report back via a VPN tunnel. I know this ‘double encryption’ isn’t strictly necessary but it makes me feel safer!

I have successfully deployed the OSSEC agent on OpenBSD firewalls; unusually, this was very easy with no problems during installation. There were very few differences to Linux deployment, those being the way in which OSSEC is started on boot and the way that it blocks attackers after detection.

To start at boot time without any interaction, the following must be added to /etc/rc.local:

echo "Starting OSSEC HIDS"

/usr/share/ossec/bin/ossec-control start

In order to have the Packet Filter firewall block suspected attackers this needs to be added to pf.conf:

table <ossec_fwtable> persist #ossec_fwtable

block in quick from <ossec_fwtable> to any

block out quick from any to <ossec_fwtable>

I’m very happy with OSSEC and have found it very easy to deploy remotely across the enterprise. My only complaint is that the default rules and configuration tend to be a little too sensitive. My inbox has been bombarded with alerts of SSH brute force attacks. While it’s good to know these are taking place, it can get a little annoying. I haven’t had a chance to customise the rule set quite yet and would be really interested to hear about other people’s experiences with doing this. If you have been using OSSEC, please leave a comment and let me know how you’ve found the right balance between ignorant bliss and paranoia!