Средняя
В новостях о кибератаках чаще всего обсуждают уязвимости, вредоносное ПО и фишинг. Но иногда атака строится не вокруг сложного эксплойта, а вокруг плохо защищённой конфигурации сетевого устройства.
Хороший пример — недавняя история с кампанией APT28 против роутеров TP-Link и MikroTik. По данным Минюста США, злоумышленники с 2024 года использовали известные уязвимости, получали доступ к тысячам роутеров TP-Link и меняли их DNS-настройки так, чтобы DNS-запросы уходили на серверы под контролем атакующих. Это позволяло проводить атаки типа adversary-in-the-middle и перехватывать пароли, токены, письма и другие чувствительные данные.
Британский NCSC описывает похожую механику: APT28 перезаписывали DHCP/DNS-настройки на роутерах, чтобы перенаправлять трафик через контролируемые DNS-серверы и красть пароли, OAuth-токены и другие учётные данные.
На первый взгляд это история про домашние и малые офисные роутеры. Но вывод из неё шире: конфигурация сетевого устройства сама по себе является рубежом защиты. Если она настроена слабо, даже обычный роутер может стать точкой перехвата трафика и дальнейшей компрометации.
Содержание
Что в этом кейсе было критично?
В атаке не требовалось обязательно устанавливать сложный агент на рабочие станции пользователей. Достаточно было получить контроль над сетевым устройством и изменить его параметры.
Ключевые проблемы выглядели достаточно приземлённо:
- устаревшие или уязвимые версии прошивок;
- слабые или скомпрометированные учётные данные;
- доступность административных интерфейсов;
- возможность изменить DNS/DHCP-настройки;
- отсутствие контроля целостности конфигурации;
- использование устройств,
- оторые уже не поддерживаются производителем.
В результате атакующий мог изменить DNS-resolver’ы и направить пользователей через свою инфраструктуру. Для пользователя всё могло выглядеть почти нормально: сайты открываются, почта работает, сервисы доступны. Но часть запросов и аутентификационных потоков уже проходит через чужую точку контроля.
Это важный урок для корпоративной инфраструктуры: не все риски видны на уровне endpoint или SIEM. Иногда проблема начинается ниже — на уровне сетевого оборудования и его базовых настроек.
Харденинг — это не разовая настройка
Харденинг часто воспринимают как чек-лист при вводе устройства в эксплуатацию: поменять пароль, выключить Telnet, включить SSH, настроить NTP, прописать syslog, ограничить доступ к админке.
Это правильно, но недостаточно.
Конфигурация живёт и меняется. Появляются новые администраторы, временные доступы, миграции, аварийные изменения, новые интеграции и исключения. То, что было безопасно настроено на старте, через год может оказаться набором компромиссов и забытых временных решений.
Поэтому харденинг должен быть не разовым действием, а регулярной проверкой фактической конфигурации. Вопрос должен звучать так:
Соответствует ли текущее состояние устройства утверждённому профилю безопасности?
И проверять нужно не только межсетевые правила, но и системные настройки устройства.
Что нужно контролировать в конфигурациях?
Для маршрутизаторов, межсетевых экранов и других сетевых устройств важны базовые классы проверок.
Доступ к управлению
Административные интерфейсы не должны быть доступны из недоверенных сегментов или из интернета. Управление должно идти только из выделенного административного сегмента или через защищённые каналы.
Проверять стоит:
- SSH, HTTPS, API-доступ;
- отключение Telnet и небезопасных протоколов;
- ограничения по source-адресам;
- доступность management-интерфейсов снаружи;
- использование MFA или централизованной аутентификации, если поддерживается.
Учётные записи и аутентификация
Заводские логины, общие локальные учётки и слабые пароли остаются одной из самых частых проблем.
Контролировать нужно:
- отсутствие default credentials;
- минимальный набор локальных пользователей;
- интеграцию с AAA/LDAP/RADIUS/TACACS+;
- права администраторов;
- политику паролей;
- отключение неиспользуемых учётных записей.
DNS, DHCP и маршрутизация
Кейс с TP-Link хорошо показывает, что DNS-настройки — это не второстепенный параметр. Подмена DNS может стать основой для перехвата учётных данных и перенаправления пользователей.
Проверять нужно:
- какие DNS-серверы заданы на устройстве;
- кто может менять DHCP/DNS-настройки;
- нет ли неизвестных forwarder’ов;
- не появились ли подозрительные статические маршруты;
- не изменились ли маршруты по умолчанию;
- нет ли несанкционированного policy-based routing.
Логирование и мониторинг
Если устройство изменили, организация должна это увидеть.
Важны проверки:
- включён ли syslog;
- куда отправляются события;
- логируются ли административные действия;
- фиксируются ли изменения конфигурации;
- синхронизировано ли время через NTP;
- включено ли логирование критичных событий безопасности.
Версии ПО и поддержка
Устройство без актуальных обновлений постепенно превращается в постоянный риск. Минюст США в рекомендациях по кампании APT28 отдельно указывает на необходимость обновлять прошивку и заменять устройства, находящиеся в статусе End-of-Life или End-of-Support.
Проверять нужно:
- версию прошивки;
- наличие известных уязвимостей;
- статус поддержки устройства;
- соответствие версии внутреннему baseline;
- необходимость замены устаревшего оборудования.
Где здесь место NSPM?
NSPM обычно ассоциируют с анализом правил межсетевых экранов: какие доступы разрешены, какие правила избыточны, где нарушена сегментация, какие изменения были внесены.
Но зрелая NSPM-система должна смотреть шире. Политика сетевой безопасности — это не только ACL и firewall rules. Это ещё и конфигурация устройств, через которые проходит трафик.
NSPM может использовать профили харденинга: набор проверок, которым должны соответствовать маршрутизаторы, МЭ и другие сетевые устройства. Например:
- административный доступ разрешён только из management-сегмента;
- Telnet отключён;
- используются только доверенные DNS-серверы;
- syslog настроен и отправляет события в SIEM;
- NTP настроен на корпоративные источники времени;
- локальные пользователи ограничены;
- правила без логирования запрещены;
- удалённое управление с внешнего интерфейса запрещено;
- версия ПО не ниже утверждённой;
- устройство не находится в статусе EOL/EOS.
Такие проверки можно применять регулярно: после загрузки новой конфигурации, после изменения, по расписанию или перед аудитом.
Харденинг как часть общей модели защиты
Важно не противопоставлять харденинг другим мерам безопасности. Он не заменяет патч-менеджмент, мониторинг, EDR, SIEM или контроль доступа. Но он закрывает свой уровень.
Если устройство настроено небезопасно, остальные средства защиты могут увидеть последствия слишком поздно. Например, SIEM получит события уже после того, как DNS был подменён, а учётные данные начали уходить через чужую инфраструктуру.
Хороший профиль харденинга снижает вероятность самого сценария:
- административный интерфейс не доступен атакующему;
- слабые протоколы отключены;
- неизвестные DNS-серверы запрещены;
- изменение конфигурации фиксируется;
- устройство обновлено;
- отклонение от baseline быстро обнаруживается.
Это и есть один из рубежей защиты: не дать сетевому устройству стать удобной точкой управления для атакующего.
Что получает организация?
Регулярный контроль харденинга даёт несколько практических эффектов.
Во‑первых, снижается поверхность атаки. Чем меньше лишних сервисов, открытых интерфейсов и слабых настроек, тем меньше возможностей для первичного доступа.
Во‑вторых, быстрее обнаруживаются нежелательные изменения. Если кто‑то изменил DNS, включил удалённое управление или добавил локальную учётку, это должно быть видно не через месяцы, а при ближайшей проверке.
В‑третьих, появляется доказательная база для аудита. Можно показать не только документы и регламенты, но и фактическое соответствие устройств профилям безопасности.
В‑четвёртых, снижается зависимость от ручных проверок. Инженеру не нужно каждый раз заходить на устройство и глазами искать отклонения. Система сама показывает, какие устройства не соответствуют baseline и почему.
Вывод
История с DNS-hijacking через роутеры показывает, что сетевое устройство может стать точкой атаки даже без сложного вредоносного ПО на рабочих станциях. Иногда достаточно изменить несколько параметров конфигурации — и трафик пользователей уже проходит через инфраструктуру атакующего.
Поэтому харденинг конфигураций должен быть частью постоянного процесса сетевой безопасности. Нужно контролировать не только правила доступа, но и системные настройки: управление, учётные записи, DNS, DHCP, маршрутизацию, логирование, версии ПО и статус поддержки.
NSPM в этой модели выступает не только инструментом анализа firewall rules, но и системой контроля состояния сетевой инфраструктуры. Он помогает сравнивать реальные конфигурации с утверждёнными профилями безопасности, находить отклонения и подтверждать, что сетевые устройства остаются надёжным рубежом защиты, а не слабым звеном.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
