MikroTik RouterOS Whitelist-Based Anti-DDoS Configuration Guide

Executive Summary

This guide presents an advanced whitelist-based anti-DDoS configuration methodology for MikroTik RouterOS, specifically designed for high-traffic environments such as game server hosting. The architecture emphasizes legitimate traffic validation rather than attack pattern blocking, resulting in minimal false positives and robust protection against sophisticated DDoS attacks.

Core Principles:

• Whitelist-First Architecture: Only verified legitimate traffic reaches protected resources
• Multi-Layer Defense: Protection at RAW, Mangle, and Filter firewall chains
• Dynamic Adaptation: Automatic whitelist population based on validated traffic patterns
• Protocol-Aware: Specialized rules for TCP, UDP, and ICMP with game-specific logic
• Performance Optimized: Stateless operation with minimal latency overhead

Attack Mitigation Coverage:

• SYN Flood attacks
• UDP Amplification/Reflection attacks
• Application-layer (Layer 7) attacks
• Protocol exploitation attacks
• IP spoofing attacks
• Bot-driven attacks

---

Table of Contents

1. Architecture Overview
2. Design Philosophy
3. Network Topology Setup
4. Core System Configuration
5. Address List Strategy
6. RAW Firewall Chain Implementation
7. UDP Protection Layer
8. TCP Protection Layer
9. ICMP Protection Layer
10. Mangle Chain Configuration
11. Filter Chain Rules
12. Performance Optimization
13. Monitoring and Logging
14. Testing and Validation
15. Troubleshooting Guide

---

Architecture Overview

Traffic Processing Flow

Internet Traffic
    ↓
[RAW Chain: Pre-routing]
    ├─→ Anti-Spoofing
    ├─→ Whitelist Validation
    ├─→ Protocol Classification
    └─→ Rate Limiting
         ↓
[Mangle Chain: Packet Marking]
    ├─→ MSS Clamping
    ├─→ Traffic Shaping Marks
    └─→ QoS Classification
         ↓
[Filter Chain: Final Policy]
    ├─→ Port Filtering
    ├─→ Application Rules
    └─→ Egress Validation
         ↓
[Protected Infrastructure]

Defense Strategy Layers

Layer 1 - RAW Chain (Most Efficient):

• Processes packets before connection tracking
• Lowest CPU overhead
• Ideal for high packet-rate attacks
• Stateless operation

Layer 2 - Mangle Chain:

• Packet modification and marking
• Traffic classification
• MSS clamping for MTU optimization

Layer 3 - Filter Chain:

• Final policy enforcement
• Application-specific rules
• Port-based filtering

---

Design Philosophy

Why Whitelist-Based?

Traditional blacklist-based DDoS protection suffers from fundamental limitations:

❌ Blacklist Approach Problems:

• Reactive (blocks after attack detected)
• Requires constant updates
• Easily bypassed with IP rotation
• High false positive rates
• Resource-intensive pattern matching

✅ Whitelist Approach Benefits:

• Proactive (only known-good traffic allowed)
• Self-maintaining through dynamic validation
• Resistant to IP rotation attacks
• Near-zero false positives when properly configured
• Minimal CPU overhead

Dynamic Whitelist Population

The configuration automatically identifies and whitelists legitimate traffic through:

1. Protocol Signature Detection: Identifies valid client behavior patterns
2. Content Inspection: Validates application-specific protocol markers
3. Rate-Based Validation: Legitimate clients exhibit normal connection rates
4. Infrastructure Whitelisting: Pre-approved CDN, DNS, and platform IPs

Attack Mitigation Philosophy

Unknown Source → Validation Tests → Pass → Add to Whitelist → Allow Traffic
                                  ↓
                                Fail
                                  ↓
                         Rate Limit → Threshold Exceeded → Block

---

Network Topology Setup

Interface Configuration

Define your network interfaces with clear naming:

/interface ethernet
set [ find default-name=ether1 ] name=wan
set [ find default-name=ether2 ] name=client-network
set [ find default-name=ether3 ] name=server-network
set [ find default-name=ether4 ] name=uplink1
set [ find default-name=ether5 ] name=uplink2

Interface Roles:

• wan: Primary internet-facing interface
• client-network: Client-facing network segment
• server-network: Protected server infrastructure
• uplink1/uplink2: Redundant uplink connections

Link Aggregation (Optional)

For redundancy and increased bandwidth:

/interface bonding
add name=uplink-bond slaves=uplink1,uplink2 mode=802.3ad

Benefits:

• Automatic failover
• Load balancing
• Increased throughput

---

Core System Configuration

Connection Tracking - Critical Decision

Option 1: Disabled (Recommended for DDoS scenarios)

/ip firewall connection tracking
set enabled=no

Advantages:

• ✅ 10x higher packet processing capacity
• ✅ Eliminates connection table exhaustion
• ✅ 30-50% lower CPU utilization
• ✅ Immune to state-exhaustion attacks

Disadvantages:

• ❌ NAT requires connection tracking (use separate router for NAT)
• ❌ Stateful firewall rules won't work
• ❌ Connection tracking-based features unavailable

Option 2: Minimal Tracking (Hybrid approach)

/ip firewall connection tracking
set enabled=yes \
    tcp-established-timeout=1s \
    tcp-syn-sent-timeout=1s \
    tcp-syn-received-timeout=1s \
    tcp-close-timeout=1s \
    udp-timeout=1s \
    generic-timeout=1s \
    loose-tcp-tracking=yes

Use Case: When NAT is required but DDoS protection is still critical.

TCP/IP Stack Hardening

