🧠 Skills: PDQ State of Sysadmin 2026 — цифра которая объясняет всё
Коллеги, пятница и последний май-пост по skills. Сегодня — одна цифра из исследования PDQ и то, что за ней стоит.
62% сисадминов говорят что их роль расширилась новыми обязанностями. 52% ожидают экспертизы без предоставления обучения. 52% управляют всё более сложными системами. 50% говорят что темп изменений делает глубокую экспертизу невозможной.
Это не skills gap. Это дизайн работы который не масштабируется.
Отчёт PDQ 2026 показывает: стресс становится структурным. И структурные проблемы требуют структурных решений — автоматизации и AI. Не очередной дашборд, не очередной инструмент, не очередная речь «будьте проактивнее». Нужно проектировать работу которую могут выдержать люди, у которых тоже есть выходные.
Три вещи которые реально меняют ситуацию — не абстрактные советы, а конкретные действия:
Относись к on-call нагрузке как к операционному риску — не как к символу доблести, не как к испытанию. Это измеримая угроза uptime и удержанию специалистов.
Итог: две недели Copy Fail, Dirty Frag, Fragnesia, Patch Tuesday, RC4, Secure Boot — и это просто май 2026. Один человек не должен держать это в одиночку. Если держишь — у тебя не профессионализм, у твоей организации — архитектурная проблема управления рисками.
Хороших выходных, коллеги. Вы их заслужили.
#skills #карьера #workload #автоматизация #sysadmin #admin_future
Коллеги, пятница и последний май-пост по 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.
Почему это важно как архитектурный урок:
Dirty Frag применяет две отдельные page-cache write примитивы: один в xfrm-ESP, другой в RxRPC. Оба позволяют модифицировать page-cache-backed память не принадлежащую исключительно ядру, что даёт возможность повредить чувствительные файлы и получить привилегии. Три разных пути — один класс. Следи за XFRM и splice() в следующих раскрытиях.
Итог: патч + перезагрузка = закрыто. Без перезагрузки патч не работает. Проверь uname -r прямо сейчас.
#linux #kernel #security #pagecache #copyfail #sysadmin #admin_future
Коллеги, понедельник — хороший момент чтобы разобраться в механике, а не просто закрыть тикет с митигейшном. 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 июня произойдёт ошибка hard match — см. документацию по шагам митигейшн. Лучше найти и исправить до дедлайна, чем разбираться почему синхронизация сломалась в начале июня.
Итог: два действия до 1 июня. Найти cloud-привилегированные учётки с onPremisesImmutableId. Проверить аудит Agent ID Administrator с февраля. Это займёт час — и закроет серьёзный вектор атаки.
#windows #entra #activedirectory #hybrididentity #security #sysadmin #admin_future
Коллеги, пока все смотрели на 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 — это не про скорость чтения. Это про правильную последовательность вопросов.
Пять вопросов в порядке приоритета:
Сколько это занимает на практике:
Зачем формализовать это как процесс:
Без структуры каждый CVE кажется одинаково срочным. Со структурой — большинство закрываются за 5 минут с решением «не моя проблема» или «плановый патч». Оставшиеся 10-20% получают правильный приоритет и внимание.
Итог: пять вопросов. Сохрани в заметки. Следующий CVE проверь по этому списку — увидишь разницу.
#skills #security #cve #патчинг #sysadmin #admin_future
Коллеги, май 2026 показал: три LPE в Linux, Patch Tuesday со 120 CVE, Entra ID issues, RC4 в Kerberos. Всё одновременно. И каждый раз нужно быстро понять — это моя проблема или нет?
Навык быстрого чтения security advisory — это не про скорость чтения. Это про правильную последовательность вопросов.
Пять вопросов в порядке приоритета:
ВОПРОС 1: Есть ли это в моей среде?
Не "затрагивает ли Linux вообще", а "загружен ли у меня algif_aead?"
Не "уязвим ли Windows DNS Client", а "есть ли у меня WS2025 DC?"
Если нет — всё остальное не важно.
Инструменты:
lsmod | grep <module> # Linux модули
Get-WindowsFeature <role> # Windows роли
Get-HotFix -Id <KB> # установлен ли патч
ВОПРОС 2: Активно ли эксплуатируется?
Проверяем CISA KEV: cisa.gov/known-exploited-vulnerabilities-catalog
Если есть — это emergency. Если нет — плановый цикл.
Три статуса которые важны:
"Exploited in the wild" (CISA KEV) → сегодня
"Exploitation More Likely" (Microsoft) → этот цикл
"Exploitation Less Likely" → следующий квартал
ВОПРОС 3: Что нужно для эксплуатации?
Читаем Prerequisites/Attack Vector:
Network + Unauthenticated → критично, публичные сервисы
Network + Authenticated → важно, но нужен аккаунт
Local → нужен локальный доступ
Physical → обычно не первый приоритет
Copy Fail: Local + Unprivileged → критично для shared hosts
DNS CVE-2026-41096: Network + Unauthenticated → критично для DC
ВОПРОС 4: Есть ли митигейшн без патча?
Всегда смотрим Workarounds секцию.
Для Copy Fail: blacklist algif_aead — 30 секунд работы
Для RC4 Kerberos: включить AES-ключи заранее
Митигейшн даёт время — не заменяет патч
ВОПРОС 5: Когда патч?
Уже есть → в ближайшее maintenance window
Preview/RC → в production не трогаем, ставим в лабу
Нет → митигейшн + мониторинг + следим за релизом
Сколько это занимает на практике:
Copy Fail (когда вышел):
Q1: "algif_aead у меня загружен?" — 30 секунд, lsmod
Q2: "CISA KEV?" — да, 1 мая добавили → emergency
Q3: "Local + Unprivileged" → все shared hosts под угрозой
Q4: blacklist algif_aead → 2 команды, 1 минута
Q5: патч вышел для Ubuntu/RHEL → ставим при ближайшем window
Итого: 5 минут от чтения до принятого решения.
Entra hard match (1 июня дедлайн):
Q1: "Есть ли у нас гибридная Entra Connect среда?" → да/нет
Если нет → закрыли, не наш случай
Если да → Q2-Q5
Зачем формализовать это как процесс:
Без структуры каждый CVE кажется одинаково срочным. Со структурой — большинство закрываются за 5 минут с решением «не моя проблема» или «плановый патч». Оставшиеся 10-20% получают правильный приоритет и внимание.
Итог: пять вопросов. Сохрани в заметки. Следующий CVE проверь по этому списку — увидишь разницу.
#skills #security #cve #патчинг #sysadmin #admin_future
🐧 Linux: ModuleJail — сисадмин из Бельгии решил проблему которую не осилил Red Hat
Коллеги, май 2026-го показал: ручной blacklist модулей на флоте из сотен серверов — это не масштабируемо. Пока мы прописывали algif_aead, esp4, esp6 и rxrpc по одному, бельгийский сисадмин и Tesla-хакер Jasper Nuyens написал инструмент который делает это за секунды — для всего флота.
ModuleJail — GPLv3 shell-скрипт который сканирует запущенную Linux-систему и автоматически создаёт blacklist для всех неиспользуемых модулей ядра — без перезагрузки. Работает на Debian, Ubuntu, RHEL, Fedora, AlmaLinux и Arch Linux.
ModuleJail делает снимок загруженных модулей (/proc/modules) и вычисляет разность с полным деревом модулей (/lib/modules/$(uname -r)). Каждый модуль из разности, за исключением встроенного baseline и whitelist администратора, попадает в директиву install в модprobe.d-совместимый blacklist-файл.
Важная оговорка: ModuleJail должен запускаться только после достижения системой стабильного состояния — все сервисы запущены, ФС примонтированы, нужные драйверы загружены. Запуск слишком рано может заблокировать модули нужные позже.
Зачем это важно именно сейчас: AI-assisted security scanning делает с ядром Linux то, что массовый fuzzing сделал с userspace-кодом десять лет назад — только быстрее и в значительно большем масштабе. Много лет скрытых LPE-багов в модулях ядра вот-вот всплывут в быстрой последовательности.
Итог: не заменяет патчинг. Но пока патч не вышел — это лучший способ превратить следующий CVE в «не моя проблема» за счёт сокращения поверхности атаки.
#linux #security #kernel #modulejail #hardening #sysadmin #admin_future
Коллеги, май 2026-го показал: ручной blacklist модулей на флоте из сотен серверов — это не масштабируемо. Пока мы прописывали algif_aead, esp4, esp6 и rxrpc по одному, бельгийский сисадмин и Tesla-хакер Jasper Nuyens написал инструмент который делает это за секунды — для всего флота.
ModuleJail — GPLv3 shell-скрипт который сканирует запущенную Linux-систему и автоматически создаёт blacklist для всех неиспользуемых модулей ядра — без перезагрузки. Работает на Debian, Ubuntu, RHEL, Fedora, AlmaLinux и Arch Linux.
ModuleJail делает снимок загруженных модулей (/proc/modules) и вычисляет разность с полным деревом модулей (/lib/modules/$(uname -r)). Каждый модуль из разности, за исключением встроенного baseline и whitelist администратора, попадает в директиву install в модprobe.d-совместимый blacklist-файл.
# Установка и запуск за одну команду:
curl -fsSL https://raw.githubusercontent.com/jnuyens/modulejail/main/modulejail \
-o modulejail && chmod +x modulejail
# Запускаем с профилем для сервера (default: conservative)
# ВАЖНО: запускать только после полной загрузки всех сервисов
sudo sh modulejail -p conservative
# Три профиля:
# minimal — только core ФС и критичные модули
# conservative — minimal + драйверы для VM/bare-metal серверов (DEFAULT)
# desktop — conservative + WiFi, BT, audio, video
# Результат: /etc/modprobe.d/modulejail-blacklist.conf
# Смотрим сколько модулей заблокировано:
wc -l /etc/modprobe.d/modulejail-blacklist.conf
# Логирование заблокированных попыток загрузки (v1.2+):
# Каждая попытка modprobe <blocked_module> пишет в syslog:
journalctl -t modulejail -f
# Откат без перезагрузки — просто удаляем файл:
rm /etc/modprobe.d/modulejail-blacklist.conf
# Для немедленного эффекта — modprobe нужный_модуль вручную
# Ansible для флота (всё в git):
# - name: Deploy ModuleJail
# script: modulejail -p conservative
# args:
# creates: /etc/modprobe.d/modulejail-blacklist.conf
Важная оговорка: ModuleJail должен запускаться только после достижения системой стабильного состояния — все сервисы запущены, ФС примонтированы, нужные драйверы загружены. Запуск слишком рано может заблокировать модули нужные позже.
Зачем это важно именно сейчас: AI-assisted security scanning делает с ядром Linux то, что массовый fuzzing сделал с userspace-кодом десять лет назад — только быстрее и в значительно большем масштабе. Много лет скрытых LPE-багов в модулях ядра вот-вот всплывут в быстрой последовательности.
Итог: не заменяет патчинг. Но пока патч не вышел — это лучший способ превратить следующий CVE в «не моя проблема» за счёт сокращения поверхности атаки.
#linux #security #kernel #modulejail #hardening #sysadmin #admin_future
🪟 Windows: Secure Boot — вчера прошёл финальный AMA, June дедлайн через 6 недель
Коллеги, вчера 18 мая Microsoft провела последний AMA по Secure Boot перед июньским истечением сертификатов. Разбираем главное что прозвучало — и что нашли в майском обновлении.
Майское обновление Windows 11 (KB5089549) разместило на системах новую папку SecureBoot — это не вредонос, не ошибка установки. Это Microsoft размещает ресурсы для обновления Secure Boot, включая PowerShell-скрипты для определения статуса сертификатов и автоматизации развёртывания.
Главное с вчерашнего AMA:
Системы без новых сертификатов к июню 2026 войдут в деградированное состояние Secure Boot или не смогут загрузиться с BitLocker recovery prompts. Для отключённых устройств (lab machines, air-gapped) может потребоваться ручное вмешательство.
Один из участников поделился скриптом который сначала пытается установить Microsoft-обновление, при неудаче — делает fallback на OEM-пакет. AMA-команда одобрила подход, но предупредила: fallback нужно тщательно тестировать, так как неудачное обновление прошивки может окирпичить материнскую плату.
Зачем это критично до июня:
Обновление сертификатов — напоминание что обслуживание Windows теперь распространяется ниже уровня операционной системы. Patch Tuesday доставляет полезную нагрузку, но прошивка решает, может ли цепочка доверия принять и сохранить её.
Итог: шесть недель. Экспортируй CSV с NOT_STARTED серверами прямо сейчас — это твой план на эту неделю.
#windows #secureboot #pki #security #sysadmin #admin_future
Коллеги, вчера 18 мая Microsoft провела последний AMA по Secure Boot перед июньским истечением сертификатов. Разбираем главное что прозвучало — и что нашли в майском обновлении.
Майское обновление Windows 11 (KB5089549) разместило на системах новую папку SecureBoot — это не вредонос, не ошибка установки. Это Microsoft размещает ресурсы для обновления Secure Boot, включая PowerShell-скрипты для определения статуса сертификатов и автоматизации развёртывания.
Главное с вчерашнего AMA:
Системы без новых сертификатов к июню 2026 войдут в деградированное состояние Secure Boot или не смогут загрузиться с BitLocker recovery prompts. Для отключённых устройств (lab machines, air-gapped) может потребоваться ручное вмешательство.
Один из участников поделился скриптом который сначала пытается установить Microsoft-обновление, при неудаче — делает fallback на OEM-пакет. AMA-команда одобрила подход, но предупредила: fallback нужно тщательно тестировать, так как неудачное обновление прошивки может окирпичить материнскую плату.
# Итоговая проверка статуса — прямо сейчас:
# Смотрим статус обновления сертификатов
Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue
# Значения:
# (отсутствует или пусто) = NOT_STARTED — нужно действовать
# "InProgress" = в процессе
# "Updated" = готово
# Массовый аудит парка серверов:
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -ExpandProperty Name
$results = foreach ($s in $servers) {
try {
Invoke-Command -ComputerName $s -ScriptBlock {
$sb = Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue
[PSCustomObject]@{
Server = $env:COMPUTERNAME
Status = if ($sb) { $sb.UEFICA2023Status } else { "NOT_STARTED" }
}
} -ErrorAction Stop
} catch {
[PSCustomObject]@{Server=$s; Status="UNREACHABLE"}
}
}
$results | Group-Object Status | Format-Table Name, Count
$results | Where-Object {$_.Status -ne "Updated"} |
Export-Csv "secureboot_todo.csv" -NoTypeInformation
# Для серверов с NOT_STARTED — запускаем обновление:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# После перезагрузки — запустить ещё раз
# Также важно: обновляем dbx (список отозванных bootloader-ов)
# Проверяем текущий dbx через PowerShell модуль SecureBoot:
Confirm-SecureBootUEFI
Get-SecureBootUEFI -Name dbx
Зачем это критично до июня:
Обновление сертификатов — напоминание что обслуживание Windows теперь распространяется ниже уровня операционной системы. Patch Tuesday доставляет полезную нагрузку, но прошивка решает, может ли цепочка доверия принять и сохранить её.
Итог: шесть недель. Экспортируй CSV с NOT_STARTED серверами прямо сейчас — это твой план на эту неделю.
#windows #secureboot #pki #security #sysadmin #admin_future
🧠 Skills: CVE-2026-46333 — новый Linux LPE раскрыт сегодня, и он позволяет читать SSH-ключи
Коллеги, небольшой сдвиг формата сегодняшнего Skills-поста. Вместо soft skills — разберём как правильно реагировать на раскрытие прямо в момент его появления. Потому что сегодня именно такой момент.
Сегодня, 19 мая 2026, исследователи Qualys раскрыли CVE-2026-46333 в ядре Linux. Уязвимость позволяет непривилегированному пользователю читать файлы принадлежащие root — в том числе SSH-ключи (/etc/ssh/ssh_host_*_key) и файл /etc/shadow. PoC доступен публично как ssh-keysign-pwn и chage_pwn. Подтверждена работоспособность на Arch Linux, Debian, Ubuntu, CentOS и Raspberry Pi OS.
Механика: уязвимость в __ptrace_may_access(), которая пропускает dumpable-проверку когда task->mm == NULL. do_exit() запускает exit_mm() перед exit_files() — нет mm, но fd-ы ещё живые — и pidfd_getfd(2) успешно выполняется в этом окне когда uid вызывающего совпадает с целевым.
Это не LPE до root — это чтение приватных ключей. Для серверов с SSH-доступом — это критично.
Как работает правильная реакция на fresh disclosure:
Первые 30 минут: читаем advisory, понимаем prerequisites (local? network? authenticated?), проверяем есть ли у нас этот компонент в системе.
30 минут — 2 часа: ищем временный митигейшн (не патч — его ещё нет). Применяем если риск в нашей среде реален.
После: ждём патча дистрибутива, ставим как только появится, убираем митигейшн.
Это не паника — это процесс. Разница в том, что процесс можно делегировать и автоматизировать.
Итог: ptrace_scope = 1 — это одна команда которая снижает риск не только от CVE-2026-46333, но и от всего класса ptrace-атак. Это и есть defence-in-depth в действии.
#skills #linux #cve #security #реакция #sysadmin #admin_future
Коллеги, небольшой сдвиг формата сегодняшнего Skills-поста. Вместо soft skills — разберём как правильно реагировать на раскрытие прямо в момент его появления. Потому что сегодня именно такой момент.
Сегодня, 19 мая 2026, исследователи Qualys раскрыли CVE-2026-46333 в ядре Linux. Уязвимость позволяет непривилегированному пользователю читать файлы принадлежащие root — в том числе SSH-ключи (/etc/ssh/ssh_host_*_key) и файл /etc/shadow. PoC доступен публично как ssh-keysign-pwn и chage_pwn. Подтверждена работоспособность на Arch Linux, Debian, Ubuntu, CentOS и Raspberry Pi OS.
Механика: уязвимость в __ptrace_may_access(), которая пропускает dumpable-проверку когда task->mm == NULL. do_exit() запускает exit_mm() перед exit_files() — нет mm, но fd-ы ещё живые — и pidfd_getfd(2) успешно выполняется в этом окне когда uid вызывающего совпадает с целевым.
Это не LPE до root — это чтение приватных ключей. Для серверов с SSH-доступом — это критично.
# НЕМЕДЛЕННАЯ ДИАГНОСТИКА:
# Смотрим были ли у нас непривилегированные пользователи
# с доступом к системе за последние сутки
last | head -20
grep "Accepted" /var/log/auth.log | grep -v root | tail -20
# Если на сервере нет непривилегированных пользователей кроме root —
# риск значительно ниже (нет кому эксплуатировать)
awk -F: '$3 >= 1000 && $7 != "/sbin/nologin" && $7 != "/bin/false" \
{print $1, $7}' /etc/passwd
# МИТИГЕЙШН пока патча нет:
# 1. Ужесточаем права на SSH host keys (уже должны быть 600):
ls -la /etc/ssh/ssh_host_*
chmod 600 /etc/ssh/ssh_host_*_key
# 2. Ограничиваем чтение shadow:
ls -la /etc/shadow # должен быть 640 или 000
chmod 640 /etc/shadow
# 3. Если на сервере есть непривилегированные пользователи —
# временно блокируем ptrace для непривилегированных:
echo 1 | tee /proc/sys/kernel/yama/ptrace_scope
# или более жёстко:
echo 3 | tee /proc/sys/kernel/yama/ptrace_scope
# 3 = только root может ptrace (ломает некоторые отладчики)
# Делаем permanent через sysctl:
echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# СЛЕДИМ за патчем:
# upstream: kernel.org (ветки 7.0.x, 6.18.x, 6.12.x)
# Ubuntu: ubuntu.com/security/notices
# RHEL: access.redhat.com/security
Как работает правильная реакция на fresh disclosure:
Первые 30 минут: читаем advisory, понимаем prerequisites (local? network? authenticated?), проверяем есть ли у нас этот компонент в системе.
30 минут — 2 часа: ищем временный митигейшн (не патч — его ещё нет). Применяем если риск в нашей среде реален.
После: ждём патча дистрибутива, ставим как только появится, убираем митигейшн.
Это не паника — это процесс. Разница в том, что процесс можно делегировать и автоматизировать.
Итог: ptrace_scope = 1 — это одна команда которая снижает риск не только от CVE-2026-46333, но и от всего класса ptrace-атак. Это и есть defence-in-depth в действии.
#skills #linux #cve #security #реакция #sysadmin #admin_future
🐧 Linux: DirtyDecrypt — пятый вариант page-cache атаки за три недели, и сегодня вышел PoC
Коллеги, майский марафон Linux-уязвимостей продолжается. Сегодня утром на Hacker News — DirtyDecrypt (CVE-2026-31635). Это уже пятая уязвимость одного класса за три недели.
DirtyDecrypt обнаружили исследователи Zellic и V12, но при попытке зарепортить узнали — уязвимость уже была исправлена в mainline. Это rxgk page cache write из-за отсутствующего COW-guard в rxgk_decrypt_skb(). Оценивается как вариант Copy Fail, Dirty Frag и Fragnesia — все они дают root на уязвимых системах.
Хорошая новость: патч уже в mainline. Плохая: PoC публичен прямо сейчас.
Итоговая карта всех пяти за май 2026:
Все шесть закрываются одним митигейшном на системах без IPsec/RxRPC:
Зачем это важно как тренд: DirtyDecrypt обнаружили независимо, а уязвимость уже исправили — это говорит о том, что AI-assisted code analysis находит одни и те же классы ошибок быстрее чем когда-либо. Темп раскрытий этого месяца — не случайность, это новая норма.
Итог: mitigation-файл + ptrace_scope = закрыты все шесть CVE мая. Патч ядра ставим при ближайшем обслуживании. И да — это ещё не конец месяца.
#linux #kernel #cve #dirtydecrypt #security #sysadmin #admin_future
Коллеги, майский марафон Linux-уязвимостей продолжается. Сегодня утром на Hacker News — DirtyDecrypt (CVE-2026-31635). Это уже пятая уязвимость одного класса за три недели.
DirtyDecrypt обнаружили исследователи Zellic и V12, но при попытке зарепортить узнали — уязвимость уже была исправлена в mainline. Это rxgk page cache write из-за отсутствующего COW-guard в rxgk_decrypt_skb(). Оценивается как вариант Copy Fail, Dirty Frag и Fragnesia — все они дают root на уязвимых системах.
Хорошая новость: патч уже в mainline. Плохая: PoC публичен прямо сейчас.
Итоговая карта всех пяти за май 2026:
Copy Fail (CVE-2026-31431) — 29 апреля — AF_ALG, algif_aead
Dirty Frag (CVE-2026-43284) — 7 мая — ESP xfrm, esp4/esp6
Dirty Frag (CVE-2026-43500) — 7 мая — RxRPC rxrpc
Fragnesia (CVE-2026-46300) — 13 мая — XFRM ESP-in-TCP
DirtyDecrypt(CVE-2026-31635) — 20 мая — rxgk_decrypt_skb
CVE-2026-46333 — 19 мая — ptrace exit-race (чтение ключей)
Все шесть закрываются одним митигейшном на системах без IPsec/RxRPC:
# ПОЛНЫЙ МИТИГЕЙШН — все шесть CVE мая 2026
# (если algif_aead, esp4/esp6, rxrpc не нужны):
printf "install algif_aead /bin/false\n\
install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n" | \
tee /etc/modprobe.d/may2026-kernel-lpe.conf
rmmod algif_aead esp4 esp6 rxrpc 2>/dev/null || true
# Для CVE-2026-46333 (ptrace / SSH keys):
echo "kernel.yama.ptrace_scope = 1" >> \
/etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# Проверяем статус патчей на всём флоте:
# Нужны ядра: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207
uname -r
# ModuleJail — автоматизирует это для всех неиспользуемых модулей:
# github.com/jnuyens/modulejail
sudo sh modulejail -p conservative
Зачем это важно как тренд: DirtyDecrypt обнаружили независимо, а уязвимость уже исправили — это говорит о том, что AI-assisted code analysis находит одни и те же классы ошибок быстрее чем когда-либо. Темп раскрытий этого месяца — не случайность, это новая норма.
Итог: mitigation-файл + ptrace_scope = закрыты все шесть CVE мая. Патч ядра ставим при ближайшем обслуживании. И да — это ещё не конец месяца.
#linux #kernel #cve #dirtydecrypt #security #sysadmin #admin_future
🪟 Windows: AD CS в майском обновлении получил постквантовую криптографию — и это важнее чем звучит
Коллеги, в шуме вокруг Secure Boot, RC4 и Patch Tuesday почти никто не заметил кое-что важное в майском обновлении Windows Server 2025. Тихо и без фанфар.
Майское обновление добавляет в AD CS поддержку постквантовой криптографии: ML-DSA-44, ML-DSA-65 и ML-DSA-87 на Windows Server 2025. Это позволяет администраторам начать оценивать постквантовые криптографические алгоритмы и проверять PQC-готовность корпоративных PKI-сред.
Что это такое и зачем нам это сейчас:
Атака «harvest now, decrypt later» — не теория. Спецслужбы нескольких стран активно предупреждают, что противники уже сейчас эксфильтруют зашифрованные данные в расчёте на квантовое дешифрование в течение ближайшего десятилетия. Для любых данных с требованиями конфиденциальности более 10 лет — решение должно приниматься сейчас.
Как попробовать уже сегодня:
Что сейчас работает и что нет: ранние тесты показывают многообещающие результаты для сценариев подписи, таких как code signing. Однако более широкие инфраструктурные нагрузки, включая TLS, VPN и Remote Desktop, пока ограничены.
Зачем начинать сейчас если TLS/VPN ещё не готовы: организации, начинающие миграцию в 2026 году, имеют достаточно времени для соответствия срокам устаревания 2030 года. Те кто ждут 2028-го — столкнутся со сжатой высокорисковой миграцией.
Итог: не деплоить в продакшн. Поднять тестовую CA, выпустить ML-DSA-65 сертификат, посмотреть на размеры и latency. Это час работы — и понимание что тебя ждёт через 2-3 года.
#windows #adcs #pki #postquantum #security #sysadmin #admin_future
Коллеги, в шуме вокруг Secure Boot, RC4 и Patch Tuesday почти никто не заметил кое-что важное в майском обновлении Windows Server 2025. Тихо и без фанфар.
Майское обновление добавляет в AD CS поддержку постквантовой криптографии: ML-DSA-44, ML-DSA-65 и ML-DSA-87 на Windows Server 2025. Это позволяет администраторам начать оценивать постквантовые криптографические алгоритмы и проверять PQC-готовность корпоративных PKI-сред.
Что это такое и зачем нам это сейчас:
Атака «harvest now, decrypt later» — не теория. Спецслужбы нескольких стран активно предупреждают, что противники уже сейчас эксфильтруют зашифрованные данные в расчёте на квантовое дешифрование в течение ближайшего десятилетия. Для любых данных с требованиями конфиденциальности более 10 лет — решение должно приниматься сейчас.
Как попробовать уже сегодня:
# ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ:
# Windows Server 2025 с майским обновлением KB5087539
# AD CS Certification Authority установлен и настроен
# Проверяем версию после обновления:
Get-ItemProperty `
"HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" |
Select-Object CurrentBuild, UBR
# Нужен build 26100.32860 или выше
# Открываем Certificate Authority MMC:
# certsrv.msc -> [CA Name] -> Properties -> Cryptography
# Через PowerShell — проверяем доступные PQC-алгоритмы:
# (Нужен Provider Category: Key Storage Provider)
certutil -csplist | Select-String "ML-DSA"
# Создаём тестовый PQC-сертификат (code signing сценарий):
# 1. В CA Properties -> Cryptography -> CSP: Microsoft Software Key Storage Provider
# 2. Signature algorithm: ML-DSA-65 (оптимальный баланс размер/безопасность)
# 3. Выпускаем тестовый cert только для code signing
# ПРЕДУПРЕЖДЕНИЕ о размерах:
# ML-DSA-65 цепочка сертификатов: ~10KB vs ~1.5KB у ECDSA
# Это влияет на TLS handshake latency
# Пока НЕ для TLS, VPN, RDP — только для code signing и оценки
# Проверяем выпущенные PQC-сертификаты:
certutil -CAInfo
certutil -view -out "SerialNumber,NotBefore,NotAfter,Subject,PublicKey"
Что сейчас работает и что нет: ранние тесты показывают многообещающие результаты для сценариев подписи, таких как code signing. Однако более широкие инфраструктурные нагрузки, включая TLS, VPN и Remote Desktop, пока ограничены.
Зачем начинать сейчас если TLS/VPN ещё не готовы: организации, начинающие миграцию в 2026 году, имеют достаточно времени для соответствия срокам устаревания 2030 года. Те кто ждут 2028-го — столкнутся со сжатой высокорисковой миграцией.
Итог: не деплоить в продакшн. Поднять тестовую CA, выпустить ML-DSA-65 сертификат, посмотреть на размеры и latency. Это час работы — и понимание что тебя ждёт через 2-3 года.
#windows #adcs #pki #postquantum #security #sysadmin #admin_future
🔥1
🧠 Skills: Май 2026 — разбор полётов. Чему нас научил этот месяц
Коллеги, среда — хороший момент для рефлексии в середине недели. Май 2026 ещё не закончился, но уже войдёт в учебники по security operations. Разберём что реально можно взять из этого месяца.
Шесть CVE в Linux за три недели. Patch Tuesday со 120 CVE. RC4 enforcement в июле. Secure Boot до июня. Entra hard match 1 июня. DirtyDecrypt сегодня утром.
Три вещи которые работали и три которые нет:
Один практический вывод в виде действия прямо сейчас:
Зачем это важно как навык:
Реакция на инциденты — это мышца. Май 2026 её неплохо потренировал. Команды которые вышли из этого месяца с отлаженным процессом — в следующий раз среагируют за часы, а не за дни.
Итог: три недели CVE-шторма показали кто автоматизирован, кто нет. Кто мониторит правильное, кто реагирует на заголовки. Это не критика — это диагностика. Используй её.
#skills #security #процессы #автоматизация #sysadmin #admin_future
Коллеги, среда — хороший момент для рефлексии в середине недели. Май 2026 ещё не закончился, но уже войдёт в учебники по security operations. Разберём что реально можно взять из этого месяца.
Шесть CVE в Linux за три недели. Patch Tuesday со 120 CVE. RC4 enforcement в июле. Secure Boot до июня. Entra hard match 1 июня. DirtyDecrypt сегодня утром.
Три вещи которые работали и три которые нет:
ЧТО РАБОТАЛО:
1. МОНИТОРИНГ ПРАВИЛЬНЫХ ИСТОЧНИКОВ
Команды которые быстро реагировали — подписаны на:
- CISA KEV (daily digest)
- Ubuntu/RHEL security advisories (RSS/email)
- Hacker News /new (для zero-day до патча)
Не на твиттер и не на агрегаторы с задержкой в день.
2. BLACKLIST КАК ВРЕМЕННЫЙ ЩИТ
Кто заблокировал algif_aead/esp4/esp6/rxrpc в первый день —
спокойно ставил патчи по расписанию.
Кто ждал патча сразу — жил три недели под риском.
3. ЧЁТКИЙ ПРОЦЕСС ПРИОРИТИЗАЦИИ
5 вопросов: есть ли в моей среде? активно эксплуатируется?
вектор атаки? митигейшн? когда патч?
Экономит 80% времени на панику.
ЧТО НЕ РАБОТАЛО:
1. "ПРОПАТЧИМ НА СЛЕДУЮЩЕЙ НЕДЕЛЕ"
Copy Fail появился 29 апреля с публичным PoC.
CISA KEV — 1 мая. Дедлайн — 15 мая.
Кто ждал плановый цикл через две недели —
работал без защиты неделю с известным рабочим эксплойтом.
2. РУЧНОЙ BLACKLIST БЕЗ АВТОМАТИЗАЦИИ
Каждая новая CVE требовала нового захода на каждый сервер.
ModuleJail — ответ на это. IaC-подход — правильный ответ.
3. РЕАКЦИЯ НА ЗАГОЛОВКИ БЕЗ ПРОВЕРКИ СРЕДЫ
"Copy Fail затрагивает все дистрибутивы с 2017 года!"
— да, но только при наличии загруженного algif_aead.
На many продакшн-серверах его нет.
Паника тратит ресурсы которые нужны на реальные угрозы.
Один практический вывод в виде действия прямо сейчас:
# Если после этого месяца у тебя нет этих трёх вещей — сделай сегодня:
# 1. ПОДПИСКА НА CISA KEV (RSS для мониторинга)
# https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
# Добавь в любой RSS-ридер или настрой скрипт
# 2. ПРОВЕРКА KERNEL MITIGATION СТАТУСА
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc" && \
echo "РИСК: модули загружены" || \
echo "OK: модули не загружены"
# 3. ANSIBLE PLAYBOOK ДЛЯ RAPID BLACKLIST DEPLOY
# Один playbook который за 2 минуты закрывает флот
# вместо ручного захода на каждый сервер:
# ---
# - name: Kernel module mitigations May 2026
# hosts: all
# become: true
# tasks:
# - name: Block vulnerable kernel modules
# copy:
# dest: /etc/modprobe.d/may2026-mitigations.conf
# content: |
# install algif_aead /bin/false
# install esp4 /bin/false
# install esp6 /bin/false
# install rxrpc /bin/false
Зачем это важно как навык:
Реакция на инциденты — это мышца. Май 2026 её неплохо потренировал. Команды которые вышли из этого месяца с отлаженным процессом — в следующий раз среагируют за часы, а не за дни.
Итог: три недели CVE-шторма показали кто автоматизирован, кто нет. Кто мониторит правильное, кто реагирует на заголовки. Это не критика — это диагностика. Используй её.
#skills #security #процессы #автоматизация #sysadmin #admin_future
🐧 Linux: Май 2026 закрыт — финальный чеклист по ядру для тех кто ещё не всё сделал
Коллеги, четверг 21 мая — подводим итог самому насыщенному security-месяцу в Linux за несколько лет. Шесть уязвимостей, все патчи вышли, но статистика показывает: большая часть флотов ещё не обновлена.
Это четвёртая уязвимость ядра Linux требующая внимания администраторов за три недели, после Copy Fail (29 апреля), Dirty Frag (7 мая) и Fragnesia (13 мая). Если вы не хотите экстренно патчить и перезагружать несколько раз в месяц — это сигнал выстроить систему.
Финальный чеклист на сегодня:
Один архитектурный вывод из мая: AI-assisted code analysis нашёл несколько уязвимостей в одной и той же поверхности атаки за три недели. Вопрос для 2026 года — не будут ли продолжаться kernel-эксплойты, а будет ли ваша инфраструктура защищена когда они появятся.
Итог: патч + перезагрузка + mitigation-файл + ptrace_scope. Четыре пункта. Если не сделано — сделай прямо сейчас, это последний четверг мая.
#linux #kernel #security #patch #sysadmin #admin_future
Коллеги, четверг 21 мая — подводим итог самому насыщенному security-месяцу в Linux за несколько лет. Шесть уязвимостей, все патчи вышли, но статистика показывает: большая часть флотов ещё не обновлена.
Это четвёртая уязвимость ядра Linux требующая внимания администраторов за три недели, после Copy Fail (29 апреля), Dirty Frag (7 мая) и Fragnesia (13 мая). Если вы не хотите экстренно патчить и перезагружать несколько раз в месяц — это сигнал выстроить систему.
Финальный чеклист на сегодня:
# ШАГ 1: Проверяем версию ядра — все патчи закрыты начиная с:
# 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207 / 5.10.256
uname -r
# ШАГ 2: Если ядро не обновлено — ставим немедленно
# Ubuntu/Debian:
apt update && apt full-upgrade -y
# RHEL/Rocky/AlmaLinux:
dnf update kernel -y
# ШАГ 3: Mitigation-файл — закрывает все page-cache CVE даже без патча
cat /etc/modprobe.d/may2026-kernel-lpe.conf 2>/dev/null || \
printf "install algif_aead /bin/false\ninstall esp4 /bin/false\n\
install esp6 /bin/false\ninstall rxrpc /bin/false\n" | \
tee /etc/modprobe.d/may2026-kernel-lpe.conf
# ШАГ 4: ptrace_scope — закрывает CVE-2026-46333 (чтение SSH-ключей)
sysctl kernel.yama.ptrace_scope
# Если 0 — ставим минимум 1:
echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ШАГ 5: ModuleJail — системное решение для флота
# После патча и перезагрузки — автоматически блокирует ВСЕ
# неиспользуемые модули, не только эти шесть:
# github.com/jnuyens/modulejail
sudo sh modulejail -p conservative
# ШАГ 6: Проверяем что drop_caches сброшен на хостах
# где могла быть эксплуатация (критично для Fragnesia):
echo 1 | tee /proc/sys/vm/drop_caches
Один архитектурный вывод из мая: AI-assisted code analysis нашёл несколько уязвимостей в одной и той же поверхности атаки за три недели. Вопрос для 2026 года — не будут ли продолжаться kernel-эксплойты, а будет ли ваша инфраструктура защищена когда они появятся.
Итог: патч + перезагрузка + mitigation-файл + ptrace_scope. Четыре пункта. Если не сделано — сделай прямо сейчас, это последний четверг мая.
#linux #kernel #security #patch #sysadmin #admin_future
🪟 Windows: Secure Boot — 10 дней до истечения, финальный чеклист для серверов
Коллеги, конец июня — не абстрактный дедлайн. Две из трёх затронутых сертификатов — Microsoft Corporation KEK CA 2011 и Microsoft UEFI CA 2011 — истекают в июне 2026. Microsoft Windows Production PCA 2011, подписывающий сам Windows Boot Manager, истекает в октябре 2026.
Что произойдёт если не успеть: системы без обновления потеряют возможность устанавливать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.
Критически важное для серверов: в отличие от Windows PC, которые получают сертификаты 2023 года автоматически через Controlled Feature Rollout, Windows Server требует ручного действия — автоматически они не прилетают.
Устройства оффлайн, в спящем режиме, на полке — не получат обновления и рискуют оказаться изолированными после июня 2026. Старое железо без OEM firmware-обновлений также в опасности.
Итог: если у тебя есть серверы со статусом NOT_STARTED — это твоя задача на сегодня. Не на следующей неделе. Сегодня. До июня осталось меньше шести недель.
#windows #secureboot #windowsserver #security #sysadmin #admin_future
Коллеги, конец июня — не абстрактный дедлайн. Две из трёх затронутых сертификатов — Microsoft Corporation KEK CA 2011 и Microsoft UEFI CA 2011 — истекают в июне 2026. Microsoft Windows Production PCA 2011, подписывающий сам Windows Boot Manager, истекает в октябре 2026.
Что произойдёт если не успеть: системы без обновления потеряют возможность устанавливать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.
Критически важное для серверов: в отличие от Windows PC, которые получают сертификаты 2023 года автоматически через Controlled Feature Rollout, Windows Server требует ручного действия — автоматически они не прилетают.
# ФИНАЛЬНЫЙ АУДИТ — выполнить сегодня
# 1. Сколько серверов НЕ готово:
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -ExpandProperty Name
$report = foreach ($s in $servers) {
try {
Invoke-Command -ComputerName $s -ScriptBlock {
$sb = Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue
[PSCustomObject]@{
Server = $env:COMPUTERNAME
Status = if ($sb) {$sb.UEFICA2023Status} else {"NOT_STARTED"}
SecureBoot = (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)
}
} -ErrorAction Stop
} catch {
[PSCustomObject]@{Server=$s; Status="UNREACHABLE"; SecureBoot=$null}
}
}
$report | Group-Object Status | Format-Table Name, Count -AutoSize
# Экспортируем список на обработку:
$report | Where-Object {$_.Status -ne "Updated"} |
Export-Csv "secureboot_critical_$(Get-Date -Format yyyyMMdd).csv" `
-NoTypeInformation
# 2. Запускаем обновление на серверах NOT_STARTED:
# Выполнить на каждом затронутом сервере:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Перезагрузить, затем запустить ещё раз
# Проверить статус: должен стать "Updated"
# 3. Offline / air-gapped серверы — ручной путь:
# Скачать пакет с aka.ms/GetSecureBoot
# Применить через DISM или wusa.exe
# 4. Проверяем dbx (список отозванных bootloader-ов):
# Актуальный dbx критичен вместе с новыми сертификатами
Get-SecureBootUEFI -Name dbx | Select-Object -ExpandProperty Bytes | Measure-Object
# Пустой или нулевой dbx = риск
Устройства оффлайн, в спящем режиме, на полке — не получат обновления и рискуют оказаться изолированными после июня 2026. Старое железо без OEM firmware-обновлений также в опасности.
Итог: если у тебя есть серверы со статусом NOT_STARTED — это твоя задача на сегодня. Не на следующей неделе. Сегодня. До июня осталось меньше шести недель.
#windows #secureboot #windowsserver #security #sysadmin #admin_future
🧠 Skills: Crypto Agility — навык который нужен сисадмину прямо сейчас, а не в 2030-м
Коллеги, пятничный пост в четверг — потому что тема важная, а пятницу займёт что-нибудь свежее.
Май 2026 дал нам два отличных примера почему crypto agility — это не теоретическая концепция. Secure Boot 2011 → 2023: ротация корневых сертификатов требует ручного вмешательства на тысячах серверов. RC4 в Kerberos: 30 лет использовали, теперь принудительное отключение в июле. Оба случая — болезненная миграция из-за отсутствия гибкости.
Crypto agility — это способность менять криптографические алгоритмы и ключи без переписывания всей инфраструктуры. Это не про квантовые компьютеры. Это про то, что алгоритмы устаревают регулярно.
Три практических элемента которые нужны прямо сейчас:
Зачем это важно именно сейчас а не в 2030-м: криптографическая гибкость — это не просто ответ на квантовую угрозу. Слабое шифрование может быть взломано уже сегодня, а скомпрометированные долгоживущие сертификаты готовы для будущей подделки. Прежде чем справляться с живыми угрозами — нужно понимать текущую криптографическую архитектуру.
Итог: инвентаризация + мониторинг + план замены. Это три часа работы которые меняют "паника в июне 2026" на "плановое обновление в марте 2026". Сделай это сейчас — следующий Secure Boot истечёт в 2033-м, и это уже твоя задача.
#skills #security #crypto #pkи #sysadmin #admin_future
Коллеги, пятничный пост в четверг — потому что тема важная, а пятницу займёт что-нибудь свежее.
Май 2026 дал нам два отличных примера почему crypto agility — это не теоретическая концепция. Secure Boot 2011 → 2023: ротация корневых сертификатов требует ручного вмешательства на тысячах серверов. RC4 в Kerberos: 30 лет использовали, теперь принудительное отключение в июле. Оба случая — болезненная миграция из-за отсутствия гибкости.
Crypto agility — это способность менять криптографические алгоритмы и ключи без переписывания всей инфраструктуры. Это не про квантовые компьютеры. Это про то, что алгоритмы устаревают регулярно.
Три практических элемента которые нужны прямо сейчас:
ЭЛЕМЕНТ 1: КРИПТОГРАФИЧЕСКАЯ ИНВЕНТАРИЗАЦИЯ
Что нужно знать о каждом сервисе:
- Какие алгоритмы используются (RSA? ECDSA? AES?)
- Где хранятся ключи и сертификаты
- Когда истекают сертификаты
- Какие зависимости (приложения, протоколы)
Инструменты:
# Linux: сканируем конфиги
grep -r "SSLProtocol\|SSLCipherSuite\|ssl_protocols\|ssl_ciphers" \
/etc/nginx/ /etc/apache2/ /etc/haproxy/ 2>/dev/null
# Проверяем TLS на работающих сервисах:
nmap --script ssl-enum-ciphers -p 443 <IP>
# Сертификаты в системе:
find /etc -name "*.crt" -o -name "*.pem" 2>/dev/null | \
xargs -I{} openssl x509 -in {} -noout -subject -enddate 2>/dev/null
# Windows: сертификаты в хранилищах
Get-ChildItem Cert:\LocalMachine\My |
Select-Object Subject, NotAfter, Thumbprint |
Sort-Object NotAfter
ЭЛЕМЕНТ 2: МОНИТОРИНГ СРОКА ЖИЗНИ
Автоматический алерт за 90/30 дней до истечения любого сертификата.
Это то чего не было для Secure Boot 2011 — никто не получил алерт
в 2024 году что через два года сертификаты истекут.
# Простой скрипт мониторинга сертификатов:
find /etc -name "*.crt" -o -name "*.pem" 2>/dev/null | \
while read cert; do
exp=$(openssl x509 -in "$cert" -noout -enddate 2>/dev/null | \
cut -d= -f2)
if [ -n "$exp" ]; then
exp_epoch=$(date -d "$exp" +%s 2>/dev/null)
now_epoch=$(date +%s)
days_left=$(( (exp_epoch - now_epoch) / 86400 ))
if [ "$days_left" -lt 90 ]; then
echo "WARN: $cert expires in $days_left days ($exp)"
fi
fi
done
ЭЛЕМЕНТ 3: ЗАМЕНА БЕЗ ДАУНТАЙМА
Для каждого критичного сервиса должен быть ответ на вопрос:
"Если нам нужно сменить сертификат/алгоритм прямо сейчас —
сколько это займёт и что потребует перезапуска?"
Если ответ "несколько дней и полный downtime" — это проблема.
Если "15 минут и горячая перезагрузка конфига" — это crypto agility.
nginx -s reload # Hot reload сертификата без downtime
systemctl reload apache2 # То же для Apache
Зачем это важно именно сейчас а не в 2030-м: криптографическая гибкость — это не просто ответ на квантовую угрозу. Слабое шифрование может быть взломано уже сегодня, а скомпрометированные долгоживущие сертификаты готовы для будущей подделки. Прежде чем справляться с живыми угрозами — нужно понимать текущую криптографическую архитектуру.
Итог: инвентаризация + мониторинг + план замены. Это три часа работы которые меняют "паника в июне 2026" на "плановое обновление в марте 2026". Сделай это сейчас — следующий Secure Boot истечёт в 2033-м, и это уже твоя задача.
#skills #security #crypto #pkи #sysadmin #admin_future
🐧 Linux: Rust теперь в APT — и это важнее чем кажется
Коллеги, на этой неделе случилось кое-что, о чём мало кто написал — но что касается каждого администратора Debian/Ubuntu-флота напрямую.
Два события мая 2026 окончательно переместили Rust из категории «языка будущего» в load-bearing инфраструктуру. Первое: Linux 7.0 убрал пометку experimental с Rust — теперь это официальный язык ядра наравне с C. Второе: APT maintainer Julian Klode объявил что Debian's package manager начинает требовать жёсткую зависимость от Rust начиная с мая 2026.
Что это значит практически для администратора:
APT — это package manager для Debian и каждого производного дистрибутива: Ubuntu, Linux Mint, Pop!_OS, Kali Linux, Raspberry Pi OS. Rust-компилятор, стандартная библиотека и части Sequoia PGP теперь встроены в core APT — для парсинга .deb, .ar и .tar файлов, а также HTTP signature verification.
Зачем Rust именно здесь? APT обрабатывает недоверенные данные (пакеты из интернета) на уровне root. Memory corruption в парсере пакетов — это immediate root compromise. Rust устраняет целые классы уязвимостей вроде use-after-free, которые типичны для C-кода. Это интеграция снижает реальную поверхность атаки в местах где это наиболее критично.
Для администраторов air-gapped и закрытых сред — это практическое действие сейчас: убедись что твои offline-репозитории содержат rust-пакеты. После обновления APT на системах без сети это может сломать
Итог: Rust перешёл из «интересно, но не моя проблема» в «часть базовой инфраструктуры моего дистрибутива». Пятница — хороший момент проверить offline-репы.
#linux #rust #debian #ubuntu #apt #security #sysadmin #admin_future
Коллеги, на этой неделе случилось кое-что, о чём мало кто написал — но что касается каждого администратора Debian/Ubuntu-флота напрямую.
Два события мая 2026 окончательно переместили Rust из категории «языка будущего» в load-bearing инфраструктуру. Первое: Linux 7.0 убрал пометку experimental с Rust — теперь это официальный язык ядра наравне с C. Второе: APT maintainer Julian Klode объявил что Debian's package manager начинает требовать жёсткую зависимость от Rust начиная с мая 2026.
Что это значит практически для администратора:
APT — это package manager для Debian и каждого производного дистрибутива: Ubuntu, Linux Mint, Pop!_OS, Kali Linux, Raspberry Pi OS. Rust-компилятор, стандартная библиотека и части Sequoia PGP теперь встроены в core APT — для парсинга .deb, .ar и .tar файлов, а также HTTP signature verification.
Зачем Rust именно здесь? APT обрабатывает недоверенные данные (пакеты из интернета) на уровне root. Memory corruption в парсере пакетов — это immediate root compromise. Rust устраняет целые классы уязвимостей вроде use-after-free, которые типичны для C-кода. Это интеграция снижает реальную поверхность атаки в местах где это наиболее критично.
# Проверяем Rust в APT на Ubuntu 26.04:
apt-cache show apt | grep -i rust
dpkg -l | grep -i "rust\|rustc"
# Для администраторов air-gapped сред:
# APT теперь требует rustc при сборке из исходников
# Проверяем что offline-репозиторий включает rust-пакеты:
apt-get install --dry-run apt 2>&1 | grep -i rust
# Для Debian 13 Forky (выход 2027):
# Rust будет требоваться для сборки ядра модулей через DKMS
# Уже сейчас можно подготовить offline-кэш:
apt-get download rustc cargo libstd-rust-dev
# Смотрим версию Rust в системе:
rustc --version 2>/dev/null || echo "Rust not installed"
# На Ubuntu 26.04 должно быть 1.80+ из репозитория
Для администраторов air-gapped и закрытых сред — это практическое действие сейчас: убедись что твои offline-репозитории содержат rust-пакеты. После обновления APT на системах без сети это может сломать
apt upgrade если Rust недоступен.Итог: Rust перешёл из «интересно, но не моя проблема» в «часть базовой инфраструктуры моего дистрибутива». Пятница — хороший момент проверить offline-репы.
#linux #rust #debian #ubuntu #apt #security #sysadmin #admin_future
🪟 Windows: Пятничный дайджест — что закрыть до выходных по майским дедлайнам
Коллеги, конец рабочей недели — самое время для быстрой проверки: что из майских задач закрыто, а что уйдёт в понедельник с риском стать проблемой.
Три критических дедлайна ближайших недель — статус на сегодня:
Secure Boot — истечение в июне (осталось ~5 недель):
Системы без обновлённых сертификатов Secure Boot потеряют возможность получать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.
Entra hard match — дедлайн 1 июня (осталось 10 дней):
С 1 июня блокируется возможность синхронизировать cloud-privileged учётки через Entra Connect. Если не проверено — проверь прямо сейчас.
Kerberos RC4 — финал в июле (осталось ~6 недель):
После июля реестровый ключ RC4DefaultDisablementPhase игнорируется. Если не провёл аудит Event 201/202 — время поджимает.
Что реально можно сделать за пятницу:
Итог: пятница — для аудита и планирования, не для опасных изменений. Три команды выше покажут где ты стоишь. Остальное — в понедельник с холодной головой.
#windows #secureboot #kerberos #security #patchmanagement #sysadmin #admin_future
Коллеги, конец рабочей недели — самое время для быстрой проверки: что из майских задач закрыто, а что уйдёт в понедельник с риском стать проблемой.
Три критических дедлайна ближайших недель — статус на сегодня:
Secure Boot — истечение в июне (осталось ~5 недель):
Системы без обновлённых сертификатов Secure Boot потеряют возможность получать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.
Entra hard match — дедлайн 1 июня (осталось 10 дней):
С 1 июня блокируется возможность синхронизировать cloud-privileged учётки через Entra Connect. Если не проверено — проверь прямо сейчас.
Kerberos RC4 — финал в июле (осталось ~6 недель):
После июля реестровый ключ RC4DefaultDisablementPhase игнорируется. Если не провёл аудит Event 201/202 — время поджимает.
# ПЯТНИЧНЫЙ ЧЕКЛИСТ — 3 команды, 5 минут:
# 1. Secure Boot статус (топ-10 серверов по риску):
Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -First 10 Name |
ForEach-Object {
Invoke-Command -ComputerName $_.Name -ScriptBlock {
$sb = Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -EA SilentlyContinue
"$env:COMPUTERNAME : $(if($sb){$sb.UEFICA2023Status}else{'NOT_STARTED'})"
} -EA SilentlyContinue
}
# 2. RC4 — сколько событий за эту неделю (если много — срочно):
Get-WinEvent -LogName System -ComputerName (hostname) |
Where-Object {$_.Id -in @(201,202,203) -and
$_.TimeCreated -gt (Get-Date).AddDays(-7)} |
Group-Object Id | Select-Object Name, Count
# 3. Entra hard match — есть ли привилегированные sync'd учётки:
# (быстрая проверка без Graph модуля)
Get-ADUser -Filter {Enabled -eq $true} `
-Properties MemberOf, adminCount |
Where-Object {$_.adminCount -eq 1} |
Select-Object SamAccountName, DistinguishedName |
Export-Csv "friday_privcheck.csv" -NoTypeInformation
Write-Host "Привилегированных учёток: $((Import-Csv friday_privcheck.csv).Count)"
# Если > 20 — стоит пересмотреть список до понедельника
Что реально можно сделать за пятницу:
ЧТО МОЖНО ЗАКРЫТЬ ЗА 30 МИНУТ:
- Запустить Secure Boot update task на 5-10 серверах
- Посмотреть RC4 events за неделю
- Сохранить список NOT_STARTED серверов для понедельника
ЧТО НЕ ТРОГАТЬ В ПЯТНИЦУ ВЕЧЕРОМ:
- Не менять пароли krbtgt без подготовки
- Не обновлять DC в конце недели без снапшота
- Не применять Kerberos-политики без тестовой группы
Итог: пятница — для аудита и планирования, не для опасных изменений. Три команды выше покажут где ты стоишь. Остальное — в понедельник с холодной головой.
#windows #secureboot #kerberos #security #patchmanagement #sysadmin #admin_future
❤1👍1👏1
🧠 Skills: Май 2026 — итог месяца для тех кто дочитал до пятницы
Шесть уязвимостей ядра Linux. Patch Tuesday со 120 CVE. Kerberos RC4 enforcement. Secure Boot истечение. Entra hard match. Windows Server Summit. PostQuantum в AD CS. ModuleJail. DirtyDecrypt. Killswitch-proposal.
Это не был лёгкий месяц.
Но вот что важно: всё это было управляемо. Каждая из этих угроз имела митигейшн, опубликованный в течение часов после раскрытия. Каждый дедлайн был известен заранее. Каждое обновление было доступно до того как ситуация стала критической.
Три вещи которые отделяли тех кто справился от тех кто нет:
Один честный вопрос для выходных:
Возьми любую из майских угроз. Спроси себя: "Сколько времени прошло между раскрытием и моим первым действием?" Один день — отлично. Три дня — приемлемо. Неделя — есть над чем работать. Больше — это не проблема знаний, это проблема процесса.
Июнь 2026 принесёт свои сюрпризы. Они будут другими. Но твоя способность реагировать — это мышца которую прокачал май. Либо прокачал, либо нет.
Вы прошли самый насыщенный месяц в истории канала. Если инфраструктура работает — вы сделали всё правильно. Этого достаточно.
#skills #итоги #май2026 #security #процессы #sysadmin #admin_future
Шесть уязвимостей ядра Linux. Patch Tuesday со 120 CVE. Kerberos RC4 enforcement. Secure Boot истечение. Entra hard match. Windows Server Summit. PostQuantum в AD CS. ModuleJail. DirtyDecrypt. Killswitch-proposal.
Это не был лёгкий месяц.
Но вот что важно: всё это было управляемо. Каждая из этих угроз имела митигейшн, опубликованный в течение часов после раскрытия. Каждый дедлайн был известен заранее. Каждое обновление было доступно до того как ситуация стала критической.
Три вещи которые отделяли тех кто справился от тех кто нет:
1. МОНИТОРИНГ ПРАВИЛЬНЫХ ИСТОЧНИКОВ
Не твиттер, не агрегаторы.
CISA KEV → RSS → алерт на email или в мессенджер
Ubuntu/RHEL security advisory → email subscription
Microsoft Security Update Guide → RSS
Это 20 минут настройки однажды vs постоянный шум.
2. ПРОЦЕСС А НЕ ПАНИКА
Пять вопросов для любого CVE:
Есть ли в моей среде?
Активно эксплуатируется?
Вектор атаки?
Есть ли митигейшн?
Когда патч?
Структура превращает "срочно всё горит" в управляемые действия.
3. АВТОМАТИЗАЦИЯ РУТИНЫ
Кто запустил ModuleJail один раз — не правил blacklist 5 раз.
Кто выстроил Ansible-пайплайн — не заходил вручную на 30 серверов.
Кто настроил мониторинг Secure Boot — узнал о проблеме в феврале
а не в июне.
Один честный вопрос для выходных:
Возьми любую из майских угроз. Спроси себя: "Сколько времени прошло между раскрытием и моим первым действием?" Один день — отлично. Три дня — приемлемо. Неделя — есть над чем работать. Больше — это не проблема знаний, это проблема процесса.
Июнь 2026 принесёт свои сюрпризы. Они будут другими. Но твоя способность реагировать — это мышца которую прокачал май. Либо прокачал, либо нет.
Вы прошли самый насыщенный месяц в истории канала. Если инфраструктура работает — вы сделали всё правильно. Этого достаточно.
#skills #итоги #май2026 #security #процессы #sysadmin #admin_future
🔥3
🐧 Linux: CVE-2026-46333 — Qualys опубликовала полный advisory. Ротируй SSH-ключи.
Коллеги, свежие подробности по уязвимости, которую разбирали на этой неделе. Qualys Threat Research Unit опубликовала полный технический advisory по CVE-2026-46333, и там есть детали которые меняют оценку риска.
TRU идентифицировала узкое окно в котором привилегированный процесс, сбрасывающий свои учётные данные, остаётся доступным через ptrace-операции даже когда флаг dumpable должен был закрыть этот путь. Комбинируя это окно с системным вызовом pidfd_getfd() (добавленным в ядро в январе 2020), атакующий может перехватить открытые файловые дескрипторы умирающего привилегированного процесса и унаследовать его доступ к файлам — включая приватные SSH-ключи хоста.
На хостах где в период уязвимости были непривилегированные пользователи — SSH host keys и локально кэшированные учётные данные следует считать потенциально раскрытыми. Qualys рекомендует ротировать host keys и проверить весь административный материал находившийся в памяти setuid-процессов.
Также на неделе вышла PinTheft — отдельный LPE для Arch Linux систем. Если у тебя есть Arch в продакшне (надеюсь что нет) — смотри отдельный advisory.
Итог: если на хосте были local users в мае — ротируй SSH-ключи. Это 3 минуты работы и полное закрытие вектора постэксплуатации.
#linux #cve #ssh #security #kernel #sysadmin #admin_future
Коллеги, свежие подробности по уязвимости, которую разбирали на этой неделе. Qualys Threat Research Unit опубликовала полный технический advisory по CVE-2026-46333, и там есть детали которые меняют оценку риска.
TRU идентифицировала узкое окно в котором привилегированный процесс, сбрасывающий свои учётные данные, остаётся доступным через ptrace-операции даже когда флаг dumpable должен был закрыть этот путь. Комбинируя это окно с системным вызовом pidfd_getfd() (добавленным в ядро в январе 2020), атакующий может перехватить открытые файловые дескрипторы умирающего привилегированного процесса и унаследовать его доступ к файлам — включая приватные SSH-ключи хоста.
На хостах где в период уязвимости были непривилегированные пользователи — SSH host keys и локально кэшированные учётные данные следует считать потенциально раскрытыми. Qualys рекомендует ротировать host keys и проверить весь административный материал находившийся в памяти setuid-процессов.
# ШАГ 1: Патч уже есть — проверяем версию ядра
uname -r
# Патч в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207
# Если старше — обновляем НЕМЕДЛЕННО:
apt update && apt full-upgrade -y && reboot # Ubuntu/Debian
dnf update kernel -y && reboot # RHEL/Rocky/AlmaLinux
# ШАГ 2: Была ли уязвимость активна? Смотрим были ли local users:
last | grep -v "^reboot\|^wtmp" | \
awk '{print $1}' | sort -u
# Если только root — риск ниже. Если были другие — ротируем ключи.
# ШАГ 3: Ротация SSH host keys (если есть подозрение на компрометацию):
# Генерируем новые ключи:
rm /etc/ssh/ssh_host_*
ssh-keygen -A
# Перезапускаем SSH (NOT текущую сессию — откроем новую первой):
systemctl restart sshd
# Обновляем known_hosts на всех клиентах:
ssh-keyscan -H <server_ip> >> ~/.ssh/known_hosts
# ШАГ 4: Митигейшн если патч ещё не применён:
# ptrace_scope = 2 блокирует только root может ptrace непривилегированных
echo "kernel.yama.ptrace_scope = 2" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope = 3 — полный запрет (ломает отладчики, gdb, strace)
Также на неделе вышла PinTheft — отдельный LPE для Arch Linux систем. Если у тебя есть Arch в продакшне (надеюсь что нет) — смотри отдельный advisory.
Итог: если на хосте были local users в мае — ротируй SSH-ключи. Это 3 минуты работы и полное закрытие вектора постэксплуатации.
#linux #cve #ssh #security #kernel #sysadmin #admin_future
🪟 Windows: Server vNext build 29585 — что нового и почему ReFS Boot важнее чем звучит
Коллеги, Microsoft выпустила Windows Server vNext Preview Build 29585 — последний перед летним затишьем. Разбираем что важно для тех кто следит за следующим поколением.
ReFS Boot включён по умолчанию для всех vNext preview builds. При этом ReFS Boot системы создают минимальный WinRE раздел в 2GB. Когда WinRE не может быть обновлён из-за нехватки места — система может отключить WinRE. Отключение WinRE не удаляет раздел. Но если WinRE раздел удалить и расширить boot volume поверх него — это действие необратимо без чистой установки.
Это важно понимать заранее: ReFS Boot — это фундамент для Quick Machine Recovery (QMR). Без WinRE раздела QMR не работает. Удалить раздел в попытке освободить место = потерять возможность самовосстановления сервера.
Что ещё в 29585:
Quick Machine Recovery теперь доступен для тестирования в vNext Insider Previews. Функция обеспечивает восстановление серверов при критических ошибках загрузки — QMR может автоматически искать облачные исправления для устранения массовых загрузочных сбоев, значительно снижая нагрузку на IT-администраторов когда одновременно затронуты несколько устройств.
Зачем следить за vNext прямо сейчас: preview builds доступны до 15 сентября 2026. Если планируешь переход на следующую версию Windows Server — сейчас идеальный момент поднять тестовый стенд, изучить ReFS Boot поведение и QMR до того как это появится в GA.
Итог: ReFS Boot + QMR = будущее Windows Server recovery. Но WinRE раздел священен — не трогать, не уменьшать, не удалять. Запомни это до GA.
#windows #windowsserver #vnext #refs #qmr #sysadmin #admin_future
Коллеги, Microsoft выпустила Windows Server vNext Preview Build 29585 — последний перед летним затишьем. Разбираем что важно для тех кто следит за следующим поколением.
ReFS Boot включён по умолчанию для всех vNext preview builds. При этом ReFS Boot системы создают минимальный WinRE раздел в 2GB. Когда WinRE не может быть обновлён из-за нехватки места — система может отключить WinRE. Отключение WinRE не удаляет раздел. Но если WinRE раздел удалить и расширить boot volume поверх него — это действие необратимо без чистой установки.
Это важно понимать заранее: ReFS Boot — это фундамент для Quick Machine Recovery (QMR). Без WinRE раздела QMR не работает. Удалить раздел в попытке освободить место = потерять возможность самовосстановления сервера.
Что ещё в 29585:
Quick Machine Recovery теперь доступен для тестирования в vNext Insider Previews. Функция обеспечивает восстановление серверов при критических ошибках загрузки — QMR может автоматически искать облачные исправления для устранения массовых загрузочных сбоев, значительно снижая нагрузку на IT-администраторов когда одновременно затронуты несколько устройств.
# Для тех кто тестирует vNext в лабе:
# Проверяем текущий build:
winver
# или
Get-ComputerInfo | Select-Object WindowsBuildLabEx
# Проверяем статус ReFS Boot:
Get-Partition | Where-Object {$_.Type -eq "Recovery"} |
Select-Object DiskNumber, PartitionNumber, Size, Type
# Проверяем размер WinRE раздела (должен быть >= 2GB для ReFS Boot):
reagentc.exe /info
# Ищем: Windows RE location и размер
# КРИТИЧНО: НЕ УДАЛЯТЬ WinRE раздел на vNext builds
# Проверяем что он не будет затронут при расширении диска:
Get-Partition -DiskNumber 0 | Format-Table -AutoSize
# Тестируем QMR в lab (не на продакшне):
# reagentc.exe /setrecoverytestmode
# Перезагружаемся — система войдёт в WinRE и попытается найти remediation
# Для перехода с preview < 29531:
# Апгрейд НЕ поддерживается — только чистая установка
# Дедлайн использования preview: 15 сентября 2026
Зачем следить за vNext прямо сейчас: preview builds доступны до 15 сентября 2026. Если планируешь переход на следующую версию Windows Server — сейчас идеальный момент поднять тестовый стенд, изучить ReFS Boot поведение и QMR до того как это появится в GA.
Итог: ReFS Boot + QMR = будущее Windows Server recovery. Но WinRE раздел священен — не трогать, не уменьшать, не удалять. Запомни это до GA.
#windows #windowsserver #vnext #refs #qmr #sysadmin #admin_future
🧠 Skills: Конец мая — как правильно уйти в отпуск не оставив коллег в огне
Коллеги, впереди лето. Июнь — традиционно сезон отпусков в IT-командах. И традиционно — сезон когда оказывается что только один человек знал как перезапустить критичный сервис.
Разбираем как уходить в отпуск профессионально — чтобы не звонили, и чтобы инфраструктура не горела.
Три вещи которые нужно сделать до отпуска:
Один честный разговор с руководителем до отпуска:
Не "я ухожу, вы справитесь". А "вот три вещи которые могут потребовать внимания, вот кто их закроет, вот как их закрыть". Это занимает 15 минут встречи — и даёт тебе настоящий отпуск, а не режим "в отпуске но на связи".
Зачем это важно для профессии:
Администратор который не может уйти в отпуск без звонков — это признак Bus Factor = 1. Это риск для бизнеса, это проблема команды, и это признак что документация и автоматизация не доделаны. Не геройство. Проблема.
Итог: до отпуска — handoff документ, закрытые июньские дедлайны, передача PagerDuty. После — выключить рабочий чат. Хороших выходных, коллеги. Май позади.
#skills #отпуск #команда #документация #sysadmin #admin_future
Коллеги, впереди лето. Июнь — традиционно сезон отпусков в IT-командах. И традиционно — сезон когда оказывается что только один человек знал как перезапустить критичный сервис.
Разбираем как уходить в отпуск профессионально — чтобы не звонили, и чтобы инфраструктура не горела.
Три вещи которые нужно сделать до отпуска:
ЗА ДВЕ НЕДЕЛИ ДО ОТПУСКА:
1. HANDOFF DOCUMENT — не "я на связи если что"
Шаблон:
# Handoff: [Твоё имя], отпуск [дата] — [дата]
## Контакт на период отпуска
Технические вопросы: [коллега] @username
Срочные инциденты: [тимлид] +7-xxx-xxx
Меня беспокоить: только P1 который не может закрыть команда
## Что сейчас в работе
- [Задача 1]: статус, следующий шаг, кто может продолжить
- [Задача 2]: заморожено до моего возвращения, ничего срочного
## Критичные сервисы и где runbook
- Nginx кластер: runbook в Confluence/RB-WEB-001
- PostgreSQL backup: автоматический, крон в /etc/cron.d/pg_backup
- VPN сервер: если упал — runbook RB-NET-003, ключи у [коллега]
## Что НЕ трогать пока меня нет
- Не обновлять ядро на prod до моего возвращения (RC4 июль!)
- Не менять Kerberos политики (тестирование ещё не завершено)
- Secure Boot update — запущен, ждём статус "Updated" сам придёт
## Алерты и мониторинг
Grafana alerts идут в #infra-alerts Slack
PagerDuty ротация: [коллега] primary на период моего отпуска
2. ПРОВЕРЬ CRITICAL TASKS С ДЕДЛАЙНОМ
В июне: Secure Boot (истекает июнь), Entra hard match (1 июня)
Убедись что эти задачи либо закрыты ДО отпуска
либо передал конкретному человеку с конкретным дедлайном
3. АВТОМАТИЗИРУЙ ЧТО МОЖЕТ СЛОМАТЬСЯ БЕЗ ТЕБЯ
Если что-то требует ручного вмешательства каждую неделю —
это не надёжно для отпуска и не надёжно вообще.
Одна задача автоматизации до отпуска > десяти звонков из него.
Один честный разговор с руководителем до отпуска:
Не "я ухожу, вы справитесь". А "вот три вещи которые могут потребовать внимания, вот кто их закроет, вот как их закрыть". Это занимает 15 минут встречи — и даёт тебе настоящий отпуск, а не режим "в отпуске но на связи".
Зачем это важно для профессии:
Администратор который не может уйти в отпуск без звонков — это признак Bus Factor = 1. Это риск для бизнеса, это проблема команды, и это признак что документация и автоматизация не доделаны. Не геройство. Проблема.
Итог: до отпуска — handoff документ, закрытые июньские дедлайны, передача PagerDuty. После — выключить рабочий чат. Хороших выходных, коллеги. Май позади.
#skills #отпуск #команда #документация #sysadmin #admin_future
👏1
🐧 Linux: CVE-2026-46333 — Qualys опубликовала четыре рабочих эксплойта. Меняем shadow.
Коллеги, вчера Qualys опубликовала полный технический разбор CVE-2026-46333 с деталями которые меняют оценку риска. Это не просто "чтение SSH-ключей" — это четыре разных вектора атаки.
Qualys построила четыре рабочих эксплойта: через chage (раскрывает /etc/shadow), ssh-keysign (раскрывает приватные host-ключи в /etc/ssh/), pkexec (выполняет произвольные команды как root), accounts-daemon (выполняет произвольные команды как root). Все подтверждены на дефолтных установках Debian 13, Ubuntu 24.04, Ubuntu 26.04, Fedora 43 и Fedora 44.
Уязвимость важна потому что современные атаки редко останавливаются на первом плацдарме. RCE работающий как www-data, скомпрометированный CI-джоб, украденный аккаунт разработчика — изначально не root. Локальный баг ядра который читает root-секреты превращает этот плацдарм в кражу учётных данных, имперсонацию хоста или lateral movement.
Зачем ротировать именно shadow и SSH-ключи: в shared-hosting среде разница между раскрытием учётных данных и прямым root-доступом практически отсутствует — любого из этих файлов атакующему достаточно чтобы пройти весь оставшийся путь.
Итог: патч + перезагрузка. Если были локальные пользователи в мае — SSH host keys и пароли из shadow считай скомпрометированными. Ротация — это 10 минут работы.
#linux #cve #ssh #kernel #security #sysadmin #admin_future
Коллеги, вчера Qualys опубликовала полный технический разбор CVE-2026-46333 с деталями которые меняют оценку риска. Это не просто "чтение SSH-ключей" — это четыре разных вектора атаки.
Qualys построила четыре рабочих эксплойта: через chage (раскрывает /etc/shadow), ssh-keysign (раскрывает приватные host-ключи в /etc/ssh/), pkexec (выполняет произвольные команды как root), accounts-daemon (выполняет произвольные команды как root). Все подтверждены на дефолтных установках Debian 13, Ubuntu 24.04, Ubuntu 26.04, Fedora 43 и Fedora 44.
Уязвимость важна потому что современные атаки редко останавливаются на первом плацдарме. RCE работающий как www-data, скомпрометированный CI-джоб, украденный аккаунт разработчика — изначально не root. Локальный баг ядра который читает root-секреты превращает этот плацдарм в кражу учётных данных, имперсонацию хоста или lateral movement.
# ПАТЧ ЕСТЬ — проверяем прямо сейчас:
uname -r
# Патч в коммите Линуса "ptrace: slightly saner get_dumpable() logic"
# Закрыт в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 5.15.207 / 5.10.256
# Обновляем если старее:
apt update && apt full-upgrade -y && reboot # Ubuntu/Debian
dnf update kernel -y && reboot # RHEL/Rocky/AlmaLinux
# ЕСЛИ НА ХОСТЕ БЫЛИ ЛОКАЛЬНЫЕ ПОЛЬЗОВАТЕЛИ В МАЕ:
# 1. Ротируем SSH host keys:
rm /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub
ssh-keygen -A
systemctl restart sshd
# 2. Ротируем пароли учёток из /etc/shadow:
# (shadow мог быть прочитан через chage-эксплойт)
# Минимум — все системные аккаунты с shell:
awk -F: '$7 !~ /nologin|false/ && $3 >= 1000 {print $1}' \
/etc/passwd | while read u; do passwd --expire $u; done
# 3. Митигейшн если патч ещё не применён:
echo "kernel.yama.ptrace_scope = 2" >> \
/etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope=2: только root может ptrace непривилегированных процессов
Зачем ротировать именно shadow и SSH-ключи: в shared-hosting среде разница между раскрытием учётных данных и прямым root-доступом практически отсутствует — любого из этих файлов атакующему достаточно чтобы пройти весь оставшийся путь.
Итог: патч + перезагрузка. Если были локальные пользователи в мае — SSH host keys и пароли из shadow считай скомпрометированными. Ротация — это 10 минут работы.
#linux #cve #ssh #kernel #security #sysadmin #admin_future