Security

Advisories from NVD

Once a day the manager pulls the MikroTik RouterOS slice of the NVD feed and matches every record's affected version ranges against the RouterOS version each device reported at its last poll. Nothing is stored per device — the matching is done on the fly, so it costs the same whether you run five routers or five hundred.

It is informational, always. A matched advisory never blocks an upgrade, a command or anything else; it changes what you see, not what you can do.

The same roll-up feeds three other places, so you do not have to open this page to notice: a banner on the dashboard when High or Critical advisories affect at least one device, a badge on the device cards, and a Security Advisories card on the device's own page. All four are scoped — a user limited to some sites sees only the devices in them.

The honest limit is coverage. MikroTik's presence in NVD is patchy: plenty of real RouterOS issues are fixed with a line in a changelog and never receive a CVE number at all. An empty first tab means "nothing in NVD matches", not "you are safe" — which is exactly why there is a second tab.

The Security item appears in the sidebar only while the CVE feed is enabled. Turning it off in Settings removes the page along with the dashboard banner and the badges.

Vendor patches

The second tab reads MikroTik's own release changelogs and asks a narrower question: has a security release shipped on the branch this device runs, and is the device below it?

That is a weaker claim than a CVE match, and the two are deliberately never merged. A CVE record states the versions that are affected. A changelog states only the version that fixes something — it never says which versions were vulnerable. Merging the two would mean inventing an affected range, so the tabs stay separate and say different things.

Only branches actually present in your fleet are fetched. MikroTik publishes no index of releases, so each branch is probed by version number — 7.23, then 7.23.1, 7.23.2 and so on up to twenty patch releases, stopping after three consecutive misses. Security-relevant lines are those MikroTik itself marked with !), plus any line naming a CVE or mentioning security.

Comparison stays inside the device's own branch. MikroTik routinely fixes one issue across several branches at once and the changelog never states which other branches were affected, so the manager does not guess on your behalf.

Why the text is snapshotted

The first time a release's security lines are seen they are saved verbatim, and re-checked daily afterwards. If MikroTik edits the text after publication, the tab shows the release under "changelog edited upstream" with the removed and replacement lines side by side.

This is not hypothetical. RouterOS 7.23.2 shipped with the line !) ppp - fixed CVE-2026-59108;, which was later replaced with vaguer wording — and that CVE identifier appears in no public registry. Whatever was published first is what the manager keeps.

Auto-block

The third tab watches the syslog stream for hostile behaviour and can push the source address into a firewall address-list across the whole fleet. It is off by default, and it does nothing at all until your routers are sending logs to the manager — see the Logs page, which is the prerequisite, not an optional extra.

What counts as a signal

Both kinds feed the same counter. Attempts are aggregated per source address across every device in the fleet, in a sliding window — five attempts within ten minutes by default. An address that hits the threshold becomes a candidate; a slow scan spread over several routers looks, and is treated, like a slow brute-force against one.

RouterOS emits the same failure line whether the username was wrong or only the password was, so the manager treats every login failure equally. Denied connects are noisier by nature, which is why they are opt-in.

Two modes

Audit is the default: candidates are listed with their attempt counts, and an administrator blocks by hand. Auto-block blocks at the threshold without asking. The switch is the "Auto-block" setting; everything else about the two modes is identical.

Reading the candidate, blocked and whitelist tabs is open to every role. Blocking, unblocking and editing the whitelist are administrator actions.

What a block actually does

Blocking adds one address-list entry per opted-in device, with RouterOS's own timeout so the entry expires on the router itself:

/ip firewall address-list add list=mikr-blocklist address=<IP> timeout=259200s comment=mikr-ids

That is the whole of it. The manager maintains the list and nothing else — it never creates, edits or reorders a firewall rule. The drop rule is yours to add, once per device, and until you do, a blocked address is listed and still gets through:

/ip firewall raw add chain=prerouting src-address-list=mikr-blocklist action=drop comment="mikr-ids"

If you change the address-list name in Settings, the drop rule has to reference the new name. The default is mikr-blocklist.

