Wazuh hardware recommendations and best practices

[Nirav Radia]

Hi,

I have to monitor some 35-50 servers through Wazuh (both linux and Windows). I can't find any specific docs regarding what should be the ideal size of the AWS instance to use for installing Wazuh server and Elasticsearch server. (RAM, Disk size, CPU cores?)

Also, for now as I read, single-host architecture should be enough for my requirement. But what in case more clients are needed to be monitored in future? (like adding 30-40 more clients) What scaling policy should I follow for this or I should use distributed architecture from now itself and just scale-up ELK cluster in future when needed? 

Any help will be appreciated.

[David Drake]

For on premise hardware, I have 8GB RAM and 4vCPU (overkill) that serves ~1500 Linux servers.  I don't have ELK on that instance but from an OSSEC perspective - a single host would be more than enough for that small amount of servers.  From what I've seen, the more file integrity checks / events per second is what depends on the instance size.  

Also, since you are in AWS - you should be able to scale the instance type easily.  

[Nirav Radia]

Thanks David for your reply. My main concern is since I am just setting up things from scratch, should I keep OSSEC and ELK different since beginning so that when my wazuh clients increase in future ( it probably would never increase more than 100), I do not have to do anything special.

Any help would be appreciated.

[David Drake]

I just saw your reply.  It honestly depends on how you want to architect your environment.  There is no dependency requiring Wazuh and ELK to be on the same server.  It really just depends on your particular environment and the amount of servers you have access to / budget.  Everything in a single server technically makes it easier to troubleshoot where problems could be. 

[InfoSec]

The rule of thumb is to keep Wazuh server close to the infrastructure it monitors (on the same segments), regardless of where that is (cloud or or on premise).

OSSEC uses udp for communications between agents and servers, and the connection is always initiated from agent to server, after which the server reaches back to the agent. Usually UDP communications are one way, with no guaranteed delivery. So any intervening routing/firewalls may wreak havoc with communications between agent and server. Even though OSSEC communicates over UDP, at the application layer the agent and server 'synchronize'. After an interruption in agent-to-server communications, upon resumption the agent should pick up from where it left off. It however does not queue.

Best practice is to deploy as many Wazuh servers as you have locations to monitor, and use FileBeat to ship Wazuh logs to a central ELK cluster.

Theoretically, such a such a distributed setup would elegantly scale from the smallest of deployments (all-in-one if you only have one location, though for production it is best practice to have a 2-node elasticsearch cluster) to the largest (mix of on-premise and cloud infrastructure with multiple geographic locations).

Few security information management solutions are as flexible or scale so elegantly.