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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🐧 Linux: CVE-2026-46333 — Qualys опубликовала полный advisory. Ротируй SSH-ключи.

Коллеги, свежие подробности по уязвимости, которую разбирали на этой неделе. Qualys Threat Research Unit опубликовала полный технический advisory по CVE-2026-46333, и там есть детали которые меняют оценку риска.

TRU идентифицировала узкое окно в котором привилегированный процесс, сбрасывающий свои учётные данные, остаётся доступным через ptrace-операции даже когда флаг dumpable должен был закрыть этот путь. Комбинируя это окно с системным вызовом pidfd_getfd() (добавленным в ядро в январе 2020), атакующий может перехватить открытые файловые дескрипторы умирающего привилегированного процесса и унаследовать его доступ к файлам — включая приватные SSH-ключи хоста.

На хостах где в период уязвимости были непривилегированные пользователи — SSH host keys и локально кэшированные учётные данные следует считать потенциально раскрытыми. Qualys рекомендует ротировать host keys и проверить весь административный материал находившийся в памяти setuid-процессов.

# ШАГ 1: Патч уже есть — проверяем версию ядра
uname -r
# Патч в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207
# Если старше — обновляем НЕМЕДЛЕННО:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot                # RHEL/Rocky/AlmaLinux

# ШАГ 2: Была ли уязвимость активна? Смотрим были ли local users:
last | grep -v "^reboot\|^wtmp" | \
    awk '{print $1}' | sort -u
# Если только root — риск ниже. Если были другие — ротируем ключи.

# ШАГ 3: Ротация SSH host keys (если есть подозрение на компрометацию):
# Генерируем новые ключи:
rm /etc/ssh/ssh_host_*
ssh-keygen -A
# Перезапускаем SSH (NOT текущую сессию — откроем новую первой):
systemctl restart sshd

# Обновляем known_hosts на всех клиентах:
ssh-keyscan -H <server_ip> >> ~/.ssh/known_hosts

# ШАГ 4: Митигейшн если патч ещё не применён:
# ptrace_scope = 2 блокирует только root может ptrace непривилегированных
echo "kernel.yama.ptrace_scope = 2" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope = 3 — полный запрет (ломает отладчики, gdb, strace)

Также на неделе вышла PinTheft — отдельный LPE для Arch Linux систем. Если у тебя есть Arch в продакшне (надеюсь что нет) — смотри отдельный advisory.

Итог: если на хосте были local users в мае — ротируй SSH-ключи. Это 3 минуты работы и полное закрытие вектора постэксплуатации.

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

🪟 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

🧠 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

🐧 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

🪟 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

🧠 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

🐧 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

🪟 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