Architecting an Active Defense in a Network specifically with Mikrotik

Automating OpenCanary Honeypot Integration with MikroTik

In the modern cybersecurity landscape, relying solely on static firewall rules to drop packets is a failing strategy. Automated botnets and malicious actors constantly probe network perimeters. To truly secure an infrastructure—whether it is a complex enterprise environment or an advanced homelab—we need a system that actively fights back. Today, we are building an automated "Active Defense" pipeline that turns reconnaissance attempts into instant hardware-level bans.

Network Security Topology - Honeypot to MikroTik Router Automation Flow

1. Core Concepts: The Deep Dive

Before deploying code, it is critical to understand the architecture and why we select specific tools to make this setup completely "idiot-proof."

• The Honeypot (Decoy Concept): A honeypot is an intentionally vulnerable system placed on your network. It serves no legitimate business purpose. Therefore, any traffic directed at it is, by definition, malicious reconnaissance.
• OpenCanary (High-Interaction Sensor): Unlike basic port scanners that simply listen, OpenCanary actively emulates services (SSH, FTP, HTTP, SQL). When an attacker tries to brute-force the fake SSH service, OpenCanary captures their exact intent, providing high-fidelity, zero-false-positive alerts.
• MikroTik Bouncer: This is our custom automation engine. It acts as the bridge between the OpenCanary logs and the MikroTik hardware firewall, parsing threats and executing commands in real-time.

The Essential Automation Tools

• grepcidr (The Safety Net): If you automate bans, the biggest risk is locking yourself out. grepcidr is a specialized utility that checks IP addresses against entire subnets (CIDR notation) in milliseconds. We use it to ensure the Bouncer script never blocks our trusted management subnets.
• sshpass (The Authenticator): MikroTik requires authentication for SSH. Because our script runs in the background without human intervention, sshpass allows our script to securely pass credentials to the router and execute the ban command instantly.
• Systemd: We utilize Linux's native service manager to ensure our honeypot and bouncer scripts survive reboots, network drops, and unexpected crashes without requiring manual restarts.

---

2. Infrastructure Preparation (Debian 12 LXC)

We begin with a clean Debian 12 LXC container. Run the following command to install the required dependency stack:

apt update && apt upgrade -y
apt install -y python3-pip python3-venv git nano net-tools iproute2 sshpass grepcidr build-essential

Note: We include python3-venv to isolate our honeypot environment, preventing Python package conflicts with the host OS.

3. OpenCanary Installation & Configuration

We deploy OpenCanary inside a virtual environment. We must also change its default SSH port so it does not clash with the LXC container's actual management SSH.

# Create and activate the virtual environment
mkdir -p /opt/opencanary
python3 -m venv /opt/opencanary
source /opt/opencanary/bin/activate

# Install OpenCanary
pip install --upgrade pip
pip install opencanary scapy rdpy-rdp-victim

# Initialize configuration
opencanaryd --init

Next, edit the configuration file (/etc/opencanaryd/opencanary.conf). Change the ssh.port to 2222 and ensure ssh.enabled is set to true.

4. MikroTik Router Configuration: The Enforcer

We need to configure the router to securely accept commands from the honeypot, and route attacker traffic into the trap.

MikroTik Router User Setup and Key Authentication

A. The Automation User (Least Privilege)

Never use the `admin` account for scripts. Create a restricted user that is only allowed to connect from the IP of your LXC container (e.g., 192.168.50.4).

/user group add name=bouncer-group policy=read,write,policy,test
/user add name=oc-bouncer group=bouncer-group password=YourSecurePassword
/user set [find name=oc-bouncer] allowed-address=192.168.50.4/32

B. Traffic Redirection (DST-NAT)

Redirect incoming public SSH probes to the OpenCanary trap on port 2222.

/ip firewall nat add chain=dstnat dst-port=22 protocol=tcp action=dst-nat to-addresses=192.168.50.4 to-ports=2222

5. The Bouncer Script

Create the automation engine at /opt/opencanary/mikrotik-bouncer.sh. This script continuously monitors the logs, verifies the IP against your whitelist using grepcidr, and executes the ban.

#!/bin/bash
# Configuration
MIKROTIK_USER="oc-bouncer"
MIKROTIK_IP="192.168.50.1"
WHITELIST_FILE="/etc/opencanaryd/whitelist.txt"

# Continuously read the log file
tail -F /var/tmp/opencanary.log | while read line
do
    # Extract the source IP from the JSON log
    SRC_IP=$(echo $line | grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | head -n 1)

    # Validate against whitelist using grepcidr
    if [[ ! -z "$SRC_IP" ]] && ! echo "$SRC_IP" | grepcidr -f "$WHITELIST_FILE" > /dev/null; then
        echo "Malicious intent detected. Quarantining $SRC_IP..."
        
        # Push attacker to MikroTik Honeypot_Blacklist
        sshpass -e ssh -o StrictHostKeyChecking=no $MIKROTIK_USER@$MIKROTIK_IP \
        "/ip firewall address-list add list=Honeypot_Blacklist address=$SRC_IP timeout=1d comment='Blocked by OpenCanary'"
    fi
done

Don't forget to populate your /etc/opencanaryd/whitelist.txt with your trusted subnets (e.g., 192.168.50.0/24)!

6. Systemd Persistence & Fixing The "Loop"

To ensure OpenCanary spawns correctly in the background, we must use Type=forking in our systemd service file (/etc/systemd/system/opencanary.service):

[Unit]
Description=OpenCanary Daemon
After=network.target

[Service]
Type=forking
User=root
WorkingDirectory=/etc/opencanaryd
ExecStart=/opt/opencanary/bin/opencanaryd --start --allow-run-as-root --config=/etc/opencanaryd/opencanary.conf
ExecStop=/opt/opencanary/bin/opencanaryd --stop
Restart=always

[Install]
WantedBy=multi-user.target

Testing & The DNS Flood Protection Fix

During our deployment testing, we discovered a common MikroTik quirk: if your Bouncer script establishes too many rapid SSH connections to the router, MikroTik's native DNS/Connection Flood Protection might accidentally flag the LXC container as an attacker!

To fix this, we implement a strict exclusion rule in the MikroTik firewall. We tell the flood protection rule to ignore our trusted management subnet:

/ip firewall filter set [find comment="DNS Flood Protection"] src-address-list=!Trusted_LAN

Once applied, you can test the system by injecting a fake log entry (echo '{"src_host": "1.2.3.4"}' >> /var/tmp/opencanary.log). You should immediately see the IP populate in your MikroTik Address Lists.

Here is the attack and blocking in action

Conclusion

By shifting from reactive manual blocking to an automated, honeypot-integrated response, you significantly reduce operational overhead while hardening your perimeter. This architecture demonstrates that enterprise-grade active defense is highly achievable using open-source tools and robust networking hardware.