7 сентября 2026, 15:30

Я хотел посмотреть на собственную сеть не из панели управления роутером, а так, как её видит отдельная машина внутри инфраструктуры. Для этого в Proxmox уже была подготовлена Kali Linux: свежая система, стандартный набор диагностических инструментов и отдельный доступ по SSH-ключу.

Первый запуск быстро показал простую вещь, о которой легко забыть. Виртуальная машина видела только обычный виртуальный Ethernet. Сканировать радиоэфир через него невозможно: для iw и nmcli нужен настоящий Wi-Fi-адаптер.

На этом эксперимент мог закончиться, но в сервере оказался встроенный беспроводной модуль. Его и передали напрямую в Kali через PCI passthrough.

Как Kali получила доступ к радиоэфиру через Proxmox

сервер Proxmox
      |
      +-- виртуальный Ethernet --> Kali --> локальная сеть
      |
      +-- Wi-Fi PCI passthrough --> wlan0 --> радиоэфир

После перезапуска внутри VM появился wlan0, загрузился штатный драйвер, а адаптер подтвердил поддержку managed, AP и monitor mode. Kali наконец получила доступ не только к IP-сети, но и к самому беспроводному эфиру.

Границы проверки

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

Я намеренно не проводил:

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

Задача была не в том, чтобы устроить показательный «взлом». Мне нужен был воспроизводимый снимок: что сеть раскрывает сама, какие службы доступны из LAN и какие настройки пора исправить.

Безопасный путь аудита: от наблюдения к плану исправления

Что видно в радиоэфире

Первый снимок сделали штатными средствами Linux:

iw dev
nmcli device
nmcli device wifi list ifname wlan0 --rescan yes

В публичной версии статьи я не показываю реальные SSID, BSSID, MAC-адреса и уровни сигнала соседних сетей. Для вывода важны не названия, а параметры двух моих точек доступа.

Обе сети использовали AES-шифрование, и это хороший результат. Но рядом с WPA2 они всё ещё объявляли совместимость с WPA1. Такой переходный режим обычно оставляют ради старых клиентов и потом забывают убрать.

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

Третья находка — точки доступа не объявляли стандартную защиту управляющих кадров PMF/802.11w. Атаку с отключением клиентов я не проверял: для аудита было достаточно зафиксировать отсутствие признака и добавить его в план настройки.

радиосканирование
      |
      +-- WPA2 + AES --------> оставить
      |
      +-- совместимость WPA1 -> убрать
      |
      +-- WPS ----------------> отключить, если не нужен
      |
      +-- PMF не объявлена ----> проверить поддержку и включить

От Wi-Fi к шлюзу

Радиосканирование не показывает версию RouterOS, правила firewall и доступность административных служб. Поэтому второй этап шёл уже по проводному интерфейсу Kali.

Сначала определили локальный шлюз обычной таблицей маршрутизации, затем провели ограниченный TCP/UDP-аудит с Nmap. Полный TCP-скан выполнялся с лимитом скорости и одним повтором. Он занял около восьми минут и не создал заметной нагрузки на маршрутизатор.

ip -4 route
nmap -sS -sV --version-light -Pn <gateway-ip>

Команда здесь приведена как схема метода, а не готовая цель: реальный адрес и набор административных портов из публикации удалены.

Из текущей LAN оказались доступны WinBox, RouterOS API, API поверх TLS, SMB, bandwidth-test и SSH на нестандартном порту. Сам по себе открытый порт ещё не уязвимость. Вопрос в том, нужен ли сервис и кто имеет к нему сетевой доступ.

Неаутентифицированный запрос к RouterOS API был отклонён, а SMB не позволил получить список ресурсов с пустыми учётными данными. Это полезные отрицательные результаты. Они не доказывают идеальную защиту, но не дают приписать устройству то, чего проверка не показала.

Самая неприятная часть оказалась в управлении

Обычный RouterOS API был доступен без TLS. Современная версия протокола не отдаёт пароль по простому запросу, однако рабочая авторизация по незашифрованному каналу всё равно может быть прочитана тем, кто уже находится на сетевом пути. Если интеграции используют API, их нужно переводить на проверяемый TLS, а обычный endpoint отключать.

Проверка API-SSL обнаружила старые TLS 1.0/1.1 и анонимные наборы обмена ключами. Nmap оценил конфигурацию шифров как слабую. Дополнительный тест OpenSSL не завершил полноценную прикладную сессию, поэтому я не стал выдавать его за доказательство перехвата. Подтверждённый факт уже достаточен: TLS-настройка требует пересмотра и ограничения источников.

SMB поддерживал подпись, но не требовал её. Здесь вывод тоже условный: если SMB на роутере вообще не используется, правильнее отключить сервис. Если используется — ограничить сегментом и проверить обязательную подпись с обеих сторон.

Версию удалось определить без входа

Штатный NSE-скрипт для WinBox получил версию RouterOS из сетевого ответа. Она оказалась заметно старше текущей исправленной ветки.

Это позволило перейти от предположений к проверке бюллетеней производителя. Обнаруженная версия входит в диапазон CVE-2024-54772: в старых выпусках WinBox различается размер ответа для существующего и несуществующего пользователя. Уязвимость помогает определить имя учётной записи, но не обходит пароль. Исправление вышло в RouterOS 7.18 и 6.49.18.

Эксплуатацию я не запускал. Для практического решения уже хватало трёх фактов:

  • WinBox доступен из проверяемого сегмента;
  • версия попадает в затронутый диапазон;
  • производитель рекомендует обновление и ограничение управления доверенными адресами.

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

Проверялась и применимость уязвимости REST JSON CVE-2025-10948. Версия формально старше исправления, но REST endpoint на стандартных веб-портах не обнаружен. Поэтому записывать эту CVE как подтверждённую уязвимость конкретной конфигурации было бы неправильно.

Что аудит действительно доказал

Получился не отчёт о компрометации, а список проверенных настроек.

Проверка Результат
Радиоинтерфейс Kali Работает через PCI passthrough
Шифрование Wi-Fi AES используется, но разрешён WPA1
WPS Объявляется точками доступа
PMF/802.11w В радиоснимке не объявлена
Анонимный RouterOS API Доступ отклонён
API без TLS Доступен из текущей LAN
API-SSL Обнаружены устаревшие TLS-настройки
Анонимный SMB Список ресурсов не получен
Версия RouterOS Определена удалённо и требует обновления
Успешный взлом Не проводился и не подтверждён

Есть и ограничение, которое нельзя прятать в сноске. IP-проверки выполнялись из текущей локальной сети. Их результаты ничего не доказывают про доступность тех же служб из интернета, гостевого Wi-Fi или другого VLAN. Для каждого сегмента нужен отдельный повторный тест.

План исправления

Следующий этап начнётся не с кнопки Update, а с возможности вернуться назад.

  1. Сохранить текстовый export и бинарную резервную копию RouterOS.
  2. Проверить резервный административный доступ и питание устройства.
  3. Обновить RouterOS до актуального совместимого stable-релиза.
  4. После перезагрузки проверить статус Flagged, неизвестных пользователей, скрипты и задания.
  5. Ограничить WinBox, SSH и API отдельным доверенным административным сегментом.
  6. Перевести нужные интеграции на API-SSL с проверяемым сертификатом, затем отключить API без TLS.
  7. Отключить неиспользуемые SMB и bandwidth-test.
  8. Убрать WPA1 и WPS, оставить WPA2-AES либо перейти на WPA3 после проверки клиентов.
  9. Проверить поддержку PMF и включить её без потери совместимости.
  10. Повторить тот же аудит из Kali и сравнить результаты до и после.
backup -> обновление -> hardening -> проверка связности
   ^                                      |
   |                                      v
откат <----------- проблема? <------ повторный аудит

Мой главный вывод довольно приземлённый: Kali полезна не потому, что в ней есть кнопка «взломать». Она заставляет проверять сеть снаружи от конфигурации и отделять реальный сетевой ответ от того, что, как мне казалось, настроено на роутере.

В этот раз расхождение нашлось. Завтра будем его исправлять.