Тамперинг загрузчика и Timestomping

Предыдущая тема заканчивалась на systemd: точка закрепления жила в конфигурации служб и переживала перезагрузку, но всё ещё находилась внутри обычной файловой системы. Защитник, который проверяет /etc, /usr и список юнитов, такую точку рано или поздно находит. Следующий шаг — уйти ниже: изменить код, который выполняется до того, как корневая файловая система вообще смонтирована, и подделать следы, по которым эту правку можно обнаружить.

Загрузка Linux — это цепочка звеньев, каждое из которых передаёт управление следующему: прошивка UEFI, загрузчик shim, загрузчик GRUB, ядро, initramfs, init в корневой файловой системе, PID 1. На каждом переходе есть файл, который можно изменить, и есть механизм, который это изменение способен поймать. Тема разбирает и то, и другое: как устроен переход, что именно проверяется подписью, а что нет, и как изменение initramfs переживает обновление пакетов, потому что initramfs собирается заново при каждом обновлении ядра — в том числе с участием пользовательских хуков.

Вторая половина темы — временные метки. Любая правка файла меняет его метаданные, и метаданные — это тоже след. В ext4 у inode четыре времени, и три из них пользователь может менять, а четвёртое — нет; понимание того, какое именно и почему, отделяет аккуратную работу от работы, которая выдаёт себя одним stat. Разбирается и то, как метку всё-таки подделывают напрямую через debugfs, и что при этом остаётся на диске.

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

Все примеры проверены на реальной системе там, где это возможно без root: распаковка initramfs, сборка собственного образа и его загрузка в QEMU, подделка меток в образе ext4 через debugfs, разбор wtmp. Команды, требующие администратора (GRUB, update-initramfs, auditd), приведены как примеры для собственной виртуальной машины; вывод для них помечен. Общая модель загрузки и структур ядра описана в литературе ⁷⁸.

Цепочка загрузки и точки вмешательства в неё показаны на рисунке 1.

Цепочка загрузки и её звенья

UEFI, shim и GRUB

Прошивка UEFI читает загрузочную запись и запускает EFI-приложение. В системах с Secure Boot это приложение должно быть подписано ключом, которому доверяет прошивка. Обычно таким приложением является shim — небольшой загрузчик, подписанный ключом Microsoft и потому проходящий проверку на большинстве машин. shim содержит собственный список доверенных ключей (MOK, Machine Owner Key) и передаёт управление следующему звену — как правило, GRUB.

GRUB читает конфигурацию, показывает меню, загружает ядро и initramfs. Его конфигурация на Ubuntu собирается из /etc/default/grub и скриптов /etc/grub.d/ командой grub-mkconfig, которая пишет /boot/grub/grub.cfg. В grub.cfg каждый пункт меню — это две строки: linux с путём к ядру и параметрами, и initrd с путём к образу initramfs. Пример с рабочей машины:

linux	/vmlinuz-linux-zen root=UUID=27ae04c6-97fd-43ab-a885-dadc5ed8aa67 rw rootflags=subvol=@ loglevel=3 quiet
initrd	/intel-ucode.img /initramfs-linux-zen.img

Здесь важны три вещи. root=UUID=… сообщает ядру, какую файловую систему монтировать как корень. initrd может перечислять несколько образов — они склеиваются в один initramfs, и файлы из более позднего образа перекрывают одноимённые из раннего. Параметры после root= передаются ядру и дальше в init; именно через них включаются отладочные режимы.

Править grub.cfg напрямую бессмысленно: при следующем update-grub он будет перезаписан. Сама раскладка /boot, порядок пунктов меню и роль загрузчика в администрировании описаны в руководстве по системному администрированию ³. Правка делается в /etc/default/grub — там же, где живут параметры по умолчанию:

# /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

GRUB_CMDLINE_LINUX_DEFAULT попадает в обычные пункты меню, GRUB_CMDLINE_LINUX — во все пункты, включая recovery. После правки — sudo update-grub. Это штатный путь; он же — самый заметный, потому что меняет файл, который проверяется глазами и контрольной суммой.

Параметры ядра как переключатель режима

Ядро разбирает параметры командной строки до запуска первого процесса. Несколько параметров меняют то, что будет исполнено:

Список параметров, которые понимает конкретная система, стоит сверять с man 7 bootparam и с документацией набора инструментов ¹.

Разница между init= и rdinit= принципиальна. init= применяется, когда корневая файловая система уже смонтирована и ядро ищет программу в ней. rdinit= применяется к initramfs: ядро распаковывает образ в ramfs и запускает /init оттуда, не имея никакого корня. Именно rdinit= позволяет получить управление до того, как что-либо из диска будет прочитано.

rd.break и break=premount — это не параметры ядра в строгом смысле, а инструкции скрипту /init внутри initramfs: разные наборы инструментов понимают разные слова. На Ubuntu с initramfs-tools работает break=premount; на RHEL с dracut — rd.break. Попытка использовать rd.break на Ubuntu приведёт к тому, что параметр просто проигнорируется.

Проверить, с какими параметрами загружена текущая система, можно без перезагрузки:

cat /proc/cmdline

BOOT_IMAGE=/vmlinuz-linux-zen root=UUID=27ae04c6-97fd-43ab-a885-dadc5ed8aa67 rw rootflags=subvol=@ loglevel=3 quiet

initramfs: формат и момент выполнения

initramfs — это cpio-архив (формат newc), обычно сжатый gzip, xz, zstd или lz4. Ядро распаковывает его в tmpfs/ramfs и запускает /init. Формат newc описан в документации ядра ⁸; заголовок каждого файла — 110 байт ASCII с hex-полями: магия 070701, inode, режим, uid, gid, число ссылок, mtime, размер, номера устройств, длина имени, контрольная сумма. После заголовка идёт имя, выровненное до четырёх байт, затем данные, тоже выровненные.

Образ может быть склейкой нескольких архивов. На рабочей машине файл /boot/initramfs-linux-zen.img начинается с несжатого cpio с микрокодом процессора, затем идёт выравнивание нулями, затем сжатый zstd основной архив:

file /boot/initramfs-linux-zen.img

/boot/initramfs-linux-zen.img: ASCII cpio archive (SVR4 with no CRC)

xxd -s 138301440 -l 16 /boot/initramfs-linux-zen.img

