Когда на сайте происходит что-то подозрительное — неожиданно появился новый администратор, изменился файл, который никто не трогал, — первый источник ответа не догадки, а журналы Битрикса. Разберём, где искать эти данные и как читать их системно, а не открывать наугад в панике.
Журнал событий (общий лог действий)
Раздел Настройки → Инструменты разработчика → Журнал событий фиксирует действия пользователей и системные события — вход в систему, изменение настроек, ошибки модулей. Это самый общий источник, куда стоит заглянуть первым при расследовании инцидента, но детализация зависит от настроенного уровня логирования — по умолчанию фиксируется не всё подряд.
Журнал проактивной защиты
Отдельный от общего журнала событий, раздел Проактивная защита → журнал атак фиксирует именно заблокированные и подозрительные запросы — попытки SQL-инъекций, XSS, брутфорс входа. Для расследования именно взлома или попытки взлома этот журнал информативнее общего журнала событий, поскольку сфокусирован конкретно на угрозах, а не на всех действиях подряд.
Нужна помощь с Битрикс?
Лог изменений файлов (веб-антивирус)
Модуль веб-антивируса при регулярном сканировании фиксирует изменения файлов сайта — новые, изменённые или подозрительные файлы попадают в отчёт сканирования. Это особенно ценно при подозрении на взлом через уязвимость, когда злоумышленник добавил свой файл (веб-шелл) в файловую структуру сайта, — обычный журнал действий пользователя такое изменение не поймает, если файл добавлен не через административную панель.
Логи веб-сервера как источник вне Битрикса
tail -f /var/log/nginx/access.log | grep -i "wp-admin\|.php"Логи nginx и PHP-FPM на уровне сервера фиксируют каждый запрос независимо от того, что происходит внутри самого приложения, — это единственный источник, показывающий реальные IP-адреса, частоту запросов и обращения к несуществующим или подозрительным URL, включая те, что были заблокированы ещё до попадания в PHP. При серьёзном расследовании инцидента логи сервера дополняют, а не заменяют журналы Битрикса.
Что искать при подозрении на компрометацию
- Новые или изменённые файлы с недавней датой модификации в неожиданных местах файловой структуры.
- Вход в административную панель с незнакомого IP-адреса или в необычное время.
- Новые учётные записи с правами администратора, не созданные штатным процессом.
- Массовые запросы с одного адреса к формам, принимающим пользовательский ввод.
Настройка уровня детализации логирования
Уровень логирования по умолчанию рассчитан на баланс между информативностью и объёмом накапливаемых данных — для расследования конкретного инцидента временное повышение уровня детализации может дать больше данных, но стоит помнить, что такая настройка увеличивает нагрузку на базу данных и объём хранимых логов, поэтому не стоит держать максимальную детализацию постоянно без реальной необходимости.
Хранение логов вне самого сервера
Если сервер скомпрометирован полностью, злоумышленник теоретически может удалить или подделать локальные логи, чтобы скрыть следы, — для критичных проектов имеет смысл настроить пересылку логов на отдельный сервер логирования или внешний сервис, недоступный для изменения с самого веб-сервера, что делает такую подделку значительно сложнее.
Частые ошибки
- Проверяется только журнал событий, но не логи веб-сервера. Часть картины инцидента остаётся невидимой без серверных логов.
- Расследование начинается без чёткого списка того, что искать. Просмотр логов "на глаз" без системного подхода занимает намного больше времени.
- Логи хранятся только локально на потенциально скомпрометированном сервере. Риск подделки следов при полной компрометации сервера.
Итог
Расследование подозрительной активности на сайте 1С-Битрикс опирается на три взаимодополняющих источника: журнал событий и журнал проактивной защиты внутри системы, отчёт веб-антивируса об изменениях файлов и логи веб-сервера снаружи приложения. Полная картина инцидента собирается только при сопоставлении данных из всех источников сразу, а не из одного изолированного журнала.