José Manuel Requena Plens • January 19, 2026 •

MikroTik Honeypot: Trap & Auto-Block Port Scanners

Configure a MikroTik honeypot to detect port scanners, log malicious activity, and auto-block attackers using firewall address lists and the RAW table.

Every router connected to the internet faces a relentless barrage of automated scans. Bots systematically probe the entire IPv4 address space—and increasingly IPv6—searching for vulnerable services: SSH servers with weak passwords, exposed databases, outdated RDP endpoints, or misconfigured IoT devices.

Most administrators respond by silently dropping these packets. But what if you could turn these attacks into actionable intelligence? By configuring your MikroTik router as a lightweight honeypot, you can:

Detect unauthorized reconnaissance before it becomes a breach.
Log attacker IPs for analysis and threat intelligence sharing.
Block malicious actors from accessing any service on your network.

This guide walks you through implementing a production-ready honeypot on RouterOS, complete with both IPv4 and IPv6 support.

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:

Types of Honeypots
Type	Complexity	Use Case
Low-Interaction	Simple, minimal resources	Detects automated scans and basic probes. Simulates limited services.
High-Interaction	Complex, full OS/applications	Engages sophisticated attackers to study advanced TTPs (Tactics, Techniques, Procedures).

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:

Connection States in RouterOSStateMeaningExample
newFirst packet of a connection attempt (TCP SYN or first UDP packet)Scanner probing port 22
establishedPart of an already-accepted connection (bidirectional traffic seen)Ongoing SSH session
relatedNew connection related to an existing oneFTP data channel, ICMP error messages
invalidPacket doesn’t belong to any known connectionMalformed packets, port scans with unusual flags

Connection States in RouterOS
State	Meaning	Example
`new`	First packet of a connection attempt (TCP SYN or first UDP packet)	Scanner probing port 22
`established`	Part of an already-accepted connection (bidirectional traffic seen)	Ongoing SSH session
`related`	New connection related to an existing one	FTP data channel, ICMP error messages
`invalid`	Packet doesn’t belong to any known connection	Malformed packets, port scans with unusual flags

Why we only monitor “new” connections

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

TCP Three-Way Handshake

Reconnaissance happens on new: Attackers send SYN packets to probe which ports are open. This is the first packet—the new state.
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.
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.

The strategy: detect, log, and block

Our honeypot strategy has three phases:

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).

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.

TCP trap ports

TCP Ports for Honeypot Detection
Port(s)	Service	Category	Why Attackers Target It
22	SSH	Remote Access	Brute-force credentials, leaked SSH keys
23	Telnet	Remote Access	Unencrypted, often default credentials
20, 21	FTP	Legacy	Unencrypted transfer, anonymous login abuse
25	SMTP	Mail	Open relay for spam, phishing campaigns
79	Finger	Legacy	User enumeration on Unix systems
110	POP3	Mail	Credential theft, unencrypted mail access
135	MS-RPC	Windows	Remote code execution exploits
137-139	NetBIOS	Windows	SMB relay attacks, network enumeration
143	IMAP	Mail	Credential theft, unencrypted mail access
389	LDAP	Windows	Active Directory enumeration
445	SMB	Windows	EternalBlue (CVE-2017-0144), WannaCry ransomware
502	Modbus	Industrial	ICS/SCADA system attacks
512-514	R-services	Legacy	Remote execution without authentication
593	RPC/HTTP	Windows	Exchange server exploits
636	LDAPS	Windows	Active Directory enumeration
1433	MSSQL	Database	SQL injection, malware distribution
1521	Oracle DB	Database	Database privilege escalation
1883, 8883	MQTT	IoT	Unauthorized message interception
3128	Squid Proxy	Proxy	Open proxy abuse for anonymization
3306	MySQL	Database	SQL injection, weak authentication
3389	RDP	Remote Access	BlueKeep (CVE-2019-0708), ransomware delivery
5432	PostgreSQL	Database	Database exploits, data theft
5900-5903	VNC	Remote Access	Screen control, often weak/no password
6000-6009	X11	Remote Access	Display hijacking on Unix
6379	Redis	Database	Unauthenticated access, RCE via EVAL
8080, 8443, 8888	HTTP Alt	Web/Admin	Admin panels, development servers
8291	Winbox	MikroTik	Router takeover via known CVEs
10000	Webmin	Admin	Web management interface RCE
27017-27018	MongoDB	Database	Unauthenticated access, ransomware
47808	BACnet	Industrial	Building automation system attacks

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.

