Файловые системы Linux: ext4, временные метки, удалённое

Как ext4 хранит данные и метки времени, почему «удалённый» файл часто ещё на диске и как смонтировать образ, не испортив улики.

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

Понимание файловой системы — фундамент дисковой криминалистики. Не зная, что такое inode и какие у него метки времени, нельзя ни выстроить достоверный таймлайн, ни объяснить, почему удалённый файл удаётся восстановить. Всё ниже выполняется над образом диска своего или разрешённого носителя, а не над рабочей системой.

Зачем это знать защитнику

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

Устройство ext4: суперблок и inode

ext4 — основная файловая система большинства дистрибутивов Linux. На верхнем уровне диск разбит на блочные группы, а ключевые метаданные описаны в суперблоке: размер блока, число inode, метка тома, UUID, время последнего монтирования и проверки. Суперблок дублируется в нескольких местах — это и страховка, и подсказка следователю, если основной повреждён.

Каждому файлу соответствует inode с метаданными и указателями на блоки данных. Имя в каталоге — это всего лишь запись «имя → номер inode». Такое разделение объясняет жёсткие ссылки (несколько имён на один inode) и то, почему удаление имени не обязательно стирает данные.

# Параметры файловой системы из суперблока (на образе/разделе)
dumpe2fs -h /dev/loop0

# Номер inode и метаданные конкретного файла
stat /mnt/evidence/report.pdf
ls -i /mnt/evidence/report.pdf

Временные метки: atime, mtime, ctime, crtime

ext4 хранит у каждого inode четыре метки времени — это сердце таймлайна:

Тонкость, которую следователь обязан знать: mtime и atime программа может произвольно выставить системным вызовом (антифорензика — «timestomping»), а вот ctime подделать из пользовательского пространства штатно нельзя — он отражает реальное изменение inode. Поэтому расхождение «mtime в прошлом, ctime недавно» — классический признак подмены меток. Точный crtime на ext4 достают через debugfs:

# Все метки времени inode, включая crtime
debugfs -R "stat <12>" /dev/loop0

Восстановление удалённого (file carving)

Когда файл «удаляют», ext4 обычно помечает его блоки и inode как свободные, но данные на диске не затираются до тех пор, пока место не займут заново. Отсюда две стратегии восстановления:

• По метаданным — найти освобождённый inode и его указатели (в журналируемых ФС часть сведений сохраняется в журнале);
• Карвинг по сигнатурам — игнорировать файловую систему и искать на сыром образе характерные «магические» байты начала и конца файла. Например, JPEG начинается с FF D8 FF, PDF — с %PDF. Инструменты вроде photorec/scalpel собирают файлы именно так.

# Карвинг по сигнатурам из образа в каталог вывода
photorec image.dd

# Удалённые записи каталога и их inode (ext)
fls -rd /dev/loop0

Важно понимать ограничение: после перезаписи блоков или работы TRIM на SSD данные могут быть утрачены безвозвратно — поэтому носитель как можно раньше выводят из эксплуатации и снимают образ.

Журнал ext4 как источник улик

ext4 — журналируемая файловая система: прежде чем менять метаданные, она записывает намерение в служебный журнал (по умолчанию режим data=ordered журналирует только метаданные). Для следователя журнал — дополнительный источник: в нём могут оставаться недавние состояния inode и записей каталога, которые уже изменились в основной области. Иногда это позволяет увидеть прежнее имя файла или указатели на блоки только что удалённого объекта. Именно поэтому при монтировании образа важен флаг, запрещающий «доигрывание» журнала: если позволить ядру применить отложенные транзакции, состояние файловой системы изменится и эти промежуточные следы будут потеряны вместе с целостностью улики.

Как это работает под капотом: монтирование только для чтения

Любое исследование начинается с криминалистического образа (например, файла image.dd), а не с живого диска. Чтобы заглянуть внутрь, образ подключают как петлевое устройство и монтируют со строгими флагами, исключающими любую запись:

# Подключить образ как loop-устройство
sudo losetup -fP image.dd

# Смонтировать ТОЛЬКО для чтения, без обновления atime
sudo mount -o ro,noload,noexec,nodev /dev/loop0 /mnt/evidence

Флаг ro запрещает запись, noload не даёт ext4 «доиграть» журнал (что изменило бы ФС), noatime/умолчания исключают обновление времени доступа. Дополнительно профессионалы используют аппаратный write blocker при работе с физическим носителем. Перед анализом и после него считают хэш образа (SHA-256) — совпадение доказывает, что улика не изменилась.

Как защититься

• Сразу снимайте образ и хэш. Чем дольше скомпрометированная система работает, тем выше шанс, что удалённые данные затрутся.
• Никогда не монтируйте улику на запись. ro + write blocker — обязательны; иначе доказательство теряет силу.
• Сверяйте ctime и mtime. Их рассогласование выявляет timestomping, который злоумышленники применяют, чтобы спрятать свежие файлы среди старых.
• Для надёжного удаления — затирание. Если вы защищаете свои данные, помните: обычное удаление обратимо; нужна перезапись (shred) или шифрование диска целиком.

Итоги

• В ext4 суперблок описывает том, а каждый файл — это inode с метаданными и указателями на блоки; имя хранится отдельно в каталоге.
• Четыре метки времени (atime/mtime/ctime/crtime) образуют таймлайн; ctime трудно подделать, поэтому его расхождение с mtime выдаёт подмену.
• Удаление помечает блоки свободными, но данные остаются — их восстанавливают по метаданным или карвингом по сигнатурам, пока место не перезаписано.
• Исследуют только образ, смонтированный read-only (ro,noload), с контролем хэша до и после.