/ip settings
set rp-filter=strict \
    tcp-syncookies=yes \
    accept-redirects=no \
    accept-source-route=no \
    send-redirects=no

Parameter Explanation:

• rp-filter=strict: Reverse Path Filtering - prevents IP spoofing by verifying packet source
• tcp-syncookies=yes: SYN cookie protection against SYN flood attacks
• accept-redirects=no: Prevents ICMP redirect attacks
• accept-source-route=no: Blocks source routing attacks
• send-redirects=no: Prevents router from being used in redirect attacks

Service Minimization

Disable all unnecessary firewall helper services:

/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes

Rationale: Each enabled service-port creates additional connection tracking overhead and potential attack vectors.

Management Access Control

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=10.0.0.0/8 port=22022
set api disabled=yes
set winbox address=10.0.0.0/8 port=8291
set api-ssl disabled=yes

Security Best Practices:

• Disable all unnecessary management protocols
• Use non-standard ports
• Restrict access by source IP
• Consider VPN-only management access

---

Address List Strategy

Address List Architecture

Address lists are the foundation of whitelist-based filtering. They categorize traffic for efficient rule matching.

1. Protected Infrastructure

/ip firewall address-list
add address=203.0.113.10 list=protected-servers comment="Game Server 1"
add address=203.0.113.11 list=protected-servers comment="Game Server 2"
add address=203.0.113.0/24 list=protected-servers comment="Server Subnet"

Purpose: Defines all infrastructure requiring DDoS protection.

2. Trusted Infrastructure

DNS Servers:

add address=1.1.1.1 list=trusted-dns comment="Cloudflare DNS"
add address=1.0.0.1 list=trusted-dns comment="Cloudflare DNS"
add address=8.8.8.8 list=trusted-dns comment="Google DNS"
add address=8.8.4.4 list=trusted-dns comment="Google DNS"

CDN Networks (Example: Cloudflare):

add address=104.16.0.0/13 list=trusted-cdn comment="Cloudflare CDN"
add address=104.24.0.0/14 list=trusted-cdn comment="Cloudflare CDN"
add address=108.162.192.0/18 list=trusted-cdn comment="Cloudflare CDN"
add address=172.64.0.0/13 list=trusted-cdn comment="Cloudflare CDN"
add address=173.245.48.0/20 list=trusted-cdn comment="Cloudflare CDN"

Source: https://www.cloudflare.com/ips/

Game Platform Networks (Example: Steam):

add address=208.78.164.0/22 list=steam-network comment="Steam Content"
add address=155.133.224.0/19 list=steam-network comment="Steam Network"
add address=162.254.192.0/21 list=steam-network comment="Steam Network"

Game-Specific Infrastructure (Example: FiveM):

add address=178.32.9.100 list=fivem-infra comment="Keymaster"
add address=104.20.82.251 list=fivem-infra comment="Keymaster CDN"
add address=104.20.83.251 list=fivem-infra comment="Keymaster CDN"
add address=51.91.0.0/16 list=fivem-infra comment="Server List"

3. Dynamic Whitelists (Auto-Populated)

# UDP validated clients - 5 minute timeout
/ip firewall address-list
add list=udp-whitelist timeout=5m comment="Dynamic UDP whitelist"

# TCP validated clients - 5 minute timeout
add list=tcp-whitelist timeout=5m comment="Dynamic TCP whitelist"

# Detected attackers - 5 minute block
add list=blocked-attackers timeout=5m comment="Auto-blocked attackers"

Note: These are template entries. The lists are populated automatically by firewall rules.

4. Geographic Filtering (Optional)

For region-specific services, implement geographic IP filtering:

# Example: European Union IP ranges
add address=2.16.0.0/13 list=allowed-regions comment="EU Region"
add address=5.0.0.0/8 list=allowed-regions comment="EU Region"
# ... additional ranges

Sources for IP Lists:

• RIPE Database: https://www.ripe.net/
• IP2Location: https://lite.ip2location.com/
• MaxMind GeoIP: https://www.maxmind.com/

Important: Geographic lists require regular updates (weekly recommended).

5. Malware/Botnet Blacklists (Optional)

add address=192.0.2.50 list=known-malicious comment="Known botnet C2"

Sources:

• Spamhaus DROP list
• abuse.ch feeds
• Custom threat intelligence

---

RAW Firewall Chain Implementation

Why RAW Chain?

The RAW chain processes packets before routing and connection tracking, making it the most efficient filtering point:

• Performance: No connection state overhead
• DDoS Resilience: Cannot be exhausted by state table attacks
• Early Filtering: Drops malicious packets before resource consumption

Chain Structure Design

prerouting (entry point)
    ↓
general-validation
    ├─→ outbound-traffic
    └─→ inbound-traffic
            ├─→ udp-protection
            ├─→ tcp-protection
            └─→ icmp-protection

Base Chain Setup

/ip firewall raw

# Entry point - all traffic
add action=jump chain=prerouting jump-target=general-validation comment="Main entry point"

Anti-Spoofing Protection

# Outbound validation - traffic from protected servers
add action=jump chain=general-validation \
    in-interface=server-network \
    src-address-list=protected-servers \
    jump-target=outbound-traffic \
    comment="Validate outbound traffic"

# Inbound validation - traffic to protected servers  
add action=jump chain=general-validation \
    dst-address-list=protected-servers \
    jump-target=inbound-traffic \
    comment="Validate inbound traffic"

# Anti-spoofing: Drop traffic claiming to be from protected servers on wrong interface
add action=drop chain=general-validation \
    in-interface=!server-network \
    src-address-list=protected-servers \
    comment="Anti-spoofing protection"

