Восстановление удалённых файлов Linux через журнал ext4 — когда photorec бесполезен

На расследовании инцидента с компрометацией веб-сервера под Ubuntu 22.04 обнаружилось типичное: атакующий удалил access.log, auth.log и PHP-файл веб-шелла командой rm -rf. Первый совет из каждого русскоязычного руководства — запустить photorec. Результат: 12 000 безымянных файлов в папках recup_dir.1 … recup_dir.47, ни одного нужного лога. Текстовые файлы без характерных сигнатур для carving-инструментов невидимы в принципе. Ниже — пошаговый разбор подхода к восстановлению удалённых файлов Linux через анализ журнала, а не через сканирование сигнатур.

Почему photorec — не альтернатива для форензики скомпрометированного сервера

PhotoRec и foremost — инструменты file carving (дословно — «вырезание файлов»). Они сканируют диск побайтово и ищут known file signatures, они же magic bytes — фиксированные последовательности байтов в начале файлов. JPEG начинается с FF D8 FF, PDF — с %PDF-, ZIP — с PK. Найдя такую последовательность, photorec вырезает блок данных и сохраняет в файл с автоматическим именем.

Для восстановления фотографий с отформатированной флешки подход работает отлично. Для расследования инцидента на скомпрометированном Linux-сервере он бесполезен по трём причинам.

Лог-файлы не имеют уникальных сигнатур. /var/log/auth.log, /var/log/syslog, конфиги nginx — обычный текст в UTF-8. У текстового файла нет magic bytes, которые отличают его от любого другого текстового фрагмента на диске. PhotoRec найдёт тысячи осколков, но не отличит auth.log от строки man-страницы.

Имена и пути файлов теряются. Carving восстанавливает содержимое, но не метаданные. На выходе — f0012345.txt, f0012346.txt. При расследовании нужно доказать, что файл лежал в /var/www/html/uploads/c99.php. PhotoRec такой информации не даёт.

Временные метки отсутствуют. Для хронологии инцидента критичны время создания, модификации и последнего доступа к файлу. Эти данные хранятся в inode — структуре метаданных файла в ext4, которая содержит размер, владельца, права доступа и набор временных меток: ctime, mtime, atime. Carving-инструменты inode не анализируют.

Зачем атакующему вообще удалять файлы? Мотивация прозрачная: скрыть следы присутствия. Веб-шелл — прямое доказательство компрометации, auth.log — источник IP-адресов, с которых шёл доступ, access.log — хронология запросов к шеллу. Удаление артефактов — стандартный шаг при сокрытии следов, и задача DFIR-специалиста (DFIR — Digital Forensics and Incident Response, цифровая криминалистика и реагирование на инциденты) — эти артефакты восстановить.

Восстановление файлов ext4 через анализ журнала решает все три проблемы: журнал хранит копии транзакций с inode, включая имена, пути и полный набор временных меток.

Журнал файловой системы ext4: что это и зачем нужно при реагировании на инциденты Linux

Ext4 (Fourth Extended Filesystem) — стандартная файловая система большинства Linux-дистрибутивов: Ubuntu, Debian, CentOS, RHEL. Она использует журналирование (journaling) для защиты от повреждений при сбоях питания.

Принцип: прежде чем записать изменения в основные структуры файловой системы, ext4 фиксирует их в специальную область диска — журнал. Каждая операция (создание файла, удаление, переименование, изменение прав) сначала записывается в журнал как «намерение» и только после подтверждения применяется к основным структурам. Если сервер упал до подтверждения — при загрузке ext4 откатывает незавершённую транзакцию. Это обеспечивает целостность ФС, но для DFIR интереснее другое: даже после удаления файла его метаданные какое-то время остаются в журнале.

Три режима журналирования ext4 — они определяют, что именно попадает в журнал:

• journal — записываются и метаданные, и данные файлов. Максимум информации для восстановления, но заметно бьёт по производительности. Встречается редко.
• ordered (режим по умолчанию) — записываются только метаданные; данные файлов фиксируются на диске до закрытия транзакции в журнале. Хороший баланс: метаданные в журнале есть, содержимое файлов — на своих блоках.
• writeback — записываются только метаданные, порядок записи данных не гарантирован.

