Ossec – Architecture and Implementation – Best practices ?

This is the last update of an one year old post.

Now, with multiple months of tests and practices I can bring a better response to myself (and share it).

After multiple tests with Ossec agents (Windows, Unix, Linux), Ossec server, and syslog , I’d like to go farther and start for a deployment in ‘production’ on some sensitive machine.

My question is more related on the architecture to implement. I’m focusing more one the logs/events aspect .


Here is my current Ossec implementation. It is not perfect, but deals with some issue (cost) for the moment.

Ossec Architecture
Ossec Architecture for small organization

Current capacity : between 5 to 8 million events a day.

I’ve think I had 2 different scenarios (I put some Pro and Con) :

1. 1. Install/configure Syslog on the Hosts servers and forward the events to the central syslog and then analyse it with Ossec.

My current integration.

[Host + Syslog Agent] --> [Syslog Server] -- > [Ossec]

  • + No more config on Hosts (No agent to update – Set and forget)
  • + All logs are stored centrally then analyzed
  • + If Ossec server fails … the logs continues to feed.
  • + Bottleneck is the Syslog Server, but it’s a robust technology,  especially with rsyslog.
  • – Lose the benefit of encrypted and authenticated transport.
  • – No Integrity Check
  • – No RookitCheck
  • – No FileCheck
  • – In case of network cut no events are forwarded
  • – In case of syslog agent stop (wanted or not) no events are forwarded
  • – Works only if Syslog server is not an Appliance – like (HP) ArcSight – and the events are not stored into a database. (Ossec has to see the events and has to be installed on the syslog server).

2. 2. Install Ossec agent on the Hosts servers, forward the events to Ossec Servers then to Syslog.

[Host + Ossec Agent] --> [Ossec] --> [Syslog Server]

  • + Encrypted and authenticated transport.
  • + Integrity Check
  • + RookitCheck
  • + FileCheck
  • + In case of network cut , agent do retention and forward when ok.
  • + In case of agent stop (wanted or not), a Server side alert is displayed
  • + Ossec can be a separated and dedicated server , the logger can be an appliance (Splunk, ArcSight, …).
  • + Bottleneck is the OSSEC Server, but it also has fail-over capability, so you can have two or more managers in case one goes down.
  • – ONLY Ossec agent events are send to the Ossec
  • – With the syslog output, only the alerts are sent to the syslog server. You can get around this by reading the queue directly.
  • – Ossec agent has to be maintained on the Hosts, and sometime upgraded.

More info:

Be the first to comment

Leave a Reply

Your email address will not be published.


*


*