FortiVoice обновили: как проверить стёртый crashlog, fcgi debug и чужой PAM-модуль

FortiVoice обновлён, телефоны зарегистрировались, сканер больше не показывает критическую уязвимость. Закрывать заявку рано: прежний доступ мог оставить после себя перехват паролей и механизмы закрепления. Я, Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш», в такой ситуации разделяю обновление и расследование. Ниже покажу порядок проверки, объясню ограничения восстановления crashlog и разберу модельный проект с конкретной адресацией, версиями и критериями возвращения телефонии в работу.

1. Исправленная версия закрывает вход, но не завершает инцидент

Речь о CVE-2025-32756: выполнении кода без предварительной аутентификации через HTTP-запросы к административному интерфейсу и пользовательскому порталу. Fortinet сообщил об эксплуатации FortiVoice 13 мая 2025 года. Минимальные исправленные версии перечислены ниже. Это границы исправления конкретной ошибки, а не перечень прошивок, которые можно считать безопасными при любых обстоятельствах. Бюллетень FG-IR-25-254.

На сентябрь 2026 года останавливаться на минимуме из старого бюллетеня неправильно. Например, январский FG-IR-25-778 уже требует 7.0.8 вместо 7.0.7 либо 7.2.3 вместо ранних выпусков 7.2 для исправления другой уязвимости. Я выбираю целевой образ по актуальным PSIRT, поддержке модели, совместимости телефонии и разрешённому пути обновления. Номер из прошлогодней новости для этого недостаточен. Fortinet: FG-IR-25-778.

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

• FortiVoice 6.4.0–6.4.10: исправление CVE-2025-32756 начиная с 6.4.11.
• FortiVoice 7.0.0–7.0.6: исправление начиная с 7.0.7.
• FortiVoice 7.2.0: исправление начиная с 7.2.1.

2. Первые действия: ограничить связь и сохранить доказательства

Я начинаю с внешнего межсетевого экрана: закрываю ненужный доступ к административному интерфейсу и порталу, ограничиваю исходящие соединения appliance и его доступ к соседним сегментам. Для подозрительного устройства собственная конфигурация фильтрации — недостаточная опора. Если телефония критична, сначала организую резервный маршрут входящих через оператора, затем изоляцию. Оставлять подтверждённо скомпрометированную АТС в общей сети ради удобства расследования я не выбираю.

До перезагрузки фиксирую время устройства и расхождение с коллектором, версию и build, доступные журналы, изменения конфигурации и сетевые соединения. При необходимости специалист собирает оперативные данные: после выключения их уже не получить. Одновременно сохраняю внешние журналы firewall, VPN, DNS и административного бастиона. Каждое действие записываю: кто подключался, откуда, когда и что выполнял. Такой журнал позволяет отделить следы расследования от действий атакующего. NIST SP 800-86, раздел 5.2.

Доступный штатный диагностический архив выгружаю через System → Maintenance → Configuration → Trace Log: Prepare, затем Download trace log. Но не считаю его образом диска: документация не обещает включить туда каждый интересующий файл. Архивы храню с ограничением доступа, контрольными суммами и временем получения. Для подключения использую контролируемую административную станцию; новые постоянные секреты на подозрительном appliance пока не ввожу. Fortinet: выгрузка trace-файла.

3. Стёртый crashlog: восстановить файл или восстановить хронологию

Для первичного просмотра HTTP-следов PSIRT приводит команду diagnose debug application httpd display trace-log. Интересуют сбои mod_fcgid, аварийное завершение admin.fe и сигнал 11. Отдельное падение процесса бывает обычной программной ошибкой. Я сопоставляю его с обращениями к веб-интерфейсу, неожиданными административными событиями и сетевой активностью. Пустой журнал также ничего не доказывает: возможны ротация, переустановка, обслуживание или целенаправленное стирание. Команда и признаки в PSIRT.

Слово «стёрли» скрывает разные операции. Если удалено имя файла, но работающий процесс продолжает держать открытый дескриптор, содержимое иногда ещё доступно через /proc/PID/fd. Проверять это имеет смысл до перезапуска процесса или устройства, при наличии разрешённого системного доступа. Обычный FortiVoice CLI нельзя автоматически считать Linux shell. Поиск дескрипторов выполняет специалист средствами, доступными именно на этой платформе. Linux: unlink, открытые дескрипторы.

