Перейти к содержимому 
Пробел в безопасности «Грязный» вопрос В ядре Linux эта уязвимость позволяет локальным злоумышленникам практически гарантированно получить права root на хостинг-серверах, что в равной степени затрагивает веб-хостинг, облачные инстансы и управляемые серверы. Я покажу, как работает эта уязвимость, какие дистрибутивы затронуты, как быстро необходимо установить исправление и какие неотложные меры должны принять администраторы хостинга прямо сейчас, чтобы Производственные системы защищать.
Центральные пункты
- Риск получения прав суперпользователя: Локальное использование приводит к получению полных прав.
- Широкий эффект: Касается распространенных корпоративных дистрибутивов и рабочих узлов Kubernetes.
- Маршрут атаки: Сочетание ошибок ESP/IPsec и RxRPC в кэше страниц.
- Патчи: Доступны обновления, которые вступают в силу только после перезагрузки.
- Смягчение последствий: заблокировать esp4/esp6/rxrpc, строго ограничить локальный доступ.
Что стоит за «Dirty Frag» в ядре Linux
Dirty Frag объединяет две ошибки ядра в одну Повышение привилегий вплоть до прав root: небезопасная обработка на месте в стеке ESP/IPsec (esp4, esp6) и некорректные пути записи в подсистеме RxRPC. Оба этих фактора позволяют вносить изменения в Кэш страниц доступа к файлам, которые по сути должны быть защищены, например, к бинарным файлам с правами SUID или конфигурационным файлам. Уязвимость имеет идентификаторы CVE-2026-43284 и CVE-2026-43500; в её подтверждение был публично продемонстрирован концептуальный пример (Proof of Concept). Важно: злоумышленнику сначала требуется локальный доступ для выполнения кода, что часто встречается на хостинг-серверах. Именно поэтому небольшой «зазел в дверь» быстро приводит к полному захвату системы с Коренные права.
Почему хостинг-серверы особенно уязвимы
На хостинг-серверах существует множество Точки входа: слабые пароли, уязвимые CMS, доступ к оболочке через инструменты или неправильно настроенные службы. Как только запускается пользовательский процесс, цепочка эксплойтов может обойти систему управления правами и получить доступ к системным файлам в Кэш страниц оказать влияние. В многопользовательских средах существует даже риск нарушения границ между клиентами, поскольку одна взломанная учетная запись может вывести из строя весь хост. Кроме того, на этих системах хранятся ключи API, сертификаты и учетные данные для доступа к базам данных, которые после эскалации остаются открытыми. Поэтому я считаю, что для виртуального хостинга, рабочих узлов сборки, публичных серверов приложений и рабочих узлов Kubernetes существует особенно высокий Профиль риска.
Технический алгоритм атаки в простых шагах
Локальный злоумышленник начинает с непривилегированного Пользователь на сервере, например, через веб-шелл или уже взломанную учетную запись. С помощью Dirty Frag он получает права на запись в страницы кэша, относящиеся к привилегированным файлам. Затем он, например, изменяет SUID-бинарник или конфигурационный файл таким образом, что при следующем вызове Код с повышенными правами. Затем он отключает настройки безопасности или заменяет двоичные файлы, чтобы обеспечить свою устойчивость. В конце концов он распространяется по горизонтали, похищает учетные данные и получает доступ к другим системам в центре обработки данных или облачной VPC, пока не захватит всю Окрестности под контролем.
Затронутые дистрибутивы, контейнеры и облачные инстансы
Соответствующие компоненты ядра уже много лет используются в крупных Распределения: Ubuntu (включая LTS), Debian, RHEL, AlmaLinux, Rocky Linux, CentOS Stream, Fedora, openSUSE Tumbleweed и Amazon Linux. Контейнерные рабочие нагрузки также подвергаются риску, если ядро хоста содержит уязвимость, поскольку контейнеры используют ядро поделиться. Поэтому кластеры Kubernetes становятся мишенью для атак, особенно рабочие узлы, на которых выполняются разнообразные рабочие нагрузки. Кроме того, риск повышают CI/CD-раннеры, серверы сборки и VPN-шлюзы, использующие IPsec. Системы, на которых выполняется недоверенный код, я оцениваю как Приоритет 1.
Состояние патчей и реалистичные графики
Многие дистрибутивы уже поставляют обновленные Ядро-пакеты, однако защита вступает в силу только после перезапуска. Для CVE-2026-43284 доступны исправления для широкого круга систем, тогда как для CVE-2026-43500 в некоторых случаях возникают задержки, что требует применения временных решений. Поэтому я планирую поэтапные окна технического обслуживания, проверяю зависимости, такие как IPsec или RxRPC, а затем проверяю текущую Версия. Упорядоченное управление установкой патчей и перезагрузками позволяет быстро и прозрачно снизить риски. Тем, кто хочет систематизировать рабочие процессы, рекомендуется начать с этого Руководство по обновлениям безопасности.
Как я проверяю, уязвима ли система
Я начинаю с прагматичного анализа текущего состояния: версия ядра, загруженные модули и возможные зависимости. В крупных средах я автоматизирую эти проверки с помощью инструментов управления инвентаризацией и конфигурацией (Inventory/CM), а на отдельных серверах достаточно нескольких команд.
# Определение версии ядра и пакета дистрибутива
uname -r
rpm -q kernel || dpkg -l | grep -E 'linux-(image|kernel)'
# Загружены ли уязвимые модули?
lsmod | egrep '^(esp4|esp6|rxrpc)\b'
# Проверка использования IPsec/XFRM (может быть безобидным, но служит для классификации)
ip xfrm state 2>/dev/null
ip xfrm policy 2>/dev/null
# Обнаруживаются ли RxRPC/kAFS?
ss -xa | grep -i rxrpc || true
В средах Kubernetes я назначаю версии ядра ролям рабочих узлов на основе списка узлов и слежу за тем, чтобы в первую очередь были обновлены особо уязвимые узлы (узлы сборки/выполнения заданий, рабочие нагрузки, обращенные к публичной сети) обеспеченный стать.
Временные меры без перезагрузки
Пока все системы не перезагрузятся, я целенаправленно блокирую Модули esp4, esp6 и rxrpc через черный список Modprobe и разгружаю их, если они активны. Перед этим я проверяю с помощью lsmod, загружены ли эти компоненты, и оцениваю возможные последствия для соединений IPsec или служб kAFS/RxRPC. Параллельно я усиливаю безопасность SSH: только вход по ключу, без входа по паролю, опционально двухфакторная аутентификация (2FA) для особо чувствительный Доступы администратора. Кроме того, я ограничиваю доступ к локальной оболочке для учетных записей без привилегий и сокращаю права в соответствии с принципом «минимальных привилегий». Параллельно с этим я отслеживаю такие сигналы, как появление новых файлов SUID, подозрительные процессы или необычные изменения двоичных файлов в доступных для записи путях, чтобы выявить подозрительные Образец Узнайте об этом раньше.
Конкретные меры по снижению рисков (по возможности без простоев)
Я обеспечиваю краткосрочную защиту на трёх уровнях: модули ядра, сетевой уровень и учетные записи. При этом я документирую каждое изменение для последующего отката после успешного применения патча.
- Внесение модулей в черный список и их разгрузка (только если все взаимосвязи прояснены):
# Создать файл черного списка
printf "blacklist esp4\nblacklist esp6\nblacklist rxrpc\n" | sudo tee /etc/modprobe.d/dirtyfrag-blacklist.conf
# Разгрузка уже загруженных модулей (может завершиться сбоем, если они используются)
sudo rmmod rxrpc 2>/dev/null || true
sudo rmmod esp6 2>/dev/null || true
sudo rmmod esp4 2>/dev/null || true
# Обеспечить сохранность Initramfs (учитывайте особенности дистрибутива)
sudo update-initramfs -u || sudo dracut -f
# Проверка, что модули не будут загружаться в будущем
modprobe -n esp4; modprobe -n esp6; modprobe -n rxrpc
- Блокировка ESP на сетевом уровне (если IPsec не используется в рабочей среде):
# nftables (предпочтительно)
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0\; }
sudo nft add rule inet filter input meta l4proto 50 drop # ESP = 50
sudo nft add rule inet filter input ip6 nexthdr 50 drop
# По желанию аналогично для Output/Forward
# iptables (устаревшая версия)
sudo iptables -A INPUT -p 50 -j DROP
sudo ip6tables -A INPUT -p 50 -j DROP
- Усиление безопасности SSH и локальных учетных записей:
# Только вход с помощью ключа
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl reload sshd
# Отключить интерактивные оболочки для пользователей служб
sudo usermod -s /usr/sbin/nologin
Я хочу подчеркнуть: эти меры являются временный. После полного развертывания обновлений и перезагрузки я сниму ограничения, если это необходимо с точки зрения эксплуатации.
Обнаружение и криминалистическая экспертиза: что я отслеживаю
Поскольку Dirty Frag способствует внесению изменений в конфиденциальные файлы через кэш страниц, я сосредотачиваю свой мониторинг на проверке целостности, изменениях SUID и необычной активности процессов.
- Обнаружение изменений SUID/SGID:
# Быстрое базовое сканирование
sudo find / -xdev -type f -perm -4000 -printf '%p %u:%g %m\n' 2>/dev/null
# Проверка целостности пакетов (учитывайте дистрибутив)
rpm -Va 2>/dev/null | grep '^..5' || true
sudo debsums -s 2>/dev/null || true
- Правила аудита изменений в двоичных файлах (если служба auditd включена):
sudo auditctl -w /usr/bin -p wa -k bin-change
sudo auditctl -w /usr/sbin -p wa -k bin-change
sudo auditctl -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -k perm-change
В журналах я ищу сбои при загрузке модулей, события XFRM/ESP и внезапные скачки возможностей. В случае подозрений я сохраняю эфимерные артефакты (открытые файлы, выдержки из памяти), прежде чем отключить систему от сети и действовать в соответствии с руководством по устранению инцидентов проанализируй.
Оптимизация для контейнерных и Kubernetes-рабочих нагрузок
Для кластерных сред я использую seccomp-профили, чтобы ограничить критические системные вызовы (например, AF_KEY, AF_RXRPC, XFRM-Netlink). Одновременно я принудительно запускаю AppArmor или SELinux в режиме enforcing, чтобы нарушения политики немедленно пресекались. Чувствительные рабочие нагрузки я подвергаю более строгой изоляции, изолирую Пространства имен и строго разделяю рабочие узлы сборки и производственные сервисы. Контроллеры доступа обеспечивают соблюдение профилей безопасности, а журналы и метрики сигнализируют о необычной активности узлов. На рабочих узлах с внешним кодом я планирую установку патчей в первую очередь, поскольку именно здесь возникает наибольшая экспозиция.
Примеры политик для под (реализованные на практике)
Я приведу минимальный набор настроек SecurityContext, который хорошо подходит в качестве значения по умолчанию для типовых рабочих нагрузок:
apiVersion: v1
kind: Pod
metadata:
name: hardened-pod
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: your-registry/your-image:tag
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
runAsNonRoot: true
readOnlyRootFilesystem: true
Кроме того, я настраиваю PodSecurityAdmission (или политики через контроллер доступа) таким образом, чтобы привилегированные поды запускались только в четко определенных пространствах имен. Я не использую совместное использование пространств имён хоста (hostPID, hostNetwork), если в этом нет явной необходимости. Это снижает вероятность того, что уязвимость контейнера будет непосредственно использована в контекстах хоста проникает.
Периоды технического обслуживания, перезагрузки и внедрение версий Canary
Защита начинает действовать только после перезапуска ядра с установленным патчем. Поэтому я организую поэтапное Окно обслуживания с акцентом на доступность:
- Группа Canary: Я выбираю репрезентативные хосты для каждой платформы, сначала устанавливаю исправления и перезагружаю их, а затем отслеживаю метрики и журналы.
- Поэтапное внедрение: Затем производственные кластеры запускаются волнами, причём каждый раз проводятся проверки работоспособности и функциональные тесты «Smoke».
- «Drain & Evict» (Kubernetes): перед перезагрузкой узлы освобождаются от данных, а PDB и количество реплик обеспечивают доступность.
- План отката: В случае регрессий я переключаюсь на предыдущий ядро (выбор в GRUB) или восстанавливаю AMI/снимки.
Исправления в режиме реального времени могут помочь пережить период до полной перезагрузки, но не заменяют окончательную перезагрузку, которая потребуется, как только станут доступны все исправления для обеих уязвимостей CVE.
Управление изменениями, коммуникация и документация
Я подхожу к Dirty Frag так же, как и к любому важному обновлению ядра: создаю четкий тикет с описанием изменений, провожу анализ рисков, веду записи о тестировании и получаю одобрения. Важно информировать заинтересованные стороны о Воздействие, сроки выполнения и возможные перерывы в обслуживании. По завершении я фиксирую версии ядра, правила исключений (например, исключения IPsec) и удаляю временные обходные решения, чтобы не техническая задолженность остаются.
Типичные подводные камни на практике
- Средства смягчения последствий нарушают работу IPsec: Блокировка ESP (Proto 50) или разгрузка esp4/esp6 приводит к отключению рабочих туннелей. Я планирую использовать альтернативные маршруты или выделить отдельное окно для технического обслуживания.
- Недооценка зависимостей RxRPC: Устаревшие службы или использование kAFS встречаются редко, но все же имеются. Я тщательно проверяю ситуацию, прежде чем удалять rxrpc.
- Патч без перезагрузки: Установленные пакеты ядра не обеспечивают защиту, пока работает старое ядро. Я активно проверяю текущую версию.
- Неполное покрытие: Необходимо учитывать оба CVE — если исправления выпускаются поэтапно, остаточный риск сохраняется до полного развертывания.
- Внимание на контейнере, забыли о хосте: SecurityContext укрепляет безопасность подов, однако уязвимостью является ядро хоста. Я всегда отдаю приоритет Host-Fix.
Обзор по каждому сценарию хостинга
Для быстрого ориентирования я кратко изложу риски и немедленные шаги по каждому Сценарий вместе. Таблица помогает расставить приоритеты, когда приходится управлять большим количеством систем. Я начинаю с виртуальных серверов и рабочих узлов, затем перехожу к выделенным серверам и менее уязвимым службам. После установки исправлений я проверяю текущую версию ядра и провожу краткую проверку работоспособности. Перед тем как окончательно включить модули, я обращаю внимание на замечания, касающиеся зависимостей IPsec или RxRPC. блокировать.
| Сценарий | Основная опасность | Немедленные меры | Указание по смягчению последствий |
|---|---|---|---|
| Общий хостинг | Отмена разделения клиентов | Установка патча + перезагрузка, ограничение пользовательских оболочек | черные списки esp4/esp6/rxrpc, проверки SUID |
| Рабочий узел Kubernetes | Контейнер с правами хоста | Обновление ядра, принудительное включение seccomp/AppArmor | Ограничить AF_KEY/AF_RXRPC/XFRM |
| CI/CD-раннер | Недоверенные задания сборки | Быстрое исправление уязвимостей, принцип минимальных привилегий | Временная блокада модуля |
| VPN-/IPsec-шлюзы | Атаки на ESP/IPsec | Тщательное тестирование перед запуском | Сравнить риск и доступность |
| Выделенные корневые серверы | Полный доступ к данным | Установка исправлений, перезагрузка, проверка журналов аудита | Усиление безопасности SSH и учетных записей |
Почему так важен выбор хостинг-провайдера
Провайдер с четким Патч-Процесс, четкая коммуникация и мониторинг позволяют значительно сократить время, необходимое для устранения неполадок. Я уделяю внимание соблюдению установленных временных рамок технического обслуживания, ведению журналов изменений и тестированию обновлений безопасности. Не менее важно: разумные рекомендации по укреплению безопасности, руководства по действиям в чрезвычайных ситуациях и команда, которая активно реагирует на отклонения от нормы. Прозрачность в отношении стратегий ядра и циклов разработки в исходном проекте укрепляет доверие в критических фазах. Те, кто хочет понять суть политики обновлений, могут ознакомиться с кратким обзором по ссылке старые версии ядра на хостинге и на этом основании оценивает собственную Стратегия.
Контрольный список для быстрого внедрения
- Провести инвентаризацию: версии ядра, роли, зависимости IPsec/RxRPC.
- Установка приоритетов: в первую очередь — хосты с недоверенным кодом и узлы, доступные из внешней сети.
- Включить меры по снижению рисков: внести модули в черный список, отключить ESP, усилить защиту SSH.
- Установка патчей: сначала на тестовых и Canary-хостах, затем поэтапное развертывание.
- Планирование перезагрузок: слив/переключение на резервный сервер, проверки работоспособности, функциональные тесты.
- Проверка: проверка запущенного ядра, запуск сканирования на целостность и наличие SUID.
- Усилить мониторинг: правила Auditd, аномалии в процессах, сигнатуры журналов.
- Оценить целесообразность отмены временных обходных решений после обеспечения полной защиты.
- Документирование: изменения, исключения, извлеченные уроки.
Резюме: Чем я сейчас занимаюсь
Я расставляю приоритеты Системы с недоверенным кодом, проверяю статус патчей и планирую немедленную перезагрузку после обновлений. До этого момента я блокирую esp4, esp6 и rxrpc, при необходимости переношу системы с интенсивным использованием IPsec в отдельное окно и ужесточаю доступ по SSH. В контейнерах я применяю seccomp, а также AppArmor/SELinux и отслеживаю изменения SUID, новые бинарные файлы и подозрительные процессы. После каждого развертывания я проверяю версию, журналы и работоспособность, чтобы минимизировать риск регрессии. Так я поддерживаю Риск под контролем, пока все узлы не начнут работать стабильно, а веб-приложения, базы данных и облачные рабочие нагрузки не возобновят надежную работу.
