Порядок сбора волатильных данных Linux: почему dd и cp — не первый шаг при инциденте

На одном из ранних выездов на инцидент я убил 40 минут, копируя подозрительные файлы из /tmp через cp на внешний диск. Логика казалась железной: файлы могут удалить — надо спасать. Когда дошёл до захвата оперативной памяти через LiME, выяснилось: мои собственные операции копирования вытеснили из RAM страницы с расшифрованной конфигурацией C2-сервера и артефактами инъекции в процесс nginx. Малварь была fileless — на диске её не существовало в принципе. Расследование лишилось ключевых доказательств. Не потому что я не знал команд — а потому что запускал их не в том порядке. Дальше — про порядок сбора волатильных данных на Linux, который стоило выучить до этого инцидента.

RFC 3227 и order of volatility: что собирать первым при сборе доказательств Linux

RFC 3227 (Guidelines for Evidence Collection and Archiving) — документ IETF 2002 года, описывающий принципы сбора цифровых доказательств. Документу больше двадцати лет, но физика RAM не изменилась: при потере питания данные исчезают. Центральная идея — order of volatility (порядок волатильности): данные в системе различаются по скорости исчезновения, и собирать их нужно строго от самых эфемерных к самым стабильным.

Для форензики Linux live response иерархия выглядит так:

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

По данным CrowdStrike Global Threat Report 2025, 79% атак обходятся без традиционного malware — это так называемые hands-on-keyboard атаки, living off the land. Вредоносная активность существует только в памяти и сетевых соединениях. Без корректного порядка сбора энергозависимых данных при инциденте расследовать такие атаки попросту нечем.

Разница между dd и live forensics: что теряется при неправильном порядке

Вот корень ошибки, которую я допускал сам и регулярно вижу у других.

dd — утилита побитового копирования. Классика дисковой форензики: dd if=/dev/sda of=/mnt/evidence/disk.img bs=4M. Создаёт идеальный образ диска. Но dd не снимает оперативную память, не фиксирует процессы и не сохраняет сетевые соединения. Это инструмент для шестого шага, не для первого.

cp — копирование файлов. Каждая операция cp загружает файл в page cache — область оперативной памяти, которую ядро использует для кэширования содержимого файлов. Если вы впервые сталкиваетесь с этим термином: ядро Linux кеширует прочитанные с диска данные в свободную RAM, чтобы при повторном обращении не лезть на диск. При этом из page cache вытесняются другие страницы. Те самые, где могли лежать артефакты малвари.

Конкретный сценарий: атакующий запустил reverse shell через инъекцию в процесс Apache. Вредоносный код живёт только в памяти процесса — на диске его нет. Начинаете с cp /tmp/suspicious.sh /mnt/evidence/ или dd if=/dev/sda ... — каждая дисковая операция заставляет ядро перераспределить page cache. Когда доберётесь до захвата оперативной памяти Linux через insmod lime.ko, в дампе может не оказаться ни reverse shell, ни C2-конфигурации.

Правило: результаты сбора ВСЕГДА записываются на внешний носитель (USB-диск, NFS-шара, по сети через nc) — никогда на диск исследуемой системы. Каждый байт на скомпрометированном диске потенциально перезаписывает удалённые артефакты в unallocated space — это участки диска, где лежат остатки удалённых файлов; ОС пометила блоки как свободные, но данные ещё физически на месте, пока их не перезаписали.

Пошаговый сбор энергозависимых данных: DFIR методика для Linux

Дальше — конкретный порядок действий. Каждый шаг с объяснением «зачем» и описанием ожидаемого результата.

Что нужно перед началом: — Root-доступ к скомпрометированному хосту (SSH или физическая консоль) — Внешний носитель или сетевая шара, смонтированная в /mnt/evidence/ — сюда пойдёт всё — Если есть подозрение на подмену системных утилит — статически скомпилированные бинарники (ps, ss, lsof) с доверенного носителя. Подмена системных утилит — не паранойя: руткиты уровня ядра и userland-руткиты вроде Diamorphine делают это регулярно — Скомпилированный модуль LiME под текущую версию ядра (проверяется через uname -r) или скачанный AVML

Захват оперативной памяти Linux — шаг первый, без исключений

RAM содержит всё, чего нет на диске: расшифрованные ключи, fileless-малварь, инъектированный код, активные сетевые соединения. По данным Mandiant M-Trends 2025, медианное время обнаружения атакующего — 11 дней. За это время в памяти накопилось множество артефактов, но они исчезнут при первой перезагрузке.

LiME (Linux Memory Extractor) — модуль ядра, снимающий полный дамп памяти без остановки системы. AVML (Acquire Volatile Memory for Linux) от Microsoft — альтернатива, не требующая сборки kernel-модуля: работает через /proc/kcore или /dev/crash и автоматически справляется с KASLR (рандомизация адресного пространства ядра — механизм, при котором ядро загружается по случайному адресу при каждой загрузке, чтобы затруднить эксплуатацию) и CONFIG_STRICT_DEVMEM на современных ядрах.

