Восстановили взломанный Proxmox из резервной копии? Это ещё не значит, что атакующий ушёл

История массовых атак на Proxmox VE в августе–сентябре 2026 года напоминает хороший технический детектив. Злоумышленники получали административный доступ без пароля, устанавливали майнеры и eBPF-руткиты, проникали в виртуальные машины и заранее создавали несколько способов вернуться после восстановления инфраструктуры.

Особенно показателен инцидент с кластером из 22 гипервизоров. Администраторы восстановили файловые системы, сменили пароли и SSH-ключи, но атакующие вскоре снова появились внутри. Причин оказалось две:

🚀 руткит скрывал вредоносные файлы от стандартных утилит, поэтому rsync --delete просто не видел, что нужно удалить

🚀 созданные злоумышленниками пользователи и десятки API-токенов сохранились в общей конфигурации Proxmox, синхронизируемой через pmxcfs

В статье подробно разбирается критическая уязвимость CVE-2023-54391, позволявшая обойти аутентификацию через API Proxmox, методы сокрытия майнеров и типичные ошибки при восстановлении.

Главный вывод выходит далеко за рамки Proxmox: после компрометации root недостаточно удалить вредоносное ПО и восстановить файлы. Необходимо заново установить доверие ко всей системе — проверить кластерную конфигурацию, пользователей, API-токены, ACL, SSH-ключи и гостевые машины, а восстановление выполнять из независимой доверенной среды.
И конечно, административный интерфейс гипервизора не должен смотреть в Интернет. VPN, отдельная управляющая сеть, MFA, внешнее журналирование, независимый мониторинг и защищённые от удаления резервные копии здесь не паранойя, а базовая гигиена.

Читать разбор на Хабре

@usr_bin_linux

Куда на самом деле ходят процессы на сервере?

RustNet — терминальный сетевой монитор, который показывает активные TCP-, UDP- и QUIC-соединения и по возможности связывает их с конкретными процессами.

В интерактивном TUI можно увидеть состояние соединений, адреса, порты и объем трафика, отфильтровать данные по процессу или протоколу, а также определить HTTP, DNS, SSH, QUIC и TLS-соединения по SNI. Интерфейс работает через SSH, поэтому инструмент удобно использовать при диагностике удаленных серверов.

Дополнительные возможности:

🚀 просмотр слушающих сокетов и сетевой активности процессов

🚀 пассивная аналитика DNS-запросов

🚀 экспорт трафика в PCAP и PCAPNG для Wireshark

🚀 headless-режим с JSON для скриптов и мониторинга

🚀 снижение привилегий после запуска и платформенная изоляция

🚀 поддержка Linux, macOS, Windows и FreeBSD

Хороший вариант, когда ss, netstat и lsof уже не дают полной картины, а запускать Wireshark или разбирать tcpdump пока не хочется.

Для захвата пакетов потребуются соответствующие системные права, а на Windows — Npcap.

Репыч на Гитхаб

@usr_bin_linux

Когда одного AI-агента уже мало

Tmux-Orchestrator — экспериментальный набор скриптов для организации нескольких Claude Code-агентов в tmux. Один агент выступает оркестратором, другие становятся менеджерами проектов и инженерами, получают отдельные задачи и работают параллельно в разных терминальных сессиях.

Оркестратор может проверять состояние агентов, передавать им сообщения и назначать повторные проверки. Благодаря tmux работа продолжается после отключения от SSH-сессии, если удаленный сервер остается запущенным.

В репозитории реализованы:

🚀 иерархия «оркестратор → менеджеры проектов → инженеры»

🚀 параллельная работа с несколькими кодовыми базами

🚀 обмен сообщениями между агентами через окна tmux

🚀 планирование повторных проверок и продолжение задач

🚀 регулярные Git-коммиты, ветки и точки восстановления

🚀 наблюдение за работой агентов в реальном времени

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

Репыч на Гитхаб

@usr_bin_linux

Linux, TCP и 53 минуты до root — в эфире рубрика «Чтиво на выходные»

Что происходит, когда десятилетняя ошибка в сетевом стеке Linux встречается с AI-моделью, способной превратить уязвимость в рабочий эксплойт меньше чем за час?

Автор статьи подробно разбирает CVE-2026-98432 — use-after-free в обработке TCP-соединений, появившийся еще в ядре 4.4. Уязвимый код срабатывает до передачи данных приложению: атакующему достаточно взаимодействовать с открытым IPv4-портом.

Внутри — объяснение:

🚀 как устроено TCP-рукопожатие и request socket

🚀 откуда возникает гонка между ядрами процессора

🚀 как освобожденная память превращается в утечку данных и запись за границы объекта

🚀 почему исправление заняло всего две строки

🚀 как AI ускоряет путь от найденного бага до рабочего remote-root эксплойта

Но главный вопрос статьи шире одной CVE. Если раньше сложная эксплуатация уязвимости могла занимать недели работы редкого специалиста, то теперь эта стоимость стремительно снижается. При этом сроки доставки патчей от апстрима до серверов практически не меняются.

Получается неприятный разрыв: эксплойты создаются быстрее, а процессы обновления инфраструктуры остаются прежними.

