🪟 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 с повышенными привилегиями.

# Проверяем установлены ли майские обновления:
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. Ты это всё отработал, разобрался, закрыл. И через полгода это растворится в памяти как «что-то было с ядром в мае».

Личный журнал инцидентов — это не корпоративная документация. Это твой архив принятых решений.

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

Шаблон — пять минут после каждого инцидента:

## Инцидент: 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

🐧 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"

Один итоговый вывод про архитектуру:
Все три уязвимости — один класс: 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 сторонних приложений.

Три сценария и что выбрать в каждом:

СЦЕНАРИЙ 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

🧠 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

🐧 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 ограничивает эксплуатацию
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 ИЮНЯ ----

# 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 — это не про скорость чтения. Это про правильную последовательность вопросов.

Пять вопросов в порядке приоритета:

ВОПРОС 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-файл.

# Установка и запуск за одну команду:
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 нужно тщательно тестировать, так как неудачное обновление прошивки может окирпичить материнскую плату.

# Итоговая проверка статуса — прямо сейчас:
# Смотрим статус обновления сертификатов
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-доступом — это критично.

# НЕМЕДЛЕННАЯ ДИАГНОСТИКА:
# Смотрим были ли у нас непривилегированные пользователи
# с доступом к системе за последние сутки
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:

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 лет — решение должно приниматься сейчас.

Как попробовать уже сегодня:

# ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ:
# 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

🧠 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

Зачем это важно как навык:
Реакция на инциденты — это мышца. Май 2026 её неплохо потренировал. Команды которые вышли из этого месяца с отлаженным процессом — в следующий раз среагируют за часы, а не за дни.

Итог: три недели CVE-шторма показали кто автоматизирован, кто нет. Кто мониторит правильное, кто реагирует на заголовки. Это не критика — это диагностика. Используй её.

#skills #security #процессы #автоматизация #sysadmin #admin_future

🐧 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_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 требует ручного действия — автоматически они не прилетают.

# ФИНАЛЬНЫЙ АУДИТ — выполнить сегодня

# 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

🧠 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 # То же для Apache

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

Итог: инвентаризация + мониторинг + план замены. Это три часа работы которые меняют "паника в июне 2026" на "плановое обновление в марте 2026". Сделай это сейчас — следующий Secure Boot истечёт в 2033-м, и это уже твоя задача.

#skills #security #crypto #pkи #sysadmin #admin_future

🐧 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+ из репозитория

Для администраторов air-gapped и закрытых сред — это практическое действие сейчас: убедись что твои offline-репозитории содержат rust-пакеты. После обновления APT на системах без сети это может сломать apt upgrade если Rust недоступен.

Итог: Rust перешёл из «интересно, но не моя проблема» в «часть базовой инфраструктуры моего дистрибутива». Пятница — хороший момент проверить offline-репы.

#linux #rust #debian #ubuntu #apt #security #sysadmin #admin_future

🪟 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

🧠 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

🐧 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)

Также на неделе вышла PinTheft — отдельный LPE для Arch Linux систем. Если у тебя есть Arch в продакшне (надеюсь что нет) — смотри отдельный advisory.

Итог: если на хосте были local users в мае — ротируй SSH-ключи. Это 3 минуты работы и полное закрытие вектора постэксплуатации.

#linux #cve #ssh #security #kernel #sysadmin #admin_future