# LiME: модуль должен быть собран под текущее ядро (uname -r)
insmod /mnt/tools/lime-$(uname -r).ko "path=/mnt/evidence/mem.lime format=lime"
# Сразу хешируем — без хеша дамп теряет доказательную силу
sha256sum /mnt/evidence/mem.lime > /mnt/evidence/mem.lime.sha256

Что должно получиться: файл mem.lime размером, равным объёму RAM хоста. Сервер с 16 ГБ памяти — файл около 16 ГБ. Файл .sha256 рядом с дампом.

Частая боль: модуль LiME должен быть скомпилирован строго под uname -r целевого хоста. Ядро обновилось вчера — старый модуль не загрузится. В зрелых SOC модули LiME пересобираются автоматически при каждом обновлении ядра. Нет модуля — AVML как запасной вариант, сборка не нужна.

LiME умеет передавать дамп по сети: insmod lime.ko "path=tcp:4444 format=lime", на рабочей станции аналитика — приём через nc -l -p 4444 > mem.lime. Полезно, когда к скомпрометированному серверу нет физического доступа и USB подключить нельзя.

Фиксация процессов и сетевого стека — пока соединения живы

Пока система работает, видно дерево процессов, сетевые соединения, открытые файлы. После перезагрузки или «изоляции» хоста всё это исчезнет.

ps auxwf (флаги wf — широкий вывод + дерево) покажет, какой процесс породил какой. Если apache2 порождает /bin/sh, а тот запускает curl на внешний IP — вот она, точка входа в расследование. В терминологии MITRE ATT&CK (открытая база тактик и техник атак; идентификаторы вида T1234 указывают на конкретную технику — пригодится для классификации находок в отчёте) это техника Process Discovery (T1057, тактика Discovery).

ss -tupln показывает TCP/UDP-соединения с привязкой к PID (идентификатор процесса — число, по которому ядро различает запущенные программы). Критично зафиксировать ESTABLISHED-соединения до любой «изоляции» хоста. Альтернатива — netstat -plunto, но ss не требует установки пакета net-tools.

Ключевой приём с lsof -V: если атакующий удалил бинарник, но процесс ещё работает, через lsof можно найти ссылку на удалённый файл в /proc/[PID]/exe и скопировать его через cp /proc/[PID]/exe /mnt/evidence/recovered_binary. Бинарь жив, пока жив процесс. Этот приём неоднократно спасал расследования — запомните его.

# Фиксация состояния — всё на внешний носитель
ps auxwf > /mnt/evidence/ps.txt
ss -tupln > /mnt/evidence/ss.txt
lsof -V > /mnt/evidence/lsof.txt
ip neigh > /mnt/evidence/arp.txt
ip route show > /mnt/evidence/routes.txt
ip addr > /mnt/evidence/ifaces.txt
date > /mnt/evidence/collection_timestamp.txt

Что должно получиться: семь текстовых файлов. В ps.txt — полное дерево процессов; в ss.txt — сетевые соединения с PID; в arp.txt — ARP-таблица (соответствия IP и MAC-адресов в локальной сети — помогает понять, с какими соседями общался хост). Файл collection_timestamp.txt фиксирует время начала сбора — это часть chain of custody (цепочка хранения доказательств: кто, когда и что делал с артефактами; подробнее — ниже).

Временные данные, /proc и persistence-механизмы

/tmp, /dev/shm (RAM-диск — файловая система, живущая целиком в оперативной памяти) и /proc содержат артефакты, которые не переживают перезагрузку. /proc/[PID]/cmdline — командная строка процесса, /proc/[PID]/environ — переменные окружения, где иногда остаются пароли и API-токены в открытом виде.

На этом шаге копируем содержимое /tmp и /dev/shm на внешний носитель: cp -a /tmp/ /mnt/evidence/tmp_copy/. Для подозрительных PID — сохраняем cmdline и environ.

Параллельно проверяем persistence-механизмы — способы, которыми атакующий закрепляется в системе, чтобы пережить перезагрузку:

Cron (MITRE ATT&CK T1053.003 — тактики Execution, Persistence, Privilege Escalation): проверяем не только crontab -l, но и /etc/crontab, /etc/cron.d/, /var/spool/cron/crontabs/. Типичная маскировка — файл /etc/cron.d/apt-compat-check с именем, похожим на системное обслуживание, но содержащий reverse shell каждые 15 минут. Название выбрано не случайно: администратор пролистает его, приняв за задачу apt. В SigmaHQ (открытый репозиторий правил обнаружения) есть правило lnx_cron_crontab_file_modification.yml для отслеживания таких модификаций.

Systemd Service (MITRE ATT&CK T1543.002 — тактики Persistence, Privilege Escalation): атакующие создают юнит-файлы в /etc/systemd/system/. Почему именно туда? Этот путь имеет приоритет над стандартными юнитами из /lib/systemd/system/, что позволяет подменить легитимный сервис. Правило SigmaHQ lnx_auditd_systemd_service_creation.yml ловит создание новых юнитов через аудит.

Логи, журналы и конфигурации

