Как настроить журнал событий сайта для расследования

Журналы CMS помогают восстановить последовательность действий, но не отвечают за вас на вопрос, кто взломал сайт и как. Чтобы расследование не начиналось с догадок, фиксируйте входы, изменения учётных записей и файлов, собирайте системные события отдельно и заранее проверяйте, что записи доступны после сбоя.

Что журналы действительно дают при инциденте

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

Логи помогают проверить гипотезы, но не доказывают автоматически, что подозрительный пользователь был злоумышленником. Учетная запись могла использоваться владельцем, интеграцией или плановой задачей; часть действий могла идти от общего пользователя. Я сверяю запись CMS с веб-сервером, системой, резервными копиями и реальными изменениями сайта. Если серверные часы расходятся, события будут выглядеть в неправильном порядке. Поэтому зафиксируйте источник времени и проверяйте, что часы на узлах синхронизируются.

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

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

События, которые стоит собирать

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

Следующая группа — управление доступом. Важны создание, блокировка и удаление учётных записей, выдача административных ролей, изменение прав и действия с ключами интеграций. Отдельно отмечайте изменение настроек безопасности и отключение журналирования. Укажите исполнителя и объект изменения, если журнал это позволяет. Если все работают под одним общим администратором, запись покажет действие общей учётной записи, но не конкретного сотрудника. Общая учётка удобна примерно до первого вопроса «кто это сделал?».

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

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

• Входы и изменения учётных записей.
• Выдача ролей и прав.
• Обновления и правки файлов.
• Изменения конфигурации и содержимого.

Журнал CMS и системные логи — разные слои

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

В 1С-Битрикс события настраиваются в главном модуле: можно выбрать типы записей, срок хранения, а также дополнительную запись в syslog или JSON-файл. В учебной документации продукта для журнала событий указан срок хранения по умолчанию семь дней. Это настройка конкретного продукта, не универсальная норма для всех сайтов; проверьте её на своей установке и измените под задачи расследования. Записи могут содержать пользователя, время, событие, IP, User-Agent и URL — полезный набор для разбора, если поля включены и доступ не ограничен.

У Drupal есть модуль Database Logging (dblog), который хранит системные события в базе данных и помогает просматривать хронологию работы сайта. Но документация Drupal отдельно предупреждает: эти записи могут очищаться администраторами и задачами cron, поэтому dblog не следует использовать как криминалистический журнал; для этой цели предлагается модуль Syslog. Это хороший пример того, почему слово «логирование» не означает автоматически «надёжное хранение». Проверьте, куда пишет ваш модуль, кто может очистить данные и переживут ли записи отказ базы.

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

• CMS: действия приложения и пользователей.
• Веб-сервер: запросы и ответы.
• ОС: входы и системные события.

Где хранить записи и как выбрать срок

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

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

Ротация должна сохранять нужную историю и не блокировать создание новых записей. Проверьте, что архив действительно создаётся, доступен после ротации и удаляется только после согласованного срока. Отдельно проверьте заполнение диска и ошибки записи: когда место закончилось, журнал может перестать пополняться. На Linux за ротацию часто отвечает logrotate, но конкретные правила и расписание зависят от дистрибутива и конфигурации. Не копируйте чужой конфиг без проверки владельца файлов, прав и того, какой процесс продолжает писать в журнал.

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

• Отдельный коллектор с ограниченными правами.
• Ротация и контроль свободного места.
• Сроки по требованиям и риску.

Порядок настройки и проверка журналирования

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

Включите нужные события в тестовой среде или в согласованное окно работ. Для Bitrix проверьте список типов журнала, срок хранения и дополнительную запись в syslog либо файл JSON, если она нужна. Для Drupal решите, нужен ли dblog для оперативной диагностики, а Syslog — для передачи событий во внешнюю систему. Для WordPress проверьте выбранное расширение и его совместимость. Не включайте неизвестные модули на работающем сайте наугад: сначала оцените источник, права и влияние на базу.

Проведите тест: выполните безопасный вход, создайте тестовую учётную запись или измените тестовую страницу, затем проверьте запись в панели CMS, на коллекторе и в резервной копии журнала. Сопоставьте время, пользователя, тип события и объект. Проверьте также отказ канала передачи: понятно ли, что коллектор недоступен, и сохраняет ли источник события локально до восстановления связи? Если система молчит при тесте, я не объявляю аудит настроенным. Найдите конкретную причину и повторите проверку.

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

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

Как читать события при подозрении на взлом

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

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

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

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

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