FortiCloud SSO выключили, FortiOS обновили. Кто остался внутри?

Чужой администратор переживает обновление FortiOS, а скачанная конфигурация остаётся у атакующего после перезагрузки. Поэтому сисадмину рано закрывать инцидент сразу после установки патча. Я — Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш». Покажу, как проверить оставленные доступы, определить очередь ротации секретов и вернуть шлюз в работу, не потеряв управление и VPN.

1. Что закрыл патч и почему этого недостаточно

У этой истории две волны. Декабрьский бюллетень FG-IR-25-647 описывал CVE-2025-59718 и CVE-2025-59719; январская проблема получила отдельный номер CVE-2026-24858. Поэтому фраза «мы уже обновлялись после новости про SSO» ничего не доказывает. Например, FortiOS 7.4.9 исправляла декабрьскую CVE-2025-59718, но оставалась уязвима к январской атаке. Версию нужно сопоставлять с конкретным бюллетенем. Исправления FortiOS 7.4.9.

На 5 сентября 2026 года важно правильно читать заголовок: Fortinet отключила FortiCloud SSO 26 января, а 27 января восстановила сервис, запретив вход с уязвимых устройств. Январская уязвимость затрагивала административный FortiCloud SSO; сторонние SAML IdP и FortiAuthenticator в этой роли не затронуты. Функция выключена в заводской конфигурации, но могла включиться при регистрации устройства через GUI в FortiCare. Проверяйте фактическое состояние, а не воспоминания о первоначальной настройке. Бюллетень FG-IR-26-060.

Ниже — минимальные исправленные версии FortiOS для CVE-2026-24858 из этого бюллетеня. Это исторический порог исправления одной уязвимости. Для рабочего шлюза я выбираю актуальный поддерживаемый релиз под конкретную модель, проверяю остальные PSIRT, release notes и маршрут обновления. Но даже подходящая прошивка решает только задачу закрытия уязвимости: созданная ранее учётка и чужая копия конфигурации требуют отдельных действий.

• Ветка 7.6 — начиная с 7.6.6.
• Ветка 7.4 — начиная с 7.4.11.
• Ветка 7.2 — начиная с 7.2.13.
• Ветка 7.0 — начиная с 7.0.19.

2. Сначала ограничиваю доступ и сохраняю следы

Я начинаю с доверенного рабочего места и проверенного локального администратора. Держу консольный или независимый аварийный доступ: закрывать единственный канал управления удалённому шлюзу — плохая идея. Затем ограничиваю административные HTTPS и SSH выделенной сетью управления. Если устройство прямо сейчас меняют посторонние, изоляция важнее красивого комплекта доказательств; в остальных случаях сбор состояния и ограничение доступа идут рядом.

Отключение FortiCloud SSO выполняется так. При включённых VDOM сначала войдите в глобальный контекст командой config global; после работы выйдите из него через end. Без VDOM дополнительный переход не нужен: config system global set admin-forticloud-sso-login disable end Проверка: show full-configuration system global — найдите значение admin-forticloud-sso-login. Я оставляю функцию выключенной, если она не нужна по утверждённой схеме администрирования. Это мой выбор сокращения доступных способов входа; после серверной блокировки уязвимых версий Fortinet уже не требует локального отключения как обязательного обходного решения. CLI FortiOS 7.4.11.

Не путайте правила транзитного трафика с доступом к самому FortiGate. Для последнего применяют local-in policy. Одна разрешающая запись для вашего адреса ещё не означает запрета всем остальным: нужный явный запрет и порядок правил проверяются отдельно. Учитывайте изменённые административные порты, IPv6 и остальные сервисы шлюза. Именно поэтому я не предлагаю вставить универсальное правило deny all в аварийную консоль. Пояснение Fortinet о local-in.

До перезагрузки сохраняю доступные события, список активных сессий, конфигурацию, версию и время устройства. Для файлов фиксирую контрольные суммы и время получения, оригиналы оставляю неизменными. Выгрузка из подозрительного устройства — доказательство, а не автоматически пригодный бэкап для восстановления. Хранить её нужно с ограниченным доступом: отправка полного конфига в общий чат создаёт ещё одну утечку.

