Перейти до вмісту
-Advanced
UA RU
093 442 18 08 Консультація

Post

Аудит безпеки MikroTik RouterOS: що перевірити в корпоративній мережі

MikroTik може бути невеликим пристроєм із дуже широкою зоною впливу. Через нього часто проходять офісний інтернет, VPN, зв'язок між філіями, телефонія, гостьовий Wi-Fi та доступ до бізнес-систем. Слабке правило створює вразливість, а непідготовлене виправлення може зупинити роботу мережі. Під час аудиту потрібно враховувати обидва ризики.

Безпечний початок - перевірка в режимі read-only. Спочатку фіксують фактичний стан, зіставляють конфігурацію з реальною мережею та визначають пріоритети. Універсального firewall-скрипта для цього немає: правильна політика залежить від інтерфейсів, VLAN, VPN-маршрутів, опублікованих сервісів і способу відновлення зв'язку.

Оновлення безпеки RouterOS від 3 вересня 2026 року
MikroTik повідомила про вразливість у RouterOS і назвала оновлення важливим. Деталі проблеми виробник поки не розкриває, щоб дати адміністраторам час оновити пристрої. Виправлення включене до 7.25 beta 3, 7.24.2, 7.23.4 та 6.49.21. Для гілки 7.23 потрібно врахувати наступний випуск 7.23.5: він додатково виправляє проблему IPv6 DHCP, внесену в 7.23.4.

Що робити з важливим оновленням RouterOS

Це не ситуація для сліпого натискання Update посеред робочого дня. MikroTik рекомендує оновитися, але маршрутизатор може одночасно обслуговувати інтернет, NAT, VPN, VLAN, DHCP, телефонію та резервного провайдера. Спочатку потрібно встановити фактичну версію, вибрати реліз для своєї гілки й підготувати відновлення.

1. Перевірте версію та канал без змін

У терміналі RouterOS виконайте read-only команди:

/system/resource/print
/system/package/update/print
/system/routerboard/print

Зафіксуйте:

  • версію RouterOS;
  • канал оновлень;
  • модель і архітектуру пристрою;
  • версію RouterBOARD firmware;
  • вільне місце;
  • установлені додаткові пакети.

Не робіть висновок лише за повідомленням у WinBox. Потрібно знати, що встановлено на кожному пристрої, включно з резервними роутерами, CAPsMAN-контролерами та вузлами у філіях.

2. Виберіть виправлений реліз для своєї гілки

MikroTik вказує такі випуски з виправленням:

  • 7.25 beta 3;
  • 7.24.2;
  • 7.23.4;
  • 6.49.21.

Якщо пристрій використовує гілку 7.23, не зупиняйтеся на 7.23.4 без окремої перевірки. 4 вересня вийшла 7.23.5, яка усуває термінову проблему IPv6 DHCP, внесену попереднім релізом. Для production потрібно оцінювати актуальний наступний випуск своєї гілки, а не механічно ставити першу версію зі списку security fix.

Виробник поки не опублікував технічні деталі вразливості. Тому не можна достовірно назвати вразливий сервіс, умови експлуатації, CVE, affected range або ознаки атаки, яких MikroTik не підтвердила. Формулювання "most configurations are not at risk" також не дозволяє самостійно вважати конкретний офіс безпечним.

3. Підготуйте backup і спосіб повернути доступ

До оновлення потрібно мати:

  • зашифрований binary backup поза маршрутизатором;
  • текстовий export для аналізу конфігурації;
  • локальний або out-of-band доступ;
  • список критичних функцій;
  • погоджене maintenance window;
  • критерії відкату.

Binary backup і export мають різне призначення. Наявність файлу без перевірки способу відновлення не є готовим rollback plan.

Окремо запишіть, що має працювати після перезавантаження: обидва WAN, DHCP, DNS, публічні NAT, WireGuard або IPsec, маршрути між VLAN, телефонія, CAPsMAN і віддалений моніторинг.