083e5000: 28b5 2ffd 0458 545c 062e e408 2720 4c10  (./..XT\....' L.

Байты 28 b5 2f fd — магия zstd. Это значит, что простой cpio -it покажет только первый архив и остановится на маркере TRAILER!!!:

cpio -it < /boot/initramfs-linux-zen.img | head

bin
early_cpio
kernel/
kernel/x86/
kernel/x86/microcode/
kernel/x86/microcode/GenuineIntel.bin
lib
lib64

Именно поэтому для работы с initramfs нужны инструменты, понимающие склейку: lsinitramfs и unmkinitramfs из initramfs-tools (Ubuntu), lsinitcpio и unmkinitcpio из mkinitcpio (Arch), lsinitrd из dracut. Каждый из них знает, где заканчивается один архив и начинается следующий, и умеет разжимать каждый по отдельности.

Устройство образа и порядок выполнения показаны на рисунке 2.

Изменение initramfs

Распаковка и сборка

На Ubuntu образ лежит в /boot/initrd.img-<версия> и собирается командой update-initramfs. Посмотреть содержимое и распаковать:

lsinitramfs /boot/initrd.img-$(uname -r) | head -20
sudo unmkinitramfs /boot/initrd.img-$(uname -r) /tmp/initrd-unpacked

unmkinitramfs создаёт каталог с подкаталогами early, main и, если есть, early2 — по числу архивов в склейке. Дальше образ собирается обратно тем же способом, каким его собирает система: cpio поверх каталога и сжатие. Ручная сборка полезна для понимания, но для правки штатного образа используется update-initramfs, потому что он добавляет в образ модули ядра и скрипты, без которых система не загрузится.

# Ручная сборка минимального образа из каталога
cd /tmp/initrd-unpacked/main
find . -print0 | cpio --null -o --format=newc --quiet | gzip -9 > /tmp/custom.img

Порядок файлов в cpio важен: /init должен существовать, а все каталоги, в которые будут монтироваться файловые системы, — тоже. Ядро не создаёт их автоматически.

Свой /init и что он видит

Простейшая демонстрация того, что initramfs исполняется до монтирования корня, — собственный статически собранный /init, который печатает маркер и выключает машину. Ниже он приведён целиком; это тот же код, который использовался для проверки вывода в этом разделе.

/* demo-init.c — минимальный init для initramfs */
#include <stdio.h>
#include <unistd.h>
#include <sys/mount.h>
#include <sys/reboot.h>

int main(void) {
    mount("proc", "/proc", "proc", 0, "");
    printf("[demo] initramfs: PID 1 running before root mount\n");
    printf("[demo] uid=%d, /proc mounted, no root filesystem\n", getuid());
    fflush(stdout);
    sync();
    reboot(RB_POWER_OFF);
    return 0;
}

Сборка и упаковка:

gcc -static -O2 -o demo-init demo-init.c
mkdir -p ir/{dev,proc,sys}
cp demo-init ir/init
cd ir && find . -print0 | cpio --null -o --format=newc --quiet | gzip -9 > ../demo.img

Запуск в QEMU с ядром рабочей системы:

qemu-system-x86_64 -kernel /boot/vmlinuz-linux-zen -initrd demo.img \
  -append "console=ttyS0 rdinit=/init panic=-1" \
  -nographic -no-reboot -m 256

Booting from ROM...
[    0.916070] virt/tdx: TDX not supported by the host platform
[demo] initramfs: PID 1 running before root mount
[demo] uid=0, /proc mounted, no root filesystem
[    1.815820] reboot: Power down

Строка [demo] напечатана процессом, который стал PID 1 до того, как ядро узнало что-либо о корневой файловой системе. Это и есть точка, в которой работает бэкдор уровня initramfs: код исполняется с правами root, без systemd, без журнала systemd, без профилей AppArmor, примонтированных из корня.

Отдельный формат — UKI (Unified Kernel Image): ядро, initramfs и командная строка упакованы в один PE-файл, который загружается как EFI-приложение напрямую, без GRUB. В этом случае initramfs собирается и подписывается вместе с ядром, а его правка ломает подпись. systemd-stub, который загружает такой образ, умеет измерять компоненты в TPM и передаёт их хеши в PCR; изменение любого компонента видно при аттестации ².

Практический вариант того же приёма на штатном образе — заменить /init или добавить скрипт, который выполняется до него. В initramfs-tools /init — это shell-скрипт, который последовательно запускает скрипты из /scripts по стадиям: init-top, init-premount, local-top, local-block, local-premount, local-bottom, init-bottom. Свой скрипт в /etc/initramfs-tools/scripts/init-premount/ попадёт в образ при следующей сборке и выполнится до монтирования корня.

Хук, срабатывающий по параметру ядра

Скрипт в initramfs получает параметры ядра через /proc/cmdline и может решать, вмешиваться или нет. Это делает правку условной: на обычной загрузке система ведёт себя как обычно, а нужное поведение включается только при конкретном параметре.

#!/bin/sh
# /etc/initramfs-tools/scripts/init-premount/zz-probe
set -eu

case "$(cat /proc/cmdline)" in
    *probe=1*)
        # Выполняется только при загрузке с параметром probe=1.
        printf 'probe: initramfs stage, uid=%s\n' "$(id -u)" >> /dev/kmsg
        # Здесь может быть запуск агента, чтение диска или монтирование
        # корня в обход обычной логики.
        ;;
esac

Сборка образа с хуком:

sudo install -m 0755 zz-probe /etc/initramfs-tools/scripts/init-premount/zz-probe
sudo update-initramfs -u -k all

Чтобы хук переживал обновления ядра, его кладут не в /etc/initramfs-tools/scripts, а в пакетный хук, который вызывается при каждой сборке initramfs. В Debian/Ubuntu это /etc/kernel/postinst.d/ — каталог скриптов, которые ядро запускает после установки:

# /etc/kernel/postinst.d/zz-repack
#!/bin/sh
set -eu
# Аргумент — версия устанавливаемого ядра.
install -m 0755 /usr/local/lib/probe /etc/initramfs-tools/scripts/init-premount/zz-probe
update-initramfs -u -k "$1"

Такой хук вызывается при каждом обновлении ядра и заново добавляет скрипт в свежесобранный образ. Пользовательские пакеты при этом не меняются, dpkg -V молчит, а journalctl не содержит ничего, потому что initramfs работает до systemd.

Почему это переживает обновления и что его ломает

Механизм живучести прост: initramfs — не пакетный файл, а результат сборки. Пакетный менеджер обновляет ядро и вызывает update-initramfs, а тот собирает образ из содержимого /etc/initramfs-tools и установленных модулей. Всё, что лежит в этих каталогах, попадает в новый образ автоматически. Поэтому правка «в образе» исчезнет после обновления, а правка «в хуке» — нет.

Границы приёма:

• Secure Boot не проверяет initramfs. shim проверяет GRUB, GRUB проверяет ядро, но образ initramfs по умолчанию не подписан и не проверяется. Поэтому тамперинг initramfs проходит на системе с включённым Secure Boot. Это не дыра в Secure Boot, а его задокументированная область ответственности: он защищает цепочку до ядра, а содержимое initramfs — уже нет.
• IMA appraisal ломает приём. Если включена целостная оценка IMA (ima_appraise=enforce) и политика требует подписи или хеша для исполняемых файлов, неподписанный /init или скрипт не выполнится. IMA работает на уровне отдельных файлов, а не образа целиком.
• Подписанный initramfs ломает приём. Некоторые дистрибутивы и hardened-сборки подписывают initramfs и проверяют подпись в загрузчике или через systemd-stub/UKI. В этом случае любая правка образа обнаруживается до его выполнения.
• Измерение в TPM ломает незаметность. Если загрузчик измеряет загруженные образы в PCR, изменение initramfs меняет хеш и видно в tpm2_pcrread и в аттестации. Приём продолжает работать, но перестаёт быть незаметным.
• lockdown в режиме confidentiality ограничивает /dev/mem, kexec и загрузку неподписанных модулей; на саму распаковку initramfs это не влияет, но сужает набор действий, которые из него можно выполнить.
• update-initramfs требует root. Без прав администратора изменить системный образ нельзя; остаётся собственный образ, загруженный вручную через QEMU или через отдельную загрузочную запись.

Временные метки

Четыре времени inode

В ext4 у каждого inode есть четыре отметки времени. Они хранятся как секунды Unix плюс наносекунды в дополнительных полях inode; для больших значений используется отдельное поле с старшими битами.

stat показывает первые три, statx — все четыре:

stat /etc/hostname
statx /etc/hostname 2>/dev/null || python3 -c 'import os; print(os.stat("/etc/hostname").st_birthtime)'

На файловых системах, где btime не поддерживается, statx вернёт флаг STATX_BTIME снятым, и поле будет пустым. На ext4 с включённой опцией metadata_csum и достаточно новым ядром btime доступно.

Ключевое свойство: atime и mtime пользователь может выставить произвольно, ctime — нет. Системный вызов utimensat(2) принимает массив из двух значений — для atime и mtime; попытка передать что-то для ctime невозможна, потому что поля для неё в аргументах нет. Ядро обновляет ctime само при любом изменении inode, включая сам вызов utimensat ⁴.

touch -d '2020-01-01 00:00:00' secret.txt
stat -c 'atime=%x mtime=%y ctime=%z' secret.txt

atime=2020-01-01 00:00:00.000000000 +0300 mtime=2020-01-01 00:00:00.000000000 +0300 ctime=2026-10-19 17:40:12.184637219 +0300

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

Подделка через debugfs

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

Проверка на образе ext4, созданном в файле (реальный вывод):

truncate -s 8M t.img
mkfs.ext4 -q -F t.img
debugfs -w -R "write /etc/hostname secret.txt" t.img
debugfs -R "stat /secret.txt" t.img | grep -E 'ctime|mtime|atime|crtime'

 ctime: 0x6ad62ada:00000000 -- Mon Oct 19 17:36:10 2026
 atime: 0x6ad62ada:00000000 -- Mon Oct 19 17:36:10 2026
 mtime: 0x6ad62ada:00000000 -- Mon Oct 19 17:36:10 2026
crtime: 0x6ad62ada:00000000 -- Mon Oct 19 17:36:10 2026

Теперь подделка всех трёх доступных полей:

debugfs -w -R "set_inode_field /secret.txt mtime 202001010000" t.img
debugfs -w -R "set_inode_field /secret.txt atime 202001010000" t.img
debugfs -w -R "set_inode_field /secret.txt ctime 202001010000" t.img
debugfs -R "stat /secret.txt" t.img | grep -E 'ctime|mtime|atime|crtime'

 ctime: 0x5e0be100:00000000 -- Wed Jan  1 03:00:00 2020
 atime: 0x5e0be100:00000000 -- Wed Jan  1 03:00:00 2020
 mtime: 0x5e0be100:00000000 -- Wed Jan  1 03:00:00 2020
crtime: 0x6ad62ada:00000000 -- Mon Oct 19 17:36:10 2026

ctime подделан, crtime — нет: время создания осталось исходным. Значение 202001010000 debugfs разобрал как UTC и записал 0x5e0be100, что соответствует 00:00 UTC 1 января 2020 года, то есть 03:00 по московскому времени. Это важно помнить: touch и debugfs могут интерпретировать строку времени по-разному.

Чтобы подделать и crtime, нужна отдельная команда:

debugfs -w -R "set_inode_field /secret.txt crtime 202001010000" t.img

Но у этого действия есть последствия, которых нет у touch. Во-первых, debugfs пишет в образ напрямую, и если файловая система смонтирована, ядро об этом не знает: кэш inode остаётся старым, а следующая запись в файл перезапишет подделанные поля. Работать надо на несмонтированном образе или на размонтированной файловой системе. Во-вторых, debugfs обновляет контрольные суммы inode, но не переписывает журнал: старые значения остаются в журнале ext4 и могут быть найдены при logdump. В-третьих, сама запись в блочное устройство оставляет след в истории команд, в auditd, а на системах с dm-verity — просто не пройдёт.

Что остаётся после подделки

Даже идеально подделанные atime, mtime, ctime и crtime не делают файл невидимым. Остаются:

• журнал ext4: старые значения inode и записи о выделении блоков;
• btime соседних файлов: если файл создан в каталоге, где все остальные файлы имеют дату установки системы, а он — 2020 год, это аномалия сама по себе;
• размер и права: подделка меток не меняет size, mode, uid;
• содержимое: хеш файла сравнивается с манифестом пакета (dpkg -V, rpm -Va) или с базой AIDE;
• ctime каталога: создание и удаление файла меняет mtime и ctime каталога, и эти метки подделать сложнее, потому что их много;
• резервные копии и снапшоты: если система делает снапшоты, старая версия файла сохраняется.

Отсюда практический вывод для обнаружения: сравнивать надо не одну метку с другой, а файл с его окружением и с эталоном. ctime > mtime — быстрый фильтр, но не доказательство; отсутствие аномалии — тоже не доказательство чистоты.

Очистка журналов

wtmp, btmp, utmp, lastlog

Записи о сессиях ведутся в бинарных файлах со структурой struct utmp. Каждая запись — фиксированный набор полей: тип записи (ut_type), PID, идентификатор терминала, имя пользователя, имя хоста, время (ut_tv). Типы, которые важны для разбора: USER_PROCESS (7) — вход, DEAD_PROCESS (8) — завершение, BOOT_TIME (2) — загрузка, RUN_LVL (1) — смена уровня выполнения.

Файлы:

Просмотр и правка — через utmpdump, который превращает бинарный файл в текст и обратно. Реальный вывод:

utmpdump /var/log/wtmp | tail -4

[7] [09531] [ts/5] [noviui  ] [pts/5       ] [:1                  ] [0.0.0.0        ] [2026-10-19T12:22:21,410925+00:00]
[8] [03166] [ts/5] [noviui  ] [pts/5       ] [                    ] [0.0.0.0        ] [2026-10-19T12:27:35,045929+00:00]
[7] [15068] [ts/5] [noviui  ] [pts/5       ] [:1                  ] [0.0.0.0        ] [2026-10-19T12:49:01,139258+00:00]
[7] [23101] [ts/6] [noviui  ] [pts/6       ] [:1                  ] [0.0.0.0        ] [2026-10-19T13:21:37,396514+00:00]

Поля читаются слева направо: тип, PID, терминал, пользователь, tty, хост, адрес, время в ISO 8601 с микросекундами. Удалить конкретную сессию можно, отфильтровав текстовое представление и загрузив его обратно:

utmpdump /var/log/wtmp > /tmp/wtmp.txt
grep -v 'noviui' /tmp/wtmp.txt > /tmp/wtmp-clean.txt
utmpdump -r /tmp/wtmp-clean.txt > /var/log/wtmp

Обратная операция (-r) читает текст и пишет бинарный файл. Формат полей и типы записей описаны в utmp(5) ¹. Работает она только на размонтированном или корректно открытом файле; на живой системе wtmp постоянно дописывается, и правка «на месте» может быть перезаписана следующей записью. Кроме того, удаление записи не удаляет её из резервных копий, из journalctl (там свои записи о сессиях) и с удалённого сервера, если журналы туда отправляются.

journald, запечатанные записи и --verify

systemd-journald хранит журнал в бинарном формате в /var/log/journal/<machine-id>/ (или в /run/log/journal, если постоянное хранилище отключено). Записи состоят из полей: _PID, _UID, _COMM, _EXE, _SYSTEMD_UNIT, MESSAGE, __REALTIME_TIMESTAMP, __SEQNUM. Поле __SEQNUM — порядковый номер записи; он монотонно растёт и позволяет обнаружить пропуск.

Проверка целостности:

