sysadmin.su

Python и DevOps: Ключ к автоматизации Linux (2022) Это практическое руководство научит вас использовать Python для повседневных задач администрирования Linux с помощью наиболее удобных утилит DevOps, включая Docker, Kubernetes и Terraform. #Книга #RU #Python #DevOps #Docker #Terraform #Kubernetes #Linux

Kubesplaining — CLI-инструмент для анализа безопасности Kubernetes, написанный на Go. Он позиционируется как «Cloudsplaining для Kubernetes». В отличие от большинства сканеров (Kubescape, Trivy, Polaris), которые ищут отдельные misconfigurations, данный инструмент строит граф privilege escalation и показывает реальные многошаговые цепочки атаки от любого непривилегированного субъекта до критических: - cluster-admin / system:masters - node-escape (привилегированные поды + hostPath) - доступ к секретам в kube-system Он использует BFS поиск по RBAC + состоянию подов и выдаёт полную цепочку с объяснениями, evidence и remediation. Ключевые возможности: - Модули (всего ~45 правил): RBAC (wildcard, impersonation, bind/escalate и т.д.), Pod Security, NetworkPolicy, Admission Webhooks, Secrets, ServiceAccounts, Least-Privilege (на основе audit logs). - Поддержка живого кластера, snapshot (JSON) и отдельных манифестов. - Отличные отчёты: интерактивный HTML, JSON, CSV, SARIF (для GitHub Code Scanning). - CI-friendly: --baseline, --ci-mode, delta-анализ. - Полностью offline-анализ после скачивания snapshot'а. - Хорошая документация, примеры remediation (kubectl patch, Kyverno/Gatekeeper). Здесь можно посмотреть демо отчет.

Проектирование POSTGRES: как задумывалась популярная СУБД Чтиво на выходные. 8 июля у PostgreSQL юбилей — ей исполняется 30 лет. В 1996 году Марк Фурнье из компании Networking Services предоставил первый внешний сервер для разработки опенсорсного проекта Postgres. До этого СУБД разрабатывали на мощностях Калифорнийского университета в Беркли . В день рождения PostgreSQL на Хабре опубликовали перевод статьи, которая послужила основой этой СУБД. Кстати, у неё тоже юбилей — 40 лет с момента выхода. @usr_bin_linux

Massimiliano Oldani (sgrakkyu) опубликовал PoC, который из непривилегированного процесса внутри изолированного по сети контейнера даёт полноценный побег на хост с root. В основе — свежезакрытая уязвимость IPv6-стека ядра Linux: при сборке UDPv6-фрагментов через splice() ядро выделяло буфер только под заголовки, забывая про перенос выровненных байтов (fraggap), и запись уходила за конец объекта прямо в служебную структуру skb_shared_info. Дальше один испорченный байт nr_frags разворачивается в page use-after-free и технику Dirty Pagetable с произвольным чтением/записью ядра: KASLR обходится через SMP-трамплин, SELinux глушится подменой пролога avc_denied(), а сам побег из контейнера делается через core_pattern. Всё срабатывает детерминированно, без heap-grooming и без каких-либо привилегий. Баг тихо жил с ядра 6.0, но эксплуатировать его стало возможно только с версии 6.6, после которой он попал во все поддерживаемые ветки и был незаметно убран коммитом в середине июня — без CVE, без advisory и без бэкпорта в stable, что автор и критикует: фикс лежит в открытом дереве, фактически раздавая рабочий 0-day. Опубликованный PoC намеренно ослаблен и работает только на ядрах без CONFIG_INIT_ON_ALLOC (RHEL/CentOS). Боевую версию обещают после выхода патчей.

Трансляция SPbLUG (@spblug) Тема: Синхронизация времени: история, протоколы, особенности. От первых часов до современных серверов и протоколов. Докладывает: Михаил, главный инженер ООО "Сети WEBA" Синхронизация времени: история, протоколы, особенности. https://rutube.ru/video/0c9684977690d5b9c6927cc9d9beec76/ UPD Трансляция закончилась, запись доступна по ссылке + прицепил к посту

Prom++: как сжать разметку метрик Prometheus и снизить расход памяти в 2,5 раза с помощью статистики данных Миллионы метрик, чистый код, но аллокатор показывает в разы больше памяти, чем должно занимать «полезное» содержимое. Профайлер светит на парсинг, а вы гадаете: куда деваются мегабайты? Prom++ — это оригинальный Prometheus, переписанный на C++ командой Флант. Оптимизированы потребление RAM (среднем в 7.8 раза меньше), CPU (среднем в 2.2 раза меньше), cобственный оптимизированный WAL, агрессивное сжатие WAL. Ну, и вишенка на торте — практически (отличается в части WAL) полная совместимость с Prometheus. К сожалению, на стоимость долговременного хранения и передачи данных в S3 Prom++ не сильно повляет. Читать статью на Хабр Читать статью о том, как устроен Prom++ Репыч Prom++ на Гитхаб (там же кратко описан механизм миграции с оригинального Prometheus) 📱 Telegram | 📲 MAX

Вышел ceph 20.2.2 (Tentacle) Второй минорный релиз в ветке Tentacle, как обычно всем пользователям этой ветки рекомендуют обновиться. Из отмеченных изменений: * Платформы: добавлена поддержка пакетных установок на Rocky Linux 10 , полный сипсок тут * MDS: пофиксили segfault возникавший из-за некорректной постановки ретрай запросов в очередь * OSD * PGLog: исправлен баг чтоб точно атачить правильную версию к missing list когда игнорятся логи. * Data Integrity: добавлены ассерты поволяющие явно поймать потенциальную порчу данных в OSD missing list * RGW * Lifecycle: починены lifecycle-переносы зашифрованных multipart-объектов * REST: RESTArgs::get_string() теперь корректно декодирует URL в котором есть параметры запроса. * RADOS * Linger: пофиксили много косяков в проверках, устранили use-after-free уязвимость, убрали утечку памяти в LingerOp, и что-то еще. * neorados Watch/Notify: Теперь overflow маркер добовляется в очередь только на первом сообщение. Устранён двойной вызов cleanup при получении ошибки после запуска maybe_cleanup(). И что-то еще. * Async Utilities: пофиксили некорректное удаление объектов из списка async-сервисов * Dashboard * NVMeoF: полный редизайн UI с поддержкой DHCHAP controller key, шифрованием namespace и настройкой secure listeners * Pools & RGW: добавлена валидация stretch-кластера, исправлены проблемы с остановкой\рестартом RGW, баги sync policy, добавлена поддержка MSR EC профиля. * NFS: добавлен тоггл видимости снапшотов CephFS, пофиксили создание экспортов и исправлена проблема с консистентностьб значения path * ceph-volume: при сканировании инвентаря теперь автоматически пропускаются RAM-диски (/dev/ram*) * extblkdev: пофиксили assert в FCM-плагине при работе с multivolume-устройствами Подробнее тут: https://ceph.io/en/news/blog/2026/v20-2-2-tentacle-released/ #ceph #tentacle #release #blog #cephexpert

OpenSSH теперь сам отбивается от брутфорса В Ubuntu 26.04 из коробки едет OpenSSH 10.2 с директивой PerSourcePenalties (представлена в 9.8)— и она включена по умолчанию, хотя в sshd_config про неё ни строчки. sshd сам начисляет «штрафы» подозрительным IP (брутфорс, сканеры, краши) и временно режет им соединения — без iptables, без внешних демонов, без root. Накопился штраф → сокет закрывается ещё до запуска аутентификации. Проверить у себя: sshd -T | grep -i persource ⚠️ Работает по IP, так что VPN/CGNAT/офисы могут наказать сразу группу пользователей. Постоянных банов нет — только временные. Замена ли это Fail2Ban? Нет — скорее быстрая первая линия обороны против шума и лёгкого брутфорса. Fail2Ban остаётся для долгих банов и других сервисов. 🔗 Разбор с экспериментами и сравнением: https://habr.com/ru/articles/1032648/ #ssh #fail2ban #security

