Анализ алерта SIEM по брутфорсу SSH: почему интервалы между попытками важнее счётчика

На типичном Linux-сервере с открытым портом 22 за сутки набегает от нескольких сотен до нескольких тысяч неудачных попыток входа по SSH. Стандартное правило в SIEM (Security Information and Event Management — система, которая собирает логи со всей инфраструктуры и генерирует алерты по заданным правилам) звучит просто: «больше 5 неудачных попыток за 60 секунд». На практике это превращает поток в десятки алертов ежедневно. В SOC (Security Operations Center — центр мониторинга, где аналитики L1/L2 разбирают входящие алерты) подавляющее большинство из них — фоновый шум от интернет-сканеров. Я начинал с того же правила и закрывал по 30 одинаковых тикетов за смену. Пока не понял: отличить шум от настоящей атаки по количеству попыток невозможно, зато по паттерну интервалов между ними — почти всегда.

Ниже — разбор триажа алерта по брутфорсу SSH на учебном стенде: от генерации атаки до команд, которые извлекают дельты из auth.log, и до корреляционного правила Splunk, которое режет поток ложных срабатываний SIEM.

Зачем атакующий перебирает пароли SSH

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

В терминах MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1110 — её идентификаторы) цепочка выглядит так: сначала Brute Force (T1110, тактика Credential Access — получение учётных данных), затем, если пароль подобран, — Valid Accounts (T1078, тактики Initial Access, Persistence, Privilege Escalation и Defense Evasion), а после — SSH (T1021.004, тактика Lateral Movement — перемещение к другим хостам по сети).

Отдельная подтехника — Credential Stuffing (T1110.004): атакующий берёт готовые пары логин:пароль из утёкших баз. Масштаб утечек делает это рабочей угрозой: утечка колумбийской финтех-компании Addi в марте 2026 года — 34,5 миллиона записей с email, государственными ID, данными о кредитном рейтинге и устройствах. Утечка российского видеосервиса START (2022) — 7,4 миллиона записей, включая пароли. Credential stuffing работает, потому что люди переиспользуют пароли на разных сервисах. Банальная привычка, но она кормит целую индустрию.

Понимание мотивации помогает при триаже: если атакующий подобрал пароль, ущерб уже нанесён. Скорость реакции SOC тут критична.

Почему стандартный порог обнаружения брутфорса SSH создаёт ложные срабатывания SIEM

Стандартное правило обнаружения — threshold-based (пороговое): N неудачных попыток аутентификации с одного IP за M секунд. В Splunk чаще всего это «5 событий Failed password за 60 секунд — алерт». Исследование Jeju National University по обнаружению SSH brute-force атак на сетевых устройствах подтверждает: большинство логов несанкционированного доступа к роутерам вызваны именно SSH-брутфорсом, и для фильтрации авторы предлагают модели со взвешиванием записей, а не простой порог.

Проблема порога — он одинаково срабатывает на три совершенно разные ситуации:

Интернет-сканеры (Shodan, Censys, ZMap) обходят диапазоны IP и пробуют 1-2 стандартных логина. Генерируют 5-10 попыток и уходят. Угрозы для конкретного сервера нет, но алерт срабатывает.

Автоматизированная атака инструментами вроде Hydra или Medusa — последовательный перебор словаря с десятками попыток в секунду. Это реальная атака, но стандартное правило не отличает её от сканера.

Ботнет-атака — каждый бот делает 1-2 попытки, суммарно получается массовый перебор, но с каждого отдельного IP — ниже порога. Стандартное правило вообще не сработает.

Для SOC-аналитика это тупик: threshold-правило либо шумит (первый и второй случаи), либо молчит, когда не должно (третий). Ни то ни другое не годится для надёжного расследования инцидента брутфорс.

Три паттерна интервалов между попытками подключения SSH

Каждый источник брутфорса оставляет характерный «отпечаток» во временных метках событий безопасности. Файл auth.log (журнал аутентификации Linux, куда sshd записывает каждую попытку входа — успешную и неудачную) хранит эти метки с точностью до секунды. При триаже алертов SOC первое, что стоит проверить, — не «сколько попыток», а «с какой регулярностью они шли».

