Deploy Wazuh on Azure RHEL

Deploy Wazuh on Azure RHEL VMs with DNS and restricted network access.

Introduction

30 Second Summary

A routine system change becomes stressful when nobody has rehearsed how to undo it. A silent machine can leave you guessing where the problem lives.

In this project, you will deploy two Red Hat Enterprise Linux 9 virtual machines in Microsoft Azure, create separate XFS filesystems for /var/log and /var/tmp, and install Wazuh across both hosts. You will publish the dashboard at wazuh.cloudseam.tech and restrict access with Azure network security rules.

What You'll Build

Open https://wazuh.cloudseam.tech to sign in to your finished Wazuh dashboard. You will see the Azure-hosted endpoint report as Active on the manager.

By the end of this project, you'll have:

A two-VM Azure lab where the manager and endpoint communicate through vnet-westus3-1.
Separate /var/log and /var/tmp filesystems on both RHEL VMs, created with XFS through the RHEL web console.
A restricted Wazuh dashboard that accepts HTTPS traffic only from your public IP address.
Secret Mission: Close the temporary enrollment rule after registration and confirm that ongoing agent communication still works.

What Already Exists?

The project uses the existing foreman-lab-rg resource group, vnet-westus3-1 virtual network, snet-westus3 subnet, and cloudseam.tech DNS zone. The subnet address range is 172.16.10.0/24.

Azure initially assigns each VM a dynamic private address. In Step 2, you will change each NIC to static allocation and assign 172.16.10.10 to the manager and 172.16.10.11 to the endpoint.

Before We Start

Before We Start...

Before any hands-on work begins, lock in the Azure resources you are about to create and the access boundary around them. This keeps the deployment focused on a two-VM Wazuh lab inside your existing network.

Set Up Your Windows Transfer Tools

Review the Azure Foundation

Your Azure network and DNS zone already exist, so this step checks the foundation before any paid virtual machines are created. A quick review prevents a VM from landing in the wrong subscription, region, or subnet.

You will confirm the Microsoft Azure resource group, virtual network, subnet, and DNS zone. The foreman-lab-rg resource group stores its metadata in East US, while the lab resources remain in West US 3.

In this step, get ready to:

Confirm the existing Azure resource group and network.
Confirm the existing DNS zone.
Review the resources that create ongoing charges.

Confirm the existing network

Open the Azure portal in your browser.
Enter foreman-lab-rg in the search bar at the top of the portal.
Select the foreman-lab-rg resource group from the results.
Confirm the resource group location is East US.
Select vnet-westus3-1 from the resource list.
Confirm the virtual network location is West US 3.
Select Subnets under Settings.
Confirm snet-westus3-1 appears in the subnet table.

You should see the existing subnet inside vnet-westus3-1. This confirms both VMs can join the same private Azure network.

Confirm the DNS zone

Enter cloudseam.tech in the portal search bar.
Select the DNS zone named cloudseam.tech.
Confirm the zone overview shows an active Azure resource.

Know What Creates Charges

The RHEL virtual machines, managed disks, and public IP addresses create charges while they exist. The final cleanup section removes those project-specific resources while leaving foreman-lab-rg, vnet-westus3-1, snet-westus3-1, and cloudseam.tech in place.

Your Azure foundation is ready. Next, you will create the manager and endpoint VMs inside the existing subnet.

Build and Secure the RHEL VMs

Create the Azure RHEL VMs

Your existing Azure network is ready. You can now place a Wazuh manager and a monitored endpoint inside the same subnet.

The manager needs more compute because it runs the Wazuh server, indexer, and dashboard. The endpoint only runs the agent that reports security data.

In this step, get ready to:

Create the manager and endpoint VMs with dedicated data disks.
Lock both private addresses to the planned values.
Connect to both RHEL systems and confirm their storage.

Plan the Private Addresses

The 172.16.10.0/24 subnet reserves its first four addresses and its final address. The planned addresses below remain available for your two lab VMs.

172.16.10.10 identifies the Wazuh manager.
172.16.10.11 identifies the monitored endpoint.

Create the manager VM

