🐧 Linux: CVE-2026-4631 — Cockpit открывает root без пароля. Патчить немедленно

Коллеги, на прошлой неделе тихо закрыли одну из самых неприятных уязвимостей апреля в Linux-мире. Если вы используете Cockpit на RHEL, Rocky, AlmaLinux или Oracle Linux — читайте внимательно.

CVE-2026-4631: Cockpit передаёт имя пользователя и имя хоста напрямую в ssh без санитизации. Злоумышленник может указать имя пользователя вида "x; touch /tmp/flag; #" — и SSH выполнит инжектированную команду до того, как проверит корректность логина. Аутентификация не нужна.

Два вектора атаки: инъекция через поле username и инъекция через hostname (параметр передаётся без разделителя "--"). Результат — RCE на хосте с Cockpit.

# Проверяем версию Cockpit
rpm -q cockpit
# или
apt show cockpit 2>/dev/null | grep Version

# Смотрим открыт ли порт Cockpit наружу (по умолчанию 9090)
ss -tlnp | grep 9090
# Если виден на 0.0.0.0 — критично

# Немедленный митигейшн: закрываем доступ снаружи
# Firewalld:
firewall-cmd --remove-service=cockpit --permanent
firewall-cmd --reload

# iptables:
iptables -A INPUT -p tcp --dport 9090 -j DROP

# ---- ПАТЧ ----
# RHEL / Rocky / AlmaLinux 8:
dnf update cockpit -y  # целевой пакет: cockpit-334.x или новее

# RHEL / Rocky / AlmaLinux 9:
dnf update cockpit -y  # целевой пакет: cockpit-344.x или новее

# RHEL 10:
dnf update cockpit -y  # целевой пакет: cockpit-344-3.el10_1 или новее

# Проверяем что обновились
rpm -q cockpit
systemctl restart cockpit

Зачем это важно: Red Hat оценил уязвимость как Critical. Эксплуатация не требует аутентификации — достаточно сетевого доступа к порту 9090. PoC уже опубликован на GitHub.

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

#linux #cve #cockpit #rhel #security #sysadmin #admin_future

🪟 Windows: Kerberos RC4 enforcement уже включился — что сломалось и что делать

Коллеги, апрельский Patch Tuesday принёс не только патчи, но и тихое изменение, которое уже ломает аутентификацию в тех средах, где не подготовились.

Начиная с апреля 2026 года, апрельское накопительное обновление меняет дефолтное поведение Kerberos KDC: для учётных записей без явно заданного msDS-SupportedEncryptionTypes теперь выдаются только AES-SHA1-билеты. RC4 больше не используется по умолчанию.

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

В июле 2026 поведение зафиксируется окончательно и откат в режим аудита станет невозможен. Времени мало.

# ШАГ 1: Ищем учётки БЕЗ AES-ключей
# Скрипт от Microsoft (GitHub: microsoft/Kerberos-Crypto):
# List-AccountKeys.ps1 — находит аккаунты с RC4 но без AES

# Ручная проверка: смотрим Event ID 201, 202 в System Log DC
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -in @(201,202,206,207)} |
    Select-Object TimeCreated, Id, Message |
    Format-List

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

# ШАГ 3: Явно задаём шифрование для проблемных учёток
# 0x18 = AES128 + AES256, 0x1C = AES128 + AES256 + RC4 (временно)
Set-ADUser -Identity "svc_legacy_app" `
    -KerberosEncryptionType AES128,AES256

# ШАГ 4: Временный откат если уже всё сломалось
# Возвращаем DC в режим аудита (работает ДО июля 2026):
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" `
    -Name "RC4DefaultDisablementPhase" -Value 1

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

Зачем это нужно:
RC4 позволяет Kerberoasting: атакующий запрашивает билет, зашифрованный RC4, и взламывает его оффлайн. Современные GPU делают это за минуты. Microsoft убирает RC4 принудительно — и это правильно.

Итог: аудит уже три месяца доступен через Event ID 201-202. Если ты не смотрел — посмотри сегодня. Июль ждать не будет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#skills #eol #инфраструктура #patching #sysadmin #admin_future

🐧 Linux: CVE-2026-31431 «Copy Fail» — LPE до root из 732 байт Python-кода

Коллеги, 30 апреля опубликованы подробности уязвимости, которая затрагивает практически каждый Linux-сервер в вашей инфраструктуре. Срочно читать.

CVE-2026-31431 «Copy Fail» — локальное повышение привилегий до root для любого локального пользователя без специальных условий. Уязвимость присутствует в ядрах начиная с Linux 4.14 (2017 год). Эксплоит — 732 байта Python-кода, уже опубликован.

Проблема в authencesn — криптографическом шаблоне ядра — и эксплуатируется через интерфейс AF_ALG. Исправлена в ядрах 6.18.22, 6.19.12 и 7.0.

Действия прямо сейчас:

# ШАГ 1 — Проверяем версию ядра
uname -r
# Затронуты: 4.14 — 6.19.11, 6.18.0 — 6.18.21

# ШАГ 2 — Митигейшн БЕЗ перезагрузки (если патч ещё не вышел)
# Отключаем модуль algif_aead
lsmod | grep algif_aead
rmmod algif_aead 2>/dev/null || echo "Module not loaded — safe"

# Запрещаем загрузку модуля навсегда:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/disable-algif-aead.conf
echo "blacklist algif_aead" >> /etc/modprobe.d/disable-algif-aead.conf

# ШАГ 3 — Обновляем ядро (для дистрибутивов с патчем)
# Ubuntu 22.04 / 24.04:
apt update && apt install --only-upgrade linux-image-generic -y

# RHEL 9 / AlmaLinux 9 / Rocky 9:
dnf update kernel -y

# Debian 12:
apt update && apt full-upgrade -y

# ШАГ 4 — Проверяем активность AF_ALG в среде
# Смотрим открытые AF_ALG сокеты
ss -a | grep ALG
# Если пусто — модуль не используется, отключение безопасно

# ШАГ 5 — Перезагружаемся после обновления ядра
# Проверяем что загрузились с новым ядром:
uname -r  # должен показать исправленную версию

Зачем это важно:
Уязвимость быстро закроют в облаках и Kubernetes-кластерах. Но длинный хвост старых и забытых Linux-систем — роутеры, IoT, терминалы, промышленные системы — останется уязвимым ещё годами. В вашей инфраструктуре наверняка есть такие «забытые» хосты.

Итог: два действия сегодня — blacklist algif_aead на всех серверах где нет патча, обновить ядро там где патч доступен. PoC публичный, счёт идёт на часы.

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

🪟 Windows: Майский Patch Tuesday — hotpatch возобновляется, но есть нюанс

Коллеги, 11 мая — первый hotpatch-вторник после апрельского OOB-фикса, который прервал цикл. Разбираем коротко что происходит и чего ждать.

Напомню схему: январь, апрель, июль, октябрь — полный baseline с перезагрузкой. Февраль, март, май, июнь и т.д. — hotpatch без рестарта. Май по плану должен быть hotpatch-месяцем.

Но апрель внёс коррективу: OOB-фикс KB5091157 для апрельского DC reboot-loop потребовал перезагрузки и приостановил hotpatching. Для тех кто его установил — hotpatch возобновится только с майского обновления.

Ещё важный момент о стоимости: hotpatch для Windows Server 2025 вне Azure требует Azure Arc и платной подписки через Azure Arc — это не бесплатная функция для on-premises серверов.

# Проверяем текущий статус hotpatch на сервере
# Смотрим что установлено последним
Get-HotFix | Sort-Object InstalledOn -Descending |
    Select-Object HotFixID, InstalledOn -First 3

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

# Проверяем подключение к Azure Arc (нужно для on-prem hotpatch):
azcmagent show 2>$null | Select-String "Status"
# Connected = готов к hotpatch

# Смотрим историю hotpatch vs обычных обновлений:
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" |
    Where-Object {$_.Id -eq 19} |  # ID 19 = успешная установка
    Select-Object TimeCreated, Message |
    Format-List |
    Select-Object -First 5

# Если нужно временно отключить hotpatch (например для тестов):
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" `
    -Name "HotPatchRestrictions" -Value 1 -Type DWORD
# Вернуть: Value 0

Зачем это нужно:
Hotpatch не охватывает все обновления — .NET-патчи, несекьюрити-обновления и патчи сторонних компонентов по-прежнему требуют перезагрузки. Нельзя считать, что сервер с hotpatch больше никогда не перезагружается.

Итог: четыре перезагрузки в год вместо двенадцати — реальное улучшение для uptime. Но hotpatch не бесплатен на on-prem и не заменяет полный patch management. Знай что у тебя включено и почему.

#windows #hotpatch #patchtuesday #windowsserver2025 #sysadmin #admin_future

🧠 Skills: Говори на языке бизнеса — или вечно жди выделения бюджета

Коллеги, суббота — день для разговора не про технологии, а про то, что реально двигает карьеру вперёд.

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

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

Три конкретных паттерна, которые работают:

ПАТТЕРН 1: ПРОБЛЕМА → РИСК → ДЕНЬГИ

Инженерный язык:
"Нам нужно обновить PostgreSQL 14 — он уходит на EOL в ноябре"

Бизнесовый язык:
"PostgreSQL 14 теряет поддержку безопасности 12 ноября.
 После этой даты критические уязвимости в БД не будут
 получать патчи. Миграция займёт 3 дня и стоит X рублей.
 Инцидент с компрометацией данных — от Y рублей плюс
 репутационные потери."

Результат: решение принимается за 10 минут, а не за 3 месяца.

ПАТТЕРН 2: ПРЕДЛОЖЕНИЕ СО СТАТУС-КВО

Плохо:
"Нам нужно внедрить мониторинг"

Хорошо:
"Сейчас мы узнаём об инцидентах от пользователей.
 В среднем это 40+ минут до начала реакции.
 Prometheus + Grafana за 2 дня работы сократит это
 до 2 минут. Последний инцидент обошёлся в Z рублей.
 Инструмент бесплатный."

Результат: ты не просишь — ты предлагаешь ROI.

ПАТТЕРН 3: АПДЕЙТ ДЛЯ РУКОВОДИТЕЛЯ (еженедельно, 3 пункта)

Формат:
✓ Что сделано (с бизнес-результатом, не с техническим)
⚠ Что требует решения (с вариантами, не с вопросом)
→ Что планируется (с ожидаемым результатом)

Пример:
✓ Завершена миграция БД — теперь есть поддержка
  безопасности до 2029 года
⚠ Срок действия SSL-сертификата сайта — 14 мая.
  Вариант A: автообновление (0 руб). Вариант B: платный
  сертификат (5000 руб). Рекомендую A.
→ На следующей неделе аудит прав доступа — снизим
  риск инсайдерских инцидентов

Умение «продавать» решения руководству — это не политика и не манипуляция. Это умение предоставить цифры, обосновать ценность с точки зрения бизнес-задач и рассчитать риски.

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

Итог: технические знания открывают дверь в профессию. Умение говорить с бизнесом открывает дверь в карьеру. Оба навыка нужны — и второй прокачивается так же, как первый: практикой.

#skills #карьера #коммуникация #sysadmin #admin_future

🐧 Linux: живёшь под root в контейнере — живёшь опасно. Исправляем за 10 минут

Коллеги, воскресный пост про вещь, которую игнорируют даже опытные администраторы. Зайди в любой Docker-окружение на среднестатистическом сервере и запусти:

docker inspect $(docker ps -q) --format '{{.Name}}: User={{.Config.User}}'

Готов поспорить — большинство контейнеров покажут пустой User. Это означает root внутри. 79% Linux-атак в 2026 году используют легитимные системные инструменты — bash, cron, curl. Контейнер с root-процессом при любом побеге из namespace превращается в полноценный вектор атаки на хост.

Исправляется в три шага:

# В Dockerfile: создаём непривилегированного пользователя
FROM ubuntu:24.04

RUN groupadd -r appgroup && \
    useradd -r -g appgroup -s /sbin/nologin appuser

# Устанавливаем зависимости под root — пока ещё нужно
RUN apt-get update && apt-get install -y nginx && \
    chown -R appuser:appgroup /var/log/nginx /var/cache/nginx

# Переключаемся на непривилегированного
USER appuser

CMD ["nginx", "-g", "daemon off;"]

# Для уже запущенных контейнеров — аудит прямо сейчас:
# Кто реально запускает процессы внутри:
docker exec <container> ps aux | head -5

# В docker-compose.yml — добавляем user для каждого сервиса:
# services:
#   app:
#     image: myapp:latest
#     user: "1001:1001"  # uid:gid непривилегированного пользователя

# Запрещаем privilege escalation на уровне демона Docker:
# В /etc/docker/daemon.json:
# {
#   "userns-remap": "default",
#   "no-new-privileges": true
# }

# Проверяем что флаг no-new-privileges работает:
docker run --security-opt no-new-privileges:true \
    --user 1001 alpine whoami

Зачем это нужно:
Контейнер не является изолированной средой по умолчанию. Безопасность зависит от корректной настройки. Запуск под root — это не дефолт ради удобства, это дефолт ради лени. После вчерашней CVE-2026-31431 «Copy Fail» — любой непривилегированный пользователь на хосте мог стать root. Если контейнер уже запускается как root — второй шаг атаки не нужен.

Итог: один Dockerfile и десять минут — и твои контейнеры перестают быть тривиальным вектором атаки. Запусти аудит сегодня.

#linux #docker #containers #security #hardening #sysadmin #admin_future

🪟 Windows: PhantomRPC — архитектурная дыра в RPC без патча и без CVE

Коллеги, 24 апреля на Black Hat Asia 2026 Kaspersky раскрыли уязвимость, которую Microsoft отказалась патчить. Называется PhantomRPC — и она касается каждой Windows-машины в вашей инфраструктуре.

PhantomRPC эксплуатирует архитектурную слабость в том, как Windows RPC runtime (rpcrt4.dll) обрабатывает подключения к недоступным RPC-серверам. Когда привилегированный процесс пытается подключиться к отключённому сервису, система не проверяет легитимность ответившего сервера. Атакующий с доступом уровня NT AUTHORITY\NETWORK SERVICE разворачивает вредоносный RPC-сервер, перехватывает вызов и через RpcImpersonateClient получает токен SYSTEM.

Microsoft оценила проблему как moderate severity и закрыла тикет без CVE и без запланированного патча, сославшись на то что для атаки нужен SeImpersonatePrivilege. Kaspersky с этим не согласны — этот привилей есть у огромного числа сервисных аккаунтов по умолчанию.

Что делать сегодня — три митигейшна:

# ШАГ 1: ETW-мониторинг RPC-активности
# Ловим RPC_S_SERVER_UNAVAILABLE (Event ID 1) от привилегированных процессов

# Включаем расширенный аудит RPC:
auditpol /set /subcategory:"RPC Events" /success:enable /failure:enable

# Ищем подозрительную активность в логах:
Get-WinEvent -LogName "Microsoft-Windows-RPC/Admin" -MaxEvents 100 |
    Where-Object {$_.Id -eq 1} |
    Select-Object TimeCreated, Message |
    Format-List

# ШАГ 2: Ограничиваем SeImpersonatePrivilege
# Смотрим кто имеет этот привилей (должны быть только системные аккаунты):
$accounts = @()
$policy = secedit /export /cfg "$env:TEMP\secpol.cfg" /quiet
Get-Content "$env:TEMP\secpol.cfg" |
    Select-String "SeImpersonatePrivilege" |
    ForEach-Object { Write-Host $_ }
# Убираем лишние аккаунты через GPO:
# Computer Config -> Security Settings -> User Rights Assignment
# -> Impersonate a client after authentication

# ШАГ 3: Держим критичные сервисы запущенными
# Если TermService, DHCP Client, W32Time запущены —
# атакующий не может занять их endpoint
Get-Service TermService, Dhcp, W32Time | Select-Object Name, Status

# Убеждаемся что они в автозапуске:
Set-Service TermService -StartupType Automatic
Set-Service Dhcp -StartupType Automatic
Set-Service W32Time -StartupType Automatic
Start-Service TermService, Dhcp, W32Time

# ШАГ 4: Инструменты Kaspersky для аудита (GitHub: PhantomRPC repo)
# Позволяют найти exploitable RPC call patterns в своей среде

Зачем это важно:
Это не единственный баг в одном компоненте. Kaspersky указывают на системную слабость в том, как Windows обрабатывает провенанс RPC-серверов — значит, новые векторы атаки через эту архитектуру будут появляться и дальше.

Итог: патча нет и не предвидится. Мониторинг ETW, минимизация SeImpersonatePrivilege и запущенные сервисы-«заглушки» — это всё что есть прямо сейчас. Мало, но лучше чем ничего.

#windows #security #rpc #phantomrpc #lpe #sysadmin #admin_future

🧠 Skills: Воскресенье — время для личного технического ревью. Ты делаешь это?

Коллеги, раз в неделю стоит задавать себе три вопроса — не по работе, а по себе как по специалисту. Это занимает 15 минут, но меняет траекторию карьеры за год.

Большинство из нас растут реактивно: выучили то, что потребовалось в инциденте. Прочитали то, что попалось в ленте. Попробовали то, что пришло в задаче. Это нормально, но этого недостаточно для осознанного роста.

Три вопроса воскресного ревью:

ВОПРОС 1: "Что за эту неделю было для меня новым?"
  Новая технология, новый подход, новая проблема.
  Если ответ "ничего" — неделя прошла в зоне комфорта.
  Это не катастрофа, но должно происходить редко.

ВОПРОС 2: "Что я делал руками, что можно автоматизировать?"
  Каждое рутинное действие больше трёх раз —
  это кандидат на скрипт, плейбук или задачу в беклог.
  Запиши. Не обязательно сделать сейчас —
  но записать значит не забыть.

ВОПРОС 3: "Что я узнал о своей инфраструктуре чего не знал раньше?"
  Хорошая инфраструктура постоянно тебя удивляет.
  Если нет — значит либо она слишком проста,
  либо ты перестал её исследовать.

Практический инструмент — engineering log. Не задокументированный runbook, а личный дневник инженера:

# Engineering Log — неделя 18, 2026

## Что нового встретил
- CVE-2026-31431 Copy Fail — изучил механику AF_ALG
- PhantomRPC — понял как работает RPC impersonation
- Попробовал bpftrace для трассировки latency на проде