Entries go only to devices whose "Auto-block (IDS)" field is set to Yes on the device form — off for every device until you set it. A device that is offline when a block is issued has the entry recorded as pending and pushed the next time the manager sees it come online, with whatever remains of the original timeout. Unblocking removes the entry from every opted-in device that is reachable at that moment.

The whitelist

Private ranges — RFC1918, ULA, link-local and loopback — are excluded by default, so only public addresses are ever blocked; that behaviour is a setting you can turn off. The manager's own address is always excluded. Beyond that, the Whitelist tab takes CIDRs or single addresses by hand: your admin network, a monitoring host, an office range that occasionally fat-fingers a password. A whitelisted address never becomes a candidate in the first place.

Switching auto-block on

1. Get logs flowing

   Configure the routers to send syslog to the manager and confirm entries are arriving with the right device names attached. Nothing below works without this.

2. Enable the feature

   Settings, Auto-block / IDS section: turn Enabled on. Leave Auto-block off for now — audit mode first.

3. Whitelist yourself

   Add your management ranges on the Whitelist tab before anything can be blocked, and check that "Never block private IPs" matches how you reach the routers.

4. Opt devices in

   Set "Auto-block (IDS)" to Yes on the devices that should receive the list. The bulk-edit action on the Devices page can do this for a selection in one go.

5. Add the drop rule

   One rule per device, referencing the address-list. A template on the Command Templates page is a convenient way to push the same rule to every router.

6. Watch, then arm

   Let audit mode run for a few days and read the candidate list. If the addresses it names are the ones you would have blocked yourself, turn Auto-block on.

Thresholds, the window, the block duration, the address-list name and both whitelist behaviours all take effect immediately — none of them needs a restart.

GeoIP rules

The GeoIP generator builds a RouterOS script that fills an address-list from country zone files and installs firewall rules against it. It lives on the Command Templates page, where the Security page links to it, and it is available to administrators.

Generating a rule creates a Script-type template in the Security category. It does not touch a router. Installing it is a separate, deliberate step — the template's Deploy button puts the script into /system/script on the devices you select, and does not run it; you run it from the router, or with a scheduler.

The two modes

Blocklist drops traffic matching the countries you selected. You choose the direction — inbound, outbound or both — and the chain: raw/prerouting is the default and the cheapest, because it matches before connection tracking, while filter works on input and forward.

Allowlist inverts it: everything whose source is not in the selected countries is dropped. This mode forces the filter chain, because connection state is not available in raw, and the direction and chain choices above are ignored. It also builds in three safeguards, because an allowlist is how people lock themselves out of a router:

• established, related and untracked connections are accepted first, so your current session survives the rule that lands after it
• private ranges, plus any addresses you list under "always allow", go into a second address-list that is accepted before the drop
• if the country list came out empty — a failed download, a mistyped country — the drop rule is not installed at all and the script logs a warning instead. Failing open is the deliberate choice: src-address-list=!list against an empty list matches every source on earth

What the script does on the router

Address data comes from the aggregated country zones published by ipdeny.com — IPv4 by default, with IPv6 as a separate set of zones you can add. Every run first removes its own rules and address-list entries, matched by the geoip-mikr comment, then rebuilds them, so re-running never duplicates anything.

The download is done in 64 000-byte HTTP range windows concatenated into a single script variable. That is not premature cleverness; it is the only shape that works. On RouterOS 7.22.1, /file get contents returns nothing at all for files over roughly 50 KB, and a single /tool fetch … as-value is capped at 64 512 bytes — China's aggregated zone is 85 536 bytes, so one fetch silently yielded 4 149 of its 5 504 prefixes. Chunked and reassembled, the same list loads complete in about four and a half seconds.

The optional weekly refresh adds a scheduler entry on the device that re-runs the script by name. It uses the name offered by the Deploy dialogue, so if you rename the script on the way in, edit selfName in the script body to match.

Before you deploy one

• The account the script runs as needs read, write and test permissions — test is what /tool fetch requires.
• Large countries mean tens of thousands of prefixes. On a low-RAM RouterBOARD that is a real cost; check the model before pointing it at CN, US or RU.
• Country-level address data is approximate by nature, and the manager passes on whatever ipdeny.com publishes without second-guessing it.