News
Безпека MikroTik Device-Mode
Дізнайтеся, як device-mode RouterOS обмежує ризиковані інструменти, навіщо він потрібен і як планувати розгортання та впровадження MKController.
Огляд Device-mode — це постійний шлюз можливостей RouterOS для підсистем високого ризику: fetch, scheduler, SOCKS-проксі, bandwidth-test, контейнери та інші. Він знаходиться нижче прав користувача, тому навіть повний адміністратор не може увімкнути певні інструменти без фізичного підтвердження натисканням кнопки або циклом живлення. Цей посібник пояснює, як він працює, чому MikroTik запровадила його після епохи ботнету Mēris, як він розвивався від RouterOS v7.4 до v7.22, і як планувати розгортання, щоб впровадження MKController пройшло гладко.
Що таке device-mode RouterOS?
Device-mode — це постійний стан безпеки RouterOS, який вирішує, що може робити сама ОС, незалежно від того, який користувач увійшов у систему. Він знаходиться нижче прав користувача: навіть сеанс повного адміністратора не може увімкнути певні інструменти високого ризику, якщо політика device-mode цього не дозволяє, і межа безпеки стає “ваш пароль плюс фізичний доказ того, що хтось може торкнутися пристрою.”
Device-mode відрізняється від Safe Mode. Safe Mode захищає вас від блокування конфігурації під час інтерактивних змін (він відкочує зміни при від’єднанні сеансу). Device-mode — це довготривала політика можливостей, яка переживає перезавантаження та оновлення — як тільки функція заблокована, кожне перезавантаження зберігає блокування, доки явне фізичне підтвердження не скасує рішення.
Чому MikroTik запровадила device-mode
Зловмисники навчилися перетворювати граничні маршрутизатори на зброю інтернет-масштабу. Ботнет Mēris став переломним моментом — скомпрометовані пристрої MikroTik використовувалися як ретранслятори та генератори трафіку, зловживаючи функціями, легітимними для мережевих інженерів, але руйнівними при захопленні: SOCKS-проксі для тунелювання атакуючого трафіку, bandwidth-test для ампліфікації, scheduler + fetch для персистентності та доставки корисного навантаження.
Device-mode застосовує принцип найменших привілеїв на рівні платформи, щоб одні лише вкрадені облікові дані не змогли перемкнути найризикованіші тумблери. Межа безпеки стає “ваш пароль плюс фізичний доказ того, що хтось може торкнутися пристрою.”
Рукостискання фізичного підтвердження
Якщо ви намагаєтеся перевести обмежену функцію з no у yes, RouterOS приймає запит, але залишає його в очікуванні. Ви повинні підтвердити локально натисканням кнопки або холодним перезавантаженням у межах налаштованого таймауту, інакше RouterOS відкидає зміну. Для віддалених майданчиків плануйте, як відбудеться необхідне відключення живлення — розумний PDU, керований PoE-інжектор або руки на місці. Device-mode не замінює файрвол чи права користувача — він знаходиться нижче них як остання лінія оборони.
Режими, прапори та що блокується
Device-mode налаштовується під /system/device-mode. Внутрішньо це набір булевих прапорів, що контролюють конкретні підсистеми. Прапори, які зустрічаються в реальних операціях:
fetch— блокує/tool/fetchта будь-яку автоматизацію, що залежить від нього.scheduler— блокує/system/schedulerта заплановані скрипти.socks— блокує увімкнення SOCKS-проксі.bandwidth-testіtraffic-gen— блокують BTest та генерацію трафіку.container— блокує контейнери RouterOS, якщо явно не увімкнено.partitionsтаrouterboard— блокують низькорівневі зміни сховища та налаштувань завантаження.install-any-version/allowed-versions— обмежують шляхи відкату, які повертають старі вразливості.
Новіші версії RouterOS запровадили визначені режими, які групують прапори за рівнем обладнання:
| Режим | Рівень обладнання | Позиція | Ключові обмеження за замовчуванням |
|---|---|---|---|
| advanced | CCR, 1100, топове | Дозвільна | container, traffic-gen, install-any-version |
| home | hAP, cAP, SOHO | Строга | scheduler, fetch, socks, bandwidth-test, sniffer |
| basic | Стандартні RB, комутатори | Збалансована | socks, bandwidth-test, proxy, zerotier |
| rose | RDS, вуличний wireless | Особливе використання | Те саме, що advanced, але з container=yes |
Новий пристрій може прийти з обмежувальною позицією, яка ламає вашу стандартну автоматизацію, поки ви це не врахуєте.
Еволюція версій
Device-mode перетворився зі спеціалізованого контролю контейнерів на комплексний фреймворк. Уперше з’явився у v7.4beta, прив’язаний до підтримки контейнерів — перша функція, що вимагала /system/device-mode/update container=yes і натискання кнопки. v7.13 (та бекпорт v6.49.8) запровадила allowed-versions для блокування атак відкату проти старих CVE. v7.17 (початок 2025) принесла визначені режими за рівнем обладнання з автоматичним призначенням режиму під час оновлення. v7.19–v7.22 вирішили “глухий кут автоматизації” — v7.22rc3 (лютий 2026) додала можливість налаштувати device-mode через Netinstall та FlashFig за допомогою “mode script”, дозволивши ISP визначати стан безпеки під час початкової прошивки замість натискання кнопок на тисячах пристроїв.
Стан flagged та біль розгортання
RouterOS може позначити пристрій як flagged, коли виявляє підозрілі шаблони (втручання у файли, поведінку типу персистентності), і застосовує суворіший безпечний стан. Лічильник спроб також блокує подальші оновлення device-mode після повторних невдалих спроб змін без фізичного підтвердження. Коли лічильники виглядають несподівано, спочатку розслідуйте — не вмикайте більше функцій, щоб “змусити працювати.”
Шаблон глухого кута розгортання: маршрутизатор завантажується в обмежувальному режимі, скрипт першого завантаження потребує /tool/fetch для завантаження конфігурації, fetch заблокований, бутстрап провалюється, пристрій ніколи не досягає стану, де можливе віддалене виправлення. Новіші робочі процеси розгортання виправляють це через mode scripts Netinstall/FlashFig. Зверніть увагу, що /system/reset-configuration НЕ скидає device-mode на багатьох моделях — припущення “скидання дорівнює заводським” можуть вас здивувати.
Як безпечно увімкнути потрібну функцію
Коли вам легітимно потрібна заблокована можливість, використовуйте передбачувану процедуру:
-
Перевірте поточний стан:
/system/device-mode/print -
Запросіть зміну з таймаутом:
/system/device-mode/update fetch=yes activation-timeout=10m -
Виконайте фізичне підтвердження — натисніть кнопку Mode/Reset (залежить від моделі) або виконайте холодне перезавантаження пристрою.
-
Перевірте:
/system/device-mode/print
Якщо таймаут закінчується до підтвердження, RouterOS відкидає очікувану зміну та зберігає стару політику.
Матриця ввімкнення на основі ризиків
| Можливість | Типова легітимна потреба | Головний ризик | Безпечніший підхід |
|---|---|---|---|
fetch | Завантажувати конфіги, оновлювати сертифікати | Віддалена доставка корисного навантаження | Дозволяти лише до відомих HTTPS-кінцевих точок; обмежити вихід |
scheduler | Резервні копії, завдання обслуговування | Персистентність | Тримати скрипти мінімальними; стежити за несподіваними завданнями |
socks | Внутрішнє тунелювання | Ретранслятор ботнету | Прив’язати лише до керуючої VLAN; обмежити файрволом |
traffic-gen / bandwidth-test | Тести каналу | DoS / ампліфікація | Вмикати лише у вікнах обслуговування |
container | Запуск сервісів на маршрутизаторі | Довготривала персистентність | Надавати перевагу виділеним серверам; посилити сховище та файрвол |
Вплив на впровадження MKController
MKController залежить від передбачуваного керуючого доступу; device-mode може стати невидимим ручним гальмом під час онбордингу. Якщо він блокує необхідну дію, потік впровадження зависає — симптом часто виглядає як “пристрій доступний, але завдання провалюються.” Посібник з усунення несправностей MKController спеціально виділяє Device-Mode disabled. Плануйте це: включіть політику device-mode у свій контрольний список підготовки, вирішіть, які прапори дозволені перед відправкою, і задокументуйте, як фізичне підтвердження відбуватиметься на кожному майданчику. Для пов’язаного контексту безпеки дивіться наші посібники найкращі практики безпеки Winbox і віддалене керування WireGuard.
Контрольний список після оновлення
Після кожного оновлення RouterOS або при отриманні нового обладнання: підтвердіть, що поточний режим відповідає політиці; перевірте інструменти, від яких ви залежите (fetch, scheduler); перевірте allowed-versions у регульованих середовищах; огляньте attempt-count і стан flagged на аномалії; задокументуйте, які майданчики потребують фізичного підтвердження і як.
Зробіть наступний крок
Device-mode — це необхідна інфраструктура безпеки, але додає операційні витрати в масштабі, де фізичне підтвердження на віддалених майданчиках не можна імпровізувати. MKController централізує інвентар, керування доступом і видимість, щоб ви торкалися device-mode лише коли це виправдано, а фізичний крок був запланованим, а не реактивним.