UDP Ports for Honeypot Detection
Port	Service	Category	Why Attackers Target It
53	DNS	Amplification	100x+ amplification for DDoS attacks
69	TFTP	Legacy	Configuration file theft (no auth)
123	NTP	Amplification	500x+ amplification via monlist command
137-139	NetBIOS	Windows	Network share enumeration
161	SNMP	Amplification	650x amplification, device info leakage
520	RIP	Routing	Route injection attacks
1900	SSDP	Amplification	30x amplification via UPnP discovery
5060	SIP	VoIP	Toll fraud, call interception
5683	CoAP	IoT	IoT device exploitation
11211	Memcached	Amplification	52,000x amplification! Record-breaking DDoS vector
47808	BACnet	Industrial	Building automation systems

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:

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

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.

honeypot-ipv4.rsc

# ═══════════════════════════════════════════════════════════════════════════════
# IPv4 HONEYPOT CONFIGURATION
# ═══════════════════════════════════════════════════════════════════════════════
# This configuration detects port scanners and blocks them automatically.
# Customize the ports based on your environment - don't trap ports you use!
# ═══════════════════════════════════════════════════════════════════════════════

# ───────────────────────────────────────────────────────────────────────────────
# FILTER TABLE - Detection Rules (Input Chain)
# ───────────────────────────────────────────────────────────────────────────────

# --- TCP: Remote Access Services ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=22,23,3389,5900-5903,8291,6000-6009 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT: Remote Access (SSH, Telnet, RDP, VNC, Winbox, X11)"

# --- TCP: Database Services ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=1433,1521,3306,5432,6379,27017,27018 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT: Databases (MSSQL, Oracle, MySQL, PostgreSQL, Redis, MongoDB)"

# --- TCP: Windows/Enterprise Services ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=135,137-139,445,389,636,593 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT: Windows Services (SMB, NetBIOS, LDAP, RPC)"

# --- TCP: Legacy Protocols ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=20,21,69,512-514,79 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT: Legacy Services (FTP, TFTP, R-services, Finger)"

# --- TCP: Insecure Mail Protocols ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=25,110,143 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT: Insecure Mail (SMTP, POP3, IMAP)"

# --- TCP: Web Admin Panels & Proxies ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=8080,8443,8888,3128,10000 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT: Web Admin/Proxy (Alt-HTTP, Squid, Webmin)"

# --- TCP: IoT & Industrial Protocols ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=1883,8883,502,47808 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT: IoT/Industrial (MQTT, Modbus, BACnet)"

# --- UDP: Amplification Attack Vectors ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=udp \
    dst-port=53,123,161,1900,11211 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT UDP] " \
    comment="HONEYPOT: UDP Amplification (DNS, NTP, SNMP, SSDP, Memcached)"

# --- UDP: Legacy Protocols ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=udp \
    dst-port=69,137-139,520 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT UDP] " \
    comment="HONEYPOT: UDP Legacy (TFTP, NetBIOS, RIP)"

# --- UDP: IoT & VoIP ---
/ip firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners address-list-timeout=4h \
    connection-state=new protocol=udp \
    dst-port=5683,47808,5060 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT UDP] " \
    comment="HONEYPOT: UDP IoT/VoIP (CoAP, BACnet, SIP)"

# --- DROP already-blacklisted scanners (prevents further probing) ---
/ip firewall filter add chain=input action=drop \
    in-interface-list=WAN src-address-list=BlackList_PortScanners \
    comment="DROP: Blacklisted Port Scanners"


# ───────────────────────────────────────────────────────────────────────────────
# RAW TABLE - High-Performance Blocking (Prerouting Chain)
# ───────────────────────────────────────────────────────────────────────────────
# The RAW table processes packets BEFORE connection tracking.
# Blocking here is more efficient and reduces CPU/memory usage.

/ip firewall raw add chain=prerouting action=drop \
    in-interface-list=WAN src-address-list=BlackList_PortScanners \
    comment="DROP: Blacklisted Port Scanners (RAW - High Performance)"

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

# ═══════════════════════════════════════════════════════════════════════════════
# IPv6 HONEYPOT CONFIGURATION
# ═══════════════════════════════════════════════════════════════════════════════
# Mirrors the IPv4 configuration for comprehensive dual-stack protection.
# Uses a separate address list: BlackList_PortScanners_v6
# ═══════════════════════════════════════════════════════════════════════════════

# ───────────────────────────────────────────────────────────────────────────────
# FILTER TABLE - Detection Rules (Input Chain)
# ───────────────────────────────────────────────────────────────────────────────

# --- TCP: Remote Access Services ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=22,23,3389,5900-5903,8291,6000-6009 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT IPv6: Remote Access (SSH, Telnet, RDP, VNC, Winbox, X11)"