# Accept all other traffic (not destined for protected infrastructure)
add action=accept chain=general-validation \
    comment="Accept non-protected traffic"

Outbound Traffic Rules

# Allow outbound from protected servers
add action=accept chain=outbound-traffic \
    src-address-list=protected-servers \
    comment="Allow outbound from protected infrastructure"

Inbound Traffic Classification

# Route to protocol-specific chains
add action=jump chain=inbound-traffic \
    protocol=udp \
    dst-address-list=protected-servers \
    jump-target=udp-protection \
    comment="UDP traffic protection"

add action=jump chain=inbound-traffic \
    protocol=tcp \
    dst-address-list=protected-servers \
    jump-target=tcp-protection \
    comment="TCP traffic protection"

add action=jump chain=inbound-traffic \
    protocol=icmp \
    dst-address-list=protected-servers \
    jump-target=icmp-protection \
    comment="ICMP traffic protection"

# Drop all other protocols to protected servers
add action=drop chain=inbound-traffic \
    dst-address-list=protected-servers \
    comment="Drop non-standard protocols"

---

UDP Protection Layer

UDP is the most common DDoS attack vector due to its stateless nature. Protection requires multi-stage validation.

UDP Protection Strategy

Stage 1: Trusted Infrastructure → Accept
Stage 2: Content Validation → Whitelist
Stage 3: Whitelist Check → Accept or Reject
Stage 4: Rate Limiting → Final Protection
Stage 5: Attack Detection → Block

Stage 1: Trusted Infrastructure

# DNS responses from trusted servers
add action=accept chain=udp-protection \
    protocol=udp \
    src-address-list=trusted-dns \
    src-port=53 \
    dst-address-list=protected-servers \
    dst-limit=50,50,src-and-dst-addresses/1m40s \
    comment="DNS responses from trusted servers"

# CDN traffic
add action=accept chain=udp-protection \
    protocol=udp \
    src-address-list=trusted-cdn \
    dst-address-list=protected-servers \
    dst-limit=100,100,src-and-dst-addresses/1m40s \
    comment="CDN traffic"

# Game platform infrastructure (example: Steam)
add action=accept chain=udp-protection \
    protocol=udp \
    src-address-list=steam-network \
    dst-address-list=protected-servers \
    dst-limit=100,100,src-and-dst-addresses/1m40s \
    comment="Steam network traffic"

Stage 2: Protocol Signature Detection

For game servers, detect legitimate client patterns:

Example: FiveM Server (GTA V Multiplayer)

# FiveM initial handshake detection
add action=add-src-to-address-list chain=udp-protection \
    protocol=udp \
    dst-address-list=protected-servers \
    dst-port=30120 \
    content="\\xFF\\xFF\\xFF\\xFF" \
    dst-limit=3,3,dst-address/1m40s \
    address-list=udp-whitelist \
    address-list-timeout=5m \
    comment="FiveM protocol signature detection"

add action=accept chain=udp-protection \
    protocol=udp \
    dst-address-list=protected-servers \
    dst-port=30120 \
    content="\\xFF\\xFF\\xFF\\xFF" \
    dst-limit=3,3,dst-address/1m40s \
    comment="Accept FiveM handshake"

Generic Game Server Pattern:

# Detect valid query patterns (adjust content based on your game protocol)
add action=add-src-to-address-list chain=udp-protection \
    protocol=udp \
    dst-address-list=protected-servers \
    dst-port=27015-27030 \
    packet-size=25-50 \
    dst-limit=5,5,src-address/1m40s \
    address-list=udp-whitelist \
    address-list-timeout=5m \
    comment="Game query pattern validation"

Stage 3: Whitelist Enforcement

# Accept traffic from validated sources
add action=accept chain=udp-protection \
    protocol=udp \
    src-address-list=udp-whitelist \
    dst-address-list=protected-servers \
    dst-limit=1000,1000,src-address/1m40s \
    comment="Accept whitelisted UDP sources"

# Accept game-specific validated clients
add action=accept chain=udp-protection \
    protocol=udp \
    src-address-list=fivem-infra \
    dst-address-list=protected-servers \
    dst-port=30120 \
    dst-limit=500,500,src-address/1m40s \
    comment="FiveM infrastructure whitelist"

Stage 4: Rate Limiting for Unknown Sources

# Allow limited traffic from unknown sources (for initial validation)
add action=accept chain=udp-protection \
    protocol=udp \
    dst-address-list=protected-servers \
    dst-limit=50,50,dst-address/1m40s \
    comment="Rate limit for unknown UDP sources"

Stage 5: Attack Detection and Blocking

# Log potential attacks
add action=log chain=udp-protection \
    protocol=udp \
    dst-address-list=protected-servers \
    dst-limit=5,5,dst-address/1m40s \
    log=yes \
    log-prefix="UDP-FLOOD-DETECT" \
    comment="Log UDP flood attempts"

# Block attacking sources
add action=add-src-to-address-list chain=udp-protection \
    protocol=udp \
    dst-address-list=protected-servers \
    dst-limit=20,20,dst-address/1m40s \
    address-list=blocked-attackers \
    address-list-timeout=5m \
    comment="Block UDP flood sources"

# Drop blocked attackers
add action=drop chain=udp-protection \
    protocol=udp \
    src-address-list=blocked-attackers \
    comment="Drop blocked attackers"

# Final drop with global rate limit
add action=drop chain=udp-protection \
    protocol=udp \
    dst-address-list=protected-servers \
    limit=50000,50000:packet \
    comment="Global UDP rate limit"

