🪟 Windows: Создатель диспетчера задач признался — CPU% всегда было «некрологом недавнего прошлого»

Коллеги, на этой неделе Дэйв Пламмер — инженер Microsoft, написавший оригинальный Task Manager — объяснил то, о чём многие из нас догадывались, но не формулировали чётко. Цифра загрузки CPU в диспетчере задач никогда не была «сейчас».

«Число CPU в диспетчере задач — это движущийся некролог недавнего прошлого», объяснил Пламмер. «Не то, что происходило в момент, когда ваши глаза остановились на строке».

Как это работало изнутри:

Windows не хранит никакого магического значения загрузки CPU, готового к считыванию. Вместо этого Task Manager работал по таймеру: при каждом срабатывании запрашивал у ядра накопленное процессорное время каждого процесса и сравнивал с предыдущим снимком.

Это решение умное и дешёвое — но у него есть фундаментальное ограничение на современном железе:

«Современная загрузка CPU больше похожа на то, насколько было заполнено шоссе, а не на то, сколько миль реально проехали. Полупустое шоссе с Ferrari может пропустить гораздо больше трафика, чем забитое шоссе со старыми грузовиками».

Процессоры с Turbo Boost, тепловым троттлингом и глубокими состояниями простоя разорвали связь между «занятым временем» и «реально выполненной работой». 73% в диспетчере может означать совершенно разный объём вычислений в зависимости от того, на какой частоте работал CPU в этот момент.

Что из этого следует практически — чем смотреть вместо Task Manager:

# Реальная утилизация CPU с учётом частоты (не просто время)
# Performance Monitor — метрика "Processor Information\% Processor Utility"
# Именно её Microsoft начала использовать по умолчанию с июля 2025

# Через PowerShell — утилизация с учётом частоты:
Get-Counter '\Processor Information(_Total)\% Processor Utility' |
    Select-Object -ExpandProperty CounterSamples |
    Select-Object CookedValue

# Сравниваем с классическим % (время):
Get-Counter '\Processor(_Total)\% Processor Time' |
    Select-Object -ExpandProperty CounterSamples |
    Select-Object CookedValue

# На нагруженном сервере разница между двумя метриками
# может достигать 30-40% — именно столько "врал" старый Task Manager

# Для глубокого анализа — PAL (Performance Analysis of Logs)
# или просто смотрим в Windows Admin Center -> Performance Monitor

Кстати, Microsoft уже исправила это: с июля 2025 года Task Manager использует стандартную метрику утилизации для отображения нагрузки CPU на всех вкладках — Processes, Performance и Users — приводя её в соответствие с отраслевыми стандартами и сторонними инструментами.

Зачем это знать:
Если вы делаете выводы о нагрузке на сервер по старому диспетчеру задач — вы смотрите на интерпретацию прошлого через упрощённую формулу. Для реального capacity planning используй Performance Monitor, метрику % Processor Utility и нормальный мониторинг с историей.

Пламмер точно сформулировал суть: «Инструмент мониторинга, который требует семинара по инженерии перед завтраком, уже проиграл». Task Manager и не должен был быть точным осциллографом. Он должен был быть быстрым и понятным — и он им был. Просто не путай его с инструментом точного анализа.

Итог: то, что ты видишь в Task Manager — это не ложь. Это упрощение. Разница принципиальная, и понимать её важно, особенно когда объясняешь бизнесу почему 40% в мониторинге это не то же самое, что 40% реальной нагрузки.

#windows #performance #troubleshooting #sysadmin #admin_future

🐧 Linux: Cilium без kube-proxy — eBPF как замена iptables в Kubernetes

Коллеги, если у вас Kubernetes и kube-proxy на iptables — вы работаете с инструментом 2001 года. Не метафорически, буквально.

Проблема простая: iptables не был спроектирован для динамических сред. При каждом изменении Service или Endpoint правила перезаписываются целиком — на кластере из 500+ сервисов это создаёт заметную задержку и нагрузку на CPU.

Cilium в режиме kube-proxy replacement решает это через eBPF: таблицы маршрутизации хранятся в BPF maps, обновляются атомарно и обрабатываются прямо в ядре без userspace-прыжков.

# Устанавливаем Cilium с отключённым kube-proxy (k3s / kubeadm)
# При инициализации кластера убираем kube-proxy:
kubeadm init --skip-phases=addon/kube-proxy

# Устанавливаем Cilium через Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443 \
  --set bpf.masquerade=true

# Проверяем что kube-proxy replacement активен
cilium status --verbose | grep -i "kube-proxy"
# KubeProxyReplacement: True

# Смотрим BPF-таблицы сервисов напрямую
cilium service list
cilium bpf lb list

# Мониторинг сетевых событий в реальном времени
cilium monitor --type drop

Зачем это нужно:
Cilium с eBPF даёт встроенную наблюдаемость L3/L4/L7 без sidecar-контейнеров, встроенный network policy без overhead iptables, и Hubble — визуализацию трафика между подами в реальном времени. Для кластеров от 50 нод разница в latency ощутима.

Итог: iptables в Kubernetes — это как держать Zabbix 2.0 вместо Prometheus. Работает, но не для 2026 года.

#linux #kubernetes #ebpf #cilium #networking #sysadmin #admin_future

🪟 Windows: hotpatch в мае — что изменилось и одна важная ловушка

Коллеги, с 11 мая hotpatch включается по умолчанию для всех eligible Windows 11 24H2 устройств через Intune. Разбираем быстро что важно знать прямо сейчас.

Hotpatch патчит код запущенных процессов прямо в памяти, не заменяя файлы на диске. Поэтому перезагрузка не нужна — изменения вступают в силу немедленно для уже запущенных процессов.

Схема простая: 4 раза в год (январь, апрель, июль, октябрябрь) — полный baseline с перезагрузкой. Остальные 8 месяцев — hotpatch без рестарта.

Но апрельский цикл преподнёс сюрприз: установка KB5091157 (OOB-фикс для апрельского Patch Tuesday) требует перезагрузки и приостанавливает hotpatching. Hotpatch-обновления возобновятся только после июльского baseline. То есть если поставили фикс — ближайшие два месяца работаете в обычном режиме.

# Проверяем статус hotpatch на устройстве
Get-WmiObject -Namespace "root\cimv2" `
  -Class Win32_QuickFixEngineering |
  Sort-Object InstalledOn -Descending |
  Select-Object HotFixID, InstalledOn -First 5

# Смотрим включён ли hotpatch через реестр
Get-ItemProperty `
  -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Update\TargetingInfo\Installed\*" `
  -ErrorAction SilentlyContinue |
  Where-Object { $_.Name -like "*Hotpatch*" }

# В Intune — статус через Graph API
# Intune Portal → Devices → Windows updates →
# Quality updates → Hotpatch quality update report

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

Зачем это нужно:
После установки OOB KB5091157 с перезагрузкой hotpatching приостанавливается до июльского baseline. Это задокументированное поведение — планируй обслуживание соответственно.

Итог: hotpatch — хорошая технология. Но "включилось само" без понимания цикла — это потеря контроля над maintenance windows. Проверь VBS и пойми свой текущий статус до 11 мая.

#windows #hotpatch #intune #patching #sysadmin #admin_future

🧠 Skills: CMDB — кладбище данных или реальный инструмент. Зависит от одного решения

Коллеги, у большинства из нас есть CMDB. У меньшинства она актуальна. Это не проблема инструмента — это проблема подхода.

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

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

Единственный подход который работает в 2026 — автообнаружение + IaC как источник истины:

РАБОЧАЯ СХЕМА ДЛЯ CMDB:

Источники данных (автоматически, не вручную):
  ├── Terraform/Ansible state → что задеплоено и как
  ├── Netbox/NetAct → сетевые устройства и IP
  ├── Zabbix/Prometheus → что живёт и что мониторится
  └── AD/Entra → пользователи и машины

Принцип: если изменение не прошло через IaC —
оно не существует с точки зрения CMDB.

Что хранить в CMDB (только это, ничего лишнего):
  [CI]        Сервер / VM / контейнер
  [Атрибуты]  ОС, IP, owner, окружение (prod/stage/dev)
  [Связи]     Что от чего зависит (БД → приложение → балансер)
  [Статус]    Active / Decommissioned / Maintenance

Что НЕ хранить:
  ✗ Версии ПО (это в Ansible inventory)
  ✗ Пароли и ключи (это в Vault)
  ✗ История изменений (это в Git)

Ключевой вопрос перед добавлением любого атрибута в CMDB: кто будет поддерживать это актуальным и как? Если ответа нет — атрибут не нужен.

Зачем это нужно:
CMDB с актуальными зависимостями отвечает на вопрос "что упадёт если я выключу этот сервер?" за секунды, а не за час расследования. Это разница между проактивным и реактивным администрированием.

Итог: хорошая CMDB — это не большая, а актуальная. Лучше 50 записей которым все верят, чем 5000 которые никто не читает.

#skills #cmdb #itsm #infrastructure #sysadmin #admin_future

🐧 Linux: CVE-2026-31429 — дыра в сетевом стеке ядра, патчить не откладывая

Коллеги, на прошлой неделе тихо появилась CVE-2026-31429 — уязвимость в подсистеме управления памятью сетевого стека Linux. Разбираем быстро.

Баг находится в функции skb_kfree_head() — логике освобождения памяти socket buffer. Когда включён KFENCE (Kernel Electric-Fence, дебаг-детектор памяти), функция kfence_ksize() возвращает точный запрошенный размер вместо размера slab-бакета. Это приводит к освобождению объекта в неправильный slab-кэш — classic cross-cache free.

Уязвимость находится в «горячем, активно используемом сетевом пути» — через него проходит каждый сетевой пакет. Это делает её особенно опасной несмотря на узкий технический контекст. Возможные последствия: повреждение памяти ядра, privilege escalation или kernel panic.

# Проверяем включён ли KFENCE на сервере
cat /proc/cmdline | grep -o "kfence.sample_interval=[0-9]*"
# Если вывод пустой или значение > 0 — KFENCE активен

# Проверяем версию ядра — патч уже в stable tree
uname -r

# Ubuntu: ставим обновление ядра
sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r)
sudo reboot

# RHEL/Rocky: 
sudo dnf update kernel -y && sudo reboot

# Временный митигейшн пока патч не встал:
# Отключаем KFENCE через параметр загрузки
# В /etc/default/grub добавляем в GRUB_CMDLINE_LINUX:
# kfence.sample_interval=0
sudo update-grub  # или grub2-mkconfig -o /boot/grub2/grub.cfg

# Дополнительно: ограничиваем доступ к BPF для непривилегированных
sysctl -w kernel.unprivileged_bpf_disabled=1
echo "kernel.unprivileged_bpf_disabled=1" >> /etc/sysctl.d/99-hardening.conf

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

Итог: KFENCE по умолчанию отключён в большинстве продакшн-дистрибутивов — проверь, прежде чем паниковать. Но патч ядра в любом случае ставим при ближайшем обслуживании.

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

🪟 Windows: Entra Passkeys на Windows — пароли официально умирают с этой недели

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

Microsoft Entra passkeys на Windows достигли General Availability с конца апреля 2026. Функция позволяет создавать device-bound passkeys в контейнере Windows Hello и аутентифицироваться через лицо, отпечаток или PIN. Важно: расширяет passwordless-аутентификацию на устройства, которые не присоединены к Entra ID — включая личные и общие Windows-устройства.

Ключевое изменение по сравнению с preview: больше не требуется явно разрешать Windows Hello AAGUID через allow-list в passkey-профиле. Если ваш профиль допускает device-bound, non-attested passkeys — пользователи начнут регистрировать passkeys на Windows автоматически, без дополнительной настройки администратором.

# Проверяем текущее состояние FIDO2/passkey политики в Entra
# Нужна роль Authentication Policy Administrator

# Через Graph API (требует модуль Microsoft.Graph):
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId "fido2" |
  Select-Object -ExpandProperty AdditionalProperties

# Что проверить в Entra Admin Center:
# Identity → Security → Authentication methods → Policies → Passkey (FIDO2)
# Смотрим: включён ли, какие группы в scope, есть ли Key Restrictions

# Если хотим ЗАБЛОКИРОВАТЬ Windows Hello passkeys (только для конкретных сред):
# Добавляем Windows Hello AAGUID в block list профиля
# Windows Hello AAGUIDs:
# 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 (Windows Hello hardware)
# 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 (Windows Hello software)

# Проверяем зарегистрированные passkeys пользователя:
Get-MgUserAuthenticationFido2Method -UserId "user@domain.com" |
  Select-Object DisplayName, CreatedDateTime, AaGuid

Зачем это нужно:
Passkeys криптографически привязаны к устройству и никогда не передаются по сети — атакующий не может их украсть при фишинге или через вредоносное ПО для обхода MFA. Функция закрывает брешь в безопасности, которая оставляла личные и общие устройства с паролями после недавней волны атак на Entra SSO.

Итог: действие сегодня — зайди в Entra и убедись что знаешь, что будет происходить с passkeys в твоём тенанте. «Включилось само» — не оправдание на следующем аудите.

#windows #entra #passkeys #fido2 #security #sysadmin #admin_future

🧠 Skills: Capacity Planning — или как перестать тушить пожары и начать их предотвращать

Коллеги, честный вопрос: у вас есть прогноз нагрузки на инфраструктуру на следующий квартал? Не ощущение, а цифры? Если нет — вы занимаетесь реактивным администрированием. И рано или поздно вас накроет.

Capacity Planning — это дисциплина, которая превращает IT из реактивного «пожарного» в проактивного архитектора роста бизнеса. Её цель — оптимизировать производительность при непрерывной и пиковой нагрузке, понимая изменения в использовании: сезонные всплески, релизы продуктов, рост команды.

Минимальный рабочий фреймворк:

ШАГ 1 — СОБИРАЕМ БАЗОВЫЕ МЕТРИКИ (это уже должно быть)
  Prometheus / Zabbix / любой мониторинг:
  - CPU utilization (средний и p95 за 3 месяца)
  - RAM: available vs total, swap usage
  - Disk: usage growth rate (ГБ/неделя)
  - Network: throughput и packet loss тренды

ШАГ 2 — СЧИТАЕМ FORECAST (predict_linear в Prometheus)
  # Когда кончится диск при текущем темпе роста?
  predict_linear(
    node_filesystem_avail_bytes[30d], 90*24*3600
  ) < 0
  # Если True — через 90 дней диск будет забит

  # Когда CPU упрётся в потолок?
  predict_linear(
    rate(node_cpu_seconds_total{mode!="idle"}[30d]), 
    90*24*3600
  ) > 0.85

ШАГ 3 — МАТРИЦА РЕШЕНИЙ
  Текущий p95 < 60%  → мониторить ежемесячно
  Текущий p95 60-80% → планировать расширение в квартале
  Текущий p95 > 80%  → действовать сейчас, не ждать

ШАГ 4 — РАЗГОВОР С БИЗНЕСОМ
  "Сейчас диск растёт на 50 ГБ/неделю.
   Через 3 месяца заканчивается. 
   Расширение стоит X рублей.
   Инцидент обойдётся в Y рублей.
   Решаем сейчас?"

Распространённая ошибка: планирование в изоляции. IT-команды, которые прогнозируют спрос без информации от бизнеса, обречены на провал. Capacity plan должен опираться на бизнес-цели, а не только на исторические IT-данные.

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

Итог: capacity planning — это не документ раз в год. Это ежемесячные 30 минут с дашбордом и одним вопросом: "когда что-то упрётся в потолок?". Ответ на него должен быть у тебя всегда.

#skills #capacityplanning #мониторинг #инфраструктура #sysadmin #admin_future

🐧 Linux: systemd hardening — твои сервисы запущены в привилегиях которые им не нужны

Коллеги, большинство unit-файлов в продакшне выглядят так: Type=simple, ExecStart=..., Restart=on-failure — и всё. Сервис запускается с правами процесса, может писать куда угодно, видит всю файловую систему и весь сетевой стек. Это нормально для 2010 года.

В systemd 260 (Ubuntu 26.04, Fedora 44) появились дополнительные директивы изоляции и Memory THP-контроль на уровне юнита. Но главное — большинство директив безопасности были доступны давно, просто их не используют.

# Оцениваем текущий security score сервиса
systemd-analyze security nginx
# Покажет оценку от 0 (UNSAFE) до 10 (SAFE) и что именно проседает

# Добавляем hardening в override без правки оригинального юнита:
systemctl edit nginx

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
# Приватная /tmp — сервис не видит /tmp хоста
PrivateTmp=true

# Запрет на запись в домашние директории
ProtectHome=true

# /usr, /boot, /etc монтируются read-only
ProtectSystem=strict

# Разрешаем писать только в нужные директории
ReadWritePaths=/var/log/nginx /var/cache/nginx /run/nginx

# Убираем все capabilities кроме нужных
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# Запрет на новые привилегии через setuid/setgid
NoNewPrivileges=true

# Только нужные syscall-группы
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

# Изолируем сетевые namespace-ы (если сервис только слушает)
# PrivateNetwork=true  # раскомментировать для полной изоляции

# Контроль памяти (новое в systemd 260)
# Отключаем THP для сервисов где он мешает (Java, Redis)
MemoryTHP=never

# После правки:
systemctl daemon-reload && systemctl restart nginx

# Проверяем новый score
systemd-analyze security nginx
# Цель: зелёный (8+)

Зачем это нужно:
Скомпрометированный nginx с PrivateTmp и ProtectSystem=strict не доберётся до ваших SSH-ключей, конфигов баз данных или других сервисов. Изоляция на уровне юнита — это дешёвый слой defence-in-depth, который не требует контейнеров.

Итог: запусти systemd-analyze security на своих сервисах сегодня. Гарантирую — будет неприятно, но полезно.

#linux #systemd #hardening #security #sysadmin #admin_future

🪟 Windows: Native NVMe в WS2025 — +80% IOPS, и это ещё не включено по умолчанию

Коллеги, фича которая доступна с октября 2025-го, но большинство администраторов её не включили — потому что она opt-in и спрятана за реестром.

Всё Windows Server до 2025 включительно общался с NVMe-дисками через SCSI-эмуляцию. Команды NVMe переводились в SCSI и обратно — лишний слой абстракции, shared locks в kernel I/O path, лишние CPU-циклы. Включение native NVMe даёт до 80% выше IOPS и до 45% ниже CPU utilization под высокой I/O нагрузкой.

Это особенно важно для Storage Spaces Direct, SQL Server и любых disk-intensive workloads.

# Проверяем установлено ли обновление KB5066835 (октябрь 2025) или новее
Get-HotFix | Where-Object {$_.InstalledOn -gt "2025-10-01"} |
  Select-Object HotFixID, InstalledOn |
  Sort-Object InstalledOn -Descending | Select-Object -First 5

# Включаем Native NVMe через реестр (требует перезагрузки):
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" `
  /v 1176759950 /t REG_DWORD /d 1 /f

# Проверяем что драйвер переключился
# После перезагрузки в Device Manager NVMe диски должны показывать
# "NVM Express Controller" вместо "Standard SATA AHCI Controller"
Get-PnpDevice | Where-Object {$_.Class -eq "DiskDrive"} |
  Select-Object FriendlyName, Status

# Бенчмарк до и после — замеряем IOPS с DiskSpd:
# (скачать с https://github.com/microsoft/diskspd)
.\diskspd.exe -b4K -d30 -o32 -t8 -r -w0 -L C:\testfile.dat

# Для S2D кластеров — проверяем здоровье после включения
Get-StoragePool | Get-VirtualDisk | Select-Object FriendlyName, HealthStatus, IOPS

Зачем это нужно:
Windows Server 2025 больше не трактует все устройства хранения как SCSI. Native NVMe обеспечивает прямой многоочередной доступ к устройствам — это означает возможность достичь реальных пределов производительности железа.

Итог: если у тебя WS2025 с NVMe-дисками и это не включено — ты буквально оставляешь 80% производительности хранилища на столе. Одна команда в реестре и перезагрузка. Сделай это сегодня.

#windows #nvme #storage #performance #windowsserver2025 #sysadmin #admin_future

🧠 Skills: IaC drift — молчаливый убийца стабильности и как его ловить автоматически

Коллеги, у вас есть Ansible или Terraform. Вы гордитесь тем что инфраструктура описана как код. Но когда последний раз вы проверяли — соответствует ли то что работает в продакшне тому что написано в репозитории?

Configuration drift — это когда кто-то "быстро поправил руками" в пятницу вечером, написал "потом зафиксирую в коде" и конечно не зафиксировал. Через месяц инфраструктура живёт своей жизнью, а код — своей.

Два подхода в зависимости от инструмента:

# ---- ANSIBLE: детекция дрейфа через --check --diff ----
# Запускаем playbook в режиме проверки без изменений
ansible-playbook site.yml \
  -i inventories/production/hosts.yml \
  --check \
  --diff

# Вывод покажет ВСЕ расхождения между кодом и реальностью
# Строки с "-" = что есть сейчас, "+" = что должно быть по коду

# Автоматизируем: добавляем в cron или CI/CD pipeline
# crontab -e:
# 0 9 * * 1 ansible-playbook /opt/ansible/site.yml -i production --check --diff \
#   2>&1 | mail -s "Weekly drift report" admin@company.com

# ---- TERRAFORM: детекция дрейфа через plan ----
# Показывает расхождения между state и реальным состоянием ресурсов
terraform plan -detailed-exitcode
# Exit code: 0 = нет изменений, 1 = ошибка, 2 = есть изменения (drift!)

# В CI/CD (GitLab CI пример):
# drift_check:
#   schedule: "0 8 * * *"  # каждый день в 8:00
#   script:
#     - terraform init
#     - terraform plan -detailed-exitcode
#   allow_failure: false

# ---- ПРАВИЛО: что делать при обнаруженном дрейфе ----
# Вариант 1: исправить реальность под код (правильно)
#   ansible-playbook site.yml -i production  # применяем playbook
#   terraform apply                           # применяем план

# Вариант 2: зафиксировать реальность в код (если изменение было намеренным)
#   Обновить playbook/tf-файл, commit, PR, code review
#   terraform import resource_type.name resource_id  # импортируем в state

Зачем это нужно:
Drift detection для Ansible превращает идемпотентность в реальный механизм контроля: если ничего не меняется при запуске — системы соответствуют коду. Terraform использует state file для сравнения желаемого и реального состояния — это его главное преимущество перед Ansible в вопросе дрейфа.

Итог: IaC без регулярной проверки дрейфа — это как бэкап без тестирования восстановления. Выглядит серьёзно, но не работает в нужный момент. Настрой еженедельный отчёт сегодня — это 20 минут работы.

#skills #iac #ansible #terraform #drift #sysadmin #admin_future

🐧 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