journalctl --verify
journalctl --verify --file /var/log/journal/*/system.journal

--verify проверяет контрольные суммы и структуру файлов; формат журнала и его поля описаны в документации systemd ². Он не обнаружит аккуратно удалённый файл целиком, но обнаружит повреждение или обрыв записи. Если включено запечатывание (Seal=yes в /etc/systemd/journald.conf), каждая запись содержит HMAC, и подделка требует ключа; ключи создаются командой journalctl --setup-keys и хранятся отдельно. Проверка запечатанного журнала:

journalctl --verify --verify-key=$(cat /var/lib/systemd/journal-verify-key 2>/dev/null)

На практике запечатывание включают редко, потому что оно требует хранения ключа вне машины. Более распространённая защита — отправка журнала на внешний сервер:

# на клиенте, /etc/systemd/journald.conf
[Journal]
Storage=persistent
ForwardToSyslog=no

# на сервере
sudo systemctl enable --now systemd-journal-remote.socket

С удалённым журналом локальная очистка не имеет смысла: записи уже ушли по сети. Обнаружить отправку можно по открытому порту 19532/tcp, по конфигурации systemd-journal-upload, по исходящим соединениям в ss и по юнитам systemd-journal-upload.service.

Что остаётся после очистки

• Порядковые номера. Пропуск __SEQNUM в локальном журнале виден при экспорте (journalctl -o export).
• Размер и даты файлов. Удаление старых журналов меняет mtime каталога; journalctl --disk-usage показывает непропорционально малый объём.
• wtmp и journalctl вместе. Записи о сессии есть в двух местах; чистка одного оставляет другое.
• auth.log/secure. Если rsyslog пишет текстовые логи параллельно journald, запись остаётся там.
• auditd. События аудита пишутся отдельно и переживают чистку journald, если аудит настроен.
• Удалённый сервер. Самое надёжное хранилище — то, к которому у атакующего нет доступа.

Обнаружение и защита

Инвентаризация загрузки

Проверка начинается с чтения того, что реально загружено, и сравнения с эталоном:

cat /proc/cmdline
ls -la /boot
sha256sum /boot/vmlinuz-* /boot/initrd.img-* 2>/dev/null
lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'scripts|hooks|init$'
sudo grep -R "probe=\|rdinit=\|init=" /etc/default/grub /etc/grub.d/ 2>/dev/null

lsinitramfs с фильтром показывает, какие скрипты попали в образ. Если в списке есть файл, которого нет в пакете (dpkg -S не находит), это повод распаковать образ и прочитать его.

Сравнение с эталоном — единственный способ поймать аккуратную правку. Эталоном может быть хеш, снятый при установке, база AIDE/Tripwire или манифест пакета:

sudo aide --check
sudo debsums -s linux-image-$(uname -r) 2>/dev/null
sudo dpkg -V

debsums и dpkg -V проверяют файлы пакетов, но не проверяют initramfs: он не является файлом пакета. Поэтому хеш /boot/initrd.img-* надо хранить отдельно, а лучше — на другой машине.

Признаки timestomping

Быстрый фильтр по аномалии меток:

find / -xdev -type f -newermt '2020-01-01' ! -newermt '2020-01-02' -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | head

Файлы, у которых mtime старый, а ctime свежий, ищутся скриптом:

#!/usr/bin/env python3
"""Ищет файлы, у которых ctime заметно новее mtime."""
import os
import sys

root = sys.argv[1] if len(sys.argv) > 1 else "."
threshold = 86400 * 30

for dirpath, dirnames, filenames in os.walk(root):
    dirnames[:] = [d for d in dirnames if d not in (".git", "proc", "sys", "dev")]
    for name in filenames:
        path = os.path.join(dirpath, name)
        try:
            st = os.lstat(path)
        except OSError:
            continue
        if st.st_ctime - st.st_mtime > threshold:
            print(f"{st.st_ctime - st.st_mtime:>10.0f} {path}")

Скрипт не доказывает подделку: ctime обновляется при chmod, chown, переименовании и смене прав, поэтому расхождение может быть штатным. Он даёт список для ручной проверки.

Полный разбор образа без монтирования — задача криминалистических инструментов: sleuthkit (fls, istat) показывает inode и списки каталогов, debugfs — поля конкретного inode. Порядок действий при таком разборе — сначала снять копию образа, потом анализировать копию, сохраняя исходник нетронутым ⁵.

На несмонтированном образе метки читаются через debugfs:

sudo debugfs -R "stat /path/in/image" /dev/sdX1
sudo debugfs -R "logdump -a" /dev/sdX1 | grep -i 'ctime\|mtime'

Оба класса приёмов — изменение кода до загрузки ОС и подделка следов — описаны в модели MITRE ATT&CK как техники T1542 (Pre-OS Boot) и T1070.006 (Indicator Removal: Timestomp) ⁶.

Матрица «приём — признак — контрмера»

Что ломает приём целиком

• Secure Boot с подписанным initramfs и UKI — образ проверяется до выполнения.
• IMA appraisal в режиме enforce — неподписанные файлы не исполняются.
• Измеряемая загрузка (TPM PCR 9/12) — изменение образа видно при аттестации.
• dm-verity на корне — прямой доступ к блочному устройству не даёт изменить данные незаметно.
• Только чтение /boot — смонтированный read-only раздел не даёт пересобрать образ без перемонтирования.
• Отсутствие root — все приёмы темы требуют прав администратора на своей машине.

Итоги темы

Загрузка Linux — последовательность доверия, а не монолит. Прошивка доверяет подписи shim, shim — подписи GRUB, GRUB — подписи ядра; initramfs в эту цепочку по умолчанию не входит. Именно поэтому изменение initramfs — самый долгоживущий приём темы: он исполняется до systemd, до журналов, до профилей безопасности и переживает обновления пакетов, если правка сделана не в образе, а в хуке, который этот образ собирает.

Вторая половина темы — про следы. В ext4 четыре времени, и пользовательские вызовы меняют только два; ctime и btime обновляет ядро. Прямая запись в inode через debugfs обходит это ограничение, но оставляет журнал, несоответствие crtime окружению и запись в аудите. Очистка журналов убирает записи из одного места и не убирает из другого: wtmp, journald, auth.log, auditd и удалённый сервер хранят одно и то же событие независимо.

Практический вывод: обнаружение строится не на одной метке и не на одном журнале, а на сравнении нескольких независимых источников. Хеш /boot вне машины, эталон AIDE, порядковые номера journald, crtime рядом с соседними файлами — каждый источник по отдельности слаб, вместе они дают картину.

Следующая тема опускается ещё ниже — в ядро и в сеть: как скрыть процесс от ps, а соединение — от ss, и почему user-mode сокрытие всегда оставляет щель, которую видно прямым системным вызовом.

Литература

1. The Linux man-pages project. — https://man7.org/linux/man-pages/
2. systemd. Документация systemd.unit, systemd.service, systemd.timer, journalctl. — https://www.freedesktop.org/software/systemd/man/
3. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
4. Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
5. NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006.
6. MITRE ATT&CK: Linux techniques. — https://attack.mitre.org/
7. Bovet D. P., Cesati M. Understanding the Linux Kernel. 3rd ed. — O'Reilly Media, 2005.
8. Linux Kernel Documentation. — https://docs.kernel.org/

Дополнительные материалы

Вопросы для самопроверки

1. Какие звенья цепочки загрузки проверяются подписью, а какие нет? Где в этой цепочке находится initramfs?
2. Чем init= отличается от rdinit=? Приведите пример, когда работает только второй.
3. Почему rd.break не действует на Ubuntu, а break=premount действует? От чего это зависит?
4. Почему grub.cfg не правят напрямую и что произойдёт с правкой при следующем update-grub?
5. Почему initramfs может быть склейкой нескольких cpio-архивов и как ведёт себя cpio -it на такой склейке?
6. Какой файл внутри initramfs исполняется первым и что произойдёт, если его удалить?
7. Почему правка в /etc/initramfs-tools/scripts переживает обновление ядра, а правка внутри образа — нет?
8. Чем опасен хук в /etc/kernel/postinst.d с точки зрения контроля целостности?
9. Почему Secure Boot не мешает изменить initramfs? Что нужно включить, чтобы помешал?
10. Что такое UKI и почему в нём правка initramfs ломает подпись?
11. Какие четыре времени хранит inode ext4 и какие из них может изменить пользовательский процесс?
12. Почему touch -d не меняет ctime и что произойдёт с ctime при следующем изменении файла?
13. Что делает debugfs при записи inode и какие следы остаются на диске?
14. Почему после подделки mtime и ctime время создания всё ещё выдаёт файл?
15. Как устроена запись struct utmp и что означает тип USER_PROCESS?
16. Что проверяет journalctl --verify и почему удаление целого файла журнала может остаться незамеченным?
17. Как по __SEQNUM обнаружить пропуск записей и где взять эталонную последовательность?
18. Какие независимые источники хранят информацию о входе пользователя в систему?

Глоссарий темы

Шпаргалка

Цепочка загрузки

cat /proc/cmdline                                   # параметры текущей загрузки
grep -E '^\s*(linux|initrd)' /boot/grub/grub.cfg    # пункты меню
grep -v '^#' /etc/default/grub                      # настройки загрузчика
sudo update-grub                                    # пересборка grub.cfg
mokutil --sb-state                                  # состояние Secure Boot

initramfs

lsinitramfs /boot/initrd.img-$(uname -r) | head     # содержимое
sudo unmkinitramfs /boot/initrd.img-$(uname -r) out # распаковка
sudo update-initramfs -u -k all                     # пересборка
(cd dir && find . -print0 | cpio --null -o --format=newc --quiet | gzip -9 > ../img)

QEMU без диска

qemu-system-x86_64 -kernel /boot/vmlinuz-$(uname -r) -initrd demo.img \
  -append "console=ttyS0 rdinit=/init panic=-1" -nographic -no-reboot -m 256

Метки времени

stat -c 'atime=%x mtime=%y ctime=%z' file
touch -d '2020-01-01 00:00:00' file
debugfs -R "stat /file" t.img
debugfs -w -R "set_inode_field /file mtime 202001010000" t.img
debugfs -w -R "set_inode_field /file ctime 202001010000" t.img
debugfs -w -R "set_inode_field /file crtime 202001010000" t.img

Журналы

utmpdump /var/log/wtmp | tail
utmpdump /var/log/wtmp > /tmp/wtmp.txt
utmpdump -r /tmp/wtmp-clean.txt > /tmp/wtmp-clean.bin
last -F | head
journalctl --verify
journalctl -o export -n 5 | grep -E '__SEQNUM|__REALTIME'
journalctl --disk-usage

Типичные ошибки

Что почитать и посмотреть

• man 7 bootparam, man 5 initramfs-tools, man 8 update-initramfs, man 8 lsinitramfs — параметры ядра и инструменты initramfs в Ubuntu.
• man 5 utmp, man 1 utmpdump, man 1 last — формат записей о сессиях и работа с ними.
• man 8 debugfs, man 5 ext4 — структуры ext4 и прямой доступ к inode.
• Linux Kernel Documentation. — https://docs.kernel.org/ — разделы об initramfs, ramfs-rootfs-initramfs, об IMA и lockdown.
• systemd. Документация. — https://www.freedesktop.org/software/systemd/man/ — systemd-stub, journalctl, systemd-journald.
• NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006. — порядок снятия копии и анализа образа.
• MITRE ATT&CK: T1542 Pre-OS Boot, T1070.006 Timestomp. — https://attack.mitre.org/ — классификация приёмов.
• The Sleuth Kit. — https://www.sleuthkit.org/ — fls, istat, icat для разбора образов без монтирования.

Углубление

Почему Secure Boot заканчивается на ядре

Secure Boot — это контракт между прошивкой и загрузчиком: прошивка проверяет подпись EFI-приложения, shim проверяет подпись GRUB, GRUB проверяет подпись ядра. Initramfs в этот контракт не входит: это не исполняемый файл в понимании прошивки, а данные, которые ядро распаковывает в память. Проверять их подпись должен либо сам загрузчик (если умеет), либо ядро через IMA, либо UKI, где initramfs упакован внутрь подписанного PE-файла.

Отсюда распространённое заблуждение: «Secure Boot включён, значит загрузка защищена». Защищена цепочка до ядра; содержимое initramfs — нет. Именно поэтому в hardened-сборках initramfs подписывают отдельно или переходят на UKI с измерением в TPM.

Что именно измеряется в TPM

При измеряемой загрузке каждый компонент хешируется и записывается в PCR. Для initramfs обычно используется PCR 9 (загрузка через GRUB) или PCR 12 (UKI/systemd-stub), а также PCR 4–7 для событий загрузки. Хеш зависит от содержимого образа, поэтому любая правка меняет итоговое значение. Аттестация сравнивает текущие значения PCR с эталонными; расхождение означает, что загрузка отличалась.

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

Журнал ext4 и что в нём остаётся

ext4 ведёт журнал (journal), в который перед изменением метаданных попадают блоки inode и битмапы. После подделки inode через debugfs в журнале остаются записи о старых значениях и о выделении блоков. Посмотреть журнал можно так:

sudo debugfs -R "logdump -a" /dev/sdX1 | head -50

logdump показывает транзакции и блоки; для разбора нужен опыт, но сам факт наличия записей о файле, который «не менялся с 2020 года», — уже сигнал. Полноценный разбор образа удобнее делать sleuthkit: fls показывает список файлов с inode, istat — все поля inode, icat — содержимое по inode. Работать надо с копией образа, снятой побайтово, а исходник хранить нетронутым.

Как отличить подделку от штатного изменения

Штатные операции тоже меняют ctime: chmod, chown, setfacl, переименование, создание жёсткой ссылки. Поэтому ctime > mtime — только повод посмотреть. Отличают подделку по совокупности:

• crtime не соответствует окружению (файл «создан» раньше, чем каталог, или раньше установки системы);
• mtime и atime совпадают с точностью до секунды у файлов, которые менялись в разное время;
• размер и содержимое не соответствуют заявленному возрасту (бинарник ссылается на библиотеки, которых не было в 2020 году);
• в журнале ext4 есть записи о файле после заявленной даты;
• хеш не совпадает с манифестом пакета;
• рядом лежат файлы с датами установки, а «старый» файл выбивается из ряда.

Ни один признак по отдельности не доказывает подделку; вместе они дают картину, которую можно защищать в отчёте.

Лабораторная работа 6. До начала времён

• Раздел курса: апокриф 6 «Тамперинг загрузчика и Timestomping»

Введение

Работа состоит из восьми частей и идёт от наблюдения к построению, а затем к следам. Сначала читатель разбирает цепочку загрузки своей машины: что записано в /proc/cmdline, как устроен grub.cfg, какие образы перечислены в initrd и что реально лежит внутри initramfs. Затем собирает собственный минимальный initramfs с программой на C, которая становится PID 1 до монтирования корня, и загружает его в QEMU, чтобы увидеть это своими глазами. После этого — условный запуск по параметру ядра и штатный механизм хуков initramfs-tools.

Вторая половина работы — про следы. Читатель подделывает временные метки файла двумя способами: через touch, который меняет mtime и оставляет свежий ctime, и через debugfs, который меняет всё, кроме crtime, и оставляет журнал файловой системы. Затем разбирает бинарные журналы сессий: utmpdump, порядковые номера journald, проверка целостности. Завершается работа скриптом обнаружения и уборкой.

Базовая часть выполняется от обычного пользователя: разбор цепочки, сборка своего initramfs, запуск QEMU, работа с образом ext4 в файле и чтение журналов не требуют root. Части, где нужны системные хуки initramfs, update-initramfs и правка /boot, выполняются в собственной виртуальной машине через sudo и помечены. Продвинутые задания необязательны.

Цель работы

После выполнения работы получится:

• читать цепочку загрузки: параметры ядра, пункты меню GRUB, состав initramfs;
• отличать init=, rdinit= и break= и объяснять, на какой стадии действует каждый;
• собрать собственный initramfs с программой на C в роли PID 1 и загрузить его в QEMU;
• сделать поведение initramfs условным, привязанным к параметру ядра;
• объяснять, почему правка в хуке переживает обновление ядра, а правка в образе — нет;
• подделывать atime, mtime, ctime через debugfs и объяснять, что при этом остаётся;
• читать и фильтровать wtmp через utmpdump, проверять целостность journald;
• находить аномалии меток скриптом и отличать признак от доказательства.

Теоретический минимум

Нужны разделы «Цепочка загрузки и её звенья», «Изменение initramfs», «Временные метки» и «Очистка журналов» темы 6. Дополнительно используются темы 3 (файлы и inode), 4 (права), 7 (журналы), 11 (systemd) и 16 (резервное копирование) основной программы.

Перечень оснащения

Ubuntu 24.04 LTS или WSL2, пакеты gcc, libc6-dev, cpio, gzip, qemu-system-x86, e2fsprogs, util-linux, initramfs-tools. Архив окружения lr-env содержит программу init.c, сборщик build-image.sh, генератор образа ext4 forge-times.sh, скрипт поиска аномалий find-timestomp.py и уборку cleanup.sh. Распакуйте архив в ~/lab-apocrypha-06.

sudo apt update && sudo apt install -y gcc libc6-dev cpio gzip qemu-system-x86 e2fsprogs util-linux

Для частей 4 и 6 в виртуальной машине дополнительно нужен initramfs-tools (обычно уже установлен) и auditd, если планируется проверка правил аудита.

Порядок выполнения работы

Работайте в каталоге ~/lab-apocrypha-06. Для каждой части в «Журнале работы» фиксируйте: что ожидалось, что получилось, чем объясняется расхождение. Команды с sudo выполняются только на собственной виртуальной машине.

Меры предосторожности

QEMU запускается без дисков: в командной строке нет ни -drive, ни -hda, ни -hdb. Это значит, что виртуальная машина не может прочитать или изменить ни одну файловую систему, кроме содержимого demo.img. Не добавляйте диски «для интереса»: загрузка с rdinit=/init в образе, который умеет монтировать корень, — это уже работа с реальными данными. Все команды, меняющие /boot, /etc или /var/log, выполняются только в одноразовой виртуальной машине и только через sudo.

Подготовка

cd ~/lab-apocrypha-06
bash build-image.sh --no-run
ls -la demo.img

Скрипт компилирует init.c статически, собирает каталог ir/ с минимальным набором каталогов и упаковывает его в demo.img формата cpio+gzip. Запуск QEMU в этом шаге отключён флагом --no-run.

Часть 1. Разбор цепочки загрузки

Задание

1. Прочитайте параметры текущей загрузки и объясните каждый:

   cat /proc/cmdline
   

2. Найдите в конфигурации загрузчика строки linux и initrd и выпишите, какие образы перечислены:

   grep -E '^\s*(linux|initrd)' /boot/grub/grub.cfg | head -10
   

3. Посмотрите, что задано в /etc/default/grub, и сравните с тем, что реально в /proc/cmdline:

   grep -v '^#' /etc/default/grub | grep -v '^$'
   

4. Посмотрите первые строки содержимого initramfs:

   lsinitramfs /boot/initrd.img-$(uname -r) 2>/dev/null | head -20
   

5. Снимите хеши загрузочных файлов и сохраните их как эталон:

   sha256sum /boot/vmlinuz-$(uname -r) /boot/initrd.img-$(uname -r) | tee ~/boot-baseline.sha256
   

6. Объясните, какие звенья цепочки проверяются подписью, а какие нет. Для проверки состояния Secure Boot:

   mokutil --sb-state 2>/dev/null || echo 'mokutil не установлен'
   

Что должно получиться

В журнале — таблица: звено цепочки, файл, чем проверяется, что произойдёт при изменении. Отдельно — вывод lsinitramfs с первыми строками и сохранённый файл boot-baseline.sha256. Вывод mokutil может быть любым; важно записать фактическое состояние.

Часть 2. Собственный initramfs в QEMU

Задание

1. Прочитайте init.c из архива. Найдите, где программа монтирует /proc и где выключает машину.

2. Соберите образ и запустите его в QEMU:

   bash build-image.sh
   

   Скрипт выполняет команды:

   gcc -static -O2 -o demo-init init.c
   mkdir -p ir/{dev,proc,sys}
   cp demo-init ir/init
   (cd ir && find . -print0 | cpio --null -o --format=newc --quiet | gzip -9 > ../demo.img)
   qemu-system-x86_64 -kernel /boot/vmlinuz-$(uname -r) -initrd demo.img \
     -append "console=ttyS0 rdinit=/init panic=-1" -nographic -no-reboot -m 256
   

3. Запишите вывод последовательной консоли. Найдите в нём строку, которую печатает ваша программа.

4. Объясните, почему в этой загрузке нет ни systemd, ни /etc, ни корневой файловой системы, и почему процесс всё равно работает с правами root.

5. Проверьте, что диск машины не подключён: в команде QEMU нет ни одного -drive и ни одного -hda. Это принципиально: загрузка идёт только с initramfs.

Что должно получиться

Вывод, содержащий строку [demo] initramfs: PID 1 running before root mount и uid=0. В журнале — объяснение, что ядро распаковало demo.img в ramfs и запустило /init из него, не монтируя никакой диск.

Часть 3. Условный запуск по параметру ядра

Задание

1. В init.c уже есть проверка /proc/cmdline на подстроку probe=1. Найдите её и объясните, как программа читает файл.

2. Загрузите образ без параметра и с параметром, сравните вывод:

   bash build-image.sh --run --no-probe
   bash build-image.sh --run --probe
   

3. Сделайте поведение заметным: добавьте в ветку probe=1 вывод дополнительной строки с текущим временем (используйте time() и ctime()), пересоберите и сравните два запуска.

4. Объясните, почему такая проверка делает правку незаметной при обычной загрузке и почему она не помогает, если защитник читает /proc/cmdline уже в работающей системе.

Что должно получиться

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

Часть 4. Штатный initramfs и хуки

Задание

Выполняется в виртуальной машине с Ubuntu, нужен sudo.

1. Распакуйте штатный образ и найдите /init:

   mkdir -p /tmp/initrd && cd /tmp/initrd
   sudo unmkinitramfs /boot/initrd.img-$(uname -r) .
   ls
   head -30 main/init 2>/dev/null || head -30 init
   

2. Посмотрите, какие скрипты и хуки уже есть в образе:

   lsinitramfs /boot/initrd.img-$(uname -r) | grep -E '/(scripts|hooks|conf)/' | head -20
   

3. Добавьте собственный хук, который только пишет строку в /dev/kmsg, и пересоберите образ:

   sudo tee /etc/initramfs-tools/scripts/init-premount/zz-probe >/dev/null <<'EOF'
   #!/bin/sh
   set -eu
   case "$(cat /proc/cmdline)" in
       *probe=1*) echo "probe: initramfs stage reached" > /dev/kmsg ;;
   esac
   EOF
   sudo chmod 0755 /etc/initramfs-tools/scripts/init-premount/zz-probe
   sudo update-initramfs -u -k all
   lsinitramfs /boot/initrd.img-$(uname -r) | grep zz-probe
   

4. Убедитесь, что хеш образа изменился по сравнению с эталоном из части 1:

   sha256sum -c ~/boot-baseline.sha256 2>&1 | head
   

5. Удалите хук, пересоберите образ и верните хеш к исходному состоянию (сравните с эталоном; полное совпадение не гарантируется, если обновились модули, — объясните почему).

Что должно получиться

Хук виден в lsinitramfs, хеш образа изменился, проверка по эталону сообщает о расхождении. В журнале — объяснение, почему dpkg -V при этом молчит: initramfs не является файлом пакета.

Продвинутая часть

Соберите хук, который не просто пишет в /dev/kmsg, а монтирует корневую файловую систему в отдельный каталог и читает оттуда файл, не передавая управление штатному /init. Объясните, почему такой хук не виден в journalctl и какие следы он всё же оставляет — в /proc/cmdline, в порядке монтирования, в dmesg.

Часть 5. Timestomping: touch и debugfs

Задание

1. Создайте файл и подделывайте метку через touch:

   cd ~/lab-apocrypha-06
   mkdir -p work && cd work
   printf 'payload\n' > secret.txt
   touch -d '2020-01-01 00:00:00' secret.txt
   stat -c 'atime=%x mtime=%y ctime=%z' secret.txt
   

2. Объясните, почему ctime остался сегодняшним и можно ли его изменить через touch.

3. Создайте образ ext4 в файле и подделайте все три поля через debugfs:

   bash ../forge-times.sh
   

   Скрипт создаёт t.img, записывает в него файл, печатает stat до и после подделки.

4. Сравните crtime до и после. Объясните, почему время создания не изменилось и как его изменить.

5. Проверьте, что произойдёт, если подделать метку на смонтированной файловой системе: создайте файл в work, подделайте ему mtime, затем измените содержимое и посмотрите на ctime снова.

Что должно получиться

Вывод stat с подделанным mtime и свежим ctime для touch; вывод debugfs с подделанными atime, mtime, ctime и неизменным crtime. В журнале — таблица «поле — чем меняется — что остаётся».

Продвинутая часть

Посмотрите журнал ext4 в образе и найдите записи, относящиеся к файлу:

debugfs -R "logdump -a" work/t.img 2>/dev/null | head -40

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

Часть 6. Журналы сессий

Задание

1. Посмотрите последние записи wtmp и объясните поля:

   utmpdump /var/log/wtmp 2>/dev/null | tail -5
   

2. Сделайте копию, отфильтруйте одну запись и соберите файл обратно — только в копии, не трогая оригинал:

   utmpdump /var/log/wtmp > /tmp/wtmp.txt
   grep -v "$USER" /tmp/wtmp.txt > /tmp/wtmp-clean.txt
   utmpdump -r /tmp/wtmp-clean.txt > /tmp/wtmp-clean.bin
   utmpdump /tmp/wtmp-clean.bin | wc -l
   wc -l /tmp/wtmp.txt
   

3. Сравните число записей и объясните, что изменится для last, если подменить оригинал.

4. Проверьте целостность журнала systemd:

   journalctl --verify 2>&1 | tail -5
   journalctl -o export -n 3 | grep -E '__SEQNUM|__REALTIME' | head
   

5. Объясните, как по __SEQNUM обнаружить пропуск записей.

Что должно получиться

Разобранный вывод utmpdump, копия с удалённой записью и разницей в количестве строк, вывод journalctl --verify. В журнале — объяснение, какие ещё источники хранят ту же информацию о сессии.

Продвинутая часть

Выгрузите журнал в формате export за интересующий интервал и найдите разрыв в __SEQNUM:

journalctl -o export --since '1 hour ago' > /tmp/journal.export
grep '^__SEQNUM=' /tmp/journal.export | awk -F= '{print $2}' | sort -n | awk 'NR>1 && $1!=prev+1 {print "разрыв:", prev, "->", $1} {prev=$1}'

Объясните, какие причины разрыва возможны кроме удаления записей, и почему вывод не доказывает вмешательство.

Часть 7. Обнаружение

Задание

1. Запустите скрипт поиска аномалий на учебном каталоге:

   python3 find-timestomp.py work
   

2. Добавьте в work файл с подделанным mtime и убедитесь, что скрипт его показывает. Затем объясните, почему файл может попасть в список и без подделки (например, после chmod).

3. Соберите эталон и проверьте его:

   sha256sum work/* > work.sha256
   sha256sum -c work.sha256
   

4. Дополните таблицу обнаружения: для каждой выполненной в работе правки — команда, которой она находится.

5. Проверьте, что осталось от ваших действий в системе: найдите файлы, изменённые за последний час, в /etc и /boot (только чтение).

Что должно получиться

Список аномалий с объяснением каждой строки, рабочий эталон хешей, заполненная таблица обнаружения. В журнале — вывод, какие признаки являются косвенными, а какие — прямыми.

Продвинутая часть

Сравните список файлов initramfs с содержимым пакетов: для каждого пути из lsinitramfs проверьте, принадлежит ли он пакету (dpkg -S), и выпишите те, для которых владелец не найден. Объясните, почему часть файлов образа законно не принадлежит ни одному пакету (модули ядра, сгенерированные скрипты) и как отличить их от посторонних.

Часть 8. Уборка

Задание

1. Удалите учебные файлы и временные каталоги:

   bash cleanup.sh
   

2. В виртуальной машине удалите хук initramfs и пересоберите образ:

   sudo rm -f /etc/initramfs-tools/scripts/init-premount/zz-probe
   sudo update-initramfs -u -k all
   

3. Убедитесь, что в образе не осталось вашего скрипта:

   lsinitramfs /boot/initrd.img-$(uname -r) | grep zz-probe || echo 'чисто'
   

4. Проверьте, что ~/boot-baseline.sha256 не ссылается на удалённые файлы, и объясните, почему после пересборки хеш может отличаться от исходного даже без вашего хука.

Что должно получиться

Чистый каталог лабораторной, отсутствие хука в образе, объяснение расхождения хешей после пересборки.

Журнал работы

Для каждой части запишите:

1. Что предполагалось увидеть до выполнения команды.
2. Фактический вывод (ключевые строки).
3. Объяснение расхождения.
4. Для частей 2–6 — как это выглядит для защитника: какой командой находится, какой признак выдаёт.

Отдельно ответьте на три вопроса:

• Какая из выполненных правок переживёт обновление ядра, а какая — нет, и почему?
• Почему подделка ctime через debugfs не делает файл невидимым?
• Какие два независимых источника хранят запись о вашем входе в систему?

Контрольные вопросы

1. Чем init= отличается от rdinit= и на какой стадии загрузки действует каждый?
2. Почему rd.break не работает на Ubuntu с initramfs-tools и что использовать вместо него?
3. Что проверяет Secure Boot, а что остаётся непроверенным, и как это соотносится с initramfs?
4. Почему образ initramfs может быть склейкой нескольких cpio-архивов и как это влияет на cpio -it?
5. Почему правка в /etc/initramfs-tools/scripts переживает обновление ядра, а правка внутри /boot/initrd.img-* — нет?
6. Что делает хук в /etc/kernel/postinst.d и почему он опасен с точки зрения целостности?
7. Почему ctime нельзя изменить через utimensat, но можно через debugfs?
8. Что происходит с crtime при подделке остальных меток и как его изменить?
9. Какие следы остаются в журнале ext4 после записи через debugfs?
10. Почему utmpdump -r на живой системе может не дать ожидаемого результата?
11. Что проверяет journalctl --verify и чего он не проверяет?
12. Как по __SEQNUM обнаружить удаление записей журнала?
13. Какие три независимых источника хранят информацию о входе пользователя?
14. Почему ctime > mtime — признак, а не доказательство подделки?