QEMUtiny - уязвимости в QEMU, позволяющие получить доступ к хост-окружению из гостевой системы https://www.opennet.ru/opennews/art.shtml?num=65456 Исследователи, которые на днях выявили уязвимость Fragnesia в ядре Linux, опубликовали информацию об уязвимостях в QEMU, позволяющих из гостевой системы получить root-доступ к хост-окружению. Проблеме присвоено кодовое имя QEMUtiny, но CVE-идентификатор пока не назначен. Подготовлен эксплоит, в котором задействованы две уязвимости в коде эмуляции устройства CXL (Compute Express Link). Обе уязвимости присутствуют в коде cxl-mailbox-utils.c. Первая уязвимость проявляется начиная с выпуска QEMU 7.1.0 и приводит к чтению памяти из области вне выделенного буфера из-за того, что функция cmd_logs_get_log() ошибочно трактует запрошенное смещение CEL-лога как индекс в массиве, в то время как оно задаётся в байтах. Вторая уязвимость проявляется начиная с QEMU 11.0.0 и приводит к переполнению буфера в функции cmd_features_set_feature() из-за обработки смещения на структуры при записи атрибутов без проверки, что вычисленное значение "offset + bytes_to_copy" укладывается в размер выбранной структуры. Фактически атака возможна только на последнюю ветку QEMU 11.0.0. Об исправлении пока ничего не сообщается, указано только, что перед раскрытием уязвимости, информация о ней была передана разработчикам QEMU, которые ответили, что поддержка устройства CXL в QEMU реализована не для использования при виртуализации. Эксплоит проверен с кодовой базой QEMU от 11 мая с последним коммитом 5e61afe. Работа эксплоита завязана на раскладку структур в памяти каждой конкретной сборки QEMU и системной libc, но по мнению исследователей, воспользовавшись для сканирования памяти уязвимостью, приводящей к чтению из области вне буфера, можно создать универсальный эксплоит, работающий с разными версиями QEMU. PoC https://github.com/v12-security/pocs/blob/main/qemu/poc.c > CXL Много кто из подписчиков использует? 🌝 Я почему спрашиваю, потому что вообще это вроде как реально используемая штука у "больших" CXL-Тестирование интерконнекта для дата-центров нового поколения https://habr.com/ru/companies/selectel/articles/895416/ Понятно, что QEMU в таком контексте будет использоваться скорей как тестовая среда, а не продовая, но не упомянть не мог, потому что опять комменты на Опёнке почитал

Давно не было Обновление nginx 1.31.0 с устранением RCE-уязвимости, эксплуатируемой через HTTP-запрос https://www.opennet.ru/opennews/art.shtml?num=65442 Уязвимость (CVE-2026-42945), которой присвоен критический уровень опасности, вызвана переполнением буфера в модуле ngx_http_rewrite_module, которое может быть эксплуатировано для выполнения кода с правами рабочего процесса nginx через отправку HTTP-запроса со специально оформленным URI. Проблема проявляется в конфигурациях с директивой "rewrite", в которой в регулярных выражениях используются подстановки масок при помощи неименованных переменных (например, $1 и $2), при условии, что в заменяющей строке имеется символ "?". Пример уязвимой конструкции: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last; Выражения с именованными подстановками уязвимости не подвержены. Например, уязвимость не затрагивает конструкции: rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last; Уязвимость присутствует начиная с версии 0.6.27, выпущенной в марте 2008 года. Причиной появления уязвимости стало то, что буфер выделялся с расчётом, что в него будут записаны неэкранированные данные, а фактически копировались данные после выполнения экранирования спецсимволов, размер которых был больше, так как каждый символ "+", "%" и "&" кодировался не одним, а тремя байтами. NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability PoC https://github.com/depthfirstdisclosures/nginx-rift Другие уязвимости: - CVE-2026-42926 - возможность подстановки данных атакующего в проксируемый запрос при использовании в настройках директивы "proxy_set_body" и обращении к бэкенду через HTTP/2 (proxy_http_version=2). - CVE-2026-40701 - обращение к памяти после её освобождения (use-after-free) в модуле ngx_http_ssl_module, возникающее при обработке ответов от DNS-сервера в конфигурациях с директивой "ssl_ocsp". - CVE-2026-42946 - чтение из области за пределами буфера в модулях ngx_http_uwsgi_module и ngx_http_scgi_module, возникающее при обработке специально оформленного ответа. Проблема может привести к утечке содержимого памяти рабочего процесса или его аварийному завершению. - CVE-2026-42934 - чтение из области за пределами буфера в рабочем процессе, возникающее при обработке ответов с декодированием из кодировки UTF-8 при использовании директивы "charset_map". Проблема может привести к утечке содержимого памяти рабочего процесса или его аварийному завершению. - CVE-2026-40460 - уязвимость в реализации протокола HTTP/3, допускающая спуфинг IP-адреса для обхода авторизации или ограничений. ЗЫ Когда-нибудь в Telegram можно будет залить видос без звука, чтобы его не ужимало до "GIF" на котором ничего не будет видно. А пока добавляем к видео аудио дорожку 🌝

Череда уязвимостей в ядре, приводящих к LPE и container escape продолжается. На этот раз – fragnesia. Это новая LPE уязвимость из семейства Dirty Frag/Dirty Pipe, позволяющая локальному пользователю получить root через corruption page cache в подсистеме XFRM ESP-in-TCP. Эксплойт не требует race condition и работает как deterministic logic bug, что делает эксплуатацию особенно стабильной и опасной. Интересно, что fragnesia появилась как побочный эффект одного из патчей для Dirty Frag. CVE пока не назначена, а фикс пока только в виде небольшого patchset, который ещё не успел попасть во все mainstream kernel releases. P.S. Сегодня последний день подать свой вариант на конкурс и выиграть билет на нашу конференцию БеКон 2026.

🔒 Your Container Is Not a Sandbox - интересное и достаточно объёмное чтиво о том, как microvm могут стать тем самым решением для ситуаций, когда использовать контейнеры становится не так уж и безопасно... https://emirb.github.io/blog/microvm-2026/ Автор показывает и сравнивает несколько технологий, которые доступны для использования сегодня. P. S. Интерактивные элементы на странице - отдельное приятное в этой статье. 🍪 #microvm #firecracker #напочитать -- Микроблог || RSS подписка

Если ещё беспокоитесь за copy.fail в своих кластерах - вот изи-фикс. Маленький DaemonSet, грузит BPF-LSM хук на socket_create и режет любые попытки открыть AF_ALG. Без ребута, без пересборки ядра, без правки cmdline. Работает на Talos Linux, где rmmod архитектурно недоступен (SELinux + lockdown + контроллер не умеет unload). Ставится одной командой: kubectl apply -f https://raw.githubusercontent.com/cozystack/copy-fail-blocker/main/manifests/copy-fail-blocker.yaml https://github.com/cozystack/copy-fail-blocker

https://copy.fail/ налетай, root-а собирай

KubeCon EU 2026 talks are now available All videos from KubeCon + CloudNativeCon Europe 2026 have been uploaded to YouTube and are available for everyone interested. Find them in the following playlists: - KubeCon + CloudNativeCon Europe 2026 (408 videos, including regular talks, keynotes, project lightning talks, Kubernetes SIGs’ updates, Cloud Native University, Data on Kubernetes Day, EnvoyCon, Istio Day, KubeVirt Summit, etc.); - ArgoCon Europe 2026 (31 videos); - FluxCon Europe 2026 (10 videos); - Open Source SecurityCon 2026 (16 videos). #video #events

UUID v4 vs UUID v7 — почему это важно для SRE? Привет, %username%! Сегодня поговорим о вещи, которая на первый взгляд кажется мелкой деталью — выборе версии UUID. Но если ты работаешь с высоконагруженными системами, эта "мелочь" влияет на производительность БД, I/O и даже на читаемость логов во время инцидентов. Что под капотом? UUID v4 — это 128 бит чистой случайности (122 значимых бита). Красиво, уникально, предсказуемо. Но абсолютно хаотично с точки зрения порядка. UUID v7 — первые 48 бит это Unix timestamp в миллисекундах, остальное — случайность. Идентификаторы монотонно возрастают, то есть более новые UUID всегда лексикографически больше старых. Почему это критично для нас с тобой? Проблема UUID v4 — это то, что происходит с B-tree индексом в твоей БД при вставке: - Каждый новый UUID случаен → вставки идут в произвольные места индекса; - Это вызывает page splits (расщепление страниц) и write amplification; - Фрагментация листовых страниц индекса у v4 достигает ~50%, тогда как у v7 — около 0%; - Бенчмарки показывают: вставка с UUID v7 до ~34.8% быстрее, чем с v4 на 10 млн строк; - Запросы (point lookup и range scan) у v7 быстрее за счёт лучшей локальности индекса. SRE-профит от перехода на v7 - ORDER BY created_at становится менее актуальным — можно сортировать прямо по PK; - При разборе инцидента UUID в логах сразу показывает временной порядок событий — экономит время в постмортеме; - Меньше фрагментации → меньше нагрузка на autovacuum в PostgreSQL → меньше сюрпризов в VACUUM-графиках; - Снижается write amplification → меньше нагрузка на диск, особенно актуально для облачных managed БД с billing per I/O. Когда v4 всё ещё ок? - Токены сессий, CSRF-токены — там сортировка не нужна, максимальная случайность важнее; - Системы, где раскрытие временнОго паттерна нежелательно по соображениям безопасности. Переход с v4 на v7 в новых сервисах — это практически бесплатный перформанс буст. Библиотеки есть во всех основных языках, а PostgreSQL 18 получит нативную поддержку uuidv7() из коробки. Делись в комментариях — используешь ли уже UUID v7 в своих системах? Сталкивался ли с фрагментацией индексов из-за v4 в проде? Как решал — автовакуум, партиционирование, или всё-таки миграция на v7? #SRE #DevOps #Database #PostgreSQL #UUID #Performance #IndexOptimization #BackendEngineering