🪟 Windows: Июньский Patch Tuesday — рекорд за всю историю программы и три важных приоритета

Коллеги, вчера 10 июня вышел самый большой Patch Tuesday в истории. Разбираем что важно из 200 CVE.

Июньский релиз — крупнейший за всё время существования программы, включает 3 публично раскрытых zero-day, 33 критических уязвимости (28 из которых RCE) и ещё 55 RCE уязвимостей требующих немедленного внимания. Релиз вышел при 17 оставшихся днях до абсолютного дедлайна Secure Boot сертификатов 26 июня.

Три приоритета для сисадмина:

Приоритет 1 — Hyper-V guest escape (Critical): CVE-2026-47652, CVE-2026-45641 и CVE-2026-45607 — критические RCE уязвимости в Hyper-V способные позволить побег из виртуальной машины и выполнение кода. Если у вас Hyper-V — это патчить первым.

Приоритет 2 — HTTP/2 Bomb (CVE-2026-49160): атака злоупотребляет сжатием заголовков и управлением потоком HTTP/2 так что маленькие запросы вынуждают сервер аллоцировать непропорционально большие объёмы памяти и удерживать их. Для интернет-facing серверов с IIS — срочно.

Приоритет 3 — Nightmare Eclipse zero-days закрыты: исследователь под псевдонимом Nightmare Eclipse публично раскрыл серию Windows zero-days (BlueHammer, MiniPlasma, RedSun, UnDefend, YellowKey) в знак протеста против обращения Microsoft с его bug bounty программой. Все они закрыты в этом Patch Tuesday. Но исследователь предупредил о новом раскрытии 14 июня.

# Проверяем установлен ли июньский патч:
Get-HotFix | Where-Object {$_.InstalledOn -ge "2026-06-09"} |
    Select-Object HotFixID, InstalledOn |
    Sort-Object InstalledOn -Descending | Select-Object -First 3

# Проверяем Microsoft Defender Engine (CVE-2026-41091 — уже пропатчен через автообновление):
Get-MpComputerStatus | Select-Object AMEngineVersion
# Нужна версия 1.1.26040.8 или новее

# Для Hyper-V хостов — приоритет первый:
Get-VM | Select-Object Name, State, Version
# Ставим патч и перезагружаем хост в окно обслуживания

# HTTP.sys — проверяем открыт ли HTTP/2:
netsh http show servicestate | grep -i "http/2"
# Временный митигейшн — отключить HTTP/2:
netsh http add sslcert ... # или через IIS Manager -> HTTP/2 -> Disable

