MikroTik Honeypot: Trap & Auto-Block Port Scanners

What is a honeypot?

A honeypot is a security mechanism that creates a decoy system designed to attract and detect attackers. According to Fortinet, honeypots are intentionally vulnerable systems that lure adversaries away from legitimate targets while gathering intelligence about their methods. NIST SP 800-53 includes honeypots as a formal security control (SC-26) for detecting and analyzing such attacks.

There are two main types of honeypots:

Info:

What We're Building

In this guide, we implement a low-interaction honeypot directly in the MikroTik firewall. We don’t run fake services—instead, we monitor connection attempts to ports that should never receive legitimate traffic from the internet. Any connection to these “trap ports” immediately identifies the source as a scanner.

This approach is lightweight, requires no additional hardware, and provides immediate protection while generating valuable logs.

Understanding TCP connection states

Before configuring our honeypot, it’s essential to understand how stateful firewalls like MikroTik classify network traffic. Every packet is assigned a connection state:

Why we only monitor “new” connections

Our honeypot rules specifically target connection-state=new. Here’s why this is critical:

RouterScannerRouterScannerHoneypot triggers here!Connection now "established"SYN (new connection)SYN-ACKACK

TCP Three-Way Handshake

1. Reconnaissance happens on new: Attackers send SYN packets to probe which ports are open. This is the first packet—the new state.
2. Established traffic is legitimate: Once a connection completes the handshake and becomes established, it was already approved by your firewall rules. Trapping established packets would create false positives.
3. Efficiency: By only examining the first packet of each connection, we minimize CPU overhead. The router doesn’t need to inspect every packet—just the initial probe.

Warning:

Never Trap Established Traffic

If your honeypot rules matched established connections, you would block legitimate return traffic from services you actually use. Always use connection-state=new.

The strategy: detect, log, and block

Our honeypot strategy has three phases:

Yes: RAW Table

No

No: Port 80/443

Yes: Port 22/3389/etc.

Internet Scanner

IP in Blacklist?

DROP instantly

Is port trapped?

Allow - Web Server

Honeypot Triggered

Log with prefix

Remote Syslog

Add IP to BlackList

Drop current packet (Filter)

Honeypot Detection Flow

Why use the RAW table for blocking?

We perform detection in the Filter table (Input chain), but we enforce blocking in the Raw table (Prerouting chain).

Tip:

Performance Advantage

The Raw table processes packets before Connection Tracking. By blocking attackers here, the router doesn’t allocate memory or CPU cycles to track their connections. On routers handling thousands of attacks daily, this can significantly reduce resource usage.

Trap port reference

The following tables list ports commonly targeted by attackers, based on the IANA Service Name and Port Number Registry. These are ideal candidates for honeypot traps because legitimate internet users should never need to access them on your router.

Important:

Customize for Your Environment

Before implementing, review which services you actually expose. If you run a public SSH server on port 22, don’t trap that port! The examples below assume you run web servers on ports 80/443 only.

TCP trap ports

UDP trap ports

UDP ports are particularly valuable for honeypots because many are exploited in amplification attacks—where attackers use your server to multiply attack traffic against third parties.

Step 1: create the whitelist

Before deploying any blocking rules, you must create a whitelist. This prevents accidentally blocking yourself, your VPN, monitoring systems, or legitimate services that need to access specific ports.

When to use a whitelist

Consider adding IPs to your whitelist for:

1. Your own public IPs — Home, office, or mobile hotspots you use for management
2. VPN endpoints — If you connect via a VPN with a static IP
3. Monitoring services — Uptime monitors, vulnerability scanners you control
4. Trusted partners — Security auditors, managed service providers
5. Known scanners you’ve approved — Security researchers you’ve whitelisted

Warning:

Test Before Blocking

Add your current IP to the whitelist before enabling any honeypot rules. If you lock yourself out, you’ll need physical access to the router to recover.

IPv4 whitelist

ROUTEROSCreating the IPv4 Whitelist

# Create the whitelist for IPv4

/ip firewall address-list

# Your local networks (never block these)

add list=WhiteList address=192.168.0.0/24 comment="LAN - Main Network"

add list=WhiteList address=192.168.99.0/24 comment="LAN - IoT Network"

add list=WhiteList address=192.168.100.0/24 comment="VPN - WireGuard Devices"

