🔎 Cisco SD-WAN CVE-2026-76504: замена буквы на %6a даёт права админа. Как несогласованная URL-нормализация ломает аутентификацию

Коллеги, детальный разбор классической архитектурной ошибки, которая с завидной регулярностью всплывает в веб-интерфейсах сетевых appliance и контроллеров управления.

📌 ФАКТЫ
Уязвимость: CVE-2026-76504, наивысший CVSS 9.8 (Critical), затрагивает API Cisco Catalyst SD-WAN Manager (ранее vManage).

Механика обхода (Improper URL Handling): security-прокси проверяет путь запроса до декодирования URL, а само Java-приложение за ним парсит путь уже после декодирования.

Запрос к POST /%6a_security_check (%6a — hex-код символа j) пролетает мимо фильтра безопасности, попадает в бэкенд как /j_security_check и приводит к мгновенной аутентификации в системе с привилегиями admin / netadmin.

Условия эксплуатации: удаленно, без учетных данных. Cisco зафиксировала реальные атаки «в дикой природе» при расследовании тикета в TAC в сентябре.

Workaround отсутствует. Дыра уже в каталоге CISA KEV (дедлайн на закрытие истек 3 октября).

Контекст: это уже четвертая критическая брешь в SD-WAN Manager за 2026 год (после CVE-2026-20182, 20245, 20262). Предыдущие патчи эту дыру не закрывают.

📦 МАТРИЦА ИСПРАВЛЕНИЙ
Plaintext

Ветка       Исправленный релиз      Ветка       Исправленный релиз
──────────────────────────────────────────────────────────────────
20.9        20.9.10.1               20.18       20.18.4.1
20.12       20.12.8.2               26.1        26.1.2.1
20.15       20.15.6.1               26.2        26.2.1
──────────────────────────────────────────────────────────────────
Ветки < 20.9 — официальный EOL (только плановая миграция на 20.9+)

🛠 ФОРЕНЗИКА И ПРОВЕРКА ЛОГОВ (на ноде vManage)
Bash

# 1. Поиск URL-encoded паттернов в логах реверс-прокси
grep -E 'POST /%[0-9a-fA-F]{2}_security_check' \
  /var/log/nms/containers/service-proxy/serviceproxy-access.log*

# 2. Аудит вызовов j_security_check и аномалий под служебными учетками viptela-reserved-*
grep -E 'j_security_check|viptela-reserved-' /var/log/nms/vmanage-server.log* | tail -100

Быстрый аудит любого веб-сервиса на расхождение в парсинге URL:

Bash

# Сравниваем HTTP-коды ответа на прямой и URL-encoded запросы
curl -sk -o /dev/null -w 'Декодированный путь: %{http_code}\n' https://<host>/j_security_check
curl -sk -o /dev/null -w 'Экранированный путь (%6a): %{http_code}\n' https://<host>/%6a_security_check

💡 В ЧЁМ СУТЬ

Корень проблемы — CWE-177 (URL Parsing/Discrepancy). Это фундаментальная проблема многослойных архитектур: когда фронтенд-фильтр (WAF, Envoy, Nginx, внутренний контейнер-прокси) и целевой бэкенд (Spring/Tomcat) нормализуют URL по разным стандартам.

Золотое правило: валидатор прав и обработчик бизнес-логики обязаны работать с одинаково канонизированным представлением строки запроса.

Четыре критических обхода авторизации подряд на одном продукте за год — четкий сигнал: консоль управления SD-WAN Manager нельзя считать доверенной по умолчанию, даже если на нее накачены прошлые обновления.

🛡 ЧЕКЛИСТ ДЕЙСТВИЙ
Экстренный накат патча: обновиться до актуального таргетированного билда (прошлые заплатки бессильны против %6a).

Периметральная изоляция: порты TCP/443 (Web/API), TCP/22 (SSH) и TCP/830 (NETCONF) контроллеров vManage должны быть полностью отрезаны от публичного интернета. Доступ — строго через VPN / выделенный OOB Jump-хост.

Глубокий аудит логов: просканировать логи serviceproxy-access за сентябрь на наличие шестнадцатеричных последовательностей %XX_security_check.

Реакция на инцидент: при обнаружении совпадений снять диагностический бандл request admin-tech и немедленно эскалировать кейс в Cisco TAC.

#skills #cisco #sdwan #network #security #authbypass #cve #kev #sysadmin #admin_future

🔐 APT учится SHA3: Ubuntu готовится к дню, когда SHA-2 падёт. Зачем это нужно уже сейчас

Коллеги, понедельник. Сегодня пост не про очередную горящую CVE на периметре, а про эталонную инженерную предусмотрительность и архитектурную дальновидность.

📌 ФАКТЫ
Инициатива: инженеры Canonical (в частности, Gianpiero Carpinelli) внесли в апстрим пакетного менеджера APT поддержку семейства хешей SHA3-256 и SHA3-384 для проверки целостности индексных файлов (Release, Packages, Sources).

Дефолт не меняется: SHA-256/SHA-512 остаются базовым стандартом. Поддержка SHA3 внедряется как спящий резервный механизм.

Математика жизненного цикла: современные Enterprise-релизы (такие как Ubuntu 24.04 LTS в рамках расширенной поддержки Ubuntu Pro) живут 10–12 лет — то есть вплоть до 2036 года. Если на этом горизонте математический аппарат SHA-2 даст критическую трещину, миллионы установленных хостов должны уметь валидировать пакеты по альтернативному алгоритму без аврального обновления самого APT.

Текущий статус криптографии: семейство SHA-2 (SHA-256/512) не скомпрометировано, практических атак нет. При аппруве патча в апстриме Debian/APT функционал планируют бэкпортировать в LTS-ветку 24.04.

🛠 АУДИТ РЕПОЗИТОРИЕВ И КЛЮЧЕЙ В СИСТЕМЕ
Пока Canonical закладывает фундамент на 10 лет вперед, полезно проверить, нет ли в вашей системе хвостов из прошлого века:

Bash

