Переписать историю: манипуляции с логами и временем в Linux

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

Журналы — это не истина в последней инстанции

Файл в /var/log — конечный продукт, а не сырые данные. События проходят через целый конвейер фильтрации: ядро, подсистема аудита, демон журналирования, правила форматирования. На каждом этапе что-то может быть потеряно или искажено. То, что вы читаете, — уже интерпретация системой низкоуровневых вызовов. Именно поэтому атака на логи — это не только их удаление, но и тонкая подмена, инъекция ложных событий и искажение временной шкалы, что делает восстановление реальной картины инцидента невозможным.

Уровень 1: Перехват на источнике — подмена подсистемы аудита ядра

Демон auditd — не единственный потребитель событий ядра. Можно загрузить собственный модуль, который будет перехватывать системные вызовы (например, execve, connect) ещё до того, как о них узнает штатный механизм аудита. Такой модуль может бесшумно отбрасывать события по заданным критериям: имени процесса, UID или другим атрибутам.

Для систем с включённым Secure Boot модуль должен быть корректно подписан с использованием Machine Owner Key (MOK) или встроен в образ ядра. Для средств контроля целостности на уровне пользователя он остаётся невидимым. Демон auditd продолжает работать, но видит уже отфильтрованную реальность.

Более простой, но менее надёжный метод — использование встроенных возможностей auditd. Добавление правила с флагом -exclude для определённого ключа или пользователя заставит подсистему игнорировать связанные события на самом раннем этапе. Такие записи не появятся даже во внутреннем буфере.

Уровень 2: Манипуляция временной осью

Корреляция событий по времени — основа расследования. Но системное время — абстракция, уязвимая для манипуляций.

Постепенный дрейф времени. Вместо резкого сдвига часов можно внедрить код (модуль ядра, модифицированный драйвер), который будет незаметно ускорять или замедлять системный счётчик. Расхождение в несколько миллисекунд в минуту за неделю создаёт разрыв в десятки минут. Это ломает корреляцию с записями NTP-серверов, журналами сетевого оборудования, системами контроля доступа. Обнаружить такой дрейф стандартными проверками сложно.
Контекстная подмена временной зоны. Многие утилиты (logger, скрипты с date) для форматирования времени полагаются на переменную окружения TZ. Запустив команду в среде с TZ=GMT+5, можно «отправить» её запись в логах на несколько часов вперёд или назад. Это создаёт ложные алиби или маскирует истинную последовательность действий.

[ИЗОБРАЖЕНИЕ: Схема, показывающая три оси: реальная временная шкала событий, шкала системных часов после дрейфа и временные метки в логах после применения манипуляции с TZ. Показаны расхождения между осями.]

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

Уровень 3: Прямое редактирование файлов журналов в обход логгеров

Демоны журналирования (rsyslogd, systemd-journald) держат файлы логов открытыми для записи. Прямая запись по пути /proc/[PID_demona]/fd/[номер_дескриптора] позволяет модифицировать данные на диске, минуя внутренние буферы и логику самого демона. Так можно точечно удалить или изменить строку, если точно соблюсти формат. Активные файловые дескрипторы можно найти командой lsof | grep /var/log.

Более изящный способ — инъекция ложных записей через сокет демона (/dev/log для syslog). Сообщение, отправленное таким путём, пройдёт весь стандартный путь обработки: фильтрацию, форматирование, запись. Для большинства средств анализа оно будет неотличимо от легитимных записей.

Уровень 4: Легитимные инструменты как оружие

Зачем оставлять подозрительные скрипты, если можно использовать доверенные, встроенные утилиты?

Классический пример — logrotate. Его конфигурация в /etc/logrotate.d/ позволяет выполнять произвольные команды в секциях postrotate или prerotate. Добавив строку sed -i '/10.0.0.1/d' /var/log/auth.log.1, можно автоматически удалять упоминания определённого IP-адреса из архивного лога сразу после ротации. Для систем аудита это выглядит как штатная работа планировщика.

Аналогично, настройки самих демонов (rsyslog, journald) позволяют фильтровать сообщения по facility, приоритету или содержанию. Изменение конфигурации — легитимная операция, которая радикально меняет видимую картину происходящего.

Как обнаружить манипуляции: точки контроля