Open the foreman-lab-rg resource group in the Azure portal.
Click Create in the resource group toolbar.
Select Azure virtual machine.
Enter rhel-wazuh-manager in the Virtual machine name field.
Select West US 3 in the Region field.
Select a Red Hat Enterprise Linux 9 x86_64 image in the Image field.
Select an available size with at least 4 vCPUs and 8 GiB of memory.
Select SSH public key for the authentication type.

Protect the SSH Key

Azure can create a new key pair during deployment. The browser downloads the private key once, so save it somewhere you can find again and never upload it to this project.

Enter rexuser in the Username field.
Select Generate new key pair as the SSH public key source.
Enter rhel-wazuh-lab-key as the key pair name.
Allow SSH (22) in Public inbound ports for initial administration.
Open the Disks tab.
Set the OS disk size to at least 50 GiB.
Select Create and attach a new disk under Data disks.
Enter rhel-wazuh-manager-data in the Disk name field.

The manager now has an empty data disk reserved for its log and temporary filesystems.

Select the Standard SSD option in the Storage type field.
Enter 32 in the Size (GiB) field.
Open the Networking tab.
Select vnet-westus3-1 in the Virtual network field.

Select snet-westus3 in the Subnet field.
Open the Review + create tab.
Click Create after validation passes.
Click Download private key and create resource when Azure prompts you.

Expect the deployment to take several minutes while Azure creates the VM, disk, network interface, network security group, and public IP address.

Changing the private address restarts the VM so Azure can apply the new NIC configuration. Your disk and VM settings remain intact during this restart.

Open rhel-wazuh-manager in the Azure portal.
Select Network settings under Networking.
Select the network interface name beside Network interface.
Select IP configurations under Settings.
Select ipconfig1.
Select Static under Assignment.
Enter 172.16.10.10 in the IP address field.
Click Save.

Wait for Azure to restart the manager. You should then see 172.16.10.10 beside its private IP address.

Record the downloaded key location as path to your downloaded private key.

Create the endpoint VM

Return to the foreman-lab-rg resource group.
Click Create in the resource group toolbar.
Select Azure virtual machine.
Enter rhel-wazuh-endpoint in the Virtual machine name field.
Select West US 3 in the Region field.
Select the same Red Hat Enterprise Linux 9 x86_64 image.
Select an available size with at least 2 vCPUs and 4 GiB of memory.
Select SSH public key for the authentication type.

Reuse the Public Key

The endpoint can use the public key from rhel-wazuh-lab-key. Reusing the public key keeps administration simple without exposing the private key.

Enter rexuser in the Username field.
Select Use existing key stored in Azure as the SSH public key source.
Select rhel-wazuh-lab-key.
Allow SSH (22) in Public inbound ports.
Set the OS disk size to at least 30 GiB on the Disks tab.
Select Create and attach a new disk under Data disks.
Enter rhel-wazuh-endpoint-data in the Disk name field.
Enter 32 in the Size (GiB) field.

The endpoint uses the same storage layout as the manager, which makes both systems easier to audit.

Select the Standard SSD option in the Storage type field.
Open the Networking tab.
Select vnet-westus3-1 in the Virtual network field.
Select snet-westus3 in the Subnet field.
Click Review + create.

Click Create after validation passes.

Expect the endpoint deployment to take several minutes. Once it finishes, assign its planned private address through the NIC.

Open rhel-wazuh-endpoint in the Azure portal.
Select Network settings under Networking.
Select the network interface name beside Network interface.
Select IP configurations under Settings.
Select ipconfig1.
Select Static under Assignment.
Enter 172.16.10.11 in the IP address field.
Click Save.

Azure restarts the endpoint to apply the change. You should then see 172.16.10.11 beside its private IP address.

Record addresses and verify SSH

Open rhel-wazuh-manager from the resource group.
Confirm its private address is 172.16.10.10.
Record its public address as manager public IP address.
Open rhel-wazuh-endpoint from the resource group.
Confirm its private address is 172.16.10.11.
Record its public address as endpoint public IP address.

Restrict SSH Before Connecting

Open each VM's Networking settings page. Edit the SSH rule so its source is My IP address instead of Any.

Keep port 22 open only while you administer the lab. This narrows SSH exposure to your current public address.

Before you connect, do you expect each VM to show its OS disk and a separate unmounted 32 GiB data disk?

