Как отличить взлом сайта от обычного сбоя

Проверяйте не возраст CMS сам по себе, а статус поддержки, изменения страниц и файлов, записи о входах и необъяснимую нагрузку. Один сигнал не доказывает взлом: я сопоставляю независимые следы, сохраняю состояние сайта и только потом выбираю способ локализации и восстановления.

Признак №1: CMS или расширение осталось без поддержки

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

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

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

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

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

• Запишите название и точную версию каждого компонента.
• Сверьте статус поддержки и бюллетени безопасности проекта.
• Проверьте, кто отвечает за обновление темы или модуля.
• Сначала испытайте обновление или замену на копии сайта.

Признак №2: появились чужие страницы или редиректы

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

Владелец подтверждённого ресурса может открыть в Google Search Console отчёт «Проблемы безопасности»: Google показывает обнаруженные типы проблем и примеры адресов. Поиск или браузер также могут предупредить посетителя, если Google считает сайт опасным или взломанным. Это важная зацепка, но предупреждение не заменяет осмотр сайта, а отсутствие предупреждения не доказывает чистоту. Проверяю конкретные страницы и устраняю причину. Общие шаги защиты CMS собраны в статье как защитить CMS от взлома.

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

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

• Сохраните адрес страницы и вид редиректа.
• Сравните страницу с заведомо чистой копией.
• Проверьте Security Issues в Search Console, если сайт добавлен туда.

Признак №3: журналы показывают незнакомые действия

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

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

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

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

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

Признак №4: файлы сайта изменились без объяснения

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

Для WordPress есть конкретная проверка через WP-CLI: команда «wp core verify-checksums» сравнивает файлы ядра с контрольными суммами WordPress.org. Для поддерживаемых в каталоге WordPress.org плагинов есть отдельная команда «wp plugin verify-checksums». Несовпадение надо изучить: это может быть правка разработчика, локальная модификация или постороннее изменение. Совпадение проверенных сумм тоже не проверяет базу данных, все темы, частные расширения и собственный код. По другим CMS используйте штатные средства проверки проекта и сохранённую чистую копию; например, разбор уязвимостей Drupal отдельно рассматривает обновления и поддержку компонентов.

У WordPress команда сверяет версию и локаль установленного ядра с официальными контрольными суммами; если параметры установки отличаются от тех, что команда определила автоматически, в документации предусмотрены аргументы версии и локали. Не добавляйте флаги наугад: сначала проверьте фактическую версию и настройки установки. Для плагинов команда работает только там, где каталог предоставляет ожидаемые контрольные суммы; частный код и файлы, которых нет в каталоге, этим способом не покрываются.

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

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

Признак №5: нагрузка или поведение сайта резко изменились

Медленная страница — симптом, а не диагноз. Причиной бывают рост посещаемости, медленный запрос к базе, исчерпание ресурсов тарифа, внешняя зависимость или ошибка после релиза. Я сравниваю текущую картину с обычной для этого сайта: когда началось замедление, какие страницы затронуты, изменился ли трафик, есть ли ошибки приложения, какие процессы и задачи потребляют ресурсы. Само по себе высокое использование CPU не доказывает работу майнера или атаку; причина должна подтверждаться процессами, журналами и исходящим трафиком.

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

Для практической диагностики выпишите время начала замедления, долю ошибок сервера, затронутые страницы и результаты измерения ресурсов. Сравните эти значения с обычным периодом, когда сайт работал нормально; одиночный пик может совпасть с рассылкой, публикацией или резервным копированием. Затем сопоставьте график с задачами по расписанию и журналом релизов. Такой порядок не обещает мгновенно назвать причину, зато не позволяет принять любой скачок нагрузки за криптомайнер.

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

Что делать, если нашли подтверждённый след

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

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

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

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

Результат проверки оформите коротко: подтверждено, исключено, осталось проверить. Укажите, из какой копии восстановили сайт и какие адреса повторно открыли. Если посетителям показывалось предупреждение, после исправления отдельно перепроверьте его статус; исправленный сайт и обновившаяся отметка у поисковика могут быть не синхронны мгновенно.

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

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