# Secure Boot — дедлайн 26 июня (15 дней):
Get-ItemProperty `
    "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
    -Name "UEFICA2023Status" -ErrorAction SilentlyContinue
# Если не "Updated" — немедленно запускаем:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Отдельное предупреждение: отраслевые аналитики указывают на отчётливый катализатор этого всплеска уязвимостей — ИИ. Корпоративные security-команды и независимые исследователи агрессивно используют автоматизированные LLM-инструменты для аудита кодовых баз, обнаруживая программные дефекты со скоростью и масштабом которые традиционная ручная проверка не может догнать.

Итог: 200 CVE, рекорд, три zero-day, Hyper-V escape. И Secure Boot истекает через 15 дней. Патчи — сегодня.

#windows #patchtuesday #hyper-v #security #sysadmin #admin_future

🧠 Skills: Nightmare Eclipse и кризис bug bounty — что это означает для всей индустрии

Коллеги, сегодня не только про патчи. Сегодня про ситуацию которая меняет правила игры для всего security-сообщества — и косвенно касается каждого администратора.

История: независимый исследователь под псевдонимом Nightmare Eclipse обнаружил серию критических уязвимостей в Windows и честно сообщил в Microsoft через официальные каналы. Microsoft удалила его аккаунт в MSRC и он не получил никакого вознаграждения. В ответ исследователь начал публично раскрывать уязвимости с рабочими PoC-эксплойтами. Microsoft ответила угрозами уголовного преследования, что вызвало огромную волну возмущения в security-сообществе. Microsoft отступила и заявила что не намерена преследовать исследователей.

Nightmare Eclipse представляет третью категорию: ответное раскрытие спровоцированное воспринятым нарушением со стороны вендора. Этот сценарий — когда исследователь исчерпывает официальные каналы и не получает ответа или получает активный вред — это известный сбой программ coordinated disclosure.

Почему это важно для тебя как администратора — три практических вывода:

ВЫВОД 1: ТЕМП ZERO-DAY УСКОРЯЕТСЯ

AI-assisted code analysis + недовольные исследователи +
сломанные bug bounty программы = больше публичных zero-day
без периода согласованного раскрытия.

Практическое следствие:
Patch Tuesday больше не единственный момент когда нужно
смотреть на безопасность Windows. Нужен:
  - RSS на MSRC: msrc.microsoft.com/update-guide
  - Подписка на BleepingComputer security alerts
  - CISA KEV daily check

ВЫВОД 2: DEFENDER ОБНОВЛЯЕТСЯ ОТДЕЛЬНО ОТ ОС

CVE-2026-41091 (Defender LPE) был пропатчен через автообновление
engine ДО Patch Tuesday. Если у тебя отключены автообновления Defender —
ты жил с активно эксплуатируемой уязвимостью несколько недель.

Проверяем и исправляем:
  Get-MpComputerStatus | Select-Object AMEngineVersion
  # Нужна >= 1.1.26040.8

  # Принудительное обновление Defender:
  Update-MpSignature -UpdateSource MicrosoftUpdateServer

ВЫВОД 3: BUG BOUNTY — ЭТО РИСК УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ

Когда вендор плохо управляет отношениями с исследователями —
уязвимости становятся публичными без патча.
Это системный риск для всех кто использует этот вендор.

Что делать: следить не только за CVE но и за конфликтами
в security-сообществе. Злой исследователь с PoC + дедлайн
"14 июня новое раскрытие" — это operational intelligence
которая влияет на приоритизацию патчинга прямо сейчас.

Microsoft's response, threatening prosecution rather than investigating the underlying bounty dispute, will make other researchers in similar situations less likely to attempt coordination at all. Это означает больше zero-day без предупреждения в будущем.

Итог: история с Nightmare Eclipse — это не просто скандал. Это сигнал что модель coordinated disclosure трещит под давлением AI-assisted vulnerability research и неработающих incentive-систем. Как администратор — готовься к более частым zero-day и выстраивай процессы реагирования соответственно.

#skills #security #zerodaybugs #bugbounty #patchmanagement #sysadmin #admin_future

🐧 Linux: Хватит терпеть зависания при OOM. Включаем PSI и systemd-oomd

Коллеги, добрый понедельник. Знакомая ситуация: на сервере потекла память, своп забился, load average улетел в космос, и вы даже по SSH зайти не можете. Классический OOM Killer в ядре срабатывает слишком поздно, когда система уже фактически в коме.

В 2026 году мы решаем это изящнее. Мы используем PSI (Pressure Stall Information) вместе с systemd-oomd. Этот демон убивает прожорливые cgroups ДО того, как операционная система намертво повиснет.

Скрипт для проверки и активации:

# Проверяем, включен ли PSI в ядре (вывод не должен быть пустым):
cat /proc/pressure/memory

# Если включен, активируем службу systemd-oomd:
systemctl enable --now systemd-oomd

# Смотрим статус и кто сейчас под угрозой:
oomctl status

Зачем это нужно:
Сервер должен оставаться управляемым при любых утечках памяти. Лучше пусть упадет один проблемный контейнер или веб-сервис, чем вся нода уйдет в hard reset по питанию, утащив за собой соседние процессы.

#linux #systemd #oom #performance #sysadmin #admin_future

🪟 Windows: SMB over QUIC — убиваем VPN для файловых шар

Коллеги, вчера мы ждали новых сюрпризов от Nightmare Eclipse (обещанный дроп 14 июня), но пока эфир относительно чист. Зато есть повод поговорить о хорошем. Больше никаких пробросов порта 445 и обязательных корпоративных VPN для доступа к рабочим файлам из дома.

В Windows Server 2025 технология SMB over QUIC окончательно стала мейнстримом. QUIC работает поверх протокола UDP (порт 443). Трафик всегда зашифрован TLS 1.3, провайдеры его не режут, а скорость при плохом мобильном интернете в разы выше классического TCP.

Как настроить в PowerShell:

# Проверяем поддержку на сервере:
Get-SmbServerConfiguration | Select-Object EnableSMBQUIC

# Включаем SMB over QUIC (потребуется привязать сертификат):
Set-SmbServerConfiguration -EnableSMBQUIC $true

# На клиенте (Windows 11) принудительно мапим сетевой диск через QUIC:
New-SmbMapping -LocalPath 'Z:' -RemotePath '\\fs.makshel.local\Share' -TransportType QUIC

Зачем это нужно:
Пользователи получают доступ к корпоративным шарам так же просто, как к облачному диску. А безопасники спят спокойно, потому что наружу торчит только стандартный 443 UDP порт, а не дырявый 445 TCP, который обожают шифровальщики.

#windows #windowsserver #quic #networking #sysadmin #admin_future

🧠 Skills: Усталость от алертов. Как Zabbix убивает вашу внимательность

Коллеги, если в вашей дежурной группе в Telegram каждый день сыпятся десятки сообщений "CPU Load is > 80%" или "Disk space < 20%", и вы их просто смахиваете, не читая — у вас серьезная проблема. Это называется Alert Fatigue (усталость от предупреждений).

В 2026 году мониторинг не должен быть логом событий. Алерт должен приходить ТОЛЬКО тогда, когда требуется немедленное действие живого человека.

Внедряем правило 3 вопросов для настройки любого триггера:

Это влияет на бизнес прямо сейчас?

Я должен бросить свой кофе и чинить это немедленно?

Если я проигнорирую это до завтрашнего утра, кто-то заметит?

Если хотя бы на один вопрос ответ "Нет" — смело переводим этот триггер в разрез инфо-дашбордов или утренних отчетов. Никаких пуш-уведомлений и красных значков.

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

#skills #monitoring #zabbix #management #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

🪟 Windows: Secure Boot — финальная неделя. 24 июня дедлайн, но Microsoft смягчила формулировки.

Коллеги, это последний понедельник перед дедлайном Secure Boot. Через 9 дней — 24 июня — истекает первый из сертификатов 2011 года. Но с хорошей новостью: Microsoft на втором AMA уточнила что это не «hard stop».

Microsoft уточнила: устройства продолжат функционировать даже если не завершили обновления до истечения сертификата Key Exchange Key (KEK) 24 июня 2026. Также Microsoft указала что сертификат Secure Boot DB остаётся валидным до октября 2026 — это даёт дополнительное время на подписание и распространение обновлённых boot manager-ов.

Что реально изменилось после июньского Patch Tuesday: июньский Patch Tuesday должен перевести большинство mainstream-устройств в категорию «high-confidence». Устройства классифицированные как high confidence могут получать Secure Boot обновления автоматически через Intune. Для устройств вне high-confidence категории администраторам может потребоваться вручную включить развёртывание через registry settings или политики Intune.

Ключевой совет от Microsoft: не откладывайте развёртывание в ожидании пока каждое устройство достигнет статуса high-confidence.

# ФИНАЛЬНЫЙ ЧЕКЛИСТ — последняя неделя

# 1. Проверяем confidence-статус через Intune:
# Intune -> Devices -> Monitor -> Secure Boot certificate report
# high confidence = автоматом, остальное = вручную

# 2. Проверяем статус на серверах:
$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 `
                "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
                -Name "UEFICA2023Status" -EA SilentlyContinue
            [PSCustomObject]@{
                Server=$env:COMPUTERNAME
                Status=if($sb){$sb.UEFICA2023Status}else{"NOT_STARTED"}
            }
        } -EA Stop
    } catch { [PSCustomObject]@{Server=$s; Status="UNREACHABLE"} }
}
$results | Group-Object Status | Format-Table Name, Count