macOS

Open Terminal through Spotlight search.
Restrict the downloaded private key permissions by running:

chmod 600 "[[SSH_KEY_PATH="path to your downloaded private key"]]"

Connect to the manager and check its release and addresses by running:

ssh -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" rexuser@[[MANAGER_PUBLIC_IP="manager public IP address"]] "cat /etc/redhat-release; hostname -I; lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS"

Connect to the endpoint and check its release and addresses by running:

ssh -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" rexuser@[[ENDPOINT_PUBLIC_IP="endpoint public IP address"]] "cat /etc/redhat-release; hostname -I; lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS"

Windows

Open Windows PowerShell through Windows search.
Connect to the manager and check its release and addresses by running:

ssh -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" rexuser@[[MANAGER_PUBLIC_IP="manager public IP address"]] "cat /etc/redhat-release; hostname -I; lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS"

Connect to the endpoint and check its release and addresses by running:

ssh -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" rexuser@[[ENDPOINT_PUBLIC_IP="endpoint public IP address"]] "cat /etc/redhat-release; hostname -I; lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS"

You should see a RHEL 9 release string and the planned private address from each VM. Each storage table should also include an unmounted 32G disk, which confirms the dedicated data disk is ready for partitioning.

Cannot Connect Over SSH?

Confirm the VM is running and the SSH NSG rule uses your current public IP address. If your ISP changed your address, update My IP address in the rule before retrying.

Help me troubleshoot Azure SSH access.

Both RHEL VMs now keep their planned private addresses inside snet-westus3, and each has an unformatted 32 GiB data disk. Next, you will divide those disks into separate filesystems for logs and temporary data before Wazuh writes to them.

Create Separate RHEL Filesystems

Both Red Hat Enterprise Linux VMs are reachable, and each has an empty 32 GiB Microsoft Azure data disk. You can now separate high-churn logs and temporary files from the operating system disk.

You will create dedicated XFS filesystems before Wazuh writes data to either host. This gives both VMs the same storage boundary and leaves room for future growth.

In this step, get ready to:

Prepare secure access to the RHEL web console on both VMs.
Create separate filesystems for /var/log and /var/tmp.
Migrate the existing data and verify both mounts after a reboot.

Prepare the RHEL web consoles

The RHEL web console uses Cockpit to manage storage in a browser. An SSH tunnel carries that browser traffic through port 22, so TCP 9090 stays closed in Azure and firewalld.

Connect to the manager from your local terminal by running:

ssh -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" rexuser@[[MANAGER_PUBLIC_IP="manager public IP address"]]

Install the web console, its storage extension, and rsync by running:

sudo dnf install -y cockpit cockpit-storaged rsync
sudo systemctl enable --now cockpit.socket
sudo systemctl is-active cockpit.socket

What Does This Setup Do?

cockpit provides the browser interface.
cockpit-storaged adds the Storage page.
cockpit.socket listens when the web console needs a connection.

You should see active after the packages finish installing.

Web Console Setup Failed?

Confirm the VM can reach its configured Red Hat repositories. Then retry the installation after resolving any repository or DNS error.

Help me troubleshoot the web console setup.

Set a local password for rexuser by running:

sudo passwd rexuser

The command asks for the new password twice. Choose a lab-only password, keep it in your password manager, and do not enter it anywhere in this project.

Leave the manager session by running:

exit

Connect to the endpoint from your local terminal by running:

ssh -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" rexuser@[[ENDPOINT_PUBLIC_IP="endpoint public IP address"]]

Install the same packages and start the web console by running:

sudo dnf install -y cockpit cockpit-storaged rsync
sudo systemctl enable --now cockpit.socket
sudo systemctl is-active cockpit.socket

You should see active on the endpoint too.

Set a local password for rexuser by running:

sudo passwd rexuser

Leave the endpoint session by running:

exit

Each tunnel occupies its terminal until you stop it with Ctrl+C. Keep both tunnel windows open while you work in the two web consoles.

macOS

Open two Terminal windows through Spotlight search.
Start the manager tunnel in the first window by running:

ssh -N -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" -L 127.0.0.1:9090:127.0.0.1:9090 rexuser@[[MANAGER_PUBLIC_IP="manager public IP address"]]

