Deployment guide

Wazuh

Overview

Wazuh is a free, open-source security platform that unifies SIEM and XDR. It covers log analysis, intrusion detection, file integrity monitoring, vulnerability detection, configuration assessment and incident response.

This SecureAnyCloud image installs the Wazuh 4.14 all-in-one stack on a single VM, with a unique administrator password generated on the first boot of every VM. The stack has three components. The Wazuh indexer, an OpenSearch fork, stores and searches security events. The Wazuh manager collects and analyses agent data, with Filebeat shipping alerts to the indexer. The Wazuh dashboard, an OpenSearch Dashboards fork, serves the web UI over HTTPS.

What you get:

Wazuh indexer 4.14 (OpenSearch fork) for event storage and search
Wazuh manager 4.14 (with Filebeat) for agent collection and analysis
Wazuh dashboard 4.14 (OpenSearch Dashboards fork) serving the web UI over HTTPS on :443
A dedicated Azure data disk at /var/lib/wazuh holding the indexer indices, separate from the OS disk and re-provisioned with every VM
A per-VM admin password generated at first boot and stored in a root-only file
wazuh-indexer.service, wazuh-manager.service and wazuh-dashboard.service as systemd units, enabled and active
24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B4ms (4 vCPU / 16 GiB RAM) is the recommended starting size. The Wazuh indexer is an OpenSearch JVM and runs alongside the manager and dashboard.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network, 443/tcp from the operators who use the dashboard, and 1514/tcp and 1515/tcp from the hosts running Wazuh agents.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Wazuh by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTPS (443).

Review the dedicated data disk on the Disks tab, then select Review + create and Create. After deployment, add NSG rules for 1515/tcp (agent enrollment) and 1514/tcp (agent events).

Step 2 - Deploy with the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:wazuh-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name wazuh \
  --image sac1647283583153:wazuh-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name wazuh --port 443 --priority 1010
az vm open-port --resource-group <your-rg> --name wazuh --port 1515 --priority 1020
az vm open-port --resource-group <your-rg> --name wazuh --port 1514 --priority 1030

First boot takes a few minutes. On its first boot, the VM finishes its per-VM setup in the background. It generates this VM's own credentials and starts the services. If you connect as soon as the VM shows as running, wait for that setup to complete before you continue.

To wait for it, run sudo cloud-init status --wait. The command prints status: done when the VM is ready. The credentials and services described below exist only after that.

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active wazuh-indexer.service wazuh-manager.service wazuh-dashboard.service

All three services report active.

Step 5 - Retrieve your admin password

Your VM generates a unique administrator password on first boot and writes it to a root-only file. Read it with:

sudo grep -E '^WAZUH_' /root/wazuh-credentials.txt

WAZUH_ADMIN_USER is admin, and WAZUH_ADMIN_PASSWORD holds the password.

Step 6 - Check the indexer cluster health

The Wazuh indexer exposes its REST API on :9200 over HTTPS with a self-signed certificate. Authenticate with the per-VM admin password and confirm that the cluster reports green or yellow:

PW=$(sudo grep '^WAZUH_ADMIN_PASSWORD=' /root/wazuh-credentials.txt | cut -d= -f2-)
curl -s -k -u "admin:$PW" https://127.0.0.1:9200/_cluster/health | head -c 200; echo

A single-node all-in-one deployment reports yellow, because replica shards have nowhere to go on one node. This is expected and healthy.

Step 7 - Verify dashboard authentication

The indexer security layer rejects a wrong password and accepts the per-VM password:

PW=$(sudo grep '^WAZUH_ADMIN_PASSWORD=' /root/wazuh-credentials.txt | cut -d= -f2-)
echo "wrong password -> HTTP $(curl -s -k -o /dev/null -w '%{http_code}' -u 'admin:wrong-password' https://127.0.0.1:9200/_cluster/health)"
echo "correct password -> HTTP $(curl -s -k -o /dev/null -w '%{http_code}' -u "admin:$PW" https://127.0.0.1:9200/_cluster/health)"

The wrong password returns HTTP 401. The correct one returns HTTP 200.