Проверить текущий режим: cat /proc/mounts | grep ext4 — параметр data= покажет режим. Если data=ordered — стандартная конфигурация.

Что происходит при удалении файла в ext4:

1. Запись в каталоге помечается как удалённая
2. Счётчик ссылок (link count) в inode обнуляется
3. Блоки данных помечаются как свободные в bitmap (карта занятости блоков)
4. Ext4 обнуляет указатели на блоки данных в inode

Пункт 4 — главная сложность восстановления, и это стандартное поведение ext-семейства. Даже если inode сохранился на диске, указатели на блоки данных уже стёрты — через inode файл не собрать. Обнуление указателей — общее свойство ext2/ext3/ext4, и именно оно делает recovery сложнее, чем в NTFS или FAT.

Журнал — обходной путь. Если транзакция удаления ещё не вытеснена из журнала, в нём хранятся копии inode до обнуления — с рабочими указателями на блоки данных. Эти копии и использует ext4magic для восстановления.

Тут есть одно «но», и оно критическое. Журнал ext4 имеет фиксированный размер — обычно 128 МБ — и работает циклически. Старые транзакции перезаписываются новыми. На загруженном сервере журнал может полностью обновиться за минуты. Отсюда первое правило DFIR на Linux-сервере: минимизировать запись на скомпрометированный диск сразу после обнаружения инцидента. Каждая новая операция вытесняет из журнала данные, нужные для восстановления.

Восстановление файлов ext4 через анализ журнала файловой системы: пошаговый сценарий

Полный цикл восстановления на скомпрометированном Linux-сервере. Сценарий: Ubuntu/Debian с ext4, атакующий удалил файлы в /var/log и /var/www.

Предусловия:

• Права root на сервере (или физический доступ к диску)
• Файловая система ext4 — проверить: df -Th /путь, в колонке Type должно быть ext4
• Внешний носитель для образа и восстановленных файлов (USB-диск, сетевое хранилище)
• Установленные утилиты: debugfs (входит в пакет e2fsprogs, есть по умолчанию), ext4magic (ставится отдельно: sudo apt-get install ext4magic)

Блокировка записи и снятие образа диска

Прежде чем прикасаться к файловой системе — побитовая копия раздела. Это правило без исключений: работать нужно с копией. Любая ошибка на оригинале уничтожит доказательства.

Если целевой раздел — не корневой (например, /home на /dev/sda2), размонтируйте его: umount /home. Если корневой — переведите в read-only: mount -o remount,ro /. При возможности загрузитесь с Live USB (SystemRescueCD, Ubuntu Live) и работайте оттуда, чтобы целевая ОС вообще не загружалась и ничего не писала на диск.

# Побитовая копия раздела на внешний носитель
# /dev/sda2 — замените на ваш раздел
# conv=noerror,sync — продолжать при ошибках чтения
dd if=/dev/sda2 of=/mnt/external/evidence.img bs=4M \
   conv=noerror,sync status=progress

На выходе — строка прогресса с количеством скопированных байтов и скоростью записи. По завершении размер файла evidence.img должен совпадать с размером раздела. Проверка: fdisk -l /dev/sda для размера раздела, ls -lh /mnt/external/evidence.img для размера образа.

Типичная ошибка новичка: сохранять образ на тот же диск, откуда снимаете. Это перезапишет данные, которые вы пытаетесь восстановить. Образ — на внешний носитель, всегда.

Извлечение и анализ журнала через debugfs

debugfs — утилита для низкоуровневой работы с ext2/ext3/ext4. Позволяет читать внутренние структуры файловой системы: inode, каталоги, журнал. Название обманчивое — это не «отладчик» в привычном смысле, а скорее интерактивный инспектор ФС.

В большинстве конфигураций ext4 журнал использует зарезервированный inode с номером 8 (EXT4_JOURNAL_INO), но это не гарантировано. Точный номер нужно подтвердить через dumpe2fs -h /dev/sdXN | grep -i journal перед извлечением. Первое действие — извлечь журнал в отдельный файл, пока он не перезаписан:

# Извлечение журнала из образа (или из /dev/sda2 напрямую)
# <8> — inode журнала (по умолчанию 8; проверьте через dumpe2fs)
sudo debugfs -R "dump <8> /mnt/external/sda2.journal" \
     /mnt/external/evidence.img

На выходе — файл sda2.journal размером порядка 128 МБ. Если файл пустой или нулевого размера — проверьте путь к устройству и права.

Если evidence.img — образ раздела (dd if=/dev/sda2), команда выше сработает. Если вы сняли образ всего диска (dd if=/dev/sda), debugfs не найдёт суперблок ext4 — потребуется сначала подключить нужный раздел через losetup -o <смещение_раздела> и работать с полученным loop-устройством.

Зачем копировать журнал отдельно? ext4magic может использовать внешнюю копию журнала через флаг -j. Если между инцидентом и началом расследования прошло время — внутренний журнал мог частично перезаписаться; ранняя копия сохраняет максимум данных.

Дополнительная разведка — посмотрите параметры файловой системы: sudo dumpe2fs /mnt/external/evidence.img | grep -i journal. Утилита dumpe2fs выведет информацию о суперблоке: размер журнала, количество транзакций и тип (internal/external).

Для ручного анализа конкретного inode запустите debugfs в интерактивном режиме: sudo debugfs /mnt/external/evidence.img. Внутри команда stat <НОМЕР_INODE> покажет метаданные файла: размер, владельца, временные метки, указатели на блоки. Если inode принадлежит удалённому файлу — увидите Deletion time (dtime) с точным временем удаления. dtime заполняется при удалении последней ссылки на файл, когда link count становится равным нулю. Для хронологии инцидента — бесценная информация.

Поиск и извлечение удалённых файлов через ext4magic

ext4magic — ключевой инструмент для восстановления файлов ext4 через журнал. В отличие от photorec, она понимает структуру ext4 и возвращает файлы с оригинальными именами, путями и метаданными.

Установка: sudo apt-get install ext4magic (Ubuntu/Debian). На CentOS/RHEL может потребоваться сборка из исходников.

Делай раз — разведка. Смотрим, какие удалённые файлы можно восстановить в нужном каталоге за указанный временной диапазон:

# Листинг восстановимых файлов в /var/log за 12 часов
# -a: начало диапазона (unix timestamp)
# -f: путь ОТНОСИТЕЛЬНО корня раздела
# -j: внешняя копия журнала
# -l: только показать, не восстанавливать
# Синтаксис для ext4magic 0.3.x — сверьте с ext4magic -h
sudo ext4magic /mnt/external/evidence.img \
     -a $(date -d "-12hours" +%s) \
     -f var/log -j /mnt/external/sda2.journal -l

На выходе — таблица с именами файлов. В левой колонке — процент восстановимости. Файлы с 100% восстановятся полностью. Ниже 100% — часть блоков перезаписана, файл восстановится частично.

Делай два — восстановление. Та же команда, но с флагом -r вместо -l и каталогом назначения через -d:

sudo ext4magic /mnt/external/evidence.img -a $(date -d "-12hours" +%s) -f var/log -j /mnt/external/sda2.journal -r -d /mnt/external/RECOVERED (сверьте флаги с ext4magic -h вашей версии)

Флаг -r восстанавливает файлы со 100% из предыдущего листинга. Каталог назначения — обязательно на другом разделе, не на исследуемом.

Делай три — проверка. В /mnt/external/RECOVERED появится структура каталогов с восстановленными файлами. Имена и пути сохранены: var/log/auth.log будет в RECOVERED/var/log/auth.log. Проверьте содержимое: head -20 /mnt/external/RECOVERED/var/log/auth.log — должны отобразиться строки лога. Если файл читается корректно — восстановление прошло.

ext4magic может восстановить «лишние» файлы, удалённые в том же временном диапазоне. Это нормально — отфильтруйте ненужное. Если нужен конкретный каталог (например, /var/www/html/uploads), укажите его в параметре -f: -f var/www/html/uploads.

Ограничения метода: когда восстановление данных после инцидента через журнал не работает

