Give your Wazuh server a computer all to itself

How big does the machine need to be?

It depends on how many endpoints run the Wazuh agent. Those agents send their events to the Wazuh manager, which applies its rules; the results are stored in the Wazuh indexer and shown in the Wazuh dashboard. Wazuh describes the whole thing as open-source security monitoring and log analysis. Its quickstart sizes all three parts sharing one machine, for 90 days of searchable alerts:

Read the memory column as a floor. The indexer's own requirements page recommends 16 GB and 8 cores for each indexer node, and the manager wants 20 GB of free space under /var/ossec the first time it starts, while it unpacks its vulnerability database (about 11 GB once done). Disk grows with how chatty your endpoints are: for 90 days the indexer page budgets workstations at about 1.5 GB each, servers at 3.7 GB and network devices at 7.4 GB.

On the software side, version 4.14 supports Ubuntu (16.04 up to 24.04), RHEL from 7 up to 10, CentOS Stream 10, and both Amazon Linux 2 and Amazon Linux 2023, on 64-bit Intel, AMD or ARM processors. The steps below use Ubuntu 24.04.

The server that fits

Renting a dedicated server means one physical computer runs your work and nobody else's, so the indexer never waits behind a stranger's disk activity. Every machine in our dedicated server range includes root access and an unmetered port, and you pay month by month. Two kinds suit Wazuh well:

• For up to 25 endpoints: the Xeon E3-1585L v5 card under Small and cheap, 4 cores at 3 GHz with 16 to 64 GB and an NVMe disk. It is an m710x cartridge, so you get the console screen and power button. Its smallest size, 16 GB, is already twice the quickstart's 8 GiB and matches the indexer page's recommendation; take 32 GB if you expect to keep more than 90 days of alerts.
• For 26 to 100 endpoints, or longer history: a two-processor machine under Serious workloads, for example the dual Xeon E5-2630L v3 with 16 cores, with extra disks picked on its order page. Rack servers and blades include the out-of-band console.
• Past 100 endpoints: Wazuh recommends spreading the manager and the indexer over several machines in clusters, so plan for more than one server.
• Skip the X-Gene ARM cartridge: the newest system it takes is Ubuntu 18.04 (16.04 is the only other), both out of standard support, while these steps are written for 24.04; it also has no console, only power control and reinstall.

A ready server is running within 30 minutes of approval; a custom build takes hours rather than minutes. You manage the server; we keep the hardware and the network running. If a firewall rule shuts you out, the console still shows you the screen, and the control panel lets you reinstall the operating system yourself.

Who should be able to reach which port

Only your agents, and you. The all-in-one install leaves the indexer listening on 127.0.0.1 only (the wazuh-install.sh script writes that into its configuration), but the manager's API answers on all addresses unless told otherwise, and so does the dashboard, so the firewall does the sorting:

• 1514/tcp, agent traffic: open to the networks your endpoints connect from. The channel is encrypted and authenticated.
• 1515/tcp, agent enrollment: the same networks, and protected with a password (next section). Out of the box, any machine that reaches this port can register itself.
• 443/tcp, the dashboard: you and your team. Start with an SSH tunnel; later allow your own fixed addresses.
• 55000/tcp, the manager API: keep it closed. On the all-in-one the dashboard talks to it on the same machine.
• 9200/tcp, the indexer: closed. So are 1516 and 9300-9400, which only matter when you add cluster nodes, and 514 for syslog, which is switched off until you turn it on.

Endpoints that roam, like laptops on hotel Wi-Fi, may force 1514 open to everyone. In that case keep the enrollment password on and only open 1515 while you are adding new machines.

Up and running in one sitting

Paste this as root. It switches the firewall on with nothing but SSH allowed, then runs the official assistant in all-in-one mode (-a). The assistant creates random passwords for every built-in user and keeps a copy in wazuh-install-files.tar (the block then makes that file root-only); it also refuses to install over an existing copy unless you pass -o. Last, it switches off the Wazuh package repository. The quickstart advises this so that everyday updates cannot upgrade Wazuh by accident, which it warns could break the environment. Because ufw is already on, the assistant will remind you to open 443, 1514 and 1515. Don't, yet: the agent block further down lets only your endpoints in on 1514 and 1515, and you reach the dashboard through SSH.