# 3. Для NOT_STARTED — принудительно включаем (registry):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot" `
    /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Процесс занимает ~48 часов и одну-две перезагрузки

# 4. Проверяем что boot manager обновился (DB-сертификат до октября):
Confirm-SecureBootUEFI
Get-SecureBootUEFI -Name db | Select-Object -ExpandProperty Bytes |
    Measure-Object

Зачем не расслабляться несмотря на смягчение: десктопная версия этой истории раздражающая. Серверная — операционно серьёзная. Окружения Windows Server 2016, 2019, 2022 и 2025 могут быть затронуты, и путь к исправлению сложнее чем «нажми обновить и перезагрузись».

Итог: 24 июня — не катастрофа, а начало деградации защиты. DB-сертификат живёт до октября, это буфер. Но запусти обновление на NOT_STARTED серверах на этой неделе — процесс занимает двое суток.

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

🧠 Skills: Docs-as-Code — почему Confluence умирает и что приходит на смену

Коллеги, понедельник — хороший день для темы которая отделяет зрелые инфраструктуры от хаотичных. Документация.

Главная боль технической документации известна каждому: во-первых, её нет. Во-вторых, если она есть — она не актуальна. Confluence-страница, обновлённая последний раз в 2023-м, хуже чем отсутствие документации — она вводит в заблуждение.

