Best Practices

    Wazuh Server Hardening: 10 Production Best Practices

    Concrete steps to harden a production Wazuh server, rotate default passwords, lock down the API, restrict ports, enable TLS everywhere, audit RBAC and back up keys.

    WazuGuardix Team June 16, 2026 9 min read

    A default Wazuh install is meant to get you running fast, it is not production-ready. Before you point real agents at it, work through this hardening checklist. Each item maps to a real attack vector our SOC team has seen exploited in the wild.

    1. Rotate every default password

    The installer generates an admin password and stores it in wazuh-install-files.tar. Rotate it immediately using the password tool:

    sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh -a

    2. Replace self-signed certificates

    The all-in-one installer ships self-signed certs. For production, generate certs from an internal CA (or Let's Encrypt for the dashboard) and replace the files under /etc/wazuh-indexer/certs/ and /etc/filebeat/certs/.

    3. Lock down the Wazuh API

    • Disable the default wazuh-wui user once your integrations have their own service accounts.
    • Bind the API to 127.0.0.1 if only the local dashboard consumes it, edit /var/ossec/api/configuration/api.yaml.
    • Enable rate limiting (access.max_request_per_minute) to slow brute force.

    4. Use RBAC, not the admin role

    Create dedicated roles for analysts (read-only on alerts), engineers (rule edits) and integrations (scoped API). Audit who has the admin role at least monthly.

    5. Restrict network exposure

    Only 1514/udp (agent events) and 1515/tcp (enrollment) should reach the manager from agent subnets. The indexer (9200), dashboard (443) and API (55000) should be behind the firewall or VPN, never exposed to the public internet.

    6. Use enrollment passwords (not open enrollment)

    Set authd.use_password to yes in ossec.conf and generate an enrollment password. Any agent that tries to register without it will be rejected.

    7. Back up /var/ossec/etc/client.keys

    If you lose this file you lose every agent registration. Back it up alongside ossec.conf and custom rules to encrypted offsite storage, daily.

    8. Stay on a supported Wazuh version

    Subscribe to the Wazuh security advisories list and apply minor upgrades within 30 days. Pin the major (e.g. 4.x) in your apt/yum repo to avoid surprise jumps.

    9. Enable Wazuh audit logging on itself

    Forward /var/ossec/logs/api.log, /var/ossec/logs/ossec.log and the dashboard audit log back into Wazuh itself. Self-monitoring catches rogue rule edits and credential abuse.

    10. Test your backups quarterly

    Back up /var/ossec/etc/, /var/ossec/queue/agents-timestamp, the indexer snapshots and the dashboard saved objects. Restore them into a staging box every quarter, a backup you have not restored is not a backup.

    Official reference

    Commands and configuration in this guide are based on the official Wazuh documentation. For the canonical source, see:

    HardeningSecurityBest PracticesProduction

    Need help running Wazuh in production?

    Our team designs, deploys and operates Wazuh end to end, from indexer sizing to custom rules and 24/7 SOC monitoring.

    Related guides

    Hardening

    Wazuh Post-Installation Hardening Checklist

    Right after the Wazuh installer finishes, run through this hardening checklist before exposing anything, password rotation, TLS, firewall, backups and retention.

    Read guide
    Best Practices

    Wazuh Alert Tuning: A Practical Guide to Reducing False Positives

    Stop drowning in noisy Wazuh alerts. A practical tuning loop, baseline, suppress, raise levels, measure, to get to a clean SOC queue.

    Read guide
    Best Practices

    Writing Custom Wazuh Rules: A Hands-On Guide with Examples

    A hands-on walkthrough of writing your first Wazuh detection rule, from log to decoder to rule, with five worked examples.

    Read guide