Wazuh implementation idea

[Marco S]

Hello,

We’re trying to plan and renew to the latest Wazuh version our current SIEM infrastructure that is based on an older version of Wazuh and was created and managed by externals.

Our idea currently includes a hot-warm-cold indexing architecture made of the following:

• 2 “logstash” nodes (of which 1 is master-eligible, they’ll also run a few ingest pipelines)
• 3 “hot” nodes (of which 1 is master-eligible)
• 3 “warm” nodes (of which 1 is master-eligible)
• 3 “cold” nodes

All the shards managed will have exactly a replica.

• 1 Wazuh Dashboard
• 1 Wazuh Server (in local, not in cloud like the previous nodes), will manage Sysmon logs for 3000 clients.
• 1 Already working Wazuh Server from the old setup that is managing network logs (firewall, DNS, authentication system, …). This is already local as Firewall logs are 100+ GB and we can’t afford storage expenses on cloud for these ones. This will just work as a “thick agent”, as it retrieves network logs locally via Syslog, normalizes them and sends them to indexing nodes.

We estimate that Sysmon logs will be around 15GB/day but we can’t tell for sure as we haven’t deployed it on a wide set of clients so it might be more or less and we want to keep alerts.json and backups on local machines.

We chose a hot-warm-cold architecture to extend retention time still optimizing costs with the following retention times:

• Hot: 0 to 7 days
• Warm: 7 to 14 days
• Cold: 14 to 60 days

Now, after this long introduction (sorry for that), my questions:

• Is the whole idea sound? Do you have suggestions or notice any pitfall?
• Can roles for wazuh-indexer nodes be managed just changing the configuration in opensearch.yml? Any suggestion for that?
• Any idea on how to guesstimate the sizing and requirements for our nodes?
  
  

Thank you all!

Best regards,

Marco

[Andres Micalizzi]

Hello Marco,

Thanks for using Wazuh!

This can be a good idea. Regarding your questions:

• Is the whole idea sound? Do you have suggestions or notice any pitfalls?
  A couple of possible pitfalls might be the Dashboard and the servers. Being a single node and handling such a big amount of clients, they could cause bottlenecks and in case any one of those goes down, for whatever reason, it could block the full implementation. If the server goes down, not only processes will not be received but will not be sent to the indexer and the dashboard will not work since it can't communicate with the API. I would recommend having more servers on each of the roles you have defined.
  
• Can roles for wazuh-indexer nodes be managed just by changing the configuration in opensearch.yml? Any suggestion for that?
  The roles are managed from the roles.yml (opensearch.yml contains the indexer's configuration). I would advise you used the Dashboard to set up the roles and their mappings. More Info, here.
  

• Any idea on how to guesstimate the sizing and requirements for our nodes?
  

• You can check the documentation for each part of the architecture to check your possible requirements:
  • Indexer: You should need to check the number of alerts per second you are getting to determine how many GBs will be used per server.
  • Server: Same as above, but space requirements are relatively lower (without taking into account the logs that you are already sending to your current server).
  • Dashboard: 8gb ram and 4 Cores would be recommended.

I hope this clears your question. In case of further doubt do not hesitate to ask.

[Marco S]

Hello Andres,

 

thank you for your quick answer!

About the first answer, yeah, I thought about this too. I guess that two further nodes (so that we could have two workers and a master) and maybe a way to load balance the communication from agents to the Wazuh cluster would be better?

About the second one, sorry, I explained myself poorly. By “wazuh-indexer nodes roles” I meant the roles these indexers will have (e.g. logstash to receive logs and apply ingest pipelines before indexing or hot/warm/cold nodes on the right hardware). In case of hot/warm/cold nodes as far as I know you should specify an attribute to be used in the index policy (e.g. node.attr.temp: “hot” on hot nodes). Do you need to specify anything else to differentiate how the indexers will work?

About the third one, we’d like to backup alerts on a different shared disk so I guess that the server should have enough space only for the daily alerts.json, correct?

Thank you again!

 

Best regards,

Marco

[Marco S]

Hello,

just asking for an update on this, if possible. Thank you!

Best regards,

Marco