# Your static public IPs (management access)

add list=WhiteList address=203.0.113.50 comment="Office Static IP"

add list=WhiteList address=198.51.100.25 comment="Home Static IP"

# Monitoring and security services

add list=WhiteList address=192.0.2.10 comment="Uptime Monitor - Pingdom"

add list=WhiteList address=192.0.2.20 comment="Vulnerability Scanner"

IPv6 whitelist

ROUTEROSCreating the IPv6 Whitelist

# Create the whitelist for IPv6

/ipv6 firewall address-list

# Your local IPv6 networks

add list=WhiteList address=fd00::/8 comment="ULA - Private IPv6 Range"

add list=WhiteList address=2001:db8:1::/48 comment="Your Assigned IPv6 Prefix"

# Link-local addresses (never block)

add list=WhiteList address=fe80::/10 comment="Link-Local Addresses"

# Trusted external IPv6 addresses

add list=WhiteList address=2001:db8:2::100 comment="Office IPv6 Address"

Step 2: IPv4 honeypot configuration

This configuration includes all honeypot detection rules for IPv4, organized by service category. At the end of the Filter section, we add a DROP rule to immediately block any source that has been added to the blacklist before they can attempt other attacks in the same session.

Warning:

Customize for Your Setup

The rules below use in-interface-list=WAN to identify external traffic. If your router uses a different interface list name (e.g., internet, external, or a specific interface like ether1), update this value accordingly. Check your configuration with /interface list print.

honeypot-ipv4.rsc

Step 3: IPv6 honeypot configuration

IPv6 scanning is rapidly increasing as more networks adopt dual-stack configurations. The structure mirrors IPv4, using a separate address list for IPv6 scanners.

honeypot-ipv6.rsc

Understanding the configuration

Let’s examine the key parameters that make this honeypot effective:

Leveraging logs for threat intelligence

The log=yes parameter generates entries that can be forwarded to external security systems. By configuring MikroTik to send logs to a remote syslog server, you can:

1. Feed CrowdSec — Contribute detected attackers to the community blocklist and receive protection from attacks seen globally.
2. Report to AbuseIPDB — Share threat intelligence and help others block known malicious IPs.
3. Build dashboards — Visualize attack patterns, source countries, and targeted ports.

Warning:

Customize IP Addresses

Replace 192.168.0.100 with the IP address of your syslog server (the machine running CrowdSec), and 192.168.0.1 with your router’s LAN IP address.

ROUTEROSRemote Syslog Configuration

# Configure remote syslog destination

/system logging action set [find name=remote] remote=192.168.0.100 src-address=192.168.0.1

# Send firewall logs (including honeypot) to remote server

/system logging add action=remote topics=firewall prefix="[FIREWALL]"

Integrating with CrowdSec

Below is a working configuration to parse MikroTik honeypot logs with CrowdSec. This setup captures the [HONEYPOT TCP/UDP] prefixes we configured earlier and extracts attacker IPs for automatic blocking.

Step 1: receive logs via rsyslog

On your Linux server running CrowdSec, configure rsyslog to receive UDP syslog from MikroTik and write it to a dedicated file:

/​etc/​rsyslog.d/​10-mikrotik.conf

# Load UDP input module

module(load="imudp")

input(type="imudp" port="514")

# Write all UDP syslog to MikroTik log file

if ($inputname == "imudp") then {

   action(type="omfile" file="/var/log/mikrotik.log")

   stop

}

After creating this file, restart rsyslog:

sudo systemctl restart rsyslog

You can verify that logs are arriving by checking the file:

tail -f /var/log/mikrotik.log

2026-01-19T10:37:39.291+01:00 mikrotik firewall,info [FIREWALL]: [HONEYPOT TCP] input: in:PPPoE_DIGI out:(unknown 0), connection-state:new proto TCP (SYN), 167.94.138.144:33601->YOUR_WAN_IP:389, len 60

2026-01-19T10:38:50.781+01:00 mikrotik firewall,info [FIREWALL]: [HONEYPOT TCP] input: in:PPPoE_DIGI out:(unknown 0), connection-state:new proto TCP (SYN), 109.227.42.233:48036->YOUR_WAN_IP:23, len 60

