Kalos Cybersecurity LLC
Field guide

Wazuh Lab Platform Operations Quick Reference

Alerts to Answers Analyst Field Guide 01 - v20

Introduction

This field guide is the operational starting point for the Alerts to Answers lab environment. It gives students and analysts a compact, evidence-first workflow for checking Wazuh services, agents, logs, ports, resources, and the Suricata data path before troubleshooting higher-level symptoms.

Purpose and Scope

Use this guide before every lab, after configuration changes, and whenever the platform behaves unexpectedly. The commands assume the validated package-based Wazuh 4.14.5 lab deployment; containerized or production environments require their own operating procedures.

Chapter and Lab Alignment

Alignment Placement
Primary chapter alignment Chapter 9 - Operating the Platform
Supporting chapter alignment Chapters 3 and 5
Lab alignment Primary: Lab 0 and Lab 9. Supporting: Labs 1-8.
Recommended point of use Run the health checks before analysis, after changes, and before escalation.

Baseline: Wazuh 4.14.5 lab deployment. Commands assume package-based services; container deployments require container-specific commands.

Core Components and Default Ports

Component Default port Purpose
Wazuh server 1514/TCP Agent event communication
Wazuh server 1515/TCP Agent enrollment
Wazuh server API 55000/TCP REST API
Wazuh indexer 9200/TCP Indexer API
Wazuh dashboard 443/TCP Web interface

UDP 1514 is optional and disabled by default. Restrict management and API ports to trusted networks.

Health and Service Control

Prefer the operating system service manager for start/stop/restart operations:

sudo systemctl --no-pager --full status wazuh-manager
sudo systemctl --no-pager --full status wazuh-indexer
sudo systemctl --no-pager --full status wazuh-dashboard

Use wazuh-control to inspect manager-side processes:

sudo /var/ossec/bin/wazuh-control status
sudo /var/ossec/bin/wazuh-control info -v
sudo systemctl restart wazuh-manager
sudo systemctl restart wazuh-indexer
sudo systemctl restart wazuh-dashboard

Restart only the affected component and collect evidence before restarting.

Agent Status

sudo /var/ossec/bin/agent_control -l
sudo /var/ossec/bin/agent_control -lc
sudo /var/ossec/bin/agent_control -i <agent-id>
  • -l lists all agents.
  • -lc lists currently connected agents.
  • -i shows one agent's details.

Never expose enrollment or authentication keys in screenshots.

Logs and Configuration

Location Purpose
/var/ossec/etc/ossec.conf Main Wazuh server/agent configuration
/var/ossec/etc/rules/local_rules.xml Local detection rules
/var/ossec/etc/decoders/local_decoder.xml Local decoders
/var/ossec/logs/ossec.log Wazuh operational log
/var/ossec/logs/alerts/alerts.json Structured generated alerts
/var/ossec/logs/alerts/alerts.log Human-readable generated alerts
/etc/wazuh-indexer/ Indexer package configuration
/etc/wazuh-dashboard/ Dashboard package configuration 
sudo tail -f /var/ossec/logs/ossec.log
sudo tail -f /var/ossec/logs/alerts/alerts.json
sudo journalctl -u wazuh-manager -f
sudo journalctl -u wazuh-indexer -f
sudo journalctl -u wazuh-dashboard -f

Validate Changes

Back up local files before editing. Use an XML parser for well-formedness and Wazuh Logtest for decoder/rule behavior:

sudo xmllint --noout /var/ossec/etc/ossec.conf
sudo xmllint --noout /var/ossec/etc/rules/local_rules.xml
sudo xmllint --noout /var/ossec/etc/decoders/local_decoder.xml
sudo /var/ossec/bin/wazuh-logtest

xmllint checks XML structure; it does not prove that a Wazuh rule is semantically correct. wazuh-logtest evaluates a supplied one-line event through pre-decoding, decoding, and rule matching.

Suricata Integration

On the Ubuntu sensor:

sudo tail -f /var/log/suricata/eve.json
sudo tail -f /var/ossec/logs/ossec.log
sudo systemctl --no-pager --full status suricata wazuh-agent

On the Wazuh server:

sudo tail -f /var/ossec/logs/alerts/alerts.json
sudo /var/ossec/bin/wazuh-logtest

In the Dashboard, start with:

rule.groups: suricata

Confirm in order: mirrored traffic reaches the sensor, Suricata writes eve.json, the agent monitors it as JSON, the manager receives it, and a rule generates an alert.

Resource and Time Checks

df -h
df -ih
free -h
uptime
timedatectl

For the Amazon Linux 2023 Wazuh server, check chronyd when installed:

sudo systemctl --no-pager --full status chronyd

For Ubuntu sensors, check the configured time-synchronization service, commonly systemd-timesyncd or chrony.

Listening Ports and Firewall

sudo ss -lntup | grep -E '1514|1515|55000|9200|443'

Use the firewall tool installed on that host:

sudo firewall-cmd --list-all   # firewalld, common on RPM-based systems
sudo ufw status verbose       # UFW, when installed on Ubuntu

Troubleshooting Order

  1. Confirm the source event exists on the endpoint or sensor.
  2. Confirm the Wazuh agent is active.
  3. Inspect the relevant ossec.log.
  4. Test the exact raw event with wazuh-logtest when rule/decoder behavior is in question.
  5. Confirm an alert exists in alerts.json.
  6. If the alert exists but is absent from the Dashboard, check the time range, indexer, and dashboard services.
  7. Restart only the affected service after preserving evidence.

Technical References