0% found this document useful (0 votes)
4 views17 pages

TTT Securing RouterOS Lab

The document outlines strategies for securing RouterOS against various network attacks, including port scanning, brute force, and denial of service (DoS) attacks. It details a defense-in-depth model, lab setup instructions, and specific firewall rules for mitigating these threats using RouterOS capabilities. Additionally, it provides practical demonstrations and commands for implementing these security measures effectively.

Uploaded by

Mamadou BANGOURA
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views17 pages

TTT Securing RouterOS Lab

The document outlines strategies for securing RouterOS against various network attacks, including port scanning, brute force, and denial of service (DoS) attacks. It details a defense-in-depth model, lab setup instructions, and specific firewall rules for mitigating these threats using RouterOS capabilities. Additionally, it provides practical demonstrations and commands for implementing these security measures effectively.

Uploaded by

Mamadou BANGOURA
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

SECURING ROUTEROS
Attack Detection & Defense Strategies

MikroTik Train the Trainer (TTT)


Gustavo Morales | ISERTEC Guatemala
Riga, Latvia | 2026

Attack Tool Defense Layer


Port Scan nmap -sS -p- psd matcher → address-list
Brute Force hydra SSH 3-stage dynamic blacklist
DoS SYN Flood hping3 --flood RAW table rate limiting
Port Knocking knock 1234 5678 9101 3-stage whitelist → SSH

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

1. Introduction

RouterOS, the operating system powering MikroTik devices, is widely deployed across
enterprise, ISP, and SMB environments due to its flexibility and cost-effectiveness. However, its
ubiquity also makes it a frequent target for network attacks including reconnaissance, brute
force credential attacks, denial of service, and unauthorized access attempts.

This document accompanies the Train the Trainer (TTT) home assignment presentation titled
"Securing RouterOS: Attack Detection & Defense Strategies." It provides theoretical background
on each attack type, the mitigation techniques implemented in RouterOS firewall, and the
step-by-step lab commands used during the live demonstration.

It is important to clarify that RouterOS is not an Intrusion Prevention System (IPS) by design.
The techniques documented here are mitigation strategies that leverage RouterOS firewall
capabilities — address lists, the psd matcher, RAW table rate limiting, and port knocking — to
reduce attack surface and respond dynamically to threat patterns.

1.1 Defense in Depth Model


The lab implements a three-layer defense architecture based on the official MikroTik hardening
recommendations combined with custom detection rules:

Layer 1 MikroTik Baseline — established/related accept, ICMP, default deny

Layer 2 Official Hardening — disable unused services, SSH strong crypto, restrict MAC access

Layer 3 Custom Detection — port scan psd, brute force blacklist, DoS RAW, port knocking

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

2. Lab Topology & Setup

The lab uses the following network topology. All devices are connected to a common Layer 2
switch, with the instructor RouterBoard acting as gateway and DHCP server for the
[Link]/24 network.

Device Role IP Address Notes


RB5009UG+S+ Gateway / Victim [Link] DHCP server, defense rules
(Instructor) active
Kali Linux (Chuwi) Attacker [Link] Reserved via DHCP MAC
binding
Trainer RouterBoards Participants [Link]- Apply defense rules during lab
50
Lab Switch L2 Connectivity — Connects all devices

2.1 Lab Instructions for Participants


1.​ Connect your RouterBoard: ether1 to lab switch (receives DHCP from instructor),
ether2+ to your laptop.
2.​ Open Winbox and connect via MAC address. Default credentials: admin / (no password).
3.​ Apply the defense rules from the shared document in order: RAW table first, then Filter
rules, then hardening commands.
4.​ When the instructor launches each attack, monitor your router logs in real time.
5.​ Verify your defenses by checking address lists after each attack.

2.2 RouterOS Monitor Commands


Run these commands on your RouterBoard during each attack demo:

/log print follow where message~"BLOCKED"


/ip firewall address-list print
/ip firewall filter print stats
/ip firewall raw print stats
/system resource print

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

