В 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) не обнаружат атаку, потому что файл на диске не изменяется. Изменяется только его страница в оперативной памяти.

Что Wazuh может и что не может

Важно сразу обозначить границы возможностей. Wazuh не является средством предотвращения эксплуатации ядра. Его задача — своевременно обнаружить подозрительную активность и дать время на реагирование. В случае с Dirty Frag и Copy Fail Wazuh помогает на нескольких уровнях:

Wazuh не предотвращает эксплуатацию подобных уязвимостей — для этого необходимо своевременно обновлять ядро или использовать решения для livepatch. Зато он помогает обнаружить косвенные признаки атаки: появление новых модулей ядра, подозрительные системные вызовы, изменения в конфигурации и другие аномалии, которые сопровождают эксплуатацию или закрепление злоумышленника в системе.

Далее по шагам настроим эти механизмы, начиная с инвентаризации загруженных модулей ядра.

Информационная безопасность как услуга

Предоставляем ИТ-инфраструктуру для проектов с повышенными требованиями безопасности, а также сервисы для защиты сетей, ОС и приложений.

Подробнее →

Шаг 1. Инвентаризация загруженных модулей ядра

Первым шагом создадим базовую инвентаризацию модулей ядра. Она позволяет зафиксировать исходное состояние системы и в дальнейшем обнаруживать появление новых модулей, изменение существующих или загрузку компонентов, которых раньше не было. Такие изменения сами по себе не подтверждают компрометацию, но могут быть признаком закрепления злоумышленника или установки руткита.

Скрипт собирает список всех загруженных модулей с их размером, числом использований, зависимостями и статусом подписи. Запускается через wodle command, аналогично скрипту инвентаризации контейнеров:

#!/bin/sh
# /var/ossec/custom-scripts/kernel_modules.sh

# Читаем /proc/modules: name size refcount deps state addr
while read -r mod_name size refcount deps state addr; do
  # Убираем запятую в конце имени (kernel формат)
  name=$(echo "$mod_name" | tr -d ',')

  # Статус подписи модуля
  sig_file="/sys/module/${name}/taint"
  if [ -f "$sig_file" ]; then
    taint=$(cat "$sig_file" 2>/dev/null)
  else
    taint=""
  fi

  # Путь к .ko файлу через modinfo
  mod_path=$(modinfo -F filename "$name" 2>/dev/null | head -1)
  [ -z "$mod_path" ] && mod_path="built-in"

  # Хеш файла модуля (если есть на диске)
  if [ -f "$mod_path" ]; then
    mod_hash=$(sha256sum "$mod_path" 2>/dev/null | cut -d' ' -f1)
  else
    mod_hash="N/A"
  fi

  # Версия (vermagic) из modinfo
  vermagic=$(modinfo -F vermagic "$name" 2>/dev/null | head -1)
  [ -z "$vermagic" ] && vermagic="unknown"

  printf '{"type":"kernel_module","name":"%s","size":%s,"refcount":"%s","state":"%s","taint":"%s","path":"%s","sha256":"%s","vermagic":"%s"}\n' \
    "$name" "$size" "$refcount" "$state" "$taint" "$mod_path" "$mod_hash" "$vermagic"
done < /proc/modules

exit 0

chmod 750 /var/ossec/custom-scripts/kernel_modules.sh
chown root:wazuh /var/ossec/custom-scripts/kernel_modules.sh

Конфигурация wodle command:

<wodle name="command">
  <disabled>no</disabled>
  <tag>kernel_module_inventory</tag>
  <command>/var/ossec/custom-scripts/kernel_modules.sh</command>
  <interval>1h</interval>
  <ignore_output>no</ignore_output>
  <timeout>30</timeout>
  <run_on_start>yes</run_on_start>
</wodle>

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

Пример события:

{
  "type":     "kernel_module",
  "name":     "esp4",
  "size":     32768,
  "refcount": "1",
  "state":    "Live",
  "taint":    "",
  "path":     "/lib/modules/6.12.0/kernel/net/ipv4/esp4.ko.zst",
  "sha256":   "a3f9c1...",
  "vermagic": "6.12.0-26-generic SMP preempt"
}

Wazuh сохранит полученные данные как отдельные события. При последующих запусках можно отслеживать появление новых модулей, изменение хеша файлов модулей или смену их состояния.

Шаг 2. Мониторинг версии ядра и статуса обновлений

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

Отдельный скрипт фиксирует текущую версию ядра, наличие pending-обновлений и состояние ключевых параметров безопасности через sysctl:

#!/bin/sh
# /var/ossec/custom-scripts/kernel_status.sh

kernel_version=$(uname -r)
kernel_release=$(uname -v)

# Lockdown mode (1=integrity, 2=confidentiality, 0=none)
lockdown=$(cat /sys/kernel/security/lockdown 2>/dev/null | grep -o '\[.*\]' | tr -d '[]')
[ -z "$lockdown" ] && lockdown="unsupported"

# Требование подписи модулей
sig_enforce=$(cat /proc/sys/kernel/modules_disabled 2>/dev/null || echo 0)

# kptr_restrict: скрывать ли адреса ядра
kptr=$(sysctl -n kernel.kptr_restrict 2>/dev/null || echo "unknown")

# dmesg_restrict
dmesg=$(sysctl -n kernel.dmesg_restrict 2>/dev/null || echo "unknown")

# perf_event_paranoid — важно для ряда эксплойтов
perf=$(sysctl -n kernel.perf_event_paranoid 2>/dev/null || echo "unknown")

# unprivileged_userns_clone (Debian/Ubuntu)
userns=$(sysctl -n kernel.unprivileged_userns_clone 2>/dev/null || echo "unsupported")

# Pending kernel updates (apt/dnf)
if command -v apt-get >/dev/null 2>&1; then
  pending=$(apt-get -s upgrade 2>/dev/null | grep '^Inst linux-image' | wc -l | tr -d ' ')
elif command -v dnf >/dev/null 2>&1; then
  pending=$(dnf check-update kernel 2>/dev/null | grep '^kernel' | wc -l | tr -d ' ')
else
  pending="unknown"
fi

printf '{"type":"kernel_status","version":"%s","release":"%s","lockdown":"%s","sig_enforce":%s,"kptr_restrict":"%s","dmesg_restrict":"%s","perf_paranoid":"%s","userns_clone":"%s","pending_kernel_updates":"%s"}\n' \
  "$kernel_version" "$kernel_release" "$lockdown" "$sig_enforce" \
  "$kptr" "$dmesg" "$perf" "$userns" "$pending"

Конфигурация wodle command:

<wodle name="command">
  <disabled>no</disabled>
  <tag>kernel_status</tag>
  <command>/var/ossec/custom-scripts/kernel_status.sh</command>
  <interval>6h</interval>
  <ignore_output>no</ignore_output>
  <timeout>60</timeout>
  <run_on_start>yes</run_on_start>
</wodle>

Интервал в шесть часов достаточен, поскольку версия ядра и большинство параметров безопасности изменяются редко. При необходимости проверку можно выполнять чаще.

Шаг 3. Аудит системных вызовов (auditd + Wazuh)

Первые два шага позволяют контролировать состояние системы, но не показывают, что происходит во время эксплуатации уязвимости. Для этого потребуется аудит системных вызовов. Многие эксплойты класса page-cache write используют характерную последовательность вызовов ядра, которую можно фиксировать с помощью Linux Audit и анализировать средствами Wazuh.

Wazuh умеет читать события Linux Audit и превращать их в структурированные алерты. Для этого достаточно отслеживать несколько системных вызовов и событий, которые часто встречаются в цепочках эксплуатации Dirty Frag и Copy Fail.

Каждое правило ниже отвечает за отдельный этап потенциальной атаки: создание криптографических сокетов, использование splice(), загрузку модулей ядра или изменение параметров ядра.

В статье приводим пример для auditd, так как он является наиболее популярным методом аудита. Для более продвинутых пользователей рекомендуется использовать Falco.

Установка правил аудита

Добавьте в /etc/audit/rules.d/wazuh-kernel.rules:

# Создание AF_ALG сокетов (Copy Fail использует этот интерфейс)
-a always,exit -F arch=b64 -S socket -F a0=38 -k af_alg_socket

# splice() — основной примитив для подачи page cache в crypto
-a always,exit -F arch=b64 -S splice -k splice_call

# sendmsg с подозрительными флагами (MSG_SPLICE_PAGES = 0x8000000)
-a always,exit -F arch=b64 -S sendmsg -k sendmsg_call

# Загрузка модулей ядра
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_module_load

# Выгрузка модулей
-a always,exit -F arch=b64 -S delete_module -k kernel_module_unload

# ptrace (используется в ряде LPE-цепочек)
-a always,exit -F arch=b64 -S ptrace -k ptrace_call

# Изменения в /proc/sys/kernel/
-w /proc/sys/kernel/ -p wa -k kernel_params_write

# Изменения в /sys/module/
-w /sys/module/ -p wa -k sysmodule_write

augenrules --load
systemctl restart auditd

Конфигурация Wazuh для чтения audit-лога

В ossec.conf агента добавьте localfile-блок:

<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

После подключения audit-лога агент начнет получать события Linux Audit и передавать их менеджеру Wazuh. Базовые правила уже входят в поставку, однако события, связанные с мониторингом модулей ядра и признаками эксплуатации Dirty Frag или Copy Fail, потребуют собственных правил корреляции — их и рассмотрим на следующем шаге.

Шаг 4. Правила алертинга

Мы уже настроили сбор событий. Теперь важно добавить правила, которые будут преобразовывать их в осмысленные алерты. 

Все правила добавляются в /var/ossec/etc/rules/local_rules.xml на менеджере Wazuh. Для удобства разобьем их на три группы: инвентаризация модулей, контроль состояния ядра и обнаружение подозрительной активности.

Инвентаризация модулей

<group name="kernel_inventory,">

  <rule id="100300" level="0">
    <decoded_as>json</decoded_as>
    <field name="type">^kernel_module$</field>
    <description>Kernel module inventory event</description>
  </rule>

  <!-- Модуль с признаком taint (неподписанный, из staging и т.д.) -->
  <rule id="100301" level="9">
    <if_sid>100300</if_sid>
    <field name="taint">.+</field>
    <description>Tainted kernel module loaded: $(name) taint=$(taint)</description>
    <group>kernel_security,tainted_module</group>
  </rule>

  <!-- Модуль без файла на диске — признак rootkit -->
  <rule id="100302" level="14">
    <if_sid>100300</if_sid>
    <field name="path">^N/A$</field>
    <description>Kernel module has no on-disk file: $(name) — possible rootkit!</description>
    <group>kernel_security,rootkit_indicator</group>
  </rule>

  <!-- Новый модуль, которого не было в прошлом цикле -->
  <rule id="100303" level="7">
    <if_sid>100300</if_sid>
    <options>no_full_log</options>
    <description>New kernel module observed: $(name)</description>
    <group>kernel_inventory,new_module</group>
  </rule>

</group>

Статус ядра и харденинг

<group name="kernel_status,">

  <rule id="100310" level="0">
    <decoded_as>json</decoded_as>
    <field name="type">^kernel_status$</field>
    <description>Kernel status event</description>
  </rule>

  <!-- Lockdown отключен — ядро уязвимо к ряду атак -->
  <rule id="100311" level="10">
    <if_sid>100310</if_sid>
    <field name="lockdown">^none$</field>
    <description>Kernel lockdown is disabled on $(agent.name)</description>
    <group>kernel_hardening,lockdown_off</group>
  </rule>

  <!-- Pending обновления ядра -->
  <rule id="100312" level="8">
    <if_sid>100310</if_sid>
    <field name="pending_kernel_updates">^[1-9]</field>
    <description>Pending kernel updates available: $(pending_kernel_updates) on $(agent.name)</description>
    <group>kernel_patching,update_required</group>
  </rule>

  <!-- kptr_restrict=0: адреса ядра видны всем -->
  <rule id="100313" level="6">
    <if_sid>100310</if_sid>
    <field name="kptr_restrict">^0$</field>
    <description>kernel.kptr_restrict=0: kernel addresses exposed on $(agent.name)</description>
    <group>kernel_hardening,kptr_exposed</group>
  </rule>

  <!-- unprivileged user namespaces — требуется для ряда LPE -->
  <rule id="100314" level="5">
    <if_sid>100310</if_sid>
    <field name="userns_clone">^1$</field>
    <description>Unprivileged user namespaces enabled (LPE risk) on $(agent.name)</description>
    <group>kernel_hardening,userns_enabled</group>
  </rule>

</group>

Детекция подозрительной активности через auditd

<group name="kernel_exploit_detection,">

  <!-- Загрузка модуля ядра от непривилегированного пользователя -->
  <rule id="100320" level="12">
    <if_group>audit_command</if_group>
    <match>key="kernel_module_load"</match>
    <description>Kernel module loaded: $(audit) by uid=$(audit.uid)</description>
    <group>kernel_security,module_load</group>
  </rule>

  <!-- AF_ALG сокет от непривилегированного пользователя -->
  <rule id="100321" level="8">
    <if_group>audit_syscall</if_group>
    <match>key="af_alg_socket"</match>
    <field name="audit.uid" negate="yes">^0$</field>
    <description>AF_ALG socket created by non-root uid=$(audit.uid) pid=$(audit.pid)</description>
    <group>kernel_exploit_detection,af_alg</group>
  </rule>

  <!-- splice() от непривилегированного пользователя в сочетании с sendmsg -->
  <rule id="100322" level="7">
    <if_group>audit_syscall</if_group>
    <match>key="splice_call"</match>
    <field name="audit.uid" negate="yes">^0$</field>
    <description>splice() syscall by non-root uid=$(audit.uid): potential page-cache attack primitive</description>
    <group>kernel_exploit_detection,splice</group>
  </rule>

  <!-- Корреляция: AF_ALG + splice от одного процесса за короткое время -->
  <rule id="100323" level="13" frequency="2" timeframe="5">
    <if_matched_sid>100321</if_matched_sid>
    <same_field>audit.pid</same_field>
    <description>Possible Copy Fail / Dirty Frag exploit: AF_ALG + splice from same process pid=$(audit.pid)</description>
    <group>kernel_exploit_detection,dirty_frag_indicator,high_confidence</group>
  </rule>

</group>

Правило 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 таким способом выявить нельзя.

<!-- В секции <syscheck> ossec.conf агента -->
<syscheck>
  <disabled>no</disabled>

  <!-- /proc/modules: список загруженных модулей -->
  <directories realtime="yes" check_all="yes">/proc/modules</directories>

  <!-- /sys/module/: параметры и статусы модулей -->
  <directories realtime="yes" check_all="yes">/sys/module</directories>

  <!-- Бинари с SUID/SGID — цель для page-cache write атак -->
  <directories realtime="yes" check_all="yes"
    whodata="yes">/usr/bin</directories>
  <directories realtime="yes" check_all="yes"
    whodata="yes">/usr/sbin</directories>
  <directories realtime="yes" check_all="yes"
    whodata="yes">/bin</directories>

  <!-- Критичные файлы, которые атаки часто модифицируют -->
  <directories realtime="yes" check_all="yes">/etc/passwd</directories>
  <directories realtime="yes" check_all="yes">/etc/shadow</directories>
  <directories realtime="yes" check_all="yes">/etc/sudoers</directories>

</syscheck>

Важно. 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.

policy:
  id: "kernel_hardening"
  file: "kernel_hardening.yml"
  name: "Kernel hardening for Dirty* class vulnerabilities"
  description: "Checks kernel parameters that mitigate page-cache write attacks"
  regex_type: "pcre2"

requirements:
  title: "Check that the target is a Linux system"
  description: "Policy applies only to Linux hosts with procfs"
  condition: all
  rules:
    - 'f:/proc/sys/kernel/ostype -> r:Linux'

