После очистки сайта полезно задать исполнителю один вопрос: что теперь мешает записать вредоносный файл заново? Ответ «сканер ничего не нашел» описывает текущую проверку, но не объясняет причину заражения. Разберем, какие изменения должны остаться после лечения и как владельцу проверить их выполнение.
Здесь речь о сайте, который уже работает. Если чужие ссылки или перенаправления появились снова, нужен план действий при взломе сайта: профилактическая проверка не заменяет разбор нового инцидента.
Причина заражения: доказательства отдельно от предположений
Список удаленных файлов отвечает на вопрос о найденных следах. Для защиты сайта от вирусов нужен еще один результат: установленный или обоснованно предполагаемый путь, которым посторонний получил возможность менять сайт. Попросите объяснить, какие данные подтверждают вывод и какое изменение перекрывает этот путь.
Удобно разобрать один конкретный эпизод: когда обнаружили посторонний файл, какие события ему предшествовали, какой компонент или доступ проверили. Записи о входах, изменениях прав и действиях администраторов помогают разбирать такие события; их сбор предусмотрен рекомендациями OWASP по журналированию. Одного совпадения по времени недостаточно, чтобы уверенно назвать виновную учетную запись.
Если журналы не сохранились, причина может остаться неизвестной. Отчет должен разделять подтвержденное, вероятное и непроверенное. Для оставшихся вопросов нужны исполнитель и дата следующей проверки.
Доступы, которые пережили очистку
Проверка начинается со списка тех, кто может изменять сайт: сотрудники, подрядчики и автоматические интеграции. В него входят не только пользователи CMS, но и доступы к хостингу, передаче файлов, размещению обновлений и резервным копиям. Рядом с каждой записью должны быть владелец, назначение и необходимые полномочия.
Ненужные учетные записи отключают, а подозрительные доступы разбирают отдельно. Потенциально раскрытые пароли и ключи заменяют с отзывом прежних; остановка использующей ключ программы сама по себе его не аннулирует. Этот принцип описан в OWASP Secrets Management. После замены проверяют зависящие от этих данных обмены, отправку писем и другие подключения.
Активные сеансы тоже стоит включить в проверку: выяснить, какие завершаются при смене пароля, а какие требуют отдельного отзыва. Возможность просматривать и завершать сеансы предусмотрена рекомендациями OWASP по управлению сессиями. У разных систем это устроено по-разному, поэтому отметка «пароли сменили» не описывает весь объем работы.
Кто может вернуть удаленный файл
Повторное появление файла не всегда означает новое проникновение извне. На сервере может сохраниться механизм, который выполняет посторонние команды. Например, MITRE описывает веб-шеллы как способ удержания доступа, а задания cron — как средство повторного запуска вредоносного кода. Удаление одного результата их работы не отвечает на вопрос, остался ли сам механизм.
Попросите включить в проверку серверные задания по расписанию и планировщик CMS, если он используется. Для каждого задания исполнитель должен понимать, что запускается, от чьего имени и зачем. Незнакомое название само по себе не доказывает заражение: за ним может стоять рабочая выгрузка или служебная операция.
Отдельно стоит разобрать источники штатной записи файлов: публикацию обновлений, синхронизацию с рабочей копией, установку расширений. Вопрос к каждому одинаковый: откуда берется содержимое и проверен ли этот источник? Если очистили рабочий сайт, но не проверили пакет, которым его обновляют, завершенность работ еще нельзя оценить.
Обновления и изоляция ограничивают повторное заражение
После очистки составляют список CMS, расширений, шаблонов и серверного окружения. Для каждого компонента выясняют, получает ли он исправления безопасности и есть ли непримененные обновления. Ненужное убирают; для необходимого, но неподдерживаемого компонента назначают замену или отдельное решение с указанным сроком.
Важна и возможность записи между соседними сайтами. Если несколько проектов работают с общими правами, зараженный проект может угрожать остальным. Отдельные каталоги сами по себе еще не доказывают изоляцию: проверяют учетные записи процессов и доступ к чужим файлам. Обновления, ограничение прав и разделение установок рассматриваются в официальном руководстве WordPress по защите.
Обещание «сайты, защищенные от вирусов навсегда» проверить невозможно. Принимать стоит конкретные меры, их ограничения и порядок дальнейшего обслуживания. Защита снижает риск, но требует пересмотра при смене компонентов, подрядчиков и условий размещения.
Резервные копии и уведомления должны проходить проверку
Резервная копия нужна не для предотвращения записи вредоносного файла, а для возможности восстановить данные. У нее должны быть понятные состав, срок хранения и место размещения. Для сайта с базой данных одного архива файлов недостаточно: документация WordPress о резервировании отдельно указывает на необходимость сохранять файлы и базу.
Проверку копий полезно завершить пробным восстановлением в отдельной среде. Зафиксируйте, из какой копии его выполнили, что удалось открыть и какие данные проверили. Дату архива сопоставляют с доступными сведениями о заражении: отметка «создан вчера» сама по себе не делает его пригодным для безопасного возврата.
Уведомления проверяют доставкой тестового сигнала ответственному человеку. Заранее согласуют события, требующие реакции: неожиданные изменения кода, создание привилегированной учетной записи, остановку резервирования. Журналы должны быть доступны для разбора, а важные сигналы — доходить до ответственных; такой подход описан в OWASP Logging.
Для владельца результат выглядит просто: известно, кто получает сигнал, когда его разбирает и к кому обращается при подозрении на заражение. Письмо в забытый ящик не завершает настройку наблюдения. Периодичность проверок и допустимое время реакции нужно согласовать явно.
Защита сайта от вирусов: что принимать в отчете
Фраза «очистку я уже оплатил» справедлива: прежде чем заказывать новые работы, сравните результат с согласованным объемом. Если поиск причины, отзыв доступов или проверка планировщика входили в очистку, попросите показать их результат. Если не входили, оформите оставшиеся проверки отдельными задачами с понятными границами.
В отчете должны быть:
- найденные следы и сведения о вероятном способе проникновения;
- проверенные доступы, отозванные полномочия и результат замены ключей;
- проверенные механизмы записи файлов и задания по расписанию;
- состояние обновлений, прав и изоляции соседних проектов;
- результат проверки копии и доставки уведомлений;
- непроверенные участки, ответственные и сроки следующих действий.
По этому списку удобно обсуждать сопровождение: кто обновляет компоненты, пересматривает доступы и разбирает сигналы.
Пришлите отчет об очистке и описание текущего состояния сайта — в рамках поддержки сайта разберем, какие причины и доступы еще требуют проверки.