Skip to main content

Wazuh SIEM Deployment: Getting Started and Base Deployment

 



Wazuh is a powerful free and open source SIEM Solution, it has a massive community backing and can collate and analyse logs, vulnerabilities and has the ability to create monitors on files, folders and even the registry. 

I havent seen much in the way of deployment online, so why not start now. This will be a multi-part series on the base deployment (all-in-one VM), monitoring windows and linux endpoints and host endpoints (ESXI). 

Lets Dive in! 

For this deployment, i will be deploying on my Synology NAS - this is because my NAS stays on 24/7 and doesn't consume anywhere near the amount of power that my lab hosts consume.

Begin by going to the  Wazuh VM Installation Page and download the OVA File. 

Once downloaded, We'll navigate to the Syno and bring up Virtual Machine Manager, Select VMs > Create > OVA > Next 

We'll then select Upload from PC, Find the OVA and select Next 



Select a storage volume for the VM, i'm lazy and have a single volume so that'll do 



Fill in whatever VM Details you like, The default is 4vCPU and 8GB of RAM with VMM, but depending on your usage, you may want to adjust these (see the Wazuh recommendations below) 



You can also keep the disk size default, according to my requirements, 50GB is plenty! 
Select your desired network, in this case, i'll keep it as the default which is the same as my management network! 
The remaining config items can be left default (unless you really feel like tinkering!) 




aaaaannnndd thats all folks, navigate to the web interface IP and you're done. See you in part 2, We'll run through setting up some agents and devices to be monitored 


Comments

Popular posts from this blog

Removing Multiple Datastores From Single ESXI Host Via PowerCLI

This post covers removing a multiple datastores from a single host at a time in vCenter with the use of PowerCLI. In the case where you have multiple hosts which have MANY MANY Datastores attached, its important to make sure you fully unmount and detach the DS from the host before removing storage connections.  Below is the code to make this happen $datastores = 'DS1','DS2'  $startTime = Get-Date $esxName = 'vmh.local' foreach($datastoreName in $datastores){ $datastoreName  $esx = Get-VMHost -Name $esxName $ds = Get-Datastore -Name $datastoreName $canonicalName = $ds.ExtensionData.Info.Vmfs.Extent[0].DiskName $storSys = Get-View $esx.Extensiondata.ConfigManager.StorageSystem $device = $storsys.StorageDeviceInfo.ScsiLun | where {$_.CanonicalName -eq $canonicalName} if($device.OperationalState[0] -eq 'ok'){     $StorSys.UnmountVmfsVolume($ds.ExtensionData.Info.Vmfs.Uuid) } $storSys.DetachScsiLun($device.Uuid) } $endTime = Get-Date $executionTime = $endTime...

HPE DL Series Host TPM Attestation Alarm Remediation

  Recently in my lab, i ran into an issue with the Host TPM Attestation Alarm being set. This was a little annoying that out of the box there are some configuration items that are not done by standard, and this guide will cover the specific BIOS / RBSU Configs that need to be made to clear this up.  First off, we need to boot into the BIOS / System Config / RBSU, so unfortunately you need to reboot your host - none of these changes can be made through the ILO "I reboot now - Good luck everybody else"  Next up, we need to navigate to Server Security and Secure Boot Settings  Next up, Select "Attempt Secure Boot" and accept the warning regarding the required reboot.  Navigate back to the main "Server Security" Menu and Select Trusted Platform Module Options  Ensure you have the below Config:  Current TPM Type: TPM 2.0  Current TPM 2.0 Active PCRs: SHA256 Only  TPM 2.0 Operation: No Action UNLESS your current TPM Type is not 2.0 - change to TPM ...

Deploying CEPH in the homelab

I recently rebuilt my Ceph lab to more closely mirror a real production deployment, rather than the usual - it works but don’t look too closely lab setups. The goals were simple but non-negotiable: 3 MONs (odd quorum) 2 MGRs (HA control plane) Host-level fault domain Replication size = 3 RGW (S3) only — no CephFS, no RBD Clean DNS (no /etc/hosts hacks) This post walks through the exact process I used to deploy a clean, repeatable Ceph RGW cluster using cephadm on Ubuntu, with explicit placement control and zero surprises. 🧠 Cluster Design – Nodes & IPs Monitor / Manager Nodes (Control Plane) ceph-mon01 — MON + MGR — 172.16.1.81 ceph-mon02 — MON + MGR — 172.16.1.82 ceph-mon03 — MON + MGR — 172.16.1.83 RGW (S3 Gateway) ceph-rgw01 — RGW Gateway — 172.16.1.86 OSD Storage Nodes ceph-osd01 — OSD Node (6 × 80 GB disks) — 172.16.1.91 ceph-osd02 — OSD Node (6 × 80 GB disks) — 172.16.1.92 ceph-osd03 — OSD Node (6 × 80 GB disks) — 172.16.1.93 📋 Cluster Requirements ...