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

Запись

Аудит безопасности MikroTik RouterOS: что проверить в корпоративной сети

Маршрутизатор MikroTik редко обслуживает только выход в интернет. На нем могут сходиться офисная сеть, VPN сотрудников, связь с филиалами, гостевой Wi-Fi, телефония, камеры и резервный провайдер. Поэтому аудит должен отвечать на два вопроса: где возможен несанкционированный доступ и сможет ли компания безопасно исправить проблему, не потеряв связь.

Начинать следует без изменений конфигурации. Сначала инженер фиксирует фактическое состояние RouterOS, сопоставляет его со схемой сети и выделяет риски. Команды на изменение, обновление пакетов и замена firewall относятся уже к отдельному плану работ.

Обновление безопасности 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;
  • контейнерные пакеты;
  • нестандартные scripts и 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 через форму не отправляйте.

По каким признакам видно, что контроль потерян

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

Ни один пункт сам по себе не подтверждает взлом. Это признаки того, что пограничное устройство работает без достаточной наблюдаемости и управляемого восстановления.

Безопасная диагностика в режиме read-only

Для первичного обследования не требуется переставлять правила, отключать сервисы или запускать обновление. Нужен существующий защищенный канал управления и заранее понятный способ вернуть доступ, если связь прервется по независимой причине. Специально открывать WinBox в интернет нельзя.

Паспорт устройства и роль в сети

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

Такой список нужен до обсуждения обновления. Устаревшую версию нельзя игнорировать, но и обновлять рабочий маршрутизатор только ради нового номера рискованно. Сначала проверяют совместимость, изменения в нужном выпуске, возможность локального доступа и набор тестов после перезагрузки.

Резервные копии и реальное восстановление

Проверьте наличие зашифрованного бинарного backup и текстового export. Копии должны храниться вне маршрутизатора в согласованном защищенном месте. Export удобен для анализа и документирования; backup используют для восстановления с учетом устройства и версии RouterOS. Это не взаимозаменяемые файлы.

Само наличие архива еще ничего не говорит о готовности к аварии. Нужны дата копии, описание провайдеров и адресации, порядок возврата к рабочему состоянию и человек, который сможет получить локальный доступ. Если этих данных нет, сначала устраняют риск невосстановимости, а затем меняют security policy.

Учетные записи и каналы администрирования

Составьте список пользователей, групп прав, ключей SSH, сертификатов и внешней аутентификации, если она применяется. Для каждого привилегированного доступа должны быть понятны владелец, назначение и способ отзыва. Общий пароль не позволяет установить, кто выполнил изменение, и усложняет отключение одного подрядчика.

Далее инвентаризируйте WinBox, SSH, WebFig, API, API-SSL, FTP и Telnet. Важно выяснить не только факт включения, но и доступные адреса, порты, исходные сети и интерфейсы. Перенос WinBox на другой порт уменьшает случайный шум, но не закрывает сервис от постороннего доступа. Для управления извне нужен защищенный маршрут, например согласованный VPN, а доступ разрешают только доверенным источникам.

Отдельно проверяют MAC WinBox, MAC Telnet, MAC Ping, Neighbor Discovery и RoMON. Эти механизмы работают в локальном L2-домене и могут остаться доступными на гостевых или других недоверенных портах, даже если IP firewall выглядит аккуратно.

Firewall: защита самого MikroTik и транзитного трафика

В RouterOS цепочки input и forward решают разные задачи. input контролирует обращения к самому маршрутизатору, включая WinBox, SSH, DNS и VPN endpoint. forward обрабатывает трафик между WAN, LAN, VLAN и удаленными сетями. Аудит одной цепочки не заменяет проверку другой.

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

Готовый набор firewall rules из статьи или форума здесь опасен. Без знания интерфейсов, VLAN, VPN и опубликованных сервисов он может оставить нужное направление открытым либо отключить офис. В read-only отчете описывают проблему и требуемый результат, а точные изменения проектируют после подтверждения топологии.

DNS, VPN и сегментация

Если MikroTik отвечает на DNS-запросы клиентов, определите разрешенные сети и проверьте доступность TCP/UDP 53 со стороны WAN. Также нужны upstream DNS, статические записи и неожиданные перенаправления. DNS cache для локальной сети не должен случайно превратиться в сервис для всего интернета.

Для каждого VPN peer укажите владельца, назначение, разрешенные адреса, маршруты и доступные подсети. Проверьте firewall на VPN interface, выдаваемый DNS, работу через резервный канал и процедуру отзыва ключа. Наличие шифрованного туннеля не означает минимальные права: через него может быть доступна вся сеть вместо одного требуемого ресурса.

Сопоставьте VLAN и подсети с реальными группами устройств: сотрудники, серверы, телефония, принтеры, камеры, IoT, гости и управление. Затем зафиксируйте разрешенные потоки. VLAN разделяет широковещательные домены, но доступ между сегментами определяет политика firewall и маршрутизация.

Логи и история изменений

Логи должны помогать разбирать конкретные события: входы и ошибки аутентификации, изменение конфигурации, состояние VPN, переключение провайдера, ошибки интерфейсов, перезагрузки и обновления. Если записи остаются только в оперативной памяти, важная история может исчезнуть после сбоя. При этом запись каждого отклоненного пакета создает нагрузку и мешает увидеть полезные события.

Проверьте, используется ли удаленное журналирование, кто его читает и как долго доступны записи. Отсутствие ответственного превращает даже правильно настроенный syslog в архив без практической ценности.

Как расставить приоритеты

  1. Сначала ограничить прямую экспозицию. В эту группу входят управление из недоверенных сетей, доступный с WAN DNS, неизвестные привилегированные пользователи, старые VPN peers и проход из гостевого сегмента к служебным ресурсам.
  2. Затем обеспечить возврат. До сложных правок нужны внешние копии, понятный локальный доступ, параметры провайдеров и проверяемый сценарий отката.
  3. После этого убрать избыточные права. Пересматривают широкие VPN-маршруты, межсегментный доступ, временные исключения и общие учетные записи.
  4. Планово выполнить укрепление. Сюда относятся обновления RouterOS и firmware, отключение устаревших сервисов, ограничение L2 management, настройка логов и актуализация документации.

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

Чеклист перед изменениями

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

Когда нужен инженер по MikroTik

Привлекайте инженера, если MikroTik является единственной точкой доступа к рабочим системам, схема сети устарела, а управлять устройством можно только удаленно. Экспертная работа также нужна при сложной связке policy routing, NAT, VLAN и нескольких VPN, при переходе между существенно отличающимися версиями RouterOS, после подозрительной смены конфигурации и в ситуации, когда восстановление не проверялось.

При признаках более широкой проблемы проверку маршрутизатора стоит включить в аудит кибербезопасности. MikroTik контролирует часть сетевых потоков, но по его конфигурации нельзя оценить защиту серверов, рабочих мест, учетных записей, почты и резервных копий.

Что должно остаться после аудита

  • инвентаризация устройства, версий и способов управления;
  • список находок с привязкой к фактической конфигурации;
  • приоритеты по экспозиции, влиянию на бизнес и риску восстановления;
  • отдельный план изменений с зависимостями и откатом;
  • проверки доступности, VPN, публичных сервисов и сегментации после работ;
  • перечень вопросов, по которым не удалось подтвердить владельца или назначение.

Первичный аудит может полностью оставаться read-only. Действия, способные повлиять на связь, согласуют и выполняют отдельно.

Частые вопросы

Можно ли провести аудит 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