Анализ и корреляция логов, SIEM

Этот урок учит превращать разрозненные логи в связную картину через корреляцию и поиск аномалий.

Корреляция логов — сопоставление событий из разных источников по времени и общим признакам, чтобы увидеть единую цепочку действий.

Один лог редко даёт всю картину. Вход по SSH виден в auth.log, запуск процесса — в журнале ОС, исходящее соединение — в логах firewall, скачивание — в логах прокси. По отдельности это шум; вместе, выстроенные по времени, — история атаки. Этим и занимается анализ логов.

Важно сразу зафиксировать рамку: легальный анализ логов в DFIR — это работа со своими или корпоративными системами, к которым у вас есть право доступа, либо с учебными и CTF-образами. Логи нередко содержат персональные данные (IP-адреса, имена учётных записей, в веб-логах — параметры запросов), поэтому их обработка в организации регулируется внутренними политиками и 152-ФЗ «О персональных данных». Перед тем как выгружать журналы на свою машину или в облако для анализа, убедитесь, что это разрешено политикой и что вы не нарушаете тайну переписки (138 УК) и неприкосновенность частной жизни (137 УК). Дисциплина законности — не формальность, а часть профессии: отчёт, основанный на данных, полученных с нарушением, теряет доказательную силу.

Базовые приёмы поиска

Часто всё начинается с обычного grep и подсчёта аномалий: всплеск неудачных входов, обращения к редкому домену, активность в нерабочее время. Идея проста: вы не читаете миллионы строк глазами, а превращаете поток событий в распределения и ищете в них выбросы. Десять неудачных входов с одного IP за минуту, единственное обращение к домену, которого нет ни у кого больше, всплеск трафика в 3 часа ночи — всё это «горбы» на фоне нормального шума.

# Топ IP по числу неудачных входов (брутфорс)
grep "Failed password" auth.log \
  | grep -oE "([0-9]{1,3}\.){3}[0-9]{1,3}" \
  | sort | uniq -c | sort -rn | head

# Аномальная активность ночью (02:00-04:00)
grep -E " 0[2-4]:" access.log | head

Связка sort | uniq -c | sort -rn — рабочая лошадка аналитика: она строит частотную таблицу и сортирует по убыванию. Этот же подход применим к user-agent'ам, кодам ответа HTTP, путям URL, обращениям к DNS. Научившись считать частоты и сравнивать «сегодня» с «обычным днём», вы получаете дешёвый и быстрый детектор аномалий ещё до всякого SIEM. Полезно держать под рукой и обратную операцию — поиск редкого: события, которые встречаются ровно один раз, часто оказываются самыми интересными (первое появление вредоносного домена, единичный успешный вход после серии неудачных).

Демонстрация корреляции на Python

# Сводим события из двух источников по времени
auth = [("02:10", "SSH login admin from 185.10.0.7")]
proc = [("02:12", "process /tmp/x started"),
        ("02:14", "outbound 185.10.0.7:443")]

timeline = sorted(auth + proc)
for t, ev in timeline:
    print(t, "|", ev)

Вывод:

02:10 | SSH login admin from 185.10.0.7
02:12 | process /tmp/x started
02:14 | outbound 185.10.0.7:443

Видно цепочку: вход с того же адреса, запуск файла из /tmp, исходящее соединение туда же — связная история, которой не было видно в отдельных логах. По сути корреляция — это слияние нескольких отсортированных по времени потоков в один таймлайн и поиск в нём осмысленных последовательностей. В реальном инциденте таких источников не два, а десятки (DNS, EDR, прокси, VPN, контроллер домена), но принцип тот же: общий ключ (IP, имя пользователя, хеш файла) плюс временное окно дают цепочку «как развивалась атака».

SIEM

В масштабе организации логи централизуют в SIEM (Security Information and Event Management) — системы вроде Splunk, Elastic (ELK), Wazuh. SIEM собирает события со всех систем, нормализует, индексирует и позволяет искать и коррелировать запросами, строить правила обнаружения и оповещения. Для DFIR это ускоряет поиск и даёт единую точку для построения таймлайна.

Правила, алерты и поиск

Практически работа с SIEM делится на два режима. Первый — проактивный: вы заранее описываете подозрительные паттерны правилами корреляции («пять неудачных входов, за которыми успешный, с одного IP» или «процесс PowerShell породил исходящее соединение на редкий домен»), и система сама поднимает алерт. Второй — реактивный, расследовательский: вы уже знаете, что инцидент был, и «раскручиваете» его запросами от известной точки (IP, учётка, время) во все стороны, постепенно достраивая картину. Хороший аналитик умеет оба: правила ловят типовое, а свободный поиск находит то, под что правил ещё нет.

SIEM ускоряет работу, но не думает за аналитика: он подсвечивает кандидатов, а решение «инцидент это или ложное срабатывание» принимает человек, глядя на контекст.

Как работает под капотом

Разные системы пишут события в разных форматах и часовых поясах. SIEM их нормализует (приводит поля к общей схеме, время — к UTC), после чего корреляция становится простыми запросами: «все события по IP X за окно», «вход, за которым в течение минуты запуск процесса». Без нормализации сопоставление вручную медленно и чревато ошибками во времени.

Под нормализацией скрывается парсинг сырых строк в структуру: из строки access.log выделяются поля src_ip, timestamp, url, status; из Windows-события — пользователь, хост, тип входа. Дальше время каждого события приводится к единой шкале (как правило, UTC), и именно поэтому критично, чтобы на источниках был синхронизирован NTP. Если часы одного сервера «уехали» на пять минут, его события встанут в таймлайн не туда, и причинно-следственная цепочка («сначала вход, потом запуск») может развалиться или, хуже, выстроиться ложно. Поэтому в расследовании всегда фиксируют и учитывают расхождения часов — это рутинная, но критичная проверка.

Источник A (UTC+3) ──┐
Источник B (UTC)   ──┼─► нормализация (поля + время в UTC) ─► единый индекс
Источник C (UTC-5) ──┘                                        │
                                                    запрос по ключу + окну
                                                             ▼
                                                     таймлайн инцидента

Частые ошибки

Смотреть один источник. Картина собирается только из нескольких.
Игнорировать часовые пояса. Рассинхрон ломает корреляцию.
Тонуть в объёме. Без фильтров и агрегации логи неподъёмны; считают аномалии.
Доверять, что логи полны. Их могли чистить или они могли не настроиться — проверяют пробелы.
Путать совпадение по времени с причинностью. Два события рядом во времени не обязательно связаны; связь подтверждают общим ключом и логикой.

Итоги

Корреляция сопоставляет события разных источников по времени в единую цепочку.
Базовые приёмы — grep, подсчёт и поиск аномалий; масштаб — через SIEM.
SIEM нормализует и индексирует логи, ускоряя корреляцию и построение таймлайна.
Синхронность часов и законность доступа к журналам — обязательные условия корректного анализа.