Понедельник, утро. SOC фиксирует алерт: сервер Ubuntu 22.04 в DMZ инициирует исходящие соединения на IP из TI-фида, связанного с C2-инфраструктурой. За 48 часов с хоста ушло 2.3 ГБ трафика наружу. На сервере API с персональными данными клиентов - при утечке ПДн оборотный штраф по 152-ФЗ может составить до 3% годовой выручки. Менеджмент уже набирает номер юристов, а у вас 40 минут до первого вопроса: "Что утекло?". Эти 40 минут определят, сохранятся ли доказательства или будут уничтожены неосторожным
reboot. Дальше - про то, как не потерять улики и собрать из хаоса единый таймлайн.Порядок волатильности при сборе артефактов Linux
Каждый раз, когда я прихожу на "грязный" хост в продакшне, первое решение - не "какую команду запустить", а "в каком порядке собирать данные". Принцип порядка волатильности (order of volatility) из RFC 3227 простой: сначала - то, что исчезнет при потере питания, потом - то, что переживёт перезагрузку. Подробнее - в нашем материале про расследование кибератаки.Для DFIR Linux приоритет выглядит так:
- Оперативная память - запущенные процессы, расшифрованные ключи, сетевые соединения, fileless-малварь, которая никогда не касалась диска.
- Состояние процессов и сетевого стека - дерево процессов (
/proc), открытые порты, установленные TCP-сессии, ARP-таблица. - Временные данные файловой системы - содержимое
/tmp,/dev/shm, удалённые файлы с ещё работающими процессами. - Логи и конфигурации -
/var/log/, crontab, systemd-юниты,.bash_history. - Образ диска - побитовая копия через
dc3ddилиdd.
Первые минуты: процессы, сеть, дамп памяти
Требования к окружению
Перед началом сбора артефактов GNU/Linux подготовьте:- Внешний носитель или сетевую шару для записи результатов - не пишите артефакты на скомпрометированный хост
- Доступ root (SSH или физическая консоль)
- Предсобранный набор статически скомпилированных бинарей (
ps,ss,lsof,find) - если есть подозрение, что атакующий подменил системные утилиты - RAM рабочей станции аналитика: минимум 8 ГБ, для обработки дампов памяти Volatility 3 - рекомендуется 16 ГБ
- Скомпилированный модуль LiME под текущую версию ядра целевого хоста (
uname -r)
Процессы и сетевой стек
Первое касание к хосту - фиксация текущего состояния. Командаps auxwf (именно с флагами wf - для полного дерева процессов с широким выводом) покажет, какой процесс порождён каким. Если видите, что apache2 или nginx порождает /bin/sh, а тот запускает curl на внешний IP - вот вам и pivot point для расследования инцидента Linux. Атакующие используют Process Discovery (T1057, Discovery) для разведки на хосте, но эту же технику мы разворачиваем против них.Параллельно снимайте сетевой стек:
ss -tupln покажет TCP/UDP-соединения с привязкой к PID процессов. Для incident response GNU/Linux критично зафиксировать ESTABLISHED-соединения до того, как кто-нибудь начнёт "изолировать" хост и разорвёт все сессии. Можно и netstat -plunto, но ss не требует установки пакета net-tools - одной зависимостью меньше.Следующий шаг -
lsof -V для полного списка открытых файлов. Комбинация lsof -i -u root покажет, какие сетевые сокеты использует root. Ключевой трюк: если атакующий удалил бинарь, но процесс ещё работает, через lsof вы найдёте ссылку на удалённый файл в /proc/[PID]/exe. Командой cp /proc/[PID]/exe /mnt/evidence/recovered_binary вытаскиваете сам бинарь из памяти - он ещё жив, пока жив процесс. Этот приём спасал расследование не раз.Зафиксируйте ARP-таблицу (
ip neigh), маршруты (ip route show) и конфигурацию сетевых интерфейсов (ip addr). Если атакующий прокинул reverse tunnel или добавил маршрут для lateral movement - здесь это будет видно.Дамп оперативной памяти
Стандартный инструмент для memory forensics Linux - LiME (Linux Memory Extractor). Загружаемый модуль ядра, который снимает полный дамп RAM без остановки системы. Дамп пишется на внешний носитель (USB или NFS-шара, не локальный диск хоста - запись на скомпрометированную ФС перезапишет unallocated space с артефактами):
Bash:
insmod lime-$(uname -r).ko "path=/mnt/evidence/mem.lime format=lime"insmod lime.ko "path=tcp:4444 format=lime", а на рабочей станции аналитика приём через nc -l -p 4444 > mem.lime. Формат lime нативно поддерживается Volatility 3 - извлечение списка процессов, сетевых соединений, загруженных модулей, поиск инъецированного кода.Сразу после снятия - хеширование:
sha256sum /mnt/evidence/mem.lime > /mnt/evidence/mem.lime.sha256. Без хеша дамп теряет доказательную силу - chain of custody нарушена.Частая боль: модуль LiME должен быть скомпилирован именно под текущий
uname -r. Ядро обновилось вчера, а модуль собирался под предыдущую версию - он не загрузится. В зрелых SOC-процессах модули LiME пересобираются автоматически при каждом обновлении ядра. Если модуля нет - есть AVML от Microsoft (microsoft/avml), который не требует сборки kernel-модуля и работает через /proc/kcore или /dev/crash. На современных ядрах (с CONFIG_STRICT_DEVMEM и KASLR) вариант с /proc/kcore напрямую малопригоден для полного дампа user-space - AVML решает это автоматически.Артефакты на диске: логи, persistence, следы антифорензики
Volatile-данные зафиксированы - переходим к диску. Здесь ничего не пропадёт от перезагрузки, но атакующий мог целенаправленно зачищать следы. И вот что интересно: сами эти зачистки становятся IOC.Логи аутентификации и systemd journal
Первый источник для анализа инцидента Linux - логи аутентификации. На Debian-подобных это/var/log/auth.log, на RHEL/CentOS - /var/log/secure. Разница фундаментальна: скопируете не тот файл - потеряете данные.
Bash:
# Неудачные SSH-попытки с группировкой по IP-источнику
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20
# Успешные входы в нетипичное время (00:00–05:59)
grep "Accepted" /var/log/auth.log | awk '$3 ~ /^0[0-5]:/'
# Sudo-инциденты: попытки выполнения неразрешённых команд
grep "NOT in sudoers" /var/log/auth.log/var/log/auth.log подозрительно короткий или имеет разрыв во временных метках - это само по себе IOC. Проверка через stat /var/log/auth.log: если Modify свежее, чем ожидаемое, файл мог быть перезаписан.Второй источник -
journalctl. Бинарный формат journal-логов в /var/log/journal/ значительно сложнее подчистить, чем текстовые файлы, и атакующие часто про них забывают. Команда journalctl --since "2025-06-28" --until "2025-06-30" -o json выгрузит события за нужный период в машиночитаемом формате. Нюанс: если journal настроен как volatile, данные живут в /run/log/journal/ и исчезнут при reboot. Для forensic-целей лучше работать с offline-копией: journalctl -D /mnt/evidence/var/log/journal/. При построении таймлайна инцидента journal-данные часто оказываются единственным источником, пережившим зачистку.Дополнительно:
/var/log/btmp (неудачные логоны - читается через lastb, удобно для выявления брутфорса), /var/log/wtmp (все входы и выходы - last -Faiwx), /var/log/lastlog (время последнего входа каждого пользователя).Persistence через cron и systemd-юниты
Два основных механизма persistence, которые я встречаю в подавляющем большинстве расследований на Linux:Cron (T1053.003, Persistence/Privilege Escalation). Проверяйте не только пользовательские
crontab -l -u <user>, но и системные каталоги: /etc/crontab, /etc/cron.d/, /etc/cron.daily/, /var/spool/cron/crontabs/. В одном кейсе атакующий создал файл /etc/cron.d/apt-compat-check - имя мимикрирует под стандартное обслуживание пакетов, а содержимое запускало reverse shell каждые 15 минут. Если у вас нет baseline конфигурации хоста - любой файл в /etc/cron.d/ с датой модификации позже последнего планового изменения требует внимания.Systemd Service (T1543.002, Persistence/Privilege Escalation). Атакующие создают собственные unit-файлы или модифицируют существующие. Ключевые пути:
/etc/systemd/system/- пользовательские юниты, приоритет выше стандартных из/lib/systemd/system//run/systemd/system/- runtime-юниты, не переживут reboot, но активны сейчасsystemctl list-unit-files --state=enabled- всё, что настроено на автозапуск
ExecStart: если сервис запускает bash -c "curl ... | sh" или ncat -e /bin/bash - это однозначно backdoor. Менее очевидный вариант - юнит с легитимным именем (syslog-ng-helper.service), но с ExecStartPre, который перед запуском основного сервиса выполняет скрипт из /tmp. Вот такие "помощники" встречаются чаще, чем хотелось бы.Антифорензика: три проверки на каждом триаже
Clear Command History (T1070.003). Ищите.bash_history для всех пользователей: find /home /root -name ".bash_history" -exec echo "=== {} ===" \; -exec wc -l {} \;. Если у активного пользователя файл пуст или содержит 3 строки - историю зачистили. Проверяйте .bashrc и .profile на HISTSIZE=0 или HISTFILE=/dev/null - атакующие ставят эти переменные, чтобы новые команды не записывались.Timestomp (T1070.006, Defense Evasion). Атакующие модифицируют временные метки через
touch -t, чтобы свежий файл выглядел старым. Команда stat показывает Access, Modify и Change time. На ext4 есть ещё Birth (crtime) - она не меняется через touch. Ключевой признак timestomping: Modify файла старше, чем Change. Содержимое «якобы» не менялось, но метаданные inode обновились - нормально такого не бывает.Credential Access (T1003.008). Проверяйте доступ к
/etc/shadow через ausearch -f /etc/shadow (если auditd настроен) или через access time файла. Ищите копии: find / -name "[I].shadow[/I]" -o -name "shadow.bak" -o -name "passwd.bak" 2>/dev/null.Автоматизация триажа скомпрометированного хоста с UAC
Ручной сбор артефактов работает на одном хосте. Когда алерт затрагивает пять серверов - нужна автоматизация. UAC (Unix-like Artifact Collector) - open source набор shell-скриптов с yaml-конфигурациями для статического сбора форензик-артефактов с *nix-систем. Зависимостей на целевой системе не требует - распаковал и запустил.Три стандартных профиля покрывают основные сценарии:
| Профиль | Что собирает | Когда применять |
|---|---|---|
full | Все артефакты: volatile + static, 473+ коллекторов на GNU\Linux | Полное расследование одного хоста |
ir_triage | Volatile-данные + ключевые файлы без приложений | Быстрый триаж при ограниченном времени |
offline | Только статические файлы, без volatile | Работа с образом или выключенной машиной |
Развёртывание - три команды:
Bash:
curl -L https://github.com/tclahr/uac/releases/download/v3.3.0/uac-3.3.0.tar.gz -o uac.tar.gz
tar -zxvf uac.tar.gz && cd uac-3.3.0
sudo ./uac -p ir_triage /mnt/evidence/.tar.gz, который можно отправить на SFTP, S3 или Azure через параметры командной строки. На выходе - набор текстовых файлов с output каждого коллектора: списки процессов, сетевые соединения, bodyfile файловой системы (для построения таймлайна), хеши исполняемых файлов, конфигурации сервисов, логи.Нюанс, который стоит держать в голове: по умолчанию UAC использует бинарники целевой системы. Если атакующий подменил
ps или ss - вывод будет скомпрометирован. Для серьёзных расследований готовьте статически скомпилированные бинарники и размещайте их в каталоге bin/ внутри архива UAC. Задача нетривиальная, но для production IR toolkit - без вариантов.Когда нужен сбор с десятков хостов - смотрите в сторону Velociraptor или osquery. Velociraptor позволяет удалённо запускать VQL-запросы на агентах и централизованно собирать артефакты, osquery превращает систему в SQL-базу для точечных запросов. Но для быстрого триажа на один-два хоста UAC - самый низкий порог входа.
Построение таймлайна инцидента с log2timeline
Собрать артефакты - половина дела. Вторая - выстроить из разрозненных источников единый таймлайн. Для этого есть
log2timeline (часть фреймворка Plaso). Он парсит десятки форматов - syslog, wtmp, журналы Apache/nginx, bash_history, bodyfile файловой системы, journald - и сводит всё в одну хронологическую ленту.Рабочий процесс из трёх шагов. Первый - создание Plaso-хранилища:
log2timeline.py --storage-file timeline.plaso /mnt/evidence/. Второй - фильтрация по временному окну инцидента и экспорт в CSV: psort.py -o l2tcsv -w timeline.csv timeline.plaso "date > '2025-06-28' AND date < '2025-06-30'". Третий - анализ CSV через Timeline Explorer, Timesketch или даже grep по ключевым артефактам.В готовом таймлайне вы увидите цепочку: в 02:47 атакующий авторизовался по SSH (auth.log), в 02:48 скачал бинарь через
curl (bash_history), в 02:49 создал systemd-юнит (новый файл в /etc/systemd/system/, зафиксированный в bodyfile), в 02:51 зачистил auth.log (изменение mtime файла). Без единого таймлайна каждый артефакт - изолированный фрагмент. С ним - полная цепочка атаки для postmortem-отчёта и регулятора.Detection-чеклист для триажа скомпрометированного хоста
Структурированный список проверок для первых 30 минут реагирования на инциденты GNU/Linux. Каждый пункт привязан к конкретной технике MITRE ATT&CK и конкретной команде.Этот чеклист - не замена полноценному расследованию, а структура для первых 30 минут. Тех самых минут, когда каждое действие должно быть осмысленным, а не хаотичным.
В большинстве расследований, которые я вёл, auditd на серверах не был настроен. Ни одного правила. Это значит, что единственные следы атакующего - то, что он сам оставил по неосторожности: незачищенный bash_history, забытый cron-файл, процесс, который не успели завершить. Без auditd половина чеклиста выше превращается в угадывание: вы не видите execve-вызовы, не знаете, кто и когда читал
/etc/shadow, не можете доказать, что конкретный пользователь запустил конкретный бинарь.Проблема не техническая - настроить auditd на базовый набор правил (exec, file access на критичных путях, изменение пользователей) занимает час. Проблема организационная: команды воспринимают forensic readiness как абстракцию, пока в 3 ночи не прилетает алерт и не оказывается, что доказательной базы нет. Пока retention логов 7 дней, пока нет предсобранных модулей LiME, пока bodyfile не генерируется регулярно для сравнения с baseline - каждый триаж начинается с дыр в данных, а не с ответов.
Проверьте свой сервер прямо сейчас:
auditctl -l. Если в ответ пришло No rules - у вас та же проблема. Если хотите отработать весь описанный workflow от подготовки инфраструктуры до полного расследования с разбором реальных кейсов - курс "Цифровая криминалистика и реагирование на инциденты (DFIR)" на Codeby Academy (Codeby Academy — Академия Кодебай это сильнейшая команда по информационной безопасности в России.) закрывает именно эту цепочку за 3.5 месяца с практическими лабораториями на базе инцидентов 2023–2024 годов.
Последнее редактирование модератором:
