Как замечать чужие правки в файлах CMS

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

Что показывает контроль целостности CMS

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

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

Как собрать эталон, которому можно доверять

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

Храните верификационные данные отдельно от каталога сайта и ограничьте запись к ним. Для 1С-Битрикс официальная инструкция описывает сбор данных по выбранным папкам и расширениям, последующую проверку по этому файлу и рекомендует скачать его на локальный компьютер. В той же документации отмечено, что при первом сборе создаётся исходная база для последующих сравнений. Это полезная конкретика: реперная точка должна пережить проблему на веб-сервере. После обновления ядра или компонента сначала зафиксируйте штатное изменение, проверьте результат, а затем сформируйте новую базу по чистому состоянию. Не обновляйте эталон автоматически по любому сигналу — получится кнопка «считать нормой всё, что случилось». Не храните единственную копию эталона в той же учётной записи и на том же доступном для записи томе, что и сайт. При компрометации обоих источников сравнение потеряет смысл. Проверяйте также, что сама процедура восстановления доступа к эталону описана: запертая база, которую никто не может найти, полезна примерно как инструкция в сейфе без ключа.

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

Чем проверять WordPress и 1С-Битрикс

Для ядра WordPress не нужно изобретать функцию или писать свой скрипт с хешами: WP-CLI умеет сверять установленное ядро с контрольными суммами WordPress.org. Базовая команда — wp core verify-checksums; для отдельной версии можно добавить --version=<версия>, для локали — --locale=<локаль>. Это проверка именно ядра. Плагины, темы и собственные файлы требуют отдельного подхода; для плагинов из каталога WordPress.org есть отдельная команда проверки, а для коммерческого и самописного кода нужны доверенные исходники поставщика или ваш проверенный эталон. Проверку запускайте с правами, достаточными для чтения нужных файлов, но не раздавайте ей без необходимости полномочия на изменение сайта. Сверка должна сообщать о состоянии, а не одновременно чинить его по догадке. Перед запуском в рабочей среде проверьте команду на копии проекта и убедитесь, что CLI указывает именно на нужную установку.

В документации WP-CLI есть важная оговорка: --include-root добавляет проверку корневого каталога и предупреждения о посторонних элементах, но это всё ещё не универсальная проверка каждого файла во всех каталогах сайта. Для дополнительной проверки можно использовать сканирование кода WordPress, но его результат тоже нужно разбирать. Ошибка проверки не доказывает заражение: файл мог измениться при обновлении, локализация могла не совпасть, а кастомизация — быть штатной. У Bitrix есть собственная страница контроля целостности: в документации указаны ядро, системные области и публичная часть продукта. Путь в интерфейсе и доступность функций зависят от версии и редакции, поэтому сверяйте инструкцию со своей установкой, а не переносите меню из чужого скриншота. Если проверка пропускает файл, выясните почему: компонент может не публиковать контрольные суммы, версия или локаль могли отличаться, либо путь находится вне области проверки. В WP-CLI сводка ядра не равна полному обзору wp-content. Для проверки кода плагинов из каталога есть отдельная команда, но отсутствие доступной контрольной суммы тоже нужно показывать как непроверенное состояние, а не как успех.

• WordPress: `wp core verify-checksums` — проверка ядра.
• 1С-Битрикс: встроенная проверка выбранных системных областей.
• Собственные компоненты: сравнение с контролируемым эталоном.

Как убрать шум, не оставив слепые зоны

Кеш, сессии, временные файлы и пользовательские загрузки часто меняются по штатным причинам. Если без разбора включить их в тот же поток тревог, дежурный быстро перестанет читать уведомления. Но исключить целиком uploads и забыть о нём — тоже плохой план: в каталоге загрузок могут появиться исполняемые файлы, а последствия зависят от конфигурации веб-сервера и приложения. Я разделяю наблюдение: код проверяю на соответствие образцу, каталоги данных — на неожиданные типы файлов и изменения, которые важны для конкретного сайта. Исключения фиксирую явно и пересматриваю после изменений приложения. Важно знать и режим записи приложения: какие расширения разрешены для загрузки, где хранятся оригиналы и включено ли исполнение скриптов в этих каталогах. Это уже настройка конкретной CMS и веб-сервера, поэтому проверяйте её по фактической конфигурации. Мониторинг обнаружит часть изменений, но не исправит небезопасное разрешение на выполнение загруженного кода.

Не существует универсального списка путей вроде /cache, /logs или /tmp, который безопасно вставить на любой CMS: размещение зависит от проекта. Сначала посмотрите, куда приложение действительно пишет кеш, журналы, сессии и загрузки. Затем настройте отдельную политику: например, пропускать ожидаемые изменения в данных, но отмечать появление PHP-файлов в каталоге, где должны лежать только изображения. Любое правило исключения — это граница видимости. Запишите, зачем оно нужно и кто его согласовал. Иначе через полгода никто не вспомнит, почему мониторинг «не замечает» именно эту папку. Шум лечат точной настройкой и маршрутизацией уведомлений, а не отключением наблюдения целиком. Уведомления группируйте по приоритету и маршрутизируйте к человеку, который может принять решение. Отдельно отметьте изменение ядра, появление нового исполняемого файла и ожидаемую запись очередного кеша. Одинаковый уровень для всех событий быстро обесценивает канал: срочная тревога тонет среди десятков штатных операций.

• Проверьте реальные пути записи конкретной CMS.
• Разделите код и пользовательские данные.
• Для исключений укажите причину и владельца.

Как разбирать найденное изменение

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

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

Свяжите проверку с журналами и обновлениями

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

Для Bitrix в официальном учебном материале рекомендуют регулярную проверку целостности примерно раз в неделю, а также перед системным обновлением; после обновления следует собрать новые сведения о файлах. Это ориентир именно из инструкции Bitrix, не универсальный норматив для любой CMS. Частоту для другого сайта выбирайте по темпу обновлений, цене пропущенного изменения и возможностям инструмента. Поставьте уведомления так, чтобы ответственному было понятно, какой путь изменился и что делать дальше. После штатного релиза сверяйте список изменений и только затем обновляйте эталон. В практических шагах защиты CMS важен тот же порядок: обновление и контроль доступа дополняют проверку файлов, а не заменяются ею. Уведомление должно включать путь, время, тип события, ссылку на инструкцию реакции и ответственного. Для изменений при плановом релизе можно заранее открыть окно работ, чтобы дежурный знал ожидаемый список файлов. После окна сравните фактические изменения с планом; закрытие по расписанию без сверки — такая же автоматизация самоуспокоения.

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