Что делают боты, когда всё-таки подбирают пароль к SSH?

Автор развернул honeypot на базе Cowrie и замаскировал его под мощный сервер для обучения нейросетей: 128 ядер, терабайт памяти и четыре NVIDIA H100. Затем намеренно позволил автоматическим ботам подобрать пароль.

Всего за 12,5 часа ловушка получила 1846 подключений, 1524 команды и 219 попыток скачать файлы. После входа боты добавляли свои SSH-ключи, меняли пароль root, удаляли конкурирующие майнеры, закреплялись через cron и загружали вредоносное ПО.

Получился живой разбор автоматизированных атак на публичные серверы — от разведки до превращения взломанной машины в часть ботнета. В конце есть практический чек-лист по защите SSH и поиску следов компрометации.

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

@usr_bin_linux

Ubuntu готовится к большим переменам

Вышла Ubuntu 26.10 Stonking Stingray, и это обновление интересно не только новым GNOME и косметическими изменениями. Canonical продолжает серьёзно перестраивать системные компоненты и постепенно формирует облик будущей Ubuntu 28.04 LTS.

Среди нововведений:

🚀 локальный голосовой ввод Myna без отправки аудио в облако;

🚀 ядро Linux 7.3 и поддержка будущих Intel Nova Lake и AMD Zen 6;

🚀 завершение перехода стандартных файловых утилит на Rust;

🚀 замена dbus-daemon на dbus-broker;

🚀 Sequoia PGP для проверки подписей APT-пакетов;

🚀 улучшения шифрования, аутентификации и корпоративного управления.

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

@usr_bin_linux

LSD — привычный ls, только современнее

LSD — написанная на Rust альтернатива стандартной команде ls. Она делает просмотр файлов в терминале нагляднее: добавляет цвета и иконки, древовидное представление каталогов, расширенное форматирование и гибкую настройку оформления.

Проект работает в Linux, macOS и Windows, устанавливается через пакетные менеджеры и при желании полностью заменяет обычный ls с помощью alias. Для корректного отображения иконок потребуется Nerd Font.

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

@usr_bin_linux

Можно ли навайбкодить операционную систему как Linux, только быструю?

Я давно подозревал, что фраза «давайте быстро навайбкодим» однажды доберётся от лендингов и SaaS'ов до ядра операционной системы. Дождались.

Автор этой статьи решил проверить, можно ли с помощью Claude Code создать собственную low-latency ОС — как Linux, только быстрее и без лишних микросекунд. Внутри: Rust, C++, планировщик, файловая система, борьба с задержками и тесты PostgreSQL и MariaDB.

Интересно было узнать, где ИИ действительно ускоряет разработку, а где без инженерного опыта он способен уверенно и по-быстрому навайбкодить kernel panic.

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

@usr_bin_linux

Свой игровой сервер на Linux: от systemd до Docker на примере Minecraft и Valheim

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

В статье разбираются два подхода к запуску игровых серверов — классическая установка с systemd и контейнеризация через Docker. В качестве подопытных выступают Minecraft и Valheim: от выбора ресурсов и настройки сети до обновлений, безопасности и стабильной работы.

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

@usr_bin_linux

Лог пустой, а диск заканчивается: что logrotate делает с файлами, которые приложение не закрывает

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

Спойлер: rm не всегда означает, что данные действительно исчезли. Если приложение продолжает держать файловый дескриптор открытым, оно может писать в уже удалённый файл. В каталоге его больше не видно, но место на диске всё ещё занято. Получается своеобразный «лог-призрак»: глазами его не увидеть, зато файловая система прекрасно чувствует его присутствие.

В статье разбирается, как ротация логов связана с inode и открытыми файловыми дескрипторами, чем отличаются стратегии create и copytruncate, зачем отправлять приложению HUP или USR1 и почему неправильно настроенный postrotate способен привести к потере записей.

Дополнительно рассказывают, как искать удалённые, но всё ещё открытые файлы с помощью:

lsof +L1

А также что учитывать при работе с systemd, Docker и приложениями, которые не умеют самостоятельно переоткрывать лог после ротации.

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

@usr_bin_linux

Как ограничения научили нас ставить Kubernetes поверх любой операционной системы

Kubernetes хорошо абстрагирует приложения от инфраструктуры, но у каждого worker-узла всё равно остаётся операционная система. Её необходимо устанавливать, обновлять, защищать, настраивать и каким-то образом поддерживать в одинаковом состоянии на десятках или сотнях серверов.

Долгое время Kubernetes разворачивали поверх обычных серверных дистрибутивов Linux. Подход понятный и гибкий, но постепенно каждый узел обрастает пакетами, конфигурационными файлами, systemd-юнитами и изменениями, о происхождении которых через год уже никто не помнит. Так появились специализированные операционные системы для Kubernetes: CoreOS, Flatcar, Bottlerocket, K3OS и Talos OS.

В статье разбирается, чем такие дистрибутивы отличаются от классического Linux и какие идеи делают их удобными для Kubernetes:

🚀 минимальное количество компонентов

🚀 иммутабельная файловая система

🚀 атомарные обновления

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

🚀 управление через API

🚀 минимизация или полный отказ от SSH-доступа

🚀 декларативная настройка узлов


Отдельная часть посвящена Talos OS — системе, в которой Kubernetes является не дополнительным приложением, а основной причиной существования всей ОС. Никакого привычного SSH, ручного редактирования конфигурации и установки пакетов: управление выполняется через API, а обновление происходит целиком и атомарно.

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

@usr_bin_linux

Linux 7.3 ускоряет файловые операции и меняет правила распределения ресурсов. Что еще?

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

Среди изменений:

🚀 отдельные операции fsync в Btrfs ускорены до пяти раз

🚀 улучшена работа Ext4, FUSE, io_uring и zero-copy

🚀 новый контроллер cgroup dmem помогает управлять видеопамятью и другими ресурсами устройств

🚀 разные группы процессов теперь могут использовать собственные BPF-планировщики

🚀 появились новые механизмы изоляции failfs и fchroot() для построения песочниц

🚀 добавлена начальная поддержка Apple M3 Pro, Max и Ultra, а также новых GPU и периферийных устройств

🚀 в ksmbd появились расширения для Apple Time Machine и дополнительные настройки шифрования SMB

Подробный разбор Linux 7.3 — в статье на Хабре

@usr_bin_linux

Как проверить Linux-сервер на соответствие требованиям безопасности и не утонуть в чек-листах

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

В статье разбираются инструменты, которые помогают автоматизировать проверку Linux на соответствие CIS Benchmarks, ISO 27001, PCI DSS и другим требованиям:

🚀 Lynis — быстрый комплексный аудит системы с понятными рекомендациями

🚀 OpenSCAP — формализованные проверки по SCAP-профилям и подробные HTML-отчёты

🚀 systemd-analyze security — оценка изоляции сервисов и настроек sandboxing в systemd

🚀 DevSec Hardening Framework — готовые роли Ansible, Chef и Puppet для усиления защиты

🚀 Cinc Auditor — подход compliance as code и удалённые проверки серверов по SSH

У инструментов разные задачи, поэтому на практике их разумно комбинировать — например, Lynis для общего аудита, OpenSCAP для проверки по конкретному профилю, а systemd-analyze security для анализа отдельных сервисов.

Отдельно рассматривается применение open source при подготовке к аттестации ФСТЭК. Такие инструменты не заменяют сертифицированные средства защиты, но хорошо подходят для предварительного аудита, постоянного контроля конфигурации и устранения проблем до официальной проверки.

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

@usr_bin_linux

Восстановили взломанный 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