checks:
  - id: 100001
    title: "kernel.kptr_restrict should be >= 1"
    description: "Hides kernel pointers from unprivileged users, complicating KASLR bypass"
    rationale: "Dirty Frag and Copy Fail PoCs benefit from knowing kernel addresses"
    remediation: "sysctl -w kernel.kptr_restrict=1 and persist it in /etc/sysctl.d/99-hardening.conf"
    condition: all
    rules:
      - 'f:/proc/sys/kernel/kptr_restrict -> n:^(\d+) compare >= 1'

  - id: 100002
    title: "kernel.dmesg_restrict should be 1"
    description: "Prevents unprivileged users from reading kernel ring buffer"
    remediation: "sysctl -w kernel.dmesg_restrict=1"
    condition: all
    rules:
      - 'f:/proc/sys/kernel/dmesg_restrict -> 1'

  - id: 100003
    title: "kernel.perf_event_paranoid should be >= 2"
    description: "Restricts perf subsystem access for unprivileged users"
    remediation: "sysctl -w kernel.perf_event_paranoid=3"
    condition: all
    rules:
      - 'f:/proc/sys/kernel/perf_event_paranoid -> n:^(\d+) compare >= 2'

  - id: 100004
    title: "Unprivileged user namespaces should be disabled"
    description: "Limits attack surface for many LPE exploits including Dirty Frag variants"
    remediation: "sysctl -w kernel.unprivileged_userns_clone=0 (Debian/Ubuntu) or sysctl -w user.max_user_namespaces=0"
    condition: any
    rules:
      - 'f:/proc/sys/kernel/unprivileged_userns_clone -> 0'
      - 'f:/proc/sys/user/max_user_namespaces -> 0'

  - id: 100005
    title: "Kernel lockdown mode should be enabled"
    description: "Lockdown in integrity or confidentiality mode prevents many kernel modification paths"
    remediation: "Add lockdown=integrity to kernel cmdline and reboot"
    condition: all
    rules:
      - 'f:/sys/kernel/security/lockdown -> r:\[(integrity|confidentiality)\]'

  - id: 100006
    title: "Module signature enforcement should be active"
    description: "Only signed kernel modules should be loadable"
    remediation: "Add module.sig_enforce=1 to kernel cmdline or build kernel with CONFIG_MODULE_SIG_FORCE"
    condition: all
    rules:
      - 'f:/sys/module/module/parameters/sig_enforce -> r:^Y'

Важно. Для собственных скриптов и политик не используйте дефолтные папки wazuh-agent, при обновлении агента их затрет!

Включаем нашу политику /var/ossec/etc/ossec.conf:

 <sca>
    <enabled>yes</enabled>
    <scan_on_start>yes</scan_on_start>
    <interval>12h</interval>
    <skip_nfs>yes</skip_nfs>
    <policies>
      <policy>etc/custom_scripts/sca_kernel_hardening.yml</policy>
    </policies>
  </sca>

Бесплатный курс «Системный администратор Linux с нуля»

Освойте администрирование Linux на SelectOS и станьте востребованным специалистом.

Зарегистрироваться →

Архитектура обнаружения: сводная схема

Ни один механизм Wazuh не покрывает весь жизненный цикл подобных атак самостоятельно. Только совместное использование auditd, FIM, SCA и пользовательских правил позволяет обнаруживать различные этапы эксплуатации — от подготовки до закрепления в системе.

Зафиксируем небольшой «шпаргалкой», как разные компоненты Wazuh покрывают разные этапы атаки:

Митигации на уровне ядра

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

Что делать, если патч еще не применен (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. Ниже — несколько полезных запросов, которые помогут быстро проверить работу конфигурации и найти наиболее важные события.

# Все события инвентаризации модулей
data.type: kernel_module

# Tainted-модули (неподписанные, staging)
data.type: kernel_module AND data.taint: *

# Модули без файла на диске (rootkit-индикатор)
data.type: kernel_module AND data.path: "N/A"

# Системы с незакрытыми обновлениями ядра
data.type: kernel_status AND data.pending_kernel_updates: >0

# Lockdown отключен
data.type: kernel_status AND data.lockdown: "none"

# Алерты Dirty Frag / Copy Fail класса
rule.groups: kernel_exploit_detection

# AF_ALG от непривилегированных пользователей за последние 24ч
rule.id: 100321 AND @timestamp: [now-24h TO now]

SCA можно найти в во вкладке Configuration Assessment:

Сводка по компонентам и итоги

В результате каждый компонент Wazuh берет на себя свою часть обнаружения. Вместе они покрывают разные этапы атаки — от контроля конфигурации ядра до выявления признаков эксплуатации и закрепления в системе.

Уязвимости класса page-cache write показали, что одних средств контроля целостности файлов уже недостаточно. Если изменения происходят только в оперативной памяти, обнаружение приходится строить на косвенных признаках: отслеживании подозрительных системных вызовов, контроле состояния ядра, мониторинге загрузки модулей и анализе последующих действий злоумышленника.

Предложенная конфигурация не предотвращает эксплуатацию Dirty Frag, Copy Fail и других подобных уязвимостей, зато значительно повышает наблюдаемость системы: помогает быстрее выявить попытку эксплуатации, обнаружить закрепление в системе и сократить время реагирования на инцидент.