Андрей Ефремов

В 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) — то есть, уже более 9 лет. Работает на ядрах от 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 является общим для всего хоста. Что 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(), загрузку модулей ядра или изменение параметров ядра. Установка правил аудита Добавьте в /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, возможны ложные срабатывания. В этом случае добавьте исключение по имени процесса: /usr/lib/ipsec/charon . Скриншот из дашборда Wazuh. Шаг 5. Контроль целостности /proc/modules через FIM File Integrity Monitoring (FIM) в Wazuh позволяет в реальном времени отслеживать изменения в /proc и /sys, которые отражают текущее состояние ядра. Это полезно для обнаружения последствий эксплуатации, хотя сами атаки класса page-cache write таким способом выявить нельзя. Шаг 6. SCA: автоматическая проверка харденинга ядра Security Configuration Assessment (SCA) в Wazuh позволяет регулярно проверять соответствие системы требованиям харденинга без написания скриптов. Создайте на сервере с установленным wazuh-agent директорию custom_scripts и файл scan_kernel_hardening: /var/ossec/etc/custom_scripts/sca_kernel_hardening.yml. Включаем нашу политику /var/ossec/etc/ossec.conf: Архитектура обнаружения: сводная схема Ни один механизм Wazuh не покрывает весь жизненный цикл подобных атак самостоятельно. Только совместное использование auditd, FIM, SCA и пользовательских правил позволяет обнаруживать различные этапы эксплуатации — от подготовки до закрепления в системе. Зафиксируем небольшой «шпаргалкой», как разные компоненты Wazuh покрывают разные этапы атаки: Этап атакиТехникаКомпонент WazuhПравилоРазведкаЧтение /proc/kallsyms, dmesgSCA — проверка kptr_restrict, dmesg_restrictSCA check 10001-10002ПодготовкаСоздание сокета AF_ALG auditd → Wazuh100321Эксплуатацияsplice() + sendmsg с MSG_SPLICE_PAGESauditd → Wazuh корреляция100322, 100323Запись в memoryIn-place crypto над page cacheНевозможно обнаружить напрямую—Эскалацияexecve setuid-бинаря (su, sudo)auditd execve + FIMВстроенные правила WazuhPersistenceЗагрузка вредоносного kmodwodle + auditd100302, 100320Post-exploitationЗапись в /etc/passwd, .ssh/FIM realtimeВстроенные правила FIM Митигации на уровне ядра Даже самая детальная система мониторинга не заменяет устранение причины уязвимости. Если обновление ядра пока невозможно, имеет смысл максимально сократить поверхность атаки и включить дополнительные механизмы защиты. Что делать, если патч еще не применен (Dirty Frag, Copy Fail) Проверьте текущую версию ядра (uname -r). Уязвимы ядра от 5.x до ~6.12 без патча esp4/AF_ALG. Заблокируйте загрузку модулей 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. Включите CloudLinux KernelCare или аналогичный livepatch — они уже выпустили патч для Dirty Frag. AlmaLinux уже выкатил тестовые ядра с исправлением — обновитесь через dnf update kernel. Поиск событий в Wazuh Dashboards После настройки данные из пользовательских скриптов, auditd, FIM попадают в единое хранилище Wazuh и становятся доступны для поиска в Dashboards. Ниже — несколько полезных запросов, которые помогут быстро проверить работу конфигурации и найти наиболее важные события. SCA можно найти в во вкладке Configuration Assessment: Отображение вкладки в дашборде Wazuh. Сводка по компонентам и итоги В результате каждый компонент Wazuh берет на себя свою часть обнаружения. Вместе они покрывают разные этапы атаки — от контроля конфигурации ядра до выявления признаков эксплуатации и закрепления в системе. КомпонентЧто обнаруживаетУровень алертаwodle kernel_modulesНовые/исчезнувшие модули, taint-флаги, модули без файла на диске7-14wodle kernel_statusНезакрытые обновления, lockdown off, слабые sysctl5-10auditd + WazuhСокеты AF_ALG, splice(), загрузку модулей, ptrace7-13Корреляция 100323Комбинация AF_ALG + splice от одного PID (Dirty Frag/Copy Fail паттерн)13FIM realtimeИзменения SUID-бинарей, /etc/passwd, /etc/shadow, /sys/module7-12SCA kernel_hardeningСлабые параметры ядра, отсутствие lockdown, kptr_restrict0Комплаенс Уязвимости класса page-cache write показали, что одних средств контроля целостности файлов уже недостаточно. Если изменения происходят только в оперативной памяти, обнаружение приходится строить на косвенных признаках: отслеживании подозрительных системных вызовов, контроле состояния ядра, мониторинге загрузки модулей и анализе последующих действий злоумышленника. Предложенная конфигурация не предотвращает эксплуатацию Dirty Frag, Copy Fail и других подобных уязвимостей, зато значительно повышает наблюдаемость системы: помогает быстрее выявить попытку эксплуатации, обнаружить закрепление в системе и сократить время реагирования на инцидент.

Андрей Ефремов

Материалы автора

Мониторинг модулей ядра и защита от Dirty-уязвимостей с помощью Wazuh

Справочник по Wazuh: функционал SIEM, возможности и настройка