Rate Limit Parameters Explained:

• dst-limit=50,50,dst-address/1m40s: 50 packets per destination per 100 seconds
• dst-limit=1000,1000,src-address/1m40s: 1000 packets per source per 100 seconds
• limit=50000,50000:packet: Global 50,000 packets/second

Tuning Guidelines:

• Low traffic servers: Reduce limits to 25-100 packets/second
• High traffic servers: Increase limits to 2000-5000 packets/second
• Monitor and adjust: Use /ip firewall raw print stats to observe traffic patterns

---

TCP Protection Layer

TCP protection is more complex due to connection state requirements and various attack vectors.

TCP Protection Strategy

Stage 1: SYN Flood Protection (packet size-based)
Stage 2: Game-Specific Protocol Validation
Stage 3: Content-Based Filtering
Stage 4: Whitelist Enforcement
Stage 5: Connection Rate Limiting
Stage 6: Attack Detection

Stage 1: SYN Flood Protection

SYN packets come in different sizes based on TCP options. Each size range requires different handling:

40-47 Byte SYN Packets (Minimal options):

# Accept legitimate SYN rate
add action=accept chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    packet-size=40-47 \
    dst-limit=15,15,dst-address/1m40s \
    comment="Accept 40-47 byte SYN packets"

# Log excessive SYN
add action=log chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    packet-size=40-47 \
    dst-limit=2,2,dst-address/1m40s \
    log=yes \
    log-prefix="SYN-FLOOD-40-47" \
    comment="Log SYN flood 40-47"

# Block attacking sources
add action=add-src-to-address-list chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    packet-size=40-47 \
    dst-limit=25,25,dst-address/1m40s \
    address-list=blocked-attackers \
    address-list-timeout=5m \
    comment="Block SYN flood sources 40-47"

# Global rate limit
add action=drop chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    packet-size=40-47 \
    dst-address-list=protected-servers \
    limit=50000,50000:packet \
    comment="Global SYN rate limit 40-47"

48-59 Byte SYN Packets (Standard options):

# Accept legitimate SYN rate
add action=accept chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    packet-size=48-59 \
    dst-limit=20,20,dst-address/1m40s \
    comment="Accept 48-59 byte SYN packets"

# Attack detection and blocking (similar to 40-47)
add action=add-src-to-address-list chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    packet-size=48-59 \
    dst-limit=30,30,dst-address/1m40s \
    address-list=blocked-attackers \
    address-list-timeout=5m \
    comment="Block SYN flood sources 48-59"

60 Byte SYN Packets (Most common legitimate):

# Accept legitimate SYN rate (higher threshold)
add action=accept chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    packet-size=60 \
    dst-limit=50,50,dst-address/1m40s \
    comment="Accept 60 byte SYN packets"

# Attack detection
add action=add-src-to-address-list chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    packet-size=60 \
    dst-limit=100,100,dst-address/1m40s \
    address-list=blocked-attackers \
    address-list-timeout=5m \
    comment="Block SYN flood sources 60"

Stage 2: Game-Specific Protocol Validation

Example: FiveM Server Protection

# Track initial SYN from UDP-validated sources
add action=add-src-to-address-list chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    dst-port=30120 \
    src-address-list=udp-whitelist \
    packet-size=48-60 \
    dst-limit=50,50,dst-address/1m40s \
    address-list=fivem-initial-syn \
    address-list-timeout=5s \
    comment="Track FiveM initial SYN"

add action=accept chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    dst-port=30120 \
    src-address-list=udp-whitelist \
    packet-size=48-60 \
    dst-limit=50,50,dst-address/1m40s \
    comment="Accept FiveM initial SYN"

# Detect FiveM protocol signature (CitizenFX client)
add action=add-src-to-address-list chain=tcp-protection \
    protocol=tcp \
    content="CitizenFX" \
    dst-address-list=protected-servers \
    dst-port=30120 \
    src-address-list=fivem-initial-syn \
    dst-limit=25,25,dst-address/1m40s \
    address-list=fivem-infra \
    address-list-timeout=5m \
    comment="Validate CitizenFX client"

add action=accept chain=tcp-protection \
    protocol=tcp \
    content="CitizenFX" \
    dst-address-list=protected-servers \
    dst-port=30120 \
    src-address-list=fivem-initial-syn \
    dst-limit=25,25,dst-address/1m40s \
    comment="Accept CitizenFX traffic"

# Bot detection - authTicket abuse protection
add action=accept chain=tcp-protection \
    protocol=tcp \
    tcp-flags=ack \
    content="authTicket" \
    dst-address-list=protected-servers \
    dst-port=30120 \
    src-address-list=fivem-infra \
    dst-limit=3,3,src-address/1m40s \
    limit=10,10:packet \
    comment="Accept legitimate authTicket"

add action=add-src-to-address-list chain=tcp-protection \
    protocol=tcp \
    tcp-flags=ack \
    content="authTicket" \
    dst-address-list=protected-servers \
    dst-port=30120 \
    src-address-list=fivem-infra \
    dst-limit=50,50,dst-address/1m40s \
    address-list=blocked-attackers \
    address-list-timeout=5m \
    log=yes \
    log-prefix="FIVEM-BOT-DETECTED" \
    comment="Block FiveM bot attacks"

add action=drop chain=tcp-protection \
    protocol=tcp \
    content="authTicket" \
    dst-address-list=protected-servers \
    dst-port=30120 \
    src-address-list=fivem-infra \
    tcp-flags=ack \
    comment="Drop excessive authTicket"