4. Перевірте changelog і сумісність

Перед зміною версії інженер перевіряє не тільки security announcement, а й повний changelog цільового та наступного релізу. Для цього оновлення вже є практичний приклад: 7.23.4 містила security fix, але внесла проблему IPv6 DHCP, виправлену в 7.23.5.

Особливої уваги потребують:

  • старі моделі RouterBOARD;
  • RouterOS 6 і перехід на RouterOS 7;
  • CAPsMAN та wireless packages;
  • BGP, OSPF і policy routing;
  • IPv6 DHCP;
  • IPsec і WireGuard;
  • контейнерні пакети;
  • нестандартні скрипти та scheduler jobs.

Цей список не означає, що виробник підтвердив проблему в кожному пункті. Це перелік функцій, які потрібно перевірити після зміни RouterOS, якщо вони використовуються у вашій мережі.

5. Оновлюйте у контрольованій послідовності

Для одного офісного роутера потрібне погоджене вікно та локальний шлях відновлення. Для кількох пристроїв спочатку оновлюють менш критичний або тестовий вузол з аналогічною конфігурацією. Не варто одночасно змінювати RouterOS на всіх філіях без перевірки першого результату.

Після встановлення пакета перевірте RouterBOARD firmware. Його оновлення та додаткове перезавантаження планують окремо, якщо поточна й доступна версії відрізняються.

6. Після оновлення перевірте Flagged status і конфігурацію

MikroTik повідомляє, що після оновлення RouterOS перевіряє пристрій на ознаки компрометації. Якщо система виявить підозрілу конфігурацію, пристрій може отримати статус Flagged, а в Log з'явиться critical entry.

Read-only перевірка:

/system/device-mode/print
/log/print where topics~"critical"

Якщо flagged: yes, не скидайте прапорець лише для відновлення заблокованої функції. MikroTik рекомендує вважати систему скомпрометованою, провести повний аудит налаштувань, а потім змінити паролі й використовувати актуальну RouterOS.

Навіть за flagged: no перевірте:

  • невідомих користувачів і групи прав;
  • SSH keys та сертифікати;
  • scripts і scheduler;
  • firewall, NAT та address lists;
  • socks, proxy, SMB, VPN clients і tunnels;
  • DNS static entries;
  • незнайомі файли;
  • зміни management services.

Відсутність Flagged status не є доказом, що конфігурація безпечна. Сам виробник окремо радить перевірити невідомі scripts, users та інші незнайомі зміни.

7. Прийміть роботу за сервісами

Оновлення завершене, коли пройдено acceptance checklist:

  • RouterOS має погоджену виправлену версію;
  • пристрій завантажився без помилок;
  • основний і резервний інтернет працюють;
  • DHCP видає правильні параметри;
  • DNS працює з користувацьких VLAN;
  • публічні NAT доступні лише там, де це потрібно;
  • VPN відновили тунелі;
  • міжмережеві правила не змінили потрібну сегментацію;
  • CAPsMAN і точки доступу підключені;
  • час і NTP коректні;
  • віддалений syslog та моніторинг отримують події;
  • Flagged перевірено;
  • версія, час і результати тесту задокументовані.

Якщо після 7.23.4 використовується IPv6 DHCP, не обмежуйтеся перевіркою IPv4. Перевірте видачу IPv6-параметрів або перейдіть на випуск, де MikroTik усунула внесену проблему.

Коли потрібна термінова допомога

Залучайте інженера до оновлення, якщо WinBox, SSH або WebFig доступні з інтернету, немає актуального backup, невідомі залежності VPN/NAT, пристрій обслуговує кілька філій або після перезавантаження з'явився Flagged.

IT Advanced може провести read-only перевірку версії, доступів, конфігурації та плану відновлення, а потім окремо погодити оновлення й post-change test.

CTA: Перевірити та безпечно оновити MikroTik

Для первинної оцінки достатньо моделі MikroTik, поточної версії RouterOS, каналу оновлень і короткого опису ролі пристрою. Паролі, приватні ключі та повний export через форму не надсилайте.

Бізнес-ознаки, за яких MikroTik варто перевірити

Для аудиту не обов'язково чекати на ознаки атаки. Достатня причина - невизначеність у керуванні пристроєм. Зверніть увагу на такі симптоми:

  • ніхто не може назвати встановлену версію RouterOS і пояснити вибір каналу оновлень;
  • невідомо, чи доступні WinBox, SSH, WebFig або API з боку WAN;
  • кілька людей користуються одним обліковим записом адміністратора;
  • після звільнення працівника або зміни підрядника залишилися користувачі, ключі чи VPN peers;
  • єдина резервна копія зберігається на самому маршрутизаторі;
  • гостьові пристрої, камери або IoT можуть бачити офісні системи;
  • резервний провайдер налаштований, але перемикання безпечно не перевіряли;
  • частина firewall rules не має власника, пояснення або строку дії;
  • після перезавантаження зникають логи, потрібні для розбору збою;
  • зміни залежать від однієї людини, яка пам'ятає топологію.

Ці ознаки не доводять компрометацію. Вони показують, що пристрій на межі мережі перебуває під недостатнім операційним контролем.

Що має встановити read-only аудит

Перший етап не повинен вимикати сервіси, пересувати правила чи оновлювати пакети. Для доступу використовують наявний довірений канал керування. Відкривати WinBox в інтернет спеціально для аудиту не можна.

1. Пристрій, версії та готовність до відновлення

Зафіксуйте модель, версію RouterOS, встановлені пакети, RouterBOARD firmware, вільне місце та канал оновлень. Окремо запишіть функції, які мають відновитися після перезавантаження: інтернет, публічні NAT, VPN, маршрути між VLAN, телефонія та перемикання провайдера.

Застарілий випуск створює ризик, але сам номер версії ще не визначає порядок змін. До оновлення інженеру потрібні відомості про сумісність обладнання та пакетів, зміни в цільовому випуску, список перевірок і реальний спосіб повернути локальний доступ, якщо пристрій не завантажиться штатно.

Перевірте наявність зашифрованого бінарного backup і текстового export, збережених поза маршрутизатором через погоджений захищений канал. Ці файли мають різне призначення. Export допомагає аналізувати й документувати налаштування; backup використовують для відновлення з урахуванням пристрою та версії RouterOS. Неперевірений файл підтверджує лише наявність копії, але не готовність відновити мережу.

2. Адміністративний доступ

Проведіть інвентаризацію локальних користувачів, груп прав, SSH-ключів, сертифікатів і зовнішньої автентифікації, якщо вона використовується. Доступ кожного працівника або підрядника має бути персональним і відкликатися без заміни спільного пароля для всіх.

Потім перевірте сервіси керування RouterOS як єдину систему: WinBox, SSH, WebFig, API, API-SSL, FTP і Telnet. Потрібно встановити, що ввімкнено, на яких портах працює та з яких мереж доступне. Нестандартний порт може зменшити автоматичний шум, але не замінює firewall, обмеження довірених джерел і VPN для віддаленого керування.

IP-контролю недостатньо. У локальних L2-сегментах MAC WinBox, MAC Telnet, MAC Ping, Neighbor Discovery та RoMON можуть залишати доступ до керування або розкривати інформацію про пристрій. Особливо уважно перевіряють їхню доступність на гостьових, публічних та інших недовірених портах.

3. Firewall і фактична експозиція

Трафік до самого маршрутизатора перевіряють окремо від трафіку через нього. У RouterOS ланцюг input захищає сервіси MikroTik, зокрема керування, DNS і VPN endpoints. Ланцюг forward контролює потоки між WAN, LAN, VLAN та віддаленими мережами. IPv6 також потребує окремої перевірки, навіть якщо основна схема побудована на IPv4.