3. RouterOS Hardening Baseline

Before implementing custom detection rules, the router must have a solid security baseline. The
following configuration is based on the official MikroTik security documentation and should be
applied to any production RouterOS device.

3.1 Disable Unused Services


RouterOS enables several services by default that are not required in production environments.
Each open service represents a potential attack surface:

/ip service set telnet disabled=yes


/ip service set ftp disabled=yes
/ip service set www disabled=yes
/ip service set api disabled=yes
/ip service set api-ssl disabled=yes
/ip ssh set strong-crypto=yes

3.2 Restrict Management Access


MAC-based access, neighbor discovery, and the bandwidth server should be restricted to
trusted interfaces only:

/interface list add name=LAN-list


/interface list member add interface=bridge-lab list=LAN-list
/tool mac-server set allowed-interface-list=LAN-list
/tool mac-server mac-winbox set allowed-interface-list=LAN-list
/tool mac-server ping set enabled=no
/ip neighbor discovery-settings set discover-interface-list=LAN-list
/tool bandwidth-server set enabled=no

3.3 Baseline Firewall Filter Rules


The following filter rules form the minimum recommended firewall for any RouterOS device.
They should be applied before any custom detection rules:

# Accept already-established and related connections


/ip firewall filter add chain=input action=accept
connection-state=established,related comment="Accept established/related"

# Allow DNS from LAN (required for client resolution)


/ip firewall filter add chain=input action=accept protocol=udp dst-port=53
src-address=[Link]/24 comment="Allow DNS UDP from LAN"

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

/ip firewall filter add chain=input action=accept protocol=tcp dst-port=53


src-address=[Link]/24 comment="Allow DNS TCP from LAN"

# Allow ICMP and Winbox management


/ip firewall filter add chain=input action=accept protocol=icmp comment="Accept
ICMP"
/ip firewall filter add chain=input action=accept protocol=tcp dst-port=8291
src-address=[Link]/24 comment="Allow Winbox from LAN"

# Default deny — must be last rule


/ip firewall filter add chain=input action=drop comment="Drop input - default
deny"

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

4. Demo 1 — Port Scan Detection

Port scanning is the first phase of any network attack. An attacker uses tools like nmap to
identify open ports and services running on a target device. This reconnaissance phase
provides the information needed to plan subsequent attacks.

RouterOS implements port scan detection through the psd (Port Scan Detection) parameter
available in firewall filter rules. The psd matcher analyzes incoming TCP packets and detects
patterns characteristic of port scanning based on weighted scoring of packet sequences.

4.1 The psd Parameter


The psd parameter uses four values to configure detection sensitivity:

WeightThr Minimum accumulated weight to trigger detection. Lower = more sensitive.


eshold Recommended: 21

DelayThre Time window for weight accumulation. Recommended: 3s


shold

LowPortW Weight assigned per packet to ports 0-1023. Recommended: 3


eight

HighPortW Weight assigned per packet to ports 1024-65535. Recommended: 1


eight

Example using psd=21,3s,3,1: If nmap scans ports 22, 80, and 443, it accumulates 3+3+3=9
weight. Scanning 12 high ports adds 12 more. At 21+ within 3 seconds, the source IP is flagged
as a scanner.

4.2 Firewall Rules


# Detect port scanner — add to address list for 10 minutes
/ip firewall filter add chain=input action=add-src-to-address-list protocol=tcp
psd=21,3s,3,1 address-list=port-scanners address-list-timeout=10m
comment="Detect Port Scanner"

# Drop detected scanners with log


/ip firewall filter add chain=input action=drop src-address-list=port-scanners
log=yes log-prefix="SCANNER-BLOCKED:" comment="Drop Port Scanners"

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

4.3 Attack Commands (Kali Linux)


# Targeted scan — 6 specific ports
nmap -sS -p 22,80,443,8291,8728 [Link]

# Full port scan — triggers psd detection


nmap -sS -p- -T5 --min-rate=5000 --max-retries=1 [Link]

4.4 Verification on RouterOS


