Как быстро проверить Drupal и понять, что делать дальше

За первые пять минут можно проверить, поддерживается ли Drupal, какие обновления ждут ядро и модули, и есть ли в журналах подозрительные события. Этого хватает для первичной оценки, но не для вывода «сайт чист» или «нас взломали». Ниже — порядок проверки и действия, если следы подтвердятся.

Начните с версии и обновлений Drupal

За первые пять минут я выясняю две вещи: какая версия Drupal фактически развернута и есть ли для неё открытые обновления безопасности. Сверяю административный отчёт о состоянии сайта с составом пакетов и lock-файлом проекта. Заголовок HTTP или HTML-код страницы для этого ненадёжен: версию могут скрыть, закешировать или оставить в шаблоне после обновления. Если у команды нет доступа к коду, фиксирую это как пробел в проверке, а не угадываю релиз по внешнему виду сайта. Если нужна помощь с этой работой, мы проводим аудит информационной безопасности.

Для проекта, который ведётся через Composer, команда composer outdated "drupal/*" показывает пакеты Drupal с доступными обновлениями. Это инвентаризация, а не команда на обновление. В официальной инструкции Drupal для аудита зависимостей также описан composer audit; найденные пункты нужно сверить с сообщениями Drupal Security Team и конкретными ограничениями проекта. Сначала изучаю список, проверяю совместимость и готовлю обновление в тестовом окружении. Запускать composer update на рабочем сайте наудачу — быстрый способ получить ещё одну задачу вместо ответа.

У старой ветки есть вполне измеримый риск. Поддержка Drupal 7 завершилась 5 января 2025 года: после этой даты сообщество не выпускает для неё обычные обновления безопасности. Это не доказывает, что конкретный сайт уже взломан, но означает, что уязвимости могут остаться без исправления. Для такого проекта я ставлю в план миграцию или отдельно проверяю условия расширенной поддержки; фраза «пока открывается» поддержку не заменяет.

Проверьте модули, темы и права на файлы

Затем сверяю установленные модули и темы с тем, что действительно используется сайтом. Устаревший пакет заслуживает проверки версии и advisory, но правило «не обновлялся полгода — удалить» ничего не говорит о наличии уязвимости. Отключённый модуль тоже не становится автоматически дырой: важны его код на диске, доступность обработчиков, версия и конфигурация. Перед удалением проверяю зависимости и то, не хранит ли модуль нужные данные или настройки. Для Composer-проекта изменение состава фиксируется в composer.json и composer.lock, а не ручным удалением каталога через панель.

Права доступа я проверяю по владельцу, группе и роли веб-сервера, а не по магическим числам. Руководство Drupal рекомендует не давать веб-серверу возможность менять исполняемый код; запись оставляют только тем каталогам, которым она нужна для работы, например каталогу пользовательских файлов. Точный набор прав зависит от схемы владельцев и развёртывания. Поэтому универсальное «поставьте 755 на папки и 644 на файлы» может оказаться неверным, а 777 раздаёт право записи всем локальным пользователям и процессам. Исправление должно следовать устройству конкретного хостинга.

В sites/default/files ищу неожиданные исполняемые файлы и изменения, которых не объясняет работа редакторов или интеграций. PHP-файл в каталоге загрузок — повод проверить происхождение файла, настройки исполнения и время появления, а не автоматическое доказательство взлома. Сравниваю подозрительный файл с чистым релизом, смотрю владельца и связанные запросы, сохраняю копию для анализа. Не открываю такой файл в браузере и не запускаю его «для проверки». Подозрительные изменения и обычные пользовательские загрузки нужно разделить до очистки.

Читайте журналы как цепочку событий

Я сопоставляю журнал веб-сервера, PHP и самого Drupal по времени, адресу запроса и результату. На одном сервере системный журнал будет в файлах, на другом — в journald; расположение зависит от дистрибутива и настройки. Поэтому /var/log/auth.log нельзя объявлять обязательным путём для всех. Важно увидеть последовательность: запрос к уязвимому или неизвестному маршруту, ошибку приложения, появление файла или изменение учётной записи. Если журналы уже ротированы или срок хранения слишком короткий, отмечаю это отдельно: отсутствие старой записи не доказывает, что события не было.

