🐧 Linux: AppArmor vs SELinux в 2026 — выбор который влияет на безопасность при следующем Copy Fail

Коллеги, Copy Fail дал нам хороший повод поговорить о вещи которую большинство откладывает. SELinux и AppArmor работали в режиме enforcing на ваших серверах в момент атаки? Или были отключены "потому что мешают"?

Одна из самых распространённых ошибок — отключить SELinux или AppArmor при первых проблемах. Вместо этого нужно использовать permissive (SELinux) или complain (AppArmor) режимы для отладки. Отключение этих слоёв оставляет систему открытой для атак повышения привилегий.

Быстрый выбор: SELinux — для RHEL/Rocky/AlmaLinux, AppArmor — для Ubuntu/Debian. Это не холивар, это дефолт дистрибутива.

# ---- APPARMOR (Ubuntu/Debian) ----
# Проверяем статус:
aa-status
apparmor_status | grep -E "profiles|processes"

# Включаем enforce для конкретного сервиса:
aa-enforce /etc/apparmor.d/usr.sbin.nginx
systemctl reload apparmor

# Смотрим нарушения в логах (complain mode — для диагностики):
aa-complain /etc/apparmor.d/usr.sbin.nginx
journalctl -k | grep apparmor | tail -20

# Создаём профиль для нового сервиса:
aa-genprof /usr/local/bin/myapp
# Запускаем сервис, делаем типичные операции, останавливаем
# aa-genprof предложит профиль на основе реального поведения

# ---- SELINUX (RHEL/Rocky/AlmaLinux) ----
# Проверяем статус:
getenforce  # Enforcing / Permissive / Disabled
sestatus

# Если Disabled — включаем через /etc/selinux/config:
sed -i 's/SELINUX=disabled/SELINUX=enforcing/' /etc/selinux/config
# Перезагрузка обязательна. Сначала переводим в Permissive:
sed -i 's/SELINUX=disabled/SELINUX=permissive/' /etc/selinux/config

# Смотрим что SELinux блокирует:
ausearch -m AVC -ts recent | tail -30
# Генерируем политику под конкретный deny:
ausearch -m AVC -ts recent | audit2allow -M mypolicy
semodule -i mypolicy.pp

# Проверяем нет ли процессов без confinement:
ps -eZ | grep unconfined_t

Начинайте с complain/permissive режима для одного конкретного сервиса, собирайте события под реальной нагрузкой, затем переводите в строгий режим. Резкое включение enforcing для всего почти гарантированно сломает что-то неочевидное — unix-сокеты, временные директории, кастомные пути логов.

Зачем именно сейчас:
Copy Fail требует локального доступа — но что если атакующий уже внутри через другую уязвимость? SELinux/AppArmor в enforcing ограничивает что может сделать скомпрометированный процесс даже с root-привилегиями.

Итог: запусти getenforce или aa-status прямо сейчас. Если не Enforcing — у тебя есть задача на эту пятницу.

#linux #apparmor #selinux #security #hardening #sysadmin #admin_future

🪟 Windows: Summit в понедельник — что смотреть и зачем идти именно на live Q&A

Коллеги, в понедельник 11 мая стартует Windows Server Summit 2026 — три дня, бесплатно, онлайн. Разбираем что там реально интересно для практикующего администратора.

Summit 2026 настроен под то что клиенты просили последние два года: меньше маркетинга, больше практического engineering-led контента. Три дня, три направления: новое в Windows Server 2025 включая hotpatch, гибридные сценарии через Azure Arc, лучшие практики патчинга и baseline-конфигурации.

Summit также станет ранним engagement-моментом для Windows Server v.Next — вы получите видимость направления Microsoft до того как планы будут официально объявлены. Каждая сессия включает live Q&A для прямого контакта с product team.

Что конкретно смотреть:

ДЕНЬ 1 (11 мая, 10:00-15:00 МСК):
  Приоритет: hotpatch — цикл, что сломалось в апреле,
  почему OOB-фикс прервал hotpatch и что будет в июле

  Обязательно спросить в Q&A:
  "Когда будет патч для PhantomRPC (нет CVE, нет фикса)?"
  "RC4 enforcement в июле — есть ли rollback после финализации?"

ДЕНЬ 2 (12 мая):
  Приоритет: Security baselines и OSConfig
  Интересно: Azure Arc для on-prem без подписки — 
  что реально бесплатно, что платно

ДЕНЬ 3 (13 мая):
  Главное: Windows Server v.Next preview
  Слушать на что делают акцент — это roadmap на 2-3 года
  Смотреть что убирают (как SysV из Linux) — это важнее
  чем новые фичи

КАК ЗАРЕГИСТРИРОВАТЬСЯ:
  techcommunity.microsoft.com → Events → Windows Server Summit 2026
  VIP Experience: доступ к слайдам + шанс на roundtable с product team
  Регистрация VIP — до 10 мая 23:59 PDT