Правила читають у встановленому порядку разом з interface lists, address lists, NAT і маршрутами. Шукають надто широкі дозволи, невикористані правила, тимчасові винятки без власника, неочікувані лічильники та логування, якого або недостатньо, або забагато. Не можна вставляти новий ruleset, доки не відомі топологія та дозволені потоки. Типовий набір правил може пропустити реальну загрозу або повністю відрізати офіс від мережі.

4. DNS, VPN і поділ мережі

Якщо маршрутизатор приймає DNS-запити від клієнтів, визначте дозволені мережі та перевірте, чи не доступний TCP/UDP 53 з боку WAN. Також варто переглянути upstream DNS, статичні записи й неочікувані перенаправлення. DNS cache для офісу не повинен випадково працювати як публічний сервіс.

Для кожного remote-access або site-to-site VPN зіставте peer із власником і конкретною задачею. Перевірте дозволені адреси, маршрути, доступні підмережі, DNS і firewall на VPN interface. Має бути зрозуміло, як швидко відкликати доступ. Зашифрований тунель може працювати правильно, але надавати користувачу значно більше прав, ніж потрібно.

Порівняйте налаштовані VLAN і підмережі з реальними групами пристроїв: працівники, сервери, телефонія, принтери, камери, IoT, гості та керування. VLAN сам по собі не є політикою доступу. Аудит має показати, які потоки між сегментами потрібні для роботи, а які можливі лише через відсутність обмежень.

5. Логи та контроль змін

З'ясуйте, чи можуть наявні логи відповісти на практичні запитання: хто входив, що змінилося, коли впав VPN, чи перемикався провайдер і що відбувалося перед перезавантаженням. Важливі записи доцільно передавати на віддалену систему, бо логи в оперативній пам'яті зникають саме після події, яку потрібно розібрати. Записувати кожен відхилений пакет теж не варто: на завантаженому пристрої це приховує корисні сигнали та витрачає ресурси.

На завершення конфігурацію зіставляють із документацією. Мінімальний робочий опис містить фізичні підключення, провайдерів, адресацію, VLAN, DHCP, власників VPN, публічні сервіси, призначення нестандартних правил, місця зберігання копій і відповідального за погодження змін. Якщо схема та маршрутизатор не збігаються, робочу конфігурацію фіксують як факт, а розбіжність вносять до звіту.

Як розставити пріоритети

Знахідки слід ранжувати за експозицією та впливом на роботу, а не за порядком меню RouterOS.

  1. Негайне обмеження експозиції. Сюди належать керування з недовірених мереж, публічний DNS, невідомі привілейовані користувачі, застарілі віддалені доступи та прохід із гостьових сегментів до службових ресурсів. Навіть термінові обмеження потребують погодженого шляху доступу, щоб команда не заблокувала сама себе.
  2. Перешкоди для відновлення. Відсутність придатної зовнішньої копії, локального доступу, параметрів провайдерів або способу відкату. Усунення цих прогалин робить наступні security-зміни безпечнішими.
  3. Надмірні права. Широкі VPN-маршрути, слабка сегментація, незрозумілі винятки firewall і спільні облікові записи.
  4. Планове зміцнення. Оновлення RouterOS і firmware, видалення застарілих сервісів, обмеження discovery, корекція логування та документації. Такі роботи об'єднують у контрольовані зміни з перевірками після виконання.

Кожен пункт звіту має містити спостережуваний стан, відповідний інтерфейс або сервіс, можливий вплив на бізнес, запропонований результат і спосіб його перевірити. Якщо даних недостатньо, це також потрібно вказати.

