sysadmin.su

Speedtest Tracker — свой мониторинг качества интернет-канала

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

На просторах Гитхаба нашлось интересное self-hosted-решение — Speedtest Tracker. Оно автоматически запускает тесты скорости по расписанию, сохраняет результаты и показывает, как менялось качество соединения.

Что можно отслеживать:

— скорость загрузки и отдачи;

— ping и jitter;

— потерю пакетов;

— успешные и неудачные проверки;

— отклонения от заданных пороговых значений.

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

Если скорость или задержка вышли за допустимые пределы, Speedtest Tracker может отправить уведомление по электронной почте, через webhook или Apprise. Последний позволяет подключить Telegram, Discord, Ntfy, Pushover и множество других сервисов.

Для интеграции с существующим мониторингом есть:

— endpoint с метриками Prometheus;

— готовый дашборд для Grafana;

— отправка данных в InfluxDB 2.x.

Разворачивается в контейнере. Для небольшой инсталляции достаточно SQLite, а для более серьёзного стенда можно использовать MariaDB, MySQL или PostgreSQL.

Самый очевидный вариант использования Speedtest Tracker для мониторинга домашнего подключения, каналов в филиалах, резервных линий и точек выхода в интернет. Также пригодится, если нужно подтвердить, что провайдер систематически не выдерживает заявленные параметры.

Но, как всегда, есть нюанс: тест скорости сам создаёт заметную нагрузку на канал. Поэтому интервал запуска нужно выбирать осознанно. Кроме того, результат характеризует маршрут от сервера, на котором запущен Speedtest Tracker, до выбранного тестового узла. В итоге получается домашний SLA-мониторинг.

Репыч на GitHub

Документация

Интеграция с Prometheus

@usr_bin_linux

💿 Cracking the Linux Boot Code - занятное чтиво от инженеров Oracle о диагностике запуска и загрузки системы...

- Linux Boot-Time Diagnostics Foundations;
- Deep-Dive Linux Boot Diagnostics.

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

#linux #boot #debug

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