Содержание Summit организовано вокруг реального операционного давления: более короткие окна от уязвимости до патча, стандартизация образов и baseline через смешанные парки серверов, доказательство для compliance-команд что политики применяются.

Зачем идти именно на live — не на запись:
Записи будут доступны потом. Но live Q&A — это единственный момент когда можно задать вопрос инженеру который написал hotpatch и получить ответ не из документации. Это редкая возможность.

Итог: зарегистрируйся сегодня. Три сессии в план на неделю. Одного вопроса в live Q&A иногда достаточно чтобы сэкономить месяц работы.

#windows #windowsserver #summit #sysadmin #admin_future

🧠 Skills: Privilege creep — тихая дыра которая растёт годами и взрывается в инцидент

Коллеги, пятничный пост о вещи которую все знают теоретически, но мало кто делает системно на практике.

Даже самая совершенная система управления правами со временем деградирует — «дрейф привилегий». Сотрудники меняют должности, увольняются, а их старые доступы остаются активными. Систематический аудит позволяет выявить «мёртвые души» — аккаунты уволенных, избыточные права администраторов и факты несанкционированного доступа к критичным папкам.

Copy Fail, PhantomRPC, CVE-2026-32202 — все три эксплуатируют локальный или сетевой доступ. Принцип наименьших привилегий напрямую ограничивает радиус поражения каждой из них.

Практический аудит привилегий — делаем сегодня:

# ---- WINDOWS AD: кто лишний в привилегированных группах ----
# Топ-3 группы риска:
$groups = @("Domain Admins","Enterprise Admins","Schema Admins")
foreach ($g in $groups) {
    Write-Host "=== $g ===" -ForegroundColor Red
    Get-ADGroupMember $g -Recursive |
        Get-ADUser -Properties LastLogonDate, Enabled |
        Select-Object Name, Enabled, LastLogonDate |
        Sort-Object LastLogonDate
}
# Всё что не логинилось > 90 дней — под вопросом

# Ищем аккаунты уволенных (не отключены, но не логинились):
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
    -Properties LastLogonDate, Department |
    Select-Object Name, Department, LastLogonDate |
    Export-Csv "stale_accounts.csv" -NoTypeInformation

# ---- LINUX: кто имеет sudo и не должен ----
# На каждом сервере:
grep -Po '^sudo.+:\K.*' /etc/group | tr ',' '\n'
cat /etc/sudoers /etc/sudoers.d/* 2>/dev/null | \
    grep -v "^#\|^$" | grep "ALL="
# Всё что не "systemd-related" и не конкретные команды — ревью

# ---- LINUX: сервисные учётки с интерактивным shell ----
awk -F: '$7 != "/sbin/nologin" && $7 != "/bin/false" && \
    $3 >= 500 {print $1, $7}' /etc/passwd
# Сервисные аккаунты должны иметь /sbin/nologin
# Если видишь /bin/bash — это либо человек либо проблема

# ---- АВТОМАТИЗАЦИЯ РЕВЬЮ (раз в квартал) ----
# Добавляем в cron/CI:
# 0 9 1 */3 * /opt/scripts/privilege_audit.sh | \
#   mail -s "Quarterly Privilege Audit" admin@company.com

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

Итог: один час аудита привилегий в пятницу — это несколько закрытых векторов атаки к понедельнику. Начни с Domain Admins. Обычно там уже есть сюрпризы.

#skills #security #privilegemanagement #activedirectory #linux #sysadmin #admin_future

🐧 Linux: Dirty Frag — вчера вечером раскрыли новый LPE, патчей ещё нет

Коллеги, срочная новость прямо с вчерашнего вечера. 8 мая независимый исследователь Хёнву Ким опубликовал Dirty Frag — два новых CVE в ядре Linux с публичным PoC и без патчей. Это не учебная тревога.

CVE-2026-43284 и CVE-2026-43500 — пара связанных уязвимостей в IPsec ESP и RxRPC подсистемах ядра. Любой непривилегированный локальный пользователь получает root. В отличие от Copy Fail с 4-байтовой записью, Dirty Frag позволяет полностью контролируемую запись в page cache в произвольном месте — за один выстрел. Исследователь сообщает о очень высокой надёжности без риска kernel panic.

Что делает это особенно опасным: контейнерные workloads наследуют уязвимость хоста — компрометация любого контейнера с доступом к AF_KEY, XFRM netlink или AF_RXRPC сокетам (дефолт для Docker, containerd и большинства Kubernetes pods) даёт root на хосте.

Embargo было нарушено третьей стороной, что вынудило исследователя опубликовать раньше срока — до выхода патчей дистрибутивов.

# МИТИГЕЙШН — НЕМЕДЛЕННО, пока патчей нет:
# Блокируем три затронутых модуля