Сигнатура автоматизированной атаки SSH: фиксированные интервалы

Hydra (многопоточный брутфорсер, запускает несколько параллельных SSH-сессий одновременно) генерирует характерный паттерн: дельты (промежутки) между попытками почти идентичны. В auth.log это выглядит так:

Mar 15 14:22:01 srv sshd[4821]: Failed password for root from 10.0.0.5
Mar 15 14:22:01 srv sshd[4823]: Failed password for root from 10.0.0.5
Mar 15 14:22:02 srv sshd[4825]: Failed password for root from 10.0.0.5
Mar 15 14:22:02 srv sshd[4827]: Failed password for root from 10.0.0.5

Дельты: 0, 0, 1, 0 секунд. Стандартное отклонение (мера разброса значений — чем ближе к нулю, тем однороднее ряд) этого ряда — доли секунды. Человек физически не способен вводить пароли с такой скоростью и регулярностью. Это машина, и auth.log это показывает.

CrowdSec — open-source система поведенческого обнаружения — использует именно этот принцип в сценарии ssh-time-based-bf. Его функция MedianInterval() вычисляет медиану интервалов и срабатывает, когда она стабильно низкая. Почему медиана, а не среднее? Медиана устойчивее к выбросам. Если среди 50 дельт по 0,5 секунды попадётся одна задержка в 10 секунд (ретрансмит TCP), среднее «поплывёт», а медиана — нет.

Паттерн атаки SSH через ботнет: хаотичные дельты с разных IP

Ботнет-атака выглядит принципиально иначе. Каждый бот отправляет 1-3 попытки — дельты между попытками с одного IP большие и нерегулярные. Но если агрегировать попытки по целевому серверу (не по source IP), виден нарастающий поток: дельты хаотичны, однако средняя держится в диапазоне 2-15 секунд.

Ключевые признаки: много разных source IP (десятки и сотни), одинаковые или типовые логины (root, admin, ubuntu, test), высокий разброс интервалов. Правило «5 попыток с одного IP» тут бессильно — каждый бот ниже порога. Зато правило на интервалы по destination сработает.

Ручной подбор: нерегулярные паузы

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

Стандартное отклонение дельт у живого человека — высокое (больше 5 секунд). У автоматизированного инструмента — меньше 1 секунды. Эта разница — ядро поведенческого анализа в SOC при работе с алертами по SSH.

Триаж алерта SOC на учебном стенде: делай раз, делай два, делай три

Теория без практики — пустой звук. Ниже — пошаговый анализ алерта SIEM по брутфорсу SSH на лабораторном стенде.

Генерируем атаку и собираем анализ логов auth.log

Две виртуальные машины в одной сети. Атакующая — Kali Linux (или любая машина с установленным Hydra). Целевая — Ubuntu/Debian с запущенным sshd. На целевой нужен root-доступ для чтения auth.log.

Шаг 1. На атакующей машине запускаем Hydra с минимальным словарём:

hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://192.168.1.100 -t 4 -V

Флаг -t 4 задаёт 4 параллельных потока, -V выводит каждую попытку в реальном времени. В терминале побегут строки вида [22][ssh] host: 192.168.1.100 login: root password: <пароль>.

Шаг 2. На целевой машине смотрим логи в реальном времени:

sudo tail -f /var/log/auth.log | grep "Failed password"

Если auth.log отсутствует (Ubuntu 22.04+/Debian 12 с journald без rsyslog), используйте journalctl -u ssh -f | grep "Failed password". Каждая неудачная попытка создаст строку Failed password for root from 192.168.1.50 port XXXXX ssh2. Если строки не появляются — проверяем, что sshd запущен (systemctl status sshd) и firewall не блокирует порт 22.

Дождитесь 30-50 попыток и остановите Hydra через Ctrl+C. Этого хватит для анализа паттерна.

Извлекаем дельты между временными метками событий безопасности

Нужно получить числовой ряд интервалов между попытками, чтобы статистически определить тип атаки — автоматизированная vs ручной подбор.

Шаг 3. Выгружаем временные метки неудачных попыток с IP атакующего и считаем дельты. Цепочка grep + awk + while делает это одной командой (формат rsyslog Mon DD HH:MM:SS; для journald или RFC5424 адаптируйте awk-паттерн):

