RECOVERED и VERIFIED

Почему это различие пропускают под давлением

Как только сервис снова начинает отвечать нормально, немедленное давление восстановить бизнес-процессы обычно перевешивает более медленную, тщательную работу по подтверждению того, что реальная первопричина найдена и устранена, а не просто что симптом исчез.

Что на самом деле включает проверка

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

О том, как проверка вписывается в полное восстановление, читайте в нашем руководстве по реагированию на взлом сервера.

Как Server Warden разделяет эти два состояния

На странице продукта Server Warden описывает замкнутый цикл: наблюдение, обнаружение, корреляция, сдерживание, восстановление, проверка. Правило сформулировано прямо: перезапуск или откат не являются доказательством. Статус VERIFIED присваивается только после независимых проверок состояния, хешей, прослушиваемых портов, firewall, идентичности и проверок, специфичных для запущенного сценария.

Security Lab показывает ту же идею на временной шкале: обнаружено, скоррелировано, восстановлено, проверено, с Recovery Proof и доказательствами. Объяснение простое: команда может выполниться успешно, а сервер при этом не вернуться в норму, поэтому после действия запускаются отдельные проверки файлов, сервисов и сети, задействованных в этом инциденте. Только когда они пройдены, результат становится VERIFIED.

В Lab прямо оговорено одно: каждый запуск на этой странице синтетический. Ни один хост не сканируется, ни на одной машине ничего не восстанавливается, а применение мер отображается как наблюдаемое, а не как достигнутое. Это демонстрация модели, а не оценка вашего сервера. Для оценки на сайте есть бесплатный read-only аудит.

Те же проверки вручную

На любом сервере можно приблизительно воспроизвести те же категории проверок. В плейбуке CISA по реагированию на инциденты сказано, что восстановление должно сопровождаться повышенной бдительностью, чтобы убедиться в отсутствии признаков активности противника, и предлагается рассмотреть независимую проверку действий по реагированию. С чего начать:

debsums -c
rpm -Va
ss -tulpn
awk -F: '($3 == 0) {print $1}' /etc/passwd

Первые две команды сравнивают файлы установленных пакетов с записанными контрольными суммами (семейство Debian и семейство RPM соответственно). Учтите, что в справке debsums сам инструмент назван малопригодным как средство безопасности: атакующий с root может изменить и файлы, и записи, а файлы вне пакетов не охвачены. Более надёжное свидетельство даёт пересборка из доверенного образа или мониторинг целостности файлов с эталоном, хранящимся в другом месте.

Третья команда выводит прослушиваемые сокеты для сверки с ожидаемыми; четвёртая это проверка UID 0. Добавьте просмотр authorized_keys всех учётных записей, действующих правил firewall и запланированных задач. Если какая-то проверка не пройдена, инцидент не закрыт: сдерживайте заново и возвращайтесь к анализу.

Связанные термины: Реагирование на инциденты, Сдерживание, Мониторинг целостности файлов, Read-only аудит.