Device-mode on RouterOS: the physical lock on dangerous features

In short: device-mode is a lock RouterOS puts on some powerful features (containers, bandwidth test, sniffer, proxy…): they stay off until you turn them on with a physical confirmation on the router — a button press or a power cycle. It exists to stop anyone who gets in remotely, even with the administrator password, from using those features to attack others. In this card we see how it is built, how to read it, and how to change it without locking yourself out.

What is device-mode for?

It limits what can be done on the router even with administrator credentials. It is a second lock, built for a specific case: an intruder who gets in remotely and would like to turn your router into a base for hitting others — generating traffic, sniffing, opening a proxy. With device-mode those features do not turn on from software: they ask for proof that someone is physically in front of the device.

It was introduced with RouterOS 7.17: from later versions it ships pre-configured from the factory. Older routers all start in advanced mode, the most permissive one.

How do I look at it?

A single command shows the active mode and the state of every feature:

/system device-mode print

             mode: advanced
 allowed-versions: 7.13+,6.49.8+
          flagged: no
       bandwidth-test: yes
            container: no
              sniffer: yes
             ...
        attempt-count: 0

The yes/no lines say which features are allowed. flagged is the “under watch” state (more on that below), and attempt-count counts how many change attempts you made without confirming them.

What are the four modes?

Each mode is a different list of allowed features. There is no mode that turns them all on: some (traffic generator, containers, partitions) stay off always, until you enable them by hand. The four modes are:

• advanced — the most permissive, meant for high-end devices. It leaves almost everything on; it keeps off only traffic-gen, container, partitions, install-any-version and the routerboard settings.
• home — the most closed, meant for home routers. It turns off about fifteen features, including scheduler, proxy, hotspot, sniffer, bandwidth-test, socks.
• basic — a middle ground for every other device: it leaves fetch, scheduler, sniffer, romon on, but keeps off bandwidth-test, hotspot, proxy, socks, zerotier.
• rose — like advanced, but meant for devices with disks: it is the only one that allows containers from the factory.

You can also adjust a single feature without changing mode (for example turning on just container on a mode that keeps it off): every adjustment, though, needs the same physical confirmation.

How do you change it (without locking yourself out)?

The change is requested from software, but it has no effect until you confirm it on the device. Example: turning containers on.

/system device-mode update container=yes

  update: please activate by turning power off or pressing
          reset or mode button in 5m00s

The router now waits. You have five minutes (the default activation-timeout, tunable from 10 seconds to 1 day) to do one of these:

• press the device’s reset or mode button, or
• cut and restore power (a “cold reboot”).

On confirmation, the router reboots and the change becomes active. If you do not confirm in time, the request lapses and nothing changes. On a virtual machine (a CHR) the “physical confirmation” is a reset of the VM from the hypervisor: it still takes access below RouterOS, not inside it.

⚠️ Warning: unconfirmed attempts are counted, and after three the router locks. Every update left to lapse raises attempt-count. Past three, RouterOS refuses further changes with an explicit message:

  update: too many unsuccessful attempts, turn off power
          or reboot ... to reset attempt-count

The counter resets only with a power cycle or a button press. It is deliberate: it stops a script from trying forever and from using one of your reboots to slip a change through unnoticed.

What happens if I try to use a disabled feature?

The command is refused at once, with a clear error:

/tool sniffer quick
failure: not allowed by device-mode

You can even add the configuration for a disabled feature, but it stays inert: in print it shows up with a note “inactivated, not allowed by device-mode” until you enable that feature.

What is the “allowed-versions” list?

It is a protection against downgrades. The allowed-versions line lists the RouterOS versions MikroTik considers safe. It does not depend on the installed version: it is a separate layer that stops an attacker from walking the router back, step by step, to an old vulnerable release and then hitting it. When you upgrade to a version with a newer list, the old one is overwritten. The barrier only drops if you turn on install-any-version — which, as a rule, you do not want.

What is the “flagged” state?

It is the tamper alarm. At boot RouterOS analyses the configuration for signs of unauthorized access; if it finds any, it disables the suspicious configuration and sets flagged: yes.

/system device-mode print
     mode: advanced
  flagged: yes

From then on the router keeps working, but it blocks the most sensitive actions: bandwidth test, traffic generator, sniffer, and the creation of new rules for scheduler, socks, pptp, l2tp, ipsec, proxy, smb (deleting or disabling them is still allowed). The message is unmistakable:

failure: configuration flagged, check all router configuration
         for unauthorized changes and update device-mode

To get out of it you run /system device-mode update flagged=no with the usual physical confirmation.

⚠️ Warning: if the router has been “flagged”, treat it as compromised. RouterOS has disabled the rules it judged malicious, but before leaving the flagged state check all the configuration by hand, change every password and upgrade to the latest version. The flagged state is a symptom, not the disease.

Does device-mode survive a reset?

Yes: a reset-configuration brings the configuration back to factory values, but it does not change device-mode — it stays as set. Device-mode is only touched with the confirmed procedure seen above, or, from version 7.22, during an install with Netinstall or FlashFig, where the features can be pre-set.