grep "Failed password.*192.168.1.50" /var/log/auth.log \
  | awk '{print $1, $2, $3}' \
  | while read line; do
      ts=$(date -d "$line" +%s 2>/dev/null)
      [ -n "$prev" ] && echo "$((ts - prev))"
      prev=$ts
    done

Что тут происходит: grep фильтрует строки с неудачными попытками от нужного IP. awk '{print $1, $2, $3}' вытаскивает месяц, день, время. Цикл while конвертирует каждую метку в Unix-timestamp (секунды с 1 января 1970) через date -d и вычитает предыдущую. На выходе — столбец чисел: дельты в секундах.

Для Hydra с 4 потоками ожидайте столбец из 0, 0, 1, 0, 0, 1, 0 — стабильный цикл с минимальным разбросом. Если вывод пустой — проверьте, что IP в grep совпадает с реальным адресом атакующей машины (посмотрите через ip a на Kali).

Интерпретируем паттерн атаки SSH

Шаг 4. Считаем среднее и стандартное отклонение дельт. Перенаправляем вывод предыдущей команды в файл (добавляем > deltas.txt в конце пайплайна), затем:

awk '{s+=$1; ss+=$1*$1; n++} END {m=s/n; print "mean:", m, "sd:", sqrt(ss/n-m*m)}' deltas.txt

Критерии триажа — эмпирические пороги из лабораторной практики:

Среднее меньше 2 и SD меньше 1 — с высокой вероятностью автоматизированный инструмент. Алерт требует реакции: блокировка IP, проверка на наличие успешной аутентификации после серии неудач.

Много source IP при низком среднем по destination — ботнет. Блокировка одного IP бесполезна, нужна агрегация на уровне fail2ban (утилита, которая автоматически блокирует IP после заданного числа неудачных попыток) или IPS.

Корреляция событий SIEM SSH на основе поведенческого анализа

Ручной timing-анализ работает, но не масштабируется. При 40-50 алертах в день аналитик SOC не будет запускать grep + awk на каждый. Нужно корреляционное правило, которое фильтрует шум автоматически.

Правило Splunk: стандартное отклонение как фильтр false positive

В Splunk SPL (Search Processing Language — язык запросов Splunk) логика строится так: собираем все Failed password по SSH, группируем по source IP, вычисляем дельты между событиями и считаем стандартное отклонение. Если SD низкое, а попыток больше порога — алерт с высоким приоритетом.

index=auth sourcetype=syslog "Failed password"
| sort _time
| autoregress _time as prev_time
| eval delta=_time-prev_time
| stats count stdev(delta) as sd avg(delta) as avg_d by src_ip
| where count>10 AND sd<1

Построчно: autoregress подставляет _time из предыдущего события в поле prev_time — так мы получаем пару «текущее время / предыдущее время» для каждого события. eval delta считает разницу. stats группирует по IP и вычисляет стандартное отклонение и среднее. where оставляет только IP с более чем 10 попытками и SD меньше 1 секунды — фильтр на автоматизацию. Порог count>10 заодно отсекает edge-case, при котором stdev() вернёт null или 0 для 1-2 событий, поэтому дополнительная проверка на размер выборки не нужна.

В ELK (Elasticsearch + Logstash + Kibana — альтернативный SIEM-стек) аналогичная логика реализуется через Painless-скрипт в Watcher или через transform с window-функцией. Принцип тот же: агрегация дельт и порог на SD.

Это правило не заменяет стандартное threshold-правило — оно работает параллельно, повышая приоритет алертов с автоматизированным паттерном. Алерты, не прошедшие фильтр SD, остаются в очереди с низким приоритетом — аналитик дойдёт до них, если останется время.

Маппинг на MITRE ATT&CK: от разведки до закрепления

Когда алерт прошёл триаж и подтверждён как реальная атака, его стоит задокументировать в терминах MITRE ATT&CK для отчёта об инциденте:

• Reconnaissance — Wordlist Scanning (T1595.003): атакующий подготовил или скачал словарь паролей. Этот этап невидим в SSH-логах — он происходит до атаки.
• Credential Access — Brute Force (T1110): собственно перебор. Подтехника зависит от паттерна: один логин и много паролей — Password Guessing (T1110.001), много логинов и один пароль — Password Spraying (T1110.003), пары из утечки — Credential Stuffing (T1110.004).
• Initial Access / Persistence — Valid Accounts (T1078): если пароль подобран, атакующий получает легитимный аккаунт. В auth.log это Accepted password после серии Failed password — критическая проверка при расследовании.
• Lateral Movement — SSH (T1021.004): скомпрометированный сервер используется как плацдарм для атаки на соседние хосты.

Этот маппинг — не формальность для галочки. Он нужен для корреляции с другими алертами: если SIEM зафиксировал Brute Force (T1110), а через час с того же сервера пошли SSH-подключения к внутренним хостам (T1021.004) — это уже не брутфорс, а активная компрометация.

Чек-лист расследования инцидента брутфорс

Когда timing-анализ подтвердил, что алерт — реальная атака, порядок действий:

1. Проверить успешный вход. Команда grep "Accepted" /var/log/auth.log | grep "192.168.1.50" покажет, подобрал ли атакующий пароль. Строка Accepted password после серии Failed — инцидент перешёл из «попытки» в «компрометацию», эскалация немедленно.

2. Проверить IP по внешним базам. AbuseIPDB (публичная база репортов о вредоносных IP; бесплатный тир — 1000 запросов в день через API, эндпоинт /api/v2/check?ipAddress=X) выделяет SSH-брутфорс в отдельную категорию #22 (категория #18 Brute-Force явно исключает SSH и FTP). Confidence Score выше 75 из 100 — рекомендуемый порог для блокировки. Перед блокировкой проверьте, не является ли IP выходным узлом Tor (список на torproject.org/exit-addresses) — блокировка Tor-выходов может затронуть легитимных пользователей.

3. Зафиксировать IOC (Indicators of Compromise — индикаторы компрометации). Source IP, временной диапазон атаки, используемые логины, паттерн интервалов, значения среднего и SD дельт. Всё это идёт в отчёт об анализе инцидента SOC.

4. Заблокировать источник. Через fail2ban, iptables или правило на сетевом firewall. Для ботнет-атаки — рассмотреть блокировку на уровне ASN (Autonomous System Number — идентификатор сети провайдера: если десятки атакующих IP принадлежат одному AS, блокировка всего AS может быть оправдана).

5. Обновить корреляционное правило. Если стандартное правило сработало на шум, а timing-правило его отфильтровало — результат подтверждён. Если наоборот — скорректировать пороги SD.

Эта последовательность укладывается в цикл NIST CSF 2.0: Detect (DE.AE-01 — анализ аномальных событий на основе базового уровня) → Respond (RS.AN-01 — расследование уведомлений от систем обнаружения) → Recover. OWASP выделяет проблему недостаточного логирования и мониторинга в категорию A09:2021 (Security Logging and Monitoring Failures) — если auth.log не собирается в SIEM или не настроены алерты, обнаружение брутфорса невозможно в принципе.

Большинство SOC-команд годами живут с пороговыми правилами на SSH-брутфорс и тратят основное время аналитика L1 на закрытие алертов, которые можно было отфильтровать одной функцией stdev(). Проблема не в инструментах — Splunk, ELK, Wazuh считают дельты и стандартное отклонение из коробки. Проблема в том, что первое правило, которое пишет начинающий аналитик — count > 5 за 60 секунд — становится «рабочим», и никто его не трогает, потому что «срабатывает». Срабатывает — да. На всё подряд.

Timing-анализ — не ML-модель за полмиллиона и не исследовательский проект. Это одно дополнительное условие в существующем правиле. Но оно требует понимания: ты ищешь не факт попытки, а поведение за попыткой. Автоматизированная атака vs ручной подбор — разные сущности, требующие разной реакции. Threshold-правило их не различает; timing-правило — различает.

Переход от сигнатуры к поведенческому анализу в SOC меняет качество работы радикально: вместо десятков одинаковых алертов аналитик видит три-четыре, но каждый из них — подтверждённая угроза. Если только начинаешь и хочешь пройти базу системно, от триажа алерта до написания правила — на IB Basics как раз показывают первые задачи SOC-аналитика без академического тона.