Чеклист перед будь-якою зміною

  • Підтвердити фізичний пристрій і поточний шлях керування.
  • Визначити людину на майданчику, якщо може знадобитися локальне відновлення.
  • Зберегти зашифрований backup і очищений від секретів export поза маршрутизатором.
  • Зафіксувати критичні маршрути, NAT, VPN, VLAN і параметри провайдерів.
  • Описати очікуваний результат і перевірити його з потрібних сегментів мережі.
  • Підготувати відкат до редагування firewall або маршрутизації.
  • Виконувати зміни окремими зрозумілими наборами та зберігати історію.
  • Не надсилати паролі, приватні ключі або повні файли конфігурації через публічну форму.

Коли потрібен інженер MikroTik

Залучайте інженера, якщо маршрутизатор є єдиним шляхом до production-систем, топологія не задокументована, а доступ можливий лише віддалено. Фахова робота також потрібна, коли firewall, NAT, policy routing і VPN взаємодіють у спосіб, який команда не може впевнено змоделювати; коли оновлення охоплює суттєві зміни RouterOS; після підозри на компрометацію; або коли відновлення ніколи не перевіряли.

Якщо маршрутизатор є лише частиною ширшої проблеми, перевірку варто поєднати з аудитом кібербезпеки. Мережева політика обмежує трафік, але не показує, чи належно захищені сервери, робочі місця, пошта, облікові записи та резервні копії.

Що має містити результат аудиту

  • інвентаризацію пристрою, версій і шляхів керування;
  • знахідки, пов'язані з фактичною конфігурацією та схемою мережі;
  • пріоритети за експозицією, ризиком відновлення та впливом на бізнес;
  • окремий план змін із залежностями та способом відкату;
  • перевірки зв'язку, VPN, публічних сервісів і сегментації після робіт;
  • відкриті питання, для яких не вдалося підтвердити власника або призначення.

Початковий аудит може повністю залишатися read-only. Будь-які дії, здатні вплинути на зв'язок, погоджують і виконують окремо за наявності можливості відновлення.

Питання перед аудитом MikroTik

Чи можна провести аудит MikroTik без зміни конфігурації?

Так. На першому етапі можна інвентаризувати версії, користувачів, сервіси, firewall, DNS, VPN, логи та резервні копії в режимі read-only. Виправлення оформлюють окремим погодженим планом.

Чи безпечно залишати WinBox відкритим в інтернет?

Ні. Для віддаленого керування потрібен захищений шлях, а WinBox або SSH слід дозволяти лише з довірених джерел. Відкритий для всіх адрес сервіс не є безпечною схемою.

Чи достатньо змінити стандартний порт WinBox?

Ні. Інший порт може зменшити фонове сканування, але не визначає, хто має право підключатися. Потрібні обмеження джерел, firewall, захищений шлях керування та персональні облікові записи.

Чи достатньо просто оновити RouterOS?

Не автоматично. Аудит фіксує поточну версію та ризики. Оновлення виконують лише після перевірки сумісності, резервних копій, способу відновлення та тестів після перезавантаження.

Чим backup відрізняється від export?

Backup є бінарною копією для відновлення з урахуванням пристрою та версії RouterOS. Export подає налаштування у текстовому вигляді для аналізу й документування. Для керованого відновлення потрібні обидва формати та захищене зберігання поза маршрутизатором.

Чи можна перевірити MikroTik віддалено?

Так, якщо вже існує захищений канал керування та зрозумілий порядок відновлення. Не потрібно відкривати management service з боку WAN спеціально для перевірки.

Коли повторювати аудит MikroTik?

Після зміни топології, провайдера, адміністратора або VPN, перед значним оновленням, після інциденту чи незрозумілої зміни конфігурації. Планову періодичність визначають за критичністю мережі та процесом керування змінами.

Обговорити аудит MikroTik

IT Advanced може почати з погодженої read-only перевірки та підготувати пріоритетні знахідки до обговорення будь-яких змін. Для першої розмови достатньо моделі MikroTik, відомої версії RouterOS, ролі пристрою та короткого опису мережі. Паролі, приватні ключі й файли конфігурації через форму надсилати не потрібно.

Обговорити аудит MikroTik