# 1. Какие типы хешей фактически задействованы в ваших текущих InRelease
grep -hoE '^(MD5Sum|SHA1|SHA256|SHA512|SHA3-[0-9]+):' \
  /var/lib/apt/lists/*InRelease 2>/dev/null | sort | uniq -c

# 2. Поиск устаревших GPG-ключей репозиториев (RSA 1024, DSA и legacy-форматы)
for k in /etc/apt/trusted.gpg.d/* /usr/share/keyrings/*; do
  [ -f "$k" ] || continue
  echo "== Файл: $k"
  gpg --show-keys "$k" 2>/dev/null | grep -E '^pub'
done

💡 В ЧЁМ СУТЬ

В криптографии это называется crypto-agility (криптографическая гибкость) — способность инфраструктуры переключиться на новые криптопримитивы без необходимости менять сам софт и переустанавливать ОС на клиентах.

Обновить центральное зеркало репозитория можно за полчаса. А вот обновить пакетный менеджер на тысячах серверов, изолированных промышленных контроллерах или банкоматах, если проверка подписей внезапно сломается из-за компрометации алгоритма, — задача на месяцы аварийных работ.

🛡 НА ЧТО ОБРАТИТЬ ВНИМАНИЕ В СВОЕЙ СЕТИ
Пока ядро APT готовится к будущему, аналогичный вопрос стоит задать собственной инфраструктуре:

Собственные Nexus / Artifactory / Aptly: поддерживают ли ваши локальные пайплайны сборки пакетов современные алгоритмы хеширования и подписи?

SSH-инфраструктура: давно ли вы вычищали из authorized_keys и конфигов sshd старые ключи ssh-rsa (SHA-1) в пользу ed25519 и ecdsa?

Внутренний PKI / CA: какой алгоритм подписи выставлен на корневых и промежуточных сертификатах корпоративного центра сертификации?

#linux #debian #ubuntu #apt #crypto #security #sysadmin #admin_future

🧠 Skills: journalctl — 10 команд, которые заменяют grep по /var/log

Коллеги, навык недели. Начиная с Debian 12 rsyslog по умолчанию не ставится — классических текстовых логов на свежих инсталляциях может просто не быть. Всё уходит в бинарный журнал systemd-journald.

🛠 10 БАЗОВЫХ КОМАНД
Bash

# 1. Только ошибки (от err и выше) с момента текущего старта системы
journalctl -p err -b

# 2. Логи конкретного сервиса за последний час
journalctl -u nginx --since "1 hour ago"

# 3. Режим live-мониторинга (аналог tail -f) по конкретной службе
journalctl -u ssh -f

# 4. Список всех зафиксированных загрузок ОС (с их ID и временными метками)
journalctl --list-boots

# 5. Сообщения ядра (dmesg) за ПРЕДЫДУЩУЮ загрузку (ключевое при анализе падений)
journalctl -k -b -1

# 6. Фильтр по исполняемому файлу в чистом текстовом выводе
journalctl _COMM=sshd -o cat | grep -i 'failed'

# 7. Выборка событий в жестком временном окне
journalctl --since "2026-10-05 09:00" --until "2026-10-05 10:00"

# 8. Просмотр структуры записи со всеми служебными метаполями (для построения точных фильтров)
journalctl -o json-pretty -n 1

# 9. Проверка дискового пространства, занятого журналами прямо сейчас
journalctl --disk-usage

# 10. Ротация и очистка архивов старше 30 дней
journalctl --vacuum-time=30d

⚠️ ПРОВЕРЬТЕ ПЕРСИСТЕНТНОСТЬ (сохраняются ли логи после ребута)
Bash

# Проверка наличия каталога постоянного хранения
ls -d /var/log/journal 2>/dev/null && echo "Логи пишутся на диск" || echo "ВНИМАНИЕ: логи живут только в RAM до ребута!"

# Проверка конфигурации лимитов
grep -E '^(Storage|SystemMaxUse)' /etc/systemd/journald.conf

Если каталога /var/log/journal нет — журнал по дефолту сбрасывается в tmpfs (RAM). После аварийной перезагрузки расследовать причину сбоя будет физически невозможно:

Bash

# Включение постоянного хранения логов на диске
mkdir -p /var/log/journal && systemctl restart systemd-journald

💡 В ЧЁМ СУТЬ

Связка флагов

-b -1

и

-p err

закрывает 80% всех типовых инцидентов из серии «почему сервер упал ночью».

Персистентное хранилище на диске с жестко зафиксированным лимитом

SystemMaxUse

в

journald.conf

— обязательный базовый харденинг, который настраивается сразу после установки ОС.

#skills #linux #systemd #journalctl #debian #troubleshooting #sysadmin #admin_future

🤖 «Мы полностью перегружены»: AI-патчи захлестнули сетевой стек Linux

Коллеги, показательная хроника из жизни ядра — тренд, который в ближайшие годы затронет каждого, кто эксплуатирует Linux-инфраструктуру.

📌 ФАКТЫ
Крик души мейнтейнера: Якуб Кичиньский (Jakub Kicinski), ключевой мейнтейнер сетевой подсистемы ядра, при отправке PR в ветку Linux 7.3 констатировал: «We are completely overwhelmed» («Мы абсолютно перегружены»).

Лавина коммитов: в цикле 7.3 в ветку net прилетело 632 патча, а в net-next — 648. По оценке мейнтейнеров, от 30% до 50% всего пула патчей в net-next сгенерированы либо отредактированы с помощью AI.

Смертный приговор легаси: весной Эндрю Ланн (Andrew Lunn) предложил радикально выпилить из ядра древние Ethernet-драйверы эпохи шин ISA/PCMCIA (старые 3Com, Xircom, чипы 8390 и др.) суммарно на ~27 600 строк кода. Причина: AI-агенты и автоматические фаззеры пачками выкапывают там гипотетические баги, слать патчи ради «галочки» легко, а реальных пользователей у этого железа уже нет.

Клин клином: запрещать нейросети не стали — ядро защищают встречным AI. Мейнтейнеры автоматизируют LLM-ревью входящих пулл-реквестов, валидацию через Patchwork и автокоррекцию commit message (бюджет на инференс frontier-моделей выделила Meta).

💡 В ЧЁМ СУТЬ ДЛЯ СИСАДМИНА

Нейросети драматически удешевили поиск и генерацию отчетов, но валидация и исправление по-прежнему требуют дефицитного ресурса — внимания живого сеньор-инженера.

Патч-менеджмент ускорится в разы: AI выгребает пыльные углы кодовой базы, поэтому поток минорных CVE и обновлений ядра будет нарастать лавинообразно.

Эпоха выпиливания легаси: старые подсистемы и драйверы экзотических контроллеров начнут удалять пачками, чтобы не тратить ресурсы на бессмысленный саппорт. Если держите старое железо — сюрпризы в новых ядрах гарантированы.

Внутренний саппорт ждёт то же самое: службы Helpdesk и Security-команды скоро захлебнутся во входящих баг-репортах и сканах уязвимостей, сгенерированных пользователями через локальные AI-агенты.

🛠 ДИАГНОСТИКА: КАКИЕ ДРАЙВЕРЫ ДЕРЖАТ СЕТЬ ПРЯМО СЕЙЧАС
Проверьте, какие модули ядра обслуживают ваши сетевые интерфейсы:

Bash

# 1. Физические сетевые контроллеры и активные модули ядра
lspci -k | grep -A2 -i ethernet

# 2. Быстрая привязка: сетевой интерфейс -> загруженный драйвер
for i in /sys/class/net/*; do 
  [ -e "$i/device/driver" ] && echo "$(basename "$i"): $(basename "$(readlink "$i/device/driver")")"
done

Если раньше драйвер мог тихо и стабильно работать 15 лет в статусе «работает — не трогай», то теперь его либо засыплют сгенерированными правками, либо просто выкинут из апстрима ради снижения шума.

#linux #kernel #ai #opensource #networking #devops #sysadmin #admin_future

🗓 Windows Server 2022: 13 октября заканчивается основная поддержка. Что это значит на практике

Коллеги, вторник. Ровно через неделю — октябрьский Patch Tuesday и официальная смена жизненного цикла у самой массовой серверной ОС в текущих корпоративных контурах.

📌 ФАКТЫ
13 октября 2026 года — официальное завершение фазы Mainstream Support для всех редакций Windows Server 2022.

14 октября 2031 года — окончание расширенной поддержки (Extended Support).

Что прекращается: закрывается выпуск несекьюрных хотфиксов (non-security bugfixes), перестают приниматься запросы на изменение функционала (DCR) и аннулируются бесплатные инциденты технической поддержки.

Что остаётся: регулярные ежемесячные кумулятивные обновления безопасности (LCU) будут выходить в штатном режиме ещё 5 лет.

⚠️ ГДЕ НА САМОМ ДЕЛЕ ЗАРЫТ РИСК
Повода для паники нет — серверы не превратятся в тыкву. Однако этот рубеж традиционно запускает процесс бюджетирования и планирования миграций на Windows Server 2025. И вот здесь заложена классическая граната:

В Windows Server 2025 подписание SMB-трафика (SMB Signing) включено и обязательно по умолчанию для всех исходящих и входящих клиентских подключений.

Если просто накатить новую ОС или смигрировать файловый сервер без ревизии, мгновенно отвалятся:

Старые сетевые МФУ (сканирование по SMB в сетевую папку);

Древние офисные NAS и прошивки встроенных систем;

Недоконфигурированные Linux-хосты со старыми демонами Samba, где подпись отключена ради производительности.

🛠 ДИАГНОСТИКА ИНФРАСТРУКТУРЫ ДО СТАРТА МИГРАЦИИ
Выполняем на контроллере домена или серверах через PowerShell:

PowerShell

# 1. Инвентаризация: считаем точное количество инстансов Server 2022 в домене
Get-ADComputer -Filter 'OperatingSystem -like "*Server 2022*"' |
  Measure-Object | Select-Object Count

# 2. Проверяем текущую политику требования подписи SMB на сервере и клиенте
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature

# 3. Аудит с хоста: смотрим, какие текущие сессии висят БЕЗ цифровой подписи (Signed = False)
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed

💡 В ЧЁМ СУТЬ

Windows Server 2022 без проблем и спешки доживёт до 2031 года в статусе надёжной «рабочей лошадки».

Но если вы уже тестируете или закупаете лицензии под Server 2025, главная задача прямо сейчас — не перенос ролей, а инвентаризация сетевых шар и легаси-оборудования без SMB signing. Иначе в первый же день после миграции техподдержка утонет в тикетах «бухгалтерия не может отсканировать документы».

#windowsserver #lifecycle #smb #activedirectory #migration #powershell #sysadmin #admin_future

⏱️ Ubuntu 27.04 переходит на ntpd-rs. Повод проверить, кто вообще задаёт время в вашей сети

Коллеги, среда. Время — сервис, о котором вспоминают, только когда внезапно разваливается аутентификация в Kerberos.

📌 ФАКТЫ
Планы Canonical: в релизе Ubuntu 26.10 пакет ntpd-rs включён в архив для открытого тестирования, а начиная с Ubuntu 27.04 он станет системной службой времени по умолчанию.

Архитектурная причина: переход на memory-safe реализацию протокола NTP на языке Rust со встроенной поддержкой NTS (Network Time Security).

Критичность точного времени: от стабильности часов напрямую зависят валидация цепочек TLS-сертификатов, работа тикетов Kerberos, корреляция меток в журналах SIEM и сквозной аудит событий.

🛠 ПРОВЕРКА ЗА МИНУТУ
1. Хосты под управлением Linux
Bash

# Общий статус службы времени и синхронизации
timedatectl

# Текущее смещение, стратум и активный источник (chrony)
chronyc tracking

# Детальный список апстрим-серверов и их состояние
chronyc sources -v

2. Инфраструктура Windows / Active Directory
PowerShell

# Общий статус службы Windows Time и текущее смещение
w32tm /query /status

# Фактический источник синхронизации для хоста
w32tm /query /source

# Замер расхождения времени с контроллером домена в реальном времени
w32tm /stripchart /computer:dc01 /samples:5 /dataonly

⚠️ ТИПОВЫЕ ОШИБКИ В СЕТЯХ
Неверный источник на контроллере: источник у DC определяется как Local CMOS Clock или VM IC Time Synchronization Provider — в итоге время всего домена задаётся батарейкой BIOS материнской платы либо дрейфующими часами гипервизора.

Нарушение иерархии FSMO: внешний стратум NTP настроен не на держателе роли PDC Emulator, а на произвольном контроллере домена.

Конфликт синхронизации на виртуальных DC: на виртуальных машинах контроллеров домена оставлена включённой интеграция времени с хостом виртуализации (Integration Services / VMware Tools Time Sync).

💡 В ЧЁМ СУТЬ

Протокол Kerberos по умолчанию допускает расхождение часов не более 5 минут.

Иерархия времени в инфраструктуре должна быть строго монолитной:

Внешний доверенный NTP-пул → PDC Emulator → остальные DC домена → рядовые серверы и клиенты.

Любая самодеятельность в этой цепочке превращается в причину «плавающих» и трудноуловимых сбоев входа в домен.

#skills #ntp #time #activedirectory #kerberos #ubuntu #linux #sysadmin #admin_future

💾 TrueNAS 27 RC.1: нативный S3 поверх ZFS, RAIDZ для Special vdev и новая схема версионирования

Коллеги, важная новость для тех, кто держит СХД на TrueNAS или выбирает платформу под надежное хранилище и репозитории резервных копий.

📌 ФАКТЫ
Статус релиза: 6 октября представлен билд 27 RC.1. Финальный стабильный релиз 27.0 намечен на начало декабря.

Фундамент системы: ядро Linux 6.18 LTS в связке с OpenZFS 2.4.

Нативный S3-сервер (Early Access): бакеты маппятся напрямую на ZFS-датасеты. Из коробки поддерживаются multipart-загрузка, тегирование, ACL, версионирование и аппаратная неизменяемость (Object Lock / Immutability). Работает полностью изолированно, без выхода в интернет. Продакшен-статус запланирован на 2027 год.

Fusion Pools 2.0: под класс Special vdev (хранение метаданных и мелких блоков) теперь можно использовать топологию RAIDZ, а не только классический Mirror. Кроме того, при отсутствии выделенного ZIL/SLOG этот пул может брать на себя роль журнала транзакций.

Подсистема TrueSearch: движок индексации имён и содержимого файлов с нативной поддержкой поиска Spotlight (macOS) поверх SMB-шар. Важно: датасеты с нативным шифрованием ZFS индексации не подлежат.

Ребрендинг версий: переход на годовые мажорные номера (27, 28 и т.д.) вместо привычной схемы вида 25.04 / 25.10.

💡 В ЧЁМ СУТЬ ДЛЯ СИСАДМИНА

Ключевой тектонический сдвиг — полноценный S3 с поддержкой Immutability прямо из коробки.

Это готовый локальный таргет под неизменяемые бэкапы для Veeam Backup & Replication и Proxmox Backup Server без необходимости городить рядом костыли, сторонние контейнеры или отдельный кластер MinIO.

Однако статус Early Access обязывает: обкатывать технологию в лабах можно уже сейчас, но в боевой прод выводить строго после релиза 27.0 и первых корректирующих сервисных сборок (U1/U2).

🛠 ДИАГНОСТИКА: ПРОВЕРЯЕМ ПУЛЫ И ФЛАГИ ДО АПГРЕЙДА
Bash

# 1. Проверяем здоровье текущих пулов на ошибки и ребилд
zpool status -x

# 2. Проверяем доступность и статус критических фич OpenZFS
zpool get feature@raidz_expansion,feature@block_cloning <имя_пула>

# 3. Ревизия параметров датасетов (размер блока, сжатие, аллокация места)
zfs list -o name,used,avail,compression,recordsize

#storage #truenas #zfs #s3 #backup #linux #sysadmin #admin_future

🛠 DMDE: малоизвестная, но очень сильная утилита для восстановления данных

Коллеги, инструмент в копилку инженера. Большинство дежурно вспоминают R-Studio, TestDisk или PhotoRec, но DMDE (DM Disk Editor and Data Recovery) выручает там, где тяжелые комбайны спотыкаются или зависают на сыплющихся секторах.

📌 ФАКТЫ
Авторский проект: автор — независимый разработчик Дмитрий Сидоров, софт непрерывно развивается с 2006 года. Актуальная стабильная ветка — 4.4.4 (в тестировании 4.5.0).

Кроссплатформенность: работает нативно под Windows, Linux, macOS и DOS. Портативная версия без установки легко закидывается на аварийный live-диск (WinPE / Live Linux) для работы с хостом без загрузки основной ОС.

Поддержка файловых систем: NTFS, ReFS (включая серверные пулы), FAT12/16/32, exFAT, ext2/ext3/ext4, Btrfs, HFS+/HFSX, APFS.

Ключевой функционал:

Экспресс-восстановление случайно удалённых разделов через правку MBR/GPT «на лету»;

Виртуальная сборка программных и аппаратных RAID 0, 1, 4, 5, 6 (включая кастомные задержки и смещения страйпов);

Посекторное клонирование дисков с умным обходом сбойных LBA-блоков и реверсивным чтением;

Полноценный низкоуровневый дисковый hex-редактор с шаблонами структур файловых систем.

Гуманный Free-режим: бесплатная редакция позволяет восстанавливать до 4 000 файлов из текущей выбранной директории за один проход без ограничения по общему объёму и количеству повторных запусков.

⚠️ ОСТОРОЖНО: МАЛВАРЬ В ПОИСКЕ
В репозиториях GitHub и поисковой выдаче сейчас активно крутятся фальшивые сборки с заголовками в духе «DMDE Professional 2026 Full Crack / Keygen». Это чистый дроппер стилеров и инжекторов в процессы. Скачивать утилиту нужно строго с официального зеркала dmde.com.

💡 ПРАВИЛЬНЫЙ АЛГОРИТМ СПАСЕНИЯ ДАННЫХ

Стоп-запись: аварийный накопитель немедленно перемонтируется в

read-only

либо физически выводится из системы. Никаких проверок

chkdsk

или

fsck

на живом диске!

Посекторный образ: сначала снимается полный RAW-образ (встроенным модулем копирования DMDE либо утилитой

GNU ddrescue

).

Работа со слепком: анализ структур и вычитка файлов проводятся исключительно с полученного образа, оригинальный диск убирается на полку.

Изолированный таргет: спасённые данные выгружаются на третий, заведомо исправный накопитель.

Bash

# Эталонное снятие посекторного слепка сыплющегося диска через ddrescue:

# 1. Быстрый проход: читаем всё целое, пропуская проблемные зоны и ведя лог-карту
ddrescue -n -b 4096 /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.map

# 2. Добор битых секторов: до 3 попыток вычитки проблемных кластеров по карте
ddrescue -r3 -b 4096 /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.map

#tools #datarecovery #dmde #storage #backup #sysadmin #admin_future

🖥 Proxmox запускает поддержку 24/7 с 19 октября. Закрыт главный аргумент «против» в корпоративе

Коллеги, четверг. Новость для всех, кто ведёт проекты миграции с VMware vSphere и регулярно слышит от CTO или службы безопасности вопрос: «А кому мы будем звонить в 3 часа ночи, когда упадёт прод?».

📌 ФАКТЫ
Старт круглосуточного SLA: с 19 октября Proxmox Server Solutions официально запускает сервис поддержки 24/7 для всей линейки корпоративных продуктов: Proxmox Virtual Environment (PVE), Proxmox Backup Server (PBS) и Proxmox Datacenter Manager.

Конец австрийскому таймзону: ранее официальный вендорский саппорт работал строго в бизнес-часы по Вене (CET), а для ночных дежурств приходилось искать сторонних локальных интеграторов.

Тарифные уровни:

Premium Subscription: режим 24/7 доступен сразу с 19 октября. Безлимитное число тикетов, первичное время реакции — до 2 часов, прямая эскалация инженерам разработки ядра.

Standard Subscription: поддержка 24/7 появится чуть позже, в Q4 2026.

Basic Subscription: SLA остаётся в прежних рамках (рабочие часы).

Глобальная экспансия: учреждено американское подразделение Proxmox North America Inc., обеспечивающее перекрытие смен по модели follow-the-sun.

🛠 ПРОВЕРКА ГОТОВНОСТИ НОД К ОБРАЩЕНИЮ В TAC
При ночной аварии время идёт на минуты — данные для сервисной заявки должны собираться мгновенно:

Bash

# 1. Проверяем валидность лицензионного ключа и активный уровень подписки
pvesubscription get

# 2. Выгружаем точные версии установленных пакетов ядра и гипервизора
pveversion -v | head -5

# 3. Контролируем репозитории: enterprise-репозиторий должен быть активен без ошибок
ls -la /etc/apt/sources.list.d/

# 4. Снятие полного диагностического слепка ноды (базовый артефакт для любого тикета)
pvereport > /root/pvereport-$(hostname).txt

💡 В ЧЁМ СУТЬ

Наличие контракта 24/7 снимает формальный барьер у топ-менеджмента, но не отменяет законов физики: оно не заменяет локальный кворум Corosync, кластерный High Availability и отработанный план Disaster Recovery.

Дежурный инженер вендора в Вене или США в первую очередь запросит вывод

pvereport

и системные журналы. Снимите и сохраните эталонный отчет

pvereport

прямо сейчас на здоровом кластере — в момент боевого падения вам будет с чем сравнить конфигурацию и дисковые подсистемы.

#proxmox #virtualization #support #vmware #enterprise #ha #sysadmin #admin_future

🧠 Skills: IBM и Red Hat нашли 400+ неизвестных уязвимостей в Java-библиотеках. А вы знаете, сколько JAR-файлов у вас на серверах?

Коллеги, важная новость из мира Enterprise Open Source — отличный повод прокачать навык инвентаризации зависимостей в инфраструктуре.

📌 ФАКТЫ
Программа Lightwell: совместная инициатива IBM и Red Hat закрыла более 400 ранее неизвестных уязвимостей в популярных Java-библиотеках.

Главный фокус — глубокий бэкпорт: секьюрити-патчи создаются точечно под те устаревшие версии библиотек, которые реально крутятся на продакшене у клиентов, избавляя бизнес от риска сломать прод мажорным апгрейдом.

Сервис Clearinghouse: корпоративные заказчики могут централизованно отправлять свои списки используемых зависимостей на приоритетный секьюрити-аудит.

Текущий статус: точные названия библиотек и идентификаторы CVE пока держатся под эмбарго — исправления постепенно уходят в апстрим по процедуре ответственного раскрытия (Coordinated Vulnerability Disclosure).

🛠 ИНВЕНТАРИЗАЦИЯ JAVA НА СЕРВЕРАХ ЗА 5 МИНУТ
Bash

# 1. Считаем общее число JAR-файлов в локальной файловой системе (без сетевых шар)
find / -xdev -name '*.jar' 2>/dev/null | wc -l

# 2. Топ каталогов с наибольшей концентрацией JAR (где прячется JVM-софт)
find / -xdev -name '*.jar' 2>/dev/null | xargs -r dirname | sort | uniq -c | sort -rn | head

# 3. Инспекция «толстых» JAR/fat-JAR (Spring Boot) без полной распаковки архива
unzip -l app.jar | grep -E 'BOOT-INF/lib/.*\.jar' | awk '{print $4}'

# 4. Сборка полного SBOM (Software Bill of Materials) на лету через Syft
syft dir:/opt -o table | grep -i java-archive

💡 В ЧЁМ СУТЬ

Java прячется даже там, где вы её не ждёте:

В экосистеме 1С:Предприятие (1C:EDT, Сервер взаимодействия);

В CI/CD и мониторинге (Jenkins, Elasticsearch, Logstash);

Во внутренних системах документации (Confluence, Jira);

Во встроенных веб-консолях управления СХД, KVM и ИБП.

Урок Log4Shell показал: найти уязвимый компонент на сотне серверов занимает в разы больше времени, чем накатить патч. Снятый заранее SBOM превращает неделю судорожного поиска в один моментальный

grep

.

#skills #java #sbom #supplychain #security #devops #linux #sysadmin #admin_future

🔬 Google Kage: песочница для драйверов прямо внутри ядра Linux

Коллеги, интереснейший доклад с конференции Linux Plumbers 2026 — архитектурная инициатива, способная в будущем кардинально повысить стабильность и отказоустойчивость серверов.

📌 ФАКТЫ
Архитектура Kage: экспериментальная подсистема ядра Linux от инженеров Google, задача которой — изолировать драйверы аппаратных устройств.

Технологический фундамент: компиляторная изоляция LFI (Lightweight Fault Isolation) на базе LLVM (совместный проект Стэнфорда и Google). Драйвер продолжает исполняться в адресном пространстве ядра, но компилятор жестко ограничивает его доступ только выделенным пулом памяти, предотвращая порчу чужих структур ядра.

Рабочие прототипы: уже реализована изоляция драйверов NVMe, сетевых адаптеров и Wi-Fi стеков в рамках архитектуры VKage (интеграция с подсистемой VirtIO).

Производительность: накладные расходы заявляются значительно более низкими, чем у традиционных виртуальных песочниц и микроядерных выносов в userspace (точные бенчмарки пока не финализированы).

Готовность экосистемы: поддержка LFI для архитектуры AArch64 уже принята в апстрим LLVM, реализация под x86_64 ожидается в релизе LLVM 24. Одним из ключевых полигонов внедрения станет экосистема Android.

💡 ПОЧЕМУ ЭТО ВАЖНО СИСАДМИНУ

Драйверы стороннего оборудования — самый объемный, гетерогенный и наименее надежный пласт кодовой базы ядра.

Сегодня любая ошибка адресации или use-after-free в драйвере сетевой карты либо HBA-адаптера мгновенно приводит к Kernel Panic и падению всей ноды (либо к локальному повышению привилегий). Технология Kage локализует сбой до уровня программного отказа отдельного устройства, сохраняя работу ОС и соседних сервисов.

🛠 ДИАГНОСТИКА: СТОРОННИЙ КОД В ВАШЕМ ЯДРЕ ПРЯМО СЕЙЧАС
Bash

# 1. Считаем общее число загруженных модулей ядра
lsmod | wc -l

# 2. Проверяем статус Tainted (0 = ядро чистое и стабильное, >0 = загружены проприетарные модули/были сбои)
cat /proc/sys/kernel/tainted

# 3. Выявляем модули, собранные вне основного дерева исходников ядра (out-of-tree)
for m in $(lsmod | awk 'NR>1{print $1}'); do
  modinfo -F intree "$m" 2>/dev/null | grep -q Y || echo "Вне дерева ядра: $m"
done

#linux #kernel #drivers #google #security #virtualization #sysadmin #admin_future

🧠 Skills: EXT4 объявила data=journal устаревшим. Удаление — в 2028 году. Проверьте свои маунты

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

📌 ФАКТЫ
Статус Deprecated: начиная с ядра Linux 7.3 режим монтирования data=journal в файловой системе EXT4 официально помечен как устаревший.

Таймлайн удаления: полное выпиливание кода запланировано на начало 2028 года (аккурат после стабилизации LTS-ветки 2027 года).

Что это за режим: в журнал транзакций пишутся не только метаданные файловой системы, но и само тело файлов (данные). Это давало максимальную защиту от повреждений ценой катастрофической просадки пропускной способности (двойная запись). Режим наглухо отключает Delayed Allocation и Direct I/O.

По умолчанию EXT4 работает в режиме data=ordered (журналируются только метаданные) — его эти изменения никак не затрагивают.

🛠 БЫСТРЫЙ ЧЕК СВОИХ СИСТЕМ
Bash

# 1. Смотрим, смонтировано ли что-то прямо сейчас в режиме data=journal
findmnt -t ext4 -o TARGET,SOURCE,OPTIONS | grep "data=journal"

# 2. Проверяем статическую конфигурацию в fstab
grep -n 'data=journal' /etc/fstab

# 3. Проверяем, не зашит ли режим в суперблок раздела как опция по умолчанию
for d in $(findmnt -t ext4 -no SOURCE | sort -u); do
  echo "Устройство $d:"
  tune2fs -l "$d" 2>/dev/null | grep -i 'default mount options'
done

⚠️ Если в выводе суперблока есть параметр

journal_data

— режим активируется ядром по умолчанию при каждом монтировании, даже если в

/etc/fstab

он явно не указан!

💡 В ЧЁМ СУТЬ

Опцию

data=journal

исторически любили включать «для железобетонной надёжности» под базы данных, транзакционные логи или серверы 1С:Предприятия.

На практике за это платили колоссальным падением производительности дисковой подсистемы и деградацией SSD, получая взамен мнимую безопасность. Реальную сохранность данных дают качественные ИБП, корректная работа приложения с системным вызовом

fsync()

и регулярные проверенные бэкапы, а не костыли на уровне драйвера ФС.

Запас времени на миграцию ещё есть, но найти и перевести такие разделы в стандартный

data=ordered

лучше уже сейчас.

#skills #linux #ext4 #kernel #filesystem #storage #sysadmin #admin_future

🌐 Сайты Canonical под затяжной DDoS-атакой. Ваши обновления не должны зависеть от чужого аптайма

Коллеги, поучительная инфраструктурная история, которая регулярно повторяется с любым крупным апстримом.

📌 ФАКТЫ
Атака на апстрим: 8 октября Canonical официально сообщила о «sustained DDoS» на свои публичные веб-ресурсы и предупредила о нестабильности и периодической недоступности инфраструктуры.

Что затронуто: по данным профильных изданий (Phoronix), лежали основной портал Ubuntu и прямая загрузка установочных ISO-образов. Полный перечень задетых сервисов компания не раскрывает.

Мониторинг доступности: оперативный статус отслеживается на status.canonical.com.

🛠 ЛОКАЛЬНЫЙ КЭШ ПАКЕТОВ ЗА 10 МИНУТ
Разворачиваем прозрачный кэширующий прокси, чтобы не зависеть от внешних зеркал при каждой установке пакета:

Bash

# 1. Сервер кэша (Debian / Ubuntu) — поднимается одной командой
apt update && apt install apt-cacher-ng    # служба слушает порт TCP/3142

# 2. Настройка клиентских машин через конфиг APT:
echo 'Acquire::http::Proxy "http://apt-cache.lan:3142";' > /etc/apt/apt.conf.d/01proxy
apt update

Плюсы решения:

Любой пакет скачивается из интернета ровно один раз на весь офис или дата-центр.

Вся последующая раскатка по серверному парку идёт на скорости локальной сети (1–10 Гбит/с).

При падении апстрима или внешнего канала уже выкачанные версии пакетов остаются мгновенно доступны для переустановки и деплоя.

⚠️ ЧТО ЕЩЁ ОБЯЗАТЕЛЬНО ДЕРЖАТЬ НА СВОЕЙ ПОЛКЕ
Базовые ISO: проверенные дистрибутивы Linux (Debian, Ubuntu LTS, Alma/Rocky) и образы Windows Server со сверенными контрольными суммами (SHA256).

Платформы виртуализации: инсталляторы Proxmox VE, образы ESXi, вендорские драйверы RAID-контроллеров, HBA и сетевых карт, а также прошивки для IPMI/iLO/iDRAC.

Шаблоны: золотые образы ВМ (cloud-init / sysprep) и закэшированные базовые слои Docker-контейнеров во внутреннем реестре.

💡 В ЧЁМ СУТЬ

Аварийное восстановление упавшего сервера слишком часто начинается с оптимистичной фразы: «Сейчас по-быстрому скачаю свежий образ».

В день атаки на вендора, аварии на магистральном провайдере или внезапных сетевых ограничений этот сценарий мгновенно оборачивается часами простоя боевого сервиса. Локальный кэш пакетов и собственная локальная библиотека образов — простейшая и копеечная страховка вашего времени.

#linux #ubuntu #apt #mirror #ddos #disasterrecovery #network #infrastructure #sysadmin #admin_future

🤖 Sashiko от Google: AI-ревьюер ядра Linux проверил 191 тысячу патчей. 463 CVE за год ссылаются на него

Коллеги, интереснейший доклад с Linux Plumbers 2026 — вторая сторона медали в истории про «лавину AI-патчей в ядре».

📌 ФАКТЫ (доклад Романа Гущина, Google)
Что такое Sashiko: открытый агентный инструмент для автоматизированного ревью патчей ядра Linux, работающий в связке с моделями Gemini и другими LLM.

Масштаб работы менее чем за год:

191 000+ проведённых код-ревью в 99 официальных списках рассылки (LKML и подсистемы);

19 млн+ автоматизированных обращений к Git-дереву;

7 600+ ответов от 1 100+ живых разработчиков ядра на замечания и баг-репорты Sashiko;

1 277 коммитов в апстрим основного ядра и 1 567 в ветку linux-next содержат прямые ссылки на отчёты инструмента;

463 CVE ядра Linux, выпущенных в этом году, напрямую цитируют выводы Sashiko.

Роадмап проекта: запуск локального CLI-режима для проверки кода из терминала разработчика, формирование постоянной базы найденных багов и пре-ревью собственных коммитов.

💡 В ЧЁМ СУТЬ ДЛЯ СИСАДМИНА

Если в понедельник мы обсуждали, что мейнтейнеров ядра буквально заваливает сгенерированными AI-патчами, то сегодня виден встречный процесс: AI на стороне ревью отлавливает критические баги и регрессии задолго до того, как они попадут в релиз.

Итог для эксплуатации один: количество регистрируемых CVE в ядре будет только расти. И это индикатор качественной и глубокой проверки кода, а не признак того, что Linux стал хуже.

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

🛠 БЫСТРЫЙ ЧЕК СЕРВЕРА: НА СКОЛЬКО СВЕЖЕМ ЯДРЕ ВЫ ЖИВЁТЕ
Bash

# 1. Текущая активная версия ядра и время с последнего ребута ноды
uname -r; uptime -s

# 2. Проверяем, есть ли в /boot ядро новее работающего (Debian / Ubuntu)
ls -t /boot/vmlinuz-* 2>/dev/null | head -1

# 3. Висит ли флаг обязательной перезагрузки после обновлений пакетов
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required

#linux #kernel #ai #google #opensource #cve #security #sysadmin #admin_future

📅 Завтра, 13 октября, три события в один день: Patch Tuesday, конец основной поддержки Server 2022 и блокировка NTLMv1 для SSO

Коллеги, понедельник. Неделя, которую критически важно спланировать заранее, чтобы не тушить пожары на выходных.

📌 ЧТО ПРОИСХОДИТ
Октябрьский Patch Tuesday: плановый пакет обновлений безопасности Microsoft. Помним, что в сентябре был рекордный объем исправлений (около 970 CVE) и неприятные сайд-эффекты для инфраструктуры.

Windows Server 2022 — завершение Mainstream Support: прекращается выпуск несекьюрных хотфиксов и прием бесплатных обращений по общим багам. Фаза Extended Support (ежемесячные обновления безопасности) продолжится до октября 2031 года.

Блокировка NTLMv1 для SSO: плановое переключение ключа BlockNtlmv1SSO в дефолтный режим Enforce (1) на Windows 11 24H2 и Windows Server 2025. Под прямым ударом — бесшовный вход по Wi-Fi (802.1X) и VPN через MS-CHAPv2 (если на машинах не задействован Credential Guard).

🛠 СЕГОДНЯ, ДО ПРИХОДА ОБНОВЛЕНИЙ
Обязательно снимаем свежие бэкапы/снапшоты контроллеров домена и критических хостов до установки апдейтов:

PowerShell

# 1. Смотрим последние установленные обновления в системе
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

# 2. Ищем, кто в сети все еще генерирует NTLMv1 SSO (события аудита Event ID 4024)
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' `
  -FilterXPath '*[System[EventID=4024]]' -MaxEvents 20 -ErrorAction SilentlyContinue

🛡 ОПЕРАЦИОННЫЙ ПЛАН НА НЕДЕЛЮ
Вторник: не бросаемся ставить всё подряд — сначала прицельно вычитываем список zero-day и свежие записи в каталоге CISA KEV.

Среда: раскатываем апдейты на тестовую группу серверов. Хосты Remote Desktop Services (RDS) тестируем отдельно и с пристрастием (учитывая сентябрьские зависания сессий).

Четверг – пятница: плановый накат на основной прод-парк. Держим открытым Microsoft Update Catalog — в сентябре критические фиксы для RDS были доступны исключительно там, минуя WSUS/WU.

Контроль всю неделю: внимательно следим за тикетами о проблемах с офисным Wi-Fi и подключением к VPN — с высокой вероятностью это будет блокировка NTLMv1 SSO, а не проблемы с физической сетью или точками доступа.

#patchtuesday #windows #ntlm #windowsserver #sysadmin #security #admin_future

🚨 AhsayCBS: два zero-day, SYSTEM на сервере бэкапов без пароля. Эксплуатация началась через сутки после обнаружения

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

📌 ФАКТЫ (отчет Field Effect от 9 октября)
Связка уязвимостей:

CVE-2026-105133 (CVSS 5.5) — логическая ошибка аутентификации в функции проверки пароля checkSysPwd;

CVE-2026-105134 (CVSS 9.3) — критическая инъекция команд ОС (Command Injection) в компоненте Replication Receiver.

Результат цепочки: удаленное неаутентифицированное исполнение произвольного кода (RCE) с наивысшими правами NT AUTHORITY\SYSTEM.

Под ударом: все версии платформы до 10.3.4 включительно. Официальный исправленный релиз на момент публикации вендором не обозначен.

Активная эксплуатация: реальные атаки зафиксированы поздно вечером 7 октября — всего через сутки после первых сигналов. За первые 24 часа подтверждена компрометация как минимум 5 организаций.

Анатомия закрепления: злоумышленники конфигурировали поддельный приемник репликации, заливали JSP веб-шелл, разворачивали скрытый майнер XMRig под маской легитимного процесса Microsoft Edge и прописывали фальшивую службу обновления браузера для автозагрузки.

🛠 ФОРЕНЗИКА И ПОИСК СЛЕДОВ (PowerShell на хосте AhsayCBS)
PowerShell

# 1. Поиск свежих JSP-файлов и шеллов за последнюю неделю
$installDir = 'C:\Program Files\AhsayCBS'
Get-ChildItem -Path $installDir -Recurse -Filter *.jsp -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } |
  Select-Object FullName, LastWriteTime

# 2. Выявление процессов msedge, запущенных вне легитимной директории Microsoft
Get-CimInstance Win32_Process | 
  Where-Object { $_.Name -like 'msedge*' -and $_.ExecutablePath -notlike '*\Microsoft\Edge\*' } |
  Select-Object ProcessId, Name, ExecutablePath

# 3. Аудит подозрительных служб с «Edge» в названии
Get-CimInstance Win32_Service | 
  Where-Object { $_.DisplayName -match 'Edge' -or $_.Name -match 'Edge' } |
  Select-Object Name, DisplayName, PathName, StartMode

💡 В ЧЁМ СУТЬ

В данном кейсе атакующие ограничились установкой майнера, но уровень привилегий SYSTEM на сервере бэкапов автоматически означает полный доступ к архивам данных, теневым копиям и служебным учетным записям всех защищаемых хостов предприятия.

Правило изоляции едино для любого решения (Ahsay, Veeam, Proxmox Backup Server, Commvault):

Любые порты управления, API и сервисы репликации никогда не должны смотреть в публичный интернет — только выделенный Management VLAN, изолированный VPN или защищенный туннель.

Если на сервере бэкапов обнаружены следы веб-шелла или сторонних служб — машина считается скомпрометированной целиком. Она не «лечится» установкой патча, а подлежит полной переустановке с чистого образа с обязательным отзывом и перевыпуском всех ключей доступа.

#security #backup #zeroday #ahsay #threathunting #powershell #windows #sysadmin #admin_future

🤖 Линус Торвальдс пишет патч для ядра с Claude Code. И честно это указывает

Коллеги, интересное из жизни ядра — без хайпа и строго по фактам.

📌 ФАКТЫ
Ветка в репозитории: в персональном Git-дереве Торвальдса появилась ветка noref-filemap-read-with-llm.

Архитектурная суть: оптимизация сценария, когда множество параллельных потоков одновременно читают один и тот же файл небольшими порциями. Чтение из Page Cache переводится в режим без инкремента счётчика ссылок на folio (page refcount contention). Именно постоянное атомарное обновление счётчика ссылок создаёт узкое горлышко и конкуренцию на кэш-линиях CPU при интенсивном параллельном I/O.

Честный commit message: в описании патча Линус прямо зафиксировал, что изменения подготовлены «LLM-ассистентом (Claude Code) под моим руководством». Модель помогла со скелетом кода, синтетическими тестовыми программами, перекрёстным ревью и черновиком сопроводительного письма.

Верификация: все бенчмарки и профилирование Торвальдс проводил лично на своём рабочем железе. Патчи ещё не влиты в апстрим, вероятная цель — окно слияния Linux 7.4.

Индустриальный контекст: одновременно с этим NVIDIA представила Boro — локальный AI-инструмент, заточенный под разработку и верификацию кода ядра на языке Rust.

💡 В ЧЁМ СУТЬ ДЛЯ СИСАДМИНА

Важен не сам факт задействования нейросетей, а культура инженерной ответственности:

Архитектурную постановку задачи, контроль логики и валидацию замеров выполняет живой сеньор-инженер. Факт использования ассистента декларируется открыто, а персональная ответственность за продакшен-код остаётся на авторе коммита.

Ровно по этой модели должна строиться эксплуатация любого AI-инструмента в инфраструктуре: генерировать скрипт или конфиг может модель, но валидирует, пушит в прод и несёт ответственность только сисадмин.

При принятии коммитов прямую выгоду по I/O получат высоконагруженные веб-серверы (Nginx/Envoy, отдающие статику), ноды контейнеризации с общими read-only слоями образов и CI/CD сборочные фермы.

#linux #kernel #ai #torvalds #opensource #performance #sysadmin #admin_future

🗓 Patch Tuesday сегодня вечером: как разобрать бюллетень за 15 минут, а не за 3 часа

Коллеги, вторник, 13 октября. Октябрьские обновления Microsoft традиционно начнут раскатываться около 20:00 МСК. Сегодня же официально завершается фаза основной поддержки Windows Server 2022.

📌 АЛГОРИТМ ПРИОРИТИЗАЦИИ НА ВЕЧЕР
Zero-day и CISA KEV (эксплуатация в wild): единственный класс уязвимостей, требующий внеочередной установки в первые 24–48 часов.

Сетевые RCE на внешнем периметре: компоненты, смотрящие наружу (Exchange, RDS Gateway, IIS, Always On VPN), берутся во вторую очередь в рамках текущего спринта.

Внутренний контур (LPE, Client-side): штатный цикл тестирования (лабораторная среда → пилотные серверы → общий продакшен-пул).

Раздел Known Issues: обязательное чтение перечня известных проблем в KB до нажатия кнопки одобрения во WSUS/SCCM (в сентябре это уберегло бы RDS-фермы от мертвых зависаний).

🛠 АВТОМАТИЗАЦИЯ ВЫБОРКИ: KEV И EPSS НА BASH
Bash

# 1. Выгрузка свежих уязвимостей Microsoft, попавших в CISA KEV сегодня
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | \
  jq -r '.vulnerabilities[] 
    | select(.vendorProject=="Microsoft" and .dateAdded=="2026-10-13") 
    | "\(.cveID)\t\(.vulnerabilityName)"'

# 2. Экспресс-запрос скоринга вероятности эксплуатации (EPSS) через API FIRST
# Замените список CVE на целевые идентификаторы из вечернего бюллетеня
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-XXXXX,CVE-2026-YYYYY" | \
  jq -r '.data[] | "\(.cve)\tEPSS: \(.epss)\t(процентиль: \(.percentile))"'

⚠️ КОНТРОЛЬНЫЙ ЧЕКЛИСТ ДО НАЧАЛА РАСКАТКИ
Снапшоты и бэкапы: контроллеры домена, базы данных и шлюзы аутентификации бэкапятся со сбросом транзакционных логов строго до применения обновлений.

NTLMv1 Enforce: клиентские рабочие станции на Windows 11 24H2 и серверы 2025 с корпоративным Wi-Fi/VPN через PEAP-MSCHAPv2 находятся в зоне риска отвала бесшовного входа при отсутствии Credential Guard.

Windows Server 2022: статус Mainstream завершён. Начиная со следующего месяца серверы ветки 2022 будут получать исключительно секьюрные патчи (Extended Support до 2031 года).

#patchtuesday #windows #security #kev #epss #patchmanagement #sysadmin #admin_future

🚨 Atlassian Data Center: чтение файлов без авторизации. Атаки начались через 2 часа после публикации деталей

Коллеги, после ухода Atlassian многие команды в РФ зафиксировали инфраструктуру на self-hosted инстансах Jira и Confluence Data Center. Этот пост — прямой сигнал на аудит периметра.

📌 ФАКТЫ
Идентификатор и критичность: CVE-2026-21589, базовый балл CVSS 9.3 — неаутентифицированное чтение произвольных файлов (Arbitrary File Read) в контексте каталога веб-приложения.

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

Масштаб покрытия: уязвимы Data Center редакции практически всей линейки: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Crucible, Fisheye.

Скорость реагирования ботнетов: первые попытки эксплуатации в wild зафиксированы примерно через 2 часа после выхода технического разбора от исследователей watchTowr. На текущий момент фиксируется массовое автоматизированное сканирование с вычиткой дефолтных путей конфигурационных файлов.

Исправленные релизы вендора:

Plaintext

Jira Software / JSM : 9.12.40 · 10.3.26 · 11.3.12 (JSM: 5.12.40)
Confluence          : 9.2.26  · 10.2.19
Bitbucket           : 9.4.26  · 10.2.8   · 10.5.1
Crowd               : 6.3.7   · 7.0.3   · 7.1.7 · 7.2.4
Bamboo              : 10.2.24 · 12.1.12
Crucible / Fisheye  : 4.9.15

🛠 ВРЕМЕННЫЙ МИТИГЕЙТ (ЕСЛИ НЕТ ВОЗМОЖНОСТИ НАКАТИТЬ ПАТЧ ПРЯМО СЕЙЧАС)
Изоляция сетевого контура: немедленно убрать внешние публикации (0.0.0.0/0) за корпоративный VPN или reverse-proxy с пре-аутентификацией.

Фильтрация на обратном прокси / WAF: заблокировать сигнатуры обращения к внутренним служебным эндпоинтам веб-приложения.

Локальная блокировка веб-сервера:

Для Jira, Confluence, Bamboo, Crowd — подключение модуля Tomcat RewriteValve в конфигурации контейнера сервлетов (server.xml / rewrite.config);

Для Bitbucket — активация правил отсечения запросов через urlrewrite.xml по вендорскому security bulletin.

💡 В ЧЁМ СУТЬ

Чтение файлов без RCE кажется неопасным лишь на первый взгляд.

В каталогах веб-приложений лежат файлы вроде

dbconfig.xml

, содержащие логины и открытые пароли к базам данных PostgreSQL/Oracle, секреты сессий, приватные ключи подписи и API-токены интеграций.

Если ваш инстанс торчал наружу в публичный интернет — простого наката патча недостаточно. После обновления обязательно проведите ротацию пароля сервисной учетной записи БД в СУБД и перевыпустите все связанные токены интеграций.

#security #atlassian #jira #confluence #bitbucket #cve #threathunting #devops #sysadmin #admin_future

🐍 Python 3.15 вышел: UTF-8 по умолчанию может сломать ваши скрипты на Windows

Коллеги, важный релиз для всех, кто пишет скрипты автоматизации, интеграции и парсеры системных логов на Python.

📌 ФАКТЫ
Стабильный релиз: 9 октября представлена финальная ветка Python 3.15.

UTF-8 Mode по умолчанию (PEP 686): встроенная функция open() без явного параметра encoding теперь всегда открывает файлы в кодировке UTF-8, игнорируя региональные параметры операционной системы (locale.getencoding()).

Ленивые импорты (PEP 810): синтаксис вида lazy import json — модуль парсится и загружается в память только при первом фактическом вызове атрибута (включается строго явно флагом или директивой). Существенно срезает время холодного старта CLI-утилит.

Экспериментальный JIT: прирост производительности +7–8% на архитектуре x86_64 под Linux.

Сэмплирующий профилировщик Tachyon: низкоуровневый профилировщик без остановки рантайма. Умеет аттачиться к уже запущенному production-процессу и строить flame graph узких мест.

Новые базовые типы: добавлены нативные frozendict (неизменяемый словарь) и sentinel (удобные уникальные маркеры-заглушки вместо object()).

⚠️ ГДЕ ВЫСТРЕЛИТ НА WINDOWS
Исторически на русскоязычных Windows-серверах и рабочих станциях open() по умолчанию поднимал кодировку CP1251 (ANSI) для файлов и CP866 (OEM) для консольных утилит.

После обновления интерпретатора до 3.15:

Выгрузки отчетов, реестров и прайсов из 1С:Предприятия;

Экспортированные CSV-таблицы из классического Excel;

Текстовые журналы старых служб, конфиги и .bat/.cmd скрипты в кодировке ANSI

при попытке прочитать их «по старинке» (open('file.txt')) мгновенно уронят процесс с ошибкой UnicodeDecodeError: 'utf-8' codec can't decode byte... либо тихо запишут кракозябры при сохранении.

🛠 КАК ПРАВИЛЬНО ОБРАБАТЫВАТЬ КОДИРОВКИ
1. Явная фиксация кодировки в Python
Python

# Чтение локальных Windows-выгрузок (1С, Excel, старые сервисы)
with open('export_1c.csv', mode='r', encoding='cp1251') as f:
    data = f.read()

# Корректный перехват stdout системных CLI-команд Windows (ipconfig, ping, netstat)
import subprocess

res = subprocess.run(
    ['ipconfig', '/all'], 
    capture_output=True, 
    encoding='cp866', 
    check=True
)
print(res.stdout)

2. Временный откат поведения через переменные окружения
PowerShell

# Принудительное отключение UTF-8 режима для конкретного сеанса PowerShell
$env:PYTHONUTF8 = '0'
python automation_script.py

3. Экспресс-аудит репозитория скриптов перед обновлением Python
Bash

# Ищем потенциально опасные вызовы open() без аргумента encoding в проекте
grep -rnE "open\([^)]*\)" --include="*.py" . | grep -v "encoding="

💡 В ЧЁМ СУТЬ

Явный параметр

encoding=

в каждом вызове

open()

— базовый стандарт инженерной гигиены, делающий скрипт полностью переносимым между Windows Server, Debian/Ubuntu и любыми версиями рантайма.

Перед тем как обновлять глобальный Python на серверах автоматизации или в контейнерах сборщиков, прогоните аудит кода регуляркой выше.

#skills #python #automation #windows #1c #linux #devops #sysadmin #admin_future