Docs-as-Code решает это радикально: документация живёт там же где код, в том же git, проходит те же review.

Docs-as-Code — это методология которая говорит документировать так же как ты обращаешься с кодом — используя те же инструменты, workflow и системы контроля версий что разработчики используют для написания кода. Документация хранится в plain text (Markdown, AsciiDoc), в git-репозитории, с современным тулингом для генерации HTML, PDF.

Честная оговорка чтобы не было иллюзий: Docs-as-Code не обновляет документацию автоматически так же как обновляется код. Когда разработчик добавляет новый API endpoint — документация не сгенерируется сама, если для этого не настроены конкретные workflow и автоматизация.

Практический старт для сисадмина — не нужен GitBook за деньги:

МИНИМАЛЬНЫЙ DOCS-AS-CODE СТЕК (всё бесплатно):

Хранение:    Gitea / GitLab (self-hosted)
Формат:      Markdown (или AsciiDoc если нужны include и переменные)
Генерация:   MkDocs (Material theme) — статичный сайт из .md
Диаграммы:   Mermaid / PlantUML (текстом, версионируются)
CI/CD:       git hook → автодеплой при push

СТРУКТУРА РЕПОЗИТОРИЯ:
  docs/
  ├── infrastructure/
  │   ├── network-topology.md      # + Mermaid диаграмма inline
  │   ├── servers-inventory.md
  │   └── backup-strategy.md
  ├── runbooks/
  │   ├── RB-001-db-failover.md
  │   └── RB-002-cert-renewal.md
  ├── procedures/
  │   └── onboarding-new-server.md
  └── mkdocs.yml

# Поднять MkDocs за 5 минут:
pip install mkdocs-material --break-system-packages

# Инициализируем проект:
mkdocs new infra-docs && cd infra-docs

# Правим mkdocs.yml — тема Material:
cat > mkdocs.yml << 'EOF'
site_name: Infrastructure Docs
theme:
  name: material
  features:
    - search.suggest
    - content.code.copy
markdown_extensions:
  - pymdownx.superfences:
      custom_fences:
        - name: mermaid
          class: mermaid