/ip firewall address-list print where list=port-scanners
/log print where message~"SCANNER-BLOCKED"

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

5. Demo 2 — Brute Force Detection

SSH brute force attacks attempt to gain unauthorized access by systematically trying username
and password combinations. Tools like Hydra can make hundreds of authentication attempts per
minute, making rate-based detection essential.

RouterOS implements brute force mitigation through a dynamic 3-stage blacklist. Each failed
SSH connection attempt escalates the attacker through progressively longer blocking periods,
culminating in a permanent block after repeated offenses.

5.1 3-Stage Blacklist Logic


The detection works by tracking new TCP connections to port 22 from IPs not already
whitelisted:

Stage 1 First failed attempt — add to blacklist-stage1 for 1 minute

Stage 2 Any new connection from stage1 IP — escalate to blacklist-stage2 for 1 hour

Stage 3 Any new connection from stage2 IP — add to blacklist-permanent (no expiry)

5.2 Firewall Rules


# Port knocking whitelist must come first (see Section 7)

# Stage 1 — detect new SSH connection attempts


/ip firewall filter add chain=input action=add-src-to-address-list
connection-state=new protocol=tcp dst-port=22 src-address-list=!whitelist
address-list=blacklist-stage1 address-list-timeout=1m comment="SSH BF Stage 1 -
1min"

# Stage 2 — escalate if stage1 IP tries again


/ip firewall filter add chain=input action=add-src-to-address-list
src-address-list=blacklist-stage1 address-list=blacklist-stage2
address-list-timeout=1h comment="SSH BF Stage 2 - 1hr"

# Stage 3 — permanent block


/ip firewall filter add chain=input action=add-src-to-address-list
src-address-list=blacklist-stage2 address-list=blacklist-permanent
address-list-timeout=none-dynamic comment="SSH BF Stage 3 - permanent"

# Drop rules — order matters (permanent first)

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

/ip firewall filter add chain=input action=drop


src-address-list=blacklist-permanent log=yes log-prefix="BF-PERMANENT-BLOCKED:"
comment="Drop permanent blacklist"
/ip firewall filter add chain=input action=drop
src-address-list=blacklist-stage2 log=yes log-prefix="BF-STAGE2-BLOCKED:"
comment="Drop BF stage2"
/ip firewall filter add chain=input action=drop
src-address-list=blacklist-stage1 log=yes log-prefix="BF-STAGE1-BLOCKED:"
comment="Drop BF stage1"

5.3 Attack Commands (Kali Linux)


# Create wordlist
cat << EOF > /root/ttt-lab/[Link]
admin
password
123456
mikrotik
router
EOF

# Launch hydra brute force


hydra -l admin -P /root/ttt-lab/[Link] ssh://[Link] -t 4 -V

5.4 Verification on RouterOS


/ip firewall address-list print where list=blacklist-stage1
/ip firewall address-list print where list=blacklist-permanent
/log print where message~"BF-"

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

6. Demo 3 — DoS SYN Flood Mitigation

A SYN flood is a type of Denial of Service attack that exploits the TCP three-way handshake.
The attacker sends a large number of SYN packets without completing the handshake,
exhausting the target's connection table and consuming CPU resources.

RouterOS mitigates SYN floods using the RAW firewall table, which processes packets before
connection tracking. This makes RAW table rules significantly more efficient than filter rules for
high-volume traffic, as they do not create connection state entries.

6.1 RAW Table Architecture


The RAW table sits before the connection tracking engine. For DoS mitigation:
•​ Packets that arrive faster than the configured rate are flagged as flood
•​ The source IP is added to a dynamic address list
•​ Subsequent packets from that IP are dropped immediately at the RAW level
•​ Forward traffic (internet connectivity) is NOT affected — only input to the router

6.2 RAW Firewall Rules


# Whitelist LAN traffic except Kali (.49) — skip flood check
/ip firewall raw add chain=prerouting action=accept protocol=tcp
tcp-flags=syn,!ack src-address=![Link] dst-port=!22 comment="Whitelist
LAN - skip flood check"

