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.


On Wednesday, March 8, 2017 at 9:03:34 AM UTC-8, Sushan Ghimire wrote:
>
> 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. 
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to