Средняя
В июне 2026 года исследователи сообщили о масштабной кампании FortiBleed, направленной против межсетевых экранов и SSL VPN-шлюзов Fortinet FortiGate. В обнаруженной базе содержались рабочие административные и VPN-учётные данные для десятков тысяч (упоминается около 74 тысяч) устройств в 194 странах.
Fortinet подчёркивает, что речь не идёт о новой уязвимости FortiOS. По предварительной оценке производителя, злоумышленники повторно использовали учётные данные из предыдущих инцидентов и применяли перебор паролей против устройств со слабой парольной политикой и без многофакторной аутентификации.
Таким образом, FortiBleed — не история об одной новой уязвимости, которую можно закрыть очередным обновлением. В основе кампании лежат скомпрометированные учётные данные, слабая аутентификация и доступные из интернета интерфейсы управления.
Содержание
Почему компрометация МЭ особенно опасна?
При компрометации обычного сервера злоумышленник получает контроль над одной системой и начинает искать доступные из неё ресурсы.
С межсетевым экраном ситуация сложнее. FortiGate содержит:
- правила доступа между сегментами;
- настройки NAT;
- маршруты;
- параметры VPN;
- локальные учётные записи;
- сведения о внутреннем адресном пространстве;
- настройки административного доступа.
Администратор устройства может не только изучить сеть, но и изменить саму логику её защиты: открыть новый доступ, создать VPN-пользователя, добавить маршрут или скорректировать правило.
Обычная модель выглядит так:
- Интернет
→ межсетевой экран
→ защищаемые системы
После компрометации административного контура она меняется:
- Интернет
→ интерфейс управления МЭ
→ контроль над конфигурацией
→ изменение сетевой политики
→ внутренние сегменты
→ критичные активы
Устройство, которое должно ограничивать атаку, само становится точкой её развития.
Межсетевой экран тоже нуждается в сетевой защите
устройствами. Производитель предлагает использовать доверенные адреса, local-in policy или полностью отказаться от администрирования FortiGate непосредственно из интернета. Также необходимо включить MFA для административных и VPN-учётных записей.
Пароль не должен быть единственной границей защиты административного интерфейса. Он может быть украден, повторно использован или подобран. Поэтому управляющий контур МЭ должен быть доступен только из выделенного административного сегмента или через контролируемую точку входа.
Но даже после смены паролей остаётся более сложный вопрос: что злоумышленник успел сделать до того, как доступ был заблокирован?
После компрометации конфигурации нельзя доверять по умолчанию
Получив административный доступ, злоумышленник мог:
- создать нового администратора;
- добавить VPN-пользователя;
- открыть доступ из VPN во внутреннюю сеть;
- изменить правило МЭ;
- добавить маршрут;
- скорректировать NAT;
- ослабить ограничения на управление.
Поэтому Fortinet рекомендует проверить пользователей, VPN и остальные элементы конфигурации на наличие несанкционированных изменений, желательно сравнив текущее состояние с заведомо корректной версией. Следует также искать неизвестные учётные записи, неожиданные административные подключения и признаки бокового перемещения.
В этом сценарии важен не только итоговый конфигурационный файл, но и история изменений:
- что было изменено;
- когда это произошло;
- какой учётной записью;
- было ли изменение согласовано;
- какой новый сетевой доступ оно создало.
Подозрительная активность может состоять не из одного явно вредоносного действия. Иногда это серия небольших изменений: добавление объекта, корректировка группы, расширение сервиса и создание правила. По отдельности они могут выглядеть нормально, но вместе формируют новый путь во внутреннюю сеть.
Что можно проверить с помощью Netopia?
Netopia не определяет факт утечки учётных данных и не заменяет SIEM, EDR или расследование инцидента. Но система позволяет проверить защищённость административного контура, выявить подозрительные изменения конфигурации и оценить их возможные последствия.
1. Проверить защиту административного доступа
В первую очередь можно проверить, соблюдаются ли базовые требования к управлению FortiGate:
- включена ли многофакторная аутентификация для административных учётных записей;
- доступен ли интерфейс управления из интернета;
- ограничен ли административный доступ внутренними или выделенными управляющими сетями;
- настроены ли разрешённые адреса администраторов;
- не появились ли новые способы удалённого управления устройством.
Такие проверки позволяют выявить условия, которые делают применение украденных учётных данных значительно проще.
Даже корректный пароль не должен быть единственной границей защиты. Административный интерфейс МЭ должен быть доступен только из доверенного сегмента или через контролируемую точку входа, а вход администратора должен требовать второго фактора.
2. Проверить историю изменений
Если злоумышленник получил административный доступ к FortiGate, он мог изменить конфигурацию устройства до смены паролей и блокировки учётной записи.
Netopia позволяет определить:
- какие правила, объекты и группы были изменены;
- создавались ли новые маршруты, VPN-подключения или правила NAT;
- когда произошло изменение;
- какая учётная запись его выполнила;
- изменились ли настройки административного доступа;
- были ли отключены отдельные защитные механизмы.
Особого внимания требуют действия от нехарактерной или ранее неактивной учётной записи, изменения в необычное время и серии связанных изменений на нескольких устройствах.
3. Сопоставить изменения с заявками
Изменения сетевой политики можно сопоставить с заявками в Service Desk и выделить действия, для которых не найдено согласованного основания.
Отсутствие заявки само по себе не доказывает атаку. Но в условиях возможной компрометации необходимо проверить, кто изменил конфигурацию, зачем это было сделано и какой новый доступ появился в результате.
4. Проверить достижимость критичных активов
В качестве исходных точек анализа можно использовать SSL VPN-пулы, административные подсети, адреса FortiGate и другие сети, доступ к которым мог получить злоумышленник.
Netopia анализирует топологию, маршрутизацию, NAT и политики МЭ и показывает, существует ли разрешённый путь до контроллеров домена, серверов виртуализации, систем резервного копирования, средств защиты, критичных бизнес-систем и сегментов АСУ ТП.
5. Построить векторы атак
Если прямого доступа к критичной системе нет, атакующий может двигаться через доступные узлы с известными уязвимостями:
- SSL VPN
→ доступный сервер
→ известная уязвимость
→ административный сегмент
→ критичный актив
Построение векторов атак позволяет увидеть такие многошаговые сценарии. Расчёт показывает техническую возможность, но не подтверждает факт реализации атаки.
6. Определить разрешающие правила
Для каждого найденного пути Netopia может показать:
- через какие устройства проходит трафик;
- какие правила его разрешают;
- какие объекты и сервисы используются;
- когда правила изменялись;
- какой учётной записью выполнено изменение;
- было ли оно связано с заявкой;
- существуют ли альтернативные маршруты.
В результате выстраивается полная цепочка:
- Недостаточно защищённый административный доступ
→ вход под скомпрометированной учётной записью
→ изменение без согласованной заявки
→ новый доступ из VPN
→ достижимость внутреннего сервера
→ возможный путь к критичному активу
Таким образом, Netopia помогает ответить на шесть практических вопросов:
Включена ли MFA и ограничен ли административный доступ?
Что изменилось в конфигурации?
Какая учётная запись выполнила изменение?
Было ли оно связано с заявкой?
До каких критичных активов существует доступ?
Какие правила и уязвимые узлы формируют возможный путь атаки?
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
