Attacker intelligence for a homelab honeypot. Huginn pulls the logs from your honeypot, keeps the history, shows everything about every attacker IP on its own page, and turns it into blocklists your firewalls can fetch.
See the live demo → (made-up data, read-only)
Built with Claude (AI) and run every day on my own honeypot — see How Huginn is made.
In Norse myth Huginn is one of Odin's ravens. It flies out over the world every day and comes back to tell what it saw.
internet
│ port forwards (22, 23, 25, ...)
▼
┌───────────────────────────────┐ isolated VLAN, no route to your LAN
│ Honeypot │
│ Cowrie (fake SSH/Telnet) │
│ OpenCanary (fake FTP/HTTP/…) │
│ endlessh (tarpit) │
│ hp-traps (fake mail/DB/proxy)│
│ hp-export ◄─────────────────┼──┐ SSH, key locked to one read-only command
└───────────────────────────────┘ │ (Huginn pulls; the honeypot never connects out)
│
┌───────────────────────────────┐ │
│ Huginn (your LAN) │──┘
│ SQLite history, web UI, │
│ blocklist feeds, ntfy alerts │──► firewalls fetch /feed/<token>/…
└───────────────────────────────┘
⚠️ Read this before you open any ports
A honeypot invites attacks on purpose. Port forwarding from the internet into your home network is not something to try just to see what happens. Done wrong, you give strangers a way into the network your family's laptops, phones, NAS and cameras live on. If you are not sure what the steps below mean, stop here and read up first.
Only open ports when all of this is true:
How to isolate the honeypot
Getting the port forward right in your router only controls what comes in. Isolation is about what a successful attacker can reach from the honeypot. Pick one of these:
| How | Verdict |
|---|
| 1. Own VLAN | Put the honeypot on its own VLAN (UniFi, OPNsense, pfSense, MikroTik, most managed switches). Add firewall rules: honeypot VLAN → LAN/other VLANs and the router itself = block, LAN → honeypot = allow only Huginn to the admin port. | Best. The network itself keeps it apart. |
| 2. Hypervisor firewall | No VLAN-capable gear? Keep the honeypot on your normal network, but block it from your LAN with the firewall of the host it runs on (Proxmox example below). Rules inside the honeypot itself do not count: an attacker with root just turns them off. | Acceptable. It is still on your LAN segment, so get the rules right and test them. |
| 3. Nothing | Honeypot on the same network as everything else, only a port forward. | Don't. One escape from the fake shell and the attacker is inside your home network. |
Test it from the honeypot with tools/check-isolation.sh, giving it a few machines from your LAN. It also checks the router itself, which is the most common gap:
cd Huginn && ./tools/check-isolation.sh 192.168.1.10 192.168.1.20:445 192.168.1.30:8006
UniFi (learned on our own honeypot).
- "Isolate Network" is not enough. It blocks the other VLANs, but the honeypot can still reach the gateway itself on all its addresses: its SSH (port 22) answered from the honeypot. Add a firewall policy with the honeypot network as source, the Gateway zone as destination and action Block, placed before the default "allow to Gateway" policy. Allow DNS (port 53) first only if you want the honeypot to resolve names. It does not need to, and the router's DNS may hand out your internal host names.
- Give the honeypot a static IP address in its own network settings (in Proxmox: the container's network device, Static). DHCP also goes to the gateway, so once that is blocked the lease cannot be renewed and the honeypot drops off the network. A "Fixed IP" in UniFi is still DHCP.
- Exclude the honeypot from Threat Management (IPS), or it silently drops the attacks. See Router security features can hide the attacks.
- Run
tools/check-isolation.sh again after every change.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
