Azure Ubuntu to an On-Prem Wazuh SIEM over Tailscale: Verified SSH Detection

Can an Ubuntu virtual machine running in Microsoft Azure send SSH security events to a Wazuh Manager hosted on a local VMware environment without exposing the SIEM to the public internet?

I wanted to validate this with a real end-to-end test, rather than relying only on service status or network connectivity checks.

The result: I successfully connected an Azure Ubuntu 24.04 VM to my on-premises Wazuh 4.14.8 Manager using Tailscale, generated a controlled SSH authentication failure, and verified that the corresponding alert reached Wazuh Dashboard.

This was an isolated, authorized laboratory experiment, not production security monitoring.

1. Lab Architecture

The environment consisted of:

• Cloud: Microsoft Azure, Ubuntu 24.04 LTS
• SIEM: Wazuh Manager 4.14.8 running locally on VMware
• Endpoint: Wazuh Agent 4.14.8
• Networking: Tailscale private VPN
• Log source: OpenSSH authentication events through systemd-journald
• Verification: Wazuh Dashboard / Threat Hunting

The event pipeline was:

Azure Ubuntu → OpenSSH → journald → Wazuh Agent → Tailscale → Local Wazuh Manager → SSH Decoder → Dashboard

Agent communication used TCP port 1514, while TCP 1515 was used for enrollment.

The Wazuh Manager was not exposed through public inbound SIEM rules.

2. Establishing Private Connectivity

I installed Tailscale on both the local Wazuh Manager and the Azure VM and connected them to the same private tailnet.

One interesting observation was that Tailscale traffic used a DERP relay instead of a direct peer-to-peer path.

This was sufficient for my low-volume test. It is not evidence of production-scale throughput or latency performance.

For initial Azure administration, I temporarily permitted SSH access from one specific public administrator IP through an Azure Network Security Group rule.

After validating private access, I removed that temporary rule.

3. Registering the Azure Wazuh Agent

I installed Wazuh Agent 4.14.8-1 on the Azure VM and configured it to communicate with the Manager through its Tailscale address.

The Manager confirmed:

Checking the service status alone was not enough. I also verified agent enrollment and communication from the Manager side.

Before connecting Azure, I had repaired a local Wazuh database socket issue and confirmed SSH detection using an existing local endpoint. This gave me a known-good detection baseline.

4. Generating a Controlled SSH Security Event

To validate the complete pipeline, I generated one intentionally invalid SSH login against the Azure VM's own loopback interface.

The test used a nonexistent username, rather than real credentials or external targets.

The resulting OpenSSH journal entry reached the on-premises Wazuh Manager.

Observed alert:

I verified the corresponding event in Wazuh Dashboard → Threat Hunting using:

agent.id: "002" AND rule.id: "5710"

The filtered results showed one matching alert and one authentication failure, with no successful authentication in that filtered sample.

Wazuh associated the event with MITRE ATT&CK classifications T1110.001 and T1021.004.

However, one controlled invalid-user event does not establish brute-force activity, lateral movement, or a real compromise.

That distinction matters when reporting security findings.

5. Validating the Security Boundaries

After the detection test, I performed additional checks.

First, I verified that private SSH access to the Azure VM continued to work through Tailscale.

Then I removed the temporary public SSH rule from the Azure NSG.

In the subsequent test, public TCP/22 was unreachable, while private SSH access remained available.

Finally, I deallocated the Azure VM and verified its power state.

Important cost consideration: Azure VM deallocation stops VM compute billing, but managed disks, public IP resources, and other retained services may still generate charges.

The Azure Wazuh Agent also stops sending events while the VM is deallocated.

6. The Next Challenge: Agent Disconnections

I shared this experiment in the r/Wazuh community and received useful technical feedback about agent connectivity.

A Wazuh Manager can identify when an agent stops sending keepalives, but that notification alone does not establish the cause.

For a cloud-to-on-premises deployment, several failures can produce a similar symptom:

• The Azure VM is stopped or deallocated.
• The Tailscale connection is unavailable.
• The Wazuh Agent service has stopped.
• Network communication between the agent and Manager is interrupted.

In a follow-up experiment, I plan to combine Wazuh's agent-disconnection events with external checks of VPN connectivity, service state, and Azure VM power state.

That investigation has not yet been completed and should not be confused with the SSH detection test documented here.

7. Engineering Lessons

This exercise reinforced several practical lessons.

1. Verify the complete event path.

An active service does not prove that security events are reaching the intended destination.

2. Keep monitoring infrastructure private.

A private overlay network allowed the Azure endpoint to communicate with the local SIEM without exposing the Manager to the public internet.

3. Separate evidence from interpretation.

A Wazuh rule classification is not automatically proof of a real attack.

4. Test recovery and disconnection scenarios separately.

Successful detection under normal conditions does not prove fault tolerance.

5. Treat cloud cost management as part of the runbook.

Temporary access rules and running cloud resources should be reviewed and cleaned up after testing.

Conclusion

I verified a complete security-event pipeline from Azure Ubuntu to an on-premises Wazuh Manager through Tailscale.

The experiment demonstrates agent enrollment, SSH telemetry collection, private networking, deterministic detection, dashboard verification, and responsible cloud cleanup.

It does not demonstrate continuous monitoring, automated remediation, production scalability, or root-cause diagnosis of agent disconnections.

Original technical article: Azure to On-Premises SIEM: SSH Detection with Wazuh and Tailscale

Community discussion: Azure Ubuntu → On-Prem Wazuh 4.14.8 over Tailscale on Reddit

Question for the community

If you're operating Wazuh agents across cloud and on-premises networks, how do you differentiate VPN outages, stopped instances, and Wazuh Agent failures?

Do you rely on Wazuh's built-in disconnection alerts, or have you implemented independent health checks?

Editorial disclosure: This DEV.to adaptation was prepared with AI writing assistance based on my original engineering article and documented laboratory observations. The technical claims reflect the recorded test results.