Homelab: Defining the personal journey. From baseline design to datacenter practices. Part 7.

Photo by Masq31 under CC BY-ND.

Wazuh SIEM Log Management & Configuration.

Welcome back to part 7 of the Homelab Blog series, folks. Apologies for the break once again as I’ve been away at conferences the past week. Nevertheless we’re back to cover some homelab essentials. This time we’re diving into the logs. We’ll go over SIEM tools and how to keep all your logs into one central space.

Honestly from my last job I’ve not been given a lot of the hands-on audit or log systems. Logs are some of the most important parts of a network. They’re about as important as a network inventory. They are the vital signs of health and currency on network management and operations. They also tell you when your network is sick with malware or is doing well. Logs are like the Central Nervous System to your body’s Immune System. Signals, like logs, tell you where the pain is so your body can deploy defenses where it needs them. It happens behind the scenes for the most part. So going from zero log visibility in a network to tracking all activity between services and packages can present a challenge.

Chapter guide:

1. Planning Hardware, Location & HVAC.

2. Server Migration & Scaling Considerations.

3. Exclusive Migration Tools for Homelab Users.

4. ESXi Vendor Integrations, DPU & GPU with Nvidia DOCA.

5. AI & LLM’s to Aid in Homelab: Knowledge base & troubleshooting.

6. Managed Routing & Switching Software/Vendor Integration.

7. Wazuh SIEM Log Management & Configuration.

8. FreePBX VoIP configuration.

9. Mikrotik IoT, Wireless configuration.

10. Where to next? (Failover planning, Dial-up VLAN separation, cloud integration, etc.)

===SPONSOR The process of writing a blog has shown me that I really need to hone in on log audit skills. These are skills that can translate into real world job skills at a Security Operations Center (SOC). That’s where TryHackMe comes in.

TryHackMe is a learning platform for brushing up on cybersecurity skills. As a graduate of their Pentest+ platform I can’t recommend them enough to new or returning cybersecurity practitioners. I’m currently walking through their SOC level 1 platform in preparation for my CySA+ certification, and I would recommend them if that path makes sense for your own homelab journey too.

Check out their new Cybersecurity 101 program at the link. ===END SPONSOR

Digging through the Logs.

Information contained in logs can be varying in severity. Let’s take a look at an example firewall log:

2025–12–31 21:01:47.880055+00:00 snort 72721 [120:3:2] (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE [Classification: Unknown Traffic] [Priority: 3] {TCP} 192.168.3.22:1533 -> X.X.X.X:443

There are a number of parts to this. Let’s take a closer look at each one:

• The first part is the time and date. We have a date of December 31st, 2025 here and a time of 21:01:47 at Eastern Standard time which is +5 UTC.
• This is a timestamp which is determined by the Network Time Protocol (NTP) server designated on the logging system. Do note that the NTP server isn’t always used by onboard software packages. They may need to point it at the server multiple times for every single system you use. This is similar to certificate management, and in fact certificate management also requires accurate timekeeping in web development, otherwise errors may ensue. It can be automated on a network through tooling like Endpoint Management and Active Directory. The most important thing is that the time is accurate.
• Next is the service name. We have a log which originated from “snort”. This can be changed or edited in packages and logging tools as well. It’s important to have naming consistency here as to not list every log originating from “localhost”. These can get cluttered on your network and lead to massive disorganization.
• Now we have a Process ID (PID) of “72721”. This is the unique Id on the unix system of the snort process itself. This is something you may want to keep track of to avoid process spoofing. Tools like Elastic and Wazuh, which we’ll talk about later, contain mitigation tools for PID spoofing[].
• The “[120:3:2]” component is a list bracket of Group ID, Signature ID and Revision which are specific to Snort itself. This is a field specific to snort itself. The 120 corresponds to the next item means “(http_inspect)”. It’s important to be aware of all of these elements, but we’ll pass on this one for now.
• Here we have an interesting “NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE”. This is the log message itself. This tells us what the error is.
• The “[Classification: Unknown Traffic]” is the rule in snort which was triggered.
• “[Priority: 3]” is the snort priority classification. This is what snort metrics say the priority, or sometimes called severity or urgency, is. Every product from every vendor is going to be different in classifying priority in a different way.
• “{TCP}” Is the protocol. “192.168.X.X:1533 -> X.X.X.X:443” is the source -> destination pair. In this case we have the 1st router’s default gateway. The destination is the interesting part. This can tell you where the traffic’s next hop is.

This is just one log format among hundreds. Every tool creates event and application logs differently. So how do we wade through and parse this log? Well one way to do that is with Regex. Building a regex to detect areas specific syntax is important to ensure parity in your system designed to catch and sift through logs. Creating a regex can be a time intensive process, but luckily regex frameworks and tools like Splunk and Wazuh exist to integrate these in a user-friendly way.

How do logs traverse from each endpoint on the network all the way back to a centralized location? This is a technique called log aggregation or log forwarding. Log aggregation specifies a server fit for handling logs and pushes them through. This is often done on a high power, high bandwidth system as it needs to handle IO from numerous sources. This is known as Events Per Second (EPS) per Microsoft documentation on connecting to one of their products.

Logs can stay on a system until they need to be moved to analysis tools and groups. Security and network operation centers are staffed with people that parse through and analyze logs, typically 24/7, 365. This is because without logging, the network is basically invisible to an enterprise or a small business. Many compliance frameworks have guidelines for uptime and availability, as well as service level agreements to meet obligations to say a network was running at a specific time. Having a papertail here is essential to ongoing operations as well as security. There are numerous reasons to always be logging, and so it’s always happening.

The products which parse these numerous logs take and encompass dozens of features into a software tool. Log analysis can take place in a Security Incident Event Management (SIEM) tool. Microsoft’s professional offering in this place is known as Azure Sentinel . A popular FOSS alternative SIEM I’ve found to be homelab-friendly is Wazuh. I’ve been using Wazuh for about 6 months now to varying levels of effectiveness. We’ll now take a look at how Wazuh works.

Wazuh is Wazzup!

The ecosystem which Wazuh exists in is one similar to RedHat and Fedora. The enterprise offering for Log analysis tools comes from the company Elasticsearch. Their Enterprise products are under the Elastic engine. Elastic can branch out from SIEM to a number of log proposed tools as stated on their website and docs. The GUI at first glance is nearly identical between Elastic and Wazuh. What’s more, the features surrounding Elastic brings together a cohesive way to do things like its own operating system. For the sake of sanity I’m going to simplify these things to what I had to work on to configure my own Wazuh environment and ensure stability and ability to follow along and upgrade firmware.

Here are some of the more interesting things to know about setting up Wazuh in your homelab environment. Wazuh has guides available for setting up basic configuration rules for everything from Cisco appliances to ESXi hypervisors. These can also be custom edited and parsed with regex rule readers and put into the config file. If you make a resource for parsing logs from an open source tool, that file is a shareable resource. You may want to contribute it to the Wazuh github as a merge request. Plenty of opportunity to write your own rules for your homelab tools.

Alerts in Wazuh are the first thing you’ll see on the dashboard. As mentioned from our log overview, severity depends on the vendor. Before going over Wazuh’s take, we’ll cover RFC 5424 for log severity metrics. These are levels 1–7 from EMERGENCY for all critical logs down to DEBUG which is typically for program development purposes. The logic is similar to firewall rule categories, in that the high severity logs can be accepted while the lower level ones ignored. Wazuh severity is a measured scale from 0 to 15 plus. Low severity is 0–6, medium is 7–11, high is 12–15 and critical is 15 and any metric above. You can set or review any logs on your network to pinpoint areas to prioritize incident troubleshooting.

Wazuh is offered in a number of different OS flavors and formats. You could even install it on a Solaris system if you so choose to do so. Wazuh also offers a quickstart VM. While the VM is kept more up to date than the Trex package mentioned in the previous blog. I would still recommend against using the prepackaged VM. It can be good to gauge if the software will run in your environment when quickly hooked up. However, for prolonged use in production it’s best to match the configuration desired by you and your organization. Networking with any VM may not be plug-and-play without external configuration changes for your homelab environment. The Wazuh VM is built upon an Amazon Linux system. Netplan is not configurable out of the box for Vmware or ESXi. You’ll have to have knowledge of systemd-networkd and that syntax in order to make changes.Amazon Linux is rarely parallel to Netplan, but making changes without knowing the system you’re working on can compromise the security of your log tracking tool.

To install Wazuh you’re given system requirements. The docs provide step by step setup for Wazuh. I would recommend a 4 core 8 gb with at least 200 GB of hard drive space for a test platform. Logs can take up a massive amount of space. As of the time of reporting my own Wazuh instance has about 12,000 logs over the course of a week from my configured endpoints. With a greater number of endpoints this could in theory climb into the millions or more. It’s best to keep track of your network by ensuring log parity with your SIEM.

Note that if you ever need to restart Wazuh, you can restart the program within the tool itself, but this is only 1 of 3 components. Wazuh virtual machines use a monitor, a manager and an agent for all of the services provided. Many technical problems can be solved by simply restarting all three of these components, or rebooting the system.

Once installed using the website provided script you’ll be able to access a number of features. The first thing you’ll need to do is configure the ossec file within the GUI. Editing this is essential to get the system to talk to your SIEM. If you have a syslog-ng server aggregating all log sources, you can specify that in the following format:

<remote>

<connection>syslog</connection>

<port>514</port>

<protocol>udp</protocol>

<allowed-ips>192.168.X.X</allowed-ips> #this is the log sending device IP

<local_ip>192.168.X.X</local_ip> #this is the Wazuh IP

</remote>

</ossec_config>

If you don’t use a central logging server, you can still manually connect each device to the log source. I have my homelab currently set up for that due to some technical difficulties with syslog-ng on pfsense. This leaves us with Rsyslog (Unix log standard) and BSD log (BSD standard). These are two log formats we’re ingesting into our SIEM. The syntax for Rsyslog scripting is out of the scope of this blog, but is worth mentioning. The initial config files appear as if they were Netplan, but are in fact written like bash scripting much like Powershell or cronjob tasks. Modifying logs at this level is possible but I wouldn’t encourage it for the typical sysadmin duties.

There’s a guide to enable the log archives as a source for Wazuh. The archives log is every log received and seen by Wazuh. This is pitched as a temporary solution as you need to tag incoming network logs. I’ve currently not found a way to work around preparing logfines in a more coherent manner. If any readers have follow up I’m open to feedback in the comments section.

Elastic and Wazuh’s shared engine is known as Filebeat [https://www.elastic.co/docs/reference/beats/filebeat]. Filebeat takes logs coming into the Linux system Wazuh is installed on and feeds them to the dashboard for reporting. Enabling JSON format and log archiving in the dashboard requires a config change to Filebeat fileand the ossec config file. Making this change and restarting the Wazuh manager client gives us access to these logfiles. This is what got me up and running for the first month with Wazuh. As always, YMMV.

Troubleshooting for best results.

Now say you notice that there are some issues viewing sources and destinations of logs. Oftentimes SIEM system admins find that connected systems aren’t sending logfiles at all. For this you’ll be able to use the ‘tail’ unix command to parse through the incoming logfiles from network sources. As a more extreme measure, running a packet tracer over SSH can also be a viable option to ensure syslog messages are being forwarded. Do note this does require installing openssh on the Wazuh which is another attack surface point. After doing so, running Wireshark can give you a more digestible way to see what logs are getting to your endpoint.

Once you know logging works, we can take a look at the agent section. The Wazuh agent is a downloadable client for windows, mac and linux systems. You need this client for Wazuh to track and forward information accordingly. Some of the features of agents include deeper insight to security and compliance of devices themselves. These are found under the Endpoint Security section Flyout. For instance, the device I have assigned to Wazuh is my laptop. This device is often tied to setting and registry changes. The Wazuh client alerts me whenever there’s a change to the system registry. It also tells me when the device is online or offline much like a typical MDM toolset. Devices can be unassigned at any time with the help of the CLI terminal tool.

In running my Wazuh server I’ve had the experience of backing up and updating the system one time thus far. This process is well documented on the Wazuh website. I recommend following every step exactly to avoid configuration errors.

During the research we found an interesting log for our example. ESXi recorded a disk error with the partition GPT. Digging in here we got the details of a raw disk assigned. Trading this back to the physical hardware, we found that two raw disks and 1 storage disks were found. The last disk reporting this issue was simply unformatted, which makes sense. This is a good example of how knowing your inventory can save you time.

Revisiting Pfsense for a moment, we had followed through with some guides on configuring syslog-ng. Syslog-ng simplified the log format and provides a better parsed format for sending logs to Wazuh for processing against its regex matching rules. However I strongly recommend against running this tool on a firewall or other appliance. A log aggregator can be the Wazuh system itself, but I encountered major errors sending packets as a loopback and then back to Wazuh. This includes breaking at random times, resulting in blackouts on log visibility and system configuration issues. This is why I use the tools provided with Rsyslog as a workaround.

Log or Log not — There is no Try > Catch.

I honestly don’t have much more to say about Wazuh. The setup of this system is relatively simple aside from the need to go over my inventory and hook everything up one by one. After that, you’re ready to go. Wazuh is a great tool for keeping all your systems informed with your security and compliance postures. It feels rewarding to track down logs and find out trouble spots on your network. You’ll go back and forth from tweaking rules to making adjustments. It’s another great tool to have under the belt.

And with that, we’re onto part 8 next week. This will be covering some of the intricacies of setting up a FreePBX phone system on your network. I was surprised at how entertaining working with Astricks, ATA’s and Dial up modems could be. You won’t want to miss the next part.

Thanks for reading, and as always,

Stay Safe.