# MikroTik Honeypot: Trap & Auto-Block Port Scanners

> One post from jmrp.io, published as its own document. Index: https://jmrp.io/llms-full.txt

Canonical: https://jmrp.io/blog/006-implementing-mikrotik-honeypot/
Language: en
Alternate: https://jmrp.io/es/blog/006-implementing-mikrotik-honeypot/index.md
License: https://creativecommons.org/licenses/by/4.0/
Type: TechArticle
Published: 2026-01-19
Updated: 2026-08-22
Instructions re-tested: 2026-08-22 · RouterOS 7.24 · RB5009UG+S+
Author: José Manuel Requena Plens
Summary: Configure a MikroTik honeypot to detect port scanners, log malicious activity, and auto-block attackers using firewall address lists and the RAW table.
Tags: MikroTik, Security, Networking
Topics: Honeypot (Q911932), MikroTik (Q913580), Firewall (Q80998), Port scanner (Q833766), IPv6 (Q2551624), Denial-of-service attack (Q131406)
Build-Date: 2026-09-17

Questions answered:

**What is a honeypot?**

A honeypot is a security mechanism that creates a decoy system designed to attract and detect attackers, luring them away from legitimate targets while gathering intelligence about their methods. NIST SP 800-53 includes honeypots as a formal security control (SC-26).

**Why does the honeypot only monitor "new" connections?**

Reconnaissance happens on the first packet (the TCP SYN), which carries the "new" state. Matching only "new" avoids false positives from already-established legitimate sessions and minimizes CPU overhead since only the initial probe is inspected.

**Why use the RAW table instead of the Filter table to block scanners?**

The RAW table processes packets before connection tracking, so blocking blacklisted attackers there means the router never allocates memory or CPU to track their connections. On routers handling thousands of attacks daily this significantly reduces resource usage; detection still runs in the Filter table.

**How do I avoid blocking myself when deploying the honeypot?**

Create a whitelist address-list and add your own IP before enabling any rules. The honeypot rules use src-address-list=!WhiteList so whitelisted IPs are never blocked; if you lock yourself out you'll need physical access to recover.

**Why are blocked IPs banned for only 4 hours instead of permanently?**

The rules use address-list-timeout=4h for a temporary ban. Attacker IPs are often dynamic and reassigned, so permanent bans risk blocking legitimate users later.

**Does the honeypot work with IPv6?**

Yes. The guide provides a separate IPv6 configuration that mirrors IPv4, using a distinct BlackList_PortScanners_v6 address list for comprehensive dual-stack protection.


Steps (Build a MikroTik honeypot to trap and auto-block port scanners):
1. Create the whitelist
2. Deploy the IPv4 honeypot configuration
3. Deploy the IPv6 honeypot configuration
4. Forward logs to a remote syslog server
5. Integrate the logs with CrowdSec
6. Test the honeypot

---

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](/blog/005-implementing-tarpit-nginx/). But what if you could turn these attacks into actionable intelligence? By configuring your **MikroTik** router as a lightweight **honeypot**, you can:

1. **Detect** unauthorized reconnaissance before it becomes a breach.
2. **Log** attacker IPs for analysis and threat intelligence sharing.
3. **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.

## TL;DR — MikroTik honeypot in a nutshell

- **Trap & auto-block**: detection rules in the Filter table match `connection-state=new` on bait ports and run `add-src-to-address-list` to blacklist scanners automatically.
- **High-performance blocking**: a RAW prerouting drop rule discards blacklisted traffic before connection tracking, saving CPU and memory on routers facing thousands of attacks.
- **Don't lock yourself out**: build a `WhiteList` first; rules use `src-address-list=!WhiteList`, and bans use `address-list-timeout=4h` to avoid permanent blocks on dynamic IPs.
- **Dual-stack**: a mirrored IPv6 ruleset uses a separate `BlackList_PortScanners_v6` list for full IPv4 + IPv6 coverage.
- **Threat intelligence**: forward `[HONEYPOT]` firewall logs to a remote syslog server and feed them into CrowdSec to collect attacker IPs.

---

## What is a honeypot?

