В 2026 году серия уязвимостей класса page-cache write вновь поставила под удар практически все актуальные дистрибутивы Linux. Их особенность в том, что злоумышленник может изменить содержимое файла в page cache , не затрагивая данные на диске. Из-за этого классические средства контроля целостности файлов не способны обнаружить такую компрометацию.
В этой статье рассмотрим две наиболее показательные уязвимости этого класса — Dirty Frag и Copy Fail, а затем настроим Wazuh так, чтобы он помогал выявлять признаки их эксплуатации и связанные с ними аномалии.
Классические уязвимости
Dirty Frag. Май 2026
Исследователь Hyunwoo Kim описал две независимые уязвимости в сетевом стеке ядра Linux, объединенные в общую цепочку эксплуатации. Первая затрагивает обработчик ESP (Encapsulating Security Payload) в xfrm, вторая — протокол RxRPC.
Цепочка эксплуатации использует механизм splice (file → pipe → socket) и флаг MSG_SPLICE_PAGES , позволяя атакующему подсадить в frag структуры sk_buff прямую ссылку на страницу page cache. В результате криптографический код выполняет запись непосредственно в память файла, несмотря на последующую ошибку проверки целостности.
Уязвимость существует с коммита cac2661c53f3 (январь 2017) — то есть, уже более девяти лет. Работает на ядрах от 6.12 до 7.0 и подтверждена на Ubuntu 24.04, RHEL 10.1, AlmaLinux 10, Fedora 44, openSUSE Tumbleweed. Для обеих уязвимостей назначены CVE: CVE-2026-43500 и CVE-2026-43284 .
Copy Fail, CVE-2026-31431. Апрель 2026
Исследователи Xint Code Research Team обнаружили аналогичную проблему в интерфейсе AF_ALG — криптографическом сокете ядра. Через splice() страницы page cache попадают в криптографический буфер, после чего операция дешифрования изменяет данные непосредственно в памяти. Для эксплуатации достаточно короткого Python-скрипта весом в 732 байта, использующего только стандартную библиотеку.
Уязвимость присутствует в ядре с 2017 года, затрагивает большинство популярных корпоративных дистрибутивов Linux и может использоваться в том числе для выхода из контейнера, поскольку page cache является общим для всего хоста.
Ключевая особенность обоих классов уязвимостей заключается в том, что стандартные инструменты контроля целостности (AIDE, Tripwire, sha256sum) не обнаружат атаку, потому что файл на диске не изменяется. Изменяется только его страница в оперативной памяти.
Ключевая особенность обоих классов уязвимостей заключается в том, что стандартные инструменты контроля целостности (AIDE, Tripwire, sha256sum) не обнаружат атаку, потому что файл на диске не изменяется. Изменяется только его страница в оперативной памяти.
Что Wazuh может и что не может
Важно сразу обозначить границы возможностей. Wazuh не является средством предотвращения эксплуатации ядра. Его задача — своевременно обнаружить подозрительную активность и дать время на реагирование. В случае с Dirty Frag и Copy Fail Wazuh помогает на нескольких уровнях:
Уровень защиты
Что отслеживается
Помогает обнаружить
Инвентаризация модулей
Список загруженных kmod, изменения с момента последней проверки
Persistence через вредоносные модули (rootkit)
Контроль версии ядра
Текущая версия ядра и факт обновления
Незакрытые CVE на уязвимых ядрах
Аудит syscall
Вызовы splice() , sendmsg() с необычными флагами, сокеты AF_ALG
Ранние признаки эксплойта
FIM для /proc и sysfs
Изменения в /proc/modules , /sys/module/
Динамическую загрузку модулей
SCA — проверка конфигурации
lockdown , module.sig_enforce , CONFIG_MODULE_SIG
Харденинг ядра
Wazuh не предотвращает эксплуатацию подобных уязвимостей — для этого необходимо своевременно обновлять ядро или использовать решения для livepatch. Зато он помогает обнаружить косвенные признаки атаки: появление новых модулей ядра, подозрительные системные вызовы, изменения в конфигурации и другие аномалии, которые сопровождают эксплуатацию или закрепление злоумышленника в системе.
Далее по шагам настроим эти механизмы, начиная с инвентаризации загруженных модулей ядра.
Информационная безопасность как услуга
Предоставляем ИТ-инфраструктуру для проектов с повышенными требованиями безопасности, а также сервисы для защиты сетей, ОС и приложений.
Шаг 1. Инвентаризация загруженных модулей ядра
Первым шагом создадим базовую инвентаризацию модулей ядра. Она позволяет зафиксировать исходное состояние системы и в дальнейшем обнаруживать появление новых модулей, изменение существующих или загрузку компонентов, которых раньше не было. Такие изменения сами по себе не подтверждают компрометацию, но могут быть признаком закрепления злоумышленника или установки руткита.
Скрипт собирает список всех загруженных модулей с их размером, числом использований, зависимостями и статусом подписи. Запускается через wodle command , аналогично скрипту инвентаризации контейнеров:
Конфигурация wodle command :
Интервал в один час выбран как компромисс между оперативностью и нагрузкой. Для высококритичных систем можно уменьшить до 15 минут. Инвентаризация модулей ядра — легкая операция, которая не создает заметной нагрузки.
Пример события:
Wazuh сохранит полученные данные как отдельные события. При последующих запусках можно отслеживать появление новых модулей, изменение хеша файлов модулей или смену их состояния.
Шаг 2. Мониторинг версии ядра и статуса обновлений
Следующий шаг — контроль состояния самого ядра. Помимо версии важно регулярно отслеживать параметры безопасности и наличие ожидающих установки обновлений, поскольку многие эксплойты работают только на определенных версиях ядра или при отключенных механизмах защиты.
Отдельный скрипт фиксирует текущую версию ядра, наличие pending-обновлений и состояние ключевых параметров безопасности через sysctl :
Конфигурация wodle command :
Интервал в шесть часов достаточен, поскольку версия ядра и большинство параметров безопасности изменяются редко. При необходимости проверку можно выполнять чаще.
Шаг 3. Аудит системных вызовов (auditd + Wazuh)
Первые два шага позволяют контролировать состояние системы, но не показывают, что происходит во время эксплуатации уязвимости. Для этого потребуется аудит системных вызовов. Многие эксплойты класса page-cache write используют характерную последовательность вызовов ядра, которую можно фиксировать с помощью Linux Audit и анализировать средствами Wazuh.
Wazuh умеет читать события Linux Audit и превращать их в структурированные алерты. Для этого достаточно отслеживать несколько системных вызовов и событий, которые часто встречаются в цепочках эксплуатации Dirty Frag и Copy Fail.
Каждое правило ниже отвечает за отдельный этап потенциальной атаки: создание криптографических сокетов, использование splice() , загрузку модулей ядра или изменение параметров ядра.
В статье приводим пример для auditd, так как он является наиболее популярным методом аудита. Для более продвинутых пользователей рекомендуется использовать Falco .
В статье приводим пример для auditd, так как он является наиболее популярным методом аудита. Для более продвинутых пользователей рекомендуется использовать Falco .
Установка правил аудита
Добавьте в /etc/audit/rules.d/wazuh-kernel.rules :
Конфигурация Wazuh для чтения audit-лога
В ossec.conf агента добавьте localfile-блок:
После подключения audit-лога агент начнет получать события Linux Audit и передавать их менеджеру Wazuh. Базовые правила уже входят в поставку, однако события, связанные с мониторингом модулей ядра и признаками эксплуатации Dirty Frag или Copy Fail, потребуют собственных правил корреляции — их и рассмотрим на следующем шаге.
Шаг 4. Правила алертинга
Мы уже настроили сбор событий. Теперь важно добавить правила, которые будут преобразовывать их в осмысленные алерты.
Все правила добавляются в /var/ossec/etc/rules/local_rules.xml на менеджере Wazuh. Для удобства разобьем их на три группы: инвентаризация модулей, контроль состояния ядра и обнаружение подозрительной активности.
Инвентаризация модулей
Статус ядра и харденинг
Детекция подозрительной активности через auditd
Правило 100323 использует корреляцию по времени и PID. В высоконагруженных системах с легитимным использованием AF_ALG , например, strongSwan/IPsec, возможны ложные срабатывания. В этом случае добавьте исключение по имени процесса: <field name="audit" negate="yes">/usr/lib/ipsec/charon</field> .
Шаг 5. Контроль целостности /proc/modules через FIM
File Integrity Monitoring (FIM) в Wazuh позволяет в реальном времени отслеживать изменения в /proc и /sys , которые отражают текущее состояние ядра. Это полезно для обнаружения последствий эксплуатации, хотя сами атаки класса page-cache write таким способом выявить нельзя.
Важно. FIM контролирует изменения файловой системы, а не содержимого page cache, поэтому Dirty Frag и Copy Fail не будут обнаружены в момент эксплуатации: изменяется только страница файла в памяти. Однако FIM поможет выявить последующие действия злоумышленника — например, запись бэкдора, изменение конфигурации системы, создание новых пользователей или подмену файлов уже после получения привилегий.
Важно. FIM контролирует изменения файловой системы, а не содержимого page cache, поэтому Dirty Frag и Copy Fail не будут обнаружены в момент эксплуатации: изменяется только страница файла в памяти. Однако FIM поможет выявить последующие действия злоумышленника — например, запись бэкдора, изменение конфигурации системы, создание новых пользователей или подмену файлов уже после получения привилегий.
Шаг 6. SCA: автоматическая проверка харденинга ядра
Security Configuration Assessment (SCA) в Wazuh позволяет регулярно проверять соответствие системы требованиям харденинга без написания скриптов. Создайте на сервере с установленным wazuh-agent директорию custom_scripts и файл scan_kernel_hardening: /var/ossec/etc/custom_scripts/sca_kernel_hardening.yml .
Важно. Для собственных скриптов и политик не используйте дефолтные папки wazuh-agent, при обновлении агента их затрет!
Важно. Для собственных скриптов и политик не используйте дефолтные папки wazuh-agent, при обновлении агента их затрет!
Включаем нашу политику /var/ossec/etc/ossec.conf :
Бесплатный курс «Системный администратор Linux с нуля»
Освойте администрирование Linux на SelectOS и станьте востребованным специалистом.
Архитектура обнаружения: сводная схема
Ни один механизм Wazuh не покрывает весь жизненный цикл подобных атак самостоятельно. Только совместное использование auditd, FIM, SCA и пользовательских правил позволяет обнаруживать различные этапы эксплуатации — от подготовки до закрепления в системе.
Зафиксируем небольшой «шпаргалкой», как разные компоненты Wazuh покрывают разные этапы атаки:
Этап атаки
Чтение /proc/kallsyms , dmesg
SCA — проверка kptr_restrict , dmesg_restrict
SCA check 10001-10002
Создание сокета AF_ALG
auditd → Wazuh
100321
splice() + sendmsg с MSG_SPLICE_PAGES
auditd → Wazuh корреляция
100322, 100323
Запись в memory
In-place crypto над page cache
Невозможно обнаружить напрямую
execve setuid-бинаря ( su , sudo )
auditd execve + FIM
Встроенные правила Wazuh
Загрузка вредоносного kmod
wodle + auditd
100302, 100320
Запись в /etc/passwd , .ssh/
FIM realtime
Встроенные правила FIM
Митигации на уровне ядра
Даже самая детальная система мониторинга не заменяет устранение причины уязвимости. Если обновление ядра пока невозможно, имеет смысл максимально сократить поверхность атаки и включить дополнительные механизмы защиты.
Что делать, если патч еще не применен (Dirty Frag, Copy Fail)
Проверьте текущую версию ядра ( uname -r ). Уязвимы ядра от 5.x до ~6.12 без патча esp4/AF_ALG .
Проверьте текущую версию ядра ( uname -r ). Уязвимы ядра от 5.x до ~6.12 без патча esp4/AF_ALG .
Заблокируйте загрузку модулей ESP/xfrm, если они не используются: echo 'install xfrm_user /bin/true' >> /etc/modprobe.d/disable-esp.conf .
Заблокируйте загрузку модулей ESP/xfrm, если они не используются: echo 'install xfrm_user /bin/true' >> /etc/modprobe.d/disable-esp.conf .
Отключите AF_ALG , если он не используется: echo 'install af_alg /bin/true' >> /etc/modprobe.d/disable-af_alg.conf .
Отключите AF_ALG , если он не используется: echo 'install af_alg /bin/true' >> /etc/modprobe.d/disable-af_alg.conf .
Включите CloudLinux KernelCare или аналогичный livepatch — они уже выпустили патч для Dirty Frag.
Включите CloudLinux KernelCare или аналогичный livepatch — они уже выпустили патч для Dirty Frag.
AlmaLinux уже выкатил тестовые ядра с исправлением — обновитесь через dnf update kernel .
AlmaLinux уже выкатил тестовые ядра с исправлением — обновитесь через dnf update kernel .
Поиск событий в Wazuh Dashboards
После настройки данные из пользовательских скриптов, auditd, FIM попадают в единое хранилище Wazuh и становятся доступны для поиска в Dashboards. Ниже — несколько полезных запросов, которые помогут быстро проверить работу конфигурации и найти наиболее важные события.
SCA можно найти в во вкладке Configuration Assessment:
Сводка по компонентам и итоги
В результате каждый компонент Wazuh берет на себя свою часть обнаружения. Вместе они покрывают разные этапы атаки — от контроля конфигурации ядра до выявления признаков эксплуатации и закрепления в системе.
Что обнаруживает
Уровень алерта
wodle kernel_modules
Новые/исчезнувшие модули, taint-флаги, модули без файла на диске
7-14
wodle kernel_status
Незакрытые обновления, lockdown off , слабые sysctl
5-10
auditd + Wazuh
Сокеты AF_ALG , splice() , загрузку модулей, ptrace
7-13
Корреляция 100323
Комбинация AF_ALG + splice от одного PID (Dirty Frag/Copy Fail паттерн)
FIM realtime
Изменения SUID-бинарей, /etc/passwd , /etc/shadow , /sys/module
7-12
SCA kernel_hardening
Слабые параметры ядра, отсутствие lockdown , kptr_restrict=0
Уязвимости класса page-cache write показали, что одних средств контроля целостности файлов уже недостаточно. Если изменения происходят только в оперативной памяти, обнаружение приходится строить на косвенных признаках: отслеживании подозрительных системных вызовов, контроле состояния ядра, мониторинге загрузки модулей и анализе последующих действий злоумышленника.
Предложенная конфигурация не предотвращает эксплуатацию Dirty Frag, Copy Fail и других подобных уязвимостей, зато значительно повышает наблюдаемость системы: помогает быстрее выявить попытку эксплуатации, обнаружить закрепление в системе и сократить время реагирования на инцидент.