Back to blog
FILE 0x7D·SKETCHING A ONE-CLICK HONEYPOT INSTALLER

Sketching a one-click honeypot installer

Back to blog
FILE 0x7D·SKETCHING A ONE-CLICK HONEYPOT INSTALLER
Back to blog
FILE 0x7D·SKETCHING A ONE-CLICK HONEYPOT INSTALLER
April 26, 2026 · security, honeypots, homelab

Honeypots are useful and almost nobody runs them, because the existing stacks are either too heavy (multi-container threat-intel platforms that need 16 GB of RAM) or too DIY (raw Cowrie, configure your own notifications, hope you remember to look at the logs).

So I've been sketching out a one-click installer that targets the boring middle: a Raspberry Pi or small VPS, a believable persona banner, sane notifications, no ELK.

Existing options I looked at

  • T-Pot — full multi-honeypot stack with Suricata, Elastic, etc. Excellent if you're a security team. Wildly oversized for "I want my Pi to look like an old Synology and ping me when somebody pokes it."
  • Cowrie — SSH/Telnet only. Great at what it does but you have to layer notifications and dashboards on top yourself.
  • Dionaea — SMB/FTP/HTTP/MSSQL. Older, less actively maintained.
  • OpenCanary — lightweight Python, easy banner customization. Closest fit for the "appear as a specific thing" use case.
  • Honeyd — OS fingerprinting (so nmap -O thinks the box really is Windows Server 2008). Hard to configure cleanly. Useful for the advanced personas if I want to fool tools, not just scanners.

OpenCanary is the right base. T-Pot is the wrong scope. Cowrie is fine if I'm only ever pretending to be a Linux box.

The minimum viable product

Pi 4 or 5 with 4 GB or better. One installer script. Picks a persona, drops the right OpenCanary config, installs a notifier sidecar, sets a cron to keep things alive, registers webhook URLs.

Three personas to ship first:

  • Synology DSM. Web banner on 5000/5001 with the right HTML. SMB banner pretending to be DSM. Basically zero CPU cost.
  • Windows Server 2008-ish. SMBv1 + a fake RDP banner + IIS 6.0 HTTP banner + a fake MSSQL on 1433. Heaviest of the three but still trivial for a Pi.
  • Generic Linux. Bare SSH banner. Useful as a low-noise canary on internal networks where any auth attempt is suspicious.

The installer is a single bash script wrapping docker-compose and a ~150-line Python notifier sidecar. The notifier reads the OpenCanary log stream, dedupes per-source-IP for a configurable window, and fans events out to webhooks (ntfy, Pushover, Slack, Discord, or plain email — pick at install time).

The rate-limiting problem

Without dedup, a single nmap scan against the box will send 65,535 notifications. That's a great way to get the notifier muted.

Strategy: track first-touch per (source IP, port) tuple. If the same source hits the same port within N minutes, increment a counter on the existing alert instead of generating a new one. Summary line at the end of the window: "1 source hit 1,247 ports in 60 seconds — port scan."

For a single source hitting many ports rapidly, collapse to one "port scan from X" notification and skip per-port detail. For a single source touching a single port repeatedly (brute force), keep the per-event detail but cap rate at one notification per minute.

Tailscale or WireGuard for friend-deployment

The other piece I want: drop one of these on a friend's home network, hook them into my Tailscale, and have alerts come back to me. A honeypot on a residential ISP catches very different traffic than one on a VPS — mostly hands-off scanning.

The notifier already speaks webhooks. As long as the webhook endpoint is reachable from inside the Tailscale, this is free.

Persona scope I'm not shipping in v1

  • OS fingerprinting (kernel tweaks or Honeyd-style emulation). It's a real escalation in complexity and I don't have a use case for fooling nmap -O specifically. The banners are enough for the human-readable persona story.
  • A central dashboard for multi-instance management. Webhooks are enough for one or three honeypots. If I ever run a dozen, I'll revisit.

What I'd do differently if I were further in

This is still at the sketch stage — no real LOC committed yet — so the "differently" advice is about the planning, not the build. I'd write the notifier sidecar first, against a mock OpenCanary log stream, and ship that as a usable thing on its own. The notifier is the actual product value here; OpenCanary is just an event source. Anyone running Cowrie or any other honeypot would benefit from the notifier alone. That'd give me a tight feedback loop on the notification UX before I get into persona installer details.