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

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

Зачем вообще собирать журналы событий

Журналы событий нужны не «для галочки» и не только для того, чтобы успокоить службу безопасности. Их практическая ценность раскрывается в момент инцидента, когда необходимо:

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

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

Минимальный набор логов для сайта

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

Что обязательно должно быть в каждом событии

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

• точное время события с указанием часового пояса — без этого невозможно выстроить хронологию, особенно если серверы находятся в разных локациях;
• источник запроса или действия: IP-адрес, порт, идентификатор сессии;
• идентификатор пользователя или сессии — критично для связывания действий с учётной записью, а не просто с IP;
• имя ресурса, файла, маршрута или API-метода — что именно было целью;
• результат действия: успех, отказ, ошибка — позволяет отличить попытку от реализованной атаки;
• технические идентификаторы для корреляции между сервисами: request ID, trace ID — без них сопоставить записи из разных систем практически нереально.

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

Какие логи нужны в типовых сценариях

1. Подбор пароля или захват учётной записи

Смотрите:

• auth logs;
• application logs;
• access logs;
• журналы MFA, если она используется.

Ищите:

• серию неудачных входов с одного или нескольких IP — особенно если они географически разбросаны;
• смену IP-адреса или географии в рамках одной сессии — признак перехвата сессии или использования украденных cookie;
• успешный вход сразу после череды провалов — классический сценарий подбора;
• сброс пароля и последующий вход без типичного для пользователя паттерна действий;
• отключение второго фактора — часто злоумышленники, получив доступ, сразу упрощают себе дальнейший вход;
• действия под учётной записью, которые пользователь обычно не совершает: изменение платёжных реквизитов, массовая выгрузка данных, добавление новых администраторов.

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

2. SQL-инъекция

Смотрите:

• access logs;
• error logs;
• database logs;
• WAF logs.

Ищите:

• аномальные параметры в URL или POST-запросах: кавычки, UNION, SLEEP, INFORMATION_SCHEMA;
• ошибки SQL в ответах приложения — часто видны в error log как «SQL syntax error» или «unclosed quotation mark»;
• массовые одинаковые запросы с небольшими вариациями — признак автоматизированной эксплуатации;
• нетипично длинные параметры — могут содержать закодированные полезные нагрузки;
• обращение к чувствительным таблицам или полям, нехарактерное для обычной работы приложения.

Важно помнить, что WAF может блокировать только часть атак, особенно если работает в режиме обучения или мониторинга. Поэтому даже при наличии WAF нужно проверять, не прошли ли вредоносные запросы мимо него. Логи базы данных здесь незаменимы: они покажут, был ли выполнен подозрительный запрос, даже если приложение не вернуло ошибку.

3. Загрузка webshell или вредоносного файла

Смотрите:

• access logs;
• application logs;
• file integrity logs;
• OS logs;
• WAF logs.

Ищите:

• загрузку файлов в нестандартные директории — например, в /uploads/avatar.php вместо /uploads/avatar.jpg;
• неожиданные расширения: .php, .phtml, .shtml среди изображений или документов;
• последующий вызов загруженного файла — в access.log будет обращение к тому же пути, куда только что был загружен файл;
• запуск новых процессов на сервере от имени веб-пользователя — видно в системных логах;
• изменение прав доступа или владельца файла — злоумышленники часто делают webshell исполняемым.

На практике webshell часто загружается через уязвимости в плагинах CMS или формах обратной связи. Поэтому file integrity logs должны отслеживать не только ядро, но и все директории, доступные для записи веб-сервером.

4. Подмена контента на сайте

Смотрите:

• application logs;
• access logs;
• auth logs;
• file integrity logs;
• OS logs.

Ищите:

• вход администратора с необычного места — IP, страна, время суток;
• изменения CMS, шаблонов, скриптов — особенно массовые правки за короткий промежуток;
• массовое редактирование страниц или добавление новых записей с вредоносным содержимым;
• появление чужих ссылок, редиректов или скрытых вставок (например, JavaScript-майнеров);
• следы работы через панель управления или API — даже если злоумышленник не заходил в админку напрямую, он мог использовать уязвимый REST API.

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