Example: Minecraft Server Protection

# Minecraft uses 60-byte SYN packets
add action=accept chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    dst-port=25565 \
    packet-size=60 \
    src-address-list=tcp-whitelist \
    dst-limit=5,5,src-and-dst-addresses/1m40s \
    limit=10000,10000:packet \
    comment="Minecraft legitimate connections"

# Bot attack detection
add action=add-src-to-address-list chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    dst-port=25565 \
    packet-size=60 \
    src-address-list=tcp-whitelist \
    dst-limit=100,100,dst-address/1m40s \
    address-list=blocked-attackers \
    address-list-timeout=5m \
    log=yes \
    log-prefix="MINECRAFT-BOT-ATTACK" \
    comment="Block Minecraft bot sources"

Stage 3: Content-Based Filtering

Block HTTP/HTTPS traffic to game ports (common attack vector):

# Block HTTP User-Agent to game ports
add action=drop chain=tcp-protection \
    protocol=tcp \
    content="User-Agent" \
    dst-address-list=protected-servers \
    dst-port=30120,25565,27015 \
    comment="Block HTTP to game ports"

# Block Mozilla/browser traffic
add action=drop chain=tcp-protection \
    protocol=tcp \
    content="Mozilla" \
    dst-address-list=protected-servers \
    dst-port=30120,25565,27015 \
    comment="Block browser traffic to game ports"

# Block gzip encoding (HTTP-specific)
add action=drop chain=tcp-protection \
    protocol=tcp \
    content="gzip" \
    dst-address-list=protected-servers \
    dst-port=30120,25565,27015 \
    comment="Block gzip to game ports"

Stage 4: TCP Whitelist System

# Add sources with proper HTTP behavior to whitelist (for web services)
add action=add-src-to-address-list chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    dst-port=80,443 \
    dst-limit=2,2,src-address/1m40s \
    address-list=tcp-whitelist \
    address-list-timeout=5m \
    comment="Whitelist HTTP/HTTPS clients"

# Accept traffic from TCP whitelist
add action=accept chain=tcp-protection \
    protocol=tcp \
    tcp-flags=ack \
    src-address-list=tcp-whitelist \
    dst-address-list=protected-servers \
    src-port=80,443 \
    comment="Accept whitelisted TCP traffic"

Stage 5: Service-Specific Protection

RDP/SSH Brute Force Protection:

# Accept limited connection attempts
add action=accept chain=tcp-protection \
    protocol=tcp \
    dst-address-list=protected-servers \
    dst-port=22,3389 \
    dst-limit=10,10,dst-address/1m40s \
    comment="Rate limit RDP/SSH"

# Block brute force attempts
add action=add-src-to-address-list chain=tcp-protection \
    protocol=tcp \
    tcp-flags=syn \
    dst-address-list=protected-servers \
    dst-port=22,3389 \
    dst-limit=15,15,src-address/1m40s \
    address-list=blocked-attackers \
    address-list-timeout=1h \
    log=yes \
    log-prefix="BRUTEFORCE-DETECTED" \
    comment="Block brute force"

add action=drop chain=tcp-protection \
    protocol=tcp \
    dst-address-list=protected-servers \
    dst-port=22,3389 \
    tcp-flags=syn \
    comment="Drop excessive SSH/RDP"

Stage 6: Final TCP Protection

# Accept whitelisted sources with rate limit
add action=accept chain=tcp-protection \
    protocol=tcp \
    src-address-list=tcp-whitelist \
    dst-address-list=protected-servers \
    dst-limit=2000,2000,src-address/1m40s \
    comment="Accept TCP whitelist"

# Drop blocked attackers
add action=drop chain=tcp-protection \
    protocol=tcp \
    src-address-list=blocked-attackers \
    comment="Drop blocked TCP attackers"

# Final drop with global rate limit
add action=drop chain=tcp-protection \
    protocol=tcp \
    dst-address-list=protected-servers \
    limit=100000,100000:packet \
    comment="Global TCP rate limit"

---

ICMP Protection Layer

ICMP is commonly abused for amplification attacks and can overwhelm servers if not properly limited.

ICMP Protection Strategy

/ip firewall raw

# Accept ICMP from whitelisted sources (limited)
add action=accept chain=icmp-protection \
    protocol=icmp \
    src-address-list=udp-whitelist \
    dst-address-list=protected-servers \
    dst-limit=50,50,dst-address/1m40s \
    comment="Accept ICMP from whitelist"

# Rate limit unknown ICMP sources
add action=accept chain=icmp-protection \
    protocol=icmp \
    dst-address-list=protected-servers \
    dst-limit=10,10,dst-address/1m40s \
    comment="Rate limit ICMP"

# Log excessive ICMP
add action=log chain=icmp-protection \
    protocol=icmp \
    dst-address-list=protected-servers \
    dst-limit=2,2,dst-address/1m40s \
    log=yes \
    log-prefix="ICMP-FLOOD-DETECT" \
    comment="Log ICMP flood"

# Block ICMP flood sources
add action=add-src-to-address-list chain=icmp-protection \
    protocol=icmp \
    dst-address-list=protected-servers \
    dst-limit=20,20,dst-address/1m40s \
    address-list=blocked-attackers \
    address-list-timeout=5m \
    comment="Block ICMP flood sources"

# Drop all other ICMP
add action=drop chain=icmp-protection \
    protocol=icmp \
    dst-address-list=protected-servers \
    comment="Drop excessive ICMP"

ICMP Type-Specific Filtering (Optional):