2026-01-19T10:44:01.360+01:00 mikrotik firewall,info [FIREWALL]: [HONEYPOT TCP] input: in:PPPoE_DIGI out:(unknown 0), connection-state:new proto TCP (SYN), 102.156.174.56:61901->YOUR_WAN_IP:445, len 52

Step 2: configure CrowdSec acquisition

Tell CrowdSec to read the MikroTik log file. Create an acquisition file:

/​etc/​crowdsec/​acquis.d/​mikrotik.yaml

filenames:

 - /var/log/mikrotik.log

labels:

 type: mikrotik-logs

source: file

Step 3: install the MikroTik parser

Install the community MikroTik parser from CrowdSec Hub:

sudo cscli parsers install a1ad/mikrotik-logs

Step 4: custom parser for honeypot logs (optional)

For advanced parsing that specifically captures our [HONEYPOT TCP/UDP] prefixes, create a custom parser:

/​etc/​crowdsec/​parsers/​s01-parse/​mikrotik-honeypot.yaml

Step 5: reload CrowdSec

After adding the parser and acquisition config, reload CrowdSec:

sudo systemctl reload crowdsec

Verify the acquisition is working:

sudo cscli metrics

You should see /var/log/mikrotik.log in the acquisition sources with parsed lines increasing as honeypot events occur.

Real-world results

To give you an idea of what to expect, here are actual statistics from my home network over a 24-hour period—a MikroTik RB5009 behind a standard FTTH connection in Spain:

Attack Distribution by Port

1. Telnet (23)

535·42.1%

1. SSH (22)

216·17.0%

1. SMB (445)

172·13.5%

1. HTTP Alt (8080)

106·8.3%

1. RDP (3389)

80·6.3%

1. MSSQL (1433)

63·5.0%

1. HTTPS Alt (8443)

51·4.0%

1. MySQL (3306)

49·3.9%

Data collected from all time alerts on my home connection

Top Attacking Countries

1. United States (US)

484·44.1%

1. Netherlands (NL)

194·17.7%

1. China (CN)

127·11.6%

1. Brazil (BR)

81·7.4%

1. Russia (RU)

59·5.4%

1. Bulgaria (BG)

58·5.3%

1. Germany (DE)

50·4.6%

1. India (IN)

44·4.0%

Source countries of blocked IPs

Top Attacking Organizations (ASNs)

1. DigitalOcean

180·35.4%

1. Google Cloud

108·21.3%

1. Microsoft

83·16.3%

1. Hurricane Electric

80·15.7%

1. Chinanet

57·11.2%

Top 5 networks originating attacks

Success:

Every Scanner Blocked on First Attempt

Over 1,000 unique IPs were detected and blocked in the last 24 hours. Each was immediately added to the MikroTik blacklist and registered in CrowdSec. The RAW table rule ensures these scanners cannot probe any other services—their very first reconnaissance packet is their last.

Testing your honeypot

Before considering your honeypot production-ready, verify it works correctly:

Test procedure

1. Add your test IP to watch (optional):

ROUTEROSWatch honeypot logs

/log print follow where message~"HONEYPOT"

1. From an IP NOT on your whitelist (e.g., mobile data):
2. Try connecting to a trapped port: telnet YOUR_WAN_IP 23
3. Or attempt SSH: ssh root@YOUR_WAN_IP
4. Check the address list:

ROUTEROSCheck blacklisted IPs

/ip firewall address-list print where list~"BlackList"

Your test IP should appear with the timeout countdown.

1. Verify blocking works:
2. Try to ping the router from the same IP
3. It should timeout (the RAW rule drops all traffic)
4. Clean up (remove test IP):

ROUTEROSRemove test IP from blacklist

/ip firewall address-list remove [find address=YOUR_TEST_IP]

What’s next?

You now have a self-defending router that:

1. Detects reconnaissance attempts in real-time
2. Logs attacker IPs with structured prefixes
3. Blocks attackers at the earliest possible point (RAW table)
4. Protects both IPv4 and IPv6
5. Integrates with CrowdSec for community threat intelligence

Consider extending this setup by:

1. Reporting to AbuseIPDB — Share threat intelligence with the broader security community
2. Building Grafana dashboards — Visualize attack patterns, source countries, and targeted ports
3. Setting up alerts — Get notified when specific ports are targeted or attack volume increases