Start the endpoint tunnel in the second window by running:

ssh -N -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" -L 127.0.0.1:9091:127.0.0.1:9090 rexuser@[[ENDPOINT_PUBLIC_IP="endpoint public IP address"]]

Windows

Open two Windows PowerShell windows through Windows search.
Start the manager tunnel in the first window by running:

ssh -N -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" -L 127.0.0.1:9090:127.0.0.1:9090 rexuser@[[MANAGER_PUBLIC_IP="manager public IP address"]]

Start the endpoint tunnel in the second window by running:

ssh -N -i "[[SSH_KEY_PATH="path to your downloaded private key"]]" -L 127.0.0.1:9091:127.0.0.1:9090 rexuser@[[ENDPOINT_PUBLIC_IP="endpoint public IP address"]]

Open https://localhost:9090 in one browser tab for the manager.
Continue past the self-signed certificate warning for this lab.
Sign in as rexuser with the local password you created.
Click Limited access in the top panel and enter the same password to gain administrative access.
Open https://localhost:9091 in a second browser tab for the endpoint.
Repeat the certificate, sign-in, and administrative-access steps for the endpoint.

Both browser tabs should show the RHEL web console. Neither VM needs an Azure or firewalld rule for TCP 9090 because the tunnels terminate on each VM's loopback interface.

Web Console Does Not Load?

Confirm both SSH sessions remain open and cockpit.socket is active on the target VM. If a local port is already in use, stop the conflicting process before starting the tunnel again.

Help me troubleshoot the SSH tunnels.

Create the XFS partitions

The 32 GiB disk contains no data yet, so initializing it removes nothing you need. Take care to select the unformatted 32 GiB data disk instead of the operating system disk.

Start with the manager web console at localhost:9090.
Click Storage in the left navigation.
Select the unformatted 32 GiB disk in the storage table.
Open the three-dot menu on the disk page.
Select Create partition table.
Select GPT in the initialization dialog.
Leave the zero-overwrite option disabled because this is a new empty disk.
Click Initialize.

You should now see the disk represented as free space. The next partition reserves half of it for system logs.

Open the three-dot menu beside Free space.
Select Create partition.
Enter var_log in the filesystem name field.
Enter /mnt/new-var-log in the Mount point field.
Select XFS in the Type field.
Set the size to 16 GiB.
Select No encryption.
Click Create only.

The disk now shows a 16 GiB XFS partition named var_log and free space for the next partition.

Open the three-dot menu beside the remaining free space.
Select Create partition.
Enter var_tmp in the filesystem name field.
Enter /mnt/new-var-tmp in the Mount point field.
Select XFS in the Type field.
Set the size to 8 GiB.
Select No encryption.
Click Create only.

You should see both XFS partitions and roughly 8 GiB of unallocated space. That unused capacity gives you room to extend a filesystem later.

Repeat the complete partitioning sequence in the endpoint web console at localhost:9091.

What Does This Separation Prove?

This layout creates the requested filesystem separation on both VMs. Full STIG compliance requires additional mount options, permissions, auditing, and control validation beyond this storage change.

Migrate and verify the data

Copying the existing directories preserves the files RHEL already created. The rsync options below retain ownership, permissions, hard links, ACLs, extended attributes, and SELinux labels.

Reconnect to the manager over SSH.
Confirm the two labeled XFS partitions exist by running:

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS

You should see var_log on a 16 GiB partition and var_tmp on an 8 GiB partition.

Mount the new filesystems temporarily and copy the existing data by running:

sudo mkdir -p /mnt/new-var-log /mnt/new-var-tmp
sudo mount /dev/disk/by-label/var_log /mnt/new-var-log
sudo mount /dev/disk/by-label/var_tmp /mnt/new-var-tmp
sudo rsync -aAXH --numeric-ids /var/log/ /mnt/new-var-log/
sudo rsync -aAXH --numeric-ids /var/tmp/ /mnt/new-var-tmp/

What Does the Copy Preserve?

-a preserves the directory structure, ownership, permissions, and timestamps.
-A preserves access control lists.
-X preserves extended attributes, including SELinux labels.
-H preserves hard links.

