🪟 Windows: Hotpatch по умолчанию с мая 2026 — разбираемся, что это значит для твоей инфраструктуры

Коллеги, тихая, но важная новость: начиная с майского обновления безопасности 2026 года, Windows Autopatch включает hotpatch-обновления по умолчанию для всех eligible-устройств под управлением Microsoft Intune. Если ты управляешь парком Windows 11 24H2 через Intune — с мая твои машины начнут получать патчи безопасности без перезагрузки. Автоматически. Хочешь ты этого или нет.

Разберём механику, подводные камни и что делать прямо сейчас.

Как это работает: hotpatch следует строгому квартальному циклу: в январе, апреле, июле и октябре — полное накопительное обновление с перезагрузкой (baseline), в остальные месяцы — hotpatch-пакеты, которые патчат только код запущенных процессов в памяти, без рестарта. Итого: 4 перезагрузки в год вместо 12.

Звучит идеально. Но есть нюансы:

# Проверяем, готово ли устройство к hotpatch
# Требования: Windows 11 24H2+, VBS включён, апрельский baseline установлен

# 1. Проверяем версию и билд
Get-ComputerInfo | Select-Object WindowsVersion, OsBuildNumber, OsDisplayVersion

# 2. Проверяем статус Virtualization-Based Security (обязательное требование)
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus
# 2 = Running (хорошо), 0 = Not enabled (hotpatch не получим)

# 3. Смотрим в Intune — статус по устройствам (через Graph API)
# Или через портал: Intune -> Devices -> Monitor -> Hotpatch quality update report

# 4. Если нужно ОТКЛЮЧИТЬ hotpatch для группы устройств или всего тенанта
# Intune -> Devices -> Windows updates -> Quality updates -> Edit policy
# Переключить "When available, apply without restarting" -> Block

# 5. Через реестр на конкретной машине (для тестовых сценариев)
Set-ItemProperty `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" `
  -Name "HotPatchRestrictions" `
  -Value 1 -Type DWORD
# Value 1 = отключить hotpatch, Value 0 = включить

# 6. Проверяем, какой тип обновления был установлен последним
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
# Hotpatch-обновления будут иметь KB-номер с пометкой "Hotpatch" в описании

Важное предупреждение, которое Microsoft тихо упомянула в документации: устройства с включённым hotpatch могут падать при операции "Reset This PC" — после первой фазы сброса машина перезагружается обратно на рабочий стол с ошибкой. Это задокументированная проблема. Если у тебя есть сценарии переустановки через Push Button Reset — проверь это в лабе до мая.

Зачем это нужно:
Устройства, установившие апрельский baseline и соответствующие требованиям, начнут автоматически получать hotpatch-обновления с 11 мая 2026 года. Если ты ещё не готов — контроль отказа доступен с 1 апреля через Intune. Срок уже прошёл. Проверяй настройки сегодня.

Итог: Меньше перезагрузок — это хорошо для uptime и для нервов пользователей. Но "включилось само" в enterprise без понимания механики — это риск. Проверь VBS на всём парке, убедись в апрельском baseline и реши явно: включаешь или отключаешь. Случайных изменений в инфраструктуре не бывает.

#windows #hotpatch #intune #autopatch #patching #sysadmin #admin_future

Зачем это нужно:
Обновление защищает от BlackLotus и аналогичных UEFI-буткитов, которые атакуют ранний процесс загрузки. После истечения 2011-сертификатов система не сможет получать mitigation-обновления против новых буткитов, даже если Patch Tuesday приходит вовремя.

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

#windows #secureboot #security #windowsserver #patching #sysadmin #admin_future

🪟 Windows: hotpatch в мае — что изменилось и одна важная ловушка

Коллеги, с 11 мая hotpatch включается по умолчанию для всех eligible Windows 11 24H2 устройств через Intune. Разбираем быстро что важно знать прямо сейчас.

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

Схема простая: 4 раза в год (январь, апрель, июль, октябрябрь) — полный baseline с перезагрузкой. Остальные 8 месяцев — hotpatch без рестарта.

Но апрельский цикл преподнёс сюрприз: установка KB5091157 (OOB-фикс для апрельского Patch Tuesday) требует перезагрузки и приостанавливает hotpatching. Hotpatch-обновления возобновятся только после июльского baseline. То есть если поставили фикс — ближайшие два месяца работаете в обычном режиме.

# Проверяем статус hotpatch на устройстве
Get-WmiObject -Namespace "root\cimv2" `
  -Class Win32_QuickFixEngineering |
  Sort-Object InstalledOn -Descending |
  Select-Object HotFixID, InstalledOn -First 5