# run as root on a clean Ubuntu 24.04 server
sed -i 's/^IPV6=.*/IPV6=yes/' /etc/default/ufw &&
ufw allow OpenSSH && ufw --force enable &&
cd /root && curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh &&
bash ./wazuh-install.sh -a &&
chmod 600 /root/wazuh-install-files.tar &&
sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list && apt update &&
tar -O -xf /root/wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt &&
echo "Wazuh is installed; the firewall lets in SSH only" ||
echo "STOP - something went wrong, read the messages above"

1. On your own computer, open a tunnel: ssh -L 9443:localhost:443 you@your-server.
2. Browse to https://localhost:9443 and accept the certificate warning. Wazuh signs its own certificate, so the warning is expected.
3. Sign in as admin with the password the block printed.
4. Want a fresh admin password that never sat in that archive? As root, fetch the tool with curl -sO https://packages.wazuh.com/4.14/wazuh-passwords-tool.sh and run bash wazuh-passwords-tool.sh -u admin. Leave out -p and it invents one and shows it, and on an all-in-one install it also changes the password where Filebeat and the manager use it, then restarts both.
5. Download wazuh-install-files.tar to somewhere safe. Besides the passwords it holds the certificates you need to add nodes later.

Letting your agents in

Fill in NET with the range your endpoints use and paste the block. It writes an enrollment password once (run it again and the existing one stays), turns on use_password in the manager's config, confirms the change really happened, restarts the manager, and only after all that opens 1514 and 1515 to NET. It assumes your endpoints use IPv4; per the auth reference, the enrollment service only listens on IPv6 once its ipv6 option is switched on.

# run as root on your Wazuh server
NET=""   # the address range your endpoints come from, e.g. 198.51.100.0/24
PASSFILE=/var/ossec/etc/authd.pass; CONF=/var/ossec/etc/ossec.conf
if [ -z "$NET" ]; then echo "STOP - fill in NET first"; else
  { [ -s "$PASSFILE" ] || { pw=$(openssl rand -hex 16) && [ -n "$pw" ] &&
    install -m 640 -o root -g wazuh /dev/null "$PASSFILE" &&
    printf '%s\n' "$pw" > "$PASSFILE"; }; } &&
  sed -i 's|<use_password>no</use_password>|<use_password>yes</use_password>|' "$CONF" &&
  grep -q '<use_password>yes</use_password>' "$CONF" &&
  systemctl restart wazuh-manager &&
  ufw allow from "$NET" to any port 1514,1515 proto tcp &&
  echo "agents from $NET may enrol; the password is in $PASSFILE" ||
  echo "STOP - a step did not finish; look at $CONF and the ufw output, then run again"
fi

For a Linux endpoint, Wazuh's agent page has you add its repository first, then install the agent package with WAZUH_MANAGER pointing at your server; the dashboard can also write that command for you. Then give the endpoint the same password in its own authd.pass file under /var/ossec/etc (mode 640, owner root, group wazuh) and restart wazuh-agent. Setting WAZUH_REGISTRATION_PASSWORD on the install command works too, since it writes that same authd.pass file, but the password is then saved in your command history. Never run an agent newer than your manager.

Keeping a copy safe, and staying current

This script copies everything Wazuh's backup guide lists. To keep it short we copy whole folders where the guide names single files inside them, and quietly skip paths your install does not have. The manager is stopped only while its databases in /var/ossec/queue/db are copied, exactly as the guide does it, and started again even if something breaks along the way. Only once the new archive has been read back does it delete ones older than 14 days. Everything is first gathered in a temporary folder under /tmp, so make sure the disk has room for roughly double what /var/ossec/logs takes.

