Listen to this Post
Introduction:
Logs are the silent witnesses of every digital interaction, yet most security teams treat them as afterthoughts until an incident occurs. Effective detection starts with effective logging—without complete, high‑quality telemetry, even the most advanced SIEM becomes a guessing game. This article extracts technical guidance from Okan YILDIZ’s Wazuh integration document and translates it into actionable steps for hardening log collection across Linux, Windows, and network perimeters.
Learning Objectives:
– Configure and validate Wazuh agents to ingest critical Linux logs (auth, cron, boot, package, mail, web, firewall)
– Implement Windows Security Event monitoring via Event Viewer and Group Policy
– Build a step‑by‑step playbook for RDP surveillance, UFW firewall analysis, and SIEM correlation to eliminate blind spots
You Should Know:
1. Linux Log Analysis – The Seven Pillars of Visibility
Modern Linux environments generate logs that reveal everything from failed sudo attempts to cron‑based backdoors. The post highlights seven mandatory sources: authentication logs (`/var/log/auth.log` or `/var/log/secure`), cron activity (`/var/log/cron`), boot events (`/var/log/boot.log`), package management history (`/var/log/dpkg.log` or `/var/log/yum.log`), mail services (`/var/log/maillog`), web server logs (Apache/Nginx), and firewall events (`/var/log/ufw.log`).
Step‑by‑step guide to enable and verify Linux logs for Wazuh:
1. Check if logging is active – Most distributions log auth by default, but cron and boot may need rsyslog rules.
Verify rsyslog is running sudo systemctl status rsyslog Confirm auth log exists sudo ls -la /var/log/auth.log /var/log/secure 2>/dev/null
2. Enable cron logging – Edit `/etc/rsyslog.conf` or `/etc/rsyslog.d/50-default.conf` and ensure:
cron. /var/log/cron.log
Then restart rsyslog: `sudo systemctl restart rsyslog`
3. Capture package changes – Wazuh agents can monitor `/var/log/dpkg.log` (Debian) or `/var/log/yum.log` (RHEL). Add this to `/var/ossec/etc/ossec.conf` under `
<localfile> <location>/var/log/dpkg.log</location> <log_format>syslog</log_format> </localfile>
4. Web server logs – For Apache, ensure `CustomLog` is set. Ingest via:
<localfile> <location>/var/log/apache2/access.log</location> <log_format>apache</log_format> </localfile>
5. Test log generation – Simulate a failed sudo to generate auth events:
sudo -k && sudo ls /root 2>/dev/null tail -1 5 /var/log/auth.log
2. Wazuh Integration – Configuring `ossec.conf` for Centralized Collection
The core of Wazuh’s power lies in its `ossec.conf` file, which defines what logs are collected, how they are parsed, and where they are forwarded. The referenced guide emphasises proper `
Step‑by‑step guide to configure Wazuh agent for log collection:
1. Locate the configuration – On the agent, open `/var/ossec/etc/ossec.conf` with sudo.
2. Add a new log source – Below the `
<localfile> <location>/var/log/auth.log</location> <log_format>syslog</log_format> </localfile>
3. Enable active response – To automatically block repeated failed SSH attempts, uncomment:
<active-response> <disabled>no</disabled> <command>firewall-drop</command> <location>local</location> <rules_id>5710,5711</rules_id> </active-response>
4. Restart the agent after changes:
sudo systemctl restart wazuh-agent
5. Verify configuration syntax:
sudo /var/ossec/bin/wazuh-agent -t
3. Agent & Dashboard Validation – Ensuring Telemetry Reaches the SIEM
A misconfigured agent silently fails, creating a dangerous blind spot. Validation steps from the post include checking agent health, log ingestion counters, and real‑time event visibility on the Wazuh dashboard.
Step‑by‑step guide to validate agent health and log flow:
1. On the Wazuh manager, list all agents and their status:
sudo /var/ossec/bin/agent_control -l
Look for `Active` status. If `Disconnected`, check network or firewall port 1514/TCP.
2. On the agent, verify connection to manager:
sudo /var/ossec/bin/agent_control -i <agent_id>
Or check logs: `tail -f /var/ossec/logs/ossec.log | grep -i connection`
3. Send a test event from the agent:
logger -t "wazuh-test" "This is a manual log entry for SIEM validation"
Then search the Wazuh dashboard for `data.message:”This is a manual log entry”`.
4. Check local file statistics on the manager:
sudo /var/ossec/bin/wazuh-logtest -t
Paste a sample auth log line to see if rules fire.
5. Windows agent validation – On a Windows endpoint, open PowerShell as admin and check service status:
Get-Service -1ame "WazuhSvc" Force immediate log forwarding: & 'C:\Program Files (x86)\ossec-agent\agent-control.exe' -f
4. Firewall Monitoring – Tracking UFW Events for Network Anomalies
UFW (Uncomplicated Firewall) logs allowed connections, blocked traffic, and policy changes. The post stresses that without firewall logs, lateral movement and port scans go undetected.
Step‑by‑step guide to enable and ingest UFW logs:
1. Enable UFW logging (default is low – set to medium or high):
sudo ufw logging medium
Logs appear in `/var/log/ufw.log` and also `/var/log/kern.log`.
2. Verify logging is active by generating a blocked packet:
sudo ufw deny from 192.0.2.100 curl --connect-timeout 2 192.0.2.100 sudo tail -1 10 /var/log/ufw.log
3. Configure Wazuh to monitor UFW logs – Add to `ossec.conf`:
<localfile> <location>/var/log/ufw.log</location> <log_format>syslog</log_format> </localfile>
4. Create a custom rule to alert on “IN= OUT=” (empty interface – suspicious) in `/var/ossec/etc/rules/local_rules.xml`:
<rule id="100100" level="10"> <if_sid>5716</if_sid> <match>IN= OUT=</match> <description>UFW: Packet with no incoming interface – possible local exploit</description> </rule>
5. Restart agent and trigger a blocked ping:
sudo ufw deny proto icmp ping -c 1 8.8.8.8
5. Windows Event Monitoring – Security Events via Event Viewer and Group Policy
Windows Security Events (4624 – successful logon, 4625 – failed logon, 4672 – admin logon, 4688 – process creation) are gold for threat detection. The post highlights collecting these via Event Viewer and centralising them with Wazuh.
Step‑by‑step guide to enable and forward Windows Security Events:
1. Enable Advanced Audit Policy using Group Policy (gpedit.msc):
– Navigate to `Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies`
– Enable:
– `Audit Logon` (Success and Failure)
– `Audit Process Creation` (Include command line – requires GPO option)
– `Audit Account Management`
2. Verify events are generated – Open Event Viewer (`eventvwr.msc`), navigate to `Windows Logs -> Security`. Look for Event IDs 4624, 4625, 4688.
3. Install Wazuh agent on Windows – Download from official repo. During install, provide manager IP and registration key.
4. Configure agent to collect Security Events – Edit `C:\Program Files (x86)\ossec-agent\ossec.conf`:
<localfile> <location>Security</location> <log_format>eventchannel</log_format> </localfile>
5. Test log ingestion – Generate a failed logon attempt:
Run as non‑admin – use wrong password net use \\localhost\IPC$ /user:fakeuser wrongpassword
Then on the Wazuh dashboard, search `data.win.system.eventID:4625`.
6. Remote Access Visibility – Monitoring RDP Activity
RDP is a top attack vector. The post emphasises tracking authentication attempts, source IPs, and successful/failed remote connections. By default, Windows logs RDP events (4624/4625 with Logon Type 10).
Step‑by‑step guide to harden and monitor RDP logs:
1. Enable RDP logging – Ensure Terminal Services log channel is active. In Event Viewer, go to `Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-RemoteConnectionManager -> Operational`. Enable logging if disabled.
2. Collect those logs via Wazuh – Add to `ossec.conf`:
<localfile> <location>Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational</location> <log_format>eventchannel</log_format> </localfile>
3. Create a custom detection for brute force – In `local_rules.xml` (on manager):
<rule id="100200" level="12" frequency="10" timeframe="120" ignore="60"> <if_matched_sid>5710</if_matched_sid> <!-- Base Windows failed logon --> <match>Logon Type:\s+10</match> <description>RDP brute force – 10+ failures in 2 minutes</description> </rule>
4. Correlate with network logs – On Linux firewalls, monitor port 3389 inbound. Using `tcpdump` to capture RDP connection attempts:
sudo tcpdump -i eth0 'tcp port 3389' -1 -c 10
5. Test RDP monitoring – From a remote machine, try to RDP with wrong credentials. Verify the event appears in Wazuh index.
7. Correlation and Detection – Answering the Five Ws
As Okan YILDIZ states: “Every monitoring strategy should help answer: What happened? When? Who? Which system? Allowed or blocked?” Correlation across logs is the only way to turn data into evidence.
Step‑by‑step guide for a correlation exercise:
1. Scenario – An SSH brute force followed by a successful login and a sudo command.
2. Collect from three sources:
– Auth log: failed SSH (sshd
: Failed password) - Auth log: successful SSH (Accepted password) - Sudo log: command execution (sudo: user : TTY=pts/0 ; CMD=/bin/systemctl stop firewall) 3. Write a Wazuh rule to link these events using `<same_source_ip>` and `<timeframe>`: [bash] <rule id="100300" level="15" timeframe="300"> <if_group>authentication_success</if_group> <if_group>authentication_failed</if_group> <if_group>sudo</if_group> <same_source_ip /> <description>SSH brute force → success → privilege escalation</description> </rule>
4. Query in Wazuh dashboard to visualise the timeline:
SELECT timestamp, rule.description, data.srcip FROM wazuh-alerts- WHERE data.srcip='192.168.1.100' ORDER BY timestamp
5. Automate response – Add an active response to quarantine the source IP after correlation fires.
What Undercode Say:
– Key Takeaway 1: A SIEM cannot detect what it cannot see – missing logs create blind spots that attackers exploit. Every organisation must inventory and baseline its log sources before investing in expensive analytics.
– Key Takeaway 2: Correlation is worthless without context. Combining authentication logs, firewall events, and endpoint telemetry transforms raw data into actionable evidence, enabling SOC teams to answer “allowed or blocked?” in seconds.
Analysis (10 lines): Okan YILDIZ’s post cuts to the heart of modern security monitoring: visibility is a prerequisite, not an add‑on. Too many blue teams deploy SIEMs with default log configurations, leaving SSH brute forces invisible because `/var/log/auth.log` wasn’t forwarded. The emphasis on Wazuh – an open‑source SIEM – democratises enterprise‑grade logging for resource‑constrained teams. However, the challenge isn’t technology; it’s discipline. Organisations fail to enable advanced audit policies on Windows or rotate logs without archiving. The step‑by‑step commands provided above bridge that gap, turning theoretical best practices into verifiable, repeatable actions. Most importantly, YILDIZ’s framework of six investigative questions forces defenders to design backwards from incident response needs. This shifts logging from a compliance checkbox to a strategic weapon.
Prediction:
– +1 Adoption of open‑source SIEMs like Wazuh will accelerate as commercial solutions price out mid‑market firms, leading to more community‑driven log analysis playbooks and shared detection rules.
– +1 AI‑powered log correlation will become standard within 18 months, automatically linking RDP logins with firewall blocks and authentication failures without manual rule writing.
– -1 Attackers will shift to targeting log pipelines themselves – deleting or poisoning `ossec.log` and Windows Event channels – creating a new class of “log‑blind” exploits that bypass SIEM visibility.
– -1 Organisations that fail to implement the validation steps (agent health checks, logtest verification) will suffer extended dwell times, as their dashboards show green while critical telemetry silently drops.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
[Join Undercode Academy for Verified Certifications](https://undercode.co.uk/certifications/)
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[[email protected]](mailto:[email protected])
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: [Yildizokan Wazuh](https://www.linkedin.com/posts/yildizokan_wazuh-siem-loganalysis-ugcPost-7469786492895350785-OmH2/) – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
[💬 Whatsapp](https://undercode.help/whatsapp) | [💬 Telegram](https://t.me/UndercodeCommunity)
📢 Follow UndercodeTesting & Stay Tuned:
[𝕏 formerly Twitter 🐦](https://x.com/undercodeupdate) | [@ Threads](https://www.threads.net/@undercodetesting) | [🔗 Linkedin](https://www.linkedin.com/company/undercodetesting/) | [🦋BlueSky](https://bsky.app/profile/undercode.bsky.social)
