现已上线！2025 年 Telegram 研究 — 年度关键洞察 
Admin Future
前往频道在 Telegram
Превращаем эникейщиков в System Architects. 🚀 Твой навигатор в мире IT-инфраструктуры: ▪️ Hard Skills: Linux, Windows, Network, Security ▪️ Tools: Лучший софт и скрытые фишки ▪️ Mindset: Как думать, чтобы платили много Админ - @maksimshap
显示更多242
订阅者
-2224 小时
-387 天
-3630 天
帖子存档
242
🐧 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
242
🧠 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
242
🪟 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 не работает)
242
🐧 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
242
🪟 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
242
🧠 Skills: Переводи downtime в деньги — или тебя не будут слушать
Коллеги, есть навык, который отличает инженера от архитектора инфраструктуры. Не знание конкретной технологии. Умение объяснить цену отказа на языке бизнеса.
Когда ты говоришь "нам нужна избыточность" — тебя слышат как расходы. Когда ты говоришь "один час простоя стоит нам X рублей" — тебя слышат как управление рисками. Разница принципиальная.
Даже один час даунтайма обходится средней компании в 300 000+. Для крупных предприятий цифры уходят в миллионы. Переведи это на свой контекст — и у тебя появится аргумент.
Простая формула для любого разговора с руководством:
ФОРМУЛА СТОИМОСТИ ДАУНТАЙМА: Стоимость = Минуты простоя × Стоимость минуты Стоимость минуты включает: + Потерянная выручка (продажи/транзакции в час ÷ 60) + Простой сотрудников (кол-во × зарплата в час ÷ 60) + Стоимость восстановления (инженер-часы × ставка) + Штрафы по SLA (если есть) + Репутационные потери (сложнее считать, но упоминать) ПРИМЕР: Интернет-магазин: 500 000 руб/час выручки 50 сотрудников простаивают: 50 × 2000 руб/час = 100 000 руб/час Инженер на восстановление: 5000 руб/час × 3 часа = 15 000 руб Итого 3 часа даунтайма: (500 000 + 100 000) × 3 + 15 000 = 1 815 000 руб HA-решение стоит 300 000 руб/год. ROI очевиден.Переход от 99.0% к 99.9% uptime может означать сотни тысяч сэкономленных рублей в год — часто больше, чем стоит само улучшение инфраструктуры. Зачем это нужно: Когда ты приходишь с таблицей, а не с ощущением — разговор меняется. Руководитель видит не "инженер хочет новое железо", а "инженер управляет рисками компании". Итог: посчитай стоимость одного часа простоя своего самого критичного сервиса. Запиши число. Именно с него начинается любой разговор о надёжности. #skills #downtime #sla #карьера #sysadmin #admin_future
242
🐧 Linux: nullfs в ядре 7.0 — зачем нужна «чёрная дыра» в файловой системе
Коллеги, одна из тихих, но важных вещей в ядре 7.0 — новый псевдофайловый тип nullfs. Звучит странно. Разберёмся зачем.
nullfs решает давнюю проблему initramfs: раньше pivot_root() не работал на реальной корневой ФС, потому что её нельзя было размонтировать. Userspace вынужден был делать хрупкий switch_root — рекурсивное удаление initramfs вручную перед продолжением загрузки.
Теперь схема чистая: nullfs — это минималистичная иммутабельная псевдо-ФС, она становится истинным корнем иерархии монтирования. Поверх неё монтируется mutable rootfs (tmpfs). Это позволяет сделать chdir + pivot_root + umount атомарно, без воркараундов.
Бонус для безопасности: каждый kernel thread получит nullfs как свою корневую ФС — это изолирует потоки ядра от файловой системы init-процесса. Сейчас все kernel threads разделяют файловое состояние init, что создаёт риск.
Что это значит на практике:
# nullfs включён по умолчанию в ядре 7.0
# Проверяем что он есть в системе:
cat /proc/filesystems | grep null
# Быстрее загружается initramfs — меньше задержек при старте
# Полезно замерить разницу до и после апгрейда на Ubuntu 26.04:
systemd-analyze
systemd-analyze blame | head -20
# Смотрим дерево монтирования — nullfs будет в корне:
findmnt --tree | head -5
242
🧠 Skills: Домашняя лаборатория — лучшая инвестиция в карьеру сисадмина
Коллеги, разговор о том, что разделяет администраторов, которые растут, от тех, кто стоит на месте. Ответ чаще всего один — наличие личной лаборатории.
Домашняя лаборатория — безопасное место для провалов, экспериментов и роста без страха положить продакшн. Облако не заменило homelab. Лаборатория стала ещё актуальнее — это место, где можно практиковать Git, IaC, CI/CD и контейнеры бесплатно, не получив счёт на 100 тысяч долларов из облака.
Минимальный стартовый стек в 2026 году:
ЖЕЛЕЗО (один сервер — уже лаборатория): Б/у десктоп / NUC: 32GB RAM, SSD 512GB Или: старый игровой ноут с 16GB RAM Гипервизор: Proxmox VE (бесплатно) СЕРВИСЫ ДЛЯ ПРАКТИКИ: - Proxmox + несколько VM: Linux + Windows Server - Self-hosted Git (Gitea) — всё в Git с первого дня - Ansible — автоматизируем конфиги вместо ручного тыка - Prometheus + Grafana — мониторинг как в продакшне - WireGuard — VPN для удалённого доступа к лабе ЧТО ПРАКТИКОВАТЬ: Неделя 1-2: поднять Proxmox, создать несколько VM Неделя 3-4: настроить сеть, VLAN, DNS Месяц 2: Ansible playbook для автодеплоя Ubuntu/WinServer Месяц 3: Kubernetes (k3s) + мониторинг Месяц 4+: Сломай и восстанови. Повтори.Онлайн-лабы имеют много страховочных сеток и мягких стен. Лучше всего учишься, когда реально что-то ломаешь и сам чинишь. В курсах редко кто запоминает детали — большинство усваивает общие концепции. Настоящее понимание приходит через самостоятельный разбор проблем. Зачем это нужно: Переход от рутины к стратегическому планированию инфраструктуры — вот реальный карьерный рост администратора. Специалист, который умеет строить воспроизводимую, автоматизированную инфраструктуру — это уже другой грейд и другая зарплата. Итог: лаборатория — это не хобби. Это твой личный учебный полигон, где можно освоить то, что в продакшне трогать страшно. Начни с одного старого ПК и Proxmox. Дальше само затянет. #skills #homelab #карьера #proxmox #sysadmin #admin_future
242
🪟 Windows: Апрельский Patch Tuesday сломал DC — и Microsoft уже выпустила OOB-фикс
Коллеги, если вы ещё не слышали — апрельское обновление KB5082063 наломало дров. Контроллеры домена в средах с Privileged Access Management (PAM) уходили в бесконечный цикл перезагрузок из-за краша LSASS. Затронуты все версии Windows Server от 2016 до 2025.
Хорошая новость: 19 апреля Microsoft выпустила внеплановые OOB-обновления. Для Windows Server 2025 — KB5091157 (стандартный) или KB5091470 (для hotpatch-сред, без перезагрузки).
# Проверяем установлен ли проблемный патч
Get-HotFix | Where-Object {$_.HotFixID -eq "KB5082063"}
# Проверяем статус LSASS и не крутится ли DC в петле
Get-Service lsass | Select-Object Status
Get-EventLog -LogName System -Newest 20 |
Where-Object {$_.Source -like "*LSASS*" -or $_.Source -like "*SAM*"}
# Устанавливаем OOB-фикс вручную (скачать с Microsoft Update Catalog)
# Для WS2025: KB5091157
# Для WS2022: KB5091575
# Для WS2019: KB5091574
# Если DC уже в петле — загружаемся в DSRM и откатываем:
# В меню Advanced Boot Options -> Directory Services Restore Mode
# Затем из cmd:
dism /image:C:\ /get-packages | findstr /i "KB5082063"
# dism /image:C:\ /remove-package /packagename:[имя_пакета]
242
🐧 Linux: Ubuntu 26.04 LTS вышла сегодня — что важно для сервера
Коллеги, 23 апреля 2026 — день релиза Ubuntu 26.04 LTS «Resolute Raccoon». Поддержка 5 лет бесплатно (до 2031), с Ubuntu Pro — 10 лет. Это первый LTS после 24.04.
Три вещи, важных конкретно для серверной эксплуатации:
Первое — sudo-rs теперь дефолтный sudo-провайдер. Оригинальный sudo переименован в sudo.ws. Пакет sudo-ldap удалён: LDAP-аутентификация теперь только через PAM. Если у вас sudo через LDAP — проверьте конфигурацию до апгрейда.
Второе — systemd в этом релизе убирает поддержку cgroup v1 полностью. Только унифицированная иерархия cgroup v2. Если какие-то контейнеры или легаси-сервисы у вас были привязаны к v1 — они не запустятся.
Третье — ядро Linux 7.0 из коробки. Это XFS self-healing, стабильный Rust, улучшенная производительность памяти (время аллокации больших блоков упало с 3.6 до 0.43 секунды), создание контейнеров стало на 40% быстрее.
# Проверяем готовность к апгрейду с 24.04
# Смотрим есть ли sudo через LDAP
grep -r "ldap" /etc/sudo* /etc/nsswitch.conf 2>/dev/null
# Проверяем cgroup версию
stat -fc %T /sys/fs/cgroup/
# tmpfs = v1 (проблема), cgroup2fs = v2 (порядок)
# Официальный апгрейд (когда будет открыт путь 24.04→26.04):
sudo do-release-upgrade
242
Итог: ИИ — это очень хороший стажёр с фотографической памятью и нулевым чувством ответственности. Он делает то что просишь, не думает о последствиях и иногда уверенно врёт. Твоя задача — быть опытным тимлидом этого стажёра, а не слепо доверять его выводам.
#skills #AI #автоматизация #sysadmin #карьера #powershell #admin_future
242
🧠 Skills: Как правильно использовать ИИ в работе администратора — без иллюзий и без паники
Коллеги, разговор, которого многие избегают, потому что тема кажется либо хайпом, либо угрозой. Ни то ни другое. Это просто новый инструмент — и как любой инструмент, он работает хорошо там, где его применение осмысленно, и создаёт проблемы там, где его применяют вслепую.
Первый честный тезис: ИИ не заменит системного администратора в 2026 году. Он заменит конкретные задачи — и освободит время для задач более высокого уровня. Это не успокоение, это факт: понимание инфраструктуры, принятие решений под давлением, архитектурное мышление — это по-прежнему человеческая работа.
Где ИИ реально помогает прямо сейчас — три конкретных паттерна:
ПАТТЕРН 1: ГЕНЕРАЦИЯ И ОТЛАДКА СКРИПТОВ Плохой запрос: "Напиши мне PowerShell-скрипт для AD" Хороший запрос: "Я Senior Systems Administrator. Среда: Windows Server 2025, PowerShell 7.4, домен corp.local, модуль ActiveDirectory установлен. Напиши скрипт который находит все неактивные компьютерные аккаунты (не логинились больше 90 дней), экспортирует в CSV с полями: Name, LastLogonDate, OU, Enabled. Добавь обработку ошибок и -WhatIf параметр для безопасного тест-запуска." Разница: второй запрос даёт рабочий результат с первого раза. Контекст среды — это ключ. Без него ИИ галлюцинирует cmdlets. ПАТТЕРН 2: ТРАБЛШУТИНГ КАК ДИАЛОГ Ситуация: непонятная ошибка в логах, нет времени читать man. Метод: вставить полный текст ошибки + контекст системы и спросить "объясни что происходит и дай 3 гипотезы" Пример: "На RHEL 9 в journalctl вижу: kernel: EXT4-fs error (device sdb1): ext4_find_entry:1455 Система: PostgreSQL 15, база на /dev/sdb1 ext4, kernel 6.18. Что это может быть и что проверить в первую очередь?" Результат: структурированные гипотезы, команды для диагностики. Ты всё равно принимаешь решение — ИИ даёт карту возможностей. ПАТТЕРН 3: ДОКУМЕНТАЦИЯ КАК ПОБОЧНЫЙ ПРОДУКТ После решения инцидента: скармливаешь ИИ - timeline событий из логов - команды которые выполнял - итог Просишь: "Напиши postmortem по этому инциденту в формате: Timeline / Root Cause / Impact / Actions Taken / Prevention" За 2 минуты получаешь структурированный документ. Который раньше не писал вообще, потому что "некогда".Где ИИ НЕ стоит использовать без проверки:
КРАСНЫЕ ФЛАГИ:
[!] Любые деструктивные операции без -WhatIf / --dry-run
Всегда тестируй сгенерированный скрипт в тестовой среде
[!] Конфигурации безопасности (firewall rules, SELinux policies)
ИИ не знает твою топологию — он угадывает
[!] Чувствительные данные в промпте
Не вставляй пароли, ключи, имена пользователей в публичные ИИ
[!] "ИИ сказал что так правильно" как аргумент
ИИ уверенно ошибается. Всегда проверяй по официальной документации
Практический подход — три правила зрелого использования ИИ:
Первое — контекст решает всё. Чем точнее описана среда (ОС, версия, конкретная задача, ограничения), тем выше качество ответа. Потрать 30 секунд на формулировку — сэкономишь 30 минут на исправление.
Второе — ИИ как черновик, не как финал. Каждый сгенерированный скрипт читай как код коллеги на code review: понимаешь ли что делает каждая строка? Нет — разбирай дальше или переписывай.
Третье — документируй промпты которые работают. Если нашёл промпт который даёт хорошие результаты для регулярной задачи (аудит AD, проверка сертификатов, генерация отчётов) — сохрани его в своём репозитории промптов. Это твои инструменты, не одноразовые запросы.
Зачем это важно:
Инженер, который умеет правильно использовать ИИ, решает за день то, на что раньше уходила неделя. Не потому что ИИ умнее — а потому что рутинная часть задачи делается быстрее, и остаётся больше времени на то, что требует реального опыта и суждения. В 2026 году это уже конкурентное преимущество на рынке труда, а не опциональный навык.242
Зачем это нужно:
Обновление защищает от BlackLotus и аналогичных UEFI-буткитов, которые атакуют ранний процесс загрузки. После истечения 2011-сертификатов система не сможет получать mitigation-обновления против новых буткитов, даже если Patch Tuesday приходит вовремя.
Итог: июнь — это через восемь недель. Серверный парк не обновляется сам. Сделай аудит сегодня, запланируй обновления на следующую неделю — и это закроется раньше, чем успеет стать инцидентом.
#windows #secureboot #security #windowsserver #patching #sysadmin #admin_future
242
🪟 Windows: Secure Boot 2011 → 2026 — у тебя есть два месяца до истечения сертификатов
Коллеги, это тот случай, когда Microsoft предупреждает заранее и громко — но в суете патч-вторников и инцидентов это всё равно тонет. Поэтому говорим сегодня, пока ещё есть время.
Сертификаты Secure Boot, которые Microsoft выпустила в 2011 году, начинают истекать в июне 2026 года. Затронуты физические и виртуальные машины на всех поддерживаемых версиях: Windows 10, Windows 11, Windows Server 2016, 2019, 2022, 2025 — всё железо с 2012 года.
Что произойдёт если не обновить: устройства продолжат запускаться и работать нормально, стандартные обновления Windows продолжат устанавливаться. Однако они больше не смогут получать новые средства защиты раннего процесса загрузки — обновления Windows Boot Manager, базы данных Secure Boot, списки отзыва и средства защиты от вновь обнаруженных уязвимостей уровня загрузки. С октября 2026 года — никаких security-фиксов для Windows Boot Manager.
Критический нюанс для серверов: в отличие от клиентских Windows-машин, которые получают сертификаты 2023 года автоматически через Windows Update, Windows Server требует ручного действия. Сертификаты на сервера автоматически не прилетают.
Аудит и обновление прямо сейчас:
# ШАГ 1 — Инвентаризация: проверяем статус на каждом сервере
# Проверяем текущий статус обновления сертификатов
Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue |
Select-Object UEFICA2023Status
# Возможные значения:
# (пусто / ключ отсутствует) = обновление не начато
# "InProgress" = в процессе
# "Updated" = готово, сертификаты 2023 установлены
# Проверяем включён ли Secure Boot вообще
Confirm-SecureBootUEFI
# Проверяем через Event Log — Event ID 1808 = сертификаты успешно обновлены
Get-WinEvent -LogName System |
Where-Object {$_.Id -eq 1808} |
Select-Object TimeCreated, Message |
Format-List
# ШАГ 2 — Для серверов БЕЗ сертификатов 2023: запускаем обновление вручную
# Инициируем обновление Secure Boot certificates
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
-Name "AvailableUpdates" `
-Value 0x5944
# Запускаем scheduled task для обновления
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Смотрим статус — должен появиться "InProgress"
Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status"
# ПЕРЕЗАГРУЖАЕМ сервер, затем запускаем task ещё раз
Restart-Computer -Force
# После перезагрузки:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Статус должен смениться на "Updated"
# ШАГ 3 — Массовый аудит через домен (все серверы сразу)
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -ExpandProperty Name
$results = foreach ($server in $servers) {
try {
$status = Invoke-Command -ComputerName $server -ScriptBlock {
$s = Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue
[PSCustomObject]@{
Server = $env:COMPUTERNAME
Status = if ($s) { $s.UEFICA2023Status } else { "NotStarted" }
SecureBootEnabled = (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)
}
} -ErrorAction Stop
$status
} catch {
[PSCustomObject]@{Server = $server; Status = "Unreachable"; SecureBootEnabled = $null}
}
}
$results | Sort-Object Status | Export-Csv "secureboot_audit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
$results | Group-Object Status | Format-Table Name, Count242
🐧 Linux: XFS self-healing в ядре 7.0 — конец ночных xfs_repair на продакшне
Коллеги, 12 апреля вышел Linux 7.0, и пока все обсуждают красивый мажорный номер версии и официальный статус Rust, кое-что поважнее тихо проскользнуло мимо радаров большинства. Для тех, кто держит боевые серверы на XFS — а это весь RHEL-мир, CentOS-наследники, Rocky и Alma — это прямой удар по одной из самых болезненных ситуаций в практике.
До 7.0 картина была такая: если XFS обнаруживал повреждение метаданных — от скачка питания, аппаратного сбоя или битого сектора — файловая система переходила в read-only или падала с ошибкой. Требовалось размонтировать том, часто невозможное на живой корневой ФС, загрузиться с rescue-медиа и запустить xfs_repair вручную.
Теперь другая история. Новая возможность использует специальный daemon, который опирается на parent pointer metadata и reverse mapping для обнаружения ошибок, о которых сообщает ядро, и запускает исправление автоматически. Всё это происходит пока файловая система примонтирована и активно используется.
Важный нюанс сразу: ядро не сканирует файловую систему непрерывно. Вместо этого — когда при обычных операциях чтения или записи встречаются несогласованные метаданные, оно теперь пытается исправить их на месте, а не возвращать ошибку или переходить в read-only. Это не покрывает все сценарии: глубокие структурные повреждения, аппаратный bit rot и сбои в блоках данных по-прежнему требуют офлайн-ремонта или восстановления из бэкапа.
Что делать практически прямо сейчас:
# Проверяем версию ядра — нужна 7.0+
uname -r
# На Ubuntu 26.04 LTS (выходит 23 апреля) — будет из коробки
# На текущих системах — смотрим в mainline PPA для тестовых сред:
# add-apt-repository ppa:kernel-ppa/mainline && apt update
# Проверяем что XFS примонтирован с нужными опциями
# self-healing включён по умолчанию — дополнительной конфигурации не нужно
mount | grep xfs
# Убеждаемся что есть rmapbt и parent pointers (нужны для self-heal)
xfs_info /dev/sda1 | grep -E "rmapbt|ftype|reflink"
# Мониторинг self-healing активности в реальном времени
# Смотрим dmesg — ядро будет логировать каждое исправление
dmesg -w | grep -iE "xfs.*(heal|repair|corrupt|recover)"
# Пример того что увидим при срабатывании:
# [ 183.44] XFS (sda1): Repairing corrupt inode btree in AG 2.
# [ 183.45] XFS (sda1): Self-healing complete. Filesystem operational.
# Для мониторинга через journalctl (если нет dmesg watch):
journalctl -k -f | grep -i "xfs"
# Проверяем health XFS-тома утилитой xfs_scrub (рекомендуется периодически)
# В режиме онлайн — не блокирует работу
xfs_scrub -v /mount/point
# Настраиваем регулярный xfs_scrub через systemd timer (уже есть в xfsprogs)
systemctl enable --now xfs_scrub_all.timer
systemctl status xfs_scrub_all.timer
# Смотрим статистику ошибок ФС
xfs_db -r -c "check" /dev/sda1 # offline check для диагностики
242
Зачем это важно для карьеры:
Разрыв между "администратором который смотрит на Zabbix" и "инженером который строит observability-пайплайн" в 2026 году — это разрыв в грейде и зарплате. Настройка занимает 4–6 часов в первый раз. Это звучит много — пока не сравниваешь с восьмичасовым разбором инцидента без нормальных данных.
Итог: мониторинг отвечает на вопрос "сломалось или нет". Observability отвечает на вопрос "почему сломалось и где именно". В современной инфраструктуре достаточно первого только для очень простых систем. Для всего остального нужна observability. И строить её уже можно с нуля за один вечер.
#skills #observability #prometheus #grafana #opentelemetry #sysadmin #admin_future
242
🧠 Skills: Мониторинг vs Observability — в чём разница и почему это важно для карьеры
Коллеги, разговор о вещи, которая кажется очевидной, но на практике разделяет инфраструктурных инженеров на два поколения.
Мониторинг — это когда знаешь заранее, что может сломаться, и смотришь на это. Дашборд с CPU, памятью, диском, статусом сервиса. Алерт когда CPU > 90%. Всё понятно, всё предсказуемо.
Observability — это когда можешь понять, что сломалось, даже если не знал заранее о такой поломке. Это способность задавать произвольные вопросы к системе в любой момент — без предварительной настройки метрики для каждого конкретного случая.
Разница не в инструментах. Разница в том, как мы думаем об инфраструктуре.
Два де-факто открытых стандарта в observability сегодня — Prometheus и OpenTelemetry. 65% организаций инвестируют в оба. Prometheus зрелее и больше используется в production (59%), OpenTelemetry быстрее растёт — 35% сейчас находятся на стадии POC и готовятся к масштабированию.
Практика: строим минимальный observability-стек на своём парке серверов:
# docker-compose.yml — базовый стек: Prometheus + Grafana + Node Exporter
# Разворачивается за 10 минут, даёт реальную видимость
version: '3.8'
services:
prometheus:
image: prom/prometheus:latest
container_name: prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus_data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.retention.time=30d' # Храним 30 дней истории
ports:
- "9090:9090"
restart: unless-stopped
node-exporter:
image: prom/node-exporter:latest
container_name: node_exporter
volumes:
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /:/rootfs:ro
command:
- '--path.procfs=/host/proc'
- '--path.rootfs=/rootfs'
- '--path.sysfs=/host/sys'
- '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
ports:
- "9100:9100"
restart: unless-stopped
grafana:
image: grafana/grafana:latest
container_name: grafana
volumes:
- grafana_data:/var/lib/grafana
environment:
- GF_SECURITY_ADMIN_PASSWORD=changeme_immediately
- GF_USERS_ALLOW_SIGN_UP=false
ports:
- "3000:3000"
restart: unless-stopped
volumes:
prometheus_data:
grafana_data:
# prometheus.yml — базовая конфигурация
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
# Сам Prometheus
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
# Метрики хоста
- job_name: 'node'
static_configs:
- targets: ['node-exporter:9100']
labels:
env: 'production'
datacenter: 'main'
# Если есть несколько серверов — добавляем все
- job_name: 'servers'
static_configs:
- targets:
- '192.168.1.10:9100'
- '192.168.1.11:9100'
- '192.168.1.12:9100'
# Три PromQL-запроса, которые реально нужны каждый день:
# 1. Топ-5 процессов по CPU (не просто средний по системе)
topk(5, rate(namedprocess_namegroup_cpu_seconds_total[5m]))
# 2. Свободное место на дисках с предсказанием когда кончится
predict_linear(node_filesystem_avail_bytes[6h], 4*3600) < 0
# 3. Доступная память — реальная, не та что показывает free
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
242
🪟 Windows: Patch Tuesday апрель 2026 — три проблемы из одного обновления, памятка для выживших
Коллеги, 14 апреля вышел апрельский Patch Tuesday. И он немедленно стал мемом в сообществе администраторов — но не потому что хороший. За три дня Microsoft подтвердила три отдельные проблемы от одного пакета обновлений KB5082063. Разбираем по порядку.
Что закрыли: 163 CVE, из них 8 критических, два zero-day. Самый опасный — CVE-2026-33824 с CVSS 9.8 в Windows IKE Service Extensions: уязвимость позволяет неаутентифицированному атакующему выполнить код удалённо, достаточно отправить специально сформированные пакеты на машину с включённым IKEv2. Не устанавливать нельзя.
Что сломали — проблема первая, BitLocker: некоторые Windows Server 2025 устройства с определённой конфигурацией TPM Group Policy требуют ввода ключа восстановления BitLocker при первой перезагрузке после KB5082063. Это происходит, если одновременно выполнены условия: BitLocker включён, GPO настраивает TPM PCR7, msinfo32 показывает PCR7 Binding как "Not Possible", и на устройстве уже присутствует сертификат Windows UEFI CA 2023.
Проблема вторая, ещё хуже: non-Global Catalog контроллеры домена в средах с Privileged Access Management (PAM) могут войти в бесконечный цикл перезагрузок из-за краша LSASS при старте. Затронуты Windows Server 2016, 2019, 2022 и 2025.
Проблема третья — ошибка 0x800F0983 при установке на части Windows Server 2025 систем. Обновление просто не ставится.
Что делать прямо сейчас:
# ШАГ 1 — Перед установкой KB5082063: проверяем риск BitLocker
# Проверяем состояние PCR7 Binding
Get-ComputerInfo | Select-Object BiosFirmwareType, SecureBootEnabled
# Смотрим msinfo32 через PowerShell
$csWmi = Get-WmiObject -Class Win32_ComputerSystem
# Или через msinfo32.exe — ищем строку "PCR7 Binding"
msinfo32.exe # -> System Summary -> Secure Boot State
# Если PCR7 Binding = "Not Possible" — снимаем GPO перед патчем
# Computer Config -> Admin Templates -> Windows Components
# -> BitLocker Drive Encryption -> OS Drives
# -> "Configure TPM platform validation profile" -> Not Configured
gpupdate /force
# ШАГ 2 — Проверяем, является ли DC Global Catalog (GC)
# Если NOT GC + PAM включён = высокий риск reboot loop
# Проверяем GC статус:
Import-Module ActiveDirectory
Get-ADDomainController -Identity $env:COMPUTERNAME |
Select-Object Name, IsGlobalCatalog, IPv4Address
# Если IsGlobalCatalog = False И в среде есть PAM ->
# НЕ устанавливать KB5082063 до появления фикса,
# или ставить только после консультации с Microsoft Support
# ШАГ 3 — Проверяем наличие IKEv2 (CVE-2026-33824 CVSS 9.8)
# Если IKEv2 не используется — блокируем UDP 500 и 4500
netsh advfirewall firewall show rule name="IKE*"
# Временный mitigation если патч не встаёт:
netsh advfirewall firewall add rule `
name="Block IKEv2 inbound temp" `
dir=in action=block `
protocol=UDP localport=500,4500
# ШАГ 4 — Экстракция BitLocker recovery ключей заранее (всегда!)
# Для всех машин домена:
Get-ADComputer -Filter * | ForEach-Object {
Get-ADObject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} `
-SearchBase $_.DistinguishedName `
-Properties 'msFVE-RecoveryPassword' |
Select-Object @{N='Computer';E={$_.DistinguishedName}},
@{N='Key';E={$_.'msFVE-RecoveryPassword'}}
} | Export-Csv "bitlocker_keys_backup_$(Get-Date -Format yyyyMMdd).csv"
242
🐧 Linux: io_uring — самый быстрый и самый опасный интерфейс ввода-вывода в ядре
Коллеги, разговор о том, что активно идёт в production прямо сейчас, но о чём мало говорят в контексте безопасности. io_uring появился в ядре 5.1 в 2019 году как революция асинхронного I/O — два кольцевых буфера между ядром и userspace, работа без системных вызовов, минимальный overhead. PostgreSQL оценивает его интеграцию, Meta использует в production годами. Производительность реальная.
Проблема тоже реальная. В июне 2023 года команда безопасности Google сообщила, что 60% эксплойтов в их bug bounty программе за 2022 год были направлены против уязвимостей io_uring. Итог: io_uring отключён в Android, полностью отключён в ChromeOS и на серверах Google.
Ситуация улучшилась, но не исчезла. io_uring может обходить системные вызовы целиком — это означает, что инструменты безопасности, основанные на перехвате syscall (Falco, Tetragon в стандартной конфигурации, многие коммерческие EDR), слепы к операциям через io_uring. Rootkit, работающий через io_uring, будет невидим для большинства систем обнаружения.
Практика: проверяем состояние io_uring в своей инфраструктуре и ограничиваем где нужно:
# Проверяем, используют ли процессы io_uring прямо сейчас
# Смотрим открытые io_uring файловые дескрипторы
find /proc/*/fd -type l 2>/dev/null | xargs ls -la 2>/dev/null | grep anon_inode
# Более точно — смотрим через lsof
lsof | grep io_uring
# Проверяем, какие приложения слинкованы с liburing
ldd /usr/bin/postgres 2>/dev/null | grep uring
find /usr/bin /usr/sbin /opt -type f -name "*.so*" 2>/dev/null | \
xargs grep -l "io_uring" 2>/dev/null | head -20
# ---- ОГРАНИЧЕНИЕ ДЛЯ КОНТЕЙНЕРОВ ----
# Запрет io_uring через seccomp (правильный способ для Docker/Podman)
cat > /etc/docker/seccomp-no-iouring.json << 'EOF'
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"names": ["io_uring_setup", "io_uring_enter", "io_uring_register"],
"action": "SCMP_ACT_ERRNO",
"errnoRet": 38
}
]
}
EOF
# Запускаем контейнер без io_uring
docker run --security-opt seccomp=/etc/docker/seccomp-no-iouring.json nginx
# ---- ДЛЯ systemd-сервисов ----
# В unit-файле — ограничение системных вызовов
# Добавляем в [Service]:
# SystemCallFilter=~io_uring_setup io_uring_enter io_uring_register
# ---- АУДИТ ----
# Если используете auditd — добавляем правила мониторинга io_uring
cat >> /etc/audit/rules.d/iouring.rules << 'EOF'
-a always,exit -F arch=b64 -S io_uring_setup -k iouring_activity
-a always,exit -F arch=b64 -S io_uring_enter -k iouring_activity
EOF
auditctl -R /etc/audit/rules.d/iouring.rules
# Смотрим активность:
ausearch -k iouring_activity | tail -20