# Allow only echo-request (ping) and echo-reply
add action=accept chain=icmp-protection \
    protocol=icmp \
    icmp-options=0:0,8:0 \
    dst-address-list=protected-servers \
    dst-limit=10,10,dst-address/1m40s \
    comment="Allow ICMP echo only"

# Drop all other ICMP types
add action=drop chain=icmp-protection \
    protocol=icmp \
    icmp-options=!0:0,!8:0 \
    dst-address-list=protected-servers \
    comment="Drop non-echo ICMP"

---

Mangle Chain Configuration

Mangle rules handle packet modification and traffic shaping preparation.

MSS Clamping

Prevents MTU/fragmentation issues:

/ip firewall mangle

add action=change-mss chain=forward \
    new-mss=clamp-to-pmtu \
    passthrough=yes \
    protocol=tcp \
    tcp-flags=syn \
    comment="MSS clamping for optimal MTU"

Alternative: Fixed MSS

add action=change-mss chain=forward \
    new-mss=1400 \
    passthrough=yes \
    protocol=tcp \
    tcp-flags=syn \
    tcp-mss=1401-65535 \
    out-interface=wan \
    comment="Fix MSS to 1400"

When to use:

• PPPoE connections: MSS=1452
• Standard Ethernet: MSS=1460
• VPN tunnels: MSS=1300-1400

Traffic Marking (Optional)

For QoS/traffic shaping:

# Mark game server traffic for priority
add action=mark-packet chain=prerouting \
    dst-address-list=protected-servers \
    dst-port=30120,25565,27015 \
    new-packet-mark=game-traffic \
    passthrough=no \
    comment="Mark game traffic for QoS"

# Mark management traffic
add action=mark-packet chain=prerouting \
    dst-address-list=protected-servers \
    dst-port=22,3389 \
    new-packet-mark=management-traffic \
    passthrough=no \
    comment="Mark management traffic"

---

Filter Chain Rules

Filter chain provides final policy enforcement for traffic that passed RAW and Mangle chains.

Basic Filter Rules

/ip firewall filter

# Accept established/related (if connection tracking enabled)
add action=accept chain=forward \
    connection-state=established,related \
    comment="Accept established connections"

# Drop invalid packets
add action=drop chain=forward \
    connection-state=invalid \
    comment="Drop invalid packets"

Port-Based Filtering

# Block SMB (common malware vector)
add action=drop chain=forward \
    protocol=tcp \
    port=445,139 \
    comment="Block SMB"

# Block NetBIOS
add action=drop chain=forward \
    protocol=udp \
    port=137,138 \
    comment="Block NetBIOS"

# Block common exploit ports
add action=drop chain=forward \
    protocol=tcp \
    dst-port=135,139,445,1433,3306 \
    comment="Block common exploit ports"

Egress Filtering

Prevent compromised servers from participating in attacks:

# Rate limit outbound traffic from protected servers
add action=accept chain=forward \
    src-address-list=protected-servers \
    dst-limit=5000,5000,dst-address/1m40s \
    limit=100000,100000:packet \
    comment="Rate limit outbound traffic"

# Block outbound to known malicious destinations
add action=drop chain=forward \
    src-address-list=protected-servers \
    dst-address-list=known-malicious \
    log=yes \
    log-prefix="OUTBOUND-MALICIOUS" \
    comment="Block outbound to malicious IPs"

---

Performance Optimization

Hardware Selection

Minimum Requirements:

• CPU: Multi-core x86-64 or ARM64
• RAM: 512MB
• Storage: 128MB
• Network: 1Gbps interfaces minimum

Recommended for High-Traffic:

• MikroTik CCR series (10Gbps+)
• RB4011 or RB5009 (1-5Gbps)
• x86 PC with RouterOS CHR (flexible scaling)

CPU Optimization

/system hardware
set allow-x86-64=yes

/interface ethernet
# Enable hardware offloading where supported
set [find] rx-flow-control=on tx-flow-control=on

Rule Optimization

Performance Best Practices:

1. Order rules by frequency: Most common matches first
2. Use address lists: More efficient than multiple IP rules
3. Minimize logging: Log only attack detection, not every drop
4. Use jumps: Separate chains for protocol-specific rules
5. Disable unused features: Connection tracking if not needed

Memory Management

# Monitor memory usage
/system resource print

# Increase firewall memory if available
/ip firewall connection tracking
set max-entries=500000

---

Monitoring and Logging

NetFlow/IPFIX Export

/ip traffic-flow
set enabled=yes \
    cache-entries=256k \
    active-flow-timeout=30m \
    inactive-flow-timeout=15s

/ip traffic-flow target
add address=203.0.113.100 port=2055 version=9

SNMP Monitoring

/snmp
set enabled=yes \
    contact="Network Admin" \
    location="Data Center" \
    trap-community=public \
    trap-interfaces=all

/snmp community
set [find default=yes] name=monitoring addresses=203.0.113.0/24

Syslog Configuration

/system logging action
add name=remote-syslog \
    remote=203.0.113.100 \
    remote-port=514 \
    target=remote

/system logging
add action=remote-syslog topics=firewall,info
add action=remote-syslog topics=error,critical

Real-Time Monitoring

# Watch firewall logs
/log print follow where topics~"firewall"

# Monitor RAW chain statistics
/ip firewall raw print stats

# Check dynamic address lists
/ip firewall address-list print where dynamic=yes

# Monitor resource usage
/system resource print interval=1

Graphing

/tool graphing interface add
/tool graphing queue add
/tool graphing resource add

Access graphs at: http://<router-ip>/graphs/

