The Fake ATM Strategy
Imagine you’re a bank manager and you’ve noticed someone’s been probing your vault door at 3 AM. So you install a fake ATM in the lobby—it looks real, works sorta, but it’s entirely disconnected from anything valuable. The first time someone touches it, you know exactly what time they arrived and what they tried to do. That’s a honeypot. It costs you almost nothing and gives you early warning that something’s wrong.
A honeypot is a decoy system that should never, ever be touched by legitimate traffic. It’s not your NAS. It’s not your Plex server. It’s a ghost machine with a believable name like “nas-backup” or “dev-server” or “monitoring-box” that sits on your network waiting. When anything connects to it—a scanner, a worm, a lateral-movement attack—you get an alert. Because nothing legitimate should ever be talking to a honeypot, any connection = intruder (or at least, something worth investigating).
OpenCanary is the easiest way to deploy honeypots in a home lab. It’s a lightweight Python application that emulates vulnerable services: SSH, FTP, HTTP, SMB, MySQL, Redis, and more. You spin it up in Docker, point it at a config file, and it starts listening. The moment something tries to log into the fake SSH server or accesses the fake web panel, you get notified via email, Slack, or syslog.
What OpenCanary Emulates
OpenCanary is not actually running SSH or a real web server. It’s impersonating them—responding to connection attempts and logging every probe, failed auth, port scan, or service enumeration attempt.
The most useful ones for a home lab:
- SSH — the #1 target. Any brute-force attempt, any unexpected key login, all logged.
- HTTP — fake admin panel. “Someone tried to access /admin on my decoy server at 2:47 AM.”
- SMB — windows file shares. If your honeypot is pretending to be a NAS and someone connects, that’s interesting.
- FTP — legacy but still probed by old attack tools.
- MySQL/Redis — database impostors, great for catching lateral movement attempts.
You pick which services to enable based on what your fake machine should “be.” A honeypot named “nas-backup” should emulate SMB and maybe SSH. A “monitoring-server” might emulate HTTP and SSH.
Deploying OpenCanary in Docker
Here’s the Docker Compose setup:
version: '3.8'
services: opencanary: image: thinkst/opencanary:latest container_name: opencanary restart: unless-stopped ports: - "22:8022" # SSH - "80:8080" # HTTP - "445:8445" # SMB - "3306:13306" # MySQL - "6379:16379" # Redis volumes: - ./opencanary.conf:/etc/opencanary/opencanary.conf networks: - homelab environment: - OPENCANARY_CONF=/etc/opencanary/opencanary.conf
networks: homelab: driver: bridgePort mappings: OpenCanary listens internally on high-numbered ports (8022 for SSH, 8080 for HTTP, etc.) and we map standard ports to them. From the network, it looks like a real SSH server on 22 and HTTP on 80.
Configuration: opencanary.conf
Here’s the JSON config that enables SSH, HTTP, and SMB with Slack notifications:
{ "logger": { "handlers": { "console": { "class": "logging.StreamHandler", "formatter": "standard" } } }, "device": { "device_name": "nas-backup", "listen_address": "0.0.0.0", "ignore_localhost": false, "ignore_ip_list": [] }, "listeners": [ { "port": 8022, "trigger": "connection", "protocol": "ssh", "banner": "SSH-2.0-OpenSSH_7.4" }, { "port": 8080, "trigger": "connection", "protocol": "http", "banner": "nginx/1.14.0" }, { "port": 8445, "trigger": "connection", "protocol": "smb" } ], "alerts": [ { "type": "webhook", "url": "https://hooks.slack.com/services/YOUR/WEBHOOK/URL", "method": "POST" } ], "services": { "ssh": { "enabled": true, "port": 8022, "banner": "SSH-2.0-OpenSSH_7.4" }, "http": { "enabled": true, "port": 8080, "banner": "nginx/1.14.0", "pages": [ { "path": "/admin", "status": "200", "response": "<html><body>Admin Panel</body></html>" } ] }, "smb": { "enabled": true, "port": 8445 } }}Replace YOUR/WEBHOOK/URL with your actual Slack webhook URL (grab it from Slack > Apps > Incoming Webhooks).
What Alerts Look Like
When something probes your honeypot, you get a Slack message like:
{ "event": "ssh_connection", "src_ip": "192.168.1.50", "src_port": 54321, "dst_port": 22, "timestamp": "2026-04-30T02:47:13Z", "device_name": "nas-backup", "message": "SSH connection attempt from 192.168.1.50"}If it’s your smart TV or Synology NAS poking port 22, you’ve got bigger problems than attackers. If it’s an unknown IP? Time to investigate.
Placement: The Quiet Corner of Your Network
Put your honeypot on a separate VLAN if you have one (even a guest VLAN works). Give it a name that fits your network topology but isn’t critical. The goal is: legitimate traffic never, ever reaches it. Period.
If you’re running Wazuh for centralized security monitoring (covered in earlier articles), point OpenCanary’s syslog output to your Wazuh server and correlate honeypot events with other security logs. When the honeypot triggers and your firewall logs unusual traffic from the same source, you’ve got your answer.
Canary Tokens: A Bonus Concept
If honeypot servers feel too heavy, there’s also the “canary token” concept: a special URL, Word document, PDF, or DNS record that phones home when accessed. Drop a Word doc named “Q1-Budget.docx” on your file share. If someone opens it, you get an alert. Same principle as honeypots, but lighter.
The Win
The real victory of a honeypot isn’t catching attackers (most home labs won’t). It’s peace of mind. You know, with absolute certainty, that if your honeypot alerts, something is wrong. No guessing, no log archaeology. A service that should never be touched just got touched.
Spin up OpenCanary this weekend. Name it something believable. Point it at Slack. Then sleep easy knowing you’ve got an early-warning system that actually works.
