🐧 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 — это не экзотика. Это архитектурная чистка, которая делает Linux-boot предсказуемее. Ubuntu 26.04 уже с ней.
#linux #kernel7 #boot #filesystem #sysadmin #admin_future
Коллеги, одна из тихих, но важных вещей в ядре 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
Зачем это нужно:
Надёжнее загрузка → меньше случаев когда сервер не поднялся после патча. Для флотов с автоматическим деплоем ядра — это снижение риска.
Итог: nullfs — это не экзотика. Это архитектурная чистка, которая делает Linux-boot предсказуемее. Ubuntu 26.04 уже с ней.
#linux #kernel7 #boot #filesystem #sysadmin #admin_future
🧠 Skills: Переводи downtime в деньги — или тебя не будут слушать
Коллеги, есть навык, который отличает инженера от архитектора инфраструктуры. Не знание конкретной технологии. Умение объяснить цену отказа на языке бизнеса.
Когда ты говоришь "нам нужна избыточность" — тебя слышат как расходы. Когда ты говоришь "один час простоя стоит нам X рублей" — тебя слышат как управление рисками. Разница принципиальная.
Даже один час даунтайма обходится средней компании в 300 000+. Для крупных предприятий цифры уходят в миллионы. Переведи это на свой контекст — и у тебя появится аргумент.
Простая формула для любого разговора с руководством:
Переход от 99.0% к 99.9% uptime может означать сотни тысяч сэкономленных рублей в год — часто больше, чем стоит само улучшение инфраструктуры.
Зачем это нужно:
Когда ты приходишь с таблицей, а не с ощущением — разговор меняется. Руководитель видит не "инженер хочет новое железо", а "инженер управляет рисками компании".
Итог: посчитай стоимость одного часа простоя своего самого критичного сервиса. Запиши число. Именно с него начинается любой разговор о надёжности.
#skills #downtime #sla #карьера #sysadmin #admin_future
Коллеги, есть навык, который отличает инженера от архитектора инфраструктуры. Не знание конкретной технологии. Умение объяснить цену отказа на языке бизнеса.
Когда ты говоришь "нам нужна избыточность" — тебя слышат как расходы. Когда ты говоришь "один час простоя стоит нам 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
🔥3
🪟 Windows: Создатель диспетчера задач признался — CPU% всегда было «некрологом недавнего прошлого»
Коллеги, на этой неделе Дэйв Пламмер — инженер Microsoft, написавший оригинальный Task Manager — объяснил то, о чём многие из нас догадывались, но не формулировали чётко. Цифра загрузки CPU в диспетчере задач никогда не была «сейчас».
«Число CPU в диспетчере задач — это движущийся некролог недавнего прошлого», объяснил Пламмер. «Не то, что происходило в момент, когда ваши глаза остановились на строке».
Как это работало изнутри:
Windows не хранит никакого магического значения загрузки CPU, готового к считыванию. Вместо этого Task Manager работал по таймеру: при каждом срабатывании запрашивал у ядра накопленное процессорное время каждого процесса и сравнивал с предыдущим снимком.
Это решение умное и дешёвое — но у него есть фундаментальное ограничение на современном железе:
«Современная загрузка CPU больше похожа на то, насколько было заполнено шоссе, а не на то, сколько миль реально проехали. Полупустое шоссе с Ferrari может пропустить гораздо больше трафика, чем забитое шоссе со старыми грузовиками».
Процессоры с Turbo Boost, тепловым троттлингом и глубокими состояниями простоя разорвали связь между «занятым временем» и «реально выполненной работой». 73% в диспетчере может означать совершенно разный объём вычислений в зависимости от того, на какой частоте работал CPU в этот момент.
Что из этого следует практически — чем смотреть вместо Task Manager:
Кстати, 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
Коллеги, на этой неделе Дэйв Пламмер — инженер 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 с 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
Коллеги, если у вас 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
👍1
🪟 Windows: hotpatch в мае — что изменилось и одна важная ловушка
Коллеги, с 11 мая hotpatch включается по умолчанию для всех eligible Windows 11 24H2 устройств через Intune. Разбираем быстро что важно знать прямо сейчас.
Hotpatch патчит код запущенных процессов прямо в памяти, не заменяя файлы на диске. Поэтому перезагрузка не нужна — изменения вступают в силу немедленно для уже запущенных процессов.
Схема простая: 4 раза в год (январь, апрель, июль, октябрябрь) — полный baseline с перезагрузкой. Остальные 8 месяцев — hotpatch без рестарта.
Но апрельский цикл преподнёс сюрприз: установка KB5091157 (OOB-фикс для апрельского Patch Tuesday) требует перезагрузки и приостанавливает hotpatching. Hotpatch-обновления возобновятся только после июльского baseline. То есть если поставили фикс — ближайшие два месяца работаете в обычном режиме.
Зачем это нужно:
После установки OOB KB5091157 с перезагрузкой hotpatching приостанавливается до июльского baseline. Это задокументированное поведение — планируй обслуживание соответственно.
Итог: hotpatch — хорошая технология. Но "включилось само" без понимания цикла — это потеря контроля над maintenance windows. Проверь VBS и пойми свой текущий статус до 11 мая.
#windows #hotpatch #intune #patching #sysadmin #admin_future
Коллеги, с 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: кто будет поддерживать это актуальным и как? Если ответа нет — атрибут не нужен.
Зачем это нужно:
CMDB с актуальными зависимостями отвечает на вопрос "что упадёт если я выключу этот сервер?" за секунды, а не за час расследования. Это разница между проактивным и реактивным администрированием.
Итог: хорошая CMDB — это не большая, а актуальная. Лучше 50 записей которым все верят, чем 5000 которые никто не читает.
#skills #cmdb #itsm #infrastructure #sysadmin #admin_future
Коллеги, у большинства из нас есть 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.
Зачем это нужно:
Серверы, которые не могут немедленно применить патч, должны рассмотреть ограничение сетевого доступа через firewall-правила для сокращения поверхности атаки и мониторинг журналов на предмет необычных крашей или ошибок памяти.
Итог: KFENCE по умолчанию отключён в большинстве продакшн-дистрибутивов — проверь, прежде чем паниковать. Но патч ядра в любом случае ставим при ближайшем обслуживании.
#linux #kernel #cve #security #sysadmin #admin_future
Коллеги, на прошлой неделе тихо появилась 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 автоматически, без дополнительной настройки администратором.
Зачем это нужно:
Passkeys криптографически привязаны к устройству и никогда не передаются по сети — атакующий не может их украсть при фишинге или через вредоносное ПО для обхода MFA. Функция закрывает брешь в безопасности, которая оставляла личные и общие устройства с паролями после недавней волны атак на Entra SSO.
Итог: действие сегодня — зайди в Entra и убедись что знаешь, что будет происходить с passkeys в твоём тенанте. «Включилось само» — не оправдание на следующем аудите.
#windows #entra #passkeys #fido2 #security #sysadmin #admin_future
Коллеги, новость которую стоит знать прямо сейчас, потому что она касается твоих пользователей и твоих политик — молча, без запроса разрешения.
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 из реактивного «пожарного» в проактивного архитектора роста бизнеса. Её цель — оптимизировать производительность при непрерывной и пиковой нагрузке, понимая изменения в использовании: сезонные всплески, релизы продуктов, рост команды.
Минимальный рабочий фреймворк:
Распространённая ошибка: планирование в изоляции. IT-команды, которые прогнозируют спрос без информации от бизнеса, обречены на провал. Capacity plan должен опираться на бизнес-цели, а не только на исторические IT-данные.
Зачем это нужно:
Организации, которые делают это правильно, тратят меньше (нет избыточного provisioning, нет аварийных закупок), обеспечивают надёжность (нет сюрпризов от исчерпания ресурсов) и принимают решения быстрее — на основе данных, а не интуиции.
Итог: capacity planning — это не документ раз в год. Это ежемесячные 30 минут с дашбордом и одним вопросом: "когда что-то упрётся в потолок?". Ответ на него должен быть у тебя всегда.
#skills #capacityplanning #мониторинг #инфраструктура #sysadmin #admin_future
Коллеги, честный вопрос: у вас есть прогноз нагрузки на инфраструктуру на следующий квартал? Не ощущение, а цифры? Если нет — вы занимаетесь реактивным администрированием. И рано или поздно вас накроет.
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-контроль на уровне юнита. Но главное — большинство директив безопасности были доступны давно, просто их не используют.
Зачем это нужно:
Скомпрометированный nginx с PrivateTmp и ProtectSystem=strict не доберётся до ваших SSH-ключей, конфигов баз данных или других сервисов. Изоляция на уровне юнита — это дешёвый слой defence-in-depth, который не требует контейнеров.
Итог: запусти
#linux #systemd #hardening #security #sysadmin #admin_future
Коллеги, большинство 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.
Зачем это нужно:
Windows Server 2025 больше не трактует все устройства хранения как SCSI. Native NVMe обеспечивает прямой многоочередной доступ к устройствам — это означает возможность достичь реальных пределов производительности железа.
Итог: если у тебя WS2025 с NVMe-дисками и это не включено — ты буквально оставляешь 80% производительности хранилища на столе. Одна команда в реестре и перезагрузка. Сделай это сегодня.
#windows #nvme #storage #performance #windowsserver2025 #sysadmin #admin_future
Коллеги, фича которая доступна с октября 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
GitHub
GitHub - microsoft/diskspd: DISKSPD is a storage load generator / performance test tool from the Windows/Windows Server and Cloud…
DISKSPD is a storage load generator / performance test tool from the Windows/Windows Server and Cloud Server Infrastructure Engineering teams - microsoft/diskspd
🔥2
🧠 Skills: IaC drift — молчаливый убийца стабильности и как его ловить автоматически
Коллеги, у вас есть Ansible или Terraform. Вы гордитесь тем что инфраструктура описана как код. Но когда последний раз вы проверяли — соответствует ли то что работает в продакшне тому что написано в репозитории?
Configuration drift — это когда кто-то "быстро поправил руками" в пятницу вечером, написал "потом зафиксирую в коде" и конечно не зафиксировал. Через месяц инфраструктура живёт своей жизнью, а код — своей.
Два подхода в зависимости от инструмента:
Зачем это нужно:
Drift detection для Ansible превращает идемпотентность в реальный механизм контроля: если ничего не меняется при запуске — системы соответствуют коду. Terraform использует state file для сравнения желаемого и реального состояния — это его главное преимущество перед Ansible в вопросе дрейфа.
Итог: IaC без регулярной проверки дрейфа — это как бэкап без тестирования восстановления. Выглядит серьёзно, но не работает в нужный момент. Настрой еженедельный отчёт сегодня — это 20 минут работы.
#skills #iac #ansible #terraform #drift #sysadmin #admin_future
Коллеги, у вас есть 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.
Зачем это важно: Red Hat оценил уязвимость как Critical. Эксплуатация не требует аутентификации — достаточно сетевого доступа к порту 9090. PoC уже опубликован на GitHub.
Итог: если Cockpit у тебя слушает на публичном интерфейсе и без патча — это не вопрос "могут ли взломать", а вопрос "когда". Два действия: закрыть порт и обновить пакет.
#linux #cve #cockpit #rhel #security #sysadmin #admin_future
Коллеги, на прошлой неделе тихо закрыли одну из самых неприятных уязвимостей апреля в 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 поведение зафиксируется окончательно и откат в режим аудита станет невозможен. Времени мало.
Зачем это нужно:
RC4 позволяет Kerberoasting: атакующий запрашивает билет, зашифрованный RC4, и взламывает его оффлайн. Современные GPU делают это за минуты. Microsoft убирает RC4 принудительно — и это правильно.
Итог: аудит уже три месяца доступен через Event ID 201-202. Если ты не смотрел — посмотри сегодня. Июль ждать не будет.
#windows #kerberos #activedirectory #security #sysadmin #admin_future
Коллеги, апрельский 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 в вашей инфраструктуре.
Как выстроить процесс:
Зачем это нужно:
EOL-компонент без патчей — это не технический долг. Это открытая CVE без срока закрытия. Апрельский Cockpit RCE затронул установки, которые просто не обновлялись. Большинство громких инцидентов — это не zero-day, это известные уязвимости в давно устаревшем ПО.
Итог: endoflife.date + 15 строк bash + cron — и у тебя есть система которая скажет о проблеме за полгода, а не за день до инцидента.
#skills #eol #инфраструктура #patching #sysadmin #admin_future
Коллеги, вопрос на пятницу: вы знаете, какое ПО в вашей инфраструктуре уходит на 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.
Действия прямо сейчас:
Зачем это важно:
Уязвимость быстро закроют в облаках и Kubernetes-кластерах. Но длинный хвост старых и забытых Linux-систем — роутеры, IoT, терминалы, промышленные системы — останется уязвимым ещё годами. В вашей инфраструктуре наверняка есть такие «забытые» хосты.
Итог: два действия сегодня — blacklist algif_aead на всех серверах где нет патча, обновить ядро там где патч доступен. PoC публичный, счёт идёт на часы.
#linux #cve #kernel #security #lpe #sysadmin #admin_future
Коллеги, 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 не охватывает все обновления — .NET-патчи, несекьюрити-обновления и патчи сторонних компонентов по-прежнему требуют перезагрузки. Нельзя считать, что сервер с hotpatch больше никогда не перезагружается.
Итог: четыре перезагрузки в год вместо двенадцати — реальное улучшение для uptime. Но hotpatch не бесплатен на on-prem и не заменяет полный patch management. Знай что у тебя включено и почему.
#windows #hotpatch #patchtuesday #windowsserver2025 #sysadmin #admin_future
Коллеги, 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: Говори на языке бизнеса — или вечно жди выделения бюджета
Коллеги, суббота — день для разговора не про технологии, а про то, что реально двигает карьеру вперёд.
Есть инженеры, которые знают больше всех в команде, делают огромный объём работы — и при этом годами сидят на одном месте, не получают бюджет на инфраструктуру и не участвуют в стратегических решениях. И есть те, кто умеет то же самое, но ещё умеет объяснить это руководству. Вторые растут быстрее.
Разрыв между ними — не технические знания. Это умение переводить с инженерного на бизнесовый.
Три конкретных паттерна, которые работают:
Умение «продавать» решения руководству — это не политика и не манипуляция. Это умение предоставить цифры, обосновать ценность с точки зрения бизнес-задач и рассчитать риски.
Зачем это нужно:
Инженер который понимает бизнес-контекст — получает бюджет, участвует в архитектурных решениях и влияет на направление инфраструктуры. Инженер который не понимает — ждёт пока руководитель сам дойдёт до нужного решения. Иногда это занимает годы.
Итог: технические знания открывают дверь в профессию. Умение говорить с бизнесом открывает дверь в карьеру. Оба навыка нужны — и второй прокачивается так же, как первый: практикой.
#skills #карьера #коммуникация #sysadmin #admin_future
Коллеги, суббота — день для разговора не про технологии, а про то, что реально двигает карьеру вперёд.
Есть инженеры, которые знают больше всех в команде, делают огромный объём работы — и при этом годами сидят на одном месте, не получают бюджет на инфраструктуру и не участвуют в стратегических решениях. И есть те, кто умеет то же самое, но ещё умеет объяснить это руководству. Вторые растут быстрее.
Разрыв между ними — не технические знания. Это умение переводить с инженерного на бизнесовый.
Три конкретных паттерна, которые работают:
ПАТТЕРН 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
❤1
🐧 Linux: живёшь под root в контейнере — живёшь опасно. Исправляем за 10 минут
Коллеги, воскресный пост про вещь, которую игнорируют даже опытные администраторы. Зайди в любой Docker-окружение на среднестатистическом сервере и запусти:
Готов поспорить — большинство контейнеров покажут пустой User. Это означает root внутри. 79% Linux-атак в 2026 году используют легитимные системные инструменты — bash, cron, curl. Контейнер с root-процессом при любом побеге из namespace превращается в полноценный вектор атаки на хост.
Исправляется в три шага:
Зачем это нужно:
Контейнер не является изолированной средой по умолчанию. Безопасность зависит от корректной настройки. Запуск под root — это не дефолт ради удобства, это дефолт ради лени. После вчерашней CVE-2026-31431 «Copy Fail» — любой непривилегированный пользователь на хосте мог стать root. Если контейнер уже запускается как root — второй шаг атаки не нужен.
Итог: один Dockerfile и десять минут — и твои контейнеры перестают быть тривиальным вектором атаки. Запусти аудит сегодня.
#linux #docker #containers #security #hardening #sysadmin #admin_future
Коллеги, воскресный пост про вещь, которую игнорируют даже опытные администраторы. Зайди в любой 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 с этим не согласны — этот привилей есть у огромного числа сервисных аккаунтов по умолчанию.
Что делать сегодня — три митигейшна:
Зачем это важно:
Это не единственный баг в одном компоненте. Kaspersky указывают на системную слабость в том, как Windows обрабатывает провенанс RPC-серверов — значит, новые векторы атаки через эту архитектуру будут появляться и дальше.
Итог: патча нет и не предвидится. Мониторинг ETW, минимизация SeImpersonatePrivilege и запущенные сервисы-«заглушки» — это всё что есть прямо сейчас. Мало, но лучше чем ничего.
#windows #security #rpc #phantomrpc #lpe #sysadmin #admin_future
Коллеги, 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 минут, но меняет траекторию карьеры за год.
Большинство из нас растут реактивно: выучили то, что потребовалось в инциденте. Прочитали то, что попалось в ленте. Попробовали то, что пришло в задаче. Это нормально, но этого недостаточно для осознанного роста.
Три вопроса воскресного ревью:
Практический инструмент — engineering log. Не задокументированный runbook, а личный дневник инженера:
Зачем это нужно:
Ключевой сдвиг последних лет в профессии — переход от реактивной модели работы к проактивной. Engineering log — это инструмент, который делает этот переход конкретным и измеримым. Через три месяца ты откроешь записи за январь и удивишься насколько вырос.
Итог: 15 минут в воскресенье. Три вопроса. Один файл в Git. Через год это будет лучшим документом твоего профессионального роста — точнее любого резюме.
#skills #карьера #обучение #рост #sysadmin #admin_future
Коллеги, раз в неделю стоит задавать себе три вопроса — не по работе, а по себе как по специалисту. Это занимает 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