Запрос с SQL-подобной строкой, <script> или именем несуществующего файла чаще говорит о попытке сканирования, а не об успешном проникновении. Код ответа тоже не даёт готового вердикта: 404 часто означает, что адреса нет, а 200 лишь сообщает, что сервер что-то ответил. Я проверяю, дошёл ли запрос до приложения, изменились ли данные после него и совпадает ли время с другими следами. Для каждого подозрительного эпизода сохраняю исходную запись и контекст вокруг неё, вместо того чтобы вырывать одну строку из журнала.

Дальше ищу события, которые труднее объяснить случайным сканером: созданную без заявки учётную запись с правами администратора, неожиданные изменения кода, новые задания планировщика, незнакомые исходящие соединения. Ни одна функция PHP вроде eval или base64_decode сама по себе не является доказательством вредоносного кода: такие вызовы встречаются и в легитимных проектах. Полезнее найти конкретное изменение и понять, кто его внёс и каким запросом. В этом помогают аудит изменений Drupal и базовая проверка журналов веб-сервера; похожий разбор следов я описываю в статье о признаках вредоносного PHP в логах.

Если взлом подтвердился — сохраните следы

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

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

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

Закройте причины и назначьте регулярную проверку

После восстановления фиксирую, кто отвечает за выпуск обновлений, тестирование и возврат к предыдущей версии. Официальный процесс Drupal для Composer-проектов включает проверку зависимостей, обновление кода по lock-файлу, применение необходимых обновлений базы и очистку кэша. Команды запускают в согласованном порядке и проверяют результат на тестовой копии, а не копируют вслепую в продакшен. Для первой оценки достаточно увидеть список пакетов и advisory; для обновления нужны резервная копия, план отката и проверка ключевых страниц сайта.

Отдельно убираю лишние постоянные права и доступы. Веб-серверу не нужны права на изменение ядра и модулей при обычной работе сайта; каталог загрузок настраивают отдельно и проверяют, что в нём не исполняется пользовательский код. У администраторов должны быть персональные учётные записи с минимально необходимыми полномочиями, а доступ бывшего сотрудника или подрядчика нужно отзывать, а не хранить «на всякий случай». Проверка доступа к конфигурации и журналам — часть обычного обслуживания, не разовая операция после инцидента.

Назначаю ответственного за просмотр новых сообщений Drupal Security Team и за периодическую сверку установленных версий с поддерживаемыми. Ритм выбирают по критичности проекта и срокам исправлений, а срочное advisory обрабатывают отдельно от планового окна. Для контроля изменений полезнее наблюдать за версиями пакетов, появлением новых администраторов и изменениями файлов, чем запускать неизвестный онлайн-сканер и считать зелёный значок сертификатом безопасности. Общие принципы проверки поверхности сайта собраны в материале про аудит веб-безопасности.

Условный разбор для студии «Лагуна-Плюс»

Разберу условный сценарий с компанией из исходных данных — студией «Лагуна-Плюс». Допустим, сотрудники заметили посторонние ссылки в выдаче и просят проверить сайт на Drupal. Это симптом для расследования, но он не говорит ни о конкретной причине, ни о дате проникновения. Я не приписываю студии реальную атаку, версию ядра или найденный бэкдор: таких подтверждённых исходных данных для этой статьи нет. Начинаю с фиксации жалобы, времени её появления и доступного состава сайта.

В первые пять минут я проверяю, поддерживается ли установленная ветка, какие обновления показывают Composer и Drupal Security Advisories, кто имеет административные права и есть ли несогласованные изменения в коде. Если выясняется, что это Drupal 7, у команды есть подтверждённая дата окончания поддержки — 5 января 2025 года — и понятный повод срочно планировать переход. Затем я сопоставляю запросы веб-сервера с PHP-журналом и осматриваю каталог загрузок. Ни поиск PHP-файла, ни рекламная ссылка по отдельности не позволяют назначить виноватый модуль.

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

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