Журнал ext4 — не серебряная пуля. Есть ситуации, когда подход не даст результата.

Журнал перезаписан. На активном сервере с интенсивной записью (база данных, логирование, пользовательские сессии) 128 МБ журнала обновляются за минуты. Если между удалением и началом расследования прошли часы — нужные транзакции уже вытеснены.

Атакующий использовал shred или wipe. Эти утилиты многократно перезаписывают содержимое файла случайными данными перед удалением. В режиме ordered журнал хранит только метаданные — имя, размер, владельца — но не содержимое. После shred метаданные восстановить можно, содержимое — нет.

Файловая система не ext4. XFS, Btrfs, ZFS имеют собственные механизмы журналирования. Для XFS есть xfs_logprint и xfs_db, но инструментарий восстановления значительно беднее. ext4magic поддерживает ext2/ext3/ext4, но восстановление через журнал работает только для ext3/ext4 (журналируемых ФС).

Inode полностью перезаписан. Если на месте удалённого inode уже создан новый файл — ни журнал, ни debugfs не помогут.

Когда стандартное восстановление через -r не сработало, ext4magic предлагает режим глубокого сканирования:

sudo ext4magic /dev/sda2 -m -d /mnt/external/RECOVERED_DEEP

Флаг -m запускает полное сканирование диска блок за блоком — поиск удалённых файлов по остаточным метаданным и фрагментам. Работает значительно дольше (часы на терабайтных дисках), восстанавливает файлы с числовыми именами вместо оригинальных. По сути — гибрид между carving и журнальным восстановлением: с пониманием структуры ext4, но без привязки к конкретным транзакциям журнала.

Практический совет: всегда начинайте с -l (листинг), затем -r (восстановление по журналу), и только при неудаче — -m (глубокое сканирование). Каждый следующий шаг медленнее и менее точен, но охватывает больше.

Анализ файловой системы при взломе: сравнение инструментов для DFIR Linux-сервера

Выбор инструмента зависит от задачи. Сводка для принятия решения:

extundelete (sudo extundelete /dev/sda2 --restore-all) — популярная рекомендация в русскоязычных статьях. Восстанавливает с именами, работает быстро. Ограничение: на ext4 результат нестабилен из-за обнуления указателей в inode. На практике ext4magic с внешним журналом даёт лучший результат для свежих удалений.

The Sleuth Kit (TSK) — профессиональный набор для цифровой криминалистики Linux. Команды istat (детальная информация об inode), jls (листинг записей журнала) и jcat (извлечение конкретных записей) позволяют разобрать журнал транзакция за транзакцией. Это уровень глубже, чем ext4magic: для случаев, когда автоматика не справилась или нужна детальная реконструкция хронологии действий атакующего с точностью до отдельных операций.

debugfs в ручном режиме полезен для точечного анализа: когда вы знаете номер inode удалённого файла (например, из логов auditd) и хотите изучить его метаданные, время удаления и связи с каталогами. Для массового восстановления — слишком трудоёмко.

Каждый раз, когда вижу рекомендацию «запустите photorec» в контексте расследования компрометации сервера, хочется спросить: а вы вообще пробовали? PhotoRec проектировался для восстановления медиафайлов с отформатированных SD-карт — и для этого он хорош. Но при расследовании инцидента нужны не «все файлы, которые получится вырезать», а конкретные артефакты: логи, конфиги, веб-шеллы — с путями, метками времени и доказательной ценностью для отчёта. Журнал ext4 даёт именно это, и я до сих пор не понимаю, почему подход отсутствует в большинстве русскоязычных руководств по восстановлению.

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

Навык восстановления через журнал — базовая гигиена для любого, кто администрирует Linux-серверы. Пройдите цикл один раз на тестовой VM: создайте файл, удалите, извлеките журнал через debugfs, восстановите через ext4magic. Разница между «я читал про это» и «я делал это руками» — разница между полезным участником расследования и наблюдателем. Если хотите выстроить фундамент в ИБ системно — от сетей и логирования до форензики — на codeby.school есть IB Basics, где дают не теорию про CIA-триаду, а первые практические задачи без входного порога.