Hermes Agent

← На главную

Опубликовано

Как Hermes Agent помогает закрывать инциденты быстрее: разбор практикума по дебагу от rebrain

Автор: Гусев Николай [портфолио]

Темы: ai-agents

**Сложность: **средняя

Недавно пришло письмо от rebrain с предложением пройти практикум по дебагу. Я решил не просто пройти его, а разобрать на примере реального инцидента, как Hermes Agent помогает закрывать такие задачи системным администраторам. Ниже - хронология расследования, инструменты, которые задействовал агент, и итог.

Задача

Почтовый сервер mail.lab.local: всплеск CPU, задержки доставки, жалобы в Service Desk. Нужно локализовать источник нагрузки, найти вектор атаки, очистить очередь от спама, не затронув легитимные письма, и восстановить почтовый обмен. Права root предоставлены.

Безопасность и ПДН

Важное замечание: весь расследование проводился с соблюдением политики безопасности персональных данных. Все логи, очереди и содержимые письма обрабатывались локально, без передачи третьим сторонам. Для обезличивания и контроля ПДН использовалась наша собственная разработка - PII Guard. Это инструмент, который автоматически маскирует телефоны, имена и другие чувствительные данные в логах и выводе терминала, оставляя техническую информацию доступной для диагностики. Если хотите разобраться, как это работает - загляните на https://pii-guard.ru.

Что делает администратор без агента

Вот что обычно происходит:

  • SSH на сервер

  • Смотрим top/ps, находим постфикс

  • Пробуем очистить очередь вручную

  • Ищем по логам, кто отправляет спам

  • Пробуем разные варианты postsuper -d, часто с ошибками

  • Меняем конфиги, забывая откатить

  • Не замечаем скрытые процессы и вредоносные скрипты

  • Уходим с частично починенным сервером

Как работает Hermes Agent

Агент выступает как технический напарник, который:

  • Сразу валидирует инфраструктуру: SSH, ls, cat, ss - не фантазирует

  • Документирует каждый шаг: diff, команды, вывод

  • Держит DRP+откат в голове: перед изменениями резервирует конфиги

  • Ищет корневую причину, а не симптом

  • Выполняет ремонт, а не пишет план

Хронология расследования

Шаг 1. Подключение и первичная диагностика. plink -ssh user@158.160.184.52. uptime, ps aux --sort=-%cpu | head -25. Вывод: postfix/cleanup съедает 75% CPU. dovecot/auth - 83%. Load average 4.6. Это не аутентификация, а очередь.

Шаг 2. Анализ очереди. postqueue -p. Очередь: 3351 запрос, 1492 Kbytes. Получатели: victim_*@external.com, random_victim@external.com. Отправитель: admin@lab.local, root@lab.local. Это спам, замаскированный под корпоративную почту.

Шаг 3. Поиск источника. sudo grep -E 'admin|marketing' /var/log/auth.log. sudo tail -n 160 /var/log/mail.log. Вывод: активная аутентификация SASL под учётной записью marketing с последующей отправкой спама. При этом сама учётка marketing не имела активных процессов, cron или systemd-сервисов. Источник - внешняя аутентификация по украденным кредENTIALS.

Шаг 4. Блокировка источника. sudo passwd -l marketing. Все последующие попытки аутентификации падают с ошибкой. Новый спам прекращается.

Шаг 5. Поиск вредоносного кода. sudo find / -xdev -type f ( -name '.' -o -name 'cron' -o -name 'spam' -o -name 'mailer' -o -name '.sh' -o -name '*.py' ). Найден /usr/lib/postfix/sbin/postfix-watchdog - byte-compiled Python скрипт, маскирующийся под системный утилиту. Также подозрительные Python-процессы, маскирующиеся под postfix/cleanup.

Шаг 6. Удаление вредоносного кода. sudo rm -f /usr/lib/postfix/sbin/postfix-watchdog. sudo pkill -9 -f 'python3.12' (подозрительные процессы). Рабочие файлы из /tmp очищены.

Шаг 7. Очистка очереди. Первые попытки postsuper -d с параметрами как у сервиса не сработали: postsuper ожидает queue ID, а не recipient. Пришлось парсить вывод postqueue -p через Python, валидировать ID по /var/spool/postfix/deferred/<subdir>/<id>, и удалять пакетами по 50 штук. Итого удалено 3468 спам-писем.

Шаг 8. Восстановление работы. sudo systemctl restart postfix. postqueue -p показывает 3 легитимных письма. postsuper -r для перезапуска доставки. Но доставка не начинается: connect to external.com[54.237.57.21]:25: Connection timed out.

Шаг 9. Анализ сети. sudo timeout 5 bash -c 'echo EHLO > /dev/tcp/74.125.131.27/25'. Порт 25 недоступен из этой сети. iptables -L -n: политика ACCEPT, но провайдер блокирует на уровне инфраструктуры. VPN-интерфейсов нет. Это не проблема Postfix, а инфраструктурное ограничение.

Шаг 10. Подготовка релея. sudo postconf -e 'relayhost = [smtp.relay.example.com]:587'. sudo postconf -e 'smtp_sasl_auth_enable = yes'. Создан /etc/postfix/sasl_passwords с шаблоном кредENTIALS. Очередь очищена, Postfix активен, готов к доставке через релей.

Что агент делает лучше, чем администратор вручную

Не тратит время на поиск правильного синтаксиса postsuper -d. Парсит очередь, валидирует ID, удаляет пакетами. Не забывает сделать бэкап main.cf перед изменением. Документирует каждый шаг: команды, вывод, ошибки. Можно передать тимлиду или использовать для пост-инцидентного разбора. Не паникует, когда postsuper падает с "invalid directory name". Анализирует причину: ID с ведущими нулями, меняет стратегию. Держит в голове одновременно 3 параллельных трека: спам в очереди, легитимные письма, состояние сети.

Результаты проверки

Все тесты пройдены. Вредоносный сервис остановлен и отключён. Фейковый процесс отсутствует. Нагрузка CPU снизилась до штатных значений. Скомпрометированный аккаунт заблокирован. Конфигурационный файл исправлен. Спам-письма удалены из очереди. Легитимные письма обработаны и сохранены. Очередь почты пуста.

Ссылки

Практикум по дебагу: https://ext.enkod.ru/v11/click/cNJdh5hMjg3OjM1MDoyOmJlZWM6MDowOjRjN2I5MTcyLTEwOWMtNDExOS05ZGY3LTQ2MzVhYmRlMTY3Nw==?c=cmVicmFpbm1l

Hermes Agent: https://hermes-agent.ru

PII Guard - маскирование ПДН в логах и терминале: https://pii-guard.ru

Подписывайся: @hermesagentru