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 |
Any port you forward through your firewall must be removed from this list. The honeypot cannot tell a customer from a scanner — it only knows that nothing behind the bridge should be answering on these ports. If you port-forward (DNAT) one of them, the first packet from every legitimate user produces honeypot evidence, and that user is banned from every service on your network, not just the one they connected to. Check this list against your firewall’s forwarding rules before deployment, and again each time you add a forward.
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.
Addresses on the trusted list are never banned, by the honeypot or by anything else. The device ships with a small set of public infrastructure already on it:
1.1.1.1, 1.0.0.1), Google DNS (8.8.8.8, 8.8.4.4), Quad9 (9.9.9.9), plus private address space (192.168.0.0/16).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.
A trusted address is accepted before any of the block, ban or honeypot checks run — so it is not merely “unbanned”, it is never examined in the first place and never produces evidence against itself. That is also the trade: while an address is listed, it is exempt from enforcement, and a prefix exempts its whole range. Add what you genuinely trust and no more.
There is one trusted list. Older documentation and older firmware described a second, honeypot-only exempt list (
banexempt4/banexempt6); it was folded into the main list because two lists meaning the same thing drifted apart — a host could be trusted by one and still reported by the other.
The same offender showing up again later gets fresh decisions issued, so persistent attackers stay blocked for as long as they keep trying.
If the jump host is reachable from the internet on TCP 22, remove port 22 from the honeypot list first. Otherwise your own users are banned on their first connection, in exactly the same way a scanner is — the honeypot sees a connection attempt to a port that should be unused and cannot tell the difference.
The better arrangement is to move the jump host to a non-standard port, or put it behind a VPN. Either leaves TCP 22 genuinely unused, so the honeypot keeps blocking the bulk of SSH scanners at the bridge before they reach your firewall, and your access path isn’t affected at all. Hardening the jump host (key-only authentication, fail2ban) is worth doing either way, but it does not change what the honeypot does with port 22.
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.
Put RDP behind a VPN or a dedicated remote-access gateway. That leaves TCP 3389 unused, which is what lets the honeypot block the constant credential-stuffing traffic aimed at it.
If you do forward TCP 3389, remove it from the honeypot list first — otherwise your own remote workers are banned the moment they connect.
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.
Some upstream equipment polls the addresses it routes to. NetBIOS (UDP 137) and SNMP (UDP 161) are the usual ones, and both are honeypot ports — so the honeypot reports the ISP’s own gateway, CrowdSec bans it, and traffic on the link can be disrupted.
It’s easy to recognise: the banned address is your ISP’s gateway, or sits inside your own assigned IP block; it appears steadily rather than in bursts; and it always targets your own hosts. Add it to the trusted list — that is precisely what the list is for. Removing the port from the honeypot would also stop the bans, but you’d lose that detection against everyone else.
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. Use Firewall ACLs in the admin interface: it applies the change immediately, without a reboot and without interrupting the bans already in force. The same lists can be edited as files on the device if you prefer — see Honeypot Internals for the paths, the format, and what a hand edit requires to take effect.
Do this rather than repeatedly unbanning: a trusted address never generates evidence again, whereas an unbanned one is re-banned the next time its traffic trips a scenario.
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
Unbanning an address does not stop it being banned again — the next scenario trip re-bans it. If the same address keeps coming back, either add it to the trusted list (option 1) or work out why its 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.