# Accept return traffic from WAN


/ip firewall raw add chain=prerouting action=accept in-interface=ether1
dst-address=[Link]/24 comment="Accept WAN return to LAN"

# Drop IPs already known to be flooding


/ip firewall raw add chain=prerouting action=drop
src-address-list=syn-flood-ips comment="Drop known flood IPs"

# Jump pure SYN packets to flood detection chain


/ip firewall raw add chain=prerouting action=jump jump-target=syn-flood
protocol=tcp tcp-flags=syn,!ack comment="Jump pure SYN to flood chain"

# Allow up to 200 SYN per 5 seconds — add to list if within limit


/ip firewall raw add chain=syn-flood action=add-src-to-address-list
limit=200,5:packet address-list=syn-flood-ips address-list-timeout=10m
comment="Allow up to 200 SYN/5s"

# Drop excess SYN packets

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

/ip firewall raw add chain=syn-flood action=drop log=yes


log-prefix="SYN-FLOOD-BLOCKED:" comment="Drop SYN flood"

# Enable RAW only for DoS demo — disable before other demos
/ip firewall raw disable [find]
/ip firewall raw enable [find] # run before Demo 3

6.3 Attack Commands (Kali Linux)


# SYN flood — stop with Ctrl+C after 10 seconds
sudo hping3 -S --flood -V -p 22 [Link]

6.4 Verification on RouterOS


/ip firewall raw print stats
/ip firewall address-list print where list=syn-flood-ips
/system resource print

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

7. Demo 4 — Port Knocking

Port knocking is a security mechanism that hides services (such as SSH) by keeping their ports
invisible until the correct sequence of connection attempts is made to specific ports in the
correct order. Before the knock sequence, port scanning shows all ports as filtered — the
service is effectively invisible.

RouterOS implements port knocking entirely within the firewall filter rules using dynamic address
lists with short TTLs. No additional software is required.

7.1 Knock Sequence Logic


Knock 1 TCP SYN to port 1234 → add to knock-stage1 (TTL: 30 seconds)

TCP SYN to port 5678, must be in knock-stage1 → add to knock-stage2 (TTL: 15


Knock 2
seconds)

Knock 3 TCP SYN to port 9101, must be in knock-stage2 → add to whitelist (TTL: 1 hour)

SSH Accept TCP port 22 only from whitelist address list

7.2 Firewall Rules


These rules must be placed BEFORE the port scanner and brute force detection rules to
prevent the knock packets themselves from triggering detection:

/ip firewall filter add chain=input action=add-src-to-address-list protocol=tcp


dst-port=1234 src-address-list=!blacklist-permanent address-list=knock-stage1
address-list-timeout=30s comment="Port Knock Stage 1"
/ip firewall filter add chain=input action=add-src-to-address-list protocol=tcp
dst-port=5678 src-address-list=knock-stage1 address-list=knock-stage2
address-list-timeout=15s comment="Port Knock Stage 2"
/ip firewall filter add chain=input action=add-src-to-address-list protocol=tcp
dst-port=9101 src-address-list=knock-stage2 address-list=whitelist
address-list-timeout=1h comment="Port Knock Stage 3 - whitelist"
/ip firewall filter add chain=input action=accept protocol=tcp dst-port=22
src-address-list=whitelist comment="SSH - whitelist only"

7.3 Attack Commands (Kali Linux)


# Method 1 — using knock client

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

knock [Link] 1234 5678 9101


ssh admin@[Link]

# Method 2 — using nmap (if knock not available)


nmap -Pn --host-timeout 201 --max-retries 0 -p 1234 [Link]
nmap -Pn --host-timeout 201 --max-retries 0 -p 5678 [Link]
nmap -Pn --host-timeout 201 --max-retries 0 -p 9101 [Link]
ssh admin@[Link]

7.4 Verification on RouterOS


/ip firewall address-list print where list=knock-stage1
/ip firewall address-list print where list=whitelist

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

8. Complete Firewall Configuration

