FIREWALL / QUICKSTART

Harden a fresh MikroTik, one paste at a time.

Four numbered steps. Each gives you a snippet you can read, paste, and verify before moving on. Reads in about 10 minutes; the full script at the bottom is copy-and-go when you've already understood the parts.

⚠ Before you paste

If your management session is over WAN, the rules below can lock you out. Have console access ready (serial cable on a CCR / hAP, or Winbox on the LAN side of a separate device).

01 · Clean slate

Remove any previous mikrotikfilters rules so re-runs are idempotent. We namespace everything we add with a mtkf: comment prefix and a mtkf- address-list prefix so this regex match is precise — we never touch rules you wrote.

01-clean.rsc v6 5 lines · 171 bytes

# 1. clean slate — remove any previous mikrotikfilters rules
/ip firewall filter
  remove [find comment~"^mtkf:"]
/ip firewall address-list
  remove [find list~"^mtkf-"]

01-clean.rsc v7 5 lines · 171 bytes

# 1. clean slate — remove any previous mikrotikfilters rules
/ip/firewall/filter
  remove [find comment~"^mtkf:"]
/ip/firewall/address-list
  remove [find list~"^mtkf-"]

02 · Fetch the scanners list

Pull the curated scanners list as an .rsc over HTTPS and import it. The same add list=mtkf-scanners … syntax works on v6 and v7, so this step is shared.

02-fetch.rsc 5 lines · 212 bytes

# 2. fetch the scanners list and import it as an address-list
/tool fetch mode=https \
  url="https://mikrotikfilters.com/api/lists/scanners.rsc" \
  dst-path=mtkf-scanners.rsc
/import file-name=mtkf-scanners.rsc

Verify the import worked:

/ip firewall address-list print count-only where list=mtkf-scanners

03 · Drop scanner traffic

One rule on the input chain (drops scans hitting the router itself) and one on the forward chain (drops scans aimed at NATted hosts behind the router). Both rules sit at the top of their chains; everything else falls through to your existing rules.

03-drop.rsc v6 8 lines · 290 bytes

# 3. drop scanner traffic on the input chain
/ip firewall filter
  add chain=input action=drop \
    src-address-list=mtkf-scanners \
    comment="mtkf: drop scanners (input)"
  add chain=forward action=drop \
    dst-address-list=mtkf-scanners \
    comment="mtkf: drop scanners (forward)"

03-drop.rsc v7 8 lines · 278 bytes

# 3. drop scanner traffic on the input chain
/ip/firewall/filter
add chain=input action=drop \
  src-address-list=mtkf-scanners \
  comment="mtkf: drop scanners (input)"
add chain=forward action=drop \
  dst-address-list=mtkf-scanners \
  comment="mtkf: drop scanners (forward)"

Why the syntax differs

RouterOS v6

v6 uses space-separated paths (/ip firewall filter).

RouterOS v7

v7 prefers slash-separated paths (/ip/firewall/filter) but accepts the v6 form for compatibility. We use the v7-native form on v7 because it's clearer in editors.

04 · Schedule a daily refresh

The list updates as new scanner ranges are reported. A daily fetch is enough for the volume — the worst case is a one-day delay on new entries. The schedule command itself is the same on v6 and v7.

04-schedule.rsc 3 lines · 251 bytes

# 4. schedule a daily refresh — set-and-forget
/system scheduler add name=mtkf-refresh interval=1d \
  on-event="/tool fetch mode=https url=\"https://mikrotikfilters.com/api/lists/scanners.rsc\" dst-path=mtkf-scanners.rsc; /import mtkf-scanners.rsc"

A note on the daily pull cap

Anonymous fetches are capped at 10 pulls per day per IP across all our lists combined (PLAN.md §3.4). If you schedule 15 lists, the last 5 return 429 and your scheduler logs an error. The fix is either (a) cull the list to 10, or (b) become a supporter — supporters get a higher cap and the bundle builder which combines many lists into a single fetch.