Back up /etc/fstab and add UUID-based mount entries by running:

LOG_UUID=$(sudo blkid -s UUID -o value /dev/disk/by-label/var_log)
TMP_UUID=$(sudo blkid -s UUID -o value /dev/disk/by-label/var_tmp)
sudo cp /etc/fstab /etc/fstab.before-var-mounts
printf 'UUID=%s /var/log xfs defaults 0 0\n' "$LOG_UUID" | sudo tee -a /etc/fstab
printf 'UUID=%s /var/tmp xfs defaults 0 0\n' "$TMP_UUID" | sudo tee -a /etc/fstab
sudo systemctl daemon-reload
sudo findmnt --verify --verbose

The final command should report no parse errors. The backup at /etc/fstab.before-var-mounts gives you a recovery copy if a UUID was entered incorrectly.

Mount Configuration Has an Error?

Do not reboot if findmnt --verify reports an error. Restore the backup with sudo cp /etc/fstab.before-var-mounts /etc/fstab, then check that both labels and UUIDs exist.

Help me validate the mount configuration.

The reboot briefly closes your SSH connection. That is expected while RHEL switches /var/log and /var/tmp to the new filesystems.

Run one final synchronized copy and reboot the manager by running:

sudo rsync -aAXH --numeric-ids --delete /var/log/ /mnt/new-var-log/
sudo rsync -aAXH --numeric-ids --delete /var/tmp/ /mnt/new-var-tmp/
sudo reboot

Wait about two minutes for the manager to restart before reconnecting.

Reconnect to the manager and restore the expected SELinux contexts by running:

sudo restorecon -RF /var/log /var/tmp
findmnt --mountpoint /var/log
findmnt --mountpoint /var/tmp
df -hT /var/log /var/tmp

You should see separate XFS mounts for /var/log and /var/tmp. Their displayed sizes should be close to 16 GiB and 8 GiB.

Repeat the migration, UUID configuration, reboot, and verification sequence on the endpoint.

Both VMs now keep logs and temporary data on dedicated XFS filesystems. The manager is ready for Wazuh without placing its growing logs on the operating system filesystem.

Your storage boundaries are in place on both RHEL systems. Next, you will install the Wazuh manager so its logs land on the dedicated /var/log filesystem.

Create Restore Points and Transfer Files

Install and Publish Wazuh

Both RHEL VMs now use dedicated XFS filesystems for /var/log and /var/tmp. The manager is ready for the all-in-one Wazuh installation, with its growing logs separated from the operating system filesystem.

This step installs the server, indexer, and dashboard on one RHEL VM. It also maps wazuh.cloudseam.tech to the manager's public IP address.

In this step, get ready to:

Install the Wazuh central components.
Allow restricted HTTPS access to the manager.
Create the dashboard DNS record and sign in.

Install the Wazuh manager

Connect to rhel-wazuh-manager over SSH.
Download the official Wazuh 4.14 installer by running:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh

Confirm the installer exists by running:

ls -l wazuh-install.sh

You should see wazuh-install.sh in the output.

Installer Did Not Download?

Confirm the manager can reach packages.wazuh.com through the VNet's outbound path. If the file is empty, remove it and retry after outbound HTTPS works.

Help me troubleshoot the Wazuh download.

Before you start the installer, do you expect one command to create the server, indexer, and dashboard services?

Run the Wazuh all-in-one installation by running:

sudo bash ./wazuh-install.sh -a

The installation can take several minutes while RHEL downloads and configures the central components. Keep the SSH session open until the command prints the dashboard credentials.

What Does This Command Do?

-a installs the Wazuh server, indexer, and dashboard on this single manager.
The final output includes the dashboard URL and an administrator password.

Save the generated administrator password in your password manager.
Verify the Wazuh services by running:

sudo systemctl is-active wazuh-manager
sudo systemctl is-active wazuh-indexer
sudo systemctl is-active wazuh-dashboard

You should see active three times. That confirms the Wazuh central components are running.

A Wazuh Service Is Inactive?

Review the installer output for the first failed component. Confirm the manager still has outbound HTTPS and enough disk space before retrying.

Help me diagnose the Wazuh installation.

