🐧 Linux: Хватит терпеть зависания при OOM. Включаем PSI и systemd-oomd
Коллеги, добрый понедельник. Знакомая ситуация: на сервере потекла память, своп забился, load average улетел в космос, и вы даже по SSH зайти не можете. Классический OOM Killer в ядре срабатывает слишком поздно, когда система уже фактически в коме.
В 2026 году мы решаем это изящнее. Мы используем PSI (Pressure Stall Information) вместе с systemd-oomd. Этот демон убивает прожорливые cgroups ДО того, как операционная система намертво повиснет.
Скрипт для проверки и активации:
Зачем это нужно:
Сервер должен оставаться управляемым при любых утечках памяти. Лучше пусть упадет один проблемный контейнер или веб-сервис, чем вся нода уйдет в hard reset по питанию, утащив за собой соседние процессы.
#linux #systemd #oom #performance #sysadmin #admin_future
Коллеги, добрый понедельник. Знакомая ситуация: на сервере потекла память, своп забился, 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
🪟 Windows: SMB over QUIC — убиваем VPN для файловых шар
Коллеги, вчера мы ждали новых сюрпризов от Nightmare Eclipse (обещанный дроп 14 июня), но пока эфир относительно чист. Зато есть повод поговорить о хорошем. Больше никаких пробросов порта 445 и обязательных корпоративных VPN для доступа к рабочим файлам из дома.
В Windows Server 2025 технология SMB over QUIC окончательно стала мейнстримом. QUIC работает поверх протокола UDP (порт 443). Трафик всегда зашифрован TLS 1.3, провайдеры его не режут, а скорость при плохом мобильном интернете в разы выше классического TCP.
Как настроить в PowerShell:
Зачем это нужно:
Пользователи получают доступ к корпоративным шарам так же просто, как к облачному диску. А безопасники спят спокойно, потому что наружу торчит только стандартный 443 UDP порт, а не дырявый 445 TCP, который обожают шифровальщики.
#windows #windowsserver #quic #networking #sysadmin #admin_future
Коллеги, вчера мы ждали новых сюрпризов от 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
🧠 Skills: Усталость от алертов. Как Zabbix убивает вашу внимательность
Коллеги, если в вашей дежурной группе в Telegram каждый день сыпятся десятки сообщений "CPU Load is > 80%" или "Disk space < 20%", и вы их просто смахиваете, не читая — у вас серьезная проблема. Это называется Alert Fatigue (усталость от предупреждений).
В 2026 году мониторинг не должен быть логом событий. Алерт должен приходить ТОЛЬКО тогда, когда требуется немедленное действие живого человека.
Внедряем правило 3 вопросов для настройки любого триггера:
Это влияет на бизнес прямо сейчас?
Я должен бросить свой кофе и чинить это немедленно?
Если я проигнорирую это до завтрашнего утра, кто-то заметит?
Если хотя бы на один вопрос ответ "Нет" — смело переводим этот триггер в разрез инфо-дашбордов или утренних отчетов. Никаких пуш-уведомлений и красных значков.
Зачем это нужно:
Когда случится настоящий сбой (например, дропнется RAID-массив в проде), вы можете просто пропустить этот критический алерт между пятьюдесятью рядовыми сообщениями о высокой загрузке процессора на тестовом контуре. Тишина в канале мониторинга — это признак здоровой инфраструктуры и здоровой психики администратора.
#skills #monitoring #zabbix #management #sysadmin #admin_future
Коллеги, если в вашей дежурной группе в Telegram каждый день сыпятся десятки сообщений "CPU Load is > 80%" или "Disk space < 20%", и вы их просто смахиваете, не читая — у вас серьезная проблема. Это называется Alert Fatigue (усталость от предупреждений).
В 2026 году мониторинг не должен быть логом событий. Алерт должен приходить ТОЛЬКО тогда, когда требуется немедленное действие живого человека.
Внедряем правило 3 вопросов для настройки любого триггера:
Это влияет на бизнес прямо сейчас?
Я должен бросить свой кофе и чинить это немедленно?
Если я проигнорирую это до завтрашнего утра, кто-то заметит?
Если хотя бы на один вопрос ответ "Нет" — смело переводим этот триггер в разрез инфо-дашбордов или утренних отчетов. Никаких пуш-уведомлений и красных значков.
Зачем это нужно:
Когда случится настоящий сбой (например, дропнется RAID-массив в проде), вы можете просто пропустить этот критический алерт между пятьюдесятью рядовыми сообщениями о высокой загрузке процессора на тестовом контуре. Тишина в канале мониторинга — это признак здоровой инфраструктуры и здоровой психики администратора.
#skills #monitoring #zabbix #management #sysadmin #admin_future
👍4
🐧 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 потребуют быстрого рестарта для подхвата криптографических улучшений.
Итог: неделя 24 — про дисциплину процесса, не про панику. Snapshot перед апдейтом, проверка DKMS, перезагрузка в окно, верификация сервисов после. Samba — приоритет, ransomware любит непропатченный SMB.
#linux #kernel #samba #patching #security #sysadmin #admin_future
Коллеги, добрый понедельник. После июньского рекордного хаоса на стороне 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
🪟 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.
Зачем не расслабляться несмотря на смягчение: десктопная версия этой истории раздражающая. Серверная — операционно серьёзная. Окружения Windows Server 2016, 2019, 2022 и 2025 могут быть затронуты, и путь к исправлению сложнее чем «нажми обновить и перезагрузись».
Итог: 24 июня — не катастрофа, а начало деградации защиты. DB-сертификат живёт до октября, это буфер. Но запусти обновление на NOT_STARTED серверах на этой неделе — процесс занимает двое суток.
#windows #secureboot #windowsserver #security #sysadmin #admin_future
Коллеги, это последний понедельник перед дедлайном 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
🧠 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 живым: хорошая документация должна непрерывно эволюционировать вместе с кодом который она описывает. Правило простое — изменил инфраструктуру, обнови doc в том же PR. Не «потом», а в том же коммите. Review не пропускает PR без обновления документации.
Зачем это сисадмину а не только разработчику: твои runbook, топология сети, процедуры onboarding — это и есть код инфраструктуры. В git они версионируются, ревьюятся, и главное — видно кто и когда менял. Confluence этого не даёт.
Итог: MkDocs + Gitea + правило «doc в том же PR» = документация которая не устаревает. Это вечер настройки и смена привычки. Попробуй на одном runbook на этой неделе.
#skills #docsascode #документация #mkdocs #git #sysadmin #admin_future
Коллеги, понедельник — хороший день для темы которая отделяет зрелые инфраструктуры от хаотичных. Документация.
Главная боль технической документации известна каждому: во-первых, её нет. Во-вторых, если она есть — она не актуальна. 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
❤3👍2
🐧 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 серверы его не несут — такие хосты не уязвимы. Проверьте флот перед действиями.
Зачем это важно как тренд: 19-летний возраст уязвимого кода и наличие публичного PoC означают что эксплуатация в дикой природе вероятна. Организациям не стоит ждать подтверждённых атак перед применением митигейшна.
Итог: проверь установлен ли cifs-utils. Нет — не уязвим. Есть — патч (уже в репах) или удали cifs-utils если SMB не нужен. Шестой LPE за год — паттерн очевиден.
#linux #kernel #cifswitch #cve #security #sysadmin #admin_future
Коллеги, добрая среда. Шестой 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
🪟 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 закрывает целый класс пассивной разведки в сети.
Итог: июньское обновление это не только 206 CVE и Secure Boot. Это DoH server-side GA + фикс апрельской BitLocker-проблемы. Подними DoH в лабе на этой неделе — это базовая гигиена которую долго ждали в Windows Server.
#windows #dns #doh #windowsserver2025 #security #sysadmin #admin_future
Коллеги, в июньском обновлении 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
❤2
🧠 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" в "плановую работу":
Один честный вопрос для среды:
Возьми 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
Коллеги, среда — день для стратегического взгляда. 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
🐧 Linux: Atomic Arch — 1500 AUR-пакетов с rootkit. Это не про Arch, это про доверие
Коллеги, 11 июня в сообществе Arch Linux произошло кое-что важное для всех — даже для тех, кто никогда не видел pacman. Потому что этот инцидент — учебник по современным supply chain атакам.
Атакующие систематически брали под контроль брошенные AUR-пакеты — проекты, покинутые оригинальными мейнтейнерами — и модифицировали их сборочные скрипты. Пакеты сохранили свои имена, историю и доверие пользователей. Изменились только инструкции сборки.
Masштаб: более 1500 пакетов скомпрометировано. Вредоносные PKGBUILD были изменены для тихой загрузки и установки двух npm-пакетов: atomic-lockfile и js-digest. Эти пакеты разворачивали Rust-написанный credential stealer, нацеленный на SSH-ключи, API токены, браузерные сессии, docker credentials и cloud API keys.
Особенность которая усложняет очистку: при получении root малварь загружает eBPF-руткит. Три BPF maps в /sys/fs/bpf/ управляют тем что скрыто: hidden_pids удаляет процессы из ps, hidden_names прячет файлы из ls, hidden_inodes скрывает по inode. Руткит также блокирует присоединение отладчика.
Почему это важно для всех а не только для Arch-пользователей: атакующим больше не нужно строить доверие с нуля. Они его покупают — захватывая проекты которые уже заслужили его. Это кардинально снижает предупреждающие сигналы, на которые разработчики обычно полагаются при оценке ПО.
Тот же вектор работает в npm (orphaned packages), PyPI, Cargo. Проверяй orphaned packages и пакеты с недавней сменой мейнтейнера в любом реестре.
Итог: любой AUR-пакет установленный между 11-12 июня — под вопросом. Если нашёл затронутый — считай систему полностью скомпрометированной и ротируй credentials. Пакет-менеджером это не починить.
#linux #supplychain #arch #aur #security #sysadmin #admin_future
Коллеги, 11 июня в сообществе Arch Linux произошло кое-что важное для всех — даже для тех, кто никогда не видел pacman. Потому что этот инцидент — учебник по современным supply chain атакам.
Атакующие систематически брали под контроль брошенные AUR-пакеты — проекты, покинутые оригинальными мейнтейнерами — и модифицировали их сборочные скрипты. Пакеты сохранили свои имена, историю и доверие пользователей. Изменились только инструкции сборки.
Masштаб: более 1500 пакетов скомпрометировано. Вредоносные PKGBUILD были изменены для тихой загрузки и установки двух npm-пакетов: atomic-lockfile и js-digest. Эти пакеты разворачивали Rust-написанный credential stealer, нацеленный на SSH-ключи, API токены, браузерные сессии, docker credentials и cloud API keys.
Особенность которая усложняет очистку: при получении root малварь загружает eBPF-руткит. Три BPF maps в /sys/fs/bpf/ управляют тем что скрыто: hidden_pids удаляет процессы из ps, hidden_names прячет файлы из ls, hidden_inodes скрывает по inode. Руткит также блокирует присоединение отладчика.
# Если у тебя есть Arch или Arch-based в инфраструктуре:
# 1. Проверяем установленные AUR-пакеты:
pacman -Qm # Список всех foreign (AUR) пакетов
# Сверяем с известными затронутыми: md.archlinux.org/s/SxbqukK6IA
# 2. Проверяем установки ПОСЛЕ 11 июня:
grep "installed" /var/log/pacman.log | \
awk -F '[][]' '{print $2, $4}' | \
awk '$1 >= "2026-06-11"' | head -30
# 3. Проверяем наличие eBPF rootkit:
ls /sys/fs/bpf/ 2>/dev/null
# Подозрительные: hidden_pids, hidden_names, hidden_inodes
# 4. Если затронутый пакет установлен — TREAT AS COMPROMISED:
# НЕ просто удали пакет — руткит уже выполнился
# Шаги:
# - Изоли систему от сети
# - Сразу ротируй ВСЕ credentials с другой машины:
# SSH keys, GitHub PATs, npm tokens, AWS/GCP/Azure credentials
# Docker registry tokens, всё в .env файлах, shell history
# - Загрузись с Arch ISO, проверь /etc/systemd/system/ на лишние юниты
# - Всерьёз рассмотри полную переустановку
# 5. Превентивные меры для будущего:
# В makepkg.conf — всегда просматривать PKGBUILD перед сборкой
export PKGBUILD_REVIEW=1
# Или использовать paru с --fm для просмотра через файловый менеджер:
paru -S --fm nvim package_name
Почему это важно для всех а не только для Arch-пользователей: атакующим больше не нужно строить доверие с нуля. Они его покупают — захватывая проекты которые уже заслужили его. Это кардинально снижает предупреждающие сигналы, на которые разработчики обычно полагаются при оценке ПО.
Тот же вектор работает в npm (orphaned packages), PyPI, Cargo. Проверяй orphaned packages и пакеты с недавней сменой мейнтейнера в любом реестре.
Итог: любой AUR-пакет установленный между 11-12 июня — под вопросом. Если нашёл затронутый — считай систему полностью скомпрометированной и ротируй credentials. Пакет-менеджером это не починить.
#linux #supplychain #arch #aur #security #sysadmin #admin_future
🪟 Windows: KEK CA 2011 истёк вчера. Что реально изменилось и что делать сегодня.
Коллеги, вчера 24 июня — дата которую мы отслеживали несколько месяцев. Microsoft Corporation KEK CA 2011 официально истёк 24 июня 2026. Следующий — Microsoft Corporation UEFI CA 2011 — истекает 27 июня, то есть послезавтра. Microsoft Windows Production PCA 2011 — в октябре 2026.
Главный вопрос — что реально произошло с теми кто не успел:
Устройства без новых сертификатов продолжат загружаться и работать нормально. Стандартные обновления Windows продолжат устанавливаться. Единственное что изменилось: эти устройства больше не смогут получать новые меры защиты раннего процесса загрузки — обновления Windows Boot Manager, базы данных Secure Boot, списки отзыва, и mitigation-ы для вновь обнаруженных boot-level уязвимостей.
Это не катастрофа сегодня. Это деградация защиты со временем. Новые сертификаты действительны до 2038 года. Отдельный переход на постквантовую криптографию запланирован примерно на 2030 год для будущего железа.
Что делать прямо сейчас:
Зачем всё ещё важно действовать: устройства пропустившие переход потеряют способность получать boot-level security апдейты. Не произойдёт ничего мгновенного. Но со временем это означает отсутствие новых DBX-блокировок (защита от буткитов), невозможность установки новых Windows feature updates, и растущую экспозицию к boot-level атакам.
Итог: вчерашняя дата — не конец света, но точка невозврата для boot security. Проверь статус сегодня. Обновление запускается за минуту, процесс — 48 часов. До следующего KEK в 2038 — не хочется повторять этот квест.
#windows #secureboot #windowsserver #security #sysadmin #admin_future
Коллеги, вчера 24 июня — дата которую мы отслеживали несколько месяцев. Microsoft Corporation KEK CA 2011 официально истёк 24 июня 2026. Следующий — Microsoft Corporation UEFI CA 2011 — истекает 27 июня, то есть послезавтра. Microsoft Windows Production PCA 2011 — в октябре 2026.
Главный вопрос — что реально произошло с теми кто не успел:
Устройства без новых сертификатов продолжат загружаться и работать нормально. Стандартные обновления Windows продолжат устанавливаться. Единственное что изменилось: эти устройства больше не смогут получать новые меры защиты раннего процесса загрузки — обновления Windows Boot Manager, базы данных Secure Boot, списки отзыва, и mitigation-ы для вновь обнаруженных boot-level уязвимостей.
Это не катастрофа сегодня. Это деградация защиты со временем. Новые сертификаты действительны до 2038 года. Отдельный переход на постквантовую криптографию запланирован примерно на 2030 год для будущего железа.
Что делать прямо сейчас:
# 1. ПРОВЕРЯЕМ СТАТУС — что по факту с сертификатами:
# Через новый UI (появился с апрельским обновлением):
# Settings -> Privacy & Security -> Windows Security -> Device Security
# Ищем статус Secure Boot — зелёная галочка = порядок
# Через PowerShell — проверяем наличие 2023-сертификатов:
Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -EA SilentlyContinue
# NOT_STARTED/отсутствует = сертификаты не обновлены
# Updated = сертификаты 2023 года установлены
# 2. ДЛЯ НЕ ОБНОВЛЁННЫХ СЕРВЕРОВ — запускаем обновление:
# Через scheduled task:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Процесс занимает ~48 часов и 1-2 перезагрузки
# Через реестр (если task не запускается):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot" `
/v AvailableUpdates /t REG_DWORD /d 0x5944 /f
# 3. ПРОВЕРЯЕМ ИЮНЬСКИЙ ПАТЧ — он привёз новую GPO и доп.фиксы:
Get-HotFix -Id KB5094125 # Windows Server 2025
Get-HotFix -Id KB5094128 # Windows Server 2022
# 4. НОВАЯ GPO из июньского обновления:
# Computer Config -> Admin Templates -> Windows Components -> Secure Boot
# -> LimitSecureBootRequiredServiceData
# Ограничивает телеметрию Secure Boot в Microsoft
# 5. МАССОВЫЙ АУДИТ — быстрый срез статуса по флоту:
$servers = (Get-ADComputer -Filter {OperatingSystem -like "*Server*"}).Name
$report = Invoke-Command -ComputerName $servers -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 SilentlyContinue
$report | Group-Object Status | Format-Table Name, Count
Зачем всё ещё важно действовать: устройства пропустившие переход потеряют способность получать boot-level security апдейты. Не произойдёт ничего мгновенного. Но со временем это означает отсутствие новых DBX-блокировок (защита от буткитов), невозможность установки новых Windows feature updates, и растущую экспозицию к boot-level атакам.
Итог: вчерашняя дата — не конец света, но точка невозврата для boot security. Проверь статус сегодня. Обновление запускается за минуту, процесс — 48 часов. До следующего KEK в 2038 — не хочется повторять этот квест.
#windows #secureboot #windowsserver #security #sysadmin #admin_future
🧠 Skills: Первое полугодие 2026 — честный итог и три вывода для второго
Коллеги, четверг 25 июня — последний четверг первого полугодия. Хороший момент для честного разбора не "что мы патчили", а "чему мы научились".
Шесть месяцев которые изменили ландшафт:
Январь-февраль: тихое начало, накопление. Март: выходит Linux 7.0. Апрель: KB5082063 ломает DC, BitLocker recovery, Kerberos RC4 enforcement. Май: Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt, CVE-2026-46333, CIFSwitch — шесть LPE за три недели. Июнь: рекордный Patch Tuesday (206 CVE), Atomic Arch, Secure Boot KEK истёк.
Три честных вывода:
Практическое действие на сегодня — квартальный чеклист H2:
Итог: первое полугодие 2026 было хаотичным. Второе будет другим — только если первую неделю июля потратить на систематизацию, а не на дожигание старых пожаров. Занеси дедлайны в трекер. Это и есть разница между реактивным и проактивным администрированием.
Хорошего конца полугодия, коллеги. Вы справились с майским марафоном. Теперь — готовимся к следующему.
#skills #итоги #полугодие #планирование #sysadmin #admin_future
Коллеги, четверг 25 июня — последний четверг первого полугодия. Хороший момент для честного разбора не "что мы патчили", а "чему мы научились".
Шесть месяцев которые изменили ландшафт:
Январь-февраль: тихое начало, накопление. Март: выходит Linux 7.0. Апрель: KB5082063 ломает DC, BitLocker recovery, Kerberos RC4 enforcement. Май: Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt, CVE-2026-46333, CIFSwitch — шесть LPE за три недели. Июнь: рекордный Patch Tuesday (206 CVE), Atomic Arch, Secure Boot KEK истёк.
Три честных вывода:
ВЫВОД 1: AI-ASSISTED VULNERABILITY RESEARCH ИЗМЕНИЛ ТЕМП
CVE-ев в ядре Linux за 2026 год уже больше чем за весь 2018-й.
Это не потому что ядро стало хуже — это потому что LLM находят
баги в 10 раз быстрее чем ручной code review.
Что это означает для нас:
- Reactive patching больше не работает как стратегия
- Нужны системы которые защищают ДО раскрытия конкретной CVE
(ModuleJail, LKRG, AppArmor enforce, namespace restrictions)
- Окно между раскрытием и эксплуатацией сократилось до часов
ВЫВОД 2: SUPPLY CHAIN — НОВЫЙ ПЕРИМЕТР
Atomic Arch показал: атаки больше не идут напролом.
Они наследуют доверие через orphaned packages, compromised
maintainers, зависимости в зависимостях.
Что это означает для нас:
- Любой пакет из community-репозитория (AUR, npm, PyPI)
должен проходить проверку PKGBUILD/install hooks
- Контролируемые зеркала внутри компании > прямой доступ к AUR
- Credential rotation после любого подозрительного события —
не "посмотрим" а "немедленно"
ВЫВОД 3: ДЕДЛАЙНЫ НАКАПЛИВАЛИСЬ — И БУДУТ НАКАПЛИВАТЬСЯ
H1 2026: Entra Connect 2.5.79.0 (30 сентября)
Entra hard match (1 июня — прошло)
Secure Boot KEK (24 июня — вчера)
Kerberos RC4 enforcement (июль)
Windows Server 2016 EOL (январь 2027)
H2 2026 уже несёт свои дедлайны. Они не ждут.
Что это означает для нас:
Нужна система отслеживания дедлайнов — не в голове,
не в почте, а в трекере с дейтами и owner-ами.
EOL-трекер (endoflife.date), Microsoft roadmap,
RHEL lifecycle calendar — три источника которые дают
дедлайны заранее, а не когда уже горит.
Практическое действие на сегодня — квартальный чеклист H2:
H2 2026 ДЕДЛАЙНЫ — ЗАНЕСИ В ТРЕКЕР ПРЯМО СЕЙЧАС:
[ ] Июль 2026: Kerberos RC4 finalization
→ Аудит Event 201/202 на DC, ротация паролей учёток без AES
[ ] 30 сентября 2026: Entra Connect <= 2.5.79.0 перестаёт работать
→ Проверить версию: Get-ADSyncGlobalSettings | Select Version
[ ] Октябрь 2026: Microsoft Windows Production PCA 2011 истекает
→ Проверить статус Secure Boot на оставшихся серверах
[ ] Январь 2027: Windows Server 2016 EOL
→ Инвентаризация: Get-ADComputer -Filter {OS -like "*2016*"}
→ Если больше 20 серверов — план миграции нужен вчера
[ ] Постоянно: endoflife.date для OpenSSL, PostgreSQL, Python, nginx
Итог: первое полугодие 2026 было хаотичным. Второе будет другим — только если первую неделю июля потратить на систематизацию, а не на дожигание старых пожаров. Занеси дедлайны в трекер. Это и есть разница между реактивным и проактивным администрированием.
Хорошего конца полугодия, коллеги. Вы справились с майским марафоном. Теперь — готовимся к следующему.
#skills #итоги #полугодие #планирование #sysadmin #admin_future
Получите по 200₽ за каждого, кто выберет Яндекс Поиск и будет в нём искать.
Каждый из ваших друзей — 300₽ за участие.
https://yandex.ru/bonus/xx2DfIa
Каждый из ваших друзей — 300₽ за участие.
https://yandex.ru/bonus/xx2DfIa
🐧 Linux: Bad Epoll — новый LPE из 2026-го, патч вышел 2 июля. Обновляемся.
Коллеги, добрый понедельник и добро пожаловать во второе полугодие. Начинаем не с отдыха — с нового LPE.
CVE-2026-46242 «Bad Epoll» — очередной локальный побег в root, опубликованный на прошлой неделе. Уязвимость затрагивает Linux-десктопы, серверы и Android-устройства, патч доступен. Параллельно Greg Kroah-Hartman анонсировал стабильные ядра 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260, включающие фикс для уязвимости в IPv6 (CVE-2026-53362), позволявшей атакующему выбраться из контейнера и получить root, и use-after-free в KVM (CVE-2026-53359), появившегося ещё в ядре 2.6.36.
Это уже восьмой по счёту публичный LPE в ядре Linux с начала года.
Администраторам следует приоритизировать применение обновлений ядра и glibc немедленно, так как эти компоненты лежат в основе большинства затронутых сервисов на всех дистрибутивах.
Итог: восемь LPE за полгода — это новая реальность. Автоматизированный patch pipeline это уже не nice-to-have, это гигиена. Обновляем ядро и glibc сегодня.
#linux #kernel #cve #badepoll #lpe #security #sysadmin #admin_future
Коллеги, добрый понедельник и добро пожаловать во второе полугодие. Начинаем не с отдыха — с нового LPE.
CVE-2026-46242 «Bad Epoll» — очередной локальный побег в root, опубликованный на прошлой неделе. Уязвимость затрагивает Linux-десктопы, серверы и Android-устройства, патч доступен. Параллельно Greg Kroah-Hartman анонсировал стабильные ядра 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260, включающие фикс для уязвимости в IPv6 (CVE-2026-53362), позволявшей атакующему выбраться из контейнера и получить root, и use-after-free в KVM (CVE-2026-53359), появившегося ещё в ядре 2.6.36.
Это уже восьмой по счёту публичный LPE в ядре Linux с начала года.
# Проверяем версию ядра — нужны 7.1.3 / 6.18.38 / 6.12.95+:
uname -r
# Обновляем немедленно:
apt update && apt full-upgrade -y && reboot # Ubuntu/Debian
dnf update kernel -y && reboot # RHEL/Rocky/AlmaLinux
# Дополнительно: CVE-2026-53362 — IPv6 container escape
# Если используете cgroups v1 (более старые среды):
cat /sys/fs/cgroup/cgroup.controllers 2>/dev/null
# Пусто = cgroups v2 (безопаснее), если есть вывод — v1 активен
# Проверяем есть ли cgroups v1 в контейнерных средах:
cat /proc/1/cgroup | head -5
# CISA также добавила CVE-2022-0492 в KEV:
# cgroup_release_agent_write() — container escape через cgroups v1
# Затрагивает ядра 2.6 - 4.20 и 5.5 - 5.17
# Если у тебя в контейнерах cgroups v1 — это активный вектор
# Принудительный переход на cgroups v2 (ломает часть legacy):
# В /etc/default/grub добавить в GRUB_CMDLINE_LINUX:
# systemd.unified_cgroup_hierarchy=1
# update-grub && reboot
# Неделя 27 — также критичные обновления для glibc и nginx:
apt-get install --only-upgrade nginx glibc-source libglib2.0-0 2>/dev/null
dnf update glibc nginx -y 2>/dev/null
Администраторам следует приоритизировать применение обновлений ядра и glibc немедленно, так как эти компоненты лежат в основе большинства затронутых сервисов на всех дистрибутивах.
Итог: восемь LPE за полгода — это новая реальность. Автоматизированный patch pipeline это уже не nice-to-have, это гигиена. Обновляем ядро и glibc сегодня.
#linux #kernel #cve #badepoll #lpe #security #sysadmin #admin_future
🪟 Windows: RoguePlanet без патча + July 14 Patch Tuesday через неделю. Готовимся.
Коллеги, июнь оставил нам незакрытый хвост — и следующая неделя обещает быть жаркой.
Ситуация: RoguePlanet (CVE-2026-50656) — эксплойт Nightmare Eclipse против Microsoft Defender, позволяющий локальному атакующему получить SYSTEM-привилегии на полностью пропатченных Windows 10 и 11. Microsoft подтвердила уязвимость и работает над патчем, но сроков не назвала.
Эксплойт начинается с записи EICAR-файла в фейковый wermgr.exe для триггера ремедиации Defender. Отслеживая новое HardDiskVolumeShadowCopy-устройство, атакующий использует опортунистическую блокировку и выигрывает race condition. В результате C:\Windows\System32\wermgr.exe заменяется копией RoguePlanet, который затем запускается с SYSTEM-привилегиями через задачу QueueReporting.
Что особенно неприятно: до публикации RoguePlanet исследователь анонсировал крупное раскрытие на 14 июля 2026 — дату следующего Patch Tuesday — предупредив что релиз "сломает кости в тот день".
Что делать до 14 июля:
Три более ранних эксплойта Nightmare Eclipse — BlueHammer, RedSun и UnDefend — уже были использованы в реальных атаках и добавлены в CISA KEV до выхода патчей. Это означает что июльский пакет будет горячим.
Итог: 14 июля — в календарь. Держи снапшоты DC, Application Control где возможно, мониторинг VSS и wermgr.exe прямо сейчас.
#windows #defender #rogueplanet #patchtuesday #security #sysadmin #admin_future
Коллеги, июнь оставил нам незакрытый хвост — и следующая неделя обещает быть жаркой.
Ситуация: RoguePlanet (CVE-2026-50656) — эксплойт Nightmare Eclipse против Microsoft Defender, позволяющий локальному атакующему получить SYSTEM-привилегии на полностью пропатченных Windows 10 и 11. Microsoft подтвердила уязвимость и работает над патчем, но сроков не назвала.
Эксплойт начинается с записи EICAR-файла в фейковый wermgr.exe для триггера ремедиации Defender. Отслеживая новое HardDiskVolumeShadowCopy-устройство, атакующий использует опортунистическую блокировку и выигрывает race condition. В результате C:\Windows\System32\wermgr.exe заменяется копией RoguePlanet, который затем запускается с SYSTEM-привилегиями через задачу QueueReporting.
Что особенно неприятно: до публикации RoguePlanet исследователь анонсировал крупное раскрытие на 14 июля 2026 — дату следующего Patch Tuesday — предупредив что релиз "сломает кости в тот день".
Что делать до 14 июля:
# 1. Проверяем что все июньские патчи установлены:
Get-HotFix | Where-Object {$_.InstalledOn -ge "2026-06-08"} |
Select-Object HotFixID, InstalledOn |
Sort-Object InstalledOn -Descending | Select-Object -First 5
# 2. RoguePlanet — mitigation через Application Control:
# ThreatLocker и аналоги блокируют эксплойт через allowlisting.
# Для тех кто без application control — мониторинг:
# Ищем подозрительное создание VSS-снапшотов:
Get-WinEvent -LogName "Microsoft-Windows-VolumeSnapshot-Driver/Operational" |
Where-Object {$_.TimeCreated -gt (Get-Date).AddDays(-7)} |
Select-Object TimeCreated, Message | Format-List
# Мониторим запуск wermgr.exe с необычным parent-процессом:
Get-WinEvent -LogName Security |
Where-Object {$_.Id -eq 4688} |
Where-Object {$_.Message -like "*wermgr.exe*"} |
Select-Object TimeCreated, Message | Format-List | Select-Object -First 5
# 3. Проверяем Defender Engine (отдельно обновляется):
Get-MpComputerStatus | Select-Object AMEngineVersion
# Нужна >= 1.1.26040.8 (фикс RedSun/CVE-2026-41091)
# Принудительное обновление:
Update-MpSignature
# 4. Готовимся к July 14 Patch Tuesday:
# Nightmare Eclipse обещает новые раскрытия
# Держим снапшоты DC перед Patch Tuesday
# Проверяем что тестовое окружение готово к быстрому тестированию
Три более ранних эксплойта Nightmare Eclipse — BlueHammer, RedSun и UnDefend — уже были использованы в реальных атаках и добавлены в CISA KEV до выхода патчей. Это означает что июльский пакет будет горячим.
Итог: 14 июля — в календарь. Держи снапшоты DC, Application Control где возможно, мониторинг VSS и wermgr.exe прямо сейчас.
#windows #defender #rogueplanet #patchtuesday #security #sysadmin #admin_future
🧠 Skills: Полгода CVE-шторма — пора строить систему, а не реагировать на каждый пожар
Коллеги, понедельник и начало второго полугодия. Хорошее время остановиться и переосмыслить подход.
H1 2026 дал нам: восемь LPE в ядре Linux, рекордный Patch Tuesday с 206 CVE, Nightmare Eclipse и семь Windows zero-days, Atomic Arch supply chain атаку, Secure Boot истечение, RC4 enforcement, Entra дедлайны. И это только то, о чём мы знаем.
Паттерн понятен: темп развивается из-за LLM-driven scanning — AI-инструменты помогают находить баги быстрее чем когда-либо. Это не замедлится. Значит — нужна система.
Три уровня системы которая работает независимо от темпа раскрытий:
Честная метрика для самооценки — ответь на вопрос:
Итог: второе полугодие будет не легче первого. Nightmare Eclipse обещает новые раскрытия 14 июля. LLM-assisted поиск уязвимостей не замедляется. Единственный работающий ответ — не более быстрая реакция, а система которая снижает радиус поражения до появления патча. Три уровня выше — это эта система. Начни с первого сегодня.
#skills #процессы #автоматизация #security #sysadmin #h2_2026 #admin_future
Коллеги, понедельник и начало второго полугодия. Хорошее время остановиться и переосмыслить подход.
H1 2026 дал нам: восемь LPE в ядре Linux, рекордный Patch Tuesday с 206 CVE, Nightmare Eclipse и семь Windows zero-days, Atomic Arch supply chain атаку, Secure Boot истечение, RC4 enforcement, Entra дедлайны. И это только то, о чём мы знаем.
Паттерн понятен: темп развивается из-за LLM-driven scanning — AI-инструменты помогают находить баги быстрее чем когда-либо. Это не замедлится. Значит — нужна система.
Три уровня системы которая работает независимо от темпа раскрытий:
УРОВЕНЬ 1: МОНИТОРИНГ (настроить один раз)
Три источника которые дают сигнал РАНЬШЕ чем заголовки:
□ CISA KEV RSS: cisa.gov/known-exploited-vulnerabilities-catalog
→ Добавить в RSS-ридер или настроить email digest
□ Security advisory от своих дистрибутивов:
Ubuntu: ubuntu.com/security/notices
RHEL: access.redhat.com/security/security-updates
MS: msrc.microsoft.com/update-guide/rss
□ Telegram-канал "Admin Future" :)
УРОВЕНЬ 2: МГНОВЕННЫЙ MITIGATION (автоматизировать)
Ansible playbook для быстрого закрытия поверхности атаки
до появления патча — один раз написать, применять за минуты:
- name: Linux kernel LPE mitigation 2026
hosts: all
become: true
tasks:
- name: Block vulnerable kernel modules
copy:
dest: /etc/modprobe.d/lpe-mitigation.conf
content: |
install algif_aead /bin/false
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
install cifs /bin/false
- name: Harden ptrace scope
sysctl:
name: kernel.yama.ptrace_scope
value: '1'
state: present
sysctl_set: yes
Для Windows — готовый DCR (Desired Configuration Rule)
в Intune или Ansible для Windows.
УРОВЕНЬ 3: PATCH PIPELINE (не руки, а автоматика)
Linux: unattended-upgrades для security-only (Ubuntu)
или dnf-automatic для RHEL
Windows: Windows Autopatch или WSUS с auto-approval
для Critical/Important за 48-72 часа
Цель: Critical CVE → автоматический патч за 72 часа
без ручного вмешательства на каждый сервер
Честная метрика для самооценки — ответь на вопрос:
Возьми Bad Epoll (CVE-2026-46242), объявленный на прошлой неделе.
Сколько времени прошло от публикации до закрытия 90% флота?
< 24 часов → Отличная система, ты готов к H2 2026
24-72 часа → Хорошо, но автоматизируй mitigation
3-7 дней → Есть что улучшать, сосредоточься на pipeline
> 7 дней → Нужен проект по выстраиванию системы — прямо сейчас
Итог: второе полугодие будет не легче первого. Nightmare Eclipse обещает новые раскрытия 14 июля. LLM-assisted поиск уязвимостей не замедляется. Единственный работающий ответ — не более быстрая реакция, а система которая снижает радиус поражения до появления патча. Три уровня выше — это эта система. Начни с первого сегодня.
#skills #процессы #автоматизация #security #sysadmin #h2_2026 #admin_future
🐧 Linux: DirtyClone — невидимый LPE который не оставляет следов в логах
Коллеги, добрый вторник. Пока Bad Epoll ещё патчируется на флотах, JFrog Security Research опубликовали разбор DirtyClone (CVE-2026-43503) — и это один из самых технически изощрённых LPE в серии. CVSS 8.8.
Что делает DirtyClone особенным: атака генерирует ноль записей в kernel audit log. Ваш AIDE и Tripwire не заметят ничего — бинарь на диске не изменится. Изменится только его копия в page cache памяти. Это делает DirtyClone особенно опасным в multi-tenant средах и Kubernetes-кластерах.
Механика: баг в функции __pskb_copy_fclone() — она сбрасывает флаг SKBFL_SHARED_FRAG при клонировании сетевых пакетов. Этот флаг — маркер безопасности: "эта память файловая, не пиши в неё напрямую". Без флага ядро разрешает in-place запись. Атакующий загружает /usr/bin/su в page cache, заворачивает эти страницы в сетевой пакет, клонирует через TEE-правило netfilter, прогоняет через IPsec-туннель — и IPsec-дешифрование перезаписывает бинарь в памяти. Следующий вызов su — это уже код атакующего с root-привилегиями.
Наибольший риск несут multi-tenant облака, Kubernetes-кластеры и контейнерные workload-ы с включёнными user namespaces — любое ядро без полного patch chain CVE-2026-43503 остаётся уязвимым, даже если оригинальные DirtyFrag патчи были применены.
Итог: DirtyFrag-класс, вероятно, ещё не исчерпан — любая функция, которая перемещает fragment descriptors без сохранения shared-frag бита, является потенциальным новым CVE. Патч + перезагрузка — единственное закрытие. Остальное — стопгэп.
#linux #kernel #dirtyclone #lpe #security #контейнеры #sysadmin #admin_future
Коллеги, добрый вторник. Пока Bad Epoll ещё патчируется на флотах, JFrog Security Research опубликовали разбор DirtyClone (CVE-2026-43503) — и это один из самых технически изощрённых LPE в серии. CVSS 8.8.
Что делает DirtyClone особенным: атака генерирует ноль записей в kernel audit log. Ваш AIDE и Tripwire не заметят ничего — бинарь на диске не изменится. Изменится только его копия в page cache памяти. Это делает DirtyClone особенно опасным в multi-tenant средах и Kubernetes-кластерах.
Механика: баг в функции __pskb_copy_fclone() — она сбрасывает флаг SKBFL_SHARED_FRAG при клонировании сетевых пакетов. Этот флаг — маркер безопасности: "эта память файловая, не пиши в неё напрямую". Без флага ядро разрешает in-place запись. Атакующий загружает /usr/bin/su в page cache, заворачивает эти страницы в сетевой пакет, клонирует через TEE-правило netfilter, прогоняет через IPsec-туннель — и IPsec-дешифрование перезаписывает бинарь в памяти. Следующий вызов su — это уже код атакующего с root-привилегиями.
Наибольший риск несут multi-tenant облака, Kubernetes-кластеры и контейнерные workload-ы с включёнными user namespaces — любое ядро без полного patch chain CVE-2026-43503 остаётся уязвимым, даже если оригинальные DirtyFrag патчи были применены.
# ВАЖНО: это НЕ один патч — это серия из четырёх CVE
# Нужна именно полная серия для DirtyFrag + DirtyClone
# Проверяем версию ядра (нужна 7.1.3+ / 6.18.38+ / 6.12.95+):
uname -r
# Обновляем:
apt update && apt full-upgrade -y && reboot # Debian/Ubuntu
dnf update kernel -y && reboot # RHEL/Rocky/AlmaLinux
# МИТИГЕЙШН без перезагрузки:
# Ограничиваем user namespaces:
sysctl -w kernel.unprivileged_userns_clone=0 # Debian/Ubuntu
sysctl -w user.max_user_namespaces=0 # RHEL/Fedora
# Blacklist модулей IPsec (если не используется):
printf "install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n" | \
tee /etc/modprobe.d/dirtyclone.conf
rmmod rxrpc esp4 esp6 2>/dev/null || true
# После патча — сбрасываем page cache:
echo 3 | tee /proc/sys/vm/drop_caches
# Проверяем что все четыре CVE серии закрыты:
zcat /proc/config.gz 2>/dev/null | grep CONFIG_XFRM || \
cat /boot/config-$(uname -r) | grep CONFIG_XFRM
Итог: DirtyFrag-класс, вероятно, ещё не исчерпан — любая функция, которая перемещает fragment descriptors без сохранения shared-frag бита, является потенциальным новым CVE. Патч + перезагрузка — единственное закрытие. Остальное — стопгэп.
#linux #kernel #dirtyclone #lpe #security #контейнеры #sysadmin #admin_future
🪟 Windows: RoguePlanet без патча + "bone shattering drop" 14 июля. Что делать сейчас.
Коллеги, неделя перед следующим Patch Tuesday — самый острый момент в истории с Nightmare Eclipse.
Nightmare Eclipse публично анонсировал крупное раскрытие на 14 июля 2026 — дату следующего Patch Tuesday Microsoft — предупредив что релиз "переломает кости в тот день". Изнурительная переработка RoguePlanet привела к признанию что июльский пакет может оказаться не таким масштабным как планировалось. Тем не менее дата 14 июля официально не отменена, и команды безопасности должны рассматривать её как активный горизонт угрозы.
Что актуально прямо сейчас:
RoguePlanet (CVE-2026-50656) — race condition в Defender, даёт SYSTEM-шелл на полностью пропатченных Windows 10 и 11. Microsoft не указала когда ожидается патч. Исследователь отметил что "не видел ни одной попытки детектирования или блокировки PoC через сигнатуры которая была бы эффективной — небольшие изменения в PoC полностью обходят mitigation-ы. Единственное что можно реально сделать — ждать патча от Microsoft."
Также существует GreatXML — восьмой эксплойт серии, машины уязвимы если ранее запускали Defender Offline Scan или могут загрузиться в WinRE в Offline Scan State.
Среднее время от эксплойта до использования в атаках составляло пять дней в 2026 году — работающий proof-of-concept опубликован публично, и этот таймлайн начался не когда присвоили CVE или выпустили патч, а в момент публикации.
Итог: 14 июля — следующая Patch Tuesday и возможный день новых раскрытий. До него — Application Control, обновлённый Defender, мониторинг VSS/wermgr. После — патчить в тот же день.
#windows #defender #rogueplanet #nightmare_eclipse #patchtuesday #sysadmin #admin_future
Коллеги, неделя перед следующим Patch Tuesday — самый острый момент в истории с Nightmare Eclipse.
Nightmare Eclipse публично анонсировал крупное раскрытие на 14 июля 2026 — дату следующего Patch Tuesday Microsoft — предупредив что релиз "переломает кости в тот день". Изнурительная переработка RoguePlanet привела к признанию что июльский пакет может оказаться не таким масштабным как планировалось. Тем не менее дата 14 июля официально не отменена, и команды безопасности должны рассматривать её как активный горизонт угрозы.
Что актуально прямо сейчас:
RoguePlanet (CVE-2026-50656) — race condition в Defender, даёт SYSTEM-шелл на полностью пропатченных Windows 10 и 11. Microsoft не указала когда ожидается патч. Исследователь отметил что "не видел ни одной попытки детектирования или блокировки PoC через сигнатуры которая была бы эффективной — небольшие изменения в PoC полностью обходят mitigation-ы. Единственное что можно реально сделать — ждать патча от Microsoft."
Также существует GreatXML — восьмой эксплойт серии, машины уязвимы если ранее запускали Defender Offline Scan или могут загрузиться в WinRE в Offline Scan State.
# 1. Проверяем статус июньских патчей:
Get-HotFix | Where-Object {$_.HotFixID -in @("KB5094126","KB5094127")} |
Select-Object HotFixID, InstalledOn
# KB5094126 = Windows 11, KB5094127 = Windows 10 LTSC/ESU
# 2. Обновляем Defender Engine (может прийти до PT):
Update-MpSignature -UpdateSource MicrosoftUpdateServer
Get-MpComputerStatus | Select-Object AMEngineVersion
# Следим за обновлениями выше 1.1.26060.x
# 3. Единственная реальная защита от RoguePlanet — Application Control:
# Проверяем статус WDAC:
Get-CIPolicy -FilePath "$env:windir\System32\CodeIntegrity\SIPolicy.p7b"
# Или через Intune: Endpoint Security -> App Control for Business
# ThreatLocker, AppLocker в deny-by-default режиме также блокируют
# 4. Мониторинг поведенческих индикаторов RoguePlanet:
# Ищем необычное создание VSS shadow copies + wermgr.exe:
Get-WinEvent -LogName System |
Where-Object {$_.Id -eq 8194 -and # VSS событие
$_.TimeCreated -gt (Get-Date).AddDays(-1)} |
Select-Object TimeCreated, Message | Format-List
# 5. Готовимся к 14 июля:
# Снапшот DC перед Patch Tuesday (как всегда)
# Тестовое окружение готово к быстрому развёртыванию
# Incident response team уведомлена о возможном hot-disclosure
Среднее время от эксплойта до использования в атаках составляло пять дней в 2026 году — работающий proof-of-concept опубликован публично, и этот таймлайн начался не когда присвоили CVE или выпустили патч, а в момент публикации.
Итог: 14 июля — следующая Patch Tuesday и возможный день новых раскрытий. До него — Application Control, обновлённый Defender, мониторинг VSS/wermgr. После — патчить в тот же день.
#windows #defender #rogueplanet #nightmare_eclipse #patchtuesday #sysadmin #admin_future
🔥2
🧠 Skills: Собеседование сисадмина. Выпуск #15 — вопросы на траблшутинг 2026
Коллеги, вторник — продолжаем рубрику. После полугода CVE-марафона — самое время разобрать вопросы которые сейчас реально задают на интервью Senior-уровня. Не про команды. Про мышление под давлением.
---
❓ Вопрос 1: «DirtyClone заразил сервер. Атака невидима для file integrity monitor. Ваши действия?»
❌ Ответ junior: «Запущу антивирус и проверю логи»
✅ Ответ инженера:
---
❓ Вопрос 2: «Nightmare Eclipse выпустил новый эксплойт в 18:00. Ваш процесс?»
❌ Ответ junior: «Жду официального CVE и патча»
✅ Ответ инженера:
---
❓ Вопрос 3: «Как объяснить руководителю зачем Application Control если Defender включён?»
❌ Ответ junior: «Лишний уровень защиты»
✅ Ответ инженера:
💡 Золотое правило собеса 2026:
Интервьюер на Senior оценивает не знание конкретных CVE. Он оценивает: есть ли у тебя процесс? Умеешь ли ты двигаться от "что случилось" к "что делать" системно, а не по наитию?
Лучший ответ на любой вопрос про инцидент начинается с: "Сначала я определяю масштаб и изолирую. Потом собираю данные. Потом действую."
#собеседование_AF #skills #security #sysadmin #linux #windows #admin_future
Коллеги, вторник — продолжаем рубрику. После полугода CVE-марафона — самое время разобрать вопросы которые сейчас реально задают на интервью Senior-уровня. Не про команды. Про мышление под давлением.
---
❓ Вопрос 1: «DirtyClone заразил сервер. Атака невидима для file integrity monitor. Ваши действия?»
❌ Ответ junior: «Запущу антивирус и проверю логи»
✅ Ответ инженера:
1. ПЕРВОЕ — не выключаем сервер
Выключение уничтожает доказательства в RAM.
Изолируем от сети (firewall drop, не shutdown):
iptables -I INPUT 1 -j DROP
iptables -I OUTPUT 1 -j DROP
2. СНИМАЕМ СНАПШОТ ПАМЯТИ (пока живая):
avml /tmp/memory.lime --compress # Linux Memory Extractor
# или через LiME модуль:
insmod lime.ko "path=/tmp/memory.lime format=lime"
3. ПРОВЕРЯЕМ PAGE CACHE — там и живёт DirtyClone:
# Сравниваем хэши бинарей в памяти и на диске:
sha256sum /proc/$(pgrep su)/exe
sha256sum /usr/bin/su
# Расхождение = активная эксплуатация
4. ИЩЕМ eBPF РУТКИТ (как в Atomic Arch):
ls /sys/fs/bpf/
bpftool prog list # нет ли чужих BPF программ
5. РОТИРУЕМ CREDENTIALS — немедленно, с другой машины:
SSH host keys, root пароль, service account tokens
6. REBUILD FROM SCRATCH (не просто патч):
При подтверждённой эксплуатации — только чистая установка
---
❓ Вопрос 2: «Nightmare Eclipse выпустил новый эксплойт в 18:00. Ваш процесс?»
❌ Ответ junior: «Жду официального CVE и патча»
✅ Ответ инженера:
Первые 30 минут:
1. Читаем writeup — понимаем prerequisites
(Local? Network? Defender нужен? Какие условия?)
2. CISA KEV — добавили? Это метрика срочности
3. Проверяем наш флот: есть ли условия эксплуатации?
30 мин — 2 часа:
4. Применяем mitigation если есть
(для RoguePlanet — Application Control)
5. Уведомляем stakeholders если impact критический
После:
6. Ждём патч, ставим при ближайшем maintenance window
7. Пишем incident timeline в инженерный журнал
Что НЕ делаем:
✗ Не паникуем без анализа prerequisites
✗ Не ставим непроверенные "mitigation" скрипты из Twitter
✗ Не ждём неделю "пока оценим"
---
❓ Вопрос 3: «Как объяснить руководителю зачем Application Control если Defender включён?»
❌ Ответ junior: «Лишний уровень защиты»
✅ Ответ инженера:
Язык бизнеса:
"Defender — это охранник который проверяет всех входящих.
RoguePlanet доказал что охранника можно обмануть
именно потому что он — охранник с максимальными правами.
Application Control — это список допущенных лиц.
Даже если охранник скомпрометирован, незнакомец
не в списке не попадёт в здание.
Три предыдущих эксплойта Nightmare Eclipse
уже эксплуатировались в дикой природе.
Application Control блокировал их по умолчанию
у клиентов ThreatLocker — до выхода патча.
Стоимость внедрения: [X].
Стоимость инцидента с утечкой данных: [Y >> X].
Решение — ваше."
💡 Золотое правило собеса 2026:
Интервьюер на Senior оценивает не знание конкретных CVE. Он оценивает: есть ли у тебя процесс? Умеешь ли ты двигаться от "что случилось" к "что делать" системно, а не по наитию?
Лучший ответ на любой вопрос про инцидент начинается с: "Сначала я определяю масштаб и изолирую. Потом собираю данные. Потом действую."
#собеседование_AF #skills #security #sysadmin #linux #windows #admin_future
🔥2
🐧 Linux: GhostLock — 15-летний баг с 97% надёжностью и цепочкой до браузера
Коллеги, добрая среда. Пока всё внимание было на июльский Patch Tuesday, на прошлой неделе Nebula Security раскрыли GhostLock (CVE-2026-43499) — и это один из самых серьёзных LPE 2026 года.
Use-after-free в подсистеме real-time mutex ядра Linux, существующий с 2011 года. Nebula добились 97% надёжности эксплойта через Google kernelCTF и получили $92,337 в рамках bug bounty. Эксплойт не только даёт root — он также позволяет выбраться из контейнера.
Но самое интересное — GhostLock является второй половиной цепочки IonStack: первая половина (CVE-2026-10702) — это уязвимость Firefox, которая выполняет код внутри браузера и выбирается из его sandbox. GhostLock несёт его дальше — до root. Одна вредоносная ссылка → root на системе.
Неприятный нюанс с патчами: оригинальный фикс привнёс отдельный краш-баг (CVE-2026-53166), и cleanup для него ещё стабилизировался в начале июля — ранние сборки могут не содержать финальную версию.
Открытие GhostLock было сделано с помощью AI-инструмента VEGA от Nebula Security — автоматизированного баг-хантера. Futex priority inheritance датируется 2011 годом: старый, активно используемый код ядра, который почти никто не перечитывал годами — пока автоматизированные инструменты не начали его сканировать.
Итог: не все LPE одинаковы. GhostLock + IonStack — это браузер → root одним кликом. Это высшая лига. Проверь что взял финальный патч, а не первый фикс с краш-багом.
#linux #kernel #ghostlock #lpe #security #sysadmin #admin_future
Коллеги, добрая среда. Пока всё внимание было на июльский Patch Tuesday, на прошлой неделе Nebula Security раскрыли GhostLock (CVE-2026-43499) — и это один из самых серьёзных LPE 2026 года.
Use-after-free в подсистеме real-time mutex ядра Linux, существующий с 2011 года. Nebula добились 97% надёжности эксплойта через Google kernelCTF и получили $92,337 в рамках bug bounty. Эксплойт не только даёт root — он также позволяет выбраться из контейнера.
Но самое интересное — GhostLock является второй половиной цепочки IonStack: первая половина (CVE-2026-10702) — это уязвимость Firefox, которая выполняет код внутри браузера и выбирается из его sandbox. GhostLock несёт его дальше — до root. Одна вредоносная ссылка → root на системе.
Неприятный нюанс с патчами: оригинальный фикс привнёс отдельный краш-баг (CVE-2026-53166), и cleanup для него ещё стабилизировался в начале июля — ранние сборки могут не содержать финальную версию.
# Проверяем версию ядра — нужна актуальная с ПОЛНЫМ фиксом:
uname -r
# Ubuntu: проверяем конкретный advisory для своей версии LTS
# (Ubuntu 24.04, 22.04, 20.04 всё ещё могут быть listed as vulnerable)
ubuntu-security-status --verbose | grep -i ghostlock
# или:
apt-cache policy linux-image-$(uname -r) | grep Candidate
# Обновляем + проверяем что взяли именно финальный фикс:
apt update && apt full-upgrade -y
uname -r # после reboot проверяем новую версию
# RHEL/Rocky/AlmaLinux:
dnf update kernel -y && reboot
# Проверяем два build flags которые усложняют эксплуатацию
# (не фикс, но mitigation):
cat /boot/config-$(uname -r) | grep -E "RANDOMIZE_KSTACK|STATIC_USERMODE"
# Приоритизация: патчить первыми shared/multi-tenant машины,
# cloud серверы, контейнерные хосты и CI-runners
Открытие GhostLock было сделано с помощью AI-инструмента VEGA от Nebula Security — автоматизированного баг-хантера. Futex priority inheritance датируется 2011 годом: старый, активно используемый код ядра, который почти никто не перечитывал годами — пока автоматизированные инструменты не начали его сканировать.
Итог: не все LPE одинаковы. GhostLock + IonStack — это браузер → root одним кликом. Это высшая лига. Проверь что взял финальный патч, а не первый фикс с краш-багом.
#linux #kernel #ghostlock #lpe #security #sysadmin #admin_future
🪟 Windows: Июльский Patch Tuesday — рекорд 622 CVE, RoguePlanet закрыт, и новый LegacyHive
Коллеги, вчера вышел July Patch Tuesday. Держитесь.
Microsoft опубликовал 622 уязвимости в июльском Patch Tuesday, включая рекордные 416 уязвимостей Windows. Microsoft известно об эксплуатации в дикой природе двух из сегодняшних уязвимостей, обе добавлены в CISA KEV.
Хорошая новость: RoguePlanet закрыт. Патч вышел через Malware Protection Engine версии 1.1.26060.3008 — OOB-обновление 8-9 июля, до регулярного Patch Tuesday.
Плохая новость: Nightmare Eclipse заявил что патч RoguePlanet привнёс новую проблему — при определённых условиях атакующие могут использовать обновлённый движок для заполнения всего диска.
И сразу же после вчерашнего PT: появился новый PoC LegacyHive — позволяет непривилегированному пользователю монтировать чужой user hive.
Три приоритета на сегодня:
Примечательное изменение в Patch Tuesday: Security Update Guide Microsoft больше не перечисляет отдельные уязвимости — только сводную таблицу количества по семействам продуктов и секцию "Notable CVEs". Это прямое следствие экспоненциального роста объёмов: при 622 CVE детальный listing становится неуправляемым.
Итог: 622 CVE — это не читать, это триажировать. SPNEGO NEGOEX (wormable 9.8) и SharePoint RCE — патчить сегодня. Kerberos RC4 — проверяй Event 205 прямо сейчас.
#windows #patchtuesday #sharepoint #kerberos #security #sysadmin #admin_future
Коллеги, вчера вышел July Patch Tuesday. Держитесь.
Microsoft опубликовал 622 уязвимости в июльском Patch Tuesday, включая рекордные 416 уязвимостей Windows. Microsoft известно об эксплуатации в дикой природе двух из сегодняшних уязвимостей, обе добавлены в CISA KEV.
Хорошая новость: RoguePlanet закрыт. Патч вышел через Malware Protection Engine версии 1.1.26060.3008 — OOB-обновление 8-9 июля, до регулярного Patch Tuesday.
Плохая новость: Nightmare Eclipse заявил что патч RoguePlanet привнёс новую проблему — при определённых условиях атакующие могут использовать обновлённый движок для заполнения всего диска.
И сразу же после вчерашнего PT: появился новый PoC LegacyHive — позволяет непривилегированному пользователю монтировать чужой user hive.
Три приоритета на сегодня:
# 1. КРИТИЧНО: CVE-2026-55040 — SharePoint Authentication Bypass
# Rapid7 нашли цепочку: этот баг + второй (August PT) = unauthenticated RCE
# SharePoint Server Subscription Edition, 2019, 2016 — патчить немедленно
Get-HotFix | Where-Object {$_.InstalledOn -ge "2026-07-13"} |
Select-Object HotFixID, InstalledOn | Sort-Object InstalledOn -Descending
# 2. КРИТИЧНО: CVE-2025-47981 — SPNEGO NEGOEX buffer overflow CVSS 9.8
# Wormable, no auth, no interaction, все Windows с Server 2008R2
# Уже в прошлом месяце был в preview — проверяем что закрыт:
$spnego = Get-HotFix | Where-Object {$_.HotFixID -like "*KB509*"}
$spnego | Format-Table
# 3. RoguePlanet — проверяем версию Defender Engine:
Get-MpComputerStatus | Select-Object AMEngineVersion
# Нужна >= 1.1.26060.3008
# Для air-gapped систем — принудительное обновление:
Update-MpSignature -UpdateSource InternalDefinitionUpdateServer
# 4. ДЕДЛАЙН который пришёл сегодня — Kerberos RC4 ФИНАЛ:
# Реестровый ключ RC4DefaultDisablementPhase больше не существует
# Проверяем нет ли RC4-only учёток которые теперь упадут:
Get-WinEvent -LogName System -ComputerName (hostname) |
Where-Object {$_.Id -eq 205} |
Select-Object TimeCreated, Message | Format-List | Select-Object -First 5
# Event 205 = RC4 ticket запрошен — эти учётки теперь не аутентифицируются
# 5. SQL Server 2016 — сегодня EOL extended support
# Переходит в платный ESU с 15 июля 2026
# SharePoint 2016 и 2019 — вчера последний день поддержки (нет ESU!)
Примечательное изменение в Patch Tuesday: Security Update Guide Microsoft больше не перечисляет отдельные уязвимости — только сводную таблицу количества по семействам продуктов и секцию "Notable CVEs". Это прямое следствие экспоненциального роста объёмов: при 622 CVE детальный listing становится неуправляемым.
Итог: 622 CVE — это не читать, это триажировать. SPNEGO NEGOEX (wormable 9.8) и SharePoint RCE — патчить сегодня. Kerberos RC4 — проверяй Event 205 прямо сейчас.
#windows #patchtuesday #sharepoint #kerberos #security #sysadmin #admin_future