Wazuh Proxmox virtualized

[JavierMMG]

Dear team,

I was reviewing publications about virtualized Wazuh infrastructure but I think that my problem is not mentioned in any of them. So, I'm using Proxmox software for virtualization. I have a lot of virtual machines working and I've found that when I've created a Wazuh infrastructure with one manager and one elastic all my network traffic has become very slow and my NAS server was impossible to see data inside (NFS communication).

After that, my question: did you work with Proxmox to virtualize Wazuh? do you know if the problem could be my NFS connection? are there requirements for virtual installation?

FYI: I've tested too to install a new NAS only for Wazuh infrastructure and it is with same problem.

I hope my problem is clear, if not tell me please.

Thanks a lot for your help!

[Manuel E. Gutiérrez]

Hello Javier,

Wazuh is made up of several processes which require a performant storage, keep in mind it's constantly receiving logs from all your agents, parsing them, triggering events and then forwarding data to Elasticsearch which due to its search/index capabilities is even more demanding. Your choice of NFS storage on Proxmox is not the fastest.

I've used Proxmox a lot in the past and my favorite approach was local storage with NFS for backups, this one time I used NFS in production but being honest it was an HP MSA storage with dedicated Gigabit switch for network traffic so things were smooth.

First thing you should do is benchmark you NFS performance and start from there https://www.slashroot.in/how-do-linux-nfs-performance-tuning-and-optimization.

If NFS tuning is not enough I'd say go with the next low hanging fruit, which is isolate your storage network, mixing production and network storage is a common error with Proxmox deployments but once you fix it performance will skyrocket once again. If this is not enough then I'd advise you to look at CephFS or GlusterFS but this would deprecate you current NAS server. Finally if nothing is good enough then just use local storage with a good backup policy, it's all about compromises in the end.

Hope I've shed some light on your issue.

Best.

Manuel

[Julio Cesar]

Hi Javier!

We use Wazuh and Proxmox here, and even with VM Storage and a gigabit network things can work, but with iSCSI for filesystems and NFS/CIFS only for backups.

If you are using some combination with ZFS and NFS we may need to do some tuning in both.

[Hai Yang]

Hi

In order to save the inventory changes for future forensics, we're interested in those data in the last few months.
Besides the syscollector data retrieved from wazuh db, any way to redirect the data to ES storage whenever it is processed by analysisd?

Regards
Hai

[Miguel Ruiz]

Hello Hai,

I'm sorry for the late response. I noticed that your question got somehow nested inside this other thread instead of as an independent thread.

I will gladly answer your question here, or you could create a new thread to discuss your topic.

Regarding your question, Wazuh does not have a built-in history of System Inventory changes, so performing Forensics of previous scans would not be possible without implementing some extra tool. But I could guide you through that.

You could implement a script that collected the syscollector information stored in the manager and indexed it into an Elasticsearch index, for example, wazuh-syscollector-*.

• Get all agents Id using Wazuh API call GET /agents (https://documentation.wazuh.com/3.11/user-manual/api/reference.html#get-all-agents).
• If you have more than 500 agents, you will need to use params 'limit' and 'offset' for paging.
• You can use 'select=id' to make your queries lighter.
• For every agent id, collect its syscollector information using GET /syscollector/:agent_id/:syscollector_module (https://documentation.wazuh.com/3.11/user-manual/api/reference.html#syscollector)
  
• Then process the information collected and index them into Elasticsearch. Note: To index documents into a new Elasticsearch index, you will need to create a new Elasticsearch template: https://www.elastic.co/guide/en/elasticsearch/reference/7.6/indices-templates.html

In case you don't need a full snapshot of the servers Inventory over time,  another option would be to store the results of syscollector API requests in your server and check diffs between executions. This way you could index only new inventory events, like software Installed/Removed/Updated.

Don't hesitate to let me know if you have any further questions.

Kind regards,

Miguel