OSSEC

Looking for jobs on Elance and UpWork, I stumbled upon this proposal, quoting a blog post about hardening security on a small network, according to PCI standards.
Having already heard of Snort, Auditd, mod_security and Splunk, I was quite curious about OSSEC.

OSSEC purpose is to keep an eye on your systems integrity, and raise alerts upon suspicious changes.
Arguably, it could be compared to Filetraq, though it’s intelligent enough to qualify as an IDS.

Installation process is pretty straight-forward. The main difficulty is to properly create a certificate  for ossec-authd, the register all your nodes, and don’t forget to shut ossec-authd down, once you’re done deploying agents.
Using Wazuh packages (debian and ubuntu only), almost everything is pre-configured. They’re not perfect, if you happend to install both ossec-hids and ossec-hids-agent, a few files would be defined twice, upon installing the second packages the first one would be partially removed, you’ll lose files such as /etc/init.d/ossec, preventing the last package to install properly, … You’ll have to purge both packages, purge /var/ossec from your filesystem and reinstall either ossec-hids or ossec-hids-agent.

Setting it up on my kibana server, I ended up writing a module dealing with both agent and master server setup, as well as installing ossec-webui from github.
Note: the module does not deal with installing the initial key to your main ossec instance. As explained in the module README, you would need to install it on /var/ossec/etc prior to starting ossec service.
Passed that step, puppet would deal with everything else, including agent registration to your main instance.
Also note ossec-webui is not the only web frontend to OSSEC. There’s also Analogi I haven’t tried yet. Mainly because I don’t want to install yet another MySQL.

During my first tests, I noticed a small bug, cutting communications from an agent to its master.
More details about this over here. Checking /var/ossec/logs/ossec.log, you would find the ID corresponding to your faulty node. Stopping OSSEC, removing /var/ossec/queue/rids/$your_id and starting OSSEC back should be enough.

An other problem that could occur, is nodes showing up inactive on the web manager, while the agent seems properly running. Your manager logs would contain something like:

ossec-agentd(pid): ERROR: Duplicated counter for 'fqdn'.
ossec-agentd(pid): WARN: Problem receiving message from 10.42.X.X

When you would have identified something like this, you may then run /var/ossec/bin/manage_agents on your manager, and drop the existing key for incriminated agents. Then connect to your agents, drop /var/ossec/queues/rids/ content, stop ossec service, create a new key with /var/ossec/bin/agent-auth and restart ossec.

OSSEC Logs view

Stay tuned for my next commits, as I would be adding FreeBSD support, as soon as I would have build the corresponding package on my RPI.