متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
Admin Future
الذهاب إلى القناة على Telegram
Превращаем эникейщиков в System Architects. 🚀 Твой навигатор в мире IT-инфраструктуры: ▪️ Hard Skills: Linux, Windows, Network, Security ▪️ Tools: Лучший софт и скрытые фишки ▪️ Mindset: Как думать, чтобы платили много Админ - @maksimshap
إظهار المزيد242
المشتركون
لا توجد بيانات24 ساعات
-167 أيام
-1330 أيام
جاري تحميل البيانات...
القنوات المماثلة
لا توجد بيانات
هل تواجه مشاكل؟ يرجى تحديث الصفحة أو الاتصال بمدير الدعم الخاص بنا.
سحابة العلامات
الإشارات الواردة والصادرة
---
---
---
---
---
---
جذب المشتركين
يونيو '26
يونيو '26
+1
في 0 قنوات
مايو '26
+6
في 0 قنوات
Get PRO
أبريل '26
+28
في 1 قنوات
Get PRO
مارس '26
+12
في 0 قنوات
Get PRO
فبراير '26
+32
في 0 قنوات
Get PRO
يناير '26
+17
في 0 قنوات
Get PRO
ديسمبر '25
+199
في 0 قنوات
| التاريخ | نمو المشتركين | الإشارات | القنوات | |
| 23 يونيو | 0 | |||
| 22 يونيو | 0 | |||
| 21 يونيو | 0 | |||
| 20 يونيو | 0 | |||
| 19 يونيو | 0 | |||
| 18 يونيو | 0 | |||
| 17 يونيو | 0 | |||
| 16 يونيو | 0 | |||
| 15 يونيو | 0 | |||
| 14 يونيو | 0 | |||
| 13 يونيو | +1 | |||
| 12 يونيو | 0 | |||
| 11 يونيو | 0 | |||
| 10 يونيو | 0 | |||
| 09 يونيو | 0 | |||
| 08 يونيو | 0 | |||
| 07 يونيو | 0 | |||
| 06 يونيو | 0 | |||
| 05 يونيو | 0 | |||
| 04 يونيو | 0 | |||
| 03 يونيو | 0 | |||
| 02 يونيو | 0 | |||
| 01 يونيو | 0 |
منشورات القناة
🧠 Skills: Шесть LPE за год — пора признать что патчинг это не стратегия, а тактика
Коллеги, среда — день для стратегического взгляда. CIFSwitch стал шестым LPE в ядре Linux за 2026 год: Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt, ssh-keysign-pwn и теперь CIFSwitch. Это не случайность. Это новая норма.
Паттерн каждого из них одинаков: для сисадминов управляющих Linux-флотами в 2026 году паттерн реакции один и тот же каждый раз: применить no-reboot митигейшн немедленно, затем запланировать обновление ядра и перезагрузку.
Если ты реагируешь на каждый из них вручную — ты проиграл гонку ещё до старта. Нужна стратегия defence-in-depth которая защищает ДО появления конкретной CVE.
Три слоя которые превращают "паника на каждый LPE" в "плановую работу":
СЛОЙ 1: СОКРАЩЕНИЕ ПОВЕРХНОСТИ АТАКИ (проактивно)
Большинство LPE 2026 требуют специфичных модулей/фич:
Copy Fail → algif_aead
Dirty Frag → esp4/esp6/rxrpc
CIFSwitch → cifs + unprivileged userns
Если этих модулей нет — ты не уязвим автоматически.
Инструмент: ModuleJail (автоблок неиспользуемых модулей)
sudo sh modulejail -p conservative
Или вручную blacklist всего что не используется.
KDE Linux team в мае сделала именно это — вернулись к vanilla
kernel и удалили небезопасные неиспользуемые модули после аудита.
СЛОЙ 2: ОГРАНИЧЕНИЕ NAMESPACE И PTRACE (один раз настроить)
Большая часть LPE 2026 пивотится через unprivileged user namespaces:
# Ограничиваем (ломает некоторые контейнеры — тестируй):
sysctl -w kernel.unprivileged_userns_clone=0
Ptrace-класс (ssh-keysign-pwn):
sysctl -w kernel.yama.ptrace_scope=1
Это закрывает не одну CVE, а целый класс векторов.
СЛОЙ 3: RUNTIME-МОНИТОРИНГ ЦЕЛОСТНОСТИ ЯДРА
LKRG (Linux Kernel Runtime Guard) — детектирует попытки
эксплуатации в реальном времени, даже неизвестных CVE:
modprobe lkrg
sysctl -w lkrg.profile_enforce=2
Overhead ~1.7% на Intel, 0.1% на Ryzen. Для серверов приемлемо.
ИТОГОВАЯ МАТЕМАТИКА:
Без слоёв: каждый LPE = ручной митигейшн × N серверов = часы паники
Со слоями: каждый LPE = "у нас этот модуль уже заблокирован" = 0 паники
+ плановый патч в обычное окно обслуживания
Один честный вопрос для среды:
Возьми CIFSwitch. Спроси себя — "если бы у меня был ModuleJail и ограниченные namespaces, был бы я уязвим к нему из коробки?" Для большинства серверов ответ — нет. cifs-utils там не стоит, namespaces ограничены. Угроза стала бы "не моя проблема" автоматически.
Зачем это важно: organizations should not wait for confirmed attacks before applying mitigations. Но ещё лучше — построить инфраструктуру где конкретная CVE уже митигирована до её раскрытия. Это разница между тактикой и стратегией.
Итог: патчинг обязателен, но это тактика. Стратегия — сокращение поверхности атаки, ограничение namespace/ptrace и runtime-мониторинг. Построй три слоя один раз — и седьмой LPE года встретишь спокойно.
#skills #security #defenseindepth #kernel #стратегия #sysadmin #admin_future| 2 | 🪟 Windows: DNS over HTTPS на сервере стал GA — шифруем DNS для клиентов
Коллеги, в июньском обновлении Windows Server 2025 (KB5094125) тихо приехала фича которую ждали — и которую затмили 206 CVE и Secure Boot. Разбираем.
Июньское обновление включает server-side DNS over HTTPS (DoH) как generally available. Это обеспечивает шифрованную DNS-коммуникацию между сервером и его клиентами, улучшая приватность и безопасность за счёт защиты DNS-запросов, особенно против определённых атак. Важно: DoH-поддержка применяется только к server-to-client коммуникации, не к шифрованию между серверами.
Почему это важно: DNS-запросы исторически идут открытым текстом. Любой кто видит трафик — видит какие домены резолвят твои клиенты. Для внутренней сети это вектор разведки при компрометации, для филиалов через недоверенные каналы — прямая утечка. DoH закрывает это на уровне DNS-сервера.
Также в этом же обновлении — важный фикс по теме которую мы разбирали в апреле:
Обновление решает проблему когда некоторые устройства могли входить в BitLocker recovery после обновления boot-файлов, на системах с определёнными настройками TPM validation (особенно невалидными PCR7-конфигурациями). Это поведение возникало после установки апрельского обновления KB5082063.
# Включаем DNS over HTTPS на Windows Server 2025 DNS-сервере:
# 1. Проверяем что июньское обновление установлено:
Get-HotFix -Id KB5094125 -ErrorAction SilentlyContinue
# 2. Включаем DoH на DNS-сервере:
Set-DnsServerSetting -Name "EnableDoHServer" -Value $true
# (точное имя командлета может отличаться — проверяем доступные:)
Get-DnsServerSetting -All | Select-String -Pattern "DoH|HTTPS"
# 3. Привязываем сертификат для DoH (нужен валидный TLS-сертификат):
# Сертификат с SAN = FQDN DNS-сервера
$cert = Get-ChildItem Cert:\LocalMachine\My |
Where-Object {$_.Subject -like "*dns-server-fqdn*"}
# Регистрируем сертификат для DoH listener
# 4. Проверяем что DoH слушает (порт 443):
Get-NetTCPConnection -LocalPort 443 -State Listen |
Where-Object {$_.OwningProcess -eq (Get-Process dns).Id}
# 5. Также новая GPO для контроля Secure Boot телеметрии:
# Computer Config -> Admin Templates -> Windows Components
# -> Secure Boot -> LimitSecureBootRequiredServiceData
# Позволяет ограничить какие Secure Boot данные уходят в Microsoft
# 6. Настраиваем клиентов на использование DoH:
# GPO: Computer Config -> Admin Templates -> Network -> DNS Client
# -> Configure DNS over HTTPS (DoH) name resolution -> Require DoH
Зачем включать сейчас: после месяцев фокуса на патчинге уязвимостей — это редкая возможность улучшить базовую безопасность инфраструктуры проактивно. Шифрование DNS закрывает целый класс пассивной разведки в сети.
Итог: июньское обновление это не только 206 CVE и Secure Boot. Это DoH server-side GA + фикс апрельской BitLocker-проблемы. Подними DoH в лабе на этой неделе — это базовая гигиена которую долго ждали в Windows Server.
#windows #dns #doh #windowsserver2025 #security #sysadmin #admin_future | 50 |
| 3 | 🐧 Linux: CIFSwitch — баг 2007 года даёт root одной командой. PoC опубликован.
Коллеги, добрая среда. Шестой LPE в ядре Linux за 2026 год — и снова из той же серии что Copy Fail, Dirty Frag, Fragnesia и DirtyDecrypt. На этот раз код прятался 19 лет.
CIFSwitch (CVE-2026-46243) — локальное повышение привилегий в CIFS-подсистеме ядра Linux. Уязвимость присутствовала в коде с 2007 года — 19 лет необнаруженной. На затронутых системах любой непривилегированный локальный пользователь может получить root-shell одной командой.
Исследователь Asim Manizada раскрыл баг 28 мая 2026 с рабочим PoC на GitHub в тот же день. CVE присвоен 1 июня, пропатченные ядра дошли до production-репозиториев 2 июня.
Хорошая новость — условия эксплуатации узкие: баг находится в fs/smb/client/cifs_spnego.c — коде который обрабатывает Kerberos/SPNEGO-аутентификацию для CIFS-клиента ядра. Для эксплуатации нужны два условия: установлен cifs-utils И разрешены unprivileged user namespaces.
cifs-utils не входит в дефолтную установку большинства систем, и типичные shared-hosting серверы его не несут — такие хосты не уязвимы. Проверьте флот перед действиями.
# ШАГ 1 — Проверяем уязвимы ли мы:
# Установлен ли cifs-utils:
which mount.cifs cifs.upcall 2>/dev/null
dpkg -l cifs-utils 2>/dev/null || rpm -q cifs-utils 2>/dev/null
# Если НЕ установлен — вы НЕ уязвимы, можно выдохнуть
# Разрешены ли unprivileged user namespaces:
sysctl kernel.unprivileged_userns_clone 2>/dev/null # Debian/Ubuntu
sysctl user.max_user_namespaces # RHEL/CentOS
# ШАГ 2 — Патч уже в production-репах с 2 июня:
uname -r
apt update && apt full-upgrade -y && reboot # Debian/Ubuntu
dnf update kernel -y && reboot # RHEL/Rocky/AlmaLinux
# ШАГ 3 — МИТИГЕЙШН без перезагрузки (если cifs не нужен):
echo "install cifs /bin/false" > /etc/modprobe.d/disable-cifs.conf
rmmod cifs 2>/dev/null
# ВНИМАНИЕ: ломает монтирование SMB/CIFS шар!
# Или удаляем cifs-utils если SMB не нужен:
apt remove cifs-utils # Debian/Ubuntu
dnf remove cifs-utils # RHEL/Rocky/AlmaLinux
# Без cifs-utils эксплуатация невозможна
# Или отключаем user namespaces (ломает контейнеры):
sysctl -w kernel.unprivileged_userns_clone=0 # Debian/Ubuntu
sysctl -w user.max_user_namespaces=0 # RHEL/CentOS
# ШАГ 4 — Мониторинг (multi-tenant/CI/CD):
# Следим за request_key() с необычными cifs.spnego ключами:
auditctl -a always,exit -F arch=b64 -S request_key -k cifs_spnego
Зачем это важно как тренд: 19-летний возраст уязвимого кода и наличие публичного PoC означают что эксплуатация в дикой природе вероятна. Организациям не стоит ждать подтверждённых атак перед применением митигейшна.
Итог: проверь установлен ли cifs-utils. Нет — не уязвим. Есть — патч (уже в репах) или удали cifs-utils если SMB не нужен. Шестой LPE за год — паттерн очевиден.
#linux #kernel #cifswitch #cve #security #sysadmin #admin_future | 53 |
| 4 | 🧠 Skills: Docs-as-Code — почему Confluence умирает и что приходит на смену
Коллеги, понедельник — хороший день для темы которая отделяет зрелые инфраструктуры от хаотичных. Документация.
Главная боль технической документации известна каждому: во-первых, её нет. Во-вторых, если она есть — она не актуальна. Confluence-страница, обновлённая последний раз в 2023-м, хуже чем отсутствие документации — она вводит в заблуждение.
Docs-as-Code решает это радикально: документация живёт там же где код, в том же git, проходит те же review.
Docs-as-Code — это методология которая говорит документировать так же как ты обращаешься с кодом — используя те же инструменты, workflow и системы контроля версий что разработчики используют для написания кода. Документация хранится в plain text (Markdown, AsciiDoc), в git-репозитории, с современным тулингом для генерации HTML, PDF.
Честная оговорка чтобы не было иллюзий: Docs-as-Code не обновляет документацию автоматически так же как обновляется код. Когда разработчик добавляет новый API endpoint — документация не сгенерируется сама, если для этого не настроены конкретные workflow и автоматизация.
Практический старт для сисадмина — не нужен GitBook за деньги:
МИНИМАЛЬНЫЙ DOCS-AS-CODE СТЕК (всё бесплатно):
Хранение: Gitea / GitLab (self-hosted)
Формат: Markdown (или AsciiDoc если нужны include и переменные)
Генерация: MkDocs (Material theme) — статичный сайт из .md
Диаграммы: Mermaid / PlantUML (текстом, версионируются)
CI/CD: git hook → автодеплой при push
СТРУКТУРА РЕПОЗИТОРИЯ:
docs/
├── infrastructure/
│ ├── network-topology.md # + Mermaid диаграмма inline
│ ├── servers-inventory.md
│ └── backup-strategy.md
├── runbooks/
│ ├── RB-001-db-failover.md
│ └── RB-002-cert-renewal.md
├── procedures/
│ └── onboarding-new-server.md
└── mkdocs.yml
# Поднять MkDocs за 5 минут:
pip install mkdocs-material --break-system-packages
# Инициализируем проект:
mkdocs new infra-docs && cd infra-docs
# Правим mkdocs.yml — тема Material:
cat > mkdocs.yml << 'EOF'
site_name: Infrastructure Docs
theme:
name: material
features:
- search.suggest
- content.code.copy
markdown_extensions:
- pymdownx.superfences:
custom_fences:
- name: mermaid
class: mermaid
EOF
# Локальный предпросмотр:
mkdocs serve # http://127.0.0.1:8000
# Деплой как статика (git hook или CI):
mkdocs build # генерит site/ — отдаём через nginx
# Диаграмма прямо в markdown (Mermaid):
# ```mermaid
# graph LR
# Internet --> Firewall --> LB --> Web1 & Web2 --> DB
# ```
Один принцип который делает Docs-as-Code живым: хорошая документация должна непрерывно эволюционировать вместе с кодом который она описывает. Правило простое — изменил инфраструктуру, обнови doc в том же PR. Не «потом», а в том же коммите. Review не пропускает PR без обновления документации.
Зачем это сисадмину а не только разработчику: твои runbook, топология сети, процедуры onboarding — это и есть код инфраструктуры. В git они версионируются, ревьюятся, и главное — видно кто и когда менял. Confluence этого не даёт.
Итог: MkDocs + Gitea + правило «doc в том же PR» = документация которая не устаревает. Это вечер настройки и смена привычки. Попробуй на одном runbook на этой неделе.
#skills #docsascode #документация #mkdocs #git #sysadmin #admin_future | 56 |
| 5 | 🪟 Windows: Secure Boot — финальная неделя. 24 июня дедлайн, но Microsoft смягчила формулировки.
Коллеги, это последний понедельник перед дедлайном Secure Boot. Через 9 дней — 24 июня — истекает первый из сертификатов 2011 года. Но с хорошей новостью: Microsoft на втором AMA уточнила что это не «hard stop».
Microsoft уточнила: устройства продолжат функционировать даже если не завершили обновления до истечения сертификата Key Exchange Key (KEK) 24 июня 2026. Также Microsoft указала что сертификат Secure Boot DB остаётся валидным до октября 2026 — это даёт дополнительное время на подписание и распространение обновлённых boot manager-ов.
Что реально изменилось после июньского Patch Tuesday: июньский Patch Tuesday должен перевести большинство mainstream-устройств в категорию «high-confidence». Устройства классифицированные как high confidence могут получать Secure Boot обновления автоматически через Intune. Для устройств вне high-confidence категории администраторам может потребоваться вручную включить развёртывание через registry settings или политики Intune.
Ключевой совет от Microsoft: не откладывайте развёртывание в ожидании пока каждое устройство достигнет статуса high-confidence.
# ФИНАЛЬНЫЙ ЧЕКЛИСТ — последняя неделя
# 1. Проверяем confidence-статус через Intune:
# Intune -> Devices -> Monitor -> Secure Boot certificate report
# high confidence = автоматом, остальное = вручную
# 2. Проверяем статус на серверах:
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -ExpandProperty Name
$results = foreach ($s in $servers) {
try {
Invoke-Command -ComputerName $s -ScriptBlock {
$sb = Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -EA SilentlyContinue
[PSCustomObject]@{
Server=$env:COMPUTERNAME
Status=if($sb){$sb.UEFICA2023Status}else{"NOT_STARTED"}
}
} -EA Stop
} catch { [PSCustomObject]@{Server=$s; Status="UNREACHABLE"} }
}
$results | Group-Object Status | Format-Table Name, Count
# 3. Для NOT_STARTED — принудительно включаем (registry):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot" `
/v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Процесс занимает ~48 часов и одну-две перезагрузки
# 4. Проверяем что boot manager обновился (DB-сертификат до октября):
Confirm-SecureBootUEFI
Get-SecureBootUEFI -Name db | Select-Object -ExpandProperty Bytes |
Measure-Object
Зачем не расслабляться несмотря на смягчение: десктопная версия этой истории раздражающая. Серверная — операционно серьёзная. Окружения Windows Server 2016, 2019, 2022 и 2025 могут быть затронуты, и путь к исправлению сложнее чем «нажми обновить и перезагрузись».
Итог: 24 июня — не катастрофа, а начало деградации защиты. DB-сертификат живёт до октября, это буфер. Но запусти обновление на NOT_STARTED серверах на этой неделе — процесс занимает двое суток.
#windows #secureboot #windowsserver #security #sysadmin #admin_future | 48 |
| 6 | 🐧 Linux: Неделя 24 закрылась — Samba, OpenSSL и ядро требуют перезагрузки. Планируем окно.
Коллеги, добрый понедельник. После июньского рекордного хаоса на стороне Windows, в Linux-мире неделя прошла относительно спокойно — но «спокойно» не значит «можно игнорировать». Разбираем что прилетело.
Эта неделя принесла обновления ядра и core-сервисов для OpenSSL, Samba и Apache. Они почти наверняка потребуют полной перезагрузки, поэтому планируйте окно обслуживания вокруг активного продакшн-трафика. Samba-обновление имеет критический рейтинг, потому что непропатченные file-sharing сервисы исторически были самой лёгкой точкой входа для ransomware-кампаний.
И AlmaLinux, и Rocky Linux выкатывают тяжёлую пачку advisory затрагивающих ядро, BIND DNS, OpenSSL и Samba. Пропуск этих патчей оставляет сети широко открытыми для RCE и кражи данных.
Важное предупреждение по процессу: сисадмины наблюдали как продакшн-кластеры зависали после применения kernel-патчей без предварительной проверки совместимости out-of-tree модулей. .NET-обновления также раскатываются по нескольким версиям — любые backend-сервисы на этих runtime потребуют быстрого рестарта для подхвата криптографических улучшений.
# ПЕРЕД kernel-апдейтом — проверяем out-of-tree модули
# (то что зависало кластеры у других):
# Смотрим какие модули НЕ из mainline:
grep -h "" /sys/module/*/taint 2>/dev/null
# Или ищем проприетарные/внешние модули:
for mod in $(lsmod | awk 'NR>1{print $1}'); do
modinfo "$mod" 2>/dev/null | grep -q "intree:Y" || echo "OUT-OF-TREE: $mod"
done
# Типичные виновники: nvidia, vmware, zfs, virtualbox, drbd
# Проверяем что DKMS пересоберёт их под новое ядро:
dkms status
# ПОРЯДОК БЕЗОПАСНОГО ОБНОВЛЕНИЯ:
# 1. Snapshot/backup перед апдейтом (LVM/ZFS snapshot)
# 2. Обновляем но НЕ перезагружаемся:
apt update && apt full-upgrade -y --no-install-recommends # Debian/Ubuntu
dnf update -y # RHEL/Rocky/Alma
# 3. Проверяем что DKMS-модули собрались под новое ядро:
dkms status | grep installed
# 4. Перезагружаемся в окно обслуживания:
reboot
# 5. ПОСЛЕ перезагрузки — проверяем критичные сервисы:
systemctl --failed
ss -tlnp # слушают ли нужные порты
# Для Samba:
smbclient -L localhost -N 2>&1 | head
# Для .NET:
systemctl status <ваши-dotnet-сервисы>
Итог: неделя 24 — про дисциплину процесса, не про панику. Snapshot перед апдейтом, проверка DKMS, перезагрузка в окно, верификация сервисов после. Samba — приоритет, ransomware любит непропатченный SMB.
#linux #kernel #samba #patching #security #sysadmin #admin_future | 46 |
| 7 | 🧠 Skills: Усталость от алертов. Как Zabbix убивает вашу внимательность
Коллеги, если в вашей дежурной группе в Telegram каждый день сыпятся десятки сообщений "CPU Load is > 80%" или "Disk space < 20%", и вы их просто смахиваете, не читая — у вас серьезная проблема. Это называется Alert Fatigue (усталость от предупреждений).
В 2026 году мониторинг не должен быть логом событий. Алерт должен приходить ТОЛЬКО тогда, когда требуется немедленное действие живого человека.
Внедряем правило 3 вопросов для настройки любого триггера:
Это влияет на бизнес прямо сейчас?
Я должен бросить свой кофе и чинить это немедленно?
Если я проигнорирую это до завтрашнего утра, кто-то заметит?
Если хотя бы на один вопрос ответ "Нет" — смело переводим этот триггер в разрез инфо-дашбордов или утренних отчетов. Никаких пуш-уведомлений и красных значков.
Зачем это нужно:
Когда случится настоящий сбой (например, дропнется RAID-массив в проде), вы можете просто пропустить этот критический алерт между пятьюдесятью рядовыми сообщениями о высокой загрузке процессора на тестовом контуре. Тишина в канале мониторинга — это признак здоровой инфраструктуры и здоровой психики администратора.
#skills #monitoring #zabbix #management #sysadmin #admin_future | 56 |
| 8 | 🪟 Windows: SMB over QUIC — убиваем VPN для файловых шар
Коллеги, вчера мы ждали новых сюрпризов от Nightmare Eclipse (обещанный дроп 14 июня), но пока эфир относительно чист. Зато есть повод поговорить о хорошем. Больше никаких пробросов порта 445 и обязательных корпоративных VPN для доступа к рабочим файлам из дома.
В Windows Server 2025 технология SMB over QUIC окончательно стала мейнстримом. QUIC работает поверх протокола UDP (порт 443). Трафик всегда зашифрован TLS 1.3, провайдеры его не режут, а скорость при плохом мобильном интернете в разы выше классического TCP.
Как настроить в PowerShell:
# Проверяем поддержку на сервере:
Get-SmbServerConfiguration | Select-Object EnableSMBQUIC
# Включаем SMB over QUIC (потребуется привязать сертификат):
Set-SmbServerConfiguration -EnableSMBQUIC $true
# На клиенте (Windows 11) принудительно мапим сетевой диск через QUIC:
New-SmbMapping -LocalPath 'Z:' -RemotePath '\\fs.makshel.local\Share' -TransportType QUIC
Зачем это нужно:
Пользователи получают доступ к корпоративным шарам так же просто, как к облачному диску. А безопасники спят спокойно, потому что наружу торчит только стандартный 443 UDP порт, а не дырявый 445 TCP, который обожают шифровальщики.
#windows #windowsserver #quic #networking #sysadmin #admin_future | 59 |
| 9 | 🐧 Linux: Хватит терпеть зависания при OOM. Включаем PSI и systemd-oomd
Коллеги, добрый понедельник. Знакомая ситуация: на сервере потекла память, своп забился, load average улетел в космос, и вы даже по SSH зайти не можете. Классический OOM Killer в ядре срабатывает слишком поздно, когда система уже фактически в коме.
В 2026 году мы решаем это изящнее. Мы используем PSI (Pressure Stall Information) вместе с systemd-oomd. Этот демон убивает прожорливые cgroups ДО того, как операционная система намертво повиснет.
Скрипт для проверки и активации:
# Проверяем, включен ли PSI в ядре (вывод не должен быть пустым):
cat /proc/pressure/memory
# Если включен, активируем службу systemd-oomd:
systemctl enable --now systemd-oomd
# Смотрим статус и кто сейчас под угрозой:
oomctl status
Зачем это нужно:
Сервер должен оставаться управляемым при любых утечках памяти. Лучше пусть упадет один проблемный контейнер или веб-сервис, чем вся нода уйдет в hard reset по питанию, утащив за собой соседние процессы.
#linux #systemd #oom #performance #sysadmin #admin_future | 55 |
| 10 | 🧠 Skills: Nightmare Eclipse и кризис bug bounty — что это означает для всей индустрии
Коллеги, сегодня не только про патчи. Сегодня про ситуацию которая меняет правила игры для всего security-сообщества — и косвенно касается каждого администратора.
История: независимый исследователь под псевдонимом Nightmare Eclipse обнаружил серию критических уязвимостей в Windows и честно сообщил в Microsoft через официальные каналы. Microsoft удалила его аккаунт в MSRC и он не получил никакого вознаграждения. В ответ исследователь начал публично раскрывать уязвимости с рабочими PoC-эксплойтами. Microsoft ответила угрозами уголовного преследования, что вызвало огромную волну возмущения в security-сообществе. Microsoft отступила и заявила что не намерена преследовать исследователей.
Nightmare Eclipse представляет третью категорию: ответное раскрытие спровоцированное воспринятым нарушением со стороны вендора. Этот сценарий — когда исследователь исчерпывает официальные каналы и не получает ответа или получает активный вред — это известный сбой программ coordinated disclosure.
Почему это важно для тебя как администратора — три практических вывода:
ВЫВОД 1: ТЕМП ZERO-DAY УСКОРЯЕТСЯ
AI-assisted code analysis + недовольные исследователи +
сломанные bug bounty программы = больше публичных zero-day
без периода согласованного раскрытия.
Практическое следствие:
Patch Tuesday больше не единственный момент когда нужно
смотреть на безопасность Windows. Нужен:
- RSS на MSRC: msrc.microsoft.com/update-guide
- Подписка на BleepingComputer security alerts
- CISA KEV daily check
ВЫВОД 2: DEFENDER ОБНОВЛЯЕТСЯ ОТДЕЛЬНО ОТ ОС
CVE-2026-41091 (Defender LPE) был пропатчен через автообновление
engine ДО Patch Tuesday. Если у тебя отключены автообновления Defender —
ты жил с активно эксплуатируемой уязвимостью несколько недель.
Проверяем и исправляем:
Get-MpComputerStatus | Select-Object AMEngineVersion
# Нужна >= 1.1.26040.8
# Принудительное обновление Defender:
Update-MpSignature -UpdateSource MicrosoftUpdateServer
ВЫВОД 3: BUG BOUNTY — ЭТО РИСК УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ
Когда вендор плохо управляет отношениями с исследователями —
уязвимости становятся публичными без патча.
Это системный риск для всех кто использует этот вендор.
Что делать: следить не только за CVE но и за конфликтами
в security-сообществе. Злой исследователь с PoC + дедлайн
"14 июня новое раскрытие" — это operational intelligence
которая влияет на приоритизацию патчинга прямо сейчас.
Microsoft's response, threatening prosecution rather than investigating the underlying bounty dispute, will make other researchers in similar situations less likely to attempt coordination at all. Это означает больше zero-day без предупреждения в будущем.
Итог: история с Nightmare Eclipse — это не просто скандал. Это сигнал что модель coordinated disclosure трещит под давлением AI-assisted vulnerability research и неработающих incentive-систем. Как администратор — готовься к более частым zero-day и выстраивай процессы реагирования соответственно.
#skills #security #zerodaybugs #bugbounty #patchmanagement #sysadmin #admin_future | 80 |
| 11 | 🪟 Windows: Июньский Patch Tuesday — рекорд за всю историю программы и три важных приоритета
Коллеги, вчера 10 июня вышел самый большой Patch Tuesday в истории. Разбираем что важно из 200 CVE.
Июньский релиз — крупнейший за всё время существования программы, включает 3 публично раскрытых zero-day, 33 критических уязвимости (28 из которых RCE) и ещё 55 RCE уязвимостей требующих немедленного внимания. Релиз вышел при 17 оставшихся днях до абсолютного дедлайна Secure Boot сертификатов 26 июня.
Три приоритета для сисадмина:
Приоритет 1 — Hyper-V guest escape (Critical): CVE-2026-47652, CVE-2026-45641 и CVE-2026-45607 — критические RCE уязвимости в Hyper-V способные позволить побег из виртуальной машины и выполнение кода. Если у вас Hyper-V — это патчить первым.
Приоритет 2 — HTTP/2 Bomb (CVE-2026-49160): атака злоупотребляет сжатием заголовков и управлением потоком HTTP/2 так что маленькие запросы вынуждают сервер аллоцировать непропорционально большие объёмы памяти и удерживать их. Для интернет-facing серверов с IIS — срочно.
Приоритет 3 — Nightmare Eclipse zero-days закрыты: исследователь под псевдонимом Nightmare Eclipse публично раскрыл серию Windows zero-days (BlueHammer, MiniPlasma, RedSun, UnDefend, YellowKey) в знак протеста против обращения Microsoft с его bug bounty программой. Все они закрыты в этом Patch Tuesday. Но исследователь предупредил о новом раскрытии 14 июня.
# Проверяем установлен ли июньский патч:
Get-HotFix | Where-Object {$_.InstalledOn -ge "2026-06-09"} |
Select-Object HotFixID, InstalledOn |
Sort-Object InstalledOn -Descending | Select-Object -First 3
# Проверяем Microsoft Defender Engine (CVE-2026-41091 — уже пропатчен через автообновление):
Get-MpComputerStatus | Select-Object AMEngineVersion
# Нужна версия 1.1.26040.8 или новее
# Для Hyper-V хостов — приоритет первый:
Get-VM | Select-Object Name, State, Version
# Ставим патч и перезагружаем хост в окно обслуживания
# HTTP.sys — проверяем открыт ли HTTP/2:
netsh http show servicestate | grep -i "http/2"
# Временный митигейшн — отключить HTTP/2:
netsh http add sslcert ... # или через IIS Manager -> HTTP/2 -> Disable
# Secure Boot — дедлайн 26 июня (15 дней):
Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue
# Если не "Updated" — немедленно запускаем:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Отдельное предупреждение: отраслевые аналитики указывают на отчётливый катализатор этого всплеска уязвимостей — ИИ. Корпоративные security-команды и независимые исследователи агрессивно используют автоматизированные LLM-инструменты для аудита кодовых баз, обнаруживая программные дефекты со скоростью и масштабом которые традиционная ручная проверка не может догнать.
Итог: 200 CVE, рекорд, три zero-day, Hyper-V escape. И Secure Boot истекает через 15 дней. Патчи — сегодня.
#windows #patchtuesday #hyper-v #security #sysadmin #admin_future | 59 |
| 12 | 🐧 Linux: CVE-2026-23111 — один лишний символ в nftables даёт root. Эксплойт публичный.
Коллеги, добрый четверг. После майского марафона LPE казалось что можно выдохнуть. Не успели.
CVE-2026-23111 сидит в коде nf_tables packet-filtering ядра и был пропатчен upstream ещё 5 февраля 2026. Exodus Intelligence выпустили полный технический разбор 8 июня, и это не первый публичный эксплойт — FuzzingLabs опубликовал независимое воспроизведение ещё в апреле. Баг свёлся к единственному лишнему символу — инвертированной проверке в nf_tables — и upstream-фикс убрал его одной строкой.
Достижимая конфигурация типична: nftables плюс unprivileged user namespaces — Linux-фича которая позволяет обычному аккаунту действовать как root внутри приватной песочницы и достигать кода ядра который иначе был бы недоступен. Оба компонента включены по умолчанию на большинстве десктопов и многих серверных сборках. Удалённого вектора нет.
Ubuntu оценивает CVSS 7.8 (high). PoC публичен с апреля.
# ПРОВЕРКА — уязвимы ли вы:
uname -r
# Патч в ядрах 7.0.6 / 6.18.28 / 6.12.87 / 6.6.138 и новее
# Если ваша версия старее — уязвимы
# Митигейшн — отключаем unprivileged user namespaces:
# (ломает некоторые приложения типа Chrome/Chromium sandbox!)
sysctl kernel.unprivileged_userns_clone
# Если 1 — включено. Отключаем:
sysctl -w kernel.unprivileged_userns_clone=0
echo "kernel.unprivileged_userns_clone=0" >> \
/etc/sysctl.d/99-userns.conf
# Альтернатива — AppArmor restriction (Ubuntu):
# Ограничиваем user namespaces без полного отключения:
sysctl -w kernel.apparmor_restrict_unprivileged_userns=1
# Проверяем используется ли user namespaces активными процессами:
find /proc/*/ns/user -type l 2>/dev/null | wc -l
# Если > 5-10 — что-то активно использует, отключение аккуратно
# ОБНОВЛЯЕМ ЯДРО:
apt update && apt full-upgrade -y && reboot # Ubuntu/Debian
dnf update kernel -y && reboot # RHEL/Rocky/AlmaLinux
Зачем это важно именно сейчас: публичный PoC означает что автоматизированные атаки уже возможны. Если на вашем сервере есть непривилегированные пользователи с shell-доступом — это активный риск прямо сейчас.
Итог: один символ в коде — root на твоём сервере. Ядро обновлено — проблемы нет. Не обновлено — mitigation через sysctl за 30 секунд.
#linux #kernel #nftables #cve #security #sysadmin #admin_future | 56 |
| 13 | 🧠 Skills: Июнь — время ревью инфраструктуры. Три вещи которые стоит сделать в первую неделю
Коллеги, понедельник 1 июня — хорошее начало для структурированного квартального ревью. Май был реактивным. Июнь должен быть проактивным.
После Copy Fail, Dirty Frag, Fragnesia, CVE-2026-46333, Entra hard match, RC4 и Secure Boot — у тебя есть уникальная возможность: пока всё свежо в памяти, превратить реакцию на инциденты в системные улучшения.
Три конкретных действия на первую неделю июня:
ДЕЙСТВИЕ 1: INFRASTRUCTURE HEALTH CHECK (вторник-среда)
Linux:
□ Все ядра обновлены до патчей мая
uname -r на каждом хосте (нужна 7.0.8 / 6.18.31 / 6.12.89+)
□ ptrace_scope >= 1 на всех серверах
sysctl kernel.yama.ptrace_scope
□ SSH host keys ротированы на хостах с local users
□ Mitigation файл /etc/modprobe.d/may2026-kernel-lpe.conf стоит
Windows:
□ KB5087539 установлен на все Windows Server 2025
□ Secure Boot статус "Updated" на всех серверах
(дедлайн истёк, но лучше поздно чем никогда)
□ RC4 аудит Event 201/202 — смотрим есть ли трафик
□ Entra Connect версия >= 2.5.79.0
ДЕЙСТВИЕ 2: ПРОЦЕССНЫЙ АУДИТ (четверг)
Что из майских реакций было ручным и должно стать автоматическим?
Создай список из трёх пунктов:
□ Что делал руками на каждом сервере?
→ Кандидат для Ansible playbook
□ О чём узнал от коллег а не из мониторинга?
→ Кандидат для нового алерта
□ Что занимало > 30 минут разбора?
→ Кандидат для runbook
Один playbook написать прямо в четверг.
ДЕЙСТВИЕ 3: ДЕДЛАЙНЫ ИЮНЯ-ИЮЛЯ (пятница-планирование)
Составь список уже сейчас:
□ 1 июня: Entra hard match (СЕГОДНЯ)
□ 8 июня: июньский Patch Tuesday
□ Июнь: Secure Boot сертификаты истекают
□ 30 июня: Entra Connect 2.5.79.0 (версия старее = синк ломается)
□ 1 июля: Entra Phase 2 (OnPremisesObjectIdentifier freeze)
□ Июль: RC4 Kerberos enforcement финал
Занести всё в трекер с датами и владельцами.
Не в голову — в систему.
Почему именно сейчас а не позже: вопрос для 2026 года — не будут ли продолжаться kernel-эксплойты, а будет ли ваша инфраструктура защищена когда они появятся. Системная защита строится в спокойные недели, а не во время следующего инцидента.
Итог: май был хаотичным. Июнь может быть управляемым — если первую неделю потратить на систематизацию а не на тушение пожаров. Три действия. Три дня. Хорошего понедельника.
#skills #инфраструктура #процессы #планирование #sysadmin #admin_future | 106 |
| 14 | 🪟 Windows: Entra hard match — сегодня 1 июня, блокировка включилась. Что происходит.
Коллеги, доброе утро понедельника с новой реальностью. Сегодня 1 июня 2026 — день когда Microsoft включила принудительную блокировку hard match для привилегированных Entra ID аккаунтов.
Что именно случилось сегодня:
Entra Connect Sync и Cloud Sync теперь блокируют любую попытку hard-match нового AD-объекта к существующему cloud-managed пользователю который имеет Entra роли. Существующие синхронизированные аккаунты не затронуты — блокируются только НОВЫЕ попытки hard match. Soft match поведение не изменяется.
Есть и вторая фаза: 1 июля 2026 — Entra Connect больше не сможет изменять атрибут OnPremisesObjectIdentifier после того как он уже установлен на синхронизированном пользователе. Это предотвращает переназначение уже синхронизированного пользователя на другой on-premises identity. Обе фазы возвращают одинаковую ошибку при блокировке: "Hard match operation blocked due to security hardening".
Если сегодня у тебя упала синхронизация с этой ошибкой:
# 1. Смотрим ошибки синхронизации:
# Entra Admin Center -> Identity -> Hybrid management
# -> Microsoft Entra Connect -> Sync errors
# Через PowerShell:
Get-ADSyncCSObject -ConnectorName "yourDomain.com" |
Where-Object {$_.ErrorName -ne $null} |
Select-Object Name, ErrorName, ErrorDetail |
Format-List
# 2. Диагностируем конкретный аккаунт:
# Ищем cloud-user с onPremisesImmutableId и Entra ролью:
Connect-MgGraph -Scopes "User.Read.All","RoleManagement.Read.Directory"
$user = Get-MgUser -Filter "userPrincipalName eq 'user@domain.com'" `
-Property OnPremisesImmutableId, Id
$roles = Get-MgUserTransitiveMemberOf -UserId $user.Id |
Where-Object {$_."@odata.type" -eq "#microsoft.graph.directoryRole"}
Write-Host "ImmutableId: $($user.OnPremisesImmutableId)"
Write-Host "Roles: $($roles.DisplayName -join ', ')"
# 3. ПРАВИЛЬНОЕ РЕШЕНИЕ — убираем роль с синхронизированного аккаунта
# и назначаем cloud-only аккаунту (Best Practice):
# Remove-MgDirectoryRoleMember -DirectoryRoleId <roleId> `
# -DirectoryObjectId $user.Id
# Создаём cloud-only admin account и назначаем роль ему
# 4. ВРЕМЕННЫЙ обходной путь (НЕ для production):
# Убрать onPremisesImmutableId с cloud-объекта чтобы разрешить hard match
# НО — это уберёт защиту от SyncJacking
# Делать ТОЛЬКО если понимаешь последствия
Контекст зачем это нужно: SyncJacking — атака где злоумышленник с определёнными привилегиями может злоупотребить hard matching синхронизацией в Entra Connect и полностью захватить любой синхронизированный Entra ID аккаунт — включая Active Global Administrator.
Итог: если всё работает — отлично, ты подготовился. Если упала синхронизация с ошибкой hard match — это не баг, это новая политика безопасности. Best practice: привилегированные роли только на cloud-only аккаунтах. Никогда на синхронизированных.
#windows #entra #activedirectory #hybrididentity #security #sysadmin #admin_future | 85 |
| 15 | 🐧 Linux: LKRG 1.0 — runtime-защита ядра вышла из experimental, и вот почему это важно сейчас
Коллеги, добрый понедельник и добро пожаловать в июнь. Май 2026 дал нам шесть уязвимостей ядра за три недели. Лучший момент поговорить об инструменте который менял бы картину для всех из них.
Linux Kernel Runtime Guard (LKRG) официально достиг версии 1.0 — переход от экспериментального проекта к production-ready инструменту. После нескольких лет разработки, тестирования и реального использования релиз 1.0 сигнализирует уверенность в стабильности и долгосрочном направлении.
Что делает LKRG: это loadable kernel module который мониторит целостность ядра в runtime. LKRG выполняет runtime integrity checking ядра Linux и детектирование эксплуатации уязвимостей безопасности против ядра. Это не патч ядра — модуль, который можно собрать для широкого спектра mainline и дистрибутивных ядер без их патчинга.
Если бы LKRG стоял на серверах в мае: он бы детектировал попытки page-cache write от Copy Fail/Dirty Frag/Fragnesia и реагировал — вплоть до kernel panic или kill процесса. Это не замена патчу, но дополнительный слой.
# УСТАНОВКА:
# Rocky/AlmaLinux/RHEL (через SIG Security):
dnf install epel-release
dnf install lkrg-dkms
# Debian/Ubuntu (через Kicksecure repo):
curl -fsSL https://www.kicksecure.com/keys/derivative.asc | \
gpg --dearmor | tee /usr/share/keyrings/derivative.asc
echo "deb [signed-by=/usr/share/keyrings/derivative.asc] \
https://deb.kicksecure.com bookworm main" | \
tee /etc/apt/sources.list.d/lkrg.list
apt update && apt install lkrg
# Загружаем модуль:
modprobe lkrg
dmesg | grep -i lkrg | tail -5
# Проверяем статус:
sysctl lkrg.profile_enforce
# 0=monitoring, 1=detect+log, 2=balanced, 3=heavy, 4=paranoid
# ВАЖНО: начинаем с мониторинга, не с enforce:
sysctl -w lkrg.profile_enforce=1
# Смотрим логи несколько дней — ищем false positives:
journalctl -k | grep -i lkrg | tail -20
# После проверки — включаем защиту:
echo "lkrg.profile_enforce=2" >> /etc/sysctl.d/01-lkrg.conf
# Автозагрузка:
echo "lkrg" >> /etc/modules-load.d/lkrg.conf
Важные предупреждения: performance overhead есть — около 1.7% на Intel i7, 0.1% на Ryzen. Для production-серверов это приемлемо. Опция lkrg.block_modules блокирует загрузку новых модулей — не включать если система загружает модули динамически. Начинать с profile_enforce=0 или 1 и проверять false positives несколько дней.
Итог: после мая 2026 — LKRG в production это уже не паранойя. Это разумная defence-in-depth против целого класса атак. Ставь в лабу сегодня, в прод — после тестирования.
#linux #lkrg #kernel #security #hardening #sysadmin #admin_future | 70 |
| 16 | 🧠 Skills: Публичный GitHub — почему это важнее резюме в 2026 году
Коллеги, вторник — хороший момент для темы которую откладывают до лучших времён. Лучших времён не будет. Говорим о публичном профиле инженера.
Большинство сисадминов имеют огромный массив написанного кода: скрипты, плейбуки, конфиги, шаблоны. Всё это живёт в внутренних репозиториях или на личных компьютерах. И не видно никому снаружи.
В 2026 году это уже не нейтральная позиция — это упущенное преимущество.
Три конкретных шага которые меняют ситуацию:
ШАГ 1: ПУБЛИЧНЫЙ GITHUB С РЕАЛЬНЫМИ ИНСТРУМЕНТАМИ
(не "hello world", а то что реально используешь)
Что можно публиковать без риска:
- Ansible roles для типовых задач
(hardening, monitoring setup, backup scripts)
- PowerShell-скрипты для AD-аудита
- Docker-compose шаблоны для dev-окружений
- Конфиги nginx/haproxy с комментариями
- Runbook-шаблоны в Markdown
Что НЕ публиковать:
- IP-адреса и имена хостов своей инфраструктуры
- Credentials, tokens, пароли (даже в коментах)
- Конфиги с именами пользователей и доменов компании
- Специфику уязвимостей которые ещё не закрыты
Как проверить перед публикацией:
git grep -E "password|secret|token|key" -- '*.yml' '*.sh'
trufflehog filesystem . --only-verified
ШАГ 2: README КОТОРЫЙ ОБЪЯСНЯЕТ ЗАЧЕМ, А НЕ ТОЛЬКО КАК
Плохой README: "Скрипт для бэкапа"
Хороший README:
"Скрипт автоматизирует ежедневный бэкап PostgreSQL
с шифрованием через age, загрузкой в S3-совместимое
хранилище и алертом в Telegram при ошибке.
Используется на 15 серверах в продакшне."
Разница: второй показывает что ты думал о надёжности,
безопасности и масштабе — а не просто написал bash.
ШАГ 3: ОДИН РЕПОЗИТОРИЙ В МЕСЯЦ
Не нужно всё сразу. Один полезный скрипт или плейбук
с нормальным README в месяц — за год это 12 проектов.
Это уже профиль который можно показать.
Почему это важно именно для сисадмина (не только для разработчика):
В 2026 году граница между sysadmin и infrastructure engineer размытая. Карьерный рост в IT-инфраструктуре предусматривает движение от технической поддержки и системного администрирования к старшему инженеру, архитектору и далее к руководящим ролям. На каждом переходе — публичный портфолио работает лучше чем пересказ резюме.
Зачем начинать сейчас: инженер который решил CVE-2026-46333 через ptrace_scope + ротацию ключей, написал плейбук для ModuleJail, и опубликовал его с README — это не просто хорошая история для собеседования. Это живое доказательство экспертизы.
Итог: один публичный репозиторий с чем-то реальным и полезным — лучшая инвестиция в карьеру которую можно сделать за вечер. Начни с того скрипта который написал на прошлой неделе.
#skills #github #карьера #портфолио #sysadmin #admin_future | 94 |
| 17 | 🪟 Windows: Entra hard match — 1 июня через 6 дней. Последний шанс проверить.
Коллеги, срочное напоминание. До дедлайна шесть дней — и это не тот дедлайн который переносят.
С 1 июня 2026 Microsoft Entra ID заблокирует любую попытку Entra Connect Sync или Cloud Sync выполнить hard-match нового объекта пользователя из Active Directory к существующему cloud-managed Entra ID пользователю, которому назначены Microsoft Entra роли. Если cloud-managed пользователь уже имеет onPremisesImmutableId (sourceAnchor) и назначенную роль — Connect Sync или Cloud Sync больше не смогут взять Source of Authority этого пользователя через hard-match с входящим AD-объектом.
Это защита от атаки SyncJacking — когда атакующие манипулируют синхронизацией каталогов чтобы захватить привилегированные cloud-идентичности. Hard match для непривилегированных аккаунтов не затронут. Поведение soft match не изменяется.
Дополнительный дедлайн который многие не заметили: все synchronization services в Microsoft Entra Connect Sync перестанут работать 30 сентября 2026 если не обновиться до версии минимум 2.5.79.0.
# ШАГ 1: Проверяем версию Entra Connect (нужна минимум 2.5.79.0):
Get-ADSyncGlobalSettings | Select-Object Version
# или
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" |
Select-Object AzureADConnectVersion
# Если версия ниже 2.5.79.0 — СРОЧНО обновить:
# Скачать с: entra.microsoft.com -> Identity -> Hybrid management
# -> Entra Connect -> Download
# ШАГ 2: Находим cloud-привилегированные аккаунты которые могут
# сломаться при попытке hard-match после 1 июня:
Connect-MgGraph -Scopes "RoleManagement.Read.Directory","User.Read.All"
$allRoleAssignments = Get-MgRoleManagementDirectoryRoleAssignment -All
$riskyUsers = foreach ($ra in $allRoleAssignments) {
try {
$user = Get-MgUser -UserId $ra.PrincipalId `
-Property OnPremisesImmutableId,DisplayName,UserPrincipalName `
-ErrorAction Stop
if ($user.OnPremisesImmutableId) {
[PSCustomObject]@{
DisplayName = $user.DisplayName
UPN = $user.UserPrincipalName
ImmutableId = $user.OnPremisesImmutableId
RoleId = $ra.RoleDefinitionId
}
}
} catch {}
}
$riskyUsers | Format-Table -AutoSize
$riskyUsers | Export-Csv "entra_hardmatch_risk.csv" -NoTypeInformation
# ШАГ 3: Если нашли проблемные аккаунты — два варианта:
# Вариант A: Убрать Entra-роль с синхронизированного пользователя
# и назначить cloud-only аккаунту (правильный путь)
# Вариант B: Убедиться что AD-объект с таким sourceAnchor
# уже синхронизирован (тогда блокировка не сработает —
# блокирует только НОВЫЕ hard-match попытки)
# ШАГ 4: Тест синхронизации (запускаем и смотрим ошибки):
Start-ADSyncSyncCycle -PolicyType Delta
Get-ADSyncConnectorRunStatus | Format-Table -AutoSize
Зачем это критично прямо сейчас: если после 1 июня синхронизация попытается hard-match привилегированный аккаунт — она упадёт с ошибкой. Это может заблокировать lifecycle-операции: создание аккаунтов, обновления, отключения. В разгар рабочего дня.
Итог: два действия до пятницы. Проверить версию Entra Connect (должна быть 2.5.79.0+). Запустить скрипт поиска проблемных аккаунтов. Шесть дней — достаточно если начать сейчас.
#windows #entra #activedirectory #hybrididentity #security #sysadmin #admin_future | 81 |
| 18 | 🐧 Linux: CVE-2026-46333 — Qualys опубликовала четыре рабочих эксплойта. Меняем shadow.
Коллеги, вчера Qualys опубликовала полный технический разбор CVE-2026-46333 с деталями которые меняют оценку риска. Это не просто "чтение SSH-ключей" — это четыре разных вектора атаки.
Qualys построила четыре рабочих эксплойта: через chage (раскрывает /etc/shadow), ssh-keysign (раскрывает приватные host-ключи в /etc/ssh/), pkexec (выполняет произвольные команды как root), accounts-daemon (выполняет произвольные команды как root). Все подтверждены на дефолтных установках Debian 13, Ubuntu 24.04, Ubuntu 26.04, Fedora 43 и Fedora 44.
Уязвимость важна потому что современные атаки редко останавливаются на первом плацдарме. RCE работающий как www-data, скомпрометированный CI-джоб, украденный аккаунт разработчика — изначально не root. Локальный баг ядра который читает root-секреты превращает этот плацдарм в кражу учётных данных, имперсонацию хоста или lateral movement.
# ПАТЧ ЕСТЬ — проверяем прямо сейчас:
uname -r
# Патч в коммите Линуса "ptrace: slightly saner get_dumpable() logic"
# Закрыт в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 5.15.207 / 5.10.256
# Обновляем если старее:
apt update && apt full-upgrade -y && reboot # Ubuntu/Debian
dnf update kernel -y && reboot # RHEL/Rocky/AlmaLinux
# ЕСЛИ НА ХОСТЕ БЫЛИ ЛОКАЛЬНЫЕ ПОЛЬЗОВАТЕЛИ В МАЕ:
# 1. Ротируем SSH host keys:
rm /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub
ssh-keygen -A
systemctl restart sshd
# 2. Ротируем пароли учёток из /etc/shadow:
# (shadow мог быть прочитан через chage-эксплойт)
# Минимум — все системные аккаунты с shell:
awk -F: '$7 !~ /nologin|false/ && $3 >= 1000 {print $1}' \
/etc/passwd | while read u; do passwd --expire $u; done
# 3. Митигейшн если патч ещё не применён:
echo "kernel.yama.ptrace_scope = 2" >> \
/etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope=2: только root может ptrace непривилегированных процессов
Зачем ротировать именно shadow и SSH-ключи: в shared-hosting среде разница между раскрытием учётных данных и прямым root-доступом практически отсутствует — любого из этих файлов атакующему достаточно чтобы пройти весь оставшийся путь.
Итог: патч + перезагрузка. Если были локальные пользователи в мае — SSH host keys и пароли из shadow считай скомпрометированными. Ротация — это 10 минут работы.
#linux #cve #ssh #kernel #security #sysadmin #admin_future | 70 |
| 19 | 🧠 Skills: Конец мая — как правильно уйти в отпуск не оставив коллег в огне
Коллеги, впереди лето. Июнь — традиционно сезон отпусков в IT-командах. И традиционно — сезон когда оказывается что только один человек знал как перезапустить критичный сервис.
Разбираем как уходить в отпуск профессионально — чтобы не звонили, и чтобы инфраструктура не горела.
Три вещи которые нужно сделать до отпуска:
ЗА ДВЕ НЕДЕЛИ ДО ОТПУСКА:
1. HANDOFF DOCUMENT — не "я на связи если что"
Шаблон:
# Handoff: [Твоё имя], отпуск [дата] — [дата]
## Контакт на период отпуска
Технические вопросы: [коллега] @username
Срочные инциденты: [тимлид] +7-xxx-xxx
Меня беспокоить: только P1 который не может закрыть команда
## Что сейчас в работе
- [Задача 1]: статус, следующий шаг, кто может продолжить
- [Задача 2]: заморожено до моего возвращения, ничего срочного
## Критичные сервисы и где runbook
- Nginx кластер: runbook в Confluence/RB-WEB-001
- PostgreSQL backup: автоматический, крон в /etc/cron.d/pg_backup
- VPN сервер: если упал — runbook RB-NET-003, ключи у [коллега]
## Что НЕ трогать пока меня нет
- Не обновлять ядро на prod до моего возвращения (RC4 июль!)
- Не менять Kerberos политики (тестирование ещё не завершено)
- Secure Boot update — запущен, ждём статус "Updated" сам придёт
## Алерты и мониторинг
Grafana alerts идут в #infra-alerts Slack
PagerDuty ротация: [коллега] primary на период моего отпуска
2. ПРОВЕРЬ CRITICAL TASKS С ДЕДЛАЙНОМ
В июне: Secure Boot (истекает июнь), Entra hard match (1 июня)
Убедись что эти задачи либо закрыты ДО отпуска
либо передал конкретному человеку с конкретным дедлайном
3. АВТОМАТИЗИРУЙ ЧТО МОЖЕТ СЛОМАТЬСЯ БЕЗ ТЕБЯ
Если что-то требует ручного вмешательства каждую неделю —
это не надёжно для отпуска и не надёжно вообще.
Одна задача автоматизации до отпуска > десяти звонков из него.
Один честный разговор с руководителем до отпуска:
Не "я ухожу, вы справитесь". А "вот три вещи которые могут потребовать внимания, вот кто их закроет, вот как их закрыть". Это занимает 15 минут встречи — и даёт тебе настоящий отпуск, а не режим "в отпуске но на связи".
Зачем это важно для профессии:
Администратор который не может уйти в отпуск без звонков — это признак Bus Factor = 1. Это риск для бизнеса, это проблема команды, и это признак что документация и автоматизация не доделаны. Не геройство. Проблема.
Итог: до отпуска — handoff документ, закрытые июньские дедлайны, передача PagerDuty. После — выключить рабочий чат. Хороших выходных, коллеги. Май позади.
#skills #отпуск #команда #документация #sysadmin #admin_future | 73 |
| 20 | 🪟 Windows: Server vNext build 29585 — что нового и почему ReFS Boot важнее чем звучит
Коллеги, Microsoft выпустила Windows Server vNext Preview Build 29585 — последний перед летним затишьем. Разбираем что важно для тех кто следит за следующим поколением.
ReFS Boot включён по умолчанию для всех vNext preview builds. При этом ReFS Boot системы создают минимальный WinRE раздел в 2GB. Когда WinRE не может быть обновлён из-за нехватки места — система может отключить WinRE. Отключение WinRE не удаляет раздел. Но если WinRE раздел удалить и расширить boot volume поверх него — это действие необратимо без чистой установки.
Это важно понимать заранее: ReFS Boot — это фундамент для Quick Machine Recovery (QMR). Без WinRE раздела QMR не работает. Удалить раздел в попытке освободить место = потерять возможность самовосстановления сервера.
Что ещё в 29585:
Quick Machine Recovery теперь доступен для тестирования в vNext Insider Previews. Функция обеспечивает восстановление серверов при критических ошибках загрузки — QMR может автоматически искать облачные исправления для устранения массовых загрузочных сбоев, значительно снижая нагрузку на IT-администраторов когда одновременно затронуты несколько устройств.
# Для тех кто тестирует vNext в лабе:
# Проверяем текущий build:
winver
# или
Get-ComputerInfo | Select-Object WindowsBuildLabEx
# Проверяем статус ReFS Boot:
Get-Partition | Where-Object {$_.Type -eq "Recovery"} |
Select-Object DiskNumber, PartitionNumber, Size, Type
# Проверяем размер WinRE раздела (должен быть >= 2GB для ReFS Boot):
reagentc.exe /info
# Ищем: Windows RE location и размер
# КРИТИЧНО: НЕ УДАЛЯТЬ WinRE раздел на vNext builds
# Проверяем что он не будет затронут при расширении диска:
Get-Partition -DiskNumber 0 | Format-Table -AutoSize
# Тестируем QMR в lab (не на продакшне):
# reagentc.exe /setrecoverytestmode
# Перезагружаемся — система войдёт в WinRE и попытается найти remediation
# Для перехода с preview < 29531:
# Апгрейд НЕ поддерживается — только чистая установка
# Дедлайн использования preview: 15 сентября 2026
Зачем следить за vNext прямо сейчас: preview builds доступны до 15 сентября 2026. Если планируешь переход на следующую версию Windows Server — сейчас идеальный момент поднять тестовый стенд, изучить ReFS Boot поведение и QMR до того как это появится в GA.
Итог: ReFS Boot + QMR = будущее Windows Server recovery. Но WinRE раздел священен — не трогать, не уменьшать, не удалять. Запомни это до GA.
#windows #windowsserver #vnext #refs #qmr #sysadmin #admin_future | 65 |