sudo sh -c "printf 'install esp4 /bin/false\n\
install esp6 /bin/false\ninstall rxrpc /bin/false\n' \
> /etc/modprobe.d/dirtyfrag.conf"

# Выгружаем если уже загружены:
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

# Проверяем что модули не загружены:
lsmod | grep -E "esp4|esp6|rxrpc"
# Пустой вывод = в безопасности

# Проверяем затронуты ли конкретные версии ядра:
uname -r
# Затронуты ВСЕ дистрибутивы с ядром 2017+ до появления патча

# Следим за патчами:
# AlmaLinux: almalinux.org/blog
# Ubuntu: ubuntu.com/security/notices
# RHEL: access.redhat.com/security/vulnerabilities

# Мониторим загрузку подозрительных модулей:
auditctl -a always,exit -F arch=b64 \
    -S finit_module -S init_module \
    -k kernel_module_load

Зачем это критично сегодня:
Dirty Frag — прямой наследник Copy Fail того же класса уязвимостей. PoC публичен, патчей пока нет ни у одного дистрибутива. Организации должны считать уязвимость валидной и эксплуатируемой прямо сейчас.

Итог: три команды — один blacklist-файл — перезагрузка. Делай это сейчас, пока читаешь пост. Патч поставишь когда выйдет.

#linux #kernel #cve #dirtyfrag #security #lpe #sysadmin #admin_future

🪟 Windows: Secure Boot AMA 18 мая — и почему на него надо попасть

Коллеги, суббота — день для подготовки к следующей неделе. В понедельник стартует Windows Server Summit, а 18 мая Microsoft проводит Secure Boot AMA — и это важнее чем звучит.

Напоминание: сертификаты Secure Boot 2011 года начинают истекать в июне 2026. Microsoft проводит AMA 18 мая для ответов на оставшиеся вопросы после апрельского AMA.

Почему 18 мая критично именно для серверных администраторов: на Windows Server сертификаты не обновляются автоматически. Нужны ручные действия. До истечения — меньше шести недель.

Три вещи для подготовки к Summit и AMA:

# 1. Проверяем статус Secure Boot сертификатов СЕЙЧАС
# На каждом сервере:
Get-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
    -Name "UEFICA2023Status" -ErrorAction SilentlyContinue

# Если ключа нет или значение не "Updated" — сервер уязвим к июню

# 2. Быстрый аудит всего парка серверов:
$servers = Get-ADComputer `
    -Filter {OperatingSystem -like "*Server*"} |
    Select-Object -ExpandProperty Name

$results = foreach ($s in $servers) {
    try {
        Invoke-Command -ComputerName $s -ScriptBlock {
            $status = Get-ItemProperty `
                -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
                -Name "UEFICA2023Status" -ErrorAction SilentlyContinue
            [PSCustomObject]@{
                Server = $env:COMPUTERNAME
                Status = if ($status) {$status.UEFICA2023Status} else {"NOT_STARTED"}
                SecureBoot = Confirm-SecureBootUEFI -ErrorAction SilentlyContinue
            }
        } -ErrorAction Stop
    } catch {
        [PSCustomObject]@{Server=$s; Status="UNREACHABLE"; SecureBoot=$null}
    }
}

$results | Group-Object Status | Format-Table Name, Count
$results | Where-Object {$_.Status -ne "Updated"} |
    Export-Csv "secureboot_action_required.csv" -NoTypeInformation

# 3. Запускаем обновление на серверах со статусом NOT_STARTED:
# (запускать на каждом сервере)
Start-ScheduledTask `
    -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# После перезагрузки запустить ещё раз — статус станет "Updated"

Что спросить на AMA 18 мая:
Есть ли планы на автоматическое обновление для on-prem серверов в будущем? Что произойдёт с машинами у которых Secure Boot отключён — нужно ли что-то делать? Microsoft продолжает публиковать AMA по Secure Boot для ответов на вопросы по обновлению истекающих сертификатов.

Итог: шесть недель. Экспортируй CSV с серверами у которых NOT_STARTED — это твой план на следующие две недели.

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

🧠 Skills: PDQ State of Sysadmin 2026 — цифры которые больно читать, но нужно знать

Коллеги, в марте PDQ опубликовали ежегодный отчёт по состоянию профессии — 1000+ опрошенных специалистов по всему миру. Суббота — хороший день чтобы посмотреть на себя честно.

Главный вывод отчёта: инфраструктура работает стабильно. Люди — нет.

57% сисадминов чувствуют себя более стрессово чем год назад. В отличие от прошлых лет, стресс больше не концентрируется среди новичков — senior-специалисты всё чаще становятся дефолтной точкой эскалации для сложных, кросс-платформенных и высокорисковых ситуаций.

62% говорят что их роль расширилась новыми обязанностями. 52% ожидают экспертизы без предоставления обучения. 52% управляют всё более сложными системами. 50% говорят что темп изменений делает глубокую экспертизу невозможной.

Это не skills gap. Это job design problem.

Три числа которые стоит показать своему руководителю:

ДАННЫЕ ИЗ ОТЧЁТА PDQ 2026:

57%   Чувствуют больше стресса чем год назад
      (и это среди ВСЕХ грейдов, не только джунов)

62%   Фиксируют расширение ответственности
      без соответствующего расширения полномочий

73%   Хотят полную или почти полную автоматизацию
      управления endpoint — реальность пока далека

ЧТО ЗА ЭТИМ СТОИТ:
  "Инфраструктура не имеет brain debt.
   Люди — имеют. Несколько человек несут
   слишком много институциональных знаний,
   слишком много веса решений,
   слишком много ночных спасений."

  (PDQ 2026 State of Sysadmin Report)

ЧТО С ЭТИМ ДЕЛАТЬ — ПРАКТИЧЕСКИ:

1. АВТОМАТИЗИРУЙ ОДНУ ВЕЩЬ В НЕДЕЛЮ
   Не весь пайплайн. Одну задачу.
   Патчинг, инвентаризацию, алерт, отчёт.
   73% хотят автоматизацию — начни с себя.

2. ДОКУМЕНТИРУЙ BRAIN DEBT
   Что знаешь только ты?
   Запиши. Передай. Это защита, не слабость.

3. ГОВОРИ О НАГРУЗКЕ ЦИФРАМИ
   Не "я устал". А "за апрель: 3 инцидента
   вне рабочего времени, 12 часов
   на Dirty Frag + Copy Fail митигейшн,
   8 серверов на аудит Secure Boot".
   Цифры — единственный язык который слышат.

Устойчивость рабочей нагрузки и бремя дежурства теперь так же важны для удержания специалистов, как и компенсация. Данные указывают на операционный риск несогласованной ответственности и ручной работы которая не масштабируется.

Зачем это важно именно сегодня:
Эта неделя — Copy Fail, Dirty Frag, Secure Boot, CVE-2026-32202, Windows Server Summit, майский hotpatch. Всё одновременно. Это не исключение, это норма 2026 года. Отчёт PDQ это подтверждает с цифрами.

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

#skills #burnout #карьера #sysadmin #автоматизация #admin_future

🐧 Linux: Debian 14 «Forky» вводит обязательные воспроизводимые сборки — и это меняет supply chain security

Коллеги, 10 мая Debian Release Team объявила о решении которого ждали годами. Debian теперь блокирует пакеты, не прошедшие проверку воспроизводимой сборки, от попадания в testing. Это работает с 9 мая, во время текущего цикла разработки Forky. Правило распространяется и на уже существующие пакеты — если обновление нарушает воспроизводимость, миграция блокируется.

Что такое reproducible builds на практике:

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

Почему это важно именно сейчас:
Независимо верифицируемый путь от исходного кода к бинарному файлу становится всё более критичным с точки зрения безопасности цепочки поставок. XZ Utils backdoor, атаки на npm-пакеты, скомпрометированные CI/CD пайплайны — всё это атаки на supply chain. Reproducible builds делают их детектируемыми.

# Как проверить воспроизводимость пакета в Debian прямо сейчас:
# Смотрим статус на reproduce.debian.net
curl -s "https://reproduce.debian.net/api/v0/pkgset/by_name/unstable/openssh" \
    | python3 -m json.tool | grep -E "status|suite"

# Для своей системы — проверяем установленные пакеты через debsums:
apt install debsums
debsums -c  # проверяем контрольные суммы файлов

# Для разработчиков пакетов — проверяем воспроизводимость через reprotest:
apt install reprotest
reprotest -- dpkg-buildpackage -b .
# Собирает пакет дважды в разных условиях и сравнивает результат

# Смотрим общий дашборд воспроизводимости Debian:
# https://reproduce.debian.net/
# На момент анонса: >98% пакетов уже воспроизводимы на всех архитектурах

Debian 14 «Forky» также станет первым релизом с нативным rollback, undo и историей операций в APT package manager. Выход ожидается в июне-августе 2027 года.

Итог: reproducible builds — это не академия. Это инфраструктурный фундамент доверия к пакетам. Debian сделал это обязательным. Остальным дистрибутивам теперь неловко этого не делать.

#linux #debian #security #supplychain #sysadmin #admin_future

🪟 Windows: Quick Machine Recovery в Windows Server vNext — ответ Microsoft на CrowdStrike

Коллеги, сегодня второй день Windows Server Summit 2026, и одна из главных обсуждаемых тем — Quick Machine Recovery в Server vNext. Разбираем что это такое и стоит ли ждать.

Предыстория: QMR — прямой ответ на инцидент CrowdStrike в 2024 году, когда ошибочное обновление вызвало массовые BSOD и загрузочные сбои на более чем 8 миллионах Windows-машин по всему миру.

Механика: QMR теперь доступен для тестирования в Windows Server vNext Insider Preview (build 29574). Функция обеспечивает восстановление серверов при критических ошибках загрузки. QMR может автоматически искать облачные исправления для устранения массовых загрузочных сбоев, значительно снижая нагрузку на IT-администраторов когда затронуты несколько устройств одновременно.

Как это работает: устройство не загружается 2+ раза → входит в WinRE → QMR подключается к облаку Microsoft → проверяет известные проблемы → скачивает и применяет исправление → перезагружается. Без физического доступа к серверу, без ручного вмешательства.

# Конфигурация QMR через Intune (CSP)
# Путь: ./Device/Vendor/MSFT/RemoteRemediation/CloudRemediationSettings
# Или через Settings Catalog: Remote Remediation → Enable Cloud Remediation

# На клиентском Windows 11 (уже GA с KB5062660):
# Проверяем статус QMR:
Get-ItemProperty `
    -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinRE" |
    Select-Object *Recovery*

