If you have a public IP address — and almost every business connected to the internet does — that IP is being constantly probed by automated scanners. Within hours of any new IPv4 address going online, it starts receiving:
The Defend-O-Tron's honeypot watches for these probes as traffic passes through the bridge, blocks the offender's IP, and shares the address with the CrowdSec community so the same actor is blocked everywhere they show up next. Your firewall sees less brute-force noise. The community gets a new bad actor on the blocklist. You see fewer alerts that need investigating.
The honeypot is a set of nftables rules on the Defend-O-Tron's ingress interface (the side connected to your ISP). It watches for inbound connection attempts on ports your network shouldn't be receiving traffic on. None of these ports are open on the Defend-O-Tron — these are ports the honeypot watches for inbound attempts to your network.
Because the Defend-O-Tron sits between your ISP and your firewall, the honeypot can see attempts that would otherwise hit your router directly. Catching them at the bridge means your firewall sees less of the noise, your logs stay cleaner, and the offending addresses get added to the global CrowdSec community blocklist so every other CrowdSec-equipped device benefits too.
The default port list is curated for accuracy and performance. Most bad actors probe these common ports first; if they get nothing, they either move on or get caught further upstream by the deep-packet IDS layer (Suricata + CrowdSec). Adding too many ports increases log noise without increasing real-world protection.
| Port(s) | Service | What it catches |
|---|---|---|
| 20-21 | FTP | Probes for misconfigured anonymous-FTP servers |
| 22 | SSH | The most-scanned port on the internet — brute-force and CVE scans |
| 23 | Telnet | IoT botnet recruitment (Mirai-family malware loves Telnet) |
| 25 | SMTP | Open-relay scanners and spam-abuse hunters |
| 445 | SMB | Windows file-sharing exploitation, ransomware reconnaissance |
| 1433-1434 | MSSQL | Microsoft SQL Server credential stuffing and CVE exploitation |
| 3128 | HTTP Proxy | Open-proxy hunters |
| 3306 | MySQL | Database brute-force and CVE exploitation |
| 3389 | RDP | Remote Desktop credential stuffing |
| 5985-5986 | WinRM | Windows Remote Management credential stuffing |
| 8291 | MikroTik Winbox | MikroTik router CVE exploitation |
| Port(s) | Service | What it catches |
|---|---|---|
| 69 | TFTP | IoT and embedded-device firmware-pulling exploits |
| 135-139 | NetBIOS | Legacy Windows networking probes |
| 161 | SNMP | Network-device enumeration |
ICMP is deliberately not in the honeypot list. Including it would interfere with Path MTU Discovery (PMTUD) and IPv6 neighbour discovery — protocols the internet quietly depends on. IPv6 addresses are still blocked if other defense scenarios flag them as bad actors.
A small set of public infrastructure addresses are never banned by the honeypot under any circumstance:
1.1.1.1, 1.0.0.1), Google DNS (8.8.8.8, 8.8.4.4), Quad9 (9.9.9.9).This protects against a misbehaving public DNS service accidentally triggering a ban that would break recursive name resolution for everyone behind the Defend-O-Tron.
The same offender showing up again later gets fresh decisions issued, so persistent attackers stay blocked for as long as they keep trying.
Even if your jump host is hardened (key-only authentication, fail2ban, etc.), the honeypot prevents the bulk of SSH scanners from ever reaching it. Bots that probe TCP 22 from the public internet get blocked at the bridge before they can touch your jump host's firewall — cleaner logs, less work for your local defenses.
If you run SMTP on standard TCP 25, remove port 25 from the honeypot port list before deployment — see Honeypot Internals for the file you edit. Legitimate inbound mail will otherwise be blocked. Better still: front your mail server with SMTPS (TCP 465) or submission (TCP 587), neither of which is in the honeypot list.
Internal Windows file sharing isn't affected — the honeypot only watches inbound from the internet, not local traffic. But if any SMB traffic from the public internet shows up at TCP 445, it's almost certainly ransomware reconnaissance and gets blocked immediately.
The honeypot protects internet-facing RDP servers from constant credential-stuffing attempts. Far better: front RDP with a VPN or a dedicated remote-access gateway so it isn't exposed to the public internet at all. If you must expose it, the honeypot makes the noise survivable.
TCP 8291 (Winbox) probes are a near-constant background on most public IPs. The honeypot catches them and shares the addresses with the community. This pairs especially well with the CrowdSec API MikroTik bouncer, which then enforces the same blocks at the router itself.
TFTP (UDP 69), NetBIOS (UDP 135-139), and SNMP (UDP 161) probes are common against IoT and industrial deployments. The honeypot catches the reconnaissance phase before it turns into compromise.
Most attack noise is filtered upstream before it reaches you, so honeypot activity will be quieter — but anything that does come through is high-signal. Worth keeping enabled even if the volume is low.
Real-world traffic occasionally trips honeypot rules. A scanner from your ISP's network monitoring, a customer behind shared NAT, a misconfigured legitimate service — all of these can produce false positives. Three ways to handle one:
The most durable fix when an address should never be banned: add it to the good-actors list. This is an edit to a configuration file and requires a reboot — see Honeypot Internals for the file path and format.
If you have a (free) CrowdSec community account attached to your device:
The unban propagates to your device within a couple of minutes.
Open Tools → Terminal in the admin interface and use cscli:
sudo cscli decisions list # see what's currently banned
sudo cscli decisions delete -i 1.2.3.4 # remove a single IP
sudo cscli decisions delete -r 1.2.3.0/24 # remove a subnet
sudo cscli decisions delete --id 42 # remove by decision ID
A good actor that gets unbanned without being whitelisted can be re-banned later if their traffic trips a scenario again. If you're seeing the same IP get banned repeatedly, either whitelist it (option 1) or investigate why their traffic looks bad in the first place.
Adjusting the port list, editing the CrowdSec parser, or modifying the bruteforce scenario is advanced work that can break your protection if done incorrectly. See the dedicated Honeypot Internals page for ACL file structure, NFT rule reference, CrowdSec parser/scenario YAML, and GROK pattern background.