# Смотрим включён ли hotpatch через реестр
Get-ItemProperty `
  -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Update\TargetingInfo\Installed\*" `
  -ErrorAction SilentlyContinue |
  Where-Object { $_.Name -like "*Hotpatch*" }

# В Intune — статус через Graph API
# Intune Portal → Devices → Windows updates →
# Quality updates → Hotpatch quality update report

# Проверяем VBS (обязательное требование для hotpatch):
Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus
# 2 = Running (можно hotpatch), 0 = отключён (hotpatch не работает)

Зачем это нужно:
После установки OOB KB5091157 с перезагрузкой hotpatching приостанавливается до июльского baseline. Это задокументированное поведение — планируй обслуживание соответственно.

Итог: hotpatch — хорошая технология. Но "включилось само" без понимания цикла — это потеря контроля над maintenance windows. Проверь VBS и пойми свой текущий статус до 11 мая.

#windows #hotpatch #intune #patching #sysadmin #admin_future

🧠 Skills: EOL-трекер — самый недооценённый инструмент в арсенале администратора

Коллеги, вопрос на пятницу: вы знаете, какое ПО в вашей инфраструктуре уходит на EOL в следующие 12 месяцев?

Не "примерно знаете". Точно. С датами.

Если нет — вы уже опаздываете. CentOS 7 умер в 2024-м и до сих пор живёт в продакшне у большинства. Ubuntu 20.04 LTS уходит в апреле 2025-го. Python 3.9 EOL был в октябре 2025-го. Каждый из них — потенциальная уязвимость без патчей и потенциальный инцидент.

Практический минимум: один источник правды для всего EOL в вашей инфраструктуре.

# ---- endoflife.date — лучший бесплатный EOL-трекер ----
# API бесплатный, покрывает 300+ продуктов

# Проверяем конкретную версию прямо из CLI:
curl -s https://endoflife.date/api/ubuntu/22.04.json | \
    python3 -m json.tool
# Покажет: eol date, lts, support status

# Скрипт: проверяем весь стек разом
#!/bin/bash
PRODUCTS=("ubuntu/22.04" "rhel/9" "postgresql/14" "python/3.10" "nginx/1.24")
echo "=== EOL CHECK $(date +%Y-%m-%d) ==="
for p in "${PRODUCTS[@]}"; do
    result=$(curl -s "https://endoflife.date/api/${p}.json")
    eol=$(echo $result | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('eol','unknown'))")
    support=$(echo $result | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('support','unknown'))")
    echo "$p | EOL: $eol | Support ends: $support"
done

# Пример вывода:
# ubuntu/22.04  | EOL: 2027-04-01 | Support ends: 2024-04-01
# rhel/9        | EOL: 2032-05-31 | Support ends: 2027-05-31
# postgresql/14 | EOL: 2026-11-12 | Support ends: 2026-11-12
# python/3.10   | EOL: 2026-10-04 | Support ends: 2026-10-04  <- скоро!
# nginx/1.24    | EOL: false      | Support ends: 2025-04-24  <- уже!

Как выстроить процесс:

1. ИНВЕНТАРИЗАЦИЯ (один раз, потом поддерживается)
   Список всех ОС + версий + приложений + версий
   Храним в Git, обновляем при каждом деплое

2. АВТОМАТИЧЕСКИЙ МОНИТОРИНГ (ежемесячно)
   Запускаем скрипт выше через CI/CD или cron
   Алерт если до EOL < 180 дней — планируем обновление
   Алерт если до EOL < 90 дней — критично, ставим в спринт