Какой порядок проверки лучше использовать

Чтобы не утонуть в массе событий, действуйте по шагам. Хаотичный просмотр логов обычно приводит к потере времени и упущенным деталям.

Шаг 1. Зафиксировать время инцидента

Сначала определите:

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

Если время на разных узлах не синхронизировано, расследование становится сильно сложнее: вы будете видеть событие в access.log на пять минут раньше, чем в auth.log, и не сможете уверенно связать их. Поэтому NTP — не роскошь, а обязательный элемент инфраструктуры.

Шаг 2. Сначала смотреть веб-уровень

Начинайте с access.log и error.log, потому что именно там чаще всего видна первая точка входа. Ищите аномалии вокруг предполагаемого времени инцидента: всплески ошибок, необычные запросы, обращения к редко используемым скриптам. Если сайт работает за reverse proxy, убедитесь, что access.log содержит реальные IP посетителей, а не адрес прокси.

Шаг 3. Затем сопоставить с приложением и авторизацией

После этого переходите к application logs и auth logs, чтобы понять, был ли успешный вход и какие действия совершались внутри системы. Здесь важно найти идентификатор сессии или пользователя, который фигурировал в подозрительных запросах, и отследить всю его активность.

Шаг 4. Проверить базу данных и ОС

Если есть признаки утечки или модификации, смотрите database logs и system logs. Это помогает увидеть, не вышел ли атакующий за рамки веб-приложения: например, выполнил ли команды через SQL-инъекцию или запустил обратный shell. Системные логи могут показать появление новых процессов, изменение конфигураций или попытки повышения привилегий.

Шаг 5. Сверить с защитными системами

WAF, IDS/IPS, reverse proxy и firewall часто помогают понять, что именно блокировалось, а что прошло мимо защиты. Сравните временные метки: если WAF зафиксировал атаку, но не заблокировал её (например, был в режиме обучения), а в access.log виден успешный запрос, значит, уязвимость была проэксплуатирована. Эта информация критична для последующего усиления защиты.

Типовые ошибки при сборе логов

Самые частые проблемы в реальных расследованиях такие:

• логи не включены заранее — когда инцидент уже произошёл, включать логирование поздно;
• хранится только access.log без error.log и application logs — это даёт лишь треть картины;
• журналы перезаписываются слишком быстро — например, ротация настроена на сутки, а инцидент обнаружили через неделю;
• время на серверах не синхронизировано — события из разных источников невозможно выстроить в единую цепочку;
• логи лежат на том же сервере, который могли скомпрометировать — злоумышленник может их подчистить или удалить;
• в журналах нет ID пользователя, сессии или запроса — нельзя понять, кто именно выполнил действие;
• нечем сопоставить события между несколькими сервисами — нет общего идентификатора транзакции или запроса.

Что это ломает на практике

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

Как организовать хранение логов правильно

Для расследования важны не только сами журналы, но и условия их хранения. Если логи можно бесследно удалить или изменить, их ценность стремится к нулю.

Базовые правила

• хранить логи централизованно, а не только на одном сервере — отдельный log-сервер или облачное хранилище с ограниченным доступом;
• ограничить доступ к журналам — только уполномоченные сотрудники, желательно с двухфакторной аутентификацией;
• включить резервное копирование — чтобы даже при компрометации основного хранилища осталась копия;
• сохранять историю достаточно долго для ретроспективного анализа — минимальный срок зависит от специфики, но для многих проектов разумно хранить логи не менее 30–90 дней, а критичные события — до года;
• защищать логи от подмены и удаления — использовать append-only файловые системы или WORM-хранилища;
• использовать единый формат и нормальную синхронизацию времени — все системы должны писать логи в UTC или с явным указанием пояса.

Практический минимум для сайта

