This is full-frontal nerdery, so if you’re normally here for pictures, links to interesting things, and my never-ending bitching about astroturfed “grass-roots political movements”, this post will probably not be relevant to your interests.
One of the things I’m interested in is log management and intrusion detection, and there are a lot of fascinating options for this sort of thing ranging in cost from hella expensive to free. Any grizzly neckbeard with a three button mouse and a copy of the sed and awk book has probably used logsurfer, tripwire, or any number of other options for keeping an eye on system logs, but I find OSSEC‘s feature set to be far more suitable and flexible and require much less effort and patience.
OSSEC is a really interesting piece of software that manages to do an excellent job at monitoring logs and also acting as a HIDS1. So it is excellent at monitoring system logs, but it also detects changes to system utilities and binaries, and uses some logic that you can interact with to detect anomalous behavior. There are a lot of health monitoring suites that offer to alert system admins based on error messages or changed files, but OSSEC also offers central agent and policy management, active response capabilities, and it works across a variety of network topologies2.
Further information on OSSEC is out of scope so from here on I’ll be assuming you know what it is and that you want to install the agent or the server on a Mac OS X 10.9 Mavericks system and that you’re familiar with homebrew and comfortable with the CLI.
Gotcha 1: llvm — y u no inline asm?
The first gotcha you’ll likely encounter with OSSEC’s install.sh method of building and installing the agent and/or server, is that Apple’s compiler doesn’t like inline assembly language. Oops. You’re going to need to install a new bundle for gcc to proceed, so install one via homebrew.
Ensure sure you have Xcode and the Command Line Tools installed, and then install a version of gcc you’re comfortable with
and you’d think you’re going to all square from here on out, but you’d be wrong. Prepare to do battle with what I can only assume is a broken configure script because no matter how I tried to insist on wanting to use gcc/g++ out of homebrew, it refused. Some tutorials will have you putting on a pair of Bad Idea Jeans and replacing Apple’s binaries in
— and I wave my hands at them disdainfully.
Instead, this will get you going without doing anything too stupid. There is a directory inside your extracted OSSEC tarball called
and a file in there called
. Edit the
file and adjust accordingly. Mine merely declares my favored compilers living in
So now we’ll prefer the stuff we just installed with homebrew over Apple’s tools. You can get fancier with it, but generally I prefer using Apple’s compiler and use vanilla
only when required. You could alternatively set aside Apple’s binaries (as root)
and assume that updates to the Xcode CLI package or OS X can and will stomp these with complete disregard for your feelings.
You may now resume your use of
to configure and build your server, agent, hybrid, or local instance as expected. While you’re installing agent keys and/or provisioning your Mavericks system for monitoring, you should know that it probably won’t start automatically when you reboot. Weaksauce.
Gotcha 2: StartupItems? What?
OS X doesn’t want to use
anymore so we’re not going to try to make it happen. The OSSEC installer shoves some stuff in there and leaves a file in
that isn’t needed, so you can safely remove the OSSEC startup script from
because we’re sophisticated users that aren’t running Mac OS X 10.4 or something equally antiquated. Instead we’ll make a
Now I need to load that job and start it, and confirm it started the processes correctly. This won’t work very well if you haven’t actually provisioned the agent for non-server installs, but you can probably find your own way from here.
Easy as pie, piece of cake, something something cupcake. We now have a Mavericks system that compiled and installed OSSEC, and it will start the services upon reboot.
For more information on OSSEC, please go to the OSSEC website, and if you’re curious about the project and the developer, Daniel Cid, he’s been featured on The Setup a couple of years ago. It’s a pretty good post for The Setup, especially considering it was somewhat unusual seeing a researcher in my field listed there. If you subscribe to the OSSEC mailing lists or read the archives you’ll discover quickly that Daniel and I have many personality traits in common. Guess what they are!
host intrusion detection system, as opposed to network intrusion detection systems like snort ↩
case in point — I’m using the hybrid server mode at home to correlate local event streams and then escalate interesting things to a remote server for further analysis and handling the alerting ↩