Вектор атаки	Механизм	Возможный артефакт для обнаружения
Прямая запись в файл	Запись через `/proc/pid/fd/X`	Расхождение размера файла (st_size) с данными в индексе демона; несоответствие контрольных сумм (AIDE, Wazuh).
Инъекция в очередь	Отправка сообщений в `/dev/log`	Записи от процессов без иных системных событий; аномальная последовательность PID или временных меток.
Фильтрация в auditd	Правила с `-exclude`	Несанкционированные изменения в `/etc/audit/rules.d/`; отсутствие событий для действий, обязательных по политике.
Манипуляция временем	Дрейф часов, изменение TZ	Расхождения между системным временем и аппаратными часами (RTC); аномалии в логах NTP; скачки временных меток в последовательных записях.

Уровень 5: Компрометация конвейера сбора

Централизованный сбор в SIEM создаёт точку консолидации и уязвимости. Скомпрометировав агент на хосте (rsyslog, fluentd), можно фильтровать или менять данные до отправки. Это эффективнее атаки на каждый сервер по отдельности.

Если транспорт не защищён (обычный syslog по UDP/TCP без TLS), возможна атака на сетевом уровне. При доступе к коммутатору можно использовать ARP-spoofing для перехвата и выборочного удаления пакетов с логами. Для SIEM это будет выглядеть как рядовая сетевая потеря.

Почему эти методы работают

Системы мониторинга построены на доверии к источнику данных. Они проверяют доступ к файлам логов, но не анализируют целостность всей цепочки генерации события: от системного вызова в ядре → обработки подсистемой аудита → фильтрации демоном → записи на диск → передачи по сети. Каждое звено этой цепи — потенциальная точка для вмешательства.

Что невозможно скрыть полностью: альтернативные артефакты

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

Журналы систем контроля целостности (HIDS/FIM). Инструменты вроде Wazuh или Osquery могут вести независимые журналы изменений файлов и процессов, передавая их по защищённому каналу.
Сетевые метаданные. Межсетевые экраны, системы предотвращения вторжений или коммутаторы с NetFlow логируют сессии и соединения, невидимые на хосте.
Метаданные файловой системы. Прямое редактирование файла через дескриптор изменит время его последней модификации (mtime). Необъяснимое изменение mtime у лога вне расписания ротации — косвенный признак.
Артефакты в памяти (RAM). Следы процессов, сетевых сокетов, загруженных модулей ядра могут быть извлечены из дампа памяти, если реагирование происходит до выключения системы.
Аппаратные журналы. Логи серверного оборудования (BMC, iDRAC), включающие события питания, перезагрузок и доступа к консоли, независимы от гостевой ОС.

[ИЗОБРАЖЕНИЕ: Диаграмма, показывающая альтернативные источники артефактов (HIDS, сетевые устройства, метаданные ФС, память, BMC) как независимые точки верификации против скомпрометированного системного логгирования.]

Стратегия защиты: от пассивного сбора к активной верификации

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

Многоуровневое и разнородное журналирование. Собирайте данные не только с ОС, но и с гипервизоров, сетевых устройств, систем контроля целостности. Атаковать все эти разнородные источники одновременно сложнее, чем одну точку сбора.
Непрерывный контроль целостности цепочки. Мониторьте не только файлы логов, но и конфигурации демонов, загруженные модули ядра, системное время и его источники. Любое изменение должно генерировать алерт.
Защищённый и аутентифицированный транспорт. Передача логов должна использовать шифрование (TLS) и взаимную аутентификацию (клиентские сертификаты). Это исключает вмешательство на сетевом уровне.
Анализ аномалий и согласованности. Ищите не только сигнатуры, но и статистические отклонения: неожиданное падение объёма логов с хоста, разрывы в последовательностях ID событий, несоответствия временных меток между разными источниками.
Запись в неизменяемый журнал (WORM). Используйте возможности СХД или специализированных платформ для создания логов только для добавления (Write-Once Read-Many). Это аппаратный уровень защиты от изменений.

Итог: журналы — это не объективная реальность, а её интерпретация системой. Задача — постоянно подвергать эту интерпретацию сомнению, проверяя её на внутреннюю согласованность и сверяя с независимыми источниками. Безопасность — это архитектура, в которой ложь становится статистически маловероятной.