3. Где искать «скрытого» администратора

В подтверждённой январской кампании «скрытый» обычно означает незамеченный. Fortinet описывает локальные учётки audit, backup, itadmin, secadmin, support; специальная невидимость в GUI для них не установлена. Проверять только эти имена нельзя. Я сверяю каждого администратора с владельцем, назначением и согласованными правами. Знакомое имя тоже не оправдание: у штатного сотрудника могли изменить профиль или добавить способ входа. Индикаторы и наблюдения Fortinet.

Проверку выполняйте под доверенным глобальным super_admin. При VDOM сначала используйте config global, после команд вернитесь через end. Отсутствие раздела у ограниченного администратора не доказывает отсутствие объектов. Для исходного снимка использую: get system status show full-configuration system admin show full-configuration system api-user show full-configuration system accprofile show system sso-forticloud-admin Это чтение конфигурации, включая чувствительные значения. Деревья администраторов и SSO сопоставляйте со своей версией по CLI Reference FortiOS 7.4.11.

В system admin смотрю accprofile, доступные VDOM, trusthost, remote-auth, wildcard и ssh-public-key1/2/3. Профили из system accprofile раскрываю целиком: название readonly само по себе ничего не гарантирует. Отдельно проверяю API-администраторов, разрешения SSO и соответствующие таблицы сопоставлений. Затем расширяю сравнение с чистой копией на VPN-пользователей, группы, маршруты, политики, DNS, central-management и автоматизацию. Удаление одной подозрительной записи не должно заслонить остальные изменения. Поля system admin.

Активные административные подключения показывает get system info admin status. Команда execute disconnect-admin-session ? помогает получить актуальные индексы, после чего execute disconnect-admin-session <index> завершает выбранную сессию. Перепроверяйте индекс перед каждым отключением. Сначала сохраняю сведения и исключаю повторный вход, затем завершаю все сессии подтверждённо чужой учётки. Управление сессиями. Удаляю запись из другой доверенной учётки: config system admin delete «<проверенное_имя>» end Имя в угловых скобках замените на проверенное. Пока администратор подключён, удалить его нельзя. Инструкция удаления Fortinet.

4. Как установить, что происходило до обновления

Мне нужна цепочка событий: вход, изменения, экспорт, последующая активность. В опубликованном Fortinet примере успешный SSO-вход имеет logid="0100032001« и method=»sso«; создание администратора — logid=»0100044547", action="Add", cfgpath="system.admin". Это полезные отправные точки, но поиск должен охватывать и другие методы входа, изменения существующих объектов, операции с конфигурацией. Сопоставляйте пользователя, источник, время и объект, а не один IP из списка индикаторов. Примеры событий Fortinet.

Проверяю локальные события вместе с FortiAnalyzer или внешним syslog. Временную шкалу привожу к одному часовому поясу, учитываю перезагрузки, сроки хранения и провалы доставки. Если перед инцидентом журналы начали храниться иначе, это отдельный объект проверки. Тишина после обновления может означать отсутствие новых действий, потерю старых записей или отключённую отправку. В отчёте эти ситуации должны различаться, иначе читатель получит ложную уверенность.

Подтверждённый посторонний super_admin для меня достаточен, чтобы начать ротацию потенциально доступных секретов, даже если отдельного события скачивания нет. Одновременно проверяю контроллеры домена: где использовалась LDAP-учётка шлюза, какие входы, изменения групп и новые пользователи появились. В июне 2026 года Fortinet отдельно сообщала о предполагаемом повторном использовании учётных данных из прежних инцидентов. Это оценка производителя, а не доказательство новой уязвимости. Разбор повторной компрометации учётных данных.

5. Какие секреты ротировать и в какой очереди