## Что автоматизировал или хочу автоматизировать
- [x] Скрипт проверки SeImpersonatePrivilege по домену
- [ ] Автоматический EOL-чек через endoflife.date API (следующая неделя)
- [ ] Weekly drift report через Ansible --check (запланировано)

## Что узнал об инфраструктуре
- На трёх серверах algif_aead был загружен — не знал
- Docker-образ staging запускался под root с 2024 года

## Один навык который хочу прокачать в мае
- eBPF: написать свой первый bpftrace скрипт для prod-трассировки

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

Итог: 15 минут в воскресенье. Три вопроса. Один файл в Git. Через год это будет лучшим документом твоего профессионального роста — точнее любого резюме.

#skills #карьера #обучение #рост #sysadmin #admin_future

🐧 Linux: CVE-2026-31431 «Copy Fail» — CISA добавила в KEV, дедлайн 15 мая

Коллеги, обновление по Copy Fail которую мы разбирали на прошлой неделе. 1 мая CISA официально добавила CVE-2026-31431 в каталог Known Exploited Vulnerabilities. Федеральным агентствам США предписано установить патчи до 15 мая 2026 года.

Появились новые подробности о механике атаки: эксплоит выполняет контролируемую 4-байтовую перезапись в page cache ядра, что приводит к повреждению данных. Атакующий получает UID 0 и полные root-привилегии.

Самое неприятное: поскольку page cache — это in-memory версия исполняемых файлов, его модификация фактически изменяет бинарники во время выполнения без записи на диск. Это позволяет инжектировать код в привилегированные бинарники, например /usr/bin/su, и получить root.

Для контейнерных сред угроза выше: Docker, LXC и Kubernetes предоставляют процессам внутри контейнера доступ к подсистеме AF_ALG если модуль algif_aead загружен — даже непривилегированный процесс в контейнере может эксплуатировать эту уязвимость.

# СТАТУС ПАТЧЕЙ (по состоянию на 4 мая):
# Ubuntu 22.04: linux-image-6.5.0-44 или новее — ГОТОВ
# Ubuntu 24.04: linux-image-6.8.0-60 или новее — ГОТОВ
# RHEL/AlmaLinux/Rocky 9: kernel-5.14.0-570 или новее — ГОТОВ
# Debian 12: kernel 6.1.90 или новее — ГОТОВ

# Проверяем версию ядра:
uname -r

# Проверяем что патч применён (для Ubuntu):
apt-cache policy linux-image-$(uname -r) | grep Installed

# Если патч НЕ доступен — митигейшн:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/block-algif.conf
echo "blacklist algif_aead" >> /etc/modprobe.d/block-algif.conf
# Применяется без перезагрузки:
rmmod algif_aead 2>/dev/null; echo "Module blocked"

# Проверяем контейнерные хосты — ищем загруженный модуль:
lsmod | grep algif_aead
# Если вывод пустой — хост безопасен ДО появления патча

Зачем это срочно: уязвимость введена тремя отдельными, каждый по себе безобидными изменениями в 2011, 2015 и 2017 годах. Она присутствует во всех дистрибутивах с 2017 года и активно эксплуатируется прямо сейчас.

Итог: патч + перезагрузка. Или blacklist algif_aead + мониторинг. Третьего варианта нет.

#linux #cve #kernel #security #copyfail #sysadmin #admin_future

🪟 Windows: CVE-2026-32202 — APT28 крадёт NTLMv2-хэши через LNK-файл без клика

Коллеги, срочная новость которую Microsoft тихо пропустила в апрельском Patch Tuesday без пометки «эксплуатируется» — и только 27 апреля признала ошибку. Разбираем.

CVE-2026-32202 — уязвимость в Windows Shell, позволяющая атакующему коерцировать NTLM-аутентификацию от любого пользователя, который открывает папку с вредоносным LNK-файлом. Взаимодействие пользователя не требуется — достаточно открыть папку в Проводнике.

Уязвимость возникла из-за неполного патча для CVE-2026-21510, которую APT28 (Fancy Bear) активно эксплуатировал с декабря 2025 года в кампаниях против Украины и стран ЕС. Февральский патч остановил RCE, но оставил открытым вектор кражи NTLM-хэша.

Механика: LNK-файл содержит UNC-путь вида \\attacker.com\share\payload.cpl. Когда Explorer рендерит папку — инициируется SMB-соединение, Windows автоматически отправляет Net-NTLMv2 хэш атакующему. Хэш используется для NTLM relay атаки или офлайн-брутфорса.

# ШАГ 1: Проверяем установлен ли апрельский патч KB5082063
Get-HotFix | Where-Object {$_.HotFixID -eq "KB5082063"} |
    Select-Object HotFixID, InstalledOn