EOF

# Локальный предпросмотр:
mkdocs serve  # http://127.0.0.1:8000

# Деплой как статика (git hook или CI):
mkdocs build  # генерит site/ — отдаём через nginx

# Диаграмма прямо в markdown (Mermaid):
# ```mermaid
# graph LR
#   Internet --> Firewall --> LB --> Web1 & Web2 --> DB
# ```

Один принцип который делает Docs-as-Code живым: хорошая документация должна непрерывно эволюционировать вместе с кодом который она описывает. Правило простое — изменил инфраструктуру, обнови doc в том же PR. Не «потом», а в том же коммите. Review не пропускает PR без обновления документации.

Зачем это сисадмину а не только разработчику: твои runbook, топология сети, процедуры onboarding — это и есть код инфраструктуры. В git они версионируются, ревьюятся, и главное — видно кто и когда менял. Confluence этого не даёт.

Итог: MkDocs + Gitea + правило «doc в том же PR» = документация которая не устаревает. Это вечер настройки и смена привычки. Попробуй на одном runbook на этой неделе.

#skills #docsascode #документация #mkdocs #git #sysadmin #admin_future

🐧 Linux: CIFSwitch — баг 2007 года даёт root одной командой. PoC опубликован.

Коллеги, добрая среда. Шестой LPE в ядре Linux за 2026 год — и снова из той же серии что Copy Fail, Dirty Frag, Fragnesia и DirtyDecrypt. На этот раз код прятался 19 лет.

CIFSwitch (CVE-2026-46243) — локальное повышение привилегий в CIFS-подсистеме ядра Linux. Уязвимость присутствовала в коде с 2007 года — 19 лет необнаруженной. На затронутых системах любой непривилегированный локальный пользователь может получить root-shell одной командой.

Исследователь Asim Manizada раскрыл баг 28 мая 2026 с рабочим PoC на GitHub в тот же день. CVE присвоен 1 июня, пропатченные ядра дошли до production-репозиториев 2 июня.

Хорошая новость — условия эксплуатации узкие: баг находится в fs/smb/client/cifs_spnego.c — коде который обрабатывает Kerberos/SPNEGO-аутентификацию для CIFS-клиента ядра. Для эксплуатации нужны два условия: установлен cifs-utils И разрешены unprivileged user namespaces.

cifs-utils не входит в дефолтную установку большинства систем, и типичные shared-hosting серверы его не несут — такие хосты не уязвимы. Проверьте флот перед действиями.

# ШАГ 1 — Проверяем уязвимы ли мы:
# Установлен ли cifs-utils:
which mount.cifs cifs.upcall 2>/dev/null
dpkg -l cifs-utils 2>/dev/null || rpm -q cifs-utils 2>/dev/null
# Если НЕ установлен — вы НЕ уязвимы, можно выдохнуть

# Разрешены ли unprivileged user namespaces:
sysctl kernel.unprivileged_userns_clone 2>/dev/null   # Debian/Ubuntu
sysctl user.max_user_namespaces                       # RHEL/CentOS

# ШАГ 2 — Патч уже в production-репах с 2 июня:
uname -r
apt update && apt full-upgrade -y && reboot   # Debian/Ubuntu
dnf update kernel -y && reboot                # RHEL/Rocky/AlmaLinux

# ШАГ 3 — МИТИГЕЙШН без перезагрузки (если cifs не нужен):
echo "install cifs /bin/false" > /etc/modprobe.d/disable-cifs.conf
rmmod cifs 2>/dev/null
# ВНИМАНИЕ: ломает монтирование SMB/CIFS шар!

# Или удаляем cifs-utils если SMB не нужен:
apt remove cifs-utils    # Debian/Ubuntu
dnf remove cifs-utils    # RHEL/Rocky/AlmaLinux
# Без cifs-utils эксплуатация невозможна

# Или отключаем user namespaces (ломает контейнеры):
sysctl -w kernel.unprivileged_userns_clone=0  # Debian/Ubuntu
sysctl -w user.max_user_namespaces=0          # RHEL/CentOS

# ШАГ 4 — Мониторинг (multi-tenant/CI/CD):
# Следим за request_key() с необычными cifs.spnego ключами:
auditctl -a always,exit -F arch=b64 -S request_key -k cifs_spnego

Зачем это важно как тренд: 19-летний возраст уязвимого кода и наличие публичного PoC означают что эксплуатация в дикой природе вероятна. Организациям не стоит ждать подтверждённых атак перед применением митигейшна.

Итог: проверь установлен ли cifs-utils. Нет — не уязвим. Есть — патч (уже в репах) или удали cifs-utils если SMB не нужен. Шестой LPE за год — паттерн очевиден.

#linux #kernel #cifswitch #cve #security #sysadmin #admin_future

🪟 Windows: DNS over HTTPS на сервере стал GA — шифруем DNS для клиентов

Коллеги, в июньском обновлении Windows Server 2025 (KB5094125) тихо приехала фича которую ждали — и которую затмили 206 CVE и Secure Boot. Разбираем.

Июньское обновление включает server-side DNS over HTTPS (DoH) как generally available. Это обеспечивает шифрованную DNS-коммуникацию между сервером и его клиентами, улучшая приватность и безопасность за счёт защиты DNS-запросов, особенно против определённых атак. Важно: DoH-поддержка применяется только к server-to-client коммуникации, не к шифрованию между серверами.

Почему это важно: DNS-запросы исторически идут открытым текстом. Любой кто видит трафик — видит какие домены резолвят твои клиенты. Для внутренней сети это вектор разведки при компрометации, для филиалов через недоверенные каналы — прямая утечка. DoH закрывает это на уровне DNS-сервера.

Также в этом же обновлении — важный фикс по теме которую мы разбирали в апреле:

Обновление решает проблему когда некоторые устройства могли входить в BitLocker recovery после обновления boot-файлов, на системах с определёнными настройками TPM validation (особенно невалидными PCR7-конфигурациями). Это поведение возникало после установки апрельского обновления KB5082063.

# Включаем DNS over HTTPS на Windows Server 2025 DNS-сервере:

# 1. Проверяем что июньское обновление установлено:
Get-HotFix -Id KB5094125 -ErrorAction SilentlyContinue

# 2. Включаем DoH на DNS-сервере:
Set-DnsServerSetting -Name "EnableDoHServer" -Value $true
# (точное имя командлета может отличаться — проверяем доступные:)
Get-DnsServerSetting -All | Select-String -Pattern "DoH|HTTPS"

# 3. Привязываем сертификат для DoH (нужен валидный TLS-сертификат):
# Сертификат с SAN = FQDN DNS-сервера
$cert = Get-ChildItem Cert:\LocalMachine\My |
    Where-Object {$_.Subject -like "*dns-server-fqdn*"}
# Регистрируем сертификат для DoH listener

# 4. Проверяем что DoH слушает (порт 443):
Get-NetTCPConnection -LocalPort 443 -State Listen |
    Where-Object {$_.OwningProcess -eq (Get-Process dns).Id}

# 5. Также новая GPO для контроля Secure Boot телеметрии:
# Computer Config -> Admin Templates -> Windows Components
# -> Secure Boot -> LimitSecureBootRequiredServiceData
# Позволяет ограничить какие Secure Boot данные уходят в Microsoft

# 6. Настраиваем клиентов на использование DoH:
# GPO: Computer Config -> Admin Templates -> Network -> DNS Client
# -> Configure DNS over HTTPS (DoH) name resolution -> Require DoH

Зачем включать сейчас: после месяцев фокуса на патчинге уязвимостей — это редкая возможность улучшить базовую безопасность инфраструктуры проактивно. Шифрование DNS закрывает целый класс пассивной разведки в сети.

Итог: июньское обновление это не только 206 CVE и Secure Boot. Это DoH server-side GA + фикс апрельской BitLocker-проблемы. Подними DoH в лабе на этой неделе — это базовая гигиена которую долго ждали в Windows Server.

#windows #dns #doh #windowsserver2025 #security #sysadmin #admin_future

🧠 Skills: Шесть LPE за год — пора признать что патчинг это не стратегия, а тактика

Коллеги, среда — день для стратегического взгляда. CIFSwitch стал шестым LPE в ядре Linux за 2026 год: Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt, ssh-keysign-pwn и теперь CIFSwitch. Это не случайность. Это новая норма.

Паттерн каждого из них одинаков: для сисадминов управляющих Linux-флотами в 2026 году паттерн реакции один и тот же каждый раз: применить no-reboot митигейшн немедленно, затем запланировать обновление ядра и перезагрузку.

Если ты реагируешь на каждый из них вручную — ты проиграл гонку ещё до старта. Нужна стратегия defence-in-depth которая защищает ДО появления конкретной CVE.

Три слоя которые превращают "паника на каждый LPE" в "плановую работу":

СЛОЙ 1: СОКРАЩЕНИЕ ПОВЕРХНОСТИ АТАКИ (проактивно)

Большинство LPE 2026 требуют специфичных модулей/фич:
  Copy Fail    → algif_aead
  Dirty Frag   → esp4/esp6/rxrpc
  CIFSwitch    → cifs + unprivileged userns

Если этих модулей нет — ты не уязвим автоматически.
Инструмент: ModuleJail (автоблок неиспользуемых модулей)
  sudo sh modulejail -p conservative

Или вручную blacklist всего что не используется.
KDE Linux team в мае сделала именно это — вернулись к vanilla
kernel и удалили небезопасные неиспользуемые модули после аудита.

СЛОЙ 2: ОГРАНИЧЕНИЕ NAMESPACE И PTRACE (один раз настроить)

Большая часть LPE 2026 пивотится через unprivileged user namespaces:
  # Ограничиваем (ломает некоторые контейнеры — тестируй):
  sysctl -w kernel.unprivileged_userns_clone=0

Ptrace-класс (ssh-keysign-pwn):
  sysctl -w kernel.yama.ptrace_scope=1

Это закрывает не одну CVE, а целый класс векторов.

СЛОЙ 3: RUNTIME-МОНИТОРИНГ ЦЕЛОСТНОСТИ ЯДРА

LKRG (Linux Kernel Runtime Guard) — детектирует попытки
эксплуатации в реальном времени, даже неизвестных CVE:
  modprobe lkrg
  sysctl -w lkrg.profile_enforce=2

Overhead ~1.7% на Intel, 0.1% на Ryzen. Для серверов приемлемо.

ИТОГОВАЯ МАТЕМАТИКА:
  Без слоёв: каждый LPE = ручной митигейшн × N серверов = часы паники
  Со слоями: каждый LPE = "у нас этот модуль уже заблокирован" = 0 паники
              + плановый патч в обычное окно обслуживания

Один честный вопрос для среды:
Возьми CIFSwitch. Спроси себя — "если бы у меня был ModuleJail и ограниченные namespaces, был бы я уязвим к нему из коробки?" Для большинства серверов ответ — нет. cifs-utils там не стоит, namespaces ограничены. Угроза стала бы "не моя проблема" автоматически.

Зачем это важно: organizations should not wait for confirmed attacks before applying mitigations. Но ещё лучше — построить инфраструктуру где конкретная CVE уже митигирована до её раскрытия. Это разница между тактикой и стратегией.

Итог: патчинг обязателен, но это тактика. Стратегия — сокращение поверхности атаки, ограничение namespace/ptrace и runtime-мониторинг. Построй три слоя один раз — и седьмой LPE года встретишь спокойно.

#skills #security #defenseindepth #kernel #стратегия #sysadmin #admin_future