🧠 Skills: CVE-2026-46333 — новый Linux LPE раскрыт сегодня, и он позволяет читать SSH-ключи

Коллеги, небольшой сдвиг формата сегодняшнего Skills-поста. Вместо soft skills — разберём как правильно реагировать на раскрытие прямо в момент его появления. Потому что сегодня именно такой момент.

Сегодня, 19 мая 2026, исследователи Qualys раскрыли CVE-2026-46333 в ядре Linux. Уязвимость позволяет непривилегированному пользователю читать файлы принадлежащие root — в том числе SSH-ключи (/etc/ssh/ssh_host_*_key) и файл /etc/shadow. PoC доступен публично как ssh-keysign-pwn и chage_pwn. Подтверждена работоспособность на Arch Linux, Debian, Ubuntu, CentOS и Raspberry Pi OS.

Механика: уязвимость в __ptrace_may_access(), которая пропускает dumpable-проверку когда task->mm == NULL. do_exit() запускает exit_mm() перед exit_files() — нет mm, но fd-ы ещё живые — и pidfd_getfd(2) успешно выполняется в этом окне когда uid вызывающего совпадает с целевым.

Это не LPE до root — это чтение приватных ключей. Для серверов с SSH-доступом — это критично.

# НЕМЕДЛЕННАЯ ДИАГНОСТИКА:
# Смотрим были ли у нас непривилегированные пользователи
# с доступом к системе за последние сутки
last | head -20
grep "Accepted" /var/log/auth.log | grep -v root | tail -20

# Если на сервере нет непривилегированных пользователей кроме root —
# риск значительно ниже (нет кому эксплуатировать)
awk -F: '$3 >= 1000 && $7 != "/sbin/nologin" && $7 != "/bin/false" \
    {print $1, $7}' /etc/passwd

# МИТИГЕЙШН пока патча нет:
# 1. Ужесточаем права на SSH host keys (уже должны быть 600):
ls -la /etc/ssh/ssh_host_*
chmod 600 /etc/ssh/ssh_host_*_key

# 2. Ограничиваем чтение shadow:
ls -la /etc/shadow  # должен быть 640 или 000
chmod 640 /etc/shadow

# 3. Если на сервере есть непривилегированные пользователи —
# временно блокируем ptrace для непривилегированных:
echo 1 | tee /proc/sys/kernel/yama/ptrace_scope
# или более жёстко:
echo 3 | tee /proc/sys/kernel/yama/ptrace_scope
# 3 = только root может ptrace (ломает некоторые отладчики)

# Делаем permanent через sysctl:
echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf

# СЛЕДИМ за патчем:
# upstream: kernel.org (ветки 7.0.x, 6.18.x, 6.12.x)
# Ubuntu: ubuntu.com/security/notices
# RHEL: access.redhat.com/security

Как работает правильная реакция на fresh disclosure:

Первые 30 минут: читаем advisory, понимаем prerequisites (local? network? authenticated?), проверяем есть ли у нас этот компонент в системе.

30 минут — 2 часа: ищем временный митигейшн (не патч — его ещё нет). Применяем если риск в нашей среде реален.

После: ждём патча дистрибутива, ставим как только появится, убираем митигейшн.

Это не паника — это процесс. Разница в том, что процесс можно делегировать и автоматизировать.

Итог: ptrace_scope = 1 — это одна команда которая снижает риск не только от CVE-2026-46333, но и от всего класса ptrace-атак. Это и есть defence-in-depth в действии.

#skills #linux #cve #security #реакция #sysadmin #admin_future

🐧 Linux: DirtyDecrypt — пятый вариант page-cache атаки за три недели, и сегодня вышел PoC

Коллеги, майский марафон Linux-уязвимостей продолжается. Сегодня утром на Hacker News — DirtyDecrypt (CVE-2026-31635). Это уже пятая уязвимость одного класса за три недели.

DirtyDecrypt обнаружили исследователи Zellic и V12, но при попытке зарепортить узнали — уязвимость уже была исправлена в mainline. Это rxgk page cache write из-за отсутствующего COW-guard в rxgk_decrypt_skb(). Оценивается как вариант Copy Fail, Dirty Frag и Fragnesia — все они дают root на уязвимых системах.

Хорошая новость: патч уже в mainline. Плохая: PoC публичен прямо сейчас.

Итоговая карта всех пяти за май 2026:

Copy Fail  (CVE-2026-31431)  — 29 апреля — AF_ALG, algif_aead
Dirty Frag (CVE-2026-43284)  — 7 мая    — ESP xfrm, esp4/esp6
Dirty Frag (CVE-2026-43500)  — 7 мая    — RxRPC rxrpc
Fragnesia  (CVE-2026-46300)  — 13 мая   — XFRM ESP-in-TCP
DirtyDecrypt(CVE-2026-31635) — 20 мая   — rxgk_decrypt_skb
CVE-2026-46333               — 19 мая   — ptrace exit-race (чтение ключей)

Все шесть закрываются одним митигейшном на системах без IPsec/RxRPC:

# ПОЛНЫЙ МИТИГЕЙШН — все шесть CVE мая 2026
# (если algif_aead, esp4/esp6, rxrpc не нужны):
printf "install algif_aead /bin/false\n\
install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n" | \
    tee /etc/modprobe.d/may2026-kernel-lpe.conf

rmmod algif_aead esp4 esp6 rxrpc 2>/dev/null || true

# Для CVE-2026-46333 (ptrace / SSH keys):
echo "kernel.yama.ptrace_scope = 1" >> \
    /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf

# Проверяем статус патчей на всём флоте:
# Нужны ядра: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207
uname -r

# ModuleJail — автоматизирует это для всех неиспользуемых модулей:
# github.com/jnuyens/modulejail
sudo sh modulejail -p conservative

Зачем это важно как тренд: DirtyDecrypt обнаружили независимо, а уязвимость уже исправили — это говорит о том, что AI-assisted code analysis находит одни и те же классы ошибок быстрее чем когда-либо. Темп раскрытий этого месяца — не случайность, это новая норма.

Итог: mitigation-файл + ptrace_scope = закрыты все шесть CVE мая. Патч ядра ставим при ближайшем обслуживании. И да — это ещё не конец месяца.

#linux #kernel #cve #dirtydecrypt #security #sysadmin #admin_future

🪟 Windows: AD CS в майском обновлении получил постквантовую криптографию — и это важнее чем звучит

Коллеги, в шуме вокруг Secure Boot, RC4 и Patch Tuesday почти никто не заметил кое-что важное в майском обновлении Windows Server 2025. Тихо и без фанфар.

Майское обновление добавляет в AD CS поддержку постквантовой криптографии: ML-DSA-44, ML-DSA-65 и ML-DSA-87 на Windows Server 2025. Это позволяет администраторам начать оценивать постквантовые криптографические алгоритмы и проверять PQC-готовность корпоративных PKI-сред.

Что это такое и зачем нам это сейчас:

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

Как попробовать уже сегодня:

# ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ:
# Windows Server 2025 с майским обновлением KB5087539
# AD CS Certification Authority установлен и настроен

# Проверяем версию после обновления:
Get-ItemProperty `
    "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" |
    Select-Object CurrentBuild, UBR
# Нужен build 26100.32860 или выше

# Открываем Certificate Authority MMC:
# certsrv.msc -> [CA Name] -> Properties -> Cryptography

# Через PowerShell — проверяем доступные PQC-алгоритмы:
# (Нужен Provider Category: Key Storage Provider)
certutil -csplist | Select-String "ML-DSA"

# Создаём тестовый PQC-сертификат (code signing сценарий):
# 1. В CA Properties -> Cryptography -> CSP: Microsoft Software Key Storage Provider
# 2. Signature algorithm: ML-DSA-65 (оптимальный баланс размер/безопасность)
# 3. Выпускаем тестовый cert только для code signing

# ПРЕДУПРЕЖДЕНИЕ о размерах:
# ML-DSA-65 цепочка сертификатов: ~10KB vs ~1.5KB у ECDSA
# Это влияет на TLS handshake latency
# Пока НЕ для TLS, VPN, RDP — только для code signing и оценки

# Проверяем выпущенные PQC-сертификаты:
certutil -CAInfo
certutil -view -out "SerialNumber,NotBefore,NotAfter,Subject,PublicKey"

Что сейчас работает и что нет: ранние тесты показывают многообещающие результаты для сценариев подписи, таких как code signing. Однако более широкие инфраструктурные нагрузки, включая TLS, VPN и Remote Desktop, пока ограничены.

Зачем начинать сейчас если TLS/VPN ещё не готовы: организации, начинающие миграцию в 2026 году, имеют достаточно времени для соответствия срокам устаревания 2030 года. Те кто ждут 2028-го — столкнутся со сжатой высокорисковой миграцией.

Итог: не деплоить в продакшн. Поднять тестовую CA, выпустить ML-DSA-65 сертификат, посмотреть на размеры и latency. Это час работы — и понимание что тебя ждёт через 2-3 года.

#windows #adcs #pki #postquantum #security #sysadmin #admin_future

🧠 Skills: Май 2026 — разбор полётов. Чему нас научил этот месяц

Коллеги, среда — хороший момент для рефлексии в середине недели. Май 2026 ещё не закончился, но уже войдёт в учебники по security operations. Разберём что реально можно взять из этого месяца.

Шесть CVE в Linux за три недели. Patch Tuesday со 120 CVE. RC4 enforcement в июле. Secure Boot до июня. Entra hard match 1 июня. DirtyDecrypt сегодня утром.

Три вещи которые работали и три которые нет:

ЧТО РАБОТАЛО:

1. МОНИТОРИНГ ПРАВИЛЬНЫХ ИСТОЧНИКОВ
   Команды которые быстро реагировали — подписаны на:
   - CISA KEV (daily digest)
   - Ubuntu/RHEL security advisories (RSS/email)
   - Hacker News /new (для zero-day до патча)
   Не на твиттер и не на агрегаторы с задержкой в день.

2. BLACKLIST КАК ВРЕМЕННЫЙ ЩИТ
   Кто заблокировал algif_aead/esp4/esp6/rxrpc в первый день —
   спокойно ставил патчи по расписанию.
   Кто ждал патча сразу — жил три недели под риском.

3. ЧЁТКИЙ ПРОЦЕСС ПРИОРИТИЗАЦИИ
   5 вопросов: есть ли в моей среде? активно эксплуатируется?
   вектор атаки? митигейшн? когда патч?
   Экономит 80% времени на панику.

ЧТО НЕ РАБОТАЛО:

1. "ПРОПАТЧИМ НА СЛЕДУЮЩЕЙ НЕДЕЛЕ"
   Copy Fail появился 29 апреля с публичным PoC.
   CISA KEV — 1 мая. Дедлайн — 15 мая.
   Кто ждал плановый цикл через две недели —
   работал без защиты неделю с известным рабочим эксплойтом.

2. РУЧНОЙ BLACKLIST БЕЗ АВТОМАТИЗАЦИИ
   Каждая новая CVE требовала нового захода на каждый сервер.
   ModuleJail — ответ на это. IaC-подход — правильный ответ.

3. РЕАКЦИЯ НА ЗАГОЛОВКИ БЕЗ ПРОВЕРКИ СРЕДЫ
   "Copy Fail затрагивает все дистрибутивы с 2017 года!"
   — да, но только при наличии загруженного algif_aead.
   На many продакшн-серверах его нет.
   Паника тратит ресурсы которые нужны на реальные угрозы.

Один практический вывод в виде действия прямо сейчас:

# Если после этого месяца у тебя нет этих трёх вещей — сделай сегодня:

# 1. ПОДПИСКА НА CISA KEV (RSS для мониторинга)
# https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
# Добавь в любой RSS-ридер или настрой скрипт

# 2. ПРОВЕРКА KERNEL MITIGATION СТАТУСА
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc" && \
    echo "РИСК: модули загружены" || \
    echo "OK: модули не загружены"

# 3. ANSIBLE PLAYBOOK ДЛЯ RAPID BLACKLIST DEPLOY
# Один playbook который за 2 минуты закрывает флот
# вместо ручного захода на каждый сервер:
# ---
# - name: Kernel module mitigations May 2026
#   hosts: all
#   become: true
#   tasks:
#     - name: Block vulnerable kernel modules
#       copy:
#         dest: /etc/modprobe.d/may2026-mitigations.conf
#         content: |
#           install algif_aead /bin/false
#           install esp4 /bin/false
#           install esp6 /bin/false
#           install rxrpc /bin/false

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

Итог: три недели CVE-шторма показали кто автоматизирован, кто нет. Кто мониторит правильное, кто реагирует на заголовки. Это не критика — это диагностика. Используй её.

#skills #security #процессы #автоматизация #sysadmin #admin_future

🐧 Linux: Май 2026 закрыт — финальный чеклист по ядру для тех кто ещё не всё сделал

Коллеги, четверг 21 мая — подводим итог самому насыщенному security-месяцу в Linux за несколько лет. Шесть уязвимостей, все патчи вышли, но статистика показывает: большая часть флотов ещё не обновлена.

Это четвёртая уязвимость ядра Linux требующая внимания администраторов за три недели, после Copy Fail (29 апреля), Dirty Frag (7 мая) и Fragnesia (13 мая). Если вы не хотите экстренно патчить и перезагружать несколько раз в месяц — это сигнал выстроить систему.

Финальный чеклист на сегодня:

# ШАГ 1: Проверяем версию ядра — все патчи закрыты начиная с:
# 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207 / 5.10.256
uname -r

# ШАГ 2: Если ядро не обновлено — ставим немедленно
# Ubuntu/Debian:
apt update && apt full-upgrade -y

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

# ШАГ 3: Mitigation-файл — закрывает все page-cache CVE даже без патча
cat /etc/modprobe.d/may2026-kernel-lpe.conf 2>/dev/null || \
printf "install algif_aead /bin/false\ninstall esp4 /bin/false\n\
install esp6 /bin/false\ninstall rxrpc /bin/false\n" | \
tee /etc/modprobe.d/may2026-kernel-lpe.conf

# ШАГ 4: ptrace_scope — закрывает CVE-2026-46333 (чтение SSH-ключей)
sysctl kernel.yama.ptrace_scope
# Если 0 — ставим минимум 1:
echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf

# ШАГ 5: ModuleJail — системное решение для флота
# После патча и перезагрузки — автоматически блокирует ВСЕ
# неиспользуемые модули, не только эти шесть:
# github.com/jnuyens/modulejail
sudo sh modulejail -p conservative

# ШАГ 6: Проверяем что drop_caches сброшен на хостах
# где могла быть эксплуатация (критично для Fragnesia):
echo 1 | tee /proc/sys/vm/drop_caches

Один архитектурный вывод из мая: AI-assisted code analysis нашёл несколько уязвимостей в одной и той же поверхности атаки за три недели. Вопрос для 2026 года — не будут ли продолжаться kernel-эксплойты, а будет ли ваша инфраструктура защищена когда они появятся.

Итог: патч + перезагрузка + mitigation-файл + ptrace_scope. Четыре пункта. Если не сделано — сделай прямо сейчас, это последний четверг мая.

#linux #kernel #security #patch #sysadmin #admin_future

🪟 Windows: Secure Boot — 10 дней до истечения, финальный чеклист для серверов

Коллеги, конец июня — не абстрактный дедлайн. Две из трёх затронутых сертификатов — Microsoft Corporation KEK CA 2011 и Microsoft UEFI CA 2011 — истекают в июне 2026. Microsoft Windows Production PCA 2011, подписывающий сам Windows Boot Manager, истекает в октябре 2026.

Что произойдёт если не успеть: системы без обновления потеряют возможность устанавливать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.

Критически важное для серверов: в отличие от Windows PC, которые получают сертификаты 2023 года автоматически через Controlled Feature Rollout, Windows Server требует ручного действия — автоматически они не прилетают.

# ФИНАЛЬНЫЙ АУДИТ — выполнить сегодня

# 1. Сколько серверов НЕ готово:
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
    Select-Object -ExpandProperty Name

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

$report | Group-Object Status | Format-Table Name, Count -AutoSize

# Экспортируем список на обработку:
$report | Where-Object {$_.Status -ne "Updated"} |
    Export-Csv "secureboot_critical_$(Get-Date -Format yyyyMMdd).csv" `
    -NoTypeInformation

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

# 3. Offline / air-gapped серверы — ручной путь:
# Скачать пакет с aka.ms/GetSecureBoot
# Применить через DISM или wusa.exe

# 4. Проверяем dbx (список отозванных bootloader-ов):
# Актуальный dbx критичен вместе с новыми сертификатами
Get-SecureBootUEFI -Name dbx | Select-Object -ExpandProperty Bytes | Measure-Object
# Пустой или нулевой dbx = риск

Устройства оффлайн, в спящем режиме, на полке — не получат обновления и рискуют оказаться изолированными после июня 2026. Старое железо без OEM firmware-обновлений также в опасности.

Итог: если у тебя есть серверы со статусом NOT_STARTED — это твоя задача на сегодня. Не на следующей неделе. Сегодня. До июня осталось меньше шести недель.

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

🧠 Skills: Crypto Agility — навык который нужен сисадмину прямо сейчас, а не в 2030-м

Коллеги, пятничный пост в четверг — потому что тема важная, а пятницу займёт что-нибудь свежее.

Май 2026 дал нам два отличных примера почему crypto agility — это не теоретическая концепция. Secure Boot 2011 → 2023: ротация корневых сертификатов требует ручного вмешательства на тысячах серверов. RC4 в Kerberos: 30 лет использовали, теперь принудительное отключение в июле. Оба случая — болезненная миграция из-за отсутствия гибкости.

Crypto agility — это способность менять криптографические алгоритмы и ключи без переписывания всей инфраструктуры. Это не про квантовые компьютеры. Это про то, что алгоритмы устаревают регулярно.

Три практических элемента которые нужны прямо сейчас:

ЭЛЕМЕНТ 1: КРИПТОГРАФИЧЕСКАЯ ИНВЕНТАРИЗАЦИЯ

Что нужно знать о каждом сервисе:
  - Какие алгоритмы используются (RSA? ECDSA? AES?)
  - Где хранятся ключи и сертификаты
  - Когда истекают сертификаты
  - Какие зависимости (приложения, протоколы)

Инструменты:
  # Linux: сканируем конфиги
  grep -r "SSLProtocol\|SSLCipherSuite\|ssl_protocols\|ssl_ciphers" \
      /etc/nginx/ /etc/apache2/ /etc/haproxy/ 2>/dev/null

  # Проверяем TLS на работающих сервисах:
  nmap --script ssl-enum-ciphers -p 443 <IP>

  # Сертификаты в системе:
  find /etc -name "*.crt" -o -name "*.pem" 2>/dev/null | \
      xargs -I{} openssl x509 -in {} -noout -subject -enddate 2>/dev/null

  # Windows: сертификаты в хранилищах
  Get-ChildItem Cert:\LocalMachine\My |
      Select-Object Subject, NotAfter, Thumbprint |
      Sort-Object NotAfter

ЭЛЕМЕНТ 2: МОНИТОРИНГ СРОКА ЖИЗНИ

Автоматический алерт за 90/30 дней до истечения любого сертификата.
Это то чего не было для Secure Boot 2011 — никто не получил алерт
в 2024 году что через два года сертификаты истекут.

  # Простой скрипт мониторинга сертификатов:
  find /etc -name "*.crt" -o -name "*.pem" 2>/dev/null | \
    while read cert; do
      exp=$(openssl x509 -in "$cert" -noout -enddate 2>/dev/null | \
            cut -d= -f2)
      if [ -n "$exp" ]; then
        exp_epoch=$(date -d "$exp" +%s 2>/dev/null)
        now_epoch=$(date +%s)
        days_left=$(( (exp_epoch - now_epoch) / 86400 ))
        if [ "$days_left" -lt 90 ]; then
          echo "WARN: $cert expires in $days_left days ($exp)"
        fi
      fi
    done

ЭЛЕМЕНТ 3: ЗАМЕНА БЕЗ ДАУНТАЙМА

Для каждого критичного сервиса должен быть ответ на вопрос:
"Если нам нужно сменить сертификат/алгоритм прямо сейчас —
сколько это займёт и что потребует перезапуска?"

Если ответ "несколько дней и полный downtime" — это проблема.
Если "15 минут и горячая перезагрузка конфига" — это crypto agility.

nginx -s reload          # Hot reload сертификата без downtime
systemctl reload apache2 # То же для Apache

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

Итог: инвентаризация + мониторинг + план замены. Это три часа работы которые меняют "паника в июне 2026" на "плановое обновление в марте 2026". Сделай это сейчас — следующий Secure Boot истечёт в 2033-м, и это уже твоя задача.

#skills #security #crypto #pkи #sysadmin #admin_future

🐧 Linux: Rust теперь в APT — и это важнее чем кажется

Коллеги, на этой неделе случилось кое-что, о чём мало кто написал — но что касается каждого администратора Debian/Ubuntu-флота напрямую.

Два события мая 2026 окончательно переместили Rust из категории «языка будущего» в load-bearing инфраструктуру. Первое: Linux 7.0 убрал пометку experimental с Rust — теперь это официальный язык ядра наравне с C. Второе: APT maintainer Julian Klode объявил что Debian's package manager начинает требовать жёсткую зависимость от Rust начиная с мая 2026.

Что это значит практически для администратора:

APT — это package manager для Debian и каждого производного дистрибутива: Ubuntu, Linux Mint, Pop!_OS, Kali Linux, Raspberry Pi OS. Rust-компилятор, стандартная библиотека и части Sequoia PGP теперь встроены в core APT — для парсинга .deb, .ar и .tar файлов, а также HTTP signature verification.

Зачем Rust именно здесь? APT обрабатывает недоверенные данные (пакеты из интернета) на уровне root. Memory corruption в парсере пакетов — это immediate root compromise. Rust устраняет целые классы уязвимостей вроде use-after-free, которые типичны для C-кода. Это интеграция снижает реальную поверхность атаки в местах где это наиболее критично.

# Проверяем Rust в APT на Ubuntu 26.04:
apt-cache show apt | grep -i rust
dpkg -l | grep -i "rust\|rustc"

# Для администраторов air-gapped сред:
# APT теперь требует rustc при сборке из исходников
# Проверяем что offline-репозиторий включает rust-пакеты:
apt-get install --dry-run apt 2>&1 | grep -i rust

# Для Debian 13 Forky (выход 2027):
# Rust будет требоваться для сборки ядра модулей через DKMS
# Уже сейчас можно подготовить offline-кэш:
apt-get download rustc cargo libstd-rust-dev

# Смотрим версию Rust в системе:
rustc --version 2>/dev/null || echo "Rust not installed"
# На Ubuntu 26.04 должно быть 1.80+ из репозитория

Для администраторов air-gapped и закрытых сред — это практическое действие сейчас: убедись что твои offline-репозитории содержат rust-пакеты. После обновления APT на системах без сети это может сломать apt upgrade если Rust недоступен.

Итог: Rust перешёл из «интересно, но не моя проблема» в «часть базовой инфраструктуры моего дистрибутива». Пятница — хороший момент проверить offline-репы.

#linux #rust #debian #ubuntu #apt #security #sysadmin #admin_future

🪟 Windows: Пятничный дайджест — что закрыть до выходных по майским дедлайнам

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

Три критических дедлайна ближайших недель — статус на сегодня:

Secure Boot — истечение в июне (осталось ~5 недель):
Системы без обновлённых сертификатов Secure Boot потеряют возможность получать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.

Entra hard match — дедлайн 1 июня (осталось 10 дней):
С 1 июня блокируется возможность синхронизировать cloud-privileged учётки через Entra Connect. Если не проверено — проверь прямо сейчас.

Kerberos RC4 — финал в июле (осталось ~6 недель):
После июля реестровый ключ RC4DefaultDisablementPhase игнорируется. Если не провёл аудит Event 201/202 — время поджимает.

# ПЯТНИЧНЫЙ ЧЕКЛИСТ — 3 команды, 5 минут:

# 1. Secure Boot статус (топ-10 серверов по риску):
Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
    Select-Object -First 10 Name |
    ForEach-Object {
        Invoke-Command -ComputerName $_.Name -ScriptBlock {
            $sb = Get-ItemProperty `
                "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
                -Name "UEFICA2023Status" -EA SilentlyContinue
            "$env:COMPUTERNAME : $(if($sb){$sb.UEFICA2023Status}else{'NOT_STARTED'})"
        } -EA SilentlyContinue
    }

# 2. RC4 — сколько событий за эту неделю (если много — срочно):
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -in @(201,202,203) -and
        $_.TimeCreated -gt (Get-Date).AddDays(-7)} |
    Group-Object Id | Select-Object Name, Count

# 3. Entra hard match — есть ли привилегированные sync'd учётки:
# (быстрая проверка без Graph модуля)
Get-ADUser -Filter {Enabled -eq $true} `
    -Properties MemberOf, adminCount |
    Where-Object {$_.adminCount -eq 1} |
    Select-Object SamAccountName, DistinguishedName |
    Export-Csv "friday_privcheck.csv" -NoTypeInformation
Write-Host "Привилегированных учёток: $((Import-Csv friday_privcheck.csv).Count)"
# Если > 20 — стоит пересмотреть список до понедельника

Что реально можно сделать за пятницу:

ЧТО МОЖНО ЗАКРЫТЬ ЗА 30 МИНУТ:
  - Запустить Secure Boot update task на 5-10 серверах
  - Посмотреть RC4 events за неделю
  - Сохранить список NOT_STARTED серверов для понедельника

ЧТО НЕ ТРОГАТЬ В ПЯТНИЦУ ВЕЧЕРОМ:
  - Не менять пароли krbtgt без подготовки
  - Не обновлять DC в конце недели без снапшота
  - Не применять Kerberos-политики без тестовой группы

Итог: пятница — для аудита и планирования, не для опасных изменений. Три команды выше покажут где ты стоишь. Остальное — в понедельник с холодной головой.

#windows #secureboot #kerberos #security #patchmanagement #sysadmin #admin_future

🧠 Skills: Май 2026 — итог месяца для тех кто дочитал до пятницы

Шесть уязвимостей ядра Linux. Patch Tuesday со 120 CVE. Kerberos RC4 enforcement. Secure Boot истечение. Entra hard match. Windows Server Summit. PostQuantum в AD CS. ModuleJail. DirtyDecrypt. Killswitch-proposal.

Это не был лёгкий месяц.

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

Три вещи которые отделяли тех кто справился от тех кто нет:

1. МОНИТОРИНГ ПРАВИЛЬНЫХ ИСТОЧНИКОВ
   Не твиттер, не агрегаторы.
   CISA KEV → RSS → алерт на email или в мессенджер
   Ubuntu/RHEL security advisory → email subscription
   Microsoft Security Update Guide → RSS
   Это 20 минут настройки однажды vs постоянный шум.

2. ПРОЦЕСС А НЕ ПАНИКА
   Пять вопросов для любого CVE:
   Есть ли в моей среде?
   Активно эксплуатируется?
   Вектор атаки?
   Есть ли митигейшн?
   Когда патч?
   Структура превращает "срочно всё горит" в управляемые действия.

3. АВТОМАТИЗАЦИЯ РУТИНЫ
   Кто запустил ModuleJail один раз — не правил blacklist 5 раз.
   Кто выстроил Ansible-пайплайн — не заходил вручную на 30 серверов.
   Кто настроил мониторинг Secure Boot — узнал о проблеме в феврале
   а не в июне.

Один честный вопрос для выходных:

Возьми любую из майских угроз. Спроси себя: "Сколько времени прошло между раскрытием и моим первым действием?" Один день — отлично. Три дня — приемлемо. Неделя — есть над чем работать. Больше — это не проблема знаний, это проблема процесса.

Июнь 2026 принесёт свои сюрпризы. Они будут другими. Но твоя способность реагировать — это мышца которую прокачал май. Либо прокачал, либо нет.

Вы прошли самый насыщенный месяц в истории канала. Если инфраструктура работает — вы сделали всё правильно. Этого достаточно.

#skills #итоги #май2026 #security #процессы #sysadmin #admin_future