# Если не установлен — ставим KB5082063 (содержит фикс CVE-2026-32202)
# ВНИМАНИЕ: у KB5082063 есть проблемы с DC в PAM-средах
# Сначала проверить IsGlobalCatalog и установить KB5091157 (OOB-фикс)

# ШАГ 2: НЕМЕДЛЕННЫЙ МИТИГЕЙШН — блокируем исходящий SMB
# На периметровом файрволе — блокируем TCP/445 и TCP/139 наружу
netsh advfirewall firewall add rule `
    name="Block Outbound SMB CVE-2026-32202" `
    dir=out action=block `
    protocol=TCP localport=445,139

# ШАГ 3: Принудительно переходим на Kerberos, отключаем NTLM
# (долгосрочное решение, требует тестирования)
# GPO: Computer Config -> Security Settings -> Security Options
# -> Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
# -> Значение: Deny all

# ШАГ 4: Мониторим попытки NTLM аутентификации наружу
Get-WinEvent -LogName Security |
    Where-Object {$_.Id -eq 4648} |  # Explicit credential use
    Select-Object TimeCreated, Message |
    Format-List | Select-Object -First 10

# ШАГ 5: CISA deadline для FCEB — 12 мая 2026
# Для всех остальных — treat as emergency patch

Зачем это важно: Microsoft опубликовала фикс 14 апреля без пометки об эксплуатации. CISA добавила CVE в KEV и подтвердила активную эксплуатацию только 27 апреля — спустя две недели. Организации не получили формального сигнала о срочности вовремя.

Итог: три действия сегодня — проверить KB5082063, заблокировать исходящий SMB на периметре, включить мониторинг Event ID 4648. APT28 не ждёт.

#windows #security #apt28 #ntlm #cve #sysadmin #admin_future

🧠 Skills: Zero Trust — не продукт который покупают, а архитектура которую строят

Коллеги, начало недели — хороший момент поговорить о концепции, которую все знают по названию, но мало кто понимает как внедрить без боли и многомиллионного бюджета.

CVE-2026-32202 и PhantomRPC из последних новостей — это атаки через доверие. NTLM-хэш утёк потому что система автоматически доверяла серверу с UNC-путём. Lateral movement работает потому что после взлома одной машины атакующий получает доступ к соседним — им он тоже доверяет.

Zero Trust решает именно это. Не "купить продукт", а изменить модель: никогда не доверять, всегда проверять — каждый запрос аутентифицируется независимо от источника, будь то внутри периметра или снаружи.

Практический путь без выброшенного бюджета — шесть шагов:

ШАГ 1: ИНВЕНТАРИЗАЦИЯ (неделя 1)
  Что у нас есть и что критично?
  - Серверы, сервисы, базы данных
  - Кто к чему реально обращается
  - Какие учётки имеют лишние права
  Инструмент: BloodHound (AD), netstat, ss, audit logs

ШАГ 2: IDENTITY (месяц 1 — фундамент)
  MFA на всё. Без исключений.
  Passkeys/FIDO2 где возможно — убираем пароли.
  Принцип минимальных привилегий:
  - Аудит членства в Domain Admins / Administrators
  - Сервисные учётки с минимальным scope
  Это закрывает 80% векторов атаки.

ШАГ 3: СЕГМЕНТАЦИЯ (месяц 2-3)
  Разделяем сеть на зоны:
  - DMZ (публичные сервисы)
  - Servers VLAN (серверы)
  - Users VLAN (рабочие станции)
  - Management VLAN (админский доступ)
  Правило: трафик между зонами — только через явное разрешение.
  Инструмент: firewalld zone policies, nftables, VLAN на коммутаторах

ШАГ 4: DEVICE TRUST (параллельно)
  Только управляемые устройства к критичным ресурсам.
  Intune Compliance Policy или FIDO2 device binding.
  Непривязанное устройство = ненадёжное устройство.

ШАГ 5: МОНИТОРИНГ АНОМАЛИЙ (месяц 3+)
  Не "всё логировать", а "логировать важное":
  - Неудачные аутентификации (Event 4625, 4771)
  - Lateral movement (Event 4648, 4672)
  - Необычные входы по времени и географии
  Prometheus + Loki или любой SIEM.

ШАГ 6: НЕПРЕРЫВНАЯ ВЕРИФИКАЦИЯ
  Периодический re-authentication для долгих сессий.
  Conditional Access: если устройство нездорово — доступ ограничен.

Микросегментация блокирует lateral movement — даже при компрометации учётной записи атакующий ограничен небольшой частью сети, а не получает доступ ко всей инфраструктуре.

Зачем это нужно именно сейчас:
Две уязвимости этой недели — Copy Fail и CVE-2026-32202 — показывают что внешний периметр как единственная линия обороны мёртв. Патчи закрывают дыры, но Zero Trust ограничивает ущерб даже когда дыра не закрыта.

Итог: Zero Trust строится итерационно. Начни с MFA и аудита привилегий — это уже Zero Trust. Не нужно покупать Zscaler за миллион рублей на первом шаге.

#skills #zerotrust #security #инфраструктура #микросегментация #sysadmin #admin_future

🐧 Linux: Proxmox Backup Server 4.2 — S3 из preview стал production, и вот что это меняет

Коллеги, 30 апреля вышел Proxmox Backup Server 4.2 — и это один из тех релизов, где changelog стоит читать внимательно, а не по диагонали.

Три главных изменения для тех кто держит инфраструктуру на Proxmox:

S3-совместимые объектные хранилища теперь официально поддерживаются как backend для бэкапов. Появились счётчики запросов и статистика трафика прямо в сводке datastora — это помогает рано замечать неожиданные всплески трафика. Wasabi, Backblaze, MinIO, RustFS — всё это теперь не "экспериментально", а production-ready.

Push sync jobs теперь могут шифровать снапшоты на лету перед отправкой на удалённый datastore — для сценариев когда принимающий сервер находится в менее доверенной среде. Pull sync jobs симметрично умеют расшифровывать. Ключи для tape и sync теперь управляются из единой панели.

Sync jobs теперь обрабатывают несколько групп параллельно через новый параметр worker-threads. Это увеличивает throughput на высоколатентных линках и помогает обойти ограничения HTTP/2 соединений.

Под капотом: Debian 13.4 Trixie, Linux kernel 7.0 как стабильный default, ZFS 2.4.

# Обновляем существующую установку через APT:
apt update && apt dist-upgrade -y

# Проверяем версию после обновления:
pbs-manager version

# Настраиваем S3 datastore через API (или через WebUI):
# Storage -> Add -> S3-Compatible Storage
# Указываем: bucket, endpoint, access key, secret key, region

# Настраиваем параллельные потоки для sync job (в WebUI):
# Datastore -> Sync Jobs -> Edit -> Worker Threads: 4
# Рекомендуется: 2-8 в зависимости от количества групп и ширины канала

# Проверяем статистику S3 datastora:
# Storage -> [datastore name] -> Summary -> Request Counters
# Мониторим API requests/day и transfer bytes

# Включаем шифрование sync job:
# Sync Job -> Edit -> Encryption -> Enable
# Выбираем ключ (создать: Configuration -> Sync Encryption Keys)

Зачем это важно:
Стратегия 3-2-1 становится реальной без дорогих решений: быстрые локальные бэкапы на основном хранилище PBS, копии в S3 для офсайт-защиты. Теперь это не хак через rclone, а встроенная функция с мониторингом и шифрованием.

Итог: PBS 4.2 — апгрейд без поводов откладывать. Особенно если уже смотрели на S3 как on offsite target.

#linux #proxmox #backup #s3 #storage #sysadmin #admin_future

🪟 Windows: Sysmon стал встроенным — и это меняет мониторинг всего флота

Коллеги, новость которая тихо пришла в марте и уже начала раскатываться — и которую стоит понять до того, как оно появится у вас само.

Microsoft интегрирует Sysmon нативно в Windows 11 и Windows Server 2025. Теперь это Optional Feature — включается стандартным механизмом ОС, обновляется через Windows Update, без ручной загрузки бинарей с Sysinternals.

Что это означает практически: существующие конфигурационные файлы из community-репозиториев (SwiftOnSecurity, sysmon-modular) поддерживаются. Event IDs, XML-конфиги, канал Microsoft-Windows-Sysmon/Operational — всё остаётся как есть.

# Включаем native Sysmon через Optional Features (WS2025 / Win11):
# Вариант 1 — через GUI:
# Settings -> System -> Optional Features -> Add feature -> Sysmon

# Вариант 2 — через PowerShell:
Add-WindowsCapability -Online -Name "Sysmon~~~~0.0.1.0"

# Проверяем статус:
Get-WindowsCapability -Online | Where-Object {$_.Name -like "*Sysmon*"}

# Применяем конфиг (синтаксис тот же что и у standalone):
sysmon -i sysmon-config.xml

# Используем готовый community-конфиг SwiftOnSecurity:
# github.com/SwiftOnSecurity/sysmon-config
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" `
    -OutFile "sysmon-config.xml"