• web-сервер и приложение отправляют логи на отдельный сервер (можно через syslog или агенты);
• система синхронизирует время через NTP с надёжными источниками;
• критичные события дублируются в защищённое хранилище — например, в облачный бакет с политикой неизменяемости;
• для расследования сохраняются не только ошибки, но и успешные действия — иначе вы не увидите, что атакующий сделал после входа;
• логи не удаляются автоматически раньше, чем это позволяет политика безопасности — ротация должна быть настроена с запасом по времени.

Отдельно отмечу: для сайтов, обрабатывающих персональные данные, требования к логированию событий безопасности закреплены в приказах ФСТЭК и нормативных актах к 152-ФЗ. Там чётко сказано, что нужно фиксировать попытки доступа, изменения прав и другие события. Игнорирование этих требований может привести не только к проблемам при расследовании, но и к административной ответственности.

На что смотреть в журналах в первую очередь

Вот короткий чек-лист для первичного анализа. Если вы видите хотя бы один из этих признаков, стоит копнуть глубже:

• всплеск 404, 403 или 500 с одного IP — часто признак сканирования или фаззинга;
• массовые одинаковые запросы — автоматизированная атака;
• необычные user agent — скрипты, старые версии браузеров, отсутствие UA;
• попытки обхода фильтров и кодирования параметров: двойное URL-кодирование, Unicode-эквиваленты;
• входы в нерабочее время — особенно если учётная запись обычно активна днём;
• новые администраторы или смена ролей — часто цель злоумышленника после получения доступа;
• необычные выгрузки данных: экспорт в CSV, обращение к API отчётов;
• изменения файлов сайта — особенно в директориях тем, плагинов, загрузок;
• ошибки после подозрительного запроса — например, синтаксическая ошибка SQL сразу после GET-параметра с кавычкой;
• перезапуски сервисов без понятной причины — могут маскировать закрепление в системе.

Что должно быть у команды до инцидента

Хорошее расследование начинается не после взлома, а заранее. Когда инцидент уже произошёл, настраивать логирование поздно. Полезно заранее настроить:

• логирование на уровне веб-сервера, приложения, базы и ОС — с детализацией, достаточной для расследования;
• централизованный сбор журналов — хотя бы на отдельный сервер или в SIEM-систему, если позволяет бюджет;
• единый формат времени — UTC на всех узлах;
• алерты на подозрительные паттерны — хотя бы на резкий рост ошибок или множественные неудачные входы;
• хранение критичных логов вне основного боевого сервера — чтобы злоумышленник не мог их уничтожить;
• регулярную проверку, что логи действительно пишутся — не реже раза в месяц убеждаться, что диски не переполнены, агенты работают, а в журналах появляются свежие записи.

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

Короткий вывод

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

FAQ

Какие логи самые важные в первую очередь?

В первую очередь — access.log, error.log, application logs и auth logs. Они быстрее всего показывают точку входа и успех атаки. Без них вы даже не поймёте, был ли инцидент вообще.

Достаточно ли одного access.log?

Нет. Он показывает запросы, но не объясняет, что произошло внутри приложения, базы данных и системы. Вы увидите, что кто-то обратился к /admin, но не узнаете, вошёл ли он, что изменил и какие данные скачал.

Нужно ли хранить логи долго?

Да, иначе ретроспективное расследование будет невозможным. Срок хранения зависит от политики компании и требований к безопасности, но удалять журналы слишком рано — плохая практика. Для многих проектов минимальный разумный срок — 30 дней, но лучше ориентироваться на 90 дней и более, особенно если сайт обрабатывает чувствительные данные.

Что делать, если логи уже удалены?

Тогда придётся восстанавливать картину по остаточным данным: резервным копиям, WAF, DNS, прокси, базе данных и внешним системам мониторинга. Но полнота расследования будет ниже, а доказательная сила таких материалов — слабее. Именно поэтому так важно настроить хранение логов заранее.

Можно ли расследовать инцидент без централизованного логирования?

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