Step 8 - Confirm the dashboard answers on HTTPS

Request the dashboard over HTTPS:

curl -s -k -o /dev/null -w 'wazuh dashboard -> HTTP %{http_code}\n' https://127.0.0.1/

The Wazuh dashboard returns HTTP 200, or 302 to the login page.

Step 9 - Sign in to the Wazuh dashboard

Open https://<vm-public-ip>/ in a browser. Your browser warns about the self-signed certificate. Accept it, or install your own certificate as described in Enabling a trusted certificate below.

Sign in as admin with the password from Step 5. You land on the Wazuh overview, with modules for threat detection, security operations and cloud security.

Step 10 - Review endpoint security and agents

From the menu, open Endpoints (or Agents) to see enrolled agents and their status. The threat-detection and security-events views let you drill into alerts collected by the manager.

The Discover and security events view shows the raw alert documents indexed by the Wazuh indexer.

Step 11 - Enroll a Wazuh agent

Install the Wazuh agent on the hosts you want to monitor. Point each agent at this VM's public IP on port 1515 (enrollment) and port 1514 (events). On a Linux endpoint, run:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo WAZUH_MANAGER='<vm-public-ip>' bash ./wazuh-install.sh --wazuh-agent sudo systemctl enable --now wazuh-agent

The new agent appears under Endpoints in the dashboard within a minute.

Enabling a trusted certificate

The dashboard ships with a self-signed certificate. For production, replace it with a certificate from your own CA or a public CA.

The dashboard certificate lives under /etc/wazuh-dashboard/certs/. Replace dashboard.pem and dashboard-key.pem with your certificate and key, then restart the dashboard with sudo systemctl restart wazuh-dashboard.

Backup and maintenance

The Wazuh indexer data, which includes all indexed security events and alerts, lives on the dedicated data disk at /var/lib/wazuh. Snapshot that disk in Azure to back up your event store.

Keep the OS patched with sudo apt update && sudo apt upgrade. To restart the stack cleanly, run sudo systemctl restart wazuh-indexer wazuh-manager wazuh-dashboard.

Support

This image is backed by 24/7 SecureAnyCloud support. Contact us by email or chat for help with agent enrollment, rule tuning, integrations, dashboard configuration, scaling and backups.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them. Wazuh is a trademark of Wazuh Inc.

Deploy on Azure

Launch Wazuh SIEM on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

Wazuh is a free and open source security platform that unifies SIEM and XDR capabilities. Agents on your Linux, Windows and macOS endpoints collect logs, file integrity events, running-process and package inventories, and configuration state. The Wazuh server correlates all of it against thousands of rules.

The Wazuh dashboard gives you one console for log data analysis, intrusion detection, file integrity monitoring, vulnerability detection, security configuration assessment, regulatory compliance reporting and MITRE ATT&CK mapping.

This SecureAnyCloud image installs Wazuh 4.14.6 using the project's own all-in-one deployment. The Wazuh indexer, the Wazuh server and the Wazuh dashboard are installed, wired together and managed by systemd on a single instance. Two things set it apart from a manual install:

Nothing shared ships in the image. Wazuh's documented default logins and the installer's build-time passwords are both removed before capture. On the first boot of every instance, the appliance regenerates the entire TLS certificate chain: a new root certificate authority, and new indexer, server and dashboard certificates. It rotates every indexer account and both server API accounts to freshly generated random passwords, then writes yours to a root-only file.
It is shaped for production from the first boot. Security event indices live on their own dedicated data volume, and the Wazuh server's queue, alerts and archives live on a second one. The management API is bound to loopback, and an unauthenticated liveness endpoint is served for load balancer health checks.

What you get:

Wazuh 4.14.6 all-in-one: wazuh-indexer, wazuh-manager, wazuh-dashboard and filebeat, all installed from the project's official packages
wazuh-certs-firstboot.service, which regenerates the whole TLS certificate chain for this instance before the Wazuh services start
wazuh-firstboot.service, which rotates every indexer account and both server API accounts, then writes this instance's credentials to a root-only file
A dedicated 80 GiB volume at /var/lib/wazuh for the indexer's data and logs, and a dedicated 40 GiB volume at /var/ossec for the Wazuh server, both mounted by filesystem UUID
nginx.service serving an unauthenticated /health endpoint on TCP 80 for load balancer and Auto Scaling probes
The Wazuh server API bound to 127.0.0.1, so it is never exposed to the internet by default
Ubuntu 24.04 LTS base, fully patched at build, with unattended security upgrades enabled

Prerequisites

You need an active AWS account, an EC2 key pair, and a VPC with a subnet.

The recommended instance type is m5.large (2 vCPU, 8 GiB), which comfortably exceeds Wazuh's documented all-in-one minimum for up to 25 agents. Size up as your agent count and event rate grow (see Step 11).

Launch from the AWS Marketplace

Find Wazuh SIEM on the AWS Marketplace, subscribe, and launch an instance. In the launch wizard, attach a security group that allows these inbound ports:

TCP 22, from your administrators, for SSH
TCP 443, from your administrators, for the Wazuh dashboard
TCP 1514, from the endpoints you will monitor, for agent event traffic
TCP 1515, from the endpoints you will monitor, for agent enrollment
TCP 80, optional, for the unauthenticated /health endpoint used by load balancer probes

Restrict every rule to the narrowest source range that works for you. The dashboard is the only administrative surface that needs to be reachable from your network.

Launch with the AWS CLI

Launch the instance from the AMI with the AWS CLI:

AMI_ID="<marketplace-ami-id>"
# from the Marketplace listing, in your region KEY_NAME="my-key" SUBNET_ID="subnet-xxxxxxxx" SG_ID="sg-xxxxxxxx"
# allows 22 + 443 + 1514 + 1515 from your networks only aws ec2 run-instances \
  --image-id "$AMI_ID" --instance-type m5.large \
  --key-name "$KEY_NAME" --subnet-id "$SUBNET_ID" \
  --security-group-ids "$SG_ID" \
  --metadata-options 'HttpTokens=required' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=wazuh-siem}]'

The image carries its own block device mappings, so the two data volumes are created and attached for you.

Connecting to your instance

Connect over SSH as the login user for your image's operating system. For Ubuntu 24.04 LTS, the login user is ubuntu and the SSH command is ssh -i my-key.pem ubuntu@<instance-public-ip>.

wazuh-certs-firstboot.service, the three Wazuh services, filebeat.service, nginx.service and wazuh-firstboot.service all start automatically on first boot.

First boot generates a certificate chain and rotates every credential, which takes a couple of minutes on a fresh instance. Wait for /var/lib/sac/data/wazuh-firstboot.done to appear before you sign in.

Retrieve this instance's credentials

First boot writes a root-only credentials file. Every instance gets different values, and the image contains no shared or default credential. List the keys the file holds:

sudo test -f /var/lib/sac/data/wazuh-firstboot.done && echo "first boot complete"
sudo grep -oE '^[A-Z_]+=' /root/wazuh-credentials.txt

first boot complete WAZUH_DASHBOARD_URL= WAZUH_ADMIN_USER= WAZUH_ADMIN_PASSWORD= <set-at-first-boot>= WAZUH_API_USER= WAZUH_API_PASSWORD=

To read a single value, print just that line rather than the whole file:

sudo grep '^WAZUH_ADMIN_USER=' /root/wazuh-credentials.txt

WAZUH_ADMIN_USER=admin

WAZUH_ADMIN_PASSWORD is the dashboard login for user admin. WAZUH_API_PASSWORD is for the Wazuh server API user wazuh (Step 10). Copy both into your password manager and keep them out of your shell history.

Verify the services

Confirm that all seven services are active:

sudo systemctl is-active wazuh-indexer wazuh-manager wazuh-dashboard filebeat nginx
sudo systemctl is-active wazuh-certs-firstboot wazuh-firstboot

active active active active active active active

The unauthenticated liveness endpoint is the only endpoint that answers without a credential. This is what an Elastic Load Balancing or Auto Scaling health check needs:

curl -s -o /dev/null -w 'GET /health -> HTTP %{http_code}\n' http://127.0.0.1/health
curl -s http://127.0.0.1/health

GET /health -> HTTP 200 ok

Confirm your credential is unique to this instance

Run this check before you trust any security appliance. Read your password from the root-only file into a shell variable. Confirm that it authenticates to the indexer, and that Wazuh's documented defaults do not:

PW=$(sudo grep '^WAZUH_ADMIN_PASSWORD=' /root/wazuh-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'per-instance password -> HTTP %{http_code}\n' -u "admin:$PW" https://127.0.0.1:9200/_cluster/health
curl -sk -o /dev/null -w 'admin:admin -> HTTP %{http_code}\n' -u 'admin:admin' https://127.0.0.1:9200/_cluster/health
curl -sk -o /dev/null -w 'admin:SecretPassword -> HTTP %{http_code}\n' -u 'admin:SecretPassword' https://127.0.0.1:9200/_cluster/health
curl -sk -o /dev/null -w 'admin:wazuh -> HTTP %{http_code}\n' -u 'admin:wazuh' https://127.0.0.1:9200/_cluster/health

per-instance password -> HTTP 200 admin:admin -> HTTP 401 admin:SecretPassword -> HTTP 401 admin:wazuh -> HTTP 401

Only your per-instance password works. The same holds for the Wazuh server API, whose documented defaults are also rotated on first boot. Check it with:

APW=$(sudo grep '^WAZUH_API_PASSWORD=' /root/wazuh-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'wazuh:<per-instance> -> HTTP %{http_code}\n' -u "wazuh:$APW" https://127.0.0.1:55000/security/user/authenticate
curl -sk -o /dev/null -w 'wazuh:wazuh -> HTTP %{http_code}\n' -u 'wazuh:wazuh' https://127.0.0.1:55000/security/user/authenticate
curl -sk -o /dev/null -w 'wazuh-wui:wazuh-wui -> HTTP %{http_code}\n' -u 'wazuh-wui:wazuh-wui' https://127.0.0.1:55000/security/user/authenticate

wazuh:<per-instance> -> HTTP 200 wazuh:wazuh -> HTTP 401 wazuh-wui:wazuh-wui -> HTTP 401

Then confirm that the indexer cluster is healthy:

PW=$(sudo grep '^WAZUH_ADMIN_PASSWORD=' /root/wazuh-credentials.txt | cut -d= -f2-)
curl -sk -u "admin:$PW" https://127.0.0.1:9200/_cluster/health | jq '{status, number_of_nodes, active_shards}'

{ "status": "green", "number_of_nodes": 1, "active_shards": 26 }

Sign in to the dashboard

Open https://<instance-public-ip>/ in a browser. The appliance uses the self-signed certificate it generated on first boot, so your browser warns you the first time. Accept the warning, or put your own certificate in front of the dashboard (Step 13).

Explore the overview console

After you sign in, you land on the overview. The agents summary is empty until you enroll your first endpoint. The alerts panel is already counting, because the Wazuh server monitors the instance it runs on from the moment it starts.

The module groups map out the platform:

Endpoint security: Configuration Assessment, Malware Detection, File Integrity Monitoring
Threat intelligence: Threat Hunting, Vulnerability Detection, MITRE ATT&CK
Security operations: IT Hygiene, PCI DSS and the other compliance views
Cloud security: Docker, Amazon Web Services, and the other cloud integrations

Enroll your first agent

Wazuh collects data from endpoints through its agent. In the dashboard, choose Deploy new agent. The wizard builds the exact install and enrollment command for the operating system, architecture and server address you pick.

Set Server address to this instance's public IP or DNS name. Make sure your security group allows TCP 1514 and 1515 from the endpoint. The wizard then gives you a one-line command to run as root on the endpoint you want to monitor. For a Debian or Ubuntu host, it looks like this:

# Run this on the ENDPOINT you want to monitor, not on the Wazuh server. WAZUH_MANAGER='<public-ip>' dpkg -i ./wazuh-agent.deb systemctl daemon-reload && systemctl enable --now wazuh-agent

Before you start, confirm on the Wazuh server that the enrollment listener is up:

sudo ss -tlnp | grep -E ':(1514|1515) '

LISTEN 0 128 0.0.0.0:1514 0.0.0.0:* users:(("wazuh-remoted",...)) LISTEN 0 128 0.0.0.0:1515 0.0.0.0:* users:(("wazuh-authd",...))

New agents appear in the dashboard within a minute of enrolling, and their events start flowing into Threat Hunting immediately.

Threat intelligence and MITRE ATT&CK

The image ships Wazuh's MITRE ATT&CK integration. It maps alerts onto adversary tactics and techniques.

The full ATT&CK reference is available locally in the dashboard: threat groups, mitigations, software, tactics and techniques. You can pivot from an alert to the technique behind it without leaving the console.

Use the Wazuh server API

The Wazuh server exposes a REST API that the dashboard uses and that you can call yourself for automation. In this image it is deliberately bound to 127.0.0.1, so it is not reachable from the network unless you choose to publish it. Query it from the instance:

APW=$(sudo grep '^WAZUH_API_PASSWORD=' /root/wazuh-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -sk -u "wazuh:$APW" -X POST https://127.0.0.1:55000/security/user/authenticate | jq -r .data.token)
curl -sk -H "Authorization: Bearer $TOKEN" https://127.0.0.1:55000/manager/status | jq -r '.data.affected_items[0] | to_entries[] | "\(.key) \(.value)"' | head -12

wazuh-agentlessd stopped wazuh-analysisd running wazuh-authd running wazuh-csyslogd stopped wazuh-dbd stopped wazuh-monitord running wazuh-execd running wazuh-integratord stopped wazuh-logcollector running wazuh-maild stopped wazuh-remoted running wazuh-reportd stopped

The daemons that matter for collection and correlation are running. The daemons reported as stopped are optional integrations: syslog forwarding, mail alerting, third-party integrations and cluster mode. Enable them in /var/ossec/etc/ossec.conf if you need them.

To reach the API from your workstation without exposing it, tunnel over SSH rather than changing the bind address:

ssh -i my-key.pem -L 55000:127.0.0.1:55000 ubuntu@<public-ip>

If you need the API published, edit host in /var/ossec/api/configuration/api.yaml and restart wazuh-manager. Then open TCP 55000 only to the specific addresses that need it.

Where your data lives

Security event indices grow fast, and the Wazuh server's queue, alerts and archives grow alongside them. This image keeps both off the operating system disk. Each lives on its own volume that you can resize independently:

df -hT /var/lib/wazuh /var/ossec /
sudo grep -E 'wazuh|ossec' /etc/fstab

Filesystem Type Size Used Avail Use% Mounted on /dev/nvme0n1 ext4 79G 5.7M 75G 1% /var/lib/wazuh /dev/nvme2n1 ext4 40G 13G 25G 35% /var/ossec /dev/root ext4 48G 7.1G 41G 15% / UUID=ce1b8983-88c6-4c47-8206-cff448ddf911 /var/lib/wazuh ext4 defaults,nofail 0 2 UUID=85a04686-bafb-47ac-819f-96e9efb34bd2 /var/ossec ext4 defaults,nofail 0 2

The UUIDs above come from the instance this guide was verified against. Yours will differ.

The indexer writes its shards and its own logs under /var/lib/wazuh. The Wazuh server keeps everything under /var/ossec. Both fstab entries reference the filesystem UUID, so the layout survives a stop and start and any change in NVMe device naming.

To grow either volume, expand the EBS volume in the console, then run sudo resize2fs on the device. No reinstall or data movement is needed.

Confirm that the indexer is writing to the dedicated volume:

sudo grep -E '^path\.(data|logs):' /etc/wazuh-indexer/opensearch.yml
sudo du -sh /var/lib/wazuh/indexer-data

path.data: /var/lib/wazuh/indexer-data path.logs: /var/lib/wazuh/indexer-logs 5.6M /var/lib/wazuh/indexer-data

Sizing. Wazuh's own guidance for an all-in-one deployment is 2 vCPU and 4 GiB for up to 25 agents, so m5.large is the recommended starting point. Move to m5.xlarge or larger if you pass roughly 25 agents, or if you archive every event rather than only alerts. In that case, also raise the indexer heap in /etc/wazuh-indexer/jvm.options to about half the instance memory.

The index lifecycle policy in the dashboard, under Index Management, governs retention.

Certificates are unique to your instance

The Wazuh components authenticate to each other with TLS client certificates, and the indexer treats its admin certificate as a superuser credential. A baked-in certificate chain would be a shared secret across every deployment of the image, so this appliance does not ship one.

wazuh-certs-firstboot.service creates a new root certificate authority and a new certificate for each component before the Wazuh services start. The root private key is generated in memory and never written to disk. Inspect the certificate:

sudo openssl x509 -noout -subject -issuer -dates -in /etc/wazuh-indexer/certs/root-ca.pem

subject=OU = Wazuh, O = Wazuh, L = California issuer=OU = Wazuh, O = Wazuh, L = California notBefore=Jul 25 23:44:07 2026 GMT notAfter=Jul 22 23:44:07 2036 GMT

The notBefore date is the moment your instance first booted, not the date the image was built. That date confirms that the chain is yours.

Put your own certificate in front of the dashboard

The dashboard's own certificate is self-signed. That is fine for an internal console, but it produces a browser warning. For a public or shared deployment, terminate TLS with a certificate your users already trust.

The simplest route on AWS is an Application Load Balancer with an AWS Certificate Manager certificate. Forward to the instance on TCP 443, and use http://<instance-private-ip>/health as the target group health check.

Alternatively, replace the dashboard's certificate in place. Put your certificate and key at /etc/wazuh-dashboard/certs/wazuh-dashboard.pem and /etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem. Keep the ownership and 0400 permissions the existing files have, then restart wazuh-dashboard. Leave the indexer and server certificates alone, because they form the internal chain from Step 12.

Keep the appliance current

The operating system is fully patched at build and has unattended security upgrades enabled, so OS security fixes apply automatically.

You upgrade Wazuh itself on your own schedule, following the project's documented upgrade path for the version you are moving to. Upgrade the indexer first, then the server, then the dashboard. Take an EBS snapshot of both data volumes before you begin.

Check what you are running:

dpkg-query -W -f='${Package} ${Version}\n' wazuh-manager wazuh-indexer wazuh-dashboard filebeat

wazuh-manager 4.14.6-1 wazuh-indexer 4.14.6-1 wazuh-dashboard 4.14.6-1 filebeat 7.10.2-2

Troubleshooting

The dashboard will not load. Wait a minute after first boot, because the indexer has to be up before the dashboard serves. Run sudo systemctl status wazuh-dashboard and sudo journalctl -u wazuh-dashboard -n 50 to see what it is waiting for.

First boot did not finish. /var/lib/sac/data/wazuh-firstboot.done is created only after every credential has been rotated and verified. If the file is missing, run sudo journalctl -u wazuh-certs-firstboot -u wazuh-firstboot --no-pager to see which step failed.

An agent will not enroll. Check that TCP 1515 is reachable from the endpoint and that the endpoint uses this instance's address as its manager. On the server, sudo tail -n 50 /var/ossec/logs/ossec.log shows enrollment attempts as they arrive.

The indexer will not start after resizing. Confirm that both volumes are mounted with df -hT /var/lib/wazuh /var/ossec. The nofail fstab option deliberately lets the instance boot without them, so you can fix the mount instead of losing SSH access.

Support

SecureAnyCloud provides 24/7 technical support for this image. Support covers deployment, agent enrollment, rule and decoder tuning, storage sizing and retention, upgrades, and putting your own certificate in front of the dashboard. Email sales@secureanycloud.com with your instance ID and a description of the issue.

Wazuh is a trademark of Wazuh Inc. Wazuh is distributed under the GNU General Public License version 2. All product and company names are trademarks or registered trademarks of their respective holders.

Deploy on AWS

Launch Wazuh SIEM with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS