Порядок летучести: что собирать первым
Этот урок объясняет правило порядка летучести — какие данные исчезают быстрее и поэтому собираются первыми.
Порядок летучести (order of volatility) — принцип, по которому при сборе доказательств сначала фиксируют данные, исчезающие быстрее всего, затем — более стабильные.
Данные в системе «живут» разное время. Содержимое регистров процессора меняется миллионы раз в секунду, оперативная память исчезает при выключении, а файлы на диске и резервные копии могут храниться годами. Если собирать в неправильном порядке — например, сначала возиться с диском, — летучие данные просто исчезнут. Правило порядка летучести закреплено в практических руководствах по сбору цифровых доказательств (его формулировка восходит к RFC 3227 «Guidelines for Evidence Collection and Archiving») и стало одним из базовых рефлексов любого DFIR-специалиста.
За правилом стоит экономическая логика: время на месте инцидента ограничено, а данные «портятся» с разной скоростью. Разумно сначала спасти то, что испарится через секунды, и оставить на потом то, что спокойно дождётся своей очереди. Это тот же принцип, что и в медицине при сортировке пострадавших: внимание идёт туда, где промедление необратимо.
Шкала летучести (от самого летучего к стабильному)
1. Регистры и кеш CPU микросекунды 2. Таблицы маршрутизации, секунды ARP-кеш, статистика ядра 3. Оперативная память (RAM) до выключения 4. Временные файлы, /tmp до перезагрузки/очистки 5. Диск (файлы, метаданные) долго 6. Удалённые логи на других долго серверах, мониторинг 7. Архивы, резервные копии очень долго
Что это значит на практике
На живой системе порядок сбора обычно такой: сначала фиксируют сетевые соединения и состояние (быстро исчезают), затем снимают дамп памяти, потом — образ диска. Логи с других серверов и бэкапы можно забрать позже: они стабильны.
Почему сетевое состояние ценят так высоко? Активные TCP-соединения, список слушающих портов, таблица ARP, кеш DNS — всё это прямые улики работы злоумышленника прямо сейчас: к какому командному серверу (C2) уходит трафик, какой процесс держит подозрительное соединение, какие хосты в сети «знакомы» заражённой машине. Эти данные живут секунды-минуты и не сохраняются никуда автоматически. Дамп памяти — следующий по ценности артефакт: в нём расшифрованные данные, ключи, инжектированный код, история команд, артефакты fileless-вредоносов, которых на диске может вообще не быть.
Полезно держать в голове и обратную сторону шкалы. Архивы и резервные копии стоят в самом низу приоритета не потому, что они не важны, а потому что они стабильны: их можно забрать и завтра, и через неделю, состояние не изменится. То же касается логов, уже отправленных на отдельный сервер сбора (syslog, SIEM): они зафиксированы вне исследуемой машины и переживут даже её полное уничтожение. Поэтому грамотный план сбора выглядит как воронка: в первые минуты лихорадочно спасаем сеть и память, затем спокойно снимаем образ диска, а стабильные источники подтягиваем уже на этапе анализа, без спешки.
Ещё одна практическая деталь — куда сохранять собранное. Категорически нельзя писать дампы и логи на исследуемый диск: это и меняет оригинал, и рискует перезаписать ценные удалённые данные. Вывод направляют на внешний носитель или по сети на станцию сбора. В примере ниже для наглядности мы пишем в локальные файлы, но в реальном сценарии путём назначения был бы примонтированный внешний диск или сетевой приёмник.
# Пример последовательности на живой Linux-системе
# (выполняется с правом доступа, вывод сохраняется в лог)
# 1. летучее состояние сети и процессов
netstat -antp > net_connections.txt
ps aux > processes.txt
# 2. дамп оперативной памяти (спец. инструментом)
# avml memory.lime # или LiME/AVML
# 3. образ диска снимают после памяти
# dd if=/dev/sda of=disk.img bs=4M (см. раздел про образы)Документируй последовательность, а не только результат
Сам факт того, в каком порядке вы собирали артефакты, тоже является частью доказательной базы. В журнале фиксируют время каждого шага, использованную команду и куда сохранён результат. Это позволяет позже показать, что сбор шёл методично и от летучего к стабильному, а не хаотично. Кроме того, последовательность объясняет расхождения во временах: если памяти сняли в 14:02, а диск — в 14:40, естественно, что состояние диска отражает чуть более позднюю картину.
Как работает под капотом
Логика проста: чем короче «время жизни» данных, тем выше их приоритет. Память исчезает при отключении питания; сетевые таблицы обновляются постоянно; диск переживает выключение. Поэтому образ диска можно снять и через час, а вот соединения и память — только сейчас. При этом каждый собранный артефакт сразу хешируют, чтобы зафиксировать его состояние на момент сбора.
Тонкость в том, что сам акт сбора летучих данных немного меняет систему: запуск netstat создаёт процесс, чтение памяти конкурирует за ту же память. Это неизбежный «эффект наблюдателя» в live-форензике. Его не устраняют, а минимизируют и документируют: используют компактные доверенные инструменты, по возможности с внешнего носителя, и записывают, что и когда запускали, чтобы потом отличить свои следы от следов злоумышленника.
Живая vs выключенная — короткая ремарка
Если система уже выключена, летучие данные потеряны, и работают только с диском. Если включена — есть шанс получить память и сетевое состояние, но любое действие на живой системе меняет её, поэтому каждый шаг документируют. Подробнее — в следующем уроке.
Принцип, а не жёсткий рецепт
Важно понимать порядок летучести как принцип, а не как незыблемый список, который нужно выполнять буквально шаг за шагом. Конкретная последовательность зависит от ситуации: если есть подозрение на активную утечку данных через сеть прямо сейчас, разумно в первую очередь зафиксировать сетевые соединения; если на кону ключ шифрования в памяти — приоритет у дампа RAM. Шкала задаёт общий вектор «от быстро исчезающего к стабильному», а внутри этого вектора аналитик расставляет акценты под конкретный инцидент и обосновывает их в журнале. Слепое следование списку без учёта контекста так же опасно, как и полное его игнорирование.
Частые ошибки
- Начать с диска. Пока копируется диск, память и соединения исчезают.
- Забыть про сетевое состояние. ARP-кеш и активные соединения живут секунды-минуты.
- Не хешировать сразу. Артефакт без хеша на момент сбора теряет доказательную силу.
- Перезагрузить «чтобы зайти под админом». Перезагрузка убивает всё летучее.
- Не записать порядок и время шагов. Без хронологии трудно объяснить расхождения и доказать методичность.
Итоги
- Сначала собирают самое летучее: регистры/кеш, сетевое состояние, память; потом — диск и архивы.
- На живой системе порядок: сеть и процессы, дамп памяти, образ диска.
- Каждый артефакт хешируют сразу при сборе, а саму последовательность документируют.