🧠 Skills: Cattle vs Pets — принцип которому 15 лет, но половина инфраструктур его игнорирует
Коллеги, вторник — хороший момент для фундаментального разговора. Принцип «скот vs питомцы» (Cattle vs Pets) сформулировали ещё в 2011 году, но я до сих пор регулярно вижу инфраструктуры где каждый сервер — уникальный именованный питомец с историей ручных конфигураций.
Вместо питомцев у нас есть Cattle — стадо: серверы анонимны, взаимозаменяемы. Если узел № 154 ведёт себя нестабильно, его не лечат как любимого котика — его пристреливают как охромевшую лошадь. Удаляют и автоматически поднимают новый, идентичный, здоровый. Именно этот принцип породил Infrastructure as Code.
Как выглядят «питомцы» в реальной жизни:
Практический переход от питомцев к скоту — четыре шага:
Почему это важно именно сейчас:
Copy Fail и Dirty Frag показали — сервера которые нельзя быстро пересоздать это не просто технический долг. Это риск. Если патч ломает питомца — нет возможности быстро откатиться на чистую конфигурацию. Если питомец умирает — нет возможности его воссоздать.
Infrastructure as Code: инфраструктура описывается в коде, воспроизводится автоматически, тестируется и версионируется как любой другой программный продукт.
Итог: посмотри на свой список серверов прямо сейчас. Посчитай сколько из них питомцы. Это твой список технического долга на следующий квартал.
#skills #iac #infrastructure #ansible #terraform #sysadmin #admin_future
Коллеги, вторник — хороший момент для фундаментального разговора. Принцип «скот vs питомцы» (Cattle vs Pets) сформулировали ещё в 2011 году, но я до сих пор регулярно вижу инфраструктуры где каждый сервер — уникальный именованный питомец с историей ручных конфигураций.
Вместо питомцев у нас есть Cattle — стадо: серверы анонимны, взаимозаменяемы. Если узел № 154 ведёт себя нестабильно, его не лечат как любимого котика — его пристреливают как охромевшую лошадь. Удаляют и автоматически поднимают новый, идентичный, здоровый. Именно этот принцип породил Infrastructure as Code.
Как выглядят «питомцы» в реальной жизни:
ПРИЗНАКИ "ПИТОМЦА":
- У сервера есть имя собственное: "Старый-Файловый",
"Сервак-Богдана", "Этот-трогать-нельзя"
- Никто не знает что на нём запущено кроме одного человека
- Последний раз переустанавливали в 2019 году
- Конфиги правились руками, в git не попадали
- Апгрейд невозможен — "упадёт всё"
ПРИЗНАКИ "СКОТА":
- Серверы называются по роли + номер: web-01, db-03
- Любой сервер можно удалить и поднять заново за минуты
- Конфигурация полностью в Ansible/Terraform
- Нет уникальных ручных настроек которые нигде не записаны
- Новый член команды может задеплоить среду с нуля
Практический переход от питомцев к скоту — четыре шага:
# ШАГ 1: Аудит — какие серверы у нас "питомцы"?
# Признак: uptime больше года без переустановки
uptime -s # дата последнего старта
# Если дата 2023 и раньше на продакшн-сервере — питомец
# ШАГ 2: Документируем что реально запущено (chef-solo, ansible-pull)
# На подозрительном сервере:
ss -tlnp # что слушает
systemctl list-units --type=service --state=running
crontab -l; ls /etc/cron.d/ # кроны
find /etc -newer /etc/os-release -type f 2>/dev/null | head -20
# Последнее — файлы изменённые после установки ОС
# ШАГ 3: Описываем текущее состояние как Ansible playbook
# ansible-pull или ручное написание по результатам аудита
# Проверяем идемпотентность:
ansible-playbook site.yml --check --diff
# ШАГ 4: Blue/Green замена
# Поднимаем новый сервер по playbook
# Переключаем трафик (DNS, LB)
# Старый питомец умирает с почестями
# Держим его неделю на всякий случай
Почему это важно именно сейчас:
Copy Fail и Dirty Frag показали — сервера которые нельзя быстро пересоздать это не просто технический долг. Это риск. Если патч ломает питомца — нет возможности быстро откатиться на чистую конфигурацию. Если питомец умирает — нет возможности его воссоздать.
Infrastructure as Code: инфраструктура описывается в коде, воспроизводится автоматически, тестируется и версионируется как любой другой программный продукт.
Итог: посмотри на свой список серверов прямо сейчас. Посчитай сколько из них питомцы. Это твой список технического долга на следующий квартал.
#skills #iac #infrastructure #ansible #terraform #sysadmin #admin_future
🐧 Linux: Killswitch в ядре — красная кнопка для zero-day, которая пугает всех кроме Red Hat
Коллеги, последние две недели — Copy Fail, Dirty Frag, оба с публичным PoC, оба до выхода патчей. Sasha Levin (NVIDIA, co-maintainer stable Linux) предложил системный ответ на этот хаос. И разгорелся нешуточный спор.
Предложенная фича «Killswitch» позволяет администраторам временно отключить конкретные уязвимые функции ядра прямо в runtime — вместо того чтобы сидеть и ждать патчей. Как сказал сам Левин: «когда уязвимость становится публичной, флоты остаются открытыми пока не будет собрано, распространено и перезагружено в новое ядро. Для многих проблем самый простой митигейшн — просто прекратить вызывать багованную функцию».
Как это работает: фича доступна через securityfs ядра. Привилегированный администратор включает killswitch для конкретной функции — она немедленно начинает возвращать ошибку. Эффект мгновенный, работает до отключения или перезагрузки.
Почему это спорно:
В r/cybersecurity предложение называют «ужасной идеей», «абсурдом» и «абсолютно пугающим». Аргумент против: люди будут использовать killswitch вместо патчинга.
Red Hat поддержал: «мы за включение killswitch в ядро, особенно по мере того как темп и серьёзность эксплойтов растёт благодаря LLM-сканированию. Патчи критичны, но они часто разрушительны. Организациям приходится взвешивать защиту через патч против производственного impact от рестартов».
Зачем это важно как концепция: killswitch — признание факта: если окно между публичным раскрытием и выходом патчей нельзя надёжно контролировать, администраторам нужен способ снизить риск на своих условиях.
Итог: proposal ещё под ревью, в ядро не принят. Но принцип — правильный. Ручная версия через blacklist работает уже сейчас и именно это большинство из нас делало последние две недели.
#linux #kernel #security #killswitch #copyfail #dirtyfrag #sysadmin #admin_future
Коллеги, последние две недели — Copy Fail, Dirty Frag, оба с публичным PoC, оба до выхода патчей. Sasha Levin (NVIDIA, co-maintainer stable Linux) предложил системный ответ на этот хаос. И разгорелся нешуточный спор.
Предложенная фича «Killswitch» позволяет администраторам временно отключить конкретные уязвимые функции ядра прямо в runtime — вместо того чтобы сидеть и ждать патчей. Как сказал сам Левин: «когда уязвимость становится публичной, флоты остаются открытыми пока не будет собрано, распространено и перезагружено в новое ядро. Для многих проблем самый простой митигейшн — просто прекратить вызывать багованную функцию».
Как это работает: фича доступна через securityfs ядра. Привилегированный администратор включает killswitch для конкретной функции — она немедленно начинает возвращать ошибку. Эффект мгновенный, работает до отключения или перезагрузки.
Почему это спорно:
В r/cybersecurity предложение называют «ужасной идеей», «абсурдом» и «абсолютно пугающим». Аргумент против: люди будут использовать killswitch вместо патчинга.
Red Hat поддержал: «мы за включение killswitch в ядро, особенно по мере того как темп и серьёзность эксплойтов растёт благодаря LLM-сканированию. Патчи критичны, но они часто разрушительны. Организациям приходится взвешивать защиту через патч против производственного impact от рестартов».
# Что это значит СЕЙЧАС — фича ещё не в ядре, это proposal.
# Но принцип уже можно применять вручную для Copy Fail и Dirty Frag:
# Copy Fail (CVE-2026-31431) — блокируем AF_ALG путь:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/killswitch.conf
rmmod algif_aead 2>/dev/null
# Dirty Frag (CVE-2026-43284 + CVE-2026-43500) — блокируем esp4/esp6/rxrpc:
echo -e "install esp4 /bin/false\ninstall esp6 /bin/false\n\
install rxrpc /bin/false" >> /etc/modprobe.d/killswitch.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
# Проверяем что всё заблокировано:
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc"
# Пустой вывод = хорошо
# ЕСЛИ НУЖЕН esp4/esp6 (используете IPsec) — только патч ядра:
uname -r # нужна 7.0.6 / 6.18.29 / 6.12.87 / 6.6.138+
apt update && apt full-upgrade # Ubuntu/Debian
dnf update kernel -y # RHEL/AlmaLinux/Rocky
Зачем это важно как концепция: killswitch — признание факта: если окно между публичным раскрытием и выходом патчей нельзя надёжно контролировать, администраторам нужен способ снизить риск на своих условиях.
Итог: proposal ещё под ревью, в ядро не принят. Но принцип — правильный. Ручная версия через blacklist работает уже сейчас и именно это большинство из нас делало последние две недели.
#linux #kernel #security #killswitch #copyfail #dirtyfrag #sysadmin #admin_future
🪟 Windows: RC4 в Kerberos — июль финализирует, а у тебя ещё не готово
Коллеги, сегодня последний день Windows Server Summit 2026. И главная тема которая звучала все три дня — RC4 в Kerberos. Не потому что новая. Потому что июль близко, а большинство до сих пор не закончили аудит.
Хронология жёсткая: январь 2026 — аудит-режим, предупреждающие события в логах DC. Апрель 2026 — enforcement: AES-SHA1 по умолчанию для учёток без явного msDS-SupportedEncryptionTypes. Июль 2026 — финал: RC4 убирается из протокольного пути полностью, ключ реестра RC4DefaultDisablementPhase игнорируется.
Что реально сломается если не подготовиться: сервисные учётки, NAS-устройства, принтеры, старые приложения, любая учётка без явного атрибута шифрования. Симптом: ошибка «KDC has no support for encryption type», сервисы не стартуют, авторизация в приложениях падает.
Зачем это срочно именно сейчас: после июля 2026 аудит-режим убирается и реестровый ключ игнорируется. Единственный откат — вручную включить RC4 для конкретной учётки. Это не план, это последний шанс перед аварией.
Итог: Event ID 201/202 на DC — смотри прямо сейчас. Каждое событие это учётка или сервис, который упадёт в июле. У тебя меньше двух месяцев.
#windows #kerberos #activedirectory #rc4 #security #sysadmin #admin_future
Коллеги, сегодня последний день Windows Server Summit 2026. И главная тема которая звучала все три дня — RC4 в Kerberos. Не потому что новая. Потому что июль близко, а большинство до сих пор не закончили аудит.
Хронология жёсткая: январь 2026 — аудит-режим, предупреждающие события в логах DC. Апрель 2026 — enforcement: AES-SHA1 по умолчанию для учёток без явного msDS-SupportedEncryptionTypes. Июль 2026 — финал: RC4 убирается из протокольного пути полностью, ключ реестра RC4DefaultDisablementPhase игнорируется.
Что реально сломается если не подготовиться: сервисные учётки, NAS-устройства, принтеры, старые приложения, любая учётка без явного атрибута шифрования. Симптом: ошибка «KDC has no support for encryption type», сервисы не стартуют, авторизация в приложениях падает.
# ШАГ 1: Смотрим Event ID 201-209 на DC — кто ещё использует RC4
Get-WinEvent -LogName System -ComputerName (hostname) |
Where-Object {$_.Id -in @(201,202,203,206,207)} |
Select-Object TimeCreated, Id, Message |
Format-List | Select-Object -First 20
# Что означают ID:
# 201 — RC4 использован (клиент только RC4, у сервиса нет msDS-SET)
# 202 — RC4 использован (у учётки нет AES-ключей)
# 203 — RC4 ЗАБЛОКИРОВАН (это уже ошибка в апрельском enforcement)
# ШАГ 2: Ищем учётки без AES-ключей
Get-ADUser -Filter {Enabled -eq $true} `
-Properties msDS-SupportedEncryptionTypes, PasswordLastSet,
ServicePrincipalNames |
Where-Object {$_.ServicePrincipalNames -ne $null} |
Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes |
Where-Object {$_.msDS-SupportedEncryptionTypes -eq $null -or
$_."msDS-SupportedEncryptionTypes" -eq 0}
# ШАГ 3: Генерируем AES-ключи для сервисных учёток
# Сброс пароля генерирует новые ключи автоматически:
Set-ADAccountPassword -Identity "svc_app01" -Reset `
-NewPassword (ConvertTo-SecureString "NewP@ss2026!" -AsPlainText -Force)
# Явно задаём поддерживаемое шифрование:
Set-ADUser -Identity "svc_app01" `
-KerberosEncryptionType AES128,AES256
# ШАГ 4: Проверяем krbtgt — если старый, AES-ключей нет:
Get-ADUser krbtgt -Properties PasswordLastSet,
msDS-SupportedEncryptionTypes |
Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes
# Если PasswordLastSet до 2012 — сбрасываем ДВАЖДЫ с репликацией
# ШАГ 5: Проверяем Event 4768/4769 на RC4-тикеты:
Get-WinEvent -LogName Security |
Where-Object {$_.Id -in @(4768,4769)} |
ForEach-Object {
if ($_.Message -match "0x17") {
Write-Host "RC4 ticket: $($_.TimeCreated) - $($_.Message)" `
-ForegroundColor Red
}
} | Select-Object -First 10
Зачем это срочно именно сейчас: после июля 2026 аудит-режим убирается и реестровый ключ игнорируется. Единственный откат — вручную включить RC4 для конкретной учётки. Это не план, это последний шанс перед аварией.
Итог: Event ID 201/202 на DC — смотри прямо сейчас. Каждое событие это учётка или сервис, который упадёт в июле. У тебя меньше двух месяцев.
#windows #kerberos #activedirectory #rc4 #security #sysadmin #admin_future
🧠 Skills: Vulnerability fatigue — когда патчей слишком много и что с этим делать
Коллеги, последние две недели — отличный материал для разговора об усталости от уязвимостей. Copy Fail, Dirty Frag, CVE-2026-32202, BlueHammer, RC4 в Kerberos, Secure Boot сертификаты, Cockpit RCE. Всё в один месяц. Всё срочно. Всё критично.
Linux kernel CVE-ы выросли примерно с 300 в 2023 году до более чем 5500 в этом году — рост частично объясняется более широким использованием AI-инструментов для поиска уязвимостей. Патчировать на достаточно высокой скорости в распределённых enterprise-флотах — возможно, уже нереально.
Это не просто техническая проблема. Это проблема приоритизации.
Рабочий фреймворк: как не тонуть в CVE-потоке
Три правила которые спасают от panic-патчинга:
Первое — не все CVE одинаковы. CVSS 9.8 на компонент которого у тебя нет — не твоя проблема сегодня. CVSS 7.8 с публичным PoC на компонент в продакшне — твоя проблема прямо сейчас.
Второе — подписывайся на правильные источники, а не читай всё подряд. CISA KEV + security advisory твоих дистрибутивов + NVD для специфичных продуктов. Три источника вместо двадцати.
Третье — отделяй «звучит страшно» от «реально опасно в моей среде». Copy Fail требует локального доступа — если у тебя нет непривилегированных пользователей на серверах, риск значительно ниже. Понимание модели угроз важнее скорости реакции на любой заголовок.
Зачем это нужно:
Killswitch-предложение — признание того факта, что нормальный цикл «раскрытие → патч → деплой» трещит по швам. Пока ядро не имеет встроенного механизма — организациям нужен собственный процесс приоритизации.
Итог: vulnerability fatigue — реальное явление. Лечится не игнорированием CVE, а чёткими критериями что является пожаром, а что плановой работой. Разница между паникой и контролем — это наличие процесса.
#skills #security #vulnerabilitymanagement #патчинг #sysadmin #admin_future
Коллеги, последние две недели — отличный материал для разговора об усталости от уязвимостей. Copy Fail, Dirty Frag, CVE-2026-32202, BlueHammer, RC4 в Kerberos, Secure Boot сертификаты, Cockpit RCE. Всё в один месяц. Всё срочно. Всё критично.
Linux kernel CVE-ы выросли примерно с 300 в 2023 году до более чем 5500 в этом году — рост частично объясняется более широким использованием AI-инструментов для поиска уязвимостей. Патчировать на достаточно высокой скорости в распределённых enterprise-флотах — возможно, уже нереально.
Это не просто техническая проблема. Это проблема приоритизации.
Рабочий фреймворк: как не тонуть в CVE-потоке
УРОВЕНЬ 1: НЕМЕДЛЕННО (сегодня-завтра)
Критерии: CVSS ≥ 9.0 + публичный PoC + активная эксплуатация
Действие: митигейшн сейчас, патч при ближайшей возможности
Примеры этого месяца: Copy Fail (KEV), Dirty Frag (PoC публичный)
Источники которые смотрим ЕЖЕДНЕВНО:
- CISA KEV: cisa.gov/known-exploited-vulnerabilities-catalog
- ВСЁ с пометкой "actively exploited" от вендора
УРОВЕНЬ 2: ЭТОТ ЦИКЛ (ближайшее плановое обслуживание)
Критерии: CVSS 7-9 + нет публичного PoC + нет признаков эксплуатации
Действие: включаем в стандартный patch cycle
Примеры: большинство Patch Tuesday без пометки "exploited"
УРОВЕНЬ 3: СЛЕДУЮЩИЙ КВАРТАЛ
Критерии: CVSS < 7 + требует сложной цепочки эксплуатации
Действие: мониторим, патчим при следующем удобном случае
УРОВЕНЬ 4: НЕ ПАТЧИМ СРОЧНО
Критерии: нет вектора атаки в нашей среде
(например: уязвимость в Bluetooth на серверах без BT)
Действие: записываем, пересматриваем при изменении среды
Три правила которые спасают от panic-патчинга:
Первое — не все CVE одинаковы. CVSS 9.8 на компонент которого у тебя нет — не твоя проблема сегодня. CVSS 7.8 с публичным PoC на компонент в продакшне — твоя проблема прямо сейчас.
Второе — подписывайся на правильные источники, а не читай всё подряд. CISA KEV + security advisory твоих дистрибутивов + NVD для специфичных продуктов. Три источника вместо двадцати.
Третье — отделяй «звучит страшно» от «реально опасно в моей среде». Copy Fail требует локального доступа — если у тебя нет непривилегированных пользователей на серверах, риск значительно ниже. Понимание модели угроз важнее скорости реакции на любой заголовок.
Зачем это нужно:
Killswitch-предложение — признание того факта, что нормальный цикл «раскрытие → патч → деплой» трещит по швам. Пока ядро не имеет встроенного механизма — организациям нужен собственный процесс приоритизации.
Итог: vulnerability fatigue — реальное явление. Лечится не игнорированием CVE, а чёткими критериями что является пожаром, а что плановой работой. Разница между паникой и контролем — это наличие процесса.
#skills #security #vulnerabilitymanagement #патчинг #sysadmin #admin_future
🔥1
-🐧 Linux: Fragnesia — третья уязвимость за две недели, и у неё нет CVE
Коллеги, вчера 13 мая вышел ещё один сюрприз. Команда v12-security раскрыла «Fragnesia» — универсальный LPE-эксплойт в ядре Linux, обнаруженный Уильямом Боулингом. Fragnesia относится к семейству Dirty Frag, но это отдельная ошибка в ESP/XFRM — она получила собственный патч. Митигейшн — тот же что и для Dirty Frag.
Механика: эксплойт использует логическую ошибку в подсистеме XFRM ESP-in-TCP. Когда TCP-сокет переходит в режим espintcp ULP после того как данные уже были перемещены через splice из файла, достигается произвольная байтовая запись в page cache read-only файлов — без race condition.
Это уже третья уязвимость класса page-cache write за две недели: Copy Fail → Dirty Frag → Fragnesia.
Критическое предупреждение после эксплуатации: после запуска эксплойта /usr/bin/su в page cache остаётся изменённым и будет порождать root-шелл при каждом вызове — до принудительного сброса кэша или перезагрузки.
Зачем это важно именно сейчас:
Три LPE за две недели из одной поверхности атаки (page cache / XFRM / ESP) говорят об одном: этот класс уязвимостей ещё не исчерпан. Killswitch-proposal от Левина выглядит уже не паранойей, а инженерным реализмом.
Итог: митигейшн простой — blacklist трёх модулей. Если IPsec не используется — делать прямо сейчас. Если используется — в приоритет патч ядра как только появится.
#linux #kernel #cve #fragnesia #lpe #security #sysadmin #admin_future
Коллеги, вчера 13 мая вышел ещё один сюрприз. Команда v12-security раскрыла «Fragnesia» — универсальный LPE-эксплойт в ядре Linux, обнаруженный Уильямом Боулингом. Fragnesia относится к семейству Dirty Frag, но это отдельная ошибка в ESP/XFRM — она получила собственный патч. Митигейшн — тот же что и для Dirty Frag.
Механика: эксплойт использует логическую ошибку в подсистеме XFRM ESP-in-TCP. Когда TCP-сокет переходит в режим espintcp ULP после того как данные уже были перемещены через splice из файла, достигается произвольная байтовая запись в page cache read-only файлов — без race condition.
Это уже третья уязвимость класса page-cache write за две недели: Copy Fail → Dirty Frag → Fragnesia.
Критическое предупреждение после эксплуатации: после запуска эксплойта /usr/bin/su в page cache остаётся изменённым и будет порождать root-шелл при каждом вызове — до принудительного сброса кэша или перезагрузки.
# МИТИГЕЙШН — тот же что для Dirty Frag
# Блокируем esp4, esp6, rxrpc:
printf 'install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf
rmmod esp4 esp6 rxrpc 2>/dev/null || true
# Если система уже была под атакой — ОБЯЗАТЕЛЬНО сбрасываем page cache:
echo 1 | tee /proc/sys/vm/drop_caches
# Или перезагружаемся
# Проверяем что модули не загружены:
lsmod | grep -E "esp4|esp6|rxrpc"
# Пустой вывод = хорошо
# Для систем использующих IPsec — только патч ядра:
# Нужна версия с патчем Fragnesia (появится в 7.0.7+ / 6.18.30+)
# Следим: kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.7
# AMD CPU op-cache: отдельная уязвимость этой недели (не ядро Linux)
# Затрагивает Zen 2. Патч от AMD — через обновление microcode:
apt update && apt install amd64-microcode # Debian/Ubuntu
dnf update microcode_ctl # RHEL/Rocky/AlmaLinux
Зачем это важно именно сейчас:
Три LPE за две недели из одной поверхности атаки (page cache / XFRM / ESP) говорят об одном: этот класс уязвимостей ещё не исчерпан. Killswitch-proposal от Левина выглядит уже не паранойей, а инженерным реализмом.
Итог: митигейшн простой — blacklist трёх модулей. Если IPsec не используется — делать прямо сейчас. Если используется — в приоритет патч ядра как только появится.
#linux #kernel #cve #fragnesia #lpe #security #sysadmin #admin_future
🪟 Windows: Май 2026 Patch Tuesday — 120 CVE, ноль zero-days, два приоритета
Коллеги, вчера вышел майский Patch Tuesday. Хорошая новость: впервые с июня 2024 года — ни одного активно эксплуатируемого или публично раскрытого zero-day. Плохая: несмотря на это, три компонента требуют срочного внимания.
CVE-2026-41096 — Windows DNS Client RCE, Critical.
Злоумышленник-контролируемый DNS-сервер может отправить специально сформированный DNS-ответ на уязвимую Windows-систему, что вызовет некорректную обработку памяти клиентом DNS и позволит выполнить код удалённо. DNS-клиент есть на каждой Windows-машине. Вектор — любой ответ от вредоносного DNS-сервера.
CVE-2026-41089 — Windows Netlogon RCE, Critical.
Stack-based buffer overflow в Netlogon. Контроллеры домена — это не обычные серверы, это структура авторизации всего Windows enterprise. Ошибка которая может быть применена против DC, даже при ограниченных условиях, должна быть в топе любого совещания по приоритизации патчей.
CVE-2026-41103 — Microsoft SSO Plugin для Jira/Confluence, CVSS 9.1, Critical.
Сетевая эксплуатация, не требует привилегий, не требует взаимодействия пользователя. Microsoft пометил как «Exploitation More Likely». Успешный эксплойт даёт неаутентифицированному атакующему доступ к Jira/Confluence с повышенными привилегиями.
Зачем это важно: фраза «не эксплуатируется в дикой природе» описывает знания Microsoft на момент релиза, а не гарантию завтрашнего поведения атакующих.
Итог: отсутствие zero-day не означает «можно подождать». DNS Client + Netlogon — это патчить в первую очередь на DC и серверах. Плюс майский патч закрывает апрельскую BitLocker-проблему — два повода для обновления.
#windows #patchtuesday #security #dns #netlogon #sysadmin #admin_future
Коллеги, вчера вышел майский Patch Tuesday. Хорошая новость: впервые с июня 2024 года — ни одного активно эксплуатируемого или публично раскрытого zero-day. Плохая: несмотря на это, три компонента требуют срочного внимания.
CVE-2026-41096 — Windows DNS Client RCE, Critical.
Злоумышленник-контролируемый DNS-сервер может отправить специально сформированный DNS-ответ на уязвимую Windows-систему, что вызовет некорректную обработку памяти клиентом DNS и позволит выполнить код удалённо. DNS-клиент есть на каждой Windows-машине. Вектор — любой ответ от вредоносного DNS-сервера.
CVE-2026-41089 — Windows Netlogon RCE, Critical.
Stack-based buffer overflow в Netlogon. Контроллеры домена — это не обычные серверы, это структура авторизации всего Windows enterprise. Ошибка которая может быть применена против DC, даже при ограниченных условиях, должна быть в топе любого совещания по приоритизации патчей.
CVE-2026-41103 — Microsoft SSO Plugin для Jira/Confluence, CVSS 9.1, Critical.
Сетевая эксплуатация, не требует привилегий, не требует взаимодействия пользователя. Microsoft пометил как «Exploitation More Likely». Успешный эксплойт даёт неаутентифицированному атакующему доступ к Jira/Confluence с повышенными привилегиями.
# Проверяем установлены ли майские обновления:
Get-HotFix | Where-Object {$_.InstalledOn -ge "2026-05-12"} |
Select-Object HotFixID, InstalledOn |
Sort-Object InstalledOn -Descending
# Для Windows 11 — KB5089549:
# Для Windows 10 — KB5087544:
Get-HotFix | Where-Object {$_.HotFixID -in @("KB5089549","KB5087544")}
# Prioritization список:
# 1. DC: KB c Netlogon fix (CVE-2026-41089) — ставим первыми
# 2. Все хосты: DNS Client (CVE-2026-41096) — широкая поверхность
# 3. Atlassian-интеграции: SSO Plugin (CVE-2026-41103) — проверить версию
# Для Hyper-V хостов: CVE-2026-40402 (guest-to-host escape) — Critical
Get-VM | Select-Object Name, State, Version # смотрим что запущено
# Хорошая новость этого Patch Tuesday:
# KB5089549 (Windows 11) закрывает проблему с неожиданными
# запросами BitLocker recovery key, которая была с апреля:
Get-HotFix "KB5089549"
Зачем это важно: фраза «не эксплуатируется в дикой природе» описывает знания Microsoft на момент релиза, а не гарантию завтрашнего поведения атакующих.
Итог: отсутствие zero-day не означает «можно подождать». DNS Client + Netlogon — это патчить в первую очередь на DC и серверах. Плюс майский патч закрывает апрельскую BitLocker-проблему — два повода для обновления.
#windows #patchtuesday #security #dns #netlogon #sysadmin #admin_future
🧠 Skills: Как вести учёт своих инцидентов — личный журнал который меняет карьеру
Коллеги, четверг — хороший день для инструмента которым пользуются единицы, хотя он меняет многое.
Последние две недели — Copy Fail, Dirty Frag, Fragnesia, Patch Tuesday, Kerberos RC4, Windows Server Summit. Ты это всё отработал, разобрался, закрыл. И через полгода это растворится в памяти как «что-то было с ядром в мае».
Личный журнал инцидентов — это не корпоративная документация. Это твой архив принятых решений.
Почему это важно: современный системный администратор ожидается не просто как человек поддерживающий системы, а как инженер, проактивно проектирующий и оптимизирующий сложные системы. Переход от реактивной модели к проактивной — ключевой сдвиг профессии. Личный журнал — конкретный инструмент этого перехода.
Шаблон — пять минут после каждого инцидента:
Три выгоды которые проявятся через 6 месяцев:
Зачем именно сейчас:
Май 2026 — исключительно насыщенный месяц. Три LPE в Linux, Patch Tuesday с критическими DNS/Netlogon, RC4 в Kerberos до июля. Если не зафиксировать — через год всё это сольётся в «помню был какой-то хаос весной».
Итог: пять минут после закрытия инцидента. Markdown-файл в личном репозитории. Через год это будет самый ценный документ в твоей карьере.
#skills #инциденты #документация #карьера #sysadmin #admin_future
Коллеги, четверг — хороший день для инструмента которым пользуются единицы, хотя он меняет многое.
Последние две недели — Copy Fail, Dirty Frag, Fragnesia, Patch Tuesday, Kerberos RC4, Windows Server Summit. Ты это всё отработал, разобрался, закрыл. И через полгода это растворится в памяти как «что-то было с ядром в мае».
Личный журнал инцидентов — это не корпоративная документация. Это твой архив принятых решений.
Почему это важно: современный системный администратор ожидается не просто как человек поддерживающий системы, а как инженер, проактивно проектирующий и оптимизирующий сложные системы. Переход от реактивной модели к проактивной — ключевой сдвиг профессии. Личный журнал — конкретный инструмент этого перехода.
Шаблон — пять минут после каждого инцидента:
## Инцидент: Fragnesia / Dirty Frag mitigation
Дата: 2026-05-14
Длительность работы: ~2 часа
### Что случилось
Публичный LPE в ядре Linux, класс page-cache write.
Третья уязвимость за две недели из той же поверхности.
### Что я сделал
1. Заблокировал esp4/esp6/rxrpc через /etc/modprobe.d/
2. Проверил все 23 сервера на наличие загруженных модулей
3. Сбросил page cache на двух серверах где модули были загружены
4. Создал задачу в трекере на обновление ядра как только
патч Fragnesia попадёт в stable
### Что нового я узнал
- drop_caches нужен если эксплойт уже мог быть применён
- splice() / sendfile() — вектор для этого класса атак
- Killswitch-proposal от Левина — интересная архитектура,
следить за принятием в ядро
### Что сделал бы иначе
Автоматизировать audit модулей — сейчас делал вручную на каждом
сервере. Написать Ansible-playbook для blacklist и проверки.
### Action items
- [ ] Написать playbook fragnesia_mitigation.yml
- [ ] Добавить проверку загруженных ESP-модулей в Prometheus alert
- [ ] Обновить ядро когда патч появится в репо (трекеру неделя)
Три выгоды которые проявятся через 6 месяцев:
1. СОБЕСЕДОВАНИЯ И РЕВЬЮ
"Расскажи о сложном инциденте" — у тебя конкретные примеры
с датами, решениями и выводами. Не "что-то было с ядром".
2. ПАТТЕРНЫ
Перечитывая журнал за квартал — видишь что ломается
чаще всего. Это твой список для превентивной работы.
3. ПЕРЕДАЧА ЗНАНИЙ
Когда придёт новый человек или нужно делегировать —
у тебя есть архив решений, а не только память.
Зачем именно сейчас:
Май 2026 — исключительно насыщенный месяц. Три LPE в Linux, Patch Tuesday с критическими DNS/Netlogon, RC4 в Kerberos до июля. Если не зафиксировать — через год всё это сольётся в «помню был какой-то хаос весной».
Итог: пять минут после закрытия инцидента. Markdown-файл в личном репозитории. Через год это будет самый ценный документ в твоей карьере.
#skills #инциденты #документация #карьера #sysadmin #admin_future
🔥2
🐧 Linux: Итог двух недель хаоса — что случилось, что закрыто, что делать сейчас
Коллеги, пятница — хороший момент подвести итог самого насыщенного security-периода в Linux за последние годы. Три уязвимости одного класса за две недели. Сегодня — финальный срез.
Сегодня, 15 мая — дедлайн CISA для федеральных агентств США по Copy Fail (CVE-2026-31431). Патчи выпущены всеми major дистрибутивами.
Итоговая карта угроз:
Copy Fail (CVE-2026-31431): логическая ошибка в authencesn криптографическом шаблоне. 732-байтовый Python-скрипт даёт root на всех Linux дистрибутивах с 2017 года. Эксплуатируется в дикой природе.
Dirty Frag (CVE-2026-43284 + CVE-2026-43500): две уязвимости в xfrm-ESP и RxRPC. Патч в 7.0.6 / 6.18.29.
Fragnesia (CVE-2026-46300): отдельная ошибка в XFRM ESP-in-TCP, та же поверхность атаки. Позволяет непривилегированному локальному атакующему изменять содержимое read-only файлов в page cache и получать root через детерминированный page-cache corruption primitive.
Один итоговый вывод про архитектуру:
Все три уязвимости — один класс: page-cache write primitive. Это означает что поверхность ещё не исчерпана. Killswitch-предложение Левина обсуждается именно потому что традиционный цикл "раскрытие → патч → деплой" не справляется когда эксплойты появляются быстрее патчей.
Итог: патч + перезагрузка. Для контейнерных сред — проверить хостовое ядро, не только образ контейнера. Хороших выходных без инцидентов.
#linux #kernel #cve #copyfail #dirtyfrag #fragnesia #sysadmin #admin_future
Коллеги, пятница — хороший момент подвести итог самого насыщенного security-периода в Linux за последние годы. Три уязвимости одного класса за две недели. Сегодня — финальный срез.
Сегодня, 15 мая — дедлайн CISA для федеральных агентств США по Copy Fail (CVE-2026-31431). Патчи выпущены всеми major дистрибутивами.
Итоговая карта угроз:
Copy Fail (CVE-2026-31431): логическая ошибка в authencesn криптографическом шаблоне. 732-байтовый Python-скрипт даёт root на всех Linux дистрибутивах с 2017 года. Эксплуатируется в дикой природе.
Dirty Frag (CVE-2026-43284 + CVE-2026-43500): две уязвимости в xfrm-ESP и RxRPC. Патч в 7.0.6 / 6.18.29.
Fragnesia (CVE-2026-46300): отдельная ошибка в XFRM ESP-in-TCP, та же поверхность атаки. Позволяет непривилегированному локальному атакующему изменять содержимое read-only файлов в page cache и получать root через детерминированный page-cache corruption primitive.
# ФИНАЛЬНЫЙ СТАТУС ПАТЧЕЙ — проверяем прямо сейчас:
uname -r
# Нужные версии (все три CVE закрыты):
# Ubuntu 24.04: 6.8.0-60+ → apt update && apt full-upgrade && reboot
# Ubuntu 22.04: 5.15.0-140+ → apt update && apt full-upgrade && reboot
# RHEL/Rocky/AlmaLinux 9: 5.14.0-611.54.3+ → dnf update kernel && reboot
# RHEL/Rocky/AlmaLinux 8: 4.18.0-553.123.2+ → dnf update kernel && reboot
# Debian 12: linux 6.1.136 → apt full-upgrade && reboot
# Если патч ещё не применён — митигейшн (пока):
cat /etc/modprobe.d/kernel-lpe-2026.conf 2>/dev/null || \
printf "install algif_aead /bin/false\n\
install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n" | \
tee /etc/modprobe.d/kernel-lpe-2026.conf
# Критически важно: если хост мог быть скомпрометирован —
# сбрасываем page cache ПЕРЕД тем как доверять setuid-бинарям:
echo 1 | tee /proc/sys/vm/drop_caches
# Проверяем что модули не загружены:
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc"
Один итоговый вывод про архитектуру:
Все три уязвимости — один класс: page-cache write primitive. Это означает что поверхность ещё не исчерпана. Killswitch-предложение Левина обсуждается именно потому что традиционный цикл "раскрытие → патч → деплой" не справляется когда эксплойты появляются быстрее патчей.
Итог: патч + перезагрузка. Для контейнерных сред — проверить хостовое ядро, не только образ контейнера. Хороших выходных без инцидентов.
#linux #kernel #cve #copyfail #dirtyfrag #fragnesia #sysadmin #admin_future
🪟 Windows: WSUS мёртв — время признать это и выбрать замену
Коллеги, майский Patch Tuesday закрыт, обновления разложены по серверам. И самое время поговорить о вещи которую многие откладывают: WSUS deprecated с сентября 2024 и пора принять решение о замене.
Deprecation WSUS означает: Microsoft больше не будет разрабатывать новые функции. WSUS продолжает работать для Windows-обновлений, но IT-команды должны ожидать растущих ограничений — особенно в части поддержки современных ОС, облачных интеграций и patching сторонних приложений.
Три сценария и что выбрать в каждом:
Зачем это важно именно сейчас: большинство IT-команд начинают планировать миграцию потому что WSUS не будет эволюционировать, что со временем сделает его труднее совместимым с современными требованиями patching и безопасности. Ранний переход рекомендуется чтобы избежать будущих сбоев.
Итог: WSUS работает, но это тупик. Выбери сценарий, запиши план, поставь срок. Через год инфраструктура скажет тебе спасибо.
#windows #wsus #patching #sysadmin #admin_future
Коллеги, майский Patch Tuesday закрыт, обновления разложены по серверам. И самое время поговорить о вещи которую многие откладывают: WSUS deprecated с сентября 2024 и пора принять решение о замене.
Deprecation WSUS означает: Microsoft больше не будет разрабатывать новые функции. WSUS продолжает работать для Windows-обновлений, но IT-команды должны ожидать растущих ограничений — особенно в части поддержки современных ОС, облачных интеграций и patching сторонних приложений.
Три сценария и что выбрать в каждом:
СЦЕНАРИЙ 1: Hybrid / Entra-joined + Intune
Решение: Windows Autopatch (уже включён в Intune)
Что даёт: автоматический patching по кольцам,
hotpatch для WS2025 без перезагрузки,
reporting по compliance в одном месте
Цена: включено в Microsoft 365 E3/E5
СЦЕНАРИЙ 2: On-premises, air-gapped или строгий контроль
Решение: Microsoft Configuration Manager (SCCM/MECM)
Что даёт: полный контроль над approvals и расписанием,
поддержка всех версий Windows включая offline,
третьесторонние обновления через Software Updates
Цена: лицензия MECM / System Center
СЦЕНАРИЙ 3: Смешанный парк (Windows + Linux + macOS)
Решение: Azure Update Manager (бесплатно для Azure VM,
Azure Arc для on-prem)
Что даёт: единая консоль для всех ОС,
schedule patching, compliance reporting
Цена: Azure Arc $6/сервер/месяц для on-prem
СЦЕНАРИЙ 4: Небольшой парк, нет облака, нет бюджета
Решение: оставляем WSUS ещё на год-два
(работает, просто не развивается),
параллельно оцениваем open-source:
- wsusoffline.net (автономная синхронизация)
- Ansible для применения патчей без WSUS
# Аудит текущего WSUS — что сейчас не в порядке:
# Типичные проблемы которые будут только хуже:
# 1. Размер базы WSUS (растёт бесконтрольно):
$wsus = Get-WsusServer
$db = $wsus.GetDatabaseConfiguration()
Write-Host "WSUS DB size: approximately large"
# Запускаем очистку (должна быть в cron уже):
Invoke-WsusServerCleanup `
-CleanupObsoleteComputers `
-CleanupUnneededContentFiles `
-CompressUpdates `
-CleanupObsoleteUpdates `
-DeclineExpiredUpdates `
-DeclineSupersededUpdates
# 2. Клиенты которые давно не чекинились (признак drift):
Get-WsusComputer | Where-Object {
$_.LastSyncTime -lt (Get-Date).AddDays(-30)
} | Select-Object FullDomainName, LastSyncTime |
Sort-Object LastSyncTime |
Export-Csv "wsus_stale_clients.csv" -NoTypeInformation
Зачем это важно именно сейчас: большинство IT-команд начинают планировать миграцию потому что WSUS не будет эволюционировать, что со временем сделает его труднее совместимым с современными требованиями patching и безопасности. Ранний переход рекомендуется чтобы избежать будущих сбоев.
Итог: WSUS работает, но это тупик. Выбери сценарий, запиши план, поставь срок. Через год инфраструктура скажет тебе спасибо.
#windows #wsus #patching #sysadmin #admin_future
✍1
🧠 Skills: PDQ State of Sysadmin 2026 — цифра которая объясняет всё
Коллеги, пятница и последний май-пост по skills. Сегодня — одна цифра из исследования PDQ и то, что за ней стоит.
62% сисадминов говорят что их роль расширилась новыми обязанностями. 52% ожидают экспертизы без предоставления обучения. 52% управляют всё более сложными системами. 50% говорят что темп изменений делает глубокую экспертизу невозможной.
Это не skills gap. Это дизайн работы который не масштабируется.
Отчёт PDQ 2026 показывает: стресс становится структурным. И структурные проблемы требуют структурных решений — автоматизации и AI. Не очередной дашборд, не очередной инструмент, не очередная речь «будьте проактивнее». Нужно проектировать работу которую могут выдержать люди, у которых тоже есть выходные.
Три вещи которые реально меняют ситуацию — не абстрактные советы, а конкретные действия:
Относись к on-call нагрузке как к операционному риску — не как к символу доблести, не как к испытанию. Это измеримая угроза uptime и удержанию специалистов.
Итог: две недели Copy Fail, Dirty Frag, Fragnesia, Patch Tuesday, RC4, Secure Boot — и это просто май 2026. Один человек не должен держать это в одиночку. Если держишь — у тебя не профессионализм, у твоей организации — архитектурная проблема управления рисками.
Хороших выходных, коллеги. Вы их заслужили.
#skills #карьера #workload #автоматизация #sysadmin #admin_future
Коллеги, пятница и последний май-пост по skills. Сегодня — одна цифра из исследования PDQ и то, что за ней стоит.
62% сисадминов говорят что их роль расширилась новыми обязанностями. 52% ожидают экспертизы без предоставления обучения. 52% управляют всё более сложными системами. 50% говорят что темп изменений делает глубокую экспертизу невозможной.
Это не skills gap. Это дизайн работы который не масштабируется.
Отчёт PDQ 2026 показывает: стресс становится структурным. И структурные проблемы требуют структурных решений — автоматизации и AI. Не очередной дашборд, не очередной инструмент, не очередная речь «будьте проактивнее». Нужно проектировать работу которую могут выдержать люди, у которых тоже есть выходные.
Три вещи которые реально меняют ситуацию — не абстрактные советы, а конкретные действия:
1. АВТОМАТИЗИРУЙ РИСК, А НЕ ТОЛЬКО СКУКУ
Большинство автоматизируют скучное (отчёты, инвентаризацию).
Автоматизируй рискованное и повторяющееся:
- Патчинг: Ansible playbook + cron = не думаешь каждый вторник
- Drift detection: --check раз в неделю = видишь проблему до инцидента
- Ротация паролей: LAPS v2 = не помнишь когда менял пароль сервисной учётки
Правило: если ты делаешь одно и то же третий раз — это скрипт,
не ручная работа.
2. ДОКУМЕНТИРУЙ ОТВЕТСТВЕННОСТЬ, НЕ ТОЛЬКО КОНФИГУРАЦИИ
У каждого сервиса должен быть owner.
Не "IT отвечает за всё" — это и есть причина 62%.
Шаблон в CMDB или просто в таблице:
| Сервис | Owner (бизнес) | On-call (IT) | Критичность |
|------------|----------------|--------------|-------------|
| CRM | Отдел продаж | team@it | High |
| 1С Бухгалт | Бухгалтерия | team@it | Critical |
Когда что-то падает — первый звонок owner, не IT.
IT решает техническую часть, не несёт бизнес-ответственность.
3. СЧИТАЙ НАГРУЗКУ КАК МЕТРИКУ, А НЕ ОЩУЩЕНИЕ
Отчёт руководству раз в квартал:
- N инцидентов вне рабочего времени
- N часов на emergency patching (Copy Fail, Dirty Frag, etc.)
- N задач inherited без ресурсов
Это не жалоба. Это операционный отчёт.
Цифры делают невидимую нагрузку видимой.
Относись к on-call нагрузке как к операционному риску — не как к символу доблести, не как к испытанию. Это измеримая угроза uptime и удержанию специалистов.
Итог: две недели Copy Fail, Dirty Frag, Fragnesia, Patch Tuesday, RC4, Secure Boot — и это просто май 2026. Один человек не должен держать это в одиночку. Если держишь — у тебя не профессионализм, у твоей организации — архитектурная проблема управления рисками.
Хороших выходных, коллеги. Вы их заслужили.
#skills #карьера #workload #автоматизация #sysadmin #admin_future
🐧 Linux: Как работает page-cache write — механика трёх уязвимостей мая на пальцах
Коллеги, понедельник — хороший момент чтобы разобраться в механике, а не просто закрыть тикет с митигейшном. Copy Fail, Dirty Frag, Fragnesia — все три эксплуатируют один примитив. Понимание «почему» защитит от следующего.
Page cache — это буфер в памяти ядра для содержимого файлов. Когда ты читаешь файл, ядро кэширует страницы. Когда файл открыт read-only — ядро гарантирует неизменность этих страниц. Или гарантировало.
Copy Fail: ядро устанавливает req->src = req->dst и цепляет tag-страницы из source scatterlist в output scatterlist через sg_chain(). Когда userspace подаёт данные через splice(), эти tag-страницы ссылаются на page cache файла. Алгоритм authencesn записывает 4 байта в scratch space — и эта запись оказывается внутри кэшированных данных файла в памяти, минуя права доступа.
Fragnesia (CVE-2026-46300): та же поверхность, другой вектор — логическая ошибка в XFRM ESP-in-TCP subsystem. Когда TCP-сокет переходит в espintcp ULP после splice из файла — достигается произвольная байтовая запись в page cache read-only файлов без race condition.
Итог для всех трёх: запись в read-only /usr/bin/su → setuid бит → root.
Почему это важно как архитектурный урок:
Dirty Frag применяет две отдельные page-cache write примитивы: один в xfrm-ESP, другой в RxRPC. Оба позволяют модифицировать page-cache-backed память не принадлежащую исключительно ядру, что даёт возможность повредить чувствительные файлы и получить привилегии. Три разных пути — один класс. Следи за XFRM и splice() в следующих раскрытиях.
Итог: патч + перезагрузка = закрыто. Без перезагрузки патч не работает. Проверь uname -r прямо сейчас.
#linux #kernel #security #pagecache #copyfail #sysadmin #admin_future
Коллеги, понедельник — хороший момент чтобы разобраться в механике, а не просто закрыть тикет с митигейшном. Copy Fail, Dirty Frag, Fragnesia — все три эксплуатируют один примитив. Понимание «почему» защитит от следующего.
Page cache — это буфер в памяти ядра для содержимого файлов. Когда ты читаешь файл, ядро кэширует страницы. Когда файл открыт read-only — ядро гарантирует неизменность этих страниц. Или гарантировало.
Copy Fail: ядро устанавливает req->src = req->dst и цепляет tag-страницы из source scatterlist в output scatterlist через sg_chain(). Когда userspace подаёт данные через splice(), эти tag-страницы ссылаются на page cache файла. Алгоритм authencesn записывает 4 байта в scratch space — и эта запись оказывается внутри кэшированных данных файла в памяти, минуя права доступа.
Fragnesia (CVE-2026-46300): та же поверхность, другой вектор — логическая ошибка в XFRM ESP-in-TCP subsystem. Когда TCP-сокет переходит в espintcp ULP после splice из файла — достигается произвольная байтовая запись в page cache read-only файлов без race condition.
Итог для всех трёх: запись в read-only /usr/bin/su → setuid бит → root.
# СТАТУС ПАТЧЕЙ — понедельник 18 мая:
# Все три (Copy Fail + Dirty Frag + Fragnesia) закрыты в:
# Ubuntu 24.04: linux 6.8.0-64 → проверяем
uname -r && apt-cache policy linux-image-$(uname -r)
# RHEL/AlmaLinux/Rocky 9: kernel-5.14.0-611.54.3
rpm -qa kernel | sort | tail -3
# Debian 12: linux 6.1.136 → apt-cache policy linux-image-amd64
# Если патч стоит — проверяем что перезагрузились с новым ядром:
uname -r # должна совпадать с установленной версией
# Если НЕ перезагружались — митигейшн всё ещё нужен:
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc"
# Непустой вывод + патч без перезагрузки = всё ещё уязвимы
# После патча И перезагрузки — можно убрать blacklist:
# rm /etc/modprobe.d/kernel-lpe-2026.conf && update-initramfs -u
# Проверяем AppArmor/SELinux — дополнительная защита:
# AppArmor (Ubuntu): ограничение user namespaces частично митигирует Fragnesia
aa-status | grep "user namespaces"
# SELinux (RHEL): enforcing mode ограничивает эксплуатацию
getenforce
Почему это важно как архитектурный урок:
Dirty Frag применяет две отдельные page-cache write примитивы: один в xfrm-ESP, другой в RxRPC. Оба позволяют модифицировать page-cache-backed память не принадлежащую исключительно ядру, что даёт возможность повредить чувствительные файлы и получить привилегии. Три разных пути — один класс. Следи за XFRM и splice() в следующих раскрытиях.
Итог: патч + перезагрузка = закрыто. Без перезагрузки патч не работает. Проверь uname -r прямо сейчас.
#linux #kernel #security #pagecache #copyfail #sysadmin #admin_future
🪟 Windows: Entra ID — две угрозы с одним дедлайном, 1 июня
Коллеги, пока все смотрели на Patch Tuesday и RC4 в Kerberos, в мире гибридной идентификации тихо созрели два изменения с одинаковым дедлайном — 1 июня 2026. Оба критичны для hybrid Entra Connect сред.
Первое: блокировка hard match для привилегированных учёток.
С 1 июня 2026 Microsoft Entra ID заблокирует любую попытку Entra Connect Sync или Cloud Sync выполнить hard-match нового объекта пользователя из Active Directory к существующему cloud-managed Entra ID пользователю с ролями Entra. Это защита от атак через манипуляцию атрибутами пользовательских объектов в Active Directory.
Почему это важно: атакующий с доступом к on-premises AD создаёт пользователя с matching sourceAnchor — и при следующей синхронизации захватывает cloud-identity включая Global Admin. Microsoft закрывает эту дыру принудительно.
Второе: уже закрытая (но проверить нужно) уязвимость Agent ID Administrator.
99% тенантов имеют хотя бы один привилегированный service principal. Пользователи с ролью Agent ID Administrator могли взять ownership произвольных service principals — включая те, у которых есть directory roles или высокоуровневые Graph permissions. Это полный захват service principal. Патч вышел 9 апреля, но следы активности нужно проверить.
Зачем это срочно именно сейчас: если после 1 июня произойдёт ошибка hard match — см. документацию по шагам митигейшн. Лучше найти и исправить до дедлайна, чем разбираться почему синхронизация сломалась в начале июня.
Итог: два действия до 1 июня. Найти cloud-привилегированные учётки с onPremisesImmutableId. Проверить аудит Agent ID Administrator с февраля. Это займёт час — и закроет серьёзный вектор атаки.
#windows #entra #activedirectory #hybrididentity #security #sysadmin #admin_future
Коллеги, пока все смотрели на Patch Tuesday и RC4 в Kerberos, в мире гибридной идентификации тихо созрели два изменения с одинаковым дедлайном — 1 июня 2026. Оба критичны для hybrid Entra Connect сред.
Первое: блокировка hard match для привилегированных учёток.
С 1 июня 2026 Microsoft Entra ID заблокирует любую попытку Entra Connect Sync или Cloud Sync выполнить hard-match нового объекта пользователя из Active Directory к существующему cloud-managed Entra ID пользователю с ролями Entra. Это защита от атак через манипуляцию атрибутами пользовательских объектов в Active Directory.
Почему это важно: атакующий с доступом к on-premises AD создаёт пользователя с matching sourceAnchor — и при следующей синхронизации захватывает cloud-identity включая Global Admin. Microsoft закрывает эту дыру принудительно.
Второе: уже закрытая (но проверить нужно) уязвимость Agent ID Administrator.
99% тенантов имеют хотя бы один привилегированный service principal. Пользователи с ролью Agent ID Administrator могли взять ownership произвольных service principals — включая те, у которых есть directory roles или высокоуровневые Graph permissions. Это полный захват service principal. Патч вышел 9 апреля, но следы активности нужно проверить.
# ---- ПРОВЕРКА К 1 ИЮНЯ ----
# 1. Найти cloud-привилегированные учётки КОТОРЫЕ могут сломаться:
# Ищем Entra-роли назначенные cloud-managed user с onPremisesImmutableId
Connect-MgGraph -Scopes "RoleManagement.Read.Directory","User.Read.All"
$roleAssignments = Get-MgRoleManagementDirectoryRoleAssignment -All |
Where-Object {$_.PrincipalId -ne $null}
foreach ($ra in $roleAssignments) {
$user = Get-MgUser -UserId $ra.PrincipalId `
-Property OnPremisesImmutableId, DisplayName, UserPrincipalName `
-ErrorAction SilentlyContinue
if ($user -and $user.OnPremisesImmutableId) {
Write-Host "РИСК: $($user.DisplayName) ($($user.UserPrincipalName))" `
-ForegroundColor Red
Write-Host " Роль ID: $($ra.RoleDefinitionId)"
}
}
# Все найденные — потенциально сломаются 1 июня при hard-match попытке
# 2. Проверяем Agent ID Administrator — кто назначен:
Get-MgDirectoryRole | Where-Object {$_.DisplayName -like "*Agent*"} |
ForEach-Object {
Get-MgDirectoryRoleMember -DirectoryRoleId $_.Id |
Select-Object @{N="Role";E={$_.AdditionalProperties.displayName}},
@{N="Id";E={$_.Id}}
}
# 3. Аудит подозрительных изменений ownership после февраля 2026:
# (период когда уязвимость могла эксплуатироваться)
Get-MgAuditLogDirectoryAudit -Filter `
"activityDateTime ge 2026-02-01 and
activityDisplayName eq 'Add owner to application'" |
Select-Object ActivityDateTime, InitiatedBy, TargetResources |
Export-Csv "agent_owner_audit.csv" -NoTypeInformation
# 4. Смотрим credential additions на service principals:
Get-MgAuditLogDirectoryAudit -Filter `
"activityDateTime ge 2026-02-01 and
activityDisplayName eq 'Add service principal credentials'" |
Select-Object ActivityDateTime, InitiatedBy, TargetResources |
Format-List | Select-Object -First 10
Зачем это срочно именно сейчас: если после 1 июня произойдёт ошибка hard match — см. документацию по шагам митигейшн. Лучше найти и исправить до дедлайна, чем разбираться почему синхронизация сломалась в начале июня.
Итог: два действия до 1 июня. Найти cloud-привилегированные учётки с onPremisesImmutableId. Проверить аудит Agent ID Administrator с февраля. Это займёт час — и закроет серьёзный вектор атаки.
#windows #entra #activedirectory #hybrididentity #security #sysadmin #admin_future
🧠 Skills: Как читать security advisory и не тратить час на каждый CVE
Коллеги, май 2026 показал: три LPE в Linux, Patch Tuesday со 120 CVE, Entra ID issues, RC4 в Kerberos. Всё одновременно. И каждый раз нужно быстро понять — это моя проблема или нет?
Навык быстрого чтения security advisory — это не про скорость чтения. Это про правильную последовательность вопросов.
Пять вопросов в порядке приоритета:
Сколько это занимает на практике:
Зачем формализовать это как процесс:
Без структуры каждый CVE кажется одинаково срочным. Со структурой — большинство закрываются за 5 минут с решением «не моя проблема» или «плановый патч». Оставшиеся 10-20% получают правильный приоритет и внимание.
Итог: пять вопросов. Сохрани в заметки. Следующий CVE проверь по этому списку — увидишь разницу.
#skills #security #cve #патчинг #sysadmin #admin_future
Коллеги, май 2026 показал: три LPE в Linux, Patch Tuesday со 120 CVE, Entra ID issues, RC4 в Kerberos. Всё одновременно. И каждый раз нужно быстро понять — это моя проблема или нет?
Навык быстрого чтения security advisory — это не про скорость чтения. Это про правильную последовательность вопросов.
Пять вопросов в порядке приоритета:
ВОПРОС 1: Есть ли это в моей среде?
Не "затрагивает ли Linux вообще", а "загружен ли у меня algif_aead?"
Не "уязвим ли Windows DNS Client", а "есть ли у меня WS2025 DC?"
Если нет — всё остальное не важно.
Инструменты:
lsmod | grep <module> # Linux модули
Get-WindowsFeature <role> # Windows роли
Get-HotFix -Id <KB> # установлен ли патч
ВОПРОС 2: Активно ли эксплуатируется?
Проверяем CISA KEV: cisa.gov/known-exploited-vulnerabilities-catalog
Если есть — это emergency. Если нет — плановый цикл.
Три статуса которые важны:
"Exploited in the wild" (CISA KEV) → сегодня
"Exploitation More Likely" (Microsoft) → этот цикл
"Exploitation Less Likely" → следующий квартал
ВОПРОС 3: Что нужно для эксплуатации?
Читаем Prerequisites/Attack Vector:
Network + Unauthenticated → критично, публичные сервисы
Network + Authenticated → важно, но нужен аккаунт
Local → нужен локальный доступ
Physical → обычно не первый приоритет
Copy Fail: Local + Unprivileged → критично для shared hosts
DNS CVE-2026-41096: Network + Unauthenticated → критично для DC
ВОПРОС 4: Есть ли митигейшн без патча?
Всегда смотрим Workarounds секцию.
Для Copy Fail: blacklist algif_aead — 30 секунд работы
Для RC4 Kerberos: включить AES-ключи заранее
Митигейшн даёт время — не заменяет патч
ВОПРОС 5: Когда патч?
Уже есть → в ближайшее maintenance window
Preview/RC → в production не трогаем, ставим в лабу
Нет → митигейшн + мониторинг + следим за релизом
Сколько это занимает на практике:
Copy Fail (когда вышел):
Q1: "algif_aead у меня загружен?" — 30 секунд, lsmod
Q2: "CISA KEV?" — да, 1 мая добавили → emergency
Q3: "Local + Unprivileged" → все shared hosts под угрозой
Q4: blacklist algif_aead → 2 команды, 1 минута
Q5: патч вышел для Ubuntu/RHEL → ставим при ближайшем window
Итого: 5 минут от чтения до принятого решения.
Entra hard match (1 июня дедлайн):
Q1: "Есть ли у нас гибридная Entra Connect среда?" → да/нет
Если нет → закрыли, не наш случай
Если да → Q2-Q5
Зачем формализовать это как процесс:
Без структуры каждый CVE кажется одинаково срочным. Со структурой — большинство закрываются за 5 минут с решением «не моя проблема» или «плановый патч». Оставшиеся 10-20% получают правильный приоритет и внимание.
Итог: пять вопросов. Сохрани в заметки. Следующий CVE проверь по этому списку — увидишь разницу.
#skills #security #cve #патчинг #sysadmin #admin_future
🐧 Linux: ModuleJail — сисадмин из Бельгии решил проблему которую не осилил Red Hat
Коллеги, май 2026-го показал: ручной blacklist модулей на флоте из сотен серверов — это не масштабируемо. Пока мы прописывали algif_aead, esp4, esp6 и rxrpc по одному, бельгийский сисадмин и Tesla-хакер Jasper Nuyens написал инструмент который делает это за секунды — для всего флота.
ModuleJail — GPLv3 shell-скрипт который сканирует запущенную Linux-систему и автоматически создаёт blacklist для всех неиспользуемых модулей ядра — без перезагрузки. Работает на Debian, Ubuntu, RHEL, Fedora, AlmaLinux и Arch Linux.
ModuleJail делает снимок загруженных модулей (/proc/modules) и вычисляет разность с полным деревом модулей (/lib/modules/$(uname -r)). Каждый модуль из разности, за исключением встроенного baseline и whitelist администратора, попадает в директиву install в модprobe.d-совместимый blacklist-файл.
Важная оговорка: ModuleJail должен запускаться только после достижения системой стабильного состояния — все сервисы запущены, ФС примонтированы, нужные драйверы загружены. Запуск слишком рано может заблокировать модули нужные позже.
Зачем это важно именно сейчас: AI-assisted security scanning делает с ядром Linux то, что массовый fuzzing сделал с userspace-кодом десять лет назад — только быстрее и в значительно большем масштабе. Много лет скрытых LPE-багов в модулях ядра вот-вот всплывут в быстрой последовательности.
Итог: не заменяет патчинг. Но пока патч не вышел — это лучший способ превратить следующий CVE в «не моя проблема» за счёт сокращения поверхности атаки.
#linux #security #kernel #modulejail #hardening #sysadmin #admin_future
Коллеги, май 2026-го показал: ручной blacklist модулей на флоте из сотен серверов — это не масштабируемо. Пока мы прописывали algif_aead, esp4, esp6 и rxrpc по одному, бельгийский сисадмин и Tesla-хакер Jasper Nuyens написал инструмент который делает это за секунды — для всего флота.
ModuleJail — GPLv3 shell-скрипт который сканирует запущенную Linux-систему и автоматически создаёт blacklist для всех неиспользуемых модулей ядра — без перезагрузки. Работает на Debian, Ubuntu, RHEL, Fedora, AlmaLinux и Arch Linux.
ModuleJail делает снимок загруженных модулей (/proc/modules) и вычисляет разность с полным деревом модулей (/lib/modules/$(uname -r)). Каждый модуль из разности, за исключением встроенного baseline и whitelist администратора, попадает в директиву install в модprobe.d-совместимый blacklist-файл.
# Установка и запуск за одну команду:
curl -fsSL https://raw.githubusercontent.com/jnuyens/modulejail/main/modulejail \
-o modulejail && chmod +x modulejail
# Запускаем с профилем для сервера (default: conservative)
# ВАЖНО: запускать только после полной загрузки всех сервисов
sudo sh modulejail -p conservative
# Три профиля:
# minimal — только core ФС и критичные модули
# conservative — minimal + драйверы для VM/bare-metal серверов (DEFAULT)
# desktop — conservative + WiFi, BT, audio, video
# Результат: /etc/modprobe.d/modulejail-blacklist.conf
# Смотрим сколько модулей заблокировано:
wc -l /etc/modprobe.d/modulejail-blacklist.conf
# Логирование заблокированных попыток загрузки (v1.2+):
# Каждая попытка modprobe <blocked_module> пишет в syslog:
journalctl -t modulejail -f
# Откат без перезагрузки — просто удаляем файл:
rm /etc/modprobe.d/modulejail-blacklist.conf
# Для немедленного эффекта — modprobe нужный_модуль вручную
# Ansible для флота (всё в git):
# - name: Deploy ModuleJail
# script: modulejail -p conservative
# args:
# creates: /etc/modprobe.d/modulejail-blacklist.conf
Важная оговорка: ModuleJail должен запускаться только после достижения системой стабильного состояния — все сервисы запущены, ФС примонтированы, нужные драйверы загружены. Запуск слишком рано может заблокировать модули нужные позже.
Зачем это важно именно сейчас: AI-assisted security scanning делает с ядром Linux то, что массовый fuzzing сделал с userspace-кодом десять лет назад — только быстрее и в значительно большем масштабе. Много лет скрытых LPE-багов в модулях ядра вот-вот всплывут в быстрой последовательности.
Итог: не заменяет патчинг. Но пока патч не вышел — это лучший способ превратить следующий CVE в «не моя проблема» за счёт сокращения поверхности атаки.
#linux #security #kernel #modulejail #hardening #sysadmin #admin_future
🪟 Windows: Secure Boot — вчера прошёл финальный AMA, June дедлайн через 6 недель
Коллеги, вчера 18 мая Microsoft провела последний AMA по Secure Boot перед июньским истечением сертификатов. Разбираем главное что прозвучало — и что нашли в майском обновлении.
Майское обновление Windows 11 (KB5089549) разместило на системах новую папку SecureBoot — это не вредонос, не ошибка установки. Это Microsoft размещает ресурсы для обновления Secure Boot, включая PowerShell-скрипты для определения статуса сертификатов и автоматизации развёртывания.
Главное с вчерашнего AMA:
Системы без новых сертификатов к июню 2026 войдут в деградированное состояние Secure Boot или не смогут загрузиться с BitLocker recovery prompts. Для отключённых устройств (lab machines, air-gapped) может потребоваться ручное вмешательство.
Один из участников поделился скриптом который сначала пытается установить Microsoft-обновление, при неудаче — делает fallback на OEM-пакет. AMA-команда одобрила подход, но предупредила: fallback нужно тщательно тестировать, так как неудачное обновление прошивки может окирпичить материнскую плату.
Зачем это критично до июня:
Обновление сертификатов — напоминание что обслуживание Windows теперь распространяется ниже уровня операционной системы. Patch Tuesday доставляет полезную нагрузку, но прошивка решает, может ли цепочка доверия принять и сохранить её.
Итог: шесть недель. Экспортируй CSV с NOT_STARTED серверами прямо сейчас — это твой план на эту неделю.
#windows #secureboot #pki #security #sysadmin #admin_future
Коллеги, вчера 18 мая Microsoft провела последний AMA по Secure Boot перед июньским истечением сертификатов. Разбираем главное что прозвучало — и что нашли в майском обновлении.
Майское обновление Windows 11 (KB5089549) разместило на системах новую папку SecureBoot — это не вредонос, не ошибка установки. Это Microsoft размещает ресурсы для обновления Secure Boot, включая PowerShell-скрипты для определения статуса сертификатов и автоматизации развёртывания.
Главное с вчерашнего AMA:
Системы без новых сертификатов к июню 2026 войдут в деградированное состояние Secure Boot или не смогут загрузиться с BitLocker recovery prompts. Для отключённых устройств (lab machines, air-gapped) может потребоваться ручное вмешательство.
Один из участников поделился скриптом который сначала пытается установить Microsoft-обновление, при неудаче — делает fallback на OEM-пакет. AMA-команда одобрила подход, но предупредила: fallback нужно тщательно тестировать, так как неудачное обновление прошивки может окирпичить материнскую плату.
# Итоговая проверка статуса — прямо сейчас:
# Смотрим статус обновления сертификатов
Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue
# Значения:
# (отсутствует или пусто) = NOT_STARTED — нужно действовать
# "InProgress" = в процессе
# "Updated" = готово
# Массовый аудит парка серверов:
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -ExpandProperty Name
$results = foreach ($s in $servers) {
try {
Invoke-Command -ComputerName $s -ScriptBlock {
$sb = Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue
[PSCustomObject]@{
Server = $env:COMPUTERNAME
Status = if ($sb) { $sb.UEFICA2023Status } else { "NOT_STARTED" }
}
} -ErrorAction Stop
} catch {
[PSCustomObject]@{Server=$s; Status="UNREACHABLE"}
}
}
$results | Group-Object Status | Format-Table Name, Count
$results | Where-Object {$_.Status -ne "Updated"} |
Export-Csv "secureboot_todo.csv" -NoTypeInformation
# Для серверов с NOT_STARTED — запускаем обновление:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# После перезагрузки — запустить ещё раз
# Также важно: обновляем dbx (список отозванных bootloader-ов)
# Проверяем текущий dbx через PowerShell модуль SecureBoot:
Confirm-SecureBootUEFI
Get-SecureBootUEFI -Name dbx
Зачем это критично до июня:
Обновление сертификатов — напоминание что обслуживание Windows теперь распространяется ниже уровня операционной системы. Patch Tuesday доставляет полезную нагрузку, но прошивка решает, может ли цепочка доверия принять и сохранить её.
Итог: шесть недель. Экспортируй CSV с NOT_STARTED серверами прямо сейчас — это твой план на эту неделю.
#windows #secureboot #pki #security #sysadmin #admin_future
🧠 Skills: CVE-2026-46333 — новый Linux LPE раскрыт сегодня, и он позволяет читать SSH-ключи
Коллеги, небольшой сдвиг формата сегодняшнего Skills-поста. Вместо soft skills — разберём как правильно реагировать на раскрытие прямо в момент его появления. Потому что сегодня именно такой момент.
Сегодня, 19 мая 2026, исследователи Qualys раскрыли CVE-2026-46333 в ядре Linux. Уязвимость позволяет непривилегированному пользователю читать файлы принадлежащие root — в том числе SSH-ключи (/etc/ssh/ssh_host_*_key) и файл /etc/shadow. PoC доступен публично как ssh-keysign-pwn и chage_pwn. Подтверждена работоспособность на Arch Linux, Debian, Ubuntu, CentOS и Raspberry Pi OS.
Механика: уязвимость в __ptrace_may_access(), которая пропускает dumpable-проверку когда task->mm == NULL. do_exit() запускает exit_mm() перед exit_files() — нет mm, но fd-ы ещё живые — и pidfd_getfd(2) успешно выполняется в этом окне когда uid вызывающего совпадает с целевым.
Это не LPE до root — это чтение приватных ключей. Для серверов с SSH-доступом — это критично.
Как работает правильная реакция на fresh disclosure:
Первые 30 минут: читаем advisory, понимаем prerequisites (local? network? authenticated?), проверяем есть ли у нас этот компонент в системе.
30 минут — 2 часа: ищем временный митигейшн (не патч — его ещё нет). Применяем если риск в нашей среде реален.
После: ждём патча дистрибутива, ставим как только появится, убираем митигейшн.
Это не паника — это процесс. Разница в том, что процесс можно делегировать и автоматизировать.
Итог: ptrace_scope = 1 — это одна команда которая снижает риск не только от CVE-2026-46333, но и от всего класса ptrace-атак. Это и есть defence-in-depth в действии.
#skills #linux #cve #security #реакция #sysadmin #admin_future
Коллеги, небольшой сдвиг формата сегодняшнего Skills-поста. Вместо soft skills — разберём как правильно реагировать на раскрытие прямо в момент его появления. Потому что сегодня именно такой момент.
Сегодня, 19 мая 2026, исследователи Qualys раскрыли CVE-2026-46333 в ядре Linux. Уязвимость позволяет непривилегированному пользователю читать файлы принадлежащие root — в том числе SSH-ключи (/etc/ssh/ssh_host_*_key) и файл /etc/shadow. PoC доступен публично как ssh-keysign-pwn и chage_pwn. Подтверждена работоспособность на Arch Linux, Debian, Ubuntu, CentOS и Raspberry Pi OS.
Механика: уязвимость в __ptrace_may_access(), которая пропускает dumpable-проверку когда task->mm == NULL. do_exit() запускает exit_mm() перед exit_files() — нет mm, но fd-ы ещё живые — и pidfd_getfd(2) успешно выполняется в этом окне когда uid вызывающего совпадает с целевым.
Это не LPE до root — это чтение приватных ключей. Для серверов с SSH-доступом — это критично.
# НЕМЕДЛЕННАЯ ДИАГНОСТИКА:
# Смотрим были ли у нас непривилегированные пользователи
# с доступом к системе за последние сутки
last | head -20
grep "Accepted" /var/log/auth.log | grep -v root | tail -20
# Если на сервере нет непривилегированных пользователей кроме root —
# риск значительно ниже (нет кому эксплуатировать)
awk -F: '$3 >= 1000 && $7 != "/sbin/nologin" && $7 != "/bin/false" \
{print $1, $7}' /etc/passwd
# МИТИГЕЙШН пока патча нет:
# 1. Ужесточаем права на SSH host keys (уже должны быть 600):
ls -la /etc/ssh/ssh_host_*
chmod 600 /etc/ssh/ssh_host_*_key
# 2. Ограничиваем чтение shadow:
ls -la /etc/shadow # должен быть 640 или 000
chmod 640 /etc/shadow
# 3. Если на сервере есть непривилегированные пользователи —
# временно блокируем ptrace для непривилегированных:
echo 1 | tee /proc/sys/kernel/yama/ptrace_scope
# или более жёстко:
echo 3 | tee /proc/sys/kernel/yama/ptrace_scope
# 3 = только root может ptrace (ломает некоторые отладчики)
# Делаем permanent через sysctl:
echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# СЛЕДИМ за патчем:
# upstream: kernel.org (ветки 7.0.x, 6.18.x, 6.12.x)
# Ubuntu: ubuntu.com/security/notices
# RHEL: access.redhat.com/security
Как работает правильная реакция на fresh disclosure:
Первые 30 минут: читаем advisory, понимаем prerequisites (local? network? authenticated?), проверяем есть ли у нас этот компонент в системе.
30 минут — 2 часа: ищем временный митигейшн (не патч — его ещё нет). Применяем если риск в нашей среде реален.
После: ждём патча дистрибутива, ставим как только появится, убираем митигейшн.
Это не паника — это процесс. Разница в том, что процесс можно делегировать и автоматизировать.
Итог: ptrace_scope = 1 — это одна команда которая снижает риск не только от CVE-2026-46333, но и от всего класса ptrace-атак. Это и есть defence-in-depth в действии.
#skills #linux #cve #security #реакция #sysadmin #admin_future
🐧 Linux: DirtyDecrypt — пятый вариант page-cache атаки за три недели, и сегодня вышел PoC
Коллеги, майский марафон Linux-уязвимостей продолжается. Сегодня утром на Hacker News — DirtyDecrypt (CVE-2026-31635). Это уже пятая уязвимость одного класса за три недели.
DirtyDecrypt обнаружили исследователи Zellic и V12, но при попытке зарепортить узнали — уязвимость уже была исправлена в mainline. Это rxgk page cache write из-за отсутствующего COW-guard в rxgk_decrypt_skb(). Оценивается как вариант Copy Fail, Dirty Frag и Fragnesia — все они дают root на уязвимых системах.
Хорошая новость: патч уже в mainline. Плохая: PoC публичен прямо сейчас.
Итоговая карта всех пяти за май 2026:
Все шесть закрываются одним митигейшном на системах без IPsec/RxRPC:
Зачем это важно как тренд: DirtyDecrypt обнаружили независимо, а уязвимость уже исправили — это говорит о том, что AI-assisted code analysis находит одни и те же классы ошибок быстрее чем когда-либо. Темп раскрытий этого месяца — не случайность, это новая норма.
Итог: mitigation-файл + ptrace_scope = закрыты все шесть CVE мая. Патч ядра ставим при ближайшем обслуживании. И да — это ещё не конец месяца.
#linux #kernel #cve #dirtydecrypt #security #sysadmin #admin_future
Коллеги, майский марафон Linux-уязвимостей продолжается. Сегодня утром на Hacker News — DirtyDecrypt (CVE-2026-31635). Это уже пятая уязвимость одного класса за три недели.
DirtyDecrypt обнаружили исследователи Zellic и V12, но при попытке зарепортить узнали — уязвимость уже была исправлена в mainline. Это rxgk page cache write из-за отсутствующего COW-guard в rxgk_decrypt_skb(). Оценивается как вариант Copy Fail, Dirty Frag и Fragnesia — все они дают root на уязвимых системах.
Хорошая новость: патч уже в mainline. Плохая: PoC публичен прямо сейчас.
Итоговая карта всех пяти за май 2026:
Copy Fail (CVE-2026-31431) — 29 апреля — AF_ALG, algif_aead
Dirty Frag (CVE-2026-43284) — 7 мая — ESP xfrm, esp4/esp6
Dirty Frag (CVE-2026-43500) — 7 мая — RxRPC rxrpc
Fragnesia (CVE-2026-46300) — 13 мая — XFRM ESP-in-TCP
DirtyDecrypt(CVE-2026-31635) — 20 мая — rxgk_decrypt_skb
CVE-2026-46333 — 19 мая — ptrace exit-race (чтение ключей)
Все шесть закрываются одним митигейшном на системах без IPsec/RxRPC:
# ПОЛНЫЙ МИТИГЕЙШН — все шесть CVE мая 2026
# (если algif_aead, esp4/esp6, rxrpc не нужны):
printf "install algif_aead /bin/false\n\
install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n" | \
tee /etc/modprobe.d/may2026-kernel-lpe.conf
rmmod algif_aead esp4 esp6 rxrpc 2>/dev/null || true
# Для CVE-2026-46333 (ptrace / SSH keys):
echo "kernel.yama.ptrace_scope = 1" >> \
/etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# Проверяем статус патчей на всём флоте:
# Нужны ядра: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207
uname -r
# ModuleJail — автоматизирует это для всех неиспользуемых модулей:
# github.com/jnuyens/modulejail
sudo sh modulejail -p conservative
Зачем это важно как тренд: DirtyDecrypt обнаружили независимо, а уязвимость уже исправили — это говорит о том, что AI-assisted code analysis находит одни и те же классы ошибок быстрее чем когда-либо. Темп раскрытий этого месяца — не случайность, это новая норма.
Итог: mitigation-файл + ptrace_scope = закрыты все шесть CVE мая. Патч ядра ставим при ближайшем обслуживании. И да — это ещё не конец месяца.
#linux #kernel #cve #dirtydecrypt #security #sysadmin #admin_future
🪟 Windows: AD CS в майском обновлении получил постквантовую криптографию — и это важнее чем звучит
Коллеги, в шуме вокруг Secure Boot, RC4 и Patch Tuesday почти никто не заметил кое-что важное в майском обновлении Windows Server 2025. Тихо и без фанфар.
Майское обновление добавляет в AD CS поддержку постквантовой криптографии: ML-DSA-44, ML-DSA-65 и ML-DSA-87 на Windows Server 2025. Это позволяет администраторам начать оценивать постквантовые криптографические алгоритмы и проверять PQC-готовность корпоративных PKI-сред.
Что это такое и зачем нам это сейчас:
Атака «harvest now, decrypt later» — не теория. Спецслужбы нескольких стран активно предупреждают, что противники уже сейчас эксфильтруют зашифрованные данные в расчёте на квантовое дешифрование в течение ближайшего десятилетия. Для любых данных с требованиями конфиденциальности более 10 лет — решение должно приниматься сейчас.
Как попробовать уже сегодня:
Что сейчас работает и что нет: ранние тесты показывают многообещающие результаты для сценариев подписи, таких как code signing. Однако более широкие инфраструктурные нагрузки, включая TLS, VPN и Remote Desktop, пока ограничены.
Зачем начинать сейчас если TLS/VPN ещё не готовы: организации, начинающие миграцию в 2026 году, имеют достаточно времени для соответствия срокам устаревания 2030 года. Те кто ждут 2028-го — столкнутся со сжатой высокорисковой миграцией.
Итог: не деплоить в продакшн. Поднять тестовую CA, выпустить ML-DSA-65 сертификат, посмотреть на размеры и latency. Это час работы — и понимание что тебя ждёт через 2-3 года.
#windows #adcs #pki #postquantum #security #sysadmin #admin_future
Коллеги, в шуме вокруг Secure Boot, RC4 и Patch Tuesday почти никто не заметил кое-что важное в майском обновлении Windows Server 2025. Тихо и без фанфар.
Майское обновление добавляет в AD CS поддержку постквантовой криптографии: ML-DSA-44, ML-DSA-65 и ML-DSA-87 на Windows Server 2025. Это позволяет администраторам начать оценивать постквантовые криптографические алгоритмы и проверять PQC-готовность корпоративных PKI-сред.
Что это такое и зачем нам это сейчас:
Атака «harvest now, decrypt later» — не теория. Спецслужбы нескольких стран активно предупреждают, что противники уже сейчас эксфильтруют зашифрованные данные в расчёте на квантовое дешифрование в течение ближайшего десятилетия. Для любых данных с требованиями конфиденциальности более 10 лет — решение должно приниматься сейчас.
Как попробовать уже сегодня:
# ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ:
# Windows Server 2025 с майским обновлением KB5087539
# AD CS Certification Authority установлен и настроен
# Проверяем версию после обновления:
Get-ItemProperty `
"HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" |
Select-Object CurrentBuild, UBR
# Нужен build 26100.32860 или выше
# Открываем Certificate Authority MMC:
# certsrv.msc -> [CA Name] -> Properties -> Cryptography
# Через PowerShell — проверяем доступные PQC-алгоритмы:
# (Нужен Provider Category: Key Storage Provider)
certutil -csplist | Select-String "ML-DSA"
# Создаём тестовый PQC-сертификат (code signing сценарий):
# 1. В CA Properties -> Cryptography -> CSP: Microsoft Software Key Storage Provider
# 2. Signature algorithm: ML-DSA-65 (оптимальный баланс размер/безопасность)
# 3. Выпускаем тестовый cert только для code signing
# ПРЕДУПРЕЖДЕНИЕ о размерах:
# ML-DSA-65 цепочка сертификатов: ~10KB vs ~1.5KB у ECDSA
# Это влияет на TLS handshake latency
# Пока НЕ для TLS, VPN, RDP — только для code signing и оценки
# Проверяем выпущенные PQC-сертификаты:
certutil -CAInfo
certutil -view -out "SerialNumber,NotBefore,NotAfter,Subject,PublicKey"
Что сейчас работает и что нет: ранние тесты показывают многообещающие результаты для сценариев подписи, таких как code signing. Однако более широкие инфраструктурные нагрузки, включая TLS, VPN и Remote Desktop, пока ограничены.
Зачем начинать сейчас если TLS/VPN ещё не готовы: организации, начинающие миграцию в 2026 году, имеют достаточно времени для соответствия срокам устаревания 2030 года. Те кто ждут 2028-го — столкнутся со сжатой высокорисковой миграцией.
Итог: не деплоить в продакшн. Поднять тестовую CA, выпустить ML-DSA-65 сертификат, посмотреть на размеры и latency. Это час работы — и понимание что тебя ждёт через 2-3 года.
#windows #adcs #pki #postquantum #security #sysadmin #admin_future
🔥1
🧠 Skills: Май 2026 — разбор полётов. Чему нас научил этот месяц
Коллеги, среда — хороший момент для рефлексии в середине недели. Май 2026 ещё не закончился, но уже войдёт в учебники по security operations. Разберём что реально можно взять из этого месяца.
Шесть CVE в Linux за три недели. Patch Tuesday со 120 CVE. RC4 enforcement в июле. Secure Boot до июня. Entra hard match 1 июня. DirtyDecrypt сегодня утром.
Три вещи которые работали и три которые нет:
Один практический вывод в виде действия прямо сейчас:
Зачем это важно как навык:
Реакция на инциденты — это мышца. Май 2026 её неплохо потренировал. Команды которые вышли из этого месяца с отлаженным процессом — в следующий раз среагируют за часы, а не за дни.
Итог: три недели CVE-шторма показали кто автоматизирован, кто нет. Кто мониторит правильное, кто реагирует на заголовки. Это не критика — это диагностика. Используй её.
#skills #security #процессы #автоматизация #sysadmin #admin_future
Коллеги, среда — хороший момент для рефлексии в середине недели. Май 2026 ещё не закончился, но уже войдёт в учебники по security operations. Разберём что реально можно взять из этого месяца.
Шесть CVE в Linux за три недели. Patch Tuesday со 120 CVE. RC4 enforcement в июле. Secure Boot до июня. Entra hard match 1 июня. DirtyDecrypt сегодня утром.
Три вещи которые работали и три которые нет:
ЧТО РАБОТАЛО:
1. МОНИТОРИНГ ПРАВИЛЬНЫХ ИСТОЧНИКОВ
Команды которые быстро реагировали — подписаны на:
- CISA KEV (daily digest)
- Ubuntu/RHEL security advisories (RSS/email)
- Hacker News /new (для zero-day до патча)
Не на твиттер и не на агрегаторы с задержкой в день.
2. BLACKLIST КАК ВРЕМЕННЫЙ ЩИТ
Кто заблокировал algif_aead/esp4/esp6/rxrpc в первый день —
спокойно ставил патчи по расписанию.
Кто ждал патча сразу — жил три недели под риском.
3. ЧЁТКИЙ ПРОЦЕСС ПРИОРИТИЗАЦИИ
5 вопросов: есть ли в моей среде? активно эксплуатируется?
вектор атаки? митигейшн? когда патч?
Экономит 80% времени на панику.
ЧТО НЕ РАБОТАЛО:
1. "ПРОПАТЧИМ НА СЛЕДУЮЩЕЙ НЕДЕЛЕ"
Copy Fail появился 29 апреля с публичным PoC.
CISA KEV — 1 мая. Дедлайн — 15 мая.
Кто ждал плановый цикл через две недели —
работал без защиты неделю с известным рабочим эксплойтом.
2. РУЧНОЙ BLACKLIST БЕЗ АВТОМАТИЗАЦИИ
Каждая новая CVE требовала нового захода на каждый сервер.
ModuleJail — ответ на это. IaC-подход — правильный ответ.
3. РЕАКЦИЯ НА ЗАГОЛОВКИ БЕЗ ПРОВЕРКИ СРЕДЫ
"Copy Fail затрагивает все дистрибутивы с 2017 года!"
— да, но только при наличии загруженного algif_aead.
На many продакшн-серверах его нет.
Паника тратит ресурсы которые нужны на реальные угрозы.
Один практический вывод в виде действия прямо сейчас:
# Если после этого месяца у тебя нет этих трёх вещей — сделай сегодня:
# 1. ПОДПИСКА НА CISA KEV (RSS для мониторинга)
# https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
# Добавь в любой RSS-ридер или настрой скрипт
# 2. ПРОВЕРКА KERNEL MITIGATION СТАТУСА
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc" && \
echo "РИСК: модули загружены" || \
echo "OK: модули не загружены"
# 3. ANSIBLE PLAYBOOK ДЛЯ RAPID BLACKLIST DEPLOY
# Один playbook который за 2 минуты закрывает флот
# вместо ручного захода на каждый сервер:
# ---
# - name: Kernel module mitigations May 2026
# hosts: all
# become: true
# tasks:
# - name: Block vulnerable kernel modules
# copy:
# dest: /etc/modprobe.d/may2026-mitigations.conf
# content: |
# install algif_aead /bin/false
# install esp4 /bin/false
# install esp6 /bin/false
# install rxrpc /bin/false
Зачем это важно как навык:
Реакция на инциденты — это мышца. Май 2026 её неплохо потренировал. Команды которые вышли из этого месяца с отлаженным процессом — в следующий раз среагируют за часы, а не за дни.
Итог: три недели CVE-шторма показали кто автоматизирован, кто нет. Кто мониторит правильное, кто реагирует на заголовки. Это не критика — это диагностика. Используй её.
#skills #security #процессы #автоматизация #sysadmin #admin_future
🐧 Linux: Май 2026 закрыт — финальный чеклист по ядру для тех кто ещё не всё сделал
Коллеги, четверг 21 мая — подводим итог самому насыщенному security-месяцу в Linux за несколько лет. Шесть уязвимостей, все патчи вышли, но статистика показывает: большая часть флотов ещё не обновлена.
Это четвёртая уязвимость ядра Linux требующая внимания администраторов за три недели, после Copy Fail (29 апреля), Dirty Frag (7 мая) и Fragnesia (13 мая). Если вы не хотите экстренно патчить и перезагружать несколько раз в месяц — это сигнал выстроить систему.
Финальный чеклист на сегодня:
Один архитектурный вывод из мая: AI-assisted code analysis нашёл несколько уязвимостей в одной и той же поверхности атаки за три недели. Вопрос для 2026 года — не будут ли продолжаться kernel-эксплойты, а будет ли ваша инфраструктура защищена когда они появятся.
Итог: патч + перезагрузка + mitigation-файл + ptrace_scope. Четыре пункта. Если не сделано — сделай прямо сейчас, это последний четверг мая.
#linux #kernel #security #patch #sysadmin #admin_future
Коллеги, четверг 21 мая — подводим итог самому насыщенному security-месяцу в Linux за несколько лет. Шесть уязвимостей, все патчи вышли, но статистика показывает: большая часть флотов ещё не обновлена.
Это четвёртая уязвимость ядра Linux требующая внимания администраторов за три недели, после Copy Fail (29 апреля), Dirty Frag (7 мая) и Fragnesia (13 мая). Если вы не хотите экстренно патчить и перезагружать несколько раз в месяц — это сигнал выстроить систему.
Финальный чеклист на сегодня:
# ШАГ 1: Проверяем версию ядра — все патчи закрыты начиная с:
# 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207 / 5.10.256
uname -r
# ШАГ 2: Если ядро не обновлено — ставим немедленно
# Ubuntu/Debian:
apt update && apt full-upgrade -y
# RHEL/Rocky/AlmaLinux:
dnf update kernel -y
# ШАГ 3: Mitigation-файл — закрывает все page-cache CVE даже без патча
cat /etc/modprobe.d/may2026-kernel-lpe.conf 2>/dev/null || \
printf "install algif_aead /bin/false\ninstall esp4 /bin/false\n\
install esp6 /bin/false\ninstall rxrpc /bin/false\n" | \
tee /etc/modprobe.d/may2026-kernel-lpe.conf
# ШАГ 4: ptrace_scope — закрывает CVE-2026-46333 (чтение SSH-ключей)
sysctl kernel.yama.ptrace_scope
# Если 0 — ставим минимум 1:
echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ШАГ 5: ModuleJail — системное решение для флота
# После патча и перезагрузки — автоматически блокирует ВСЕ
# неиспользуемые модули, не только эти шесть:
# github.com/jnuyens/modulejail
sudo sh modulejail -p conservative
# ШАГ 6: Проверяем что drop_caches сброшен на хостах
# где могла быть эксплуатация (критично для Fragnesia):
echo 1 | tee /proc/sys/vm/drop_caches
Один архитектурный вывод из мая: AI-assisted code analysis нашёл несколько уязвимостей в одной и той же поверхности атаки за три недели. Вопрос для 2026 года — не будут ли продолжаться kernel-эксплойты, а будет ли ваша инфраструктура защищена когда они появятся.
Итог: патч + перезагрузка + mitigation-файл + ptrace_scope. Четыре пункта. Если не сделано — сделай прямо сейчас, это последний четверг мая.
#linux #kernel #security #patch #sysadmin #admin_future
🪟 Windows: Secure Boot — 10 дней до истечения, финальный чеклист для серверов
Коллеги, конец июня — не абстрактный дедлайн. Две из трёх затронутых сертификатов — Microsoft Corporation KEK CA 2011 и Microsoft UEFI CA 2011 — истекают в июне 2026. Microsoft Windows Production PCA 2011, подписывающий сам Windows Boot Manager, истекает в октябре 2026.
Что произойдёт если не успеть: системы без обновления потеряют возможность устанавливать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.
Критически важное для серверов: в отличие от Windows PC, которые получают сертификаты 2023 года автоматически через Controlled Feature Rollout, Windows Server требует ручного действия — автоматически они не прилетают.
Устройства оффлайн, в спящем режиме, на полке — не получат обновления и рискуют оказаться изолированными после июня 2026. Старое железо без OEM firmware-обновлений также в опасности.
Итог: если у тебя есть серверы со статусом NOT_STARTED — это твоя задача на сегодня. Не на следующей неделе. Сегодня. До июня осталось меньше шести недель.
#windows #secureboot #windowsserver #security #sysadmin #admin_future
Коллеги, конец июня — не абстрактный дедлайн. Две из трёх затронутых сертификатов — Microsoft Corporation KEK CA 2011 и Microsoft UEFI CA 2011 — истекают в июне 2026. Microsoft Windows Production PCA 2011, подписывающий сам Windows Boot Manager, истекает в октябре 2026.
Что произойдёт если не успеть: системы без обновления потеряют возможность устанавливать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.
Критически важное для серверов: в отличие от Windows PC, которые получают сертификаты 2023 года автоматически через Controlled Feature Rollout, Windows Server требует ручного действия — автоматически они не прилетают.
# ФИНАЛЬНЫЙ АУДИТ — выполнить сегодня
# 1. Сколько серверов НЕ готово:
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -ExpandProperty Name
$report = foreach ($s in $servers) {
try {
Invoke-Command -ComputerName $s -ScriptBlock {
$sb = Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue
[PSCustomObject]@{
Server = $env:COMPUTERNAME
Status = if ($sb) {$sb.UEFICA2023Status} else {"NOT_STARTED"}
SecureBoot = (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)
}
} -ErrorAction Stop
} catch {
[PSCustomObject]@{Server=$s; Status="UNREACHABLE"; SecureBoot=$null}
}
}
$report | Group-Object Status | Format-Table Name, Count -AutoSize
# Экспортируем список на обработку:
$report | Where-Object {$_.Status -ne "Updated"} |
Export-Csv "secureboot_critical_$(Get-Date -Format yyyyMMdd).csv" `
-NoTypeInformation
# 2. Запускаем обновление на серверах NOT_STARTED:
# Выполнить на каждом затронутом сервере:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Перезагрузить, затем запустить ещё раз
# Проверить статус: должен стать "Updated"
# 3. Offline / air-gapped серверы — ручной путь:
# Скачать пакет с aka.ms/GetSecureBoot
# Применить через DISM или wusa.exe
# 4. Проверяем dbx (список отозванных bootloader-ов):
# Актуальный dbx критичен вместе с новыми сертификатами
Get-SecureBootUEFI -Name dbx | Select-Object -ExpandProperty Bytes | Measure-Object
# Пустой или нулевой dbx = риск
Устройства оффлайн, в спящем режиме, на полке — не получат обновления и рискуют оказаться изолированными после июня 2026. Старое железо без OEM firmware-обновлений также в опасности.
Итог: если у тебя есть серверы со статусом NOT_STARTED — это твоя задача на сегодня. Не на следующей неделе. Сегодня. До июня осталось меньше шести недель.
#windows #secureboot #windowsserver #security #sysadmin #admin_future