Allow restricted HTTPS access

Open rhel-wazuh-manager in the Azure portal.
Select Networking settings under Networking.
Click Create port rule in the inbound rules section.
Select Inbound port rule.
Select My IP address for the source.
Enter 443 in the Destination port ranges field.
Select TCP for the protocol.
Select Allow for the action.

Enter Allow-Wazuh-HTTPS-MyIP in the Name field.
Click Add.

The manager now accepts dashboard traffic on port 443 only from your current public IP address.

How Does My Windows PC Get Access?

Selecting My IP address adds the public IP address that your Windows machine uses for outbound internet traffic as the NSG source. Private addresses such as 192.168.x.x stay inside your local network.

A VPN changes the public IP address Azure sees. If you switch networks or your public IP address changes, update the NSG source before reconnecting.

Press the Windows key to open search.
Enter PowerShell in the search field.
Press Enter to open Windows PowerShell.
Test dashboard access on TCP 443 by running:

Test-NetConnection -ComputerName wazuh.cloudseam.tech -Port 443

You should see TcpTestSucceeded : True. This confirms your Windows machine can reach the dashboard through the Azure inbound rule.

TCP 443 Test Failed?

Confirm the HTTPS NSG rule uses your current public IP address as its source. If a VPN is active, Azure sees the VPN's public IP address.

Help me troubleshoot the Windows connection test.

Publish the dashboard hostname

Open the cloudseam.tech DNS zone in the Azure portal.
Click Record set.
Enter wazuh in the Name field.
Select A for the record type.
Keep the alias record option disabled.
Enter manager public IP address in the IPv4 address field.
Click Add.

DNS updates can take a few minutes to reach your resolver. A short delay here is normal.

Open https://wazuh.cloudseam.tech in your browser.
Continue past the self-signed certificate warning for this lab.
Sign in with the generated Wazuh administrator credentials.

You should see the Wazuh dashboard. That is your first end-to-end result through Azure DNS, the manager public IP, and the restricted HTTPS NSG rule.

Dashboard Does Not Open?

If the hostname does not resolve, wait a few minutes and confirm the wazuh A record contains the manager public IP address. Use the manager public IP address in your browser to separate a DNS issue from an HTTPS issue.

Confirm the TCP 443 inbound rule still uses the public IP address from your current Windows connection. A VPN or network change can change that address.

Help me troubleshoot dashboard access from Windows.

Your Wazuh manager is live at wazuh.cloudseam.tech. Next, you will install the endpoint agent and observe why its first check-in cannot cross the current Azure firewall boundary.

Install Wazuh and Observe the Blocked Agent

Install the Endpoint Agent

Your Wazuh manager is live behind Azure DNS and a restricted HTTPS rule. The endpoint can now receive the agent configuration that points back to the manager's private address.

The manager still has no inbound rules for agent enrollment or communication. You will install the agent first, then watch that network boundary stop its initial check-in.

In this step, get ready to:

Generate the RHEL agent deployment command.
Install and start the Wazuh agent.
Observe the blocked first check-in.

Generate the endpoint command

Open https://wazuh.cloudseam.tech in your browser.
Sign in with the Wazuh administrator account.
Open Agents management from the Wazuh menu.
Open the Summary page.
Click Deploy new agent.
Select Red Hat Enterprise Linux as the operating system.
Select x86_64 as the architecture.
Enter 172.16.10.10 as the server address.

Enter rhel-wazuh-endpoint as the agent name.
Copy the generated deployment command.

Why Use the Private Address?

The generated command configures the Wazuh package repository, installs the agent, and stores the manager address. Using the manager's private address keeps agent traffic inside vnet-westus3-1.

Install and start the agent

Connect to rhel-wazuh-endpoint over SSH.
Paste the generated deployment command into the endpoint terminal.
Press Enter to install the agent.

The package download can take a minute while RHEL retrieves the Wazuh agent and verifies its signature.

Enable and start the Wazuh agent by running:

sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent
sudo systemctl is-active wazuh-agent

You should see active. This proves the endpoint service is running locally.

Agent Service Is Inactive?

Confirm the generated command completed without a package error. Then run sudo systemctl status wazuh-agent and read the first failure shown in the service output.