# Тестируем QMR без реального сбоя (test mode):
# reagentc.exe /setrecoverytestmode
# Создаёт RecoverySimulation.ini — устройство войдёт в WinRE при перезагрузке
# ТОЛЬКО В ЛАБОРАТОРИИ, не на продакшне

# Для Server vNext Insider Preview (build 29574):
# Скачать: microsoft.com/en-us/software-download/windowsinsiderpreviewserver
# Expires: 15 сентября 2026

# Проверяем что QMR включён после установки:
Get-WindowsOptionalFeature -Online -FeatureName *Recovery* |
    Where-Object {$_.State -eq "Enabled"}

Важные оговорки для серверной среды: Microsoft установил жёсткую базовую линию на build 29531 — те кто запускает более старые preview-сборки должны сделать чистую установку, так как инкрементальное обновление сломает VM и кластеры. ReFS Boot включён, но удаление или изменение размера раздела WinRE может навсегда заблокировать систему.

Зачем следить уже сейчас:
QMR на клиентах Windows 11 уже работает и доказывает концепцию. Перенос на Server vNext означает что корпоративные серверы смогут самовосстанавливаться при массовых инцидентах уровня CrowdStrike — без ночных вылетов в датацентр.

Итог: preview, expires в сентябре, в production не трогать. Но тестовый стенд поднять стоит — это одна из важных фич следующей версии Windows Server.

#windows #windowsserver #QMR #recovery #sysadmin #admin_future

🧠 Skills: Cattle vs Pets — принцип которому 15 лет, но половина инфраструктур его игнорирует

Коллеги, вторник — хороший момент для фундаментального разговора. Принцип «скот vs питомцы» (Cattle vs Pets) сформулировали ещё в 2011 году, но я до сих пор регулярно вижу инфраструктуры где каждый сервер — уникальный именованный питомец с историей ручных конфигураций.

Вместо питомцев у нас есть Cattle — стадо: серверы анонимны, взаимозаменяемы. Если узел № 154 ведёт себя нестабильно, его не лечат как любимого котика — его пристреливают как охромевшую лошадь. Удаляют и автоматически поднимают новый, идентичный, здоровый. Именно этот принцип породил Infrastructure as Code.

Как выглядят «питомцы» в реальной жизни:

ПРИЗНАКИ "ПИТОМЦА":
  - У сервера есть имя собственное: "Старый-Файловый",
    "Сервак-Богдана", "Этот-трогать-нельзя"
  - Никто не знает что на нём запущено кроме одного человека
  - Последний раз переустанавливали в 2019 году
  - Конфиги правились руками, в git не попадали
  - Апгрейд невозможен — "упадёт всё"

ПРИЗНАКИ "СКОТА":
  - Серверы называются по роли + номер: web-01, db-03
  - Любой сервер можно удалить и поднять заново за минуты
  - Конфигурация полностью в Ansible/Terraform
  - Нет уникальных ручных настроек которые нигде не записаны
  - Новый член команды может задеплоить среду с нуля

Практический переход от питомцев к скоту — четыре шага:

# ШАГ 1: Аудит — какие серверы у нас "питомцы"?
# Признак: uptime больше года без переустановки
uptime -s  # дата последнего старта
# Если дата 2023 и раньше на продакшн-сервере — питомец

# ШАГ 2: Документируем что реально запущено (chef-solo, ansible-pull)
# На подозрительном сервере:
ss -tlnp          # что слушает
systemctl list-units --type=service --state=running
crontab -l; ls /etc/cron.d/   # кроны
find /etc -newer /etc/os-release -type f 2>/dev/null | head -20
# Последнее — файлы изменённые после установки ОС

# ШАГ 3: Описываем текущее состояние как Ansible playbook
# ansible-pull или ручное написание по результатам аудита
# Проверяем идемпотентность:
ansible-playbook site.yml --check --diff

# ШАГ 4: Blue/Green замена
# Поднимаем новый сервер по playbook
# Переключаем трафик (DNS, LB)
# Старый питомец умирает с почестями
# Держим его неделю на всякий случай

Почему это важно именно сейчас:
Copy Fail и Dirty Frag показали — сервера которые нельзя быстро пересоздать это не просто технический долг. Это риск. Если патч ломает питомца — нет возможности быстро откатиться на чистую конфигурацию. Если питомец умирает — нет возможности его воссоздать.

Infrastructure as Code: инфраструктура описывается в коде, воспроизводится автоматически, тестируется и версионируется как любой другой программный продукт.

Итог: посмотри на свой список серверов прямо сейчас. Посчитай сколько из них питомцы. Это твой список технического долга на следующий квартал.

#skills #iac #infrastructure #ansible #terraform #sysadmin #admin_future

🐧 Linux: Killswitch в ядре — красная кнопка для zero-day, которая пугает всех кроме Red Hat

Коллеги, последние две недели — Copy Fail, Dirty Frag, оба с публичным PoC, оба до выхода патчей. Sasha Levin (NVIDIA, co-maintainer stable Linux) предложил системный ответ на этот хаос. И разгорелся нешуточный спор.

Предложенная фича «Killswitch» позволяет администраторам временно отключить конкретные уязвимые функции ядра прямо в runtime — вместо того чтобы сидеть и ждать патчей. Как сказал сам Левин: «когда уязвимость становится публичной, флоты остаются открытыми пока не будет собрано, распространено и перезагружено в новое ядро. Для многих проблем самый простой митигейшн — просто прекратить вызывать багованную функцию».

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

Почему это спорно:

В r/cybersecurity предложение называют «ужасной идеей», «абсурдом» и «абсолютно пугающим». Аргумент против: люди будут использовать killswitch вместо патчинга.

Red Hat поддержал: «мы за включение killswitch в ядро, особенно по мере того как темп и серьёзность эксплойтов растёт благодаря LLM-сканированию. Патчи критичны, но они часто разрушительны. Организациям приходится взвешивать защиту через патч против производственного impact от рестартов».

# Что это значит СЕЙЧАС — фича ещё не в ядре, это proposal.
# Но принцип уже можно применять вручную для Copy Fail и Dirty Frag:

# Copy Fail (CVE-2026-31431) — блокируем AF_ALG путь:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/killswitch.conf
rmmod algif_aead 2>/dev/null

# Dirty Frag (CVE-2026-43284 + CVE-2026-43500) — блокируем esp4/esp6/rxrpc:
echo -e "install esp4 /bin/false\ninstall esp6 /bin/false\n\
install rxrpc /bin/false" >> /etc/modprobe.d/killswitch.conf
rmmod esp4 esp6 rxrpc 2>/dev/null

# Проверяем что всё заблокировано:
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc"
# Пустой вывод = хорошо

# ЕСЛИ НУЖЕН esp4/esp6 (используете IPsec) — только патч ядра:
uname -r  # нужна 7.0.6 / 6.18.29 / 6.12.87 / 6.6.138+
apt update && apt full-upgrade  # Ubuntu/Debian
dnf update kernel -y            # RHEL/AlmaLinux/Rocky

Зачем это важно как концепция: killswitch — признание факта: если окно между публичным раскрытием и выходом патчей нельзя надёжно контролировать, администраторам нужен способ снизить риск на своих условиях.

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

#linux #kernel #security #killswitch #copyfail #dirtyfrag #sysadmin #admin_future

🪟 Windows: RC4 в Kerberos — июль финализирует, а у тебя ещё не готово

Коллеги, сегодня последний день Windows Server Summit 2026. И главная тема которая звучала все три дня — RC4 в Kerberos. Не потому что новая. Потому что июль близко, а большинство до сих пор не закончили аудит.

Хронология жёсткая: январь 2026 — аудит-режим, предупреждающие события в логах DC. Апрель 2026 — enforcement: AES-SHA1 по умолчанию для учёток без явного msDS-SupportedEncryptionTypes. Июль 2026 — финал: RC4 убирается из протокольного пути полностью, ключ реестра RC4DefaultDisablementPhase игнорируется.

Что реально сломается если не подготовиться: сервисные учётки, NAS-устройства, принтеры, старые приложения, любая учётка без явного атрибута шифрования. Симптом: ошибка «KDC has no support for encryption type», сервисы не стартуют, авторизация в приложениях падает.

# ШАГ 1: Смотрим Event ID 201-209 на DC — кто ещё использует RC4
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -in @(201,202,203,206,207)} |
    Select-Object TimeCreated, Id, Message |
    Format-List | Select-Object -First 20

# Что означают ID:
# 201 — RC4 использован (клиент только RC4, у сервиса нет msDS-SET)
# 202 — RC4 использован (у учётки нет AES-ключей)
# 203 — RC4 ЗАБЛОКИРОВАН (это уже ошибка в апрельском enforcement)

# ШАГ 2: Ищем учётки без AES-ключей
Get-ADUser -Filter {Enabled -eq $true} `
    -Properties msDS-SupportedEncryptionTypes, PasswordLastSet,
    ServicePrincipalNames |
    Where-Object {$_.ServicePrincipalNames -ne $null} |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes |
    Where-Object {$_.msDS-SupportedEncryptionTypes -eq $null -or
                  $_."msDS-SupportedEncryptionTypes" -eq 0}

# ШАГ 3: Генерируем AES-ключи для сервисных учёток
# Сброс пароля генерирует новые ключи автоматически:
Set-ADAccountPassword -Identity "svc_app01" -Reset `
    -NewPassword (ConvertTo-SecureString "NewP@ss2026!" -AsPlainText -Force)

# Явно задаём поддерживаемое шифрование:
Set-ADUser -Identity "svc_app01" `
    -KerberosEncryptionType AES128,AES256

# ШАГ 4: Проверяем krbtgt — если старый, AES-ключей нет:
Get-ADUser krbtgt -Properties PasswordLastSet,
    msDS-SupportedEncryptionTypes |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes
# Если PasswordLastSet до 2012 — сбрасываем ДВАЖДЫ с репликацией

# ШАГ 5: Проверяем Event 4768/4769 на RC4-тикеты:
Get-WinEvent -LogName Security |
    Where-Object {$_.Id -in @(4768,4769)} |
    ForEach-Object {
        if ($_.Message -match "0x17") {
            Write-Host "RC4 ticket: $($_.TimeCreated) - $($_.Message)" `
                -ForegroundColor Red
        }
    } | Select-Object -First 10

Зачем это срочно именно сейчас: после июля 2026 аудит-режим убирается и реестровый ключ игнорируется. Единственный откат — вручную включить RC4 для конкретной учётки. Это не план, это последний шанс перед аварией.

Итог: Event ID 201/202 на DC — смотри прямо сейчас. Каждое событие это учётка или сервис, который упадёт в июле. У тебя меньше двух месяцев.

#windows #kerberos #activedirectory #rc4 #security #sysadmin #admin_future

🧠 Skills: Vulnerability fatigue — когда патчей слишком много и что с этим делать

Коллеги, последние две недели — отличный материал для разговора об усталости от уязвимостей. Copy Fail, Dirty Frag, CVE-2026-32202, BlueHammer, RC4 в Kerberos, Secure Boot сертификаты, Cockpit RCE. Всё в один месяц. Всё срочно. Всё критично.

Linux kernel CVE-ы выросли примерно с 300 в 2023 году до более чем 5500 в этом году — рост частично объясняется более широким использованием AI-инструментов для поиска уязвимостей. Патчировать на достаточно высокой скорости в распределённых enterprise-флотах — возможно, уже нереально.

Это не просто техническая проблема. Это проблема приоритизации.

Рабочий фреймворк: как не тонуть в CVE-потоке

УРОВЕНЬ 1: НЕМЕДЛЕННО (сегодня-завтра)
  Критерии: CVSS ≥ 9.0 + публичный PoC + активная эксплуатация
  Действие: митигейшн сейчас, патч при ближайшей возможности
  Примеры этого месяца: Copy Fail (KEV), Dirty Frag (PoC публичный)

  Источники которые смотрим ЕЖЕДНЕВНО:
  - CISA KEV: cisa.gov/known-exploited-vulnerabilities-catalog
  - ВСЁ с пометкой "actively exploited" от вендора

УРОВЕНЬ 2: ЭТОТ ЦИКЛ (ближайшее плановое обслуживание)
  Критерии: CVSS 7-9 + нет публичного PoC + нет признаков эксплуатации
  Действие: включаем в стандартный patch cycle
  Примеры: большинство Patch Tuesday без пометки "exploited"

УРОВЕНЬ 3: СЛЕДУЮЩИЙ КВАРТАЛ
  Критерии: CVSS < 7 + требует сложной цепочки эксплуатации
  Действие: мониторим, патчим при следующем удобном случае

УРОВЕНЬ 4: НЕ ПАТЧИМ СРОЧНО
  Критерии: нет вектора атаки в нашей среде
  (например: уязвимость в Bluetooth на серверах без BT)
  Действие: записываем, пересматриваем при изменении среды

Три правила которые спасают от panic-патчинга:

Первое — не все CVE одинаковы. CVSS 9.8 на компонент которого у тебя нет — не твоя проблема сегодня. CVSS 7.8 с публичным PoC на компонент в продакшне — твоя проблема прямо сейчас.