Читать на Хабре

@usr_bin_linux

Швейцарский нож сетевого инженера — теперь в одном веб-интерфейсе

Networking Toolbox объединяет более сотни инструментов для диагностики сетей, расчетов и проверки конфигураций.

Внутри есть:

🚀 калькуляторы IPv4/IPv6-подсетей и VLSM

🚀 операции с CIDR: разделение, объединение, сравнение и поиск свободных диапазонов

🚀 генераторы и валидаторы DNS-записей

🚀 инструменты для DNSSEC, SPF, DKIM, DMARC и CAA

🚀 анализ HTTP-заголовков, редиректов, CORS и cookie

🚀 проверка TLS-сертификатов, версий протокола и наборов шифров

🚀 BGP-, ASN-, RDAP- и GeoIP-запросы

🚀 инструменты для DHCP, MAC-адресов и Option 43

Проект выполнен как offline-first-приложение: многие расчеты работают локально в браузере, без передачи исходных данных сторонним сервисам. Проверки DNS, TLS, BGP и удаленных узлов, конечно, потребуют сетевого доступа.

Networking Toolbox можно открыть на публичном сайте или развернуть внутри собственной инфраструктуры. Самый быстрый вариант:

docker run -p 3000:3000 lissy93/networking-toolbox

Репыч на Гитхаб

@usr_bin_linux

Как инженеры на самом деле восстанавливают Linux-серверы

Автор статьи собрал статистику прохождения учебных инцидентов в Linux-окружении: пользователи получали сервер со сломанным сервисом и самостоятельно искали причину — без готовой последовательности команд.
За месяц участники взяли в работу 366 инцидентов. Успешно завершились 192 попытки, а медианное время восстановления составило 7 минут 49 секунд. При этом среди тех, кто дошел до проверки результата, доля успешных решений приблизилась к 78%.

Интереснее всего сравнение сценариев:

🚀 CrashLoopBackOff исправили в 90% попыток

🚀 ошибку 502 Bad Gateway — в 85,7%

🚀 высокую загрузку CPU — в 69%

🚀 недоступную базу данных — в 49,1%

🚀 Too many open files — в 42,9%

🚀 проблемы с OOM Killer — только в 40%

Статистика показывает любопытную вещь: конкретный симптом вроде CrashLoopBackOff или 502 сразу задает направление расследования. А сообщение «приложение не запускается» оставляет слишком много вариантов — конфигурация, права, зависимости, окружение или системные ресурсы.

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

Читать статью на Хабре

@usr_bin_linux

Too many open files — но где эти файлы?

Ошибка Too many open files часто заставляет администратора искать огромные логи и забытые файлы. Однако файловые дескрипторы расходуют не только файлы, но и сокеты, каналы и другие ресурсы процесса.

В статье на примере разбирают:

🚀 почему сервис может исчерпать лимит, создавая одни только сокеты

🚀 чем фактический лимит процесса отличается от результата ulimit -n в SSH-сессии

🚀 как проверить дескрипторы и ограничения через /proc/PID/fd и /proc/PID/limits

🚀 почему увеличение LimitNOFILE может лишь отсрочить повторное падение

🚀 как отличить недостаточный лимит от утечки ресурсов

🚀 чем ошибки EMFILE и ENFILE отличаются друг от друга

Читать статью на Хабре

@usr_bin_linux

🦀 KiviDB — многопоточная альтернатива Redis и Valkey на Rust

KiviDB — высокопроизводительное in-memory хранилище, которое использует все доступные ядра процессора и поддерживает протоколы RESP2 и RESP3. Благодаря совместимости с Redis для подключения можно использовать существующие клиенты, библиотеки и привычный redis-cli.

Возможности проекта:

🚀 шардированная многопоточная архитектура

🚀 основные структуры данных и Redis-совместимые команды

🚀 полнотекстовый поиск с фильтрацией по текстовым, числовым и теговым полям

🚀 встроенный векторный поиск с индексами FLAT и HNSW

🚀 Redis Stack-совместимые команды семейства FT.*

🚀 сохранение данных через снимки и опциональный append-only file

🚀 поддержка Lua-скриптов и TLS при сборке с соответствующими функциями

🚀 готовый образ Docker и оператор для Kubernetes

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

Проект можно запустить параллельно с Redis: по умолчанию KiviDB использует порт 6380.

docker run -d -p 6380:6380 kividb/kividb
redis-cli -p 6380 PING

KiviDB на GitHub

@usr_bin_linux

⚓️ Когда обычных способов использовать sed уже недостаточно

Обычно sed применяют, чтобы заменить строку в конфигурационном файле или быстро обработать поток текста. Но поскольку его команды вместе с регулярными выражениями образуют Тьюринг-полный язык, теоретически на нём можно написать что угодно.

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

По пути пришлось научить потоковый редактор:

🚀 выполнять двоичное сложение, вычитание, умножение и деление

🚀 генерировать псевдослучайные числа

🚀 организовывать циклы, ветвления и повторное использование кода

🚀 хранить и изменять состояние игрового поля

🚀 проверять корректность расстановки кораблей