Help me troubleshoot the agent service.

Observe the blocked check-in

Before you inspect the connection, do you think the endpoint can enroll while the manager NSG and RHEL firewall still block the agent ports?

Read the endpoint's connection state by running:

sudo grep ^status /var/ossec/var/run/wazuh-agentd.state

You should see a state other than status='connected'. The blocked result is intentional and proves Azure and RHEL controls still protect the manager's agent ports.

Confirm the manager cannot accept the enrollment connection from the endpoint by running:

timeout 5 bash -c '</dev/tcp/172.16.10.10/1515' && echo open || echo blocked

You should see blocked. That gives you a concrete network result to change in the next step.

Did You Get a Different Result?

A missing state file points to an installation or startup problem. An existing state file without connected confirms the intended network obstacle.

Help me diagnose the blocked agent.

The agent is installed, but Azure and RHEL still block its path to the manager. Next, you will open only the private Wazuh ports and watch the endpoint become active.

Open the Required Wazuh Ports

Connect the Endpoint to Wazuh

The endpoint agent is running, and its blocked connection proved the manager's current network boundary. You can now add a narrow private-network exception for Wazuh traffic.

TCP 1515 handles enrollment. TCP 1514 carries ongoing agent communication after enrollment.

In this step, get ready to:

Allow the Wazuh ports in the manager NSG.
Allow the same private path through RHEL firewalld.
Confirm the endpoint becomes active in Wazuh.

Create the Azure NSG rule

Open vnet-westus3-1 in the Azure portal.
Select Subnets under Settings.
Select snet-westus3.
Confirm its address range is 172.16.10.0/24.
Open rhel-wazuh-manager in the Azure portal.
Select Networking settings under Networking.
Click Create port rule in the inbound rules section.
Select Inbound port rule.

Select IP Addresses for the source.
Enter 172.16.10.0/24 in the source address field.
Enter 1514-1515 in the Destination port ranges field.
Select TCP for the protocol.
Select Allow for the action.
Enter 310 in the Priority field.
Enter Allow-Wazuh-Agent-Subnet in the Name field.
Click Add.

You should see the new inbound rule with the subnet address range and destination ports 1514-1515.

Open the RHEL firewall path

Connect to rhel-wazuh-manager over SSH.
Identify the active firewalld zone by running:

sudo firewall-cmd --get-active-zones

Record the zone assigned to the manager network interface as manager active firewalld zone.
Add source-restricted rules for Wazuh enrollment and communication by running:

sudo firewall-cmd --zone=[[ACTIVE_ZONE="manager active firewalld zone"]] --permanent --add-rich-rule='rule family="ipv4" source address="172.16.10.0/24" port port="1514" protocol="tcp" accept'
sudo firewall-cmd --zone=[[ACTIVE_ZONE="manager active firewalld zone"]] --permanent --add-rich-rule='rule family="ipv4" source address="172.16.10.0/24" port port="1515" protocol="tcp" accept'
sudo firewall-cmd --reload

What Do the Rich Rules Change?

The source address limits both rules to the existing Azure subnet.
1515/tcp allows initial agent enrollment.
1514/tcp allows ongoing agent traffic.

Verify the active firewall rules by running:

sudo firewall-cmd --zone=[[ACTIVE_ZONE="manager active firewalld zone"]] --list-rich-rules

You should see one TCP rule for 1514 and one for 1515. Both rules should show 172.16.10.0/24 as the source.

A Firewall Rule Is Missing?

Confirm the commands used the active zone and the subnet's exact CIDR notation. Repeat only the missing permanent rule before reloading firewalld.

Help me verify the RHEL firewall rules.

Confirm the endpoint check-in

Connect to rhel-wazuh-endpoint over SSH.
Confirm both manager ports are reachable by running:

timeout 5 bash -c '</dev/tcp/172.16.10.10/1515' && echo enrollment-open || echo enrollment-blocked
timeout 5 bash -c '</dev/tcp/172.16.10.10/1514' && echo communication-open || echo communication-blocked

You should see enrollment-open and communication-open.

Restart the endpoint agent by running:

sudo systemctl restart wazuh-agent

Before you check, do you expect the endpoint to complete enrollment now that the Azure and RHEL paths are open?