Обнуление файла — другой случай. Если длину сократили до нуля, открытый дескриптор не возвращает прежнее содержимое. Именно такое различие важно при анализе fcgi.debug: нельзя обещать универсальное восстановление через /proc. Поиск остатков на носителе требует отдельного исследования образа; результат зависит от файловой системы, последующих записей и устройства хранения. Ставить утилиты восстановления прямо на исследуемую АТС — плохая идея: новые записи могут уничтожить оставшиеся данные. Linux: truncate.

Мой первый практический результат здесь — временная шкала. Ищу ранее выгруженные trace-пакеты, внешние события, резервные копии и сетевые журналы. Сверяю часы, перезагрузки и интервалы отсутствия записей. Если сам crashlog получить нельзя, так и пишу: содержимое не восстановлено, последовательность событий установлена частично. Удалённый syslog помогает только теми событиями, которые действительно отправлялись раньше; включение отправки сегодня прошлое не вернёт.

4. fcgi debug и cron: где искать следы сбора паролей

Начальная проверка из PSIRT — diag debug application fcgi. Неожиданное general to-file ENABLED требует разбирательства: это не настройка по умолчанию. Сначала сверяю её с заявками поддержки и действиями администраторов. Законная диагностика возможна. Но неизвестный автор изменения вместе с подозрительными заданиями планировщика — уже совсем другая картина. Fortinet: проверка fcgi debugging.

В опубликованной цепочке фигурируют /var/spool/crashlog/fcgi.debug, /var/spool/.sync и два расположения crontab, перечисленные ниже. Задания собирали данные, затем обнуляли исходный debug-файл. Поэтому маленький размер журнала не успокаивает. При разборе расписания 0 */12 * * * ориентируюсь на 00:00 и 12:00 по часам системы, а не на двенадцать часов после заражения. Это помогает выбрать временные окна для сопоставления с внешними событиями.

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