# --- TCP: Database Services ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=1433,1521,3306,5432,6379,27017,27018 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT IPv6: Databases (MSSQL, Oracle, MySQL, PostgreSQL, Redis, MongoDB)"

# --- TCP: Windows/Enterprise Services ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=135,137-139,445,389,636,593 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT IPv6: Windows Services (SMB, NetBIOS, LDAP, RPC)"

# --- TCP: Legacy Protocols ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=20,21,69,512-514,79 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT IPv6: Legacy Services (FTP, TFTP, R-services, Finger)"

# --- TCP: Insecure Mail Protocols ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=25,110,143 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT IPv6: Insecure Mail (SMTP, POP3, IMAP)"

# --- TCP: Web Admin Panels & Proxies ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=8080,8443,8888,3128,10000 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT IPv6: Web Admin/Proxy (Alt-HTTP, Squid, Webmin)"

# --- TCP: IoT & Industrial Protocols ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=tcp \
    dst-port=1883,8883,502,47808 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT TCP] " \
    comment="HONEYPOT IPv6: IoT/Industrial (MQTT, Modbus, BACnet)"

# --- UDP: Amplification Attack Vectors ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=udp \
    dst-port=53,123,161,1900,11211 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT UDP] " \
    comment="HONEYPOT IPv6: UDP Amplification (DNS, NTP, SNMP, SSDP, Memcached)"

# --- UDP: Legacy Protocols ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=udp \
    dst-port=69,137-139,520 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT UDP] " \
    comment="HONEYPOT IPv6: UDP Legacy (TFTP, NetBIOS, RIP)"

# --- UDP: IoT & VoIP ---
/ipv6 firewall filter add chain=input action=add-src-to-address-list \
    address-list=BlackList_PortScanners_v6 address-list-timeout=4h \
    connection-state=new protocol=udp \
    dst-port=5683,47808,5060 \
    in-interface-list=WAN src-address-list=!WhiteList \
    log=yes log-prefix="[HONEYPOT UDP] " \
    comment="HONEYPOT IPv6: UDP IoT/VoIP (CoAP, BACnet, SIP)"

# --- DROP already-blacklisted scanners ---
/ipv6 firewall filter add chain=input action=drop \
    in-interface-list=WAN src-address-list=BlackList_PortScanners_v6 \
    comment="DROP: Blacklisted IPv6 Port Scanners"


# ───────────────────────────────────────────────────────────────────────────────
# RAW TABLE - High-Performance Blocking (Prerouting Chain)
# ───────────────────────────────────────────────────────────────────────────────

/ipv6 firewall raw add chain=prerouting action=drop \
    in-interface-list=WAN src-address-list=BlackList_PortScanners_v6 \
    comment="DROP: Blacklisted IPv6 Port Scanners (RAW - High Performance)"

Understanding the configuration

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

Rule Parameter ReferenceParameterValuePurpose
chain=inputinputTargets traffic destined for the router itself, not forwarded traffic.
connection-state=newnewOnly triggers on the first packet of a connection (SYN). Prevents false positives from established sessions.
address-list-timeout=4h4 hoursTemporary ban. Dynamic IPs change, so permanent bans risk blocking legitimate users later.
src-address-list=!WhiteListNOT WhiteListThe ! operator excludes whitelisted IPs. Critical for avoiding self-lockout.
log=yesEnabledRecords each detection to the system log. Essential for analysis and threat intelligence.
log-prefix="[HONEYPOT TCP] "Custom prefixTags log entries for easy filtering. Useful for forwarding to external systems.
in-interface-list=WANWAN interfacesOnly monitors traffic from external networks, not LAN devices.

Rule Parameter Reference
Parameter	Value	Purpose
`chain=input`	input	Targets traffic destined for the router itself, not forwarded traffic.
`connection-state=new`	new	Only triggers on the first packet of a connection (SYN). Prevents false positives from established sessions.
`address-list-timeout=4h`	4 hours	Temporary ban. Dynamic IPs change, so permanent bans risk blocking legitimate users later.
`src-address-list=!WhiteList`	NOT WhiteList	The `!` operator excludes whitelisted IPs. Critical for avoiding self-lockout.
`log=yes`	Enabled	Records each detection to the system log. Essential for analysis and threat intelligence.
`log-prefix="[HONEYPOT TCP] "`	Custom prefix	Tags log entries for easy filtering. Useful for forwarding to external systems.
`in-interface-list=WAN`	WAN interfaces	Only monitors traffic from external networks, not LAN devices.

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:

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

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:

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

onsuccess: next_stage
name: local/mikrotik-honeypot
description: "Parser for MikroTik honeypot firewall logs"
filter: "evt.Line.Raw contains '[HONEYPOT'"