The following is the complete firewall configuration for the TTT lab router. Rules must be applied
in this exact order. The RAW table rules should be disabled by default and only enabled during
the DoS demonstration.

8.1 Final Filter Rule Order

# Comment Action Purpose


0 Accept established/related accept Allow return traffic
1 Allow DNS UDP from LAN accept udp:53 Client DNS resolution
2 Allow DNS TCP from LAN accept tcp:53 DNS over TCP
3 Accept ICMP accept icmp Ping and diagnostics
4 Allow Winbox from LAN accept tcp:8291 Management access
5 Drop DoS flood IPs drop syn-flood-ips Block known flood IPs
6 Port Knock Stage 1 add-to knock-stage1 Knock sequence step 1
7 Port Knock Stage 2 add-to knock-stage2 Knock sequence step 2
8 Port Knock Stage 3 add-to whitelist Open SSH for 1 hour
9 SSH - whitelist only accept tcp:22 Allow only knocked IPs
10 Detect Port Scanner add-to port-scanners psd detection
11 Drop Port Scanners drop + log Block scanners
12 SSH BF Stage 1 add-to blacklist-stage1 1 minute block
13 SSH BF Stage 2 add-to blacklist-stage2 1 hour block
14 SSH BF Stage 3 add-to Permanent block
blacklist-permanent
15 Drop permanent blacklist drop + log BF-PERMANENT-BLOCKED
16 Drop BF stage2 drop + log BF-STAGE2-BLOCKED
17 Drop BF stage1 drop + log BF-STAGE1-BLOCKED
18 Forward established/related accept forward Allow return traffic
19 Allow LAN to WAN forward accept forward Internet access
20 Drop forward default drop forward Block unknown forward
21 Drop input default deny drop input Catch-all deny

8.2 Reset Between Demos


Run this command on RouterOS between each demo to clear all dynamic address lists:

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

/ip firewall address-list remove [find dynamic=yes]

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

9. Limitations & Production Considerations

The techniques demonstrated in this lab represent effective first-line defenses for RouterOS
deployments. However, it is important to understand their limitations when considering a
production security architecture.

9.1 RouterOS as a Mitigation Layer


RouterOS is not designed as a dedicated IPS. The firewall-based detection implemented here
has the following characteristics:
•​ Port scan detection (psd) works on packet patterns, not payload inspection
•​ Brute force blacklisting blocks by IP address — rotating IPs bypass it
•​ DoS mitigation protects the router itself, not downstream servers
•​ Port knocking is security through obscurity — it adds friction, not cryptographic
protection
•​ All blocking is based on dynamic address lists with TTLs — not persistent across reboots
unless backed up

9.2 Production Architecture Recommendations


For enterprise environments, RouterOS hardening should be the first layer in a broader security
stack:

IDS/IPS Suricata or Snort for deep packet inspection and signature-based detection

SIEM Centralized log collection and correlation (Graylog, Splunk, ELK)

AAA RADIUS authentication for centralized, scalable management access control

Segmentat VLANs and ACLs to limit lateral movement even if a device is compromised
ion

RouterOS hardening reduces attack surface, detects common patterns, and buys response
time. Combined with proper monitoring and network segmentation, it provides an excellent
security foundation at a significantly lower cost than dedicated security appliances.

9.3 Summary

Gustavo Morales | ISERTEC Guatemala Pág.


Securing RouterOS: Attack Detection & Defense Strategies | MikroTik Train the Trainer

Attack Tool Defense Layer


Port Scan Reduces reconnaissance Determined attacker uses slow
effectiveness scan (-T1)
Brute Force Blocks automated tools immediately Rotating IPs or distributed attacks
DoS Flood Protects router CPU and connection Volumetric attacks exceeding link
table capacity
Port Knocking Hides SSH from automated Known sequence can be captured
scanners via sniffing

Gustavo Morales | ISERTEC Guatemala | MikroTik TTT 2026

Gustavo Morales | ISERTEC Guatemala Pág.

You might also like