Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
Admin Future
Відкрити в Telegram
Превращаем эникейщиков в System Architects. 🚀 Твой навигатор в мире IT-инфраструктуры: ▪️ Hard Skills: Linux, Windows, Network, Security ▪️ Tools: Лучший софт и скрытые фишки ▪️ Mindset: Как думать, чтобы платили много Админ - @maksimshap
Показати більше242
Підписники
Немає даних24 години
-167 днів
-1330 день
Архів дописів
242
🪟 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"242
-🐧 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/AlmaLinux242
🧠 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
242
🪟 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 10242
🐧 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/Rocky242
🧠 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)
# Старый питомец умирает с почестями
# Держим его неделю на всякий случай242
🪟 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"}242
🐧 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% пакетов уже воспроизводимы на всех архитектурах242
🧠 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_future242
🪟 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"
242
🐧 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
242
🧠 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
242
🪟 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
242
🐧 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
getenforce или aa-status прямо сейчас. Если не Enforcing — у тебя есть задача на эту пятницу.
#linux #apparmor #selinux #security #hardening #sysadmin #admin_future242
🧠 Skills: Skill Gap Analysis — как найти дыры в своих знаниях до того как их найдёт работодатель
Коллеги, четверг — хороший день для неудобного вопроса: ты знаешь, что именно не знаешь?
Большинство инженеров развиваются реактивно — учат то, с чем столкнулись в инциденте или задаче. Это нормально. Но это означает, что твоя карта знаний полна незаметных белых пятен — в областях, с которыми ты просто не сталкивался на текущем месте.
По данным World Economic Forum, 44% профессиональных навыков обновятся к 2027 году. Для сисадмина это не страшно если ты видишь направление обновления. Страшно когда не видишь.
Простой инструмент: Skill Gap Matrix за 30 минут
ШАГ 1: ИНВЕНТАРИЗАЦИЯ (10 минут) Запиши всё что делаешь регулярно — честно, без украшений: Linux администрирование: [x] bash-скрипты и автоматизация [x] systemd и сервисы [?] eBPF и bpftrace — слышал, не применял [ ] Kernel tuning для высоких нагрузок — не знаю Windows администрирование: [x] Active Directory, GPO, LAPS [x] PowerShell автоматизация [?] Entra ID и гибридные среды — базово [ ] Kerberos delegation и attack paths — не знаю Сеть: [x] VLAN, routing, firewall [?] BGP — читал, не настраивал [ ] SD-WAN архитектура — не знаю Безопасность: [x] Patch management, базовое hardening [?] SIEM и корреляция событий — базово [ ] Threat hunting — не знаю Автоматизация: [x] Ansible playbooks [?] Terraform — базово [ ] GitOps и CI/CD для инфраструктуры — не знаю ШАГ 2: КЛАССИФИКАЦИЯ [x] = уверенно применяю в продакшне [?] = знаю теорию, нет практики [ ] = белое пятно ШАГ 3: ПРИОРИТИЗАЦИЯ Смотришь вакансии на позицию выше твоей. Что там требуют чего у тебя нет? Это твой список приоритетов для изучения. ШАГ 4: ПЛАН НА КВАРТАЛ Выбираешь ОДНУ [?] → прокачиваешь до [x] Выбираешь ОДНУ [ ] → прокачиваешь до [?] Не больше двух направлений за раз. Фокус важнее охвата.Почему это работает: специалисты с продвинутыми навыками в DevOps, облачных технологиях и кибербезопасности в 2026 году зарабатывают значительно больше — разрыв между junior и senior продолжает расти. Но разрыв закрывается не "в целом", а конкретными навыками. Skill Gap Matrix показывает именно их. Итог: 30 минут с листом бумаги или markdown-файлом. Три столбца: знаю, слышал, не знаю. Потом смотришь вакансии мечты и сравниваешь. Это честнее любого теста на самооценку. #skills #карьера #обучение #рост #sysadmin #admin_future
242
🪟 Windows: BlueHammer, RedSun, UnDefend — три новых CVE которые ещё без патча
Коллеги, пока все фиксили KB5082063 и CVE-2026-32202, тихо подтвердились ещё три эксплуатируемые уязвимости Windows — и для двух из них патча пока нет.
Злоумышленники активно эксплуатируют три недавно раскрытые уязвимости Windows — BlueHammer, RedSun и UnDefend — для получения привилегий SYSTEM или повышенных прав администратора. Для RedSun и UnDefend патчи ещё не вышли.
Что известно о каждой:
BlueHammer — уязвимость в Windows Task Host, позволяет повышение привилегий до SYSTEM. CISA выдала отдельный приказ для федеральных агентств патчить BlueHammer. Патч есть в апрельском Patch Tuesday.
CVE-2026-32202 — та самая zero-click NTLM hash leak через LNK-файл. Microsoft первоначально выставила низкий риск в апреле, затем подтвердила активную эксплуатацию и обновила advisory. CISA дедлайн для федеральных агентств — 12 мая.
RedSun и UnDefend — подробности ограничены, оба позволяют SYSTEM/admin privesc, оба пока без патча.
# ШАГ 1: Убеждаемся что апрельские патчи стоят (BlueHammer + CVE-2026-32202)
Get-HotFix | Where-Object {
$_.HotFixID -in @("KB5082063","KB5091157","KB5091470")
} | Select-Object HotFixID, InstalledOn
# ШАГ 2: Митигейшн CVE-2026-32202 (пока RedSun/UnDefend без патча)
# Блокируем исходящий NTLM на периметре:
netsh advfirewall firewall add rule `
name="Block Outbound NTLM SMB" `
dir=out action=block protocol=TCP localport=445,139
# ШАГ 3: Мониторинг аномальной NTLM-аутентификации
# Event ID 4648 = explicit credential use (признак relay-атаки)
Get-WinEvent -LogName Security -MaxEvents 200 |
Where-Object {$_.Id -eq 4648} |
Select-Object TimeCreated, Message |
Format-List | Select-Object -First 5
# ШАГ 4: Для RedSun/UnDefend (нет патча) — принцип наименьших привилегий
# Проверяем кто в локальных Administrators:
Get-LocalGroupMember -Group "Administrators" |
Where-Object {$_.PrincipalSource -ne "Local"} |
Select-Object Name, PrincipalSource
# Убираем лишних, оставляем только нужных:
# Remove-LocalGroupMember -Group "Administrators" -Member "DOMAIN\SomeUser"
# ШАГ 5: Включаем Protected Users для privileged accounts
# Это ограничивает NTLM, Kerberos delegation и credential caching:
Add-ADGroupMember -Identity "Protected Users" `
-Members "SensitiveAdmin1","SensitiveAdmin2"
242
🐧 Linux: Copy Fail — финальный статус и чего ещё не хватает в патчах
Коллеги, CVE-2026-31431 продолжает развиваться. Сегодня финальный срез по статусу — с неожиданным поворотом по RHEL.
Что случилось за неделю: Copy Fail — логический баг в криптографическом шаблоне authencesn ядра Linux. Единый 732-байтовый Python-скрипт даёт root на каждом Linux-дистрибутиве выпущенном с 2017 года. CISA добавила уязвимость в KEV с дедлайном 15 мая.
Неожиданный нюанс от Red Hat: хотя algif_aead нельзя отключить через blacklist так как он вкомпилирован в ядро, сами уязвимые функции можно заблокировать через аргументы загрузки ядра. Это меняет митигейшн для RHEL/AlmaLinux/Rocky.
# СТАТУС ПАТЧЕЙ на 7 мая 2026:
# Ubuntu 22.04/24.04 → ПАТЧ ЕСТЬ: apt update && apt full-upgrade
# Debian 12 → ПАТЧ ЕСТЬ: apt update && apt full-upgrade
# AlmaLinux/Rocky 9 → ПАТЧ ЕСТЬ: dnf update kernel -y
# RHEL 9/10 → ПАТЧ ЕСТЬ (expedited): dnf update kernel -y
# Быстрая проверка везде:
rpm -q --changelog kernel | head -5 # RHEL/Rocky
apt-cache policy linux-image-$(uname -r) # Ubuntu/Debian
# МИТИГЕЙШН ДЛЯ RHEL (algif_aead вкомпилирован, не blacklistится):
# Добавляем в /etc/default/grub в GRUB_CMDLINE_LINUX:
# module_blacklist=algif_aead extra_latent_entropy
# Или через boot args напрямую:
grubby --args="module_blacklist=algif_aead" --update-kernel=ALL
grub2-mkconfig -o /boot/grub2/grub.cfg
# Перезагрузка обязательна
# Для Ubuntu/Debian — blacklist работает через modprobe:
echo "install algif_aead /bin/false" | \
tee /etc/modprobe.d/disable-algif-aead.conf
update-initramfs -u
# Проверяем Kubernetes — контейнеры тоже в зоне риска:
# Смотрим загружен ли модуль на всех нодах:
for node in $(kubectl get nodes -o name); do
echo "=== $node ==="; \
kubectl debug node/${node##*/} -it --image=alpine \
-- lsmod 2>/dev/null | grep algif_aead; \
done
242
🧠 Skills: Собеседование сисадмина. Выпуск #13 — вопросы на архитектурное мышление
Коллеги, продолжаем рубрику. После 12 выпусков про конкретные технологии — пора разобрать тип вопросов, который действительно отделяет Senior от Middle. Это не вопросы на знание команд. Это вопросы на мышление.
Такие вопросы начинаются с "Как бы вы спроектировали..." или "Что бы вы сделали если...". Здесь нет единственно правильного ответа — есть правильный процесс мышления.
---
❓ Вопрос 1: «Вам нужно обеспечить доступность сервиса 99.9%. Как вы это спроектируете?»
❌ Ответ junior: "Поставим резервный сервер"
✅ Ответ инженера:
Начинаем с математики. 99.9% = 8.7 часов даунтайма в год. Это значит одна авария на несколько часов — и мы в рамках SLA. Дальше думаем откуда бывают падения:
ИСТОЧНИКИ НЕДОСТУПНОСТИ: Железо → N+1 серверы, RAID, горячая замена ОС / Software → Автоматический рестарт (systemd Restart=on-failure) Деплой → Blue/Green, canary, rollback за 5 мин Сеть → Два аплинка, bonding, BGP failover Дата-центр → Два ЦОДа (Active/Passive или Active/Active) Человек → Change management, maintenance window, runbook Следующий вопрос интервьюеру: "Что именно входит в downtime по SLA?" ICMP недоступность? Ответ > 2 сек? Ошибки > 1%? Определение downtime меняет всю архитектуру.--- ❓ Вопрос 2: «Production упал. Действия?» ❌ Ответ junior: "Смотрю логи, перезапускаю сервисы" ✅ Ответ инженера — ответ через фреймворк:
1. ОЦЕНИВАЕМ МАСШТАБ (2 мин) Что упало? Всё или часть? Затронуты пользователи? Сколько? Есть ли revenue impact? Уведомить бизнес? 2. КОММУНИКАЦИЯ (параллельно) Статусная страница: incident opened Stakeholders: уведомлены, ждут апдейта каждые 15 мин Команда: war room открыт 3. МИТИГАЦИЯ ДО РАССЛЕДОВАНИЯ (если есть quick win) Откат последнего деплоя если был недавно Failover на резервный узел Включение maintenance mode 4. ROOT CAUSE Когда началось? (корреляция с изменениями) Что изменилось? (деплои, патчи, конфиги, трафик) Логи: что в момент начала падения? 5. FIX + VERIFY + POSTMORTEM Не закрываем инцидент пока не уверены в причине. Postmortem через 48ч — фокус на системе, не на людях.--- ❓ Вопрос 3: «Как бы вы мигрировали monolith на микросервисы не останавливая продакшн?» ❌ Ответ junior: "Переписали бы всё с нуля" ✅ Ответ инженера — Strangler Fig pattern:
Принцип: не заменяем монолит целиком,
а постепенно "душим" его новыми сервисами.
Шаг 1: Ставим reverse proxy перед монолитом
(nginx, Envoy — всё идёт через него)
Шаг 2: Выделяем НАИМЕНЕЕ связанный модуль
(обычно: авторизация, уведомления, отчёты)
Пишем его как отдельный сервис
Шаг 3: Переключаем трафик на новый сервис (1% → 10% → 100%)
Feature flag или weighted routing на прокси
Шаг 4: Мониторим: latency, error rate, бизнес-метрики
Всё хорошо → деплоим полностью
Хуже → мгновенный rollback через прокси
Шаг 5: Повторяем для следующего модуля
Монолит умирает постепенно — без единого "дня X".
Это занимает месяцы, но без простоя продакшна.
💡 Золотое правило архитектурного собеса:
Интервьюер оценивает не правильность ответа, а структуру мышления. Хороший ответ: "Я бы начал с уточняющих вопросов..." Плохой ответ: сразу называет конкретное решение без понимания контекста.
#собеседование_AF #skills #architecture #sysadmin #карьера #admin_future242
🪟 Windows: Windows Server 2016 — до EOL 8 месяцев, и ты, скорее всего, не готов
Коллеги, 12 января 2027 года Microsoft прекращает расширенную поддержку Windows Server 2016. После этой даты прекратятся бесплатные обновления безопасности, техническая помощь и исправления ошибок. Любая уязвимость найденная после этой даты в WS2016 — останется без патча навсегда.
Почему "8 месяцев это много" — опасная иллюзия: каждый месяц промедления сужает окно для тестирования. Организации которые дождутся конца 2026 года для начала валидации приложений — будут вынуждены делать ускоренную миграцию с меньшими возможностями для отката.
Отдельная ловушка — ESU. ESU обеспечивает только критические патчи безопасности — без новых функций, без общей техподдержки. Цена удваивается каждый год, и покупка ESU в год 2 автоматически обязывает доплатить за год 1 ретроактивно. ESU — это не план, это дорогая отсрочка.
# ШАГ 1: Инвентаризация — находим все WS2016 в домене
Get-ADComputer -Filter {OperatingSystem -like "*2016*"} `
-Properties OperatingSystem, LastLogonDate, IPv4Address |
Select-Object Name, IPv4Address, LastLogonDate |
Export-Csv "ws2016_inventory_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
# ШАГ 2: Классифицируем роли каждого сервера
# Для каждого найденного сервера:
Invoke-Command -ComputerName "SERVER01" -ScriptBlock {
Get-WindowsFeature | Where-Object {$_.Installed -eq $true} |
Select-Object Name, DisplayName
}
# ШАГ 3: Проверяем domain functional level
# Поднять DFL до WS2022 — все DC должны быть WS2022+
Get-ADDomain | Select-Object DomainMode
Get-ADForest | Select-Object ForestMode
# ШАГ 4: Матрица приоритизации миграции
# Подставь свои данные:
<#
Сервер | Роль | Критичность | Дедлайн миграции
----------------|-----------|-------------|------------------
DC01-2016 | DC/DNS | Критическая | Август 2026
FILE01-2016 | File Srv | Высокая | Сентябрь 2026
APP01-2016 | Legacy App| Средняя | Октябрь 2026
PRINT01-2016 | Print Srv | Низкая | Ноябрь 2026
#>
# ШАГ 5: Изолируем то что не успеваем (временная мера до миграции)
# Жёсткая сегментация через firewall, минимальный доступ, усиленный мониторинг
# В Intune/WAC — включаем EDR на все WS2016 хосты
242
🐧 Linux: Fedora 44 вышла — и в ней есть кое-что важное для сервера
Коллеги, 28 апреля вышла Fedora Linux 44. Традиционно это не серверный дистрибутив, но Fedora — это preview того, что через полгода-год появится в RHEL, AlmaLinux и Rocky. Смотрим на неё как на хрустальный шар.
Три вещи для сисадмина:
Первое — DNF5 теперь бэкенд для PackageKit. Это означает что скрипты и инструменты, которые зависели от старого бэкенда PackageKit, потребуют обновления. Если у вас есть автоматизация через PackageKit API — проверьте совместимость заранее, до того как это придёт в RHEL 11.
Второе — Stratis 3.9.0 с онлайн-шифрованием. Теперь можно добавить или убрать шифрование существующего storage pool на лету, без пересоздания. Stratis комбинирует XFS, device-mapper для LVM и LUKS/Clevis для шифрования. Для compliance-аудита это неплохая фича.
Третье — /etc/pki/tls/cert.pem удалён по умолчанию. Это может тихо сломать приложения которые зависят от этого файла.
# Обновляемся до Fedora 44 с существующей 42/43:
sudo dnf system-upgrade download --releasever=44
sudo dnf system-upgrade reboot
# Проверяем что сломается — ищем зависимость от cert.pem:
grep -r "cert.pem" /etc/ /opt/ /usr/local/ 2>/dev/null | \
grep -v ".pyc" | head -20
# Если cert.pem нужен — восстанавливаем через update-ca-trust:
update-ca-trust extract
ls -la /etc/pki/tls/cert.pem
# Проверяем что PackageKit теперь через DNF5:
pkcon backend-details
# Должен показать: dnf5
# Смотрим Stratis пулы и шифрование:
stratis pool list
stratis pool encrypt <pool-name> # добавить шифрование онлайн
stratis pool unencrypt <pool-name> # убрать шифрование онлайн
