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.

01 · Clean slate

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

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

# 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 matchers are identical across versions; only the command path differs — /tool fetch on v6, /tool/fetch on v7.

# 2. fetch the scanners list and import it as an address-list
# check-certificate=yes is NOT the RouterOS default — without it the
# router accepts any certificate. See "Why check-certificate=yes" below.
/tool fetch mode=https check-certificate=yes \
  url="https://mikrotikfilters.com/api/lists/scanners.rsc" \
  dst-path=mtkf-scanners.rsc
/import file-name=mtkf-scanners.rsc

# 2. fetch the scanners list and import it as an address-list
# check-certificate=yes is NOT the RouterOS default — without it the
# router accepts any certificate. See "Why check-certificate=yes" below.
/tool/fetch mode=https check-certificate=yes \
  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

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

Why check-certificate=yes

RouterOS does not validate TLS certificates by default —check-certificate ships as no, somode=https alone gets you encryption without knowing who's on the other end. Anyone able to intercept the connection can hand your router their own certificate and their own list. That list becomes your firewall's drop rules, so we set the flag explicitly in every snippet we publish.

If the fetch fails with a certificate error after you set it, your router is missing a CA — import the trust anchors once with/certificate and the daily pull works from then on. Also note that http-max-redirect-count defaults to 0: our list URLs are terminal (they answer 200 directly, no redirect), so the default is correct and you don't need to raise it.

For the same reason the URL must start with https://, exactly as published. An http:// URL answers 301 to thehttps:// form, and because RouterOS does not follow redirects by default the fetch fails with no useful diagnostic — it simply never downloads. If a scheduled pull mysteriously does nothing, check the scheme first: copy the URL from the list page rather than typing it.

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.

# 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)"

# 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)"

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 scheduler entry is the same idea on v6 and v7; only the menu paths differ (/system scheduler vs /system/scheduler, and the embedded /tool fetch vs /tool/fetch).

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

# 4. schedule a daily refresh — set-and-forget
/system/scheduler add name=mtkf-refresh interval=1d \
  on-event="/tool/fetch mode=https check-certificate=yes 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. 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.