Python CLI/TUI для форензической триажной проверки систем Ubuntu — обнаруживает и устраняет механизмы персистентности с помощью сбора артефактов, корреляции временной шкалы и интеграции с Wazuh.
Форензическая триажная проверка живых систем Ubuntu — автоматизированный сбор артефактов, обнаружение механизмов закрепления и управляемое устранение примерно за минуту.
Когда вы подозреваете, что система Linux скомпрометирована, первые 30–40 минут обычно уходят на последовательный запуск одних и тех же десяти команд: проверка запущенных процессов, поиск странных заданий cron, grep по LD_PRELOAD, сканирование authorized_keys на новые записи, аудит sudoers. Каждый шаг выполняется вручную, с переключением контекста и легко приводит к ошибкам под давлением. Пропустите один источник — скажем, /etc/sudoers.d/ вместо только /etc/sudoers, или пользовательские crontab в дополнение к /etc/cron.d/ — и у вас неполная картина.
Существующие решения не решают эту задачу чисто. lynis — это аудитор настроек безопасности, а не инструмент триажа: он сообщает о слабых местах конфигурации на чистой системе и создаёт шум на заражённой. chkrootkit и rkhunter проверяют известные сигнатуры руткитов, но слепы к новым техникам закрепления, таким как злоупотребление таймерами systemd или правдоподобно выглядящие записи cron. Обобщённые запросы к SIEM требуют лог-инфраструктуры, которой может не быть на исследуемой системе. А форензические комплексы вроде Volatility нацелены на образы памяти, а не на живую оболочку на работающем хосте.
Пробел — это инструмент, который запускается на живой системе прямо сейчас, охватывает наиболее распространённые векторы закрепления, коррелирует активность из разных источников логов в единую временную шкалу и точно указывает, на что смотреть — без необходимости во внешнем агенте, базе данных или интернет-соединении.
ubuntils работает в четыре последовательных этапа:
/proc, таблиц cron, юнитов systemd, SSH-ключей, файлов sudoers, определений окружения, целостности пакетов (dpkg --verify), конфигурации PAM/NSS и загруженных модулей ядра. Большинство сборщиков завершаются за секунду-две; dpkg --verify, который перепроверяет каждый файл установленного пакета, доминирует — полное сканирование заняло 29–68 секунд на виртуальной машине с рабочим столом Ubuntu 26.04 arm64.--rules — по собранным артефактам, формируя ранжированный список находок с оценкой достоверности примерно за одну секунду.--json).Сам ubuntils не делает сетевых вызовов, и каждая функция — включая пользовательские правила и корреляцию — работает с локально собранными артефактами. Единственный способ, которым находки могут покинуть хост, — это интеграция с Wazuh: если установлен агент Wazuh, живой scan записывает свои находки в локальный файл, который агент затем отправляет своему менеджеру. Передайте --no-wazuh, чтобы отключить это для запуска.
ubuntils scan не изменяется всем нижеописанным — он по-прежнему на 100% рабочий, ориентирован на один хост, и все существующие флаги работают идентично. Две дополнительные команды, collect и analyze, разделяют тот же конвейер обнаружения/построения временной шкалы на офлайн-ориентированный рабочий процесс «сначала сбор, затем анализ» для случаев, когда вы не можете (или не хотите) запускать обнаружение непосредственно на исследуемом хосте — см. Офлайн-анализ: collect и analyze ниже, включая оговорки о покрытии обнаружения.
Ubuntu 22.04+ и любая система с PEP 668 (рекомендуется):
Ubuntu 22.04+ блокирует общесистемную установку через pip install. Используйте pipx — он прозрачно управляет окружением, так что вам никогда не придётся об этом думать:
sudo apt install pipx -y
pipx ensurepath # then open a new shell
git clone https://github.com/asmitdesai/ubuntils.git
cd ubuntils
pipx install -e .
ubuntils scan # not `ubuntils scan` — see below
Запускайте его от имени обычного пользователя: scan и collect повторно вызывают себя через sudo. Если ввести ubuntils … самостоятельно, это завершится ошибкой command not found, потому что secure_path в sudo не включает ~/.local/bin, куда pipx помещает команду. Если нужно запустить его из root-оболочки, вызывайте установленный бинарный файл по пути (~youruser/.local/bin/ubuntils scan) или вместо этого установите в виртуальное окружение:
python3 -m venv .venv
.venv/bin/pip install -e .
.venv/bin/ubuntils scan
Старые системы / ручная установка:
git clone https://github.com/asmitdesai/ubuntils.git
cd ubuntils
pip install -r requirements.txt -e .
ubuntils scan
ubuntils требует root для полного доступа к артефактам. Если вы запускаете ubuntils scan от имени непривилегированного пользователя, он автоматически перезапустит себя с sudo, используя тот же интерпретатор Python (по абсолютному пути), так что будет использовано правильное окружение без передачи вашего PATH в root-процесс. Каждая внешняя команда (ss, dpkg, systemctl, …) разрешается по фиксированному пути поиска, принадлежащему root, а не по вашему PATH. Запуск без root пропустит /etc/shadow, некоторые записи /proc и защищённые файлы cron, и для каждого будет записано предупреждение.
Только обнаружение — интерактивный TUI:
ubuntils scan
Обнаружение с сохранением вывода JSON в файл:
ubuntils scan --json > /tmp/triage-$(hostname)-$(date +%Y%m%d).json
Обнаружение с предварительным просмотром исправлений через CLI (пробный запуск — изменения не применяются):
ubuntils scan --remediate
Обнаружение с применением исправления через CLI:
ubuntils scan --remediate --confirm
Версия для печати:
ubuntils version
Соберите защищённый от подмены пакет для последующего или офлайн-анализа:
ubuntils collect --output /path/to/bundle.tar.gz
Анализ ранее собранного пакета (без прав root):
ubuntils analyze /path/to/bundle.tar.gz --json
Анализ смонтированного криминалистического образа или извлечённого дерева файловой системы вместо пакета:
ubuntils analyze --root /mnt/forensic-image --json
См. Офлайн-анализ: сбор и анализ для формата пакета и — что важно — того, что офлайн-анализ не может обнаружить по сравнению с живым scan.