---

Testing and Validation

Pre-Deployment Testing

1. Verify Address Lists

/ip firewall address-list print where list=protected-servers
/ip firewall address-list print where list=trusted-dns
/ip firewall address-list print where list=trusted-cdn

2. Rule Order Verification

/ip firewall raw print
/ip firewall filter print

3. Connectivity Testing

From a client:

# Test UDP connectivity
nc -u <server-ip> 30120

# Test TCP connectivity
telnet <server-ip> 30120

# Test ICMP
ping <server-ip>

Attack Simulation

SYN Flood Test:

# Requires hping3 tool
hping3 -S -p 30120 --flood --rand-source <target-ip>

Expected Behavior:

• Initial packets accepted
• Rate limits triggered
• Source blocked after threshold
• Server remains responsive

UDP Amplification Test:

# Send random UDP data
while true; do
    echo "random data" | nc -u <target-ip> 30120
done

Expected Behavior:

• Non-whitelisted source blocked immediately
• No service impact

Performance Benchmarking

RouterOS Bandwidth Test:

# On protected server
/tool bandwidth-server set enabled=yes authenticate=no

# From client router
/tool bandwidth-test <server-ip> protocol=tcp duration=60s
/tool bandwidth-test <server-ip> protocol=udp duration=60s

Metrics to Monitor:

• Throughput: Should be >90% of interface capacity
• Latency: <5ms added by firewall
• Packet loss: <0.1%
• CPU usage: <70% under load

---

Troubleshooting Guide

Common Issues and Solutions

Issue 1: Legitimate Traffic Blocked

Symptoms:

• Users unable to connect
• Timeouts or connection resets

Diagnosis:

# Check if source is blocked
/ip firewall address-list print where list=blocked-attackers

# View recent drops
/log print where message~"DROP" or message~"FLOOD"

# Check RAW statistics
/ip firewall raw print stats where action=drop

Solutions:

# Remove false positive from block list
/ip firewall address-list remove [find where list=blocked-attackers and address=<IP>]

# Manually whitelist legitimate source
/ip firewall address-list add address=<IP> list=udp-whitelist timeout=1h
/ip firewall address-list add address=<IP> list=tcp-whitelist timeout=1h

# Adjust rate limits (increase thresholds)
# Edit the dst-limit parameters in your rules

Issue 2: High CPU Usage

Symptoms:

• CPU constantly >80%
• Increased latency
• Packet drops

Diagnosis:

/system resource print
/tool profile

# Check rule hit counts
/ip firewall raw print stats

Solutions:

1. Optimize rule order:

# Move most-hit rules to top of chain
# Check stats and reorder accordingly

2. Reduce address list size:

# Remove unused entries
/ip firewall address-list remove [find where list=blocked-attackers and timeout<1m]

3. Disable verbose logging:

# Remove logging from high-frequency rules

4. Upgrade hardware or reduce protected infrastructure

Issue 3: Address List Overflow

Symptoms:

• Memory warnings
• Whitelist not working
• "out of memory" errors

Diagnosis:

/system resource print
/ip firewall address-list print count-only where list=udp-whitelist
/ip firewall address-list print count-only where list=tcp-whitelist

Solutions:

1. Reduce timeout values:

# Change 5m timeout to 2m in whitelist rules
address-list-timeout=2m

2. Implement periodic cleanup script:

/system scheduler add name=cleanup-whitelist interval=5m on-event={
    /ip firewall address-list remove [find where list=udp-whitelist and timeout<1m]
    /ip firewall address-list remove [find where list=tcp-whitelist and timeout<1m]
}

3. Increase router memory (upgrade hardware)

Issue 4: False Positive Attack Detection

Symptoms:

• Legitimate users blocked
• Frequent "FLOOD-DETECT" logs during normal traffic

Diagnosis:

/log print where message~"FLOOD"
/ip firewall address-list print where list=blocked-attackers

Solutions:

1. Increase rate limit thresholds:

# Change from dst-limit=10,10 to dst-limit=50,50
# Adjust based on your traffic patterns

2. Whitelist specific sources:

/ip firewall address-list add address=<trusted-IP-range> list=udp-whitelist

3. Review and tune detection rules

Issue 5: Game-Specific Connection Issues

FiveM Issues:

# Verify FiveM infrastructure whitelist
/ip firewall address-list print where list=fivem-infra

# Check content detection
/log print where message~"CitizenFX"

# Ensure UDP validation is working
/ip firewall address-list print where list=udp-whitelist

Minecraft Issues:

# Check 60-byte SYN handling
/ip firewall raw print stats where comment~"minecraft"

# Verify TCP whitelist
/ip firewall address-list print where list=tcp-whitelist

Debug Mode

Enable detailed firewall logging:

/system logging add topics=firewall,debug action=memory
/log print follow

Packet capture:

/tool sniffer quick interface=server-network ip-protocol=tcp port=30120 duration=60

Connection tracking (if enabled):

/ip firewall connection print where protocol=tcp

---

Security Best Practices

1. Regular Maintenance Schedule

Daily:

• Review firewall logs for attacks
• Check blocked-attackers list
• Monitor resource usage

Weekly:

• Update address lists (CDN, game platforms)
• Review rule statistics
• Backup configuration

Monthly:

• Analyze attack trends
• Tune rate limiting thresholds
• Test disaster recovery
• Update RouterOS (test in staging first)

Quarterly:

• Full security audit
• Performance benchmarking
• Capacity planning review

2. Configuration Backup

# Manual export
/export file=antiddos-backup