pattern_syntax:
  # Pattern for honeypot detections with [HONEYPOT TCP] or [HONEYPOT UDP] prefix
  MIKROTIK_HONEYPOT: '^%{TIMESTAMP_ISO8601:timestamp} %{HOSTNAME} firewall,.*? \[HONEYPOT %{WORD:hp_proto}\]\s+%{WORD:chain}: in:%{DATA:if_in} out:%{DATA:if_out},.*?proto %{WORD:proto}.*?, %{IP:source_ip}:%{INT:src_port}->%{IP:dst_ip}:%{INT:dst_port}.*len %{INT:length}'

nodes:
  - grok:
      pattern: "%{MIKROTIK_HONEYPOT}"
      apply_on: Line.Raw
    statics:
      - meta: service
        value: mikrotik_honeypot
      - meta: log_type
        value: honeypot_detection
      - meta: dst_port
        expression: "evt.Parsed.dst_port"
      - meta: proto
        expression: "evt.Parsed.proto"

statics:
  - meta: source_ip
    expression: "evt.Parsed.source_ip"
  - target: evt.StrTime
    expression: "evt.Parsed.timestamp"

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

Telnet (23)
SSH (22)
SMB (445)
HTTP Alt (8080)
RDP (3389)
MSSQL (1433)
HTTPS Alt (8443)
MySQL (3306)

Attack Distribution by Port
Category	Value	Percentage
Telnet (23)	535	42.1%
SSH (22)	216	17.0%
SMB (445)	172	13.5%
HTTP Alt (8080)	106	8.3%
RDP (3389)	80	6.3%
MSSQL (1433)	63	5.0%
HTTPS Alt (8443)	51	4.0%
MySQL (3306)	49	3.9%

Data collected from all time alerts on my home connection

Top Attacking Countries

United States (US)
Netherlands (NL)
China (CN)
Brazil (BR)
Russia (RU)
Bulgaria (BG)
Germany (DE)
India (IN)

Top Attacking Countries
Category	Value	Percentage
United States (US)	484	44.1%
Netherlands (NL)	194	17.7%
China (CN)	127	11.6%
Brazil (BR)	81	7.4%
Russia (RU)	59	5.4%
Bulgaria (BG)	58	5.3%
Germany (DE)	50	4.6%
India (IN)	44	4.0%

Source countries of blocked IPs

Top Attacking Organizations (ASNs)

DigitalOcean
Google Cloud
Microsoft
Hurricane Electric
Chinanet

Top Attacking Organizations (ASNs)
Category	Value	Percentage
DigitalOcean	180	35.4%
Google Cloud	108	21.3%
Microsoft	83	16.3%
Hurricane Electric	80	15.7%
Chinanet	57	11.2%

Top 5 networks originating attacks

Testing your honeypot

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

Test procedure

Add your test IP to watch (optional):

ROUTEROSWatch honeypot logs

/log print follow where message~"HONEYPOT"

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

ROUTEROSCheck blacklisted IPs

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

Your test IP should appear with the timeout countdown.

Verify blocking works:
- Try to ping the router from the same IP
- It should timeout (the RAW rule drops all traffic)
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:

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

Consider extending this setup by:

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

Fortinetwww.fortinet.com

NIST SP 800-53csf.tools

TTPsattack.mitre.org

Raw tablehelp.mikrotik.com

Connection Trackinghelp.mikrotik.com

IANA Service Name and Port Number Registrywww.iana.org

EternalBlue (CVE-2017-0144)nvd.nist.gov

BlueKeep (CVE-2019-0708)www.cisa.gov

known CVEsmikrotik.com

amplification attackswww.cloudflare.com

500x+ amplificationwww.cisa.gov

Record-breaking DDoS vectorgithub.blog

CrowdSecwww.crowdsec.net

AbuseIPDBwww.abuseipdb.com

MikroTik Honeypot: Trap & Auto-Block Port Scanners

What is a honeypot?

Understanding TCP connection states

Why we only monitor “new” connections

The strategy: detect, log, and block

Why use the RAW table for blocking?

Trap port reference

TCP trap ports

UDP trap ports

Step 1: create the whitelist

When to use a whitelist

IPv4 whitelist

IPv6 whitelist

Step 2: IPv4 honeypot configuration

Step 3: IPv6 honeypot configuration

Understanding the configuration

Leveraging logs for threat intelligence

Integrating with CrowdSec

Step 1: receive logs via rsyslog

Step 2: configure CrowdSec acquisition

Step 3: install the MikroTik parser

Step 4: custom parser for honeypot logs (optional)

Step 5: reload CrowdSec

Real-world results

Testing your honeypot

Test procedure

What’s next?

Further Reading & Resources

Table of Contents