🚀 анализировать результаты выстрелов и выбирать следующий ход

В результате получился не просто необычный эксперимент, а подробный разбор вычислений на регулярных выражениях и внутренних механизмов sed: pattern space, hold space, меток и переходов.

Читать статью на Хабре

@usr_bin_linux

До 80% экономии на GPU и эксплуатации: знакомьтесь, «Штурвал ML/AI»

У «Штурвал» появилась отдельная редакция, которая запускает ML- и AI-нагрузки в Kubernetes, эффективно использует GPU и управляет всем жизненным циклом моделей — от экспериментов до продакшена.

Что умеет «Штурвал ML/AI»:
◾️объединять GPU в общий пул и распределять ресурсы между командами;
◾️предоставлять готовый ML-стек на базе Kubeflow и MLflow;
◾️запускать обучение и инференс в одном кластере;
◾️обновлять ML-компоненты вместе с кластером;
◾️обеспечивать безопасность и контроль доступа.

По расчетам разработчика, платформа помогает сократить затраты на GPU и эксплуатацию до 80%.

Поддерживаются NVIDIA A100, H100 и L40S, а также Astra Linux, РЕД ОС, Rosa, Alt Linux, Ubuntu и Debian.

Подробнее о «Штурвал ML/AI» тут

🐳 Docker без магии: что происходит между docker build и docker run

Docker часто начинают использовать с копирования готового docker-compose.yml. Контейнеры запускаются — всё хорошо. Но позже могут возникнуть трудности: данные исчезают после пересоздания, образ неожиданно меняется, сборка занимает вечность, а секреты случайно оказываются внутри публичного image.

В статье подробно разбираются основы Docker:

🚀 чем контейнер отличается от образа и виртуальной машины

🚀 как изоляция строится на namespaces и cgroups

🚀 как устроены слои образа и механизм Copy-on-Write

🚀 что происходит на разных этапах жизненного цикла контейнера

🚀 чем volumes отличаются от bind mounts

🚀 зачем нужен .dockerignore и как он защищает от попадания секретов в образ

🚀 почему не стоит использовать тег latest в продуктивной среде

🚀 чем отличаются CMD, ENTRYPOINT, ARG и ENV

🚀 как правильно располагать инструкции в Dockerfile, чтобы использовать кэш слоёв

🚀 зачем нужны multi-stage builds и HEALTHCHECK

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

Читать статью на Хабре

@usr_bin_linux

🐧 Как работает mount в Linux

Монтирование файловых систем относится к тем темам, с которыми рано или поздно сталкивается каждый Linux-администратор. Нужно подключить новый диск, примонтировать флешку, исправить /etc/fstab или понять, почему раздел упорно сообщает target is busy.

В статье разобраны:

🚀 источники и точки монтирования

🚀 команды lsblk, blkid, findmnt и df

🚀 ручное подключение и безопасное размонтирование устройств

🚀 поиск процессов, удерживающих файловую систему

🚀 режимы ro, rw, noexec, nosuid и другие параметры

🚀 автоматическое монтирование через /etc/fstab

🚀 использование UUID вместо изменяемых имён вроде /dev/sda1

Читать статью

@usr_bin_linux

Kora — настольная ОС на Linux для ИИ-энтузиастов

В 2027 году должна выйти новая настольная ОС Kora, ориентированная не на массового пользователя, а на разработчиков, создателей контента и тех, кто ежедневно работает сразу с несколькими ИИ-моделями.

Главная идея проекта — объединить облачные и локальные модели внутри одной среды. Пользователь сможет начать работу с OpenAI, продолжить с инструментами Anthropic, а часть задач передать локальной модели, сохранив общий контекст.

Среди заявленных возможностей:

🚀 «нейронная файловая система» с семантическим поиском по содержимому документов

🚀 единый контекст для разных ИИ-провайдеров

🚀 локальное хранение памяти и пользовательских данных

🚀 поддержка x86-64 и компьютеров на Snapdragon

🚀 запуск Windows-приложений через слои совместимости

🚀 собственные приложения и SDK для разработчиков

🚀 запуск локальных моделей на производительных рабочих станциях

Kora строится на Linux и рассчитана как минимум на системы с 64 ГБ оперативной памяти.

Читать подробнее в статье

@usr_bin_linux

🔐 Быстрый аудит безопасности Linux-сервера одним Bash-скриптом

vps-audit — скрипт для первичной проверки безопасности и производительности Linux-сервера.

Скрипт проверяет:

🚀 настройки SSH, включая вход под root и авторизацию по паролю

🚀 состояние UFW, firewalld, iptables или nftables

🚀 наличие и конфигурацию Fail2ban и CrowdSec

🚀 открытые порты и запущенные сервисы

🚀 неудачные попытки авторизации

🚀 доступность системных обновлений

🚀 парольные политики, SUID-файлы и журналирование sudo

🚀 загрузку CPU, использование памяти и свободное место на дисках

Результаты выводятся в консоль со статусами PASS, WARN и FAIL, а затем сохраняются в текстовый отчёт с рекомендациями. Пороговые значения можно настроить под собственную инфраструктуру.

vps-audit на GitHub

@usr_bin_linux