OpenCanary

Option A: Azure Portal

Search the Marketplace for OpenCanary Honeypot on Ubuntu 24.04. Choose your VM size and provide your SSH public key. Attach a network security group (NSG) that allows:

• TCP 22 (your real admin SSH) from your management network only.
• TCP 21, 23, 80, 2222 and 3306 (the decoys) from the networks you want to expose the sensor to. To collect real internet reconnaissance, allow these ports from the internet. To run an internal deception sensor, allow them only from the internal ranges you are monitoring.

Option B: Azure CLI

RG="opencanary-prod"; LOCATION="eastus"; VM_NAME="opencanary-01" IMAGE_URN="sac1647283583153:opencanary-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name oc-vnet --address-prefix 10.90.0.0/16 --subnet-name oc-subnet --subnet-prefix 10.90.1.0/24 az network nsg create -g "$RG" --name oc-nsg az network nsg rule create -g "$RG" --nsg-name oc-nsg --name allow-admin-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name oc-nsg --name allow-decoys --priority 110 \
  --source-address-prefixes "Internet" --destination-port-ranges 21 23 80 2222 3306 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:opencanary-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name oc-vnet --subnet oc-subnet --nsg oc-nsg --public-ip-sku Standard

Connect on the real admin port 22 with your key. This is the admin plane, kept completely separate from the decoys.

ssh azureuser@<vm-ip>

To find the public IP, run az vm show -d -g opencanary-prod -n opencanary-01 --query publicIps -o tsv.

OpenCanary runs as a systemd service. Confirm that it is active, that the decoys are listening, and that your real SSH stays on port 22.

sudo systemctl start opencanary 2>/dev/null || true sleep 2
sudo systemctl is-active opencanary ss -tln | grep -E ':21 |:23 |:80 |:2222 |:3306 |:22 ' || true /opt/opencanary/opencanary-env/bin/python -c 'import importlib.metadata as m; print("opencanary", m.version("opencanary"))' echo "opencanary verified"

The output shows:

• opencanary reporting active
• Listening sockets for the decoys on 0.0.0.0:21, :23, :80, :2222 and :3306
• Your real admin SSH on 0.0.0.0:22
• The OpenCanary version

The first-boot service wrote a root-only note that describes the two planes, this VM's unique alert node ID and the decoy endpoints. Read it with sudo:

sudo cat /root/opencanary-info.txt

The note is owned by root:root with mode 0600. It records the decoy endpoints, the per-VM alert node ID and the location of the alert log.

OpenCanary alerts on any touch of a decoy. Trigger the HTTP and FTP decoys locally to watch it detect the interaction and write a structured alert. The commands run against loopback on the VM itself, so no traffic leaves the VM. Real attackers who reach the decoys over the public IP produce the same alerts.

curl -s -m 10 -o /dev/null --user admin:admin "ftp://127.0.0.1:21/" || true
curl -s -m 10 -o /dev/null "http://127.0.0.1:80/index.html" || true sleep 2
sudo tail -n 5 /var/log/opencanary/opencanary.log | jq -c '{logtype, dst_port, src_host, logdata}' echo "decoy interaction detected and logged"

Each line is a structured alert. You see two entries:

• The FTP login attempt (dst_port 21), capturing the username and password that were tried.
• The HTTP request (dst_port 80), recording the path and user agent.

The decoys are emulated, so none of this touched a real service.

Every decoy interaction is written to the structured JSON alert log. List the most recent alerts to see what OpenCanary captured.

sudo tail -n 12 /var/log/opencanary/opencanary.log | jq -c '{utc_time, logtype, dst_port, src_host, logdata}' echo "alerts read"

Each alert carries a logtype, the decoy port that was touched (dst_port), the source host, and the details in logdata. For the FTP, Telnet, MySQL and SSH decoys, logdata includes the credentials that were tried. This is the intelligence you forward to your monitoring pipeline.

The JSON alert log at /var/log/opencanary/opencanary.log is designed to be shipped to a log pipeline. Point Filebeat, Fluent Bit, Vector or rsyslog at that file to forward alerts to Elasticsearch, Splunk, a Graylog input or any SIEM.

OpenCanary can also send alerts directly to email, a webhook, syslog or hpfeeds. Add a handler to the logger block in the configuration, then restart the service.

# Edit the logger.kwargs.handlers block in the config to add an email, webhook or syslog sink:
sudo nano /etc/opencanaryd/opencanary.conf
sudo systemctl restart opencanary

The OpenCanary documentation lists the available handlers (SMTP for email, a generic Webhook handler, Slack, syslog and hpfeeds) and the fields each one needs.