Read the endpoint connection state by running:

sudo grep ^status /var/ossec/var/run/wazuh-agentd.state

You should see status='connected' after the agent completes enrollment. That is the network change paying off.

Open https://wazuh.cloudseam.tech in your browser.
Open Agents management.
Open Summary.
Confirm rhel-wazuh-endpoint shows Active.

That is the full Azure Wazuh path working: private agent traffic reaches the manager while the public dashboard remains limited to your IP address.

Agent Still Disconnected?

Confirm the endpoint uses the manager's current private address. Then compare the Azure NSG source range with the RHEL firewalld source range.

Help me trace the failed check-in.

Secret mission

Close the Enrollment Path

Remove TCP 1515 from both Azure and RHEL after enrollment, then prove the endpoint stays Active through TCP 1514.

Clean Up Your Resources

Decide whether to keep the Azure lab running, deallocate its VMs for later use, or delete the project-specific resources. The existing resource group, VNet, subnet, and DNS zone remain in every option.

Cost warning

Running RHEL VMs continue to incur compute and licensing charges. Deallocated VMs stop compute charges, but managed disks and some network resources can still incur charges until deleted.

Resources you used:

Virtual machines: rhel-wazuh-manager and rhel-wazuh-endpoint.
VM storage: the two OS managed disks plus rhel-wazuh-manager-data and rhel-wazuh-endpoint-data.
VM networking: the two network interfaces, public IP addresses, and network security groups.
DNS record: the wazuh A record inside cloudseam.tech.

Keep everything running

No action is needed. Choose this if you are still using the Wazuh lab.

Keep the SSH and HTTPS NSG rules restricted to your current public IP address.
Keep the Wazuh agent rules restricted to 172.16.10.0/24.
Review Azure Cost Management while both RHEL VMs remain running.

Pause - I'll come back to this later

Deallocate both VMs to stop compute and RHEL usage charges while preserving their disks, NICs, static private addresses, NSG rules, and Wazuh configuration. Disk and network charges can continue.

Open rhel-wazuh-endpoint in the Azure portal.
Click Stop in the VM toolbar.
Confirm the stop action.
Wait until the VM status shows Stopped (deallocated).
Open rhel-wazuh-manager.
Click Stop.
Confirm the stop action.
Wait until the manager status shows Stopped (deallocated).

Delete - I don't want to use this again

Deleting these resources is permanent. This removes the two project VMs and their VM-specific dependencies while preserving the existing Azure foundation.

Open rhel-wazuh-endpoint in the Azure portal.
Click Delete in the VM toolbar.
Select the endpoint OS disk, network interface, public IP address, and rhel-wazuh-endpoint-data in the associated resources list.
Confirm the endpoint deletion.
Open rhel-wazuh-manager in the Azure portal.
Click Delete in the VM toolbar.
Select the manager OS disk, network interface, public IP address, and rhel-wazuh-manager-data in the associated resources list.
Confirm the manager deletion.

Return to the foreman-lab-rg resource group after both deletions finish.
Delete any remaining network security group created for rhel-wazuh-manager.
Delete any remaining network security group created for rhel-wazuh-endpoint.
Delete rhel-wazuh-manager-data if it remains in the resource group.
Delete rhel-wazuh-endpoint-data if it remains in the resource group.
Delete any remaining OS disk, network interface, or public IP whose name contains either VM name.
Open the cloudseam.tech DNS zone.
Select the wazuh A record and click Delete.
Confirm that foreman-lab-rg, vnet-westus3-1, snet-westus3, and cloudseam.tech still exist.

Nice Work!

Excellent work. Your Microsoft Azure lab now runs a Wazuh manager and a Red Hat Enterprise Linux 9 endpoint through controlled public and private network paths.

You've learned how to:

Create a two-VM Azure RHEL lab inside an existing VNet and subnet.
Build separate XFS filesystems for /var/log and /var/tmp on both VMs while preserving data and SELinux labels.
Publish and connect a restricted Wazuh deployment through DNS, NSG rules, and RHEL firewalld.
Secret Mission: Close TCP 1515 after enrollment while preserving ongoing communication through TCP 1514.

Ready to quiz yourself?