# save as /usr/local/sbin/wazuh-backup.sh, then run it as root with bash
set -euo pipefail; umask 077
OUT=/var/backups/wazuh; mkdir -p "$OUT"; WORK=$(mktemp -d)
trap 'systemctl start wazuh-manager; rm -rf "$WORK"' EXIT
COPY="rsync -aR --ignore-missing-args"
$COPY /etc/filebeat/ /etc/postfix/ /var/ossec/api/configuration/ /var/ossec/etc/ \
  /var/ossec/logs/ /var/ossec/queue/agentless/ /var/ossec/queue/agents-timestamp \
  /var/ossec/queue/fts/ /var/ossec/queue/rids/ /var/ossec/stats/ \
  /var/ossec/var/multigroups/ /var/ossec/active-response/bin/ \
  /var/ossec/integrations/ /var/ossec/wodles/ /etc/wazuh-indexer/ \
  /usr/lib/sysctl.d/wazuh-indexer.conf /etc/wazuh-dashboard/ \
  /usr/share/wazuh-dashboard/config/opensearch_dashboards.keystore \
  /usr/share/wazuh-dashboard/data/wazuh/ \
  /usr/share/wazuh-dashboard/plugins/wazuh/public/assets/custom/images/ "$WORK/"
systemctl stop wazuh-manager
$COPY /var/ossec/queue/db/ "$WORK/"
systemctl start wazuh-manager
FILE="$OUT/wazuh-$(date +%F-%H%M%S).tar.gz"
tar -czf "$FILE" -C "$WORK" .
tar -tzf "$FILE" > /dev/null
find "$OUT" -name 'wazuh-*.tar.gz' -mtime +14 -delete
echo "saved and checked, $FILE"

Try it by hand once (that also creates /var/backups/wazuh, readable by root only), then let cron run it each night from a file such as /etc/cron.d/wazuh-backup containing 15 3 * * * root umask 077; bash /usr/local/sbin/wazuh-backup.sh >> /var/backups/wazuh/backup.log 2>&1. Move the archives to another machine you control. Alert files kept in /var/ossec/logs are included; what the indexer holds is not, and Wazuh suggests an index snapshot for that part.

Bringing a copy back means first checking that tar -tzf lists the archive without complaint, then a fresh all-in-one of the same version on a new machine, then Wazuh's restore guide; unpack the archive in an empty folder and run the guide's commands from there, since its etc/... and var/... paths match this layout. When a new release comes out, back up, snapshot the indices, turn the repository back on and follow the upgrade guide: indexer first, then the manager, then the dashboard. Two things to know before you start: after 4.12 there is no going back to 4.11 or older without reinstalling the indexer, and from 4.14.1 a decoded user field is renamed dstuser, so check saved searches that use it.

What the licence lets you do, and when to grow

Wazuh costs nothing to run. In the v4.14.9 release, the LICENSE file of the main repository covers the manager and agent under GPLv2; the indexer and dashboard repositories, forks of OpenSearch and OpenSearch Dashboards according to their README.md files, carry Apache 2.0 in LICENSE.txt, plus GPLv2 for the dashboard plugins. This is our general reading and not legal advice: hand someone a copy of the GPL-licensed parts, modified or as they came, and the source must go with them; for the Apache parts, every copy must still carry its copyright notices and a copy of the licence. Using Wazuh only for your own endpoints triggers neither. The development branch's LICENSE already moves the Wazuh engine in src/engine/ to AGPL-3.0 or later, which also asks you to offer source if you let people use a modified version over a network, so check again before upgrading to a release made from it.

One machine stops being the right answer when the dashboard must stay up through a hardware failure, or when you pass about 100 endpoints. Wazuh also does not draw resource graphs; for CPU, memory and uptime, add Zabbix or Prometheus with Grafana. And if all you need is searchable logs, OpenSearch on its own is simpler.

Questions people ask

Can Wazuh run on a server with 4 GB of memory?

The assistant refuses an all-in-one install below about 4 GB and 2 cores unless you pass -i to skip its check. That is a test setup at best: the quickstart's table starts at 8 GiB, and the indexer page recommends 16 GB.

Do my agents need the API port 55000?

No. Agents report on 1514 and enrol on 1515. The API on 55000 is used by the dashboard, which on an all-in-one sits on the same machine, so the port can stay closed to the outside.

I lost the admin password. Where is it?

If you never changed it, look in wazuh-install-files.tar (kept in the folder you ran the assistant from) for the file wazuh-passwords.txt. If you did change it, run the passwords tool again as root with -u admin to set a new one.

Is the Wazuh dashboard safe to open to the internet?

Treat it as private. It is your view into every endpoint, so reach it over an SSH tunnel or a VPN, or allow only fixed addresses you own on 443.