Building and Using OSSEC on OS X Mavericks

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

brew install gcc-4.8

after tapping

" rel="footnote">3. Once you’re building you can go for a walk around the prison yard being mindful of inmates with shivs and grudges, and come back to a built and installed


  along with the rest of your homebrew favorites.4

So now you’ve probably got


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 then symlink




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

job, like a boss.

launchd Like a Boss

I created a file named

on a system that is acting as an agent that needs to phone in to an OSSEC server, and made it read like so:


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.


and confirm it’s running the processes you’d expect:


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.

Yes, it's just that simple.
Yes, it’s just that simple.

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!

  1. host intrusion detection system, as opposed to network intrusion detection systems like snort 

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

  3. i.e.


    after tapping



  4. What are my favorites? That’s easy: mac-vim, mutt, nmap, dcraw, exiftool, yasm, tmux, sshfs/fuse, gpg, fasd, offlineimap, markdown, mmd, unrar, par2, links, and a few other odds and ends.