# Automated daily backup
/system scheduler add name=daily-backup interval=1d on-event={
    /export file=backup-$[/system clock get date]
}

# Optional: Upload to remote server
/tool fetch address=backup.example.com \
    src-path=backup-$[/system clock get date].rsc \
    user=backup password=secret mode=ftp upload=yes

3. Change Management

Document all changes:

• Date and time
• Change description
• Reason for change
• Rollback plan
• Testing results

Version control your configuration:

• Use Git for configuration exports
• Maintain separate dev/staging/production
• Test all changes in non-production first

4. Monitoring and Alerting

Set up alerts for:

• CPU usage >80% for 5+ minutes
• Memory usage >90%
• High packet drop rate
• Unusual number of blocked IPs
• New attack patterns detected

5. Incident Response

Attack detected:

1. Verify attack is real (not false positive)
2. Identify attack vector
3. Document attack characteristics
4. Implement additional mitigation if needed
5. Post-incident review and rule tuning

---

Advanced Customization Examples

Adding New Game Server Type

Example: Rust Server (port 28015)

# Add server to protected list
/ip firewall address-list add address=<rust-server-ip> list=protected-servers

# UDP protection for Rust queries
/ip firewall raw add chain=udp-protection \
    protocol=udp \
    dst-address-list=protected-servers \
    dst-port=28015-28016 \
    dst-limit=100,100,src-address/1m40s \
    action=accept \
    comment="Rust server queries" \
    place-before=0

# TCP protection for Rust RCON
/ip firewall raw add chain=tcp-protection \
    protocol=tcp \
    dst-address-list=protected-servers \
    dst-port=28016 \
    dst-limit=10,10,src-address/1m40s \
    action=accept \
    comment="Rust RCON" \
    place-before=0

Geographic Filtering

To restrict access to specific countries:

# Download and add country IP ranges to address list
/ip firewall address-list
add address=192.0.2.0/24 list=allowed-countries comment="Country-US"
add address=198.51.100.0/24 list=allowed-countries comment="Country-US"
# ... add all ranges

# In RAW chain, accept only from allowed countries
/ip firewall raw add chain=inbound-traffic \
    src-address-list=allowed-countries \
    dst-address-list=protected-servers \
    action=jump jump-target=udp-protection \
    protocol=udp \
    place-before=0

# Drop all other countries
/ip firewall raw add chain=inbound-traffic \
    src-address-list=!allowed-countries \
    dst-address-list=protected-servers \
    action=drop \
    log=yes \
    log-prefix="GEO-BLOCK"

API-Based Dynamic Whitelist

Script to update whitelists from external API:

# Schedule script to run every 5 minutes
/system scheduler add name=update-whitelist interval=5m on-event={
    :local apiUrl "https://api.example.com/trusted-ips"
    :local filename "trusted-ips.txt"
    
    # Fetch trusted IPs from API
    /tool fetch url=$apiUrl dst-path=$filename
    
    # Process and add to whitelist
    # (requires scripting to parse file and add IPs)
}

---

Performance Tuning Matrix

Rate Limit Guidelines by Traffic Level

Traffic Level	SYN/sec	UDP pps	TCP Whitelist	UDP Whitelist
Low (<100 users)	10-20	500-1000	2m timeout	2m timeout
Medium (100-500)	50-100	2000-5000	5m timeout	5m timeout
High (500-2000)	100-200	5000-10000	10m timeout	10m timeout
Very High (2000+)	200-500	10000-50000	15m timeout	15m timeout

Hardware Recommendations by Protected Traffic

Traffic	Router Model	CPU Cores	RAM	Notes
<1 Gbps	RB4011	4	1GB	Good for small deployments
1-5 Gbps	RB5009	4	1GB	ARM64 architecture
5-10 Gbps	CCR2004	4	4GB	Enterprise-grade
10+ Gbps	CCR2116	16	16GB	High-performance
Custom	CHR (x86)	8+	8GB+	Maximum flexibility

---

Conclusion

This whitelist-based anti-DDoS configuration provides robust, scalable protection for high-value infrastructure while maintaining performance and minimizing false positives. The key advantages are:

✅ Proactive Defense: Only validated traffic reaches protected resources
✅ Self-Adapting: Dynamic whitelists automatically learn legitimate patterns
✅ Protocol-Aware: Game-specific rules optimize protection
✅ Performance: Stateless RAW chain operation minimizes overhead
✅ Scalable: Address list architecture grows with your infrastructure

Key Takeaways

1. Customize for your environment: Rate limits and timeouts must match your traffic patterns
2. Monitor continuously: Use logs and statistics to tune rules
3. Test thoroughly: Validate configuration before production deployment
4. Document changes: Maintain detailed records of modifications
5. Keep updated: Regularly update address lists and RouterOS

Next Steps

1. Adapt configuration: Replace generic IPs and ports with your infrastructure
2. Test in staging: Validate rules don't block legitimate traffic
3. Deploy incrementally: Enable protection gradually to identify issues
4. Monitor and tune: Adjust thresholds based on real traffic patterns
5. Maintain regularly: Update lists and review logs weekly

---

Additional Resources

Official Documentation

• MikroTik RouterOS Firewall

Community Resources

• MikroTik Forum
• MikroTik Wiki

IP Lists and Threat Intelligence

• Cloudflare IP Ranges
• AWS IP Ranges
• Azure IP Ranges
• GeoIP Databases
• Spamhaus DROP List

---

Disclaimer

⚠️ IMPORTANT LEGAL AND SAFETY NOTICE

This configuration guide is provided for educational and legitimate defensive security purposes only.