Implementing ossec-local at scale in Docker containers

[Sushan Ghimire]

I am struggling to find a good read on pros and cons of running OSSEC on Docker containers. 

I am looking to implement intrusion detection on underlying hosts and not on the containers. All applications run on containers but are orchestrated by a orchestrator, therefore threat level is considered low. 

Because the solution needs to be highly available, I think installing ossec-local is more appropriate to the use case. On the server/client model, it appears that agents need to be registered to server and server then does heavy lifting. I want to send logs from ossec-local to Splunk (or other monitoring/alerting tools).

And finally, I have been instructed to run OSSEC on Docker containers. The logic behind that is, everything runs on containers. In my head that is an anti-pattern - containers are for isolation, an isolated process should not be watching hosts. Or maybe it should? Depending on the rules to be implemented, it sounds like I would need to map multiple volumes. 

Does anyone have experience of similar use case? Any pointers/links and thoughts will be highly appreciated. 

When I am done, I will share my learnings in a blog. 

[John Gelnaw]

Running the ossec server in a docker container, makes sense, and I run the Wazuh fork of ossec in their provided container with logstash / kibana4.

Running ossec agent in a container makes no sense to me.

I would suggest instead that you use the docker logging driver to reroute stdout from your containers to syslog, and run ossec agent on your docker host, if you want to monitor your containers.

Regardless, running the agent within a container will make it highly problematic to monitor the underlying host.

[Victor Fernandez]

Hi Sushan,

I think that embedding a local OSSEC into every container is not the best approach, IMHO. In fact, the Docker's "best practices" guideline recommends to have one process per container, this could mean one service per container.

Since agents can auto-register via ossec-authd, you could run a single manager with Authd. Containers may include an agent that auto-registers and sends logs to that manager.

I did some experiments with a configuration like this:

- Container for pure manager (remoted + analysisd) and Filebeat.

- Container for Authd (auto registration), sharing folder /var/ossec/etc.

- Container for Elasticsearch.

- Container for Kibana.

You may choose between embed an agent into each container, or as John said, configure containers to write the stdout into the host's syslog and install a single local OSSEC on the host. On the other hand, this option would make hard to do file integrity monitoring.

Best regards.