现已上线！2025 年 Telegram 研究 — 年度关键洞察 
Admin Future
前往频道在 Telegram
Превращаем эникейщиков в System Architects. 🚀 Твой навигатор в мире IT-инфраструктуры: ▪️ Hard Skills: Linux, Windows, Network, Security ▪️ Tools: Лучший софт и скрытые фишки ▪️ Mindset: Как думать, чтобы платили много Админ - @maksimshap
显示更多242
订阅者
无数据24 小时
-167 天
-1330 天
帖子存档
242
🐧 Linux: CVE-2026-46333 — Qualys опубликовала полный advisory. Ротируй SSH-ключи.
Коллеги, пятница — и свежие подробности по уязвимости, которую разбирали на этой неделе. Qualys Threat Research Unit опубликовала полный технический advisory по CVE-2026-46333, и там есть детали которые меняют оценку риска.
TRU идентифицировала узкое окно в котором привилегированный процесс, сбрасывающий свои учётные данные, остаётся доступным через ptrace-операции даже когда флаг dumpable должен был закрыть этот путь. Комбинируя это окно с системным вызовом pidfd_getfd() (добавленным в ядро в январе 2020), атакующий может перехватить открытые файловые дескрипторы умирающего привилегированного процесса и унаследовать его доступ к файлам — включая приватные SSH-ключи хоста.
На хостах где в период уязвимости были непривилегированные пользователи — SSH host keys и локально кэшированные учётные данные следует считать потенциально раскрытыми. Qualys рекомендует ротировать host keys и проверить весь административный материал находившийся в памяти setuid-процессов.
# ШАГ 1: Патч уже есть — проверяем версию ядра
uname -r
# Патч в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207
# Если старше — обновляем НЕМЕДЛЕННО:
apt update && apt full-upgrade -y && reboot # Ubuntu/Debian
dnf update kernel -y && reboot # RHEL/Rocky/AlmaLinux
# ШАГ 2: Была ли уязвимость активна? Смотрим были ли local users:
last | grep -v "^reboot\|^wtmp" | \
awk '{print $1}' | sort -u
# Если только root — риск ниже. Если были другие — ротируем ключи.
# ШАГ 3: Ротация SSH host keys (если есть подозрение на компрометацию):
# Генерируем новые ключи:
rm /etc/ssh/ssh_host_*
ssh-keygen -A
# Перезапускаем SSH (NOT текущую сессию — откроем новую первой):
systemctl restart sshd
# Обновляем known_hosts на всех клиентах:
ssh-keyscan -H <server_ip> >> ~/.ssh/known_hosts
# ШАГ 4: Митигейшн если патч ещё не применён:
# ptrace_scope = 2 блокирует только root может ptrace непривилегированных
echo "kernel.yama.ptrace_scope = 2" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope = 3 — полный запрет (ломает отладчики, gdb, strace)242
🧠 Skills: Май 2026 — итог месяца для тех кто дочитал до пятницы
Шесть уязвимостей ядра Linux. Patch Tuesday со 120 CVE. Kerberos RC4 enforcement. Secure Boot истечение. Entra hard match. Windows Server Summit. PostQuantum в AD CS. ModuleJail. DirtyDecrypt. Killswitch-proposal.
Это не был лёгкий месяц.
Но вот что важно: всё это было управляемо. Каждая из этих угроз имела митигейшн, опубликованный в течение часов после раскрытия. Каждый дедлайн был известен заранее. Каждое обновление было доступно до того как ситуация стала критической.
Три вещи которые отделяли тех кто справился от тех кто нет:
1. МОНИТОРИНГ ПРАВИЛЬНЫХ ИСТОЧНИКОВ Не твиттер, не агрегаторы. CISA KEV → RSS → алерт на email или в мессенджер Ubuntu/RHEL security advisory → email subscription Microsoft Security Update Guide → RSS Это 20 минут настройки однажды vs постоянный шум. 2. ПРОЦЕСС А НЕ ПАНИКА Пять вопросов для любого CVE: Есть ли в моей среде? Активно эксплуатируется? Вектор атаки? Есть ли митигейшн? Когда патч? Структура превращает "срочно всё горит" в управляемые действия. 3. АВТОМАТИЗАЦИЯ РУТИНЫ Кто запустил ModuleJail один раз — не правил blacklist 5 раз. Кто выстроил Ansible-пайплайн — не заходил вручную на 30 серверов. Кто настроил мониторинг Secure Boot — узнал о проблеме в феврале а не в июне.Один честный вопрос для выходных: Возьми любую из майских угроз. Спроси себя: "Сколько времени прошло между раскрытием и моим первым действием?" Один день — отлично. Три дня — приемлемо. Неделя — есть над чем работать. Больше — это не проблема знаний, это проблема процесса. Июнь 2026 принесёт свои сюрпризы. Они будут другими. Но твоя способность реагировать — это мышца которую прокачал май. Либо прокачал, либо нет. Вы прошли самый насыщенный месяц в истории канала. Если инфраструктура работает — вы сделали всё правильно. Этого достаточно. #skills #итоги #май2026 #security #процессы #sysadmin #admin_future
242
🪟 Windows: Пятничный дайджест — что закрыть до выходных по майским дедлайнам
Коллеги, конец рабочей недели — самое время для быстрой проверки: что из майских задач закрыто, а что уйдёт в понедельник с риском стать проблемой.
Три критических дедлайна ближайших недель — статус на сегодня:
Secure Boot — истечение в июне (осталось ~5 недель):
Системы без обновлённых сертификатов Secure Boot потеряют возможность получать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.
Entra hard match — дедлайн 1 июня (осталось 10 дней):
С 1 июня блокируется возможность синхронизировать cloud-privileged учётки через Entra Connect. Если не проверено — проверь прямо сейчас.
Kerberos RC4 — финал в июле (осталось ~6 недель):
После июля реестровый ключ RC4DefaultDisablementPhase игнорируется. Если не провёл аудит Event 201/202 — время поджимает.
# ПЯТНИЧНЫЙ ЧЕКЛИСТ — 3 команды, 5 минут:
# 1. Secure Boot статус (топ-10 серверов по риску):
Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -First 10 Name |
ForEach-Object {
Invoke-Command -ComputerName $_.Name -ScriptBlock {
$sb = Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -EA SilentlyContinue
"$env:COMPUTERNAME : $(if($sb){$sb.UEFICA2023Status}else{'NOT_STARTED'})"
} -EA SilentlyContinue
}
# 2. RC4 — сколько событий за эту неделю (если много — срочно):
Get-WinEvent -LogName System -ComputerName (hostname) |
Where-Object {$_.Id -in @(201,202,203) -and
$_.TimeCreated -gt (Get-Date).AddDays(-7)} |
Group-Object Id | Select-Object Name, Count
# 3. Entra hard match — есть ли привилегированные sync'd учётки:
# (быстрая проверка без Graph модуля)
Get-ADUser -Filter {Enabled -eq $true} `
-Properties MemberOf, adminCount |
Where-Object {$_.adminCount -eq 1} |
Select-Object SamAccountName, DistinguishedName |
Export-Csv "friday_privcheck.csv" -NoTypeInformation
Write-Host "Привилегированных учёток: $((Import-Csv friday_privcheck.csv).Count)"
# Если > 20 — стоит пересмотреть список до понедельникаЧТО МОЖНО ЗАКРЫТЬ ЗА 30 МИНУТ: - Запустить Secure Boot update task на 5-10 серверах - Посмотреть RC4 events за неделю - Сохранить список NOT_STARTED серверов для понедельника ЧТО НЕ ТРОГАТЬ В ПЯТНИЦУ ВЕЧЕРОМ: - Не менять пароли krbtgt без подготовки - Не обновлять DC в конце недели без снапшота - Не применять Kerberos-политики без тестовой группыИтог: пятница — для аудита и планирования, не для опасных изменений. Три команды выше покажут где ты стоишь. Остальное — в понедельник с холодной головой. #windows #secureboot #kerberos #security #patchmanagement #sysadmin #admin_future
242
🐧 Linux: Rust теперь в APT — и это важнее чем кажется
Коллеги, на этой неделе случилось кое-что, о чём мало кто написал — но что касается каждого администратора Debian/Ubuntu-флота напрямую.
Два события мая 2026 окончательно переместили Rust из категории «языка будущего» в load-bearing инфраструктуру. Первое: Linux 7.0 убрал пометку experimental с Rust — теперь это официальный язык ядра наравне с C. Второе: APT maintainer Julian Klode объявил что Debian's package manager начинает требовать жёсткую зависимость от Rust начиная с мая 2026.
Что это значит практически для администратора:
APT — это package manager для Debian и каждого производного дистрибутива: Ubuntu, Linux Mint, Pop!_OS, Kali Linux, Raspberry Pi OS. Rust-компилятор, стандартная библиотека и части Sequoia PGP теперь встроены в core APT — для парсинга .deb, .ar и .tar файлов, а также HTTP signature verification.
Зачем Rust именно здесь? APT обрабатывает недоверенные данные (пакеты из интернета) на уровне root. Memory corruption в парсере пакетов — это immediate root compromise. Rust устраняет целые классы уязвимостей вроде use-after-free, которые типичны для C-кода. Это интеграция снижает реальную поверхность атаки в местах где это наиболее критично.
# Проверяем Rust в APT на Ubuntu 26.04:
apt-cache show apt | grep -i rust
dpkg -l | grep -i "rust\|rustc"
# Для администраторов air-gapped сред:
# APT теперь требует rustc при сборке из исходников
# Проверяем что offline-репозиторий включает rust-пакеты:
apt-get install --dry-run apt 2>&1 | grep -i rust
# Для Debian 13 Forky (выход 2027):
# Rust будет требоваться для сборки ядра модулей через DKMS
# Уже сейчас можно подготовить offline-кэш:
apt-get download rustc cargo libstd-rust-dev
# Смотрим версию Rust в системе:
rustc --version 2>/dev/null || echo "Rust not installed"
# На Ubuntu 26.04 должно быть 1.80+ из репозиторияapt upgrade если Rust недоступен.
Итог: Rust перешёл из «интересно, но не моя проблема» в «часть базовой инфраструктуры моего дистрибутива». Пятница — хороший момент проверить offline-репы.
#linux #rust #debian #ubuntu #apt #security #sysadmin #admin_future242
🧠 Skills: Crypto Agility — навык который нужен сисадмину прямо сейчас, а не в 2030-м
Коллеги, пятничный пост в четверг — потому что тема важная, а пятницу займёт что-нибудь свежее.
Май 2026 дал нам два отличных примера почему crypto agility — это не теоретическая концепция. Secure Boot 2011 → 2023: ротация корневых сертификатов требует ручного вмешательства на тысячах серверов. RC4 в Kerberos: 30 лет использовали, теперь принудительное отключение в июле. Оба случая — болезненная миграция из-за отсутствия гибкости.
Crypto agility — это способность менять криптографические алгоритмы и ключи без переписывания всей инфраструктуры. Это не про квантовые компьютеры. Это про то, что алгоритмы устаревают регулярно.
Три практических элемента которые нужны прямо сейчас:
ЭЛЕМЕНТ 1: КРИПТОГРАФИЧЕСКАЯ ИНВЕНТАРИЗАЦИЯ
Что нужно знать о каждом сервисе:
- Какие алгоритмы используются (RSA? ECDSA? AES?)
- Где хранятся ключи и сертификаты
- Когда истекают сертификаты
- Какие зависимости (приложения, протоколы)
Инструменты:
# Linux: сканируем конфиги
grep -r "SSLProtocol\|SSLCipherSuite\|ssl_protocols\|ssl_ciphers" \
/etc/nginx/ /etc/apache2/ /etc/haproxy/ 2>/dev/null
# Проверяем TLS на работающих сервисах:
nmap --script ssl-enum-ciphers -p 443 <IP>
# Сертификаты в системе:
find /etc -name "*.crt" -o -name "*.pem" 2>/dev/null | \
xargs -I{} openssl x509 -in {} -noout -subject -enddate 2>/dev/null
# Windows: сертификаты в хранилищах
Get-ChildItem Cert:\LocalMachine\My |
Select-Object Subject, NotAfter, Thumbprint |
Sort-Object NotAfter
ЭЛЕМЕНТ 2: МОНИТОРИНГ СРОКА ЖИЗНИ
Автоматический алерт за 90/30 дней до истечения любого сертификата.
Это то чего не было для Secure Boot 2011 — никто не получил алерт
в 2024 году что через два года сертификаты истекут.
# Простой скрипт мониторинга сертификатов:
find /etc -name "*.crt" -o -name "*.pem" 2>/dev/null | \
while read cert; do
exp=$(openssl x509 -in "$cert" -noout -enddate 2>/dev/null | \
cut -d= -f2)
if [ -n "$exp" ]; then
exp_epoch=$(date -d "$exp" +%s 2>/dev/null)
now_epoch=$(date +%s)
days_left=$(( (exp_epoch - now_epoch) / 86400 ))
if [ "$days_left" -lt 90 ]; then
echo "WARN: $cert expires in $days_left days ($exp)"
fi
fi
done
ЭЛЕМЕНТ 3: ЗАМЕНА БЕЗ ДАУНТАЙМА
Для каждого критичного сервиса должен быть ответ на вопрос:
"Если нам нужно сменить сертификат/алгоритм прямо сейчас —
сколько это займёт и что потребует перезапуска?"
Если ответ "несколько дней и полный downtime" — это проблема.
Если "15 минут и горячая перезагрузка конфига" — это crypto agility.
nginx -s reload # Hot reload сертификата без downtime
systemctl reload apache2 # То же для Apache242
🪟 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 требует ручного действия — автоматически они не прилетают.
# ФИНАЛЬНЫЙ АУДИТ — выполнить сегодня
# 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 = риск242
🐧 Linux: Май 2026 закрыт — финальный чеклист по ядру для тех кто ещё не всё сделал
Коллеги, четверг 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_caches242
🧠 Skills: Май 2026 — разбор полётов. Чему нас научил этот месяц
Коллеги, среда — хороший момент для рефлексии в середине недели. Май 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
242
🪟 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 лет — решение должно приниматься сейчас.
Как попробовать уже сегодня:
# ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ:
# 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"
242
🐧 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:
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
242
🧠 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-доступом — это критично.
# НЕМЕДЛЕННАЯ ДИАГНОСТИКА:
# Смотрим были ли у нас непривилегированные пользователи
# с доступом к системе за последние сутки
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
242
🪟 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 нужно тщательно тестировать, так как неудачное обновление прошивки может окирпичить материнскую плату.
# Итоговая проверка статуса — прямо сейчас:
# Смотрим статус обновления сертификатов
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
242
🐧 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-файл.
# Установка и запуск за одну команду:
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
242
🧠 Skills: Как читать security advisory и не тратить час на каждый CVE
Коллеги, май 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
242
🪟 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 ИЮНЯ ----
# 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 10242
🐧 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.
# СТАТУС ПАТЧЕЙ — понедельник 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 ограничивает эксплуатацию
getenforce242
🧠 Skills: PDQ State of Sysadmin 2026 — цифра которая объясняет всё
Коллеги, пятница и последний май-пост по 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
242
🪟 Windows: WSUS мёртв — время признать это и выбрать замену
Коллеги, майский 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" -NoTypeInformation242
🐧 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.
# ФИНАЛЬНЫЙ СТАТУС ПАТЧЕЙ — проверяем прямо сейчас:
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"242
🧠 Skills: Как вести учёт своих инцидентов — личный журнал который меняет карьеру
Коллеги, четверг — хороший день для инструмента которым пользуются единицы, хотя он меняет многое.
Последние две недели — 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
- [ ] Обновить ядро когда патч появится в репо (трекеру неделя)1. СОБЕСЕДОВАНИЯ И РЕВЬЮ "Расскажи о сложном инциденте" — у тебя конкретные примеры с датами, решениями и выводами. Не "что-то было с ядром". 2. ПАТТЕРНЫ Перечитывая журнал за квартал — видишь что ломается чаще всего. Это твой список для превентивной работы. 3. ПЕРЕДАЧА ЗНАНИЙ Когда придёт новый человек или нужно делегировать — у тебя есть архив решений, а не только память.Зачем именно сейчас: Май 2026 — исключительно насыщенный месяц. Три LPE в Linux, Patch Tuesday с критическими DNS/Netlogon, RC4 в Kerberos до июля. Если не зафиксировать — через год всё это сольётся в «помню был какой-то хаос весной». Итог: пять минут после закрытия инцидента. Markdown-файл в личном репозитории. Через год это будет самый ценный документ в твоей карьере. #skills #инциденты #документация #карьера #sysadmin #admin_future