Второе — подписывайся на правильные источники, а не читай всё подряд. CISA KEV + security advisory твоих дистрибутивов + NVD для специфичных продуктов. Три источника вместо двадцати.

Третье — отделяй «звучит страшно» от «реально опасно в моей среде». Copy Fail требует локального доступа — если у тебя нет непривилегированных пользователей на серверах, риск значительно ниже. Понимание модели угроз важнее скорости реакции на любой заголовок.

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

Итог: vulnerability fatigue — реальное явление. Лечится не игнорированием CVE, а чёткими критериями что является пожаром, а что плановой работой. Разница между паникой и контролем — это наличие процесса.

#skills #security #vulnerabilitymanagement #патчинг #sysadmin #admin_future

-🐧 Linux: Fragnesia — третья уязвимость за две недели, и у неё нет CVE

Коллеги, вчера 13 мая вышел ещё один сюрприз. Команда v12-security раскрыла «Fragnesia» — универсальный LPE-эксплойт в ядре Linux, обнаруженный Уильямом Боулингом. Fragnesia относится к семейству Dirty Frag, но это отдельная ошибка в ESP/XFRM — она получила собственный патч. Митигейшн — тот же что и для Dirty Frag.

Механика: эксплойт использует логическую ошибку в подсистеме XFRM ESP-in-TCP. Когда TCP-сокет переходит в режим espintcp ULP после того как данные уже были перемещены через splice из файла, достигается произвольная байтовая запись в page cache read-only файлов — без race condition.

Это уже третья уязвимость класса page-cache write за две недели: Copy Fail → Dirty Frag → Fragnesia.

Критическое предупреждение после эксплуатации: после запуска эксплойта /usr/bin/su в page cache остаётся изменённым и будет порождать root-шелл при каждом вызове — до принудительного сброса кэша или перезагрузки.

# МИТИГЕЙШН — тот же что для Dirty Frag
# Блокируем esp4, esp6, rxrpc:
printf 'install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf
rmmod esp4 esp6 rxrpc 2>/dev/null || true

# Если система уже была под атакой — ОБЯЗАТЕЛЬНО сбрасываем page cache:
echo 1 | tee /proc/sys/vm/drop_caches
# Или перезагружаемся

# Проверяем что модули не загружены:
lsmod | grep -E "esp4|esp6|rxrpc"
# Пустой вывод = хорошо

# Для систем использующих IPsec — только патч ядра:
# Нужна версия с патчем Fragnesia (появится в 7.0.7+ / 6.18.30+)
# Следим: kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.7

# AMD CPU op-cache: отдельная уязвимость этой недели (не ядро Linux)
# Затрагивает Zen 2. Патч от AMD — через обновление microcode:
apt update && apt install amd64-microcode  # Debian/Ubuntu
dnf update microcode_ctl               # RHEL/Rocky/AlmaLinux

Зачем это важно именно сейчас:
Три LPE за две недели из одной поверхности атаки (page cache / XFRM / ESP) говорят об одном: этот класс уязвимостей ещё не исчерпан. Killswitch-proposal от Левина выглядит уже не паранойей, а инженерным реализмом.

Итог: митигейшн простой — blacklist трёх модулей. Если IPsec не используется — делать прямо сейчас. Если используется — в приоритет патч ядра как только появится.

#linux #kernel #cve #fragnesia #lpe #security #sysadmin #admin_future

🪟 Windows: Май 2026 Patch Tuesday — 120 CVE, ноль zero-days, два приоритета

Коллеги, вчера вышел майский Patch Tuesday. Хорошая новость: впервые с июня 2024 года — ни одного активно эксплуатируемого или публично раскрытого zero-day. Плохая: несмотря на это, три компонента требуют срочного внимания.

CVE-2026-41096 — Windows DNS Client RCE, Critical.
Злоумышленник-контролируемый DNS-сервер может отправить специально сформированный DNS-ответ на уязвимую Windows-систему, что вызовет некорректную обработку памяти клиентом DNS и позволит выполнить код удалённо. DNS-клиент есть на каждой Windows-машине. Вектор — любой ответ от вредоносного DNS-сервера.

CVE-2026-41089 — Windows Netlogon RCE, Critical.
Stack-based buffer overflow в Netlogon. Контроллеры домена — это не обычные серверы, это структура авторизации всего Windows enterprise. Ошибка которая может быть применена против DC, даже при ограниченных условиях, должна быть в топе любого совещания по приоритизации патчей.

CVE-2026-41103 — Microsoft SSO Plugin для Jira/Confluence, CVSS 9.1, Critical.
Сетевая эксплуатация, не требует привилегий, не требует взаимодействия пользователя. Microsoft пометил как «Exploitation More Likely». Успешный эксплойт даёт неаутентифицированному атакующему доступ к Jira/Confluence с повышенными привилегиями.

# Проверяем установлены ли майские обновления:
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