A **honeypot** is a security mechanism that creates a decoy system designed to attract and detect attackers. According to [Fortinet](https://www.fortinet.com/resources/cyberglossary/what-is-honeypot), honeypots are intentionally vulnerable systems that lure adversaries away from legitimate targets while gathering intelligence about their methods. [NIST SP 800-53](https://csf.tools/reference/nist-sp-800-53/r5/sc/sc-26/) 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](https://attack.mitre.org/) (Tactics, Techniques, Procedures). |

**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**:

**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**

```mermaid
sequenceDiagram
    participant Scanner
    participant Router
    
    Scanner->>Router: SYN (new connection)
    Note right of Router: Honeypot triggers here!
    Router-->>Scanner: SYN-ACK
    Scanner->>Router: ACK
    Note over Scanner,Router: Connection now "established"
```

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:

**Honeypot Detection Flow**

```mermaid
flowchart TD
    classDef warning fill:#e6a700,color:#000
    classDef danger fill:#c53030,color:#fff
    classDef success fill:#2d7d32,color:#fff
    
    A[Internet Scanner] --> B{IP in Blacklist?}
    B -->|Yes: RAW Table| C["DROP instantly"]:::danger
    B -->|No| D{Is port trapped?}
    
    D -->|No: Port 80/443| E["Allow - Web Server"]:::success
    D -->|Yes: Port 22/3389/etc.| F["Honeypot Triggered"]:::warning
    
    F --> G["Log with prefix"]
    G -.-> G2["Remote Syslog"]
    
    F --> H["Add IP to BlackList"]
    H --> I["Drop current packet (Filter)"]:::danger
```

### 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](https://help.mikrotik.com/docs/spaces/ROS/pages/250708066/Firewall)** processes packets *before* [Connection Tracking](https://help.mikrotik.com/docs/spaces/ROS/pages/130220087/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](https://www.iana.org/assignments/service-names-port-numbers). 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

**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)](https://nvd.nist.gov/vuln/detail/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)](https://www.cisa.gov/news-events/cybersecurity-advisories/aa19-168a), 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](https://mikrotik.com/supportsec) |
| 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](https://www.cloudflare.com/learning/ddos/drdos-ddos-attack/)**—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](https://www.cisa.gov/news-events/alerts/2014/01/13/ntp-amplification-attacks-using-cve-2013-5211) 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](https://github.blog/news-insights/company-news/ddos-incident-report/) |
| 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

**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

**Creating the IPv4 Whitelist**

```routeros
# 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

**Creating the IPv6 Whitelist**

```routeros
# 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`.

**File: `honeypot-ipv4.rsc` — Complete IPv4 Honeypot Configuration**

```routeros
# ═══════════════════════════════════════════════════════════════════════════════
# 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.

**File: `honeypot-ipv6.rsc` — Complete IPv6 Honeypot Configuration**

```routeros
# ═══════════════════════════════════════════════════════════════════════════════
# 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 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:

1. **Feed [CrowdSec](https://www.crowdsec.net/)** — Contribute detected attackers to the community blocklist and receive protection from attacks seen globally.
2. **Report to [AbuseIPDB](https://www.abuseipdb.com/)** — 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.

**Remote Syslog Configuration**

```routeros
# 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](https://www.crowdsec.net/). 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:

**File: `/etc/rsyslog.d/10-mikrotik.conf` — rsyslog MikroTik Configuration**

```bash
# 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:

**Command to restart rsyslog**

```bash
sudo systemctl restart rsyslog
```

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

**Output — tail -f /var/log/mikrotik.log**

```text
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:

**File: `/etc/crowdsec/acquis.d/mikrotik.yaml` — CrowdSec MikroTik Acquisition**

```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:

**Command to install MikroTik parser**

```bash
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:

**File: `/etc/crowdsec/parsers/s01-parse/mikrotik-honeypot.yaml` — Custom Honeypot Parser**

```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:

**Command to reload CrowdSec**

```bash
sudo systemctl reload crowdsec
```

Verify the acquisition is working:

**Command to verify CrowdSec metrics**

```bash
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**

| Item | Value | % of total |
| --- | --- | --- |
| Telnet (23) | 535 | 42.1% |
| SSH (22) | 216 | 17% |
| SMB (445) | 172 | 13.5% |
| HTTP Alt (8080) | 106 | 8.3% |
| RDP (3389) | 80 | 6.3% |
| MSSQL (1433) | 63 | 5% |
| HTTPS Alt (8443) | 51 | 4% |
| MySQL (3306) | 49 | 3.9% |

Data collected over 24 hours on my home connection

**Top Attacking Countries**

| Item | Value | % of total |
| --- | --- | --- |
| 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% |

Source countries of blocked IPs

**Top Attacking Organizations (ASNs)**

| Item | Value | % of total |
| --- | --- | --- |
| 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

**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):

**Watch honeypot logs**

```routeros
/log print follow where message~"HONEYPOT"
```

2. **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`

3. **Check the address list**:

**Check blacklisted IPs**

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

Your test IP should appear with the timeout countdown.

4. **Verify blocking works**:
   - Try to ping the router from the same IP
   - It should timeout (the RAW rule drops all traffic)

5. **Clean up** (remove test IP):

**Remove test IP from blacklist**

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

---

## What this honeypot has actually caught

This guide describes the honeypot running on my own edge router, and its counter
is public: the [homelab page](/homelab/) publishes the hit count alongside the
CrowdSec ban list, injected by the edge server as it responds rather than by
JavaScript — the crawler and the reader see the same number. It read **3,341
honeypot hits** when this note was written (2026-08-22), and it will read
something else by the time you get here, which is rather the point of leaving
the counter live instead of freezing a figure into this paragraph.

Worth knowing before you read too much into any single number: a honeypot on a
residential IP counts *indiscriminate* scanning, not attacks aimed at you. The
value is in the pattern — which ports, from where, how the volume moves — not in
the total.

## 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:

1. **Reporting to [AbuseIPDB](https://www.abuseipdb.com/)** — 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