3. РАЗГОВОР С БИЗНЕСОМ (когда алерт сработал)
   "PostgreSQL 14 уходит на EOL 12 ноября 2026.
    После этой даты — нет патчей безопасности.
    Миграция на PG 17: 3 дня работы.
    Риск без миграции: [вставить стоимость инцидента]."

Зачем это нужно:
EOL-компонент без патчей — это не технический долг. Это открытая CVE без срока закрытия. Апрельский Cockpit RCE затронул установки, которые просто не обновлялись. Большинство громких инцидентов — это не zero-day, это известные уязвимости в давно устаревшем ПО.

Итог: endoflife.date + 15 строк bash + cron — и у тебя есть система которая скажет о проблеме за полгода, а не за день до инцидента.

#skills #eol #инфраструктура #patching #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

🐧 Linux: Неделя 24 закрылась — Samba, OpenSSL и ядро требуют перезагрузки. Планируем окно.

Коллеги, добрый понедельник. После июньского рекордного хаоса на стороне Windows, в Linux-мире неделя прошла относительно спокойно — но «спокойно» не значит «можно игнорировать». Разбираем что прилетело.

Эта неделя принесла обновления ядра и core-сервисов для OpenSSL, Samba и Apache. Они почти наверняка потребуют полной перезагрузки, поэтому планируйте окно обслуживания вокруг активного продакшн-трафика. Samba-обновление имеет критический рейтинг, потому что непропатченные file-sharing сервисы исторически были самой лёгкой точкой входа для ransomware-кампаний.

И AlmaLinux, и Rocky Linux выкатывают тяжёлую пачку advisory затрагивающих ядро, BIND DNS, OpenSSL и Samba. Пропуск этих патчей оставляет сети широко открытыми для RCE и кражи данных.

Важное предупреждение по процессу: сисадмины наблюдали как продакшн-кластеры зависали после применения kernel-патчей без предварительной проверки совместимости out-of-tree модулей. .NET-обновления также раскатываются по нескольким версиям — любые backend-сервисы на этих runtime потребуют быстрого рестарта для подхвата криптографических улучшений.

# ПЕРЕД kernel-апдейтом — проверяем out-of-tree модули
# (то что зависало кластеры у других):
# Смотрим какие модули НЕ из mainline:
grep -h "" /sys/module/*/taint 2>/dev/null
# Или ищем проприетарные/внешние модули:
for mod in $(lsmod | awk 'NR>1{print $1}'); do
    modinfo "$mod" 2>/dev/null | grep -q "intree:Y" || echo "OUT-OF-TREE: $mod"
done
# Типичные виновники: nvidia, vmware, zfs, virtualbox, drbd

# Проверяем что DKMS пересоберёт их под новое ядро:
dkms status

# ПОРЯДОК БЕЗОПАСНОГО ОБНОВЛЕНИЯ:
# 1. Snapshot/backup перед апдейтом (LVM/ZFS snapshot)
# 2. Обновляем но НЕ перезагружаемся:
apt update && apt full-upgrade -y --no-install-recommends  # Debian/Ubuntu
dnf update -y                                              # RHEL/Rocky/Alma

# 3. Проверяем что DKMS-модули собрались под новое ядро:
dkms status | grep installed

# 4. Перезагружаемся в окно обслуживания:
reboot

# 5. ПОСЛЕ перезагрузки — проверяем критичные сервисы:
systemctl --failed
ss -tlnp  # слушают ли нужные порты
# Для Samba:
smbclient -L localhost -N 2>&1 | head
# Для .NET:
systemctl status <ваши-dotnet-сервисы>

Итог: неделя 24 — про дисциплину процесса, не про панику. Snapshot перед апдейтом, проверка DKMS, перезагрузка в окно, верификация сервисов после. Samba — приоритет, ransomware любит непропатченный SMB.

#linux #kernel #samba #patching #security #sysadmin #admin_future