sysmon -c sysmon-config.xml

# Проверяем что события пишутся:
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 10 |
    Select-Object TimeCreated, Id, Message |
    Format-List

# Массовое включение через GPO + DISM:
# Computer Config -> Software Settings -> Software Installation
# или через Intune: Add feature -> Sysmon

# Ключевые Event IDs для первичного мониторинга:
# 1  — Process Create (с хэшами и командной строкой)
# 3  — Network Connection
# 7  — Image Load (подозрительные DLL)
# 10 — Process Access (lsass dump!)
# 22 — DNS Query

Важное предупреждение: если у вас уже развёрнут standalone Sysmon — возможны двойное логирование и конфликты политик. Нужно спланировать миграцию: убедиться в совместимости конфигов, скоординировать с вендором SIEM, обновить правила парсинга.

Зачем это важно:
Раньше Sysmon требовал координации установки на тысячах endpoint, управления конфигами через GPO и отдельного контроля обновлений. Нативная интеграция убирает эту операционную нагрузку — каждая машина под управлением WS2025/Win11 может иметь богатую телеметрию без дополнительных агентов.

Итог: если у тебя нет Sysmon сейчас — самое время начать. Если есть — начни планировать переход на native версию до того как она появится сама.

#windows #sysmon #security #monitoring #siem #sysadmin #admin_future