• /data/etc/crontab — проверить содержимое и изменения.
• /var/spool/cron/crontabs/root — проверить отдельно; одного расположения недостаточно.
• /var/spool/.sync — исследовать как потенциально чувствительный артефакт. [Перечень файлов PSIRT](https://fortiguard.fortinet.com/psirt/FG-IR-25-254).

5. PAM: проверяю подключение модуля, затем остальные механизмы закрепления

Уточню формулировку про «подменённую библиотеку». Fortinet описывает добавленную /lib/libfmlogin.so и изменённый /etc/pam.d/sshd, который её подключает. Это не сообщение о замене штатной libpam.so. Связанный файл /tmp/.sshdpm содержит собранные учётные данные. Поэтому проверка одного имени библиотеки недостаточна: нужен весь путь обработки аутентификации. PAM-артефакты в PSIRT.

Содержимое исследую на отдельной Linux-станции, используя полученную специалистом копию файловой системы, доступную без записи. Команды ниже предназначены для такой копии, а не для штатной консоли FortiVoice. Сначала проверяю наличие файлов, затем конфигурационные ссылки и контрольные суммы. Подозрительную библиотеку не запускаю. Эталон беру для той же модели и точного build из доверенного источника: отличие от произвольной соседней версии само по себе ничего не доказывает.

MD5 известного образца полезен для точного совпадения, но другой хеш не делает файл безопасным. Я расширяю проверку на PAM-конфигурацию, задания запуска, административные учётные записи, ключи и сетевые настройки. Дополнительные ориентиры PSIRT — /bin/wpad_ac_helper, /bin/busybox, /bin/fmtest и подключение mod_socks5.so в /etc/httpd.conf. Удалить найденную строку недостаточно: работающий процесс может уже использовать загруженный код, а другой механизм — восстановить изменение после перезапуска.

• Поиск ссылки в копии: `grep -nF 'libfmlogin.so' /mnt/fve-evidence/etc/pam.d/sshd`.
• Поиск связанных записей планировщика: `grep -nE 'fcgi[.]debug|/var/spool/[.]sync' /mnt/fve-evidence/data/etc/crontab /mnt/fve-evidence/var/spool/cron/crontabs/root`.
• Контрольная сумма копии: `sha256sum /mnt/fve-evidence/lib/libfmlogin.so`.
• Для сопоставления с PSIRT: MD5 libfmlogin.so — `364929c45703a84347064e2d5de45bcd`. [Хеш и дополнительные артефакты](https://fortiguard.fortinet.com/psirt/FG-IR-25-254).

6. Модельный проект: производственная компания на 120 рабочих мест

Разберу конкретную практическую схему для условного ООО «Вектор». Это расчётный учебный сценарий, а не отчёт о проведённом клиентском расследовании; события и результаты ниже заданы для разбора. Вводные: FortiVoice FVE-200F, 72 внутренних номера, два SIP-транка, расчётная нагрузка 16 одновременных разговоров. Адрес АТС — 10.44.30.10, административного бастиона — 10.44.10.5, коллектора — 10.44.40.20. Управляемых FortiVoice Gateway в схеме нет. До обнаружения проблемы веб-интерфейс был опубликован наружу.

По сценарию администратор уже обновил 7.0.6 до 7.2.4 build 518. Такой переход разрешён release notes, но сам по себе не является процедурой очистки. В материалах учебного инцидента заданы неизвестное включение debug, подозрительная cron-запись и чужой PAM-модуль. Их наличие после обновления — условие задачи, а не результат моего эксперимента с сохранением вредоносных файлов между версиями. Для реального устройства это пришлось бы установить сбором доказательств. Fortinet: путь обновления до 7.2.4.

Я отвожу 90 минут как плановое окно переключения, предварительно согласовав резерв входящих с оператором. Исследуемое устройство изолирую, телефонию готовлю на доверенной системе. Конфигурацию сравниваю с архивом за семь дней до предполагаемого начала инцидента: администраторы, направления вызовов, интеграции, сетевые разрешения. Дата архива сама по себе чистоту не гарантирует. Обнаруженный в вводных доступ АТС к серверному сегменту целиком заменяю разрешениями к конкретным службам; SIP и медиатрафик согласую с настройками транков, без универсального открытия всех UDP-портов.

Сценарий заканчивается приёмкой восстановленной телефонии: зарегистрированы 72 номера, проверены оба транка, входящие, исходящие, перевод вызова, DTMF и двусторонний звук. Нагрузочная цель — 16 разговоров; контрольная выборка — 20 тестовых вызовов. Это критерии приёмки, не заявленные измерения. Старое устройство остаётся изолированным для исследования, постоянные секреты заменены, журналы поступают на отдельный сервер. Возможную задержку регистрации после смены SIP-паролей я включаю в окно работ: без обновления настроек телефонов ротация сама создаст аварию.

• Правило доступа: к управлению АТС допускается только бастион 10.44.10.5; прямую интернет-публикацию управления и портала убрать.
• Внешняя фильтрация: разрешить АТС только согласованные соединения с оператором, DNS, NTP, коллектором и необходимыми интеграциями.
• Пример remote logging: Enabled — включено; IP — 10.44.40.20; Port — UDP 514; Level — Information; System — Configuration change, Admin activity, System activity.
• После настройки вызвать тестовое событие и проверить его именно на коллекторе. Эти параметры не означают автоматическую отправку fcgi.debug. [Fortinet: настройка журналирования](https://docs.fortinet.com/document/fortivoice-enterprise/7.0.8/fortivoice-phone-system-administration-guide/272304/configuring-logging).

7. Возвращаю систему в работу после восстановления доверия

При подтверждённом вмешательстве в системные файлы я выбираю восстановление из доверенного образа. Для аппаратного FortiVoice производитель отдельно описывает clean installation: она перезаписывает загрузочный носитель, требует локальной консоли и сбрасывает конфигурацию. Обычный upgrade выполняет другую задачу. Перед началом проверяю официальную процедуру для модели и версии, доступность образа и способ возвращения управления. Fortinet: clean firmware installation.

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

Постоянные секреты меняю с чистой станции и ввожу только в восстановленную систему. Начинаю с административных учётных записей, затем разбираю SIP-транки, интеграции, сервисные аккаунты и пользовательские пароли по реальному риску раскрытия. Если пароль администратора повторялся на других системах, границы работ расширяются. Для доступных механизму компрометации ключей и токенов рассматриваю отзыв и перевыпуск. Проверяю соседние узлы, к которым appliance обращался подозрительным образом.

На что я не трачу первый час: выяснение названия группировки и блокировку только исторического списка IP. Для остановки инцидента это вторично. Заявку закрываю после проверки версии и build, восстановленной конфигурации, ротации секретов, доставки журналов и работы телефонии. Несколько суток наблюдения полезны для обнаружения повторных признаков, но не заменяют восстановление. Формулировка «известных индикаторов не найдено» всегда должна сопровождаться описанием того, что действительно проверили.

• Зафиксировать происхождение образа и конфигурации, перечень восстановленных данных.
• Проверить управление извне: недоступно; с разрешённого бастиона: доступно.
• Убедиться, что старые секреты больше не работают, а телефоны и интеграции используют новые.
• Проверить внешние журналы, исходящие соединения и функциональные сценарии звонков.

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