На Debian-подобных системах логи аутентификации лежат в /var/log/auth.log, на RHEL/CentOS — в /var/log/secure. Разница принципиальна: скопируете не тот файл — потеряете данные. Перед сбором проверьте, какой дистрибутив перед вами (cat /etc/os-release).

Бинарный journal (systemd-journal в /var/log/journal/) — сложнее подчистить, чем текстовые логи, и атакующие часто про него забывают. Если /var/log/auth.log подозрительно короткий или имеет разрыв во временных метках (проверяется через stat /var/log/auth.log) — это само по себе индикатор компрометации.

Дополнительно: /var/log/btmp (неудачные логоны, читается через lastb — полезно для выявления брутфорса), /var/log/wtmp (все входы и выходы — last -Faiwx), /var/log/cron (события планировщика).

Образ диска — последний шаг, не первый

Побитовая копия фиксирует всё, включая unallocated space. Именно поэтому этот шаг идёт последним: данные на диске никуда не денутся (если система не перезаписывает их), а RAM и процессы ждать не будут.

Используйте dc3dd (форк dd со встроенным хешированием и логированием) или стандартный dd. Образ — всегда на внешний носитель.

Первоначальное реагирование на инцидент Linux: типичные ошибки

«Давайте перезагрузим, вдруг поможет» — перезагрузка уничтожает RAM, сбрасывает процессы и сетевой стек. А persistence-механизмы (cron, systemd-юниты) переживут перезагрузку без проблем. Результат: улики потеряны, атакующий остался. Худший исход из возможных.

Установка инструментов на скомпрометированный хост. apt install volatility3 — это запись на диск, изменение кеша пакетов, вытеснение страниц из RAM. Инструменты готовятся заранее на внешнем носителе. Если в момент инцидента начинаете ставить пакеты — вы уже теряете артефакты.

Запуск антивируса «для проверки». Антивирус может удалить или переместить малварь — и всё, артефакт уничтожен до того, как вы его зафиксировали. Сначала сбор, потом реагирование.

Отсутствие LiME до инцидента. Модуль нужно пересобирать при каждом обновлении ядра. Нет модуля в момент инцидента — memory acquisition штатными средствами невозможен. Держите AVML как fallback или автоматизируйте пересборку LiME. Я видел команды, которые узнавали об этой проблеме в 3 часа ночи на боевом инциденте. Не повторяйте.

Chain of custody при сборе доказательств Linux форензика

Chain of custody — непрерывная документация всех действий с доказательствами. Зачем это нужно: без неё дамп памяти и образ диска не примут ни в суде, ни в нормальном внутреннем расследовании. Адвокат противоположной стороны первым делом спросит: «А кто гарантирует, что дамп не модифицировали после снятия?»

Три правила, которые стоит выучить до инцидента:

Хешируйте каждый артефакт. sha256sum сразу после создания файла. Хеш записывается рядом с артефактом. Если позже хеш не совпадёт — доказательство скомпрометировано. Не md5 — sha256. MD5 уязвим к коллизиям, и это известный аргумент в суде.

Фиксируйте время. Перед началом сбора — date на хосте и на рабочей станции. Расхождение часов (а оно бывает — иногда на минуты, иногда на часы) нужно документировать. Тайм-зону хоста (cat /etc/timezone или timedatectl) — тоже: системные логи пишутся в локальной тайм-зоне, и при корреляции с другими источниками разница может сбить весь таймлайн расследования.

Не записывайте на скомпрометированную систему. Каждый байт на диске хоста потенциально перезаписывает удалённые артефакты. Всё — на внешний носитель.

NIST CSF 2.0 (фреймворк кибербезопасности Национального института стандартов и технологий — набор рекомендаций по организации ИБ-процессов) в функции RS.AN-01 (Incident Analysis) прямо требует, чтобы уведомления от систем обнаружения расследовались. Расследование начинается с правильного сбора. Volatile-данные потеряны — расследовать нечего. Chain of custody нарушена — результаты не имеют юридического веса.

Картина, которая повторяется из инцидента в инцидент: команды знают dd, cp, grep, могут написать однострочник на awk — но не могут ответить на вопрос «что снимать первым и почему». Курсы по форензике часто начинают с инструментов: какие флаги у dd, как работает Autopsy, как поставить Volatility. Но инструмент без порядка действий — скальпель без знания анатомии.

RFC 3227 написан в 2002 году. Принцип order of volatility не устарел, потому что архитектура оперативной памяти работает так же. Ни AVML, ни Velociraptor не компенсируют потерянный дамп RAM. Самый частый сценарий потери артефактов — не атакующий их стёр, а защитник перезаписал. Скопировал файлы не туда, установил пакет, перезагрузил «на всякий случай». И это не умысел, а отсутствие incident response playbook. Подготовьте его до инцидента: модуль LiME собран, внешний носитель с тулкитом рядом, порядок шагов записан на бумаге. Именно на бумаге — когда стресс, читать markdown неудобно. Если хочется не просто статьи, а пройти базу DFIR системно, от первых шагов до реальных задач — IB Basics на codeby.school закрывает этот фундамент.