🧠 Skills: Windows Server Summit 11-13 мая — зачем туда идти и что смотреть

Коллеги, через неделю стартует Windows Server Summit 2026 — бесплатное виртуальное мероприятие от Microsoft. Три дня, инженеры продукта, никакого маркетинга (обещают).

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

Но важнее другое: Summit 2026 станет первым публичным взглядом на Windows Server v.Next — следующее поколение после 2025. Это возможность узнать направление до того как оно станет официальным.

Что конкретно стоит посмотреть — план на три дня:

День 1 (11 мая): Безопасность и патчинг
  Приоритет: сессия про hotpatch — цикл, ограничения,
  что сломалось в апреле и почему
  Ключевые темы апреля которые хочется закрыть:
  - Kerberos RC4 enforcement roadmap (июль — finalize)
  - Secure Boot certificate rollout статус
  - PhantomRPC — будет ли architectural fix

День 2 (12 мая): Операционная эффективность
  Приоритет: OSConfig и drift detection в enterprise
  Интересно: Azure Arc для on-premises серверов
  — что реально даёт без Azure Arc subscription

День 3 (13 мая): Windows Server v.Next preview
  Это главное. Слушать внимательно.
  Смотреть: какие компоненты пересматриваются,
  что уходит (как SysV из Linux), что появляется.
  Задавать вопросы в live Q&A — продукт-команда
  реально читает и отвечает.

ПРАКТИЧЕСКИЙ СОВЕТ:
  Зарегистрируйся сейчас:
  techcommunity.microsoft.com/event/windowsserver-events/
  windows-server-summit-2026/4501032

  Сессии будут доступны в записи — но live Q&A только онлайн.
  Для технических вопросов про hotpatch и RC4 —
  это редкий шанс получить ответ от людей которые это писали.

Зачем это нужно:
Апрель 2026 был жёстким — KB5082063, LSASS crash, BitLocker, CVE-2026-32202, PhantomRPC без патча. Summit — это место где можно спросить "почему так вышло и что дальше" напрямую у инженеров.

Итог: три дня, бесплатно, онлайн. Смотреть не всё подряд — смотреть сессии где есть live Q&A. Там происходит настоящий разговор.

#windows #windowsserver #summit #карьера #обучение #sysadmin #admin_future

🐧 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> # убрать шифрование онлайн

Зачем это важно:
Fedora 44 чувствует себя не просто точечным релизом, а заявлением о направлении развития. Stratis 3.9.0 с онлайн-шифрованием спасёт чью-то шкуру на compliance-аудите.

Итог: если ведёшь лабу на Fedora — обновляйся. Если держишь RHEL/Rocky — смотри на Fedora 44 как на roadmap следующего RHEL.

#linux #fedora #storage #stratis #sysadmin #admin_future

🪟 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 хосты

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

Итог: 8 месяцев — это не запас, это минимум для нормальной миграции. Сделай инвентаризацию сегодня. Это первые 30 минут — и они самые важные.

#windows #windowsserver2016 #eol #migration #sysadmin #admin_future

🧠 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_future

🐧 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

Зачем это важно сегодня: в контейнерных средах Docker, LXC и Kubernetes предоставляют процессам внутри контейнера доступ к AF_ALG если algif_aead загружен на хосте. Copy Fail может использоваться для выхода из изоляции контейнера и захвата физической машины.

Итог: дедлайн CISA — 15 мая. До него восемь дней. Патч или митигейшн — прямо сейчас, не "на следующей неделе".

#linux #cve #copyfail #kernel #security #sysadmin #admin_future

🪟 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"

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

Итог: три вектора атаки, два без патча. Protected Users + мониторинг Event 4648 + заблокированный исходящий SMB — это всё что есть прямо сейчас.

#windows #security #ntlm #cve #sysadmin #admin_future