Надпись ENC не означает, что все значения одинаково защищены. FortiGate должен уметь восстановить некоторые секреты, чтобы подключаться к внешним сервисам; административные пароли хранятся как хеши. CERT.at проверила инструментарий атакующего и подтвердила восстановление LDAP bind-пароля со стандартным ключом на свежей VM FortiGate 7.6.5. Обычные локальные пароли в этом тесте обратно не восстанавливались. Обещать «из конфига расшифруют вообще всё» неправильно. Считать обратимо зашифрованные секреты безопасными тоже нельзя. Исследование CERT.at.

Очередь я строю по возможностям доступа и месту использования. Сначала прекращаю чужое управление и меняю секреты, позволяющие войти в инфраструктуру; оставшиеся подключения перевожу на новые значения по согласованным окнам. В реестре нужны объект, владелец, потребители секрета, срок смены и проверка отказа старого значения. Если LDAP bind выполнялся привилегированной доменной учёткой, её расследование идёт параллельно восстановлению шлюза, а не после него.

Моя рабочая очередь приведена ниже. Она шире простого сброса admin: включает зависимости, которые легко забыть. Базовый набор — локальные и VPN-пароли, RADIUS, IPsec, LDAP и сертификаты — прямо указан в рекомендациях Fortinet после компрометации. Пароли администраторов меняю и при хранении в виде хешей: остаются подбор, повторное использование и возможность предшествующей подмены. Но из утечки одного bind-пароля не следует автоматическая компрометация паролей всех сотрудников.

Отдельно проверяю переход на PBKDF2: в ветке 7.4 он введён с 7.4.8, но для совместимости в конфигурации может сохраняться прежний SHA256-хеш в поле old-password. Установка новой прошивки сама по себе не означает удаления всех старых хешей. Их устранение планирую по инструкции производителя с проверкой работоспособности административных учёток. Fortinet о PBKDF2 и legacy-хешах.

• Управление: локальные администраторы, аварийные доступы и API-токены. Незнакомые SSH public keys удаляю; сами публичные ключи не являются секретами. API-токены отзываю и выпускаю заново, затем обновляю автоматизацию. Проверяю права и источники запросов. [REST API administrator](https://docs.fortinet.com/document/fortigate/7.4.10/administration-guide/399023/rest-api-administrator).
• Каталог и AAA: LDAP bind-пароль, RADIUS shared secret, TACACS+ secret, если используется. Меняю значения на обоих концах и во всех потребителях; сервисной учётке оставляю минимальные необходимые права.
• VPN: IPsec PSK на обоих пирах, затронутые локальные VPN-пароли и доступы удалённых пользователей. Завершаю соответствующие сессии; проверяю повторное установление туннелей, чтобы старые SA не маскировали ошибку смены ключа.
• PKI: для потенциально утёкших закрытых ключей генерирую новые пары, перевыпускаю сертификаты и отзываю старые. Если ушёл ключ CA для TLS-инспекции, отдельно планирую замену доверия на клиентах. Публичные сертификаты без закрытого ключа сами по себе секретом не являются.
• Интеграции: SNMP community, SNMPv3 auth/priv-пароли, SMTP, внешние коннекторы, Wi-Fi PSK и другие секреты, действительно присутствовавшие в доступном конфиге. Для SNMPv3 проверяю оба поля, auth-pwd и priv-pwd. [Параметры SNMP](https://docs.fortinet.com/document/fortigate/7.4.10/cli-reference/292257317/config-system-snmp-user).
• Повторное использование: если тот же пароль или ключ работал на соседних шлюзах, серверах либо у подрядчика, расширяю ротацию туда. Замена значения только на атакованном FortiGate оставляет остальные доступы действующими.

6. Учебный разбор: «Вектор», два шлюза и забытый LDAP

Для конкретики возьму учебную реконструкцию «ООО Вектор», производственной компании на 120 рабочих мест. Название, числа и ход событий заданы для сценария; это не отчёт о реальном клиенте или проведённом испытании. Стендовая схема: два FortiGate 100F в HA active-passive, FortiOS 7.4.10, два IPsec-туннеля, 18 локальных VPN-пользователей, LDAP regular bind через svc_fgt_ldap, резервное копирование через API. События уходят на внешний syslog с хранением 90 дней.

По сценарию дежурный выключает SSO и обновляет кластер до 7.4.11 — исторического исправления январской CVE. Контрольный дефект остаётся: в system admin есть secadmin с super_admin, созданный до обновления. В снимке конфигурации обнаруживается фрагмент: config system admin edit "secadmin" set accprofile "super_admin" set vdom "root" next end Это сокращённый фрагмент для распознавания, пароль намеренно исключён; применять его нельзя. Две штатные именные учётки подтверждены владельцами, третья — нет. Во внешнем журнале ей предшествует несогласованный SSO-вход, затем следует изменение system.admin. Так подозрительное имя получает доказательную привязку.

После сохранения следов прекращается посторонний доступ, завершаются сессии и удаляется чужая учётка; проверяются оба узла HA и конфигурация. Затем я закладываю в упражнение вторую ошибку: svc_fgt_ldap используется ещё и внутренним порталом. Если просто сменить её пароль в AD и на FortiGate, портал потеряет авторизацию. Поэтому сначала составляется список потребителей, затем сервисы переводятся на отдельные учётки с минимальными правами, старая отключается. Два PSK меняются по одному туннелю с проверкой нового соединения, API-токен обновляется в задании резервного копирования. В рабочей сети обнаруженный привилегированный доступ в AD потребовал бы отдельного расследования, а не только смены bind-пароля.

Учебный итог задаю проверяемыми результатами: посторонних администраторов — ноль; оба туннеля заново устанавливаются; 18 пользователей проходят повторную авторизацию; портал работает со своей учёткой; старые LDAP-доступ и API-токен отвергаются; новая резервная копия создаётся. Для упражнения резервирую окно 90 минут, но не выдаю его за измеренный простой или обещание заказчику. Главный результат сценария — обновлённая прошивка, очищенный конфиг и погашенные старые доступы. Одна зелёная строка версии дала бы только первый пункт.

7. Когда я считаю восстановление завершённым

При подтверждённых изменениях я предпочитаю проверенную конфигурацию, история которой понятна. «Вчерашний бэкап» не обязательно чистый: атакующий мог войти раньше. Сопоставляю копию с установленным периодом компрометации и утверждёнными изменениями. Если достоверного исходного состояния нет, собираю настройки заново или провожу полный предметный аудит с владельцами сервисов. Перед подключением исправляю утёкшие секреты и проверяю централизованные шаблоны, чтобы очередная установка из FortiManager не вернула старые значения.

Переустанавливать FortiOS с форматированием при любой утечке конфига я автоматически не требую. Утечка и нарушение целостности устройства — разные обстоятельства; при признаках второго привлекаю TAC и выполняю рекомендованную процедуру восстановления. Доступные доказательства сохраняются заранее. После восстановления проверяю версии и состояние обоих узлов HA, административные доступы, VPN, отправку событий и работу зависимых приложений. Процедура Fortinet для скомпрометированного устройства.

Для будущих утечек рассматриваю private-data-encryption с собственным ключом, отдельно проверяя особенности версии, TPM, HA и восстановления на заменённом устройстве. Это требует аккуратного хранения ключевого материала и проверяемой процедуры восстановления. Включение функции после кражи не меняет старый файл у атакующего. Шифрование резервного файла паролем и маскирование при передаче третьим лицам также полезны, но решают отдельные задачи. Хранение секретов, защита резервных копий.

Я закрываю работы, когда у каждого оставленного доступа есть владелец, изменения объяснены, старые секреты перестали действовать, а восстановленные сервисы проверены. Ограничения расследования записываю прямо: какие журналы отсутствуют и что доказать нельзя. Красивый дашборд, переименование штатного admin и коллекцию заблокированных IP можно отложить. Ограничение управления, MFA, исправления, внешний журнал и ротацию затронутых секретов — нельзя. Проверку того, что старый доступ больше не работает, я ценю выше скриншота успешного обновления.

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