Хостер прислал abuse-жалобу: как отвечать и что показывать

MAATRIX

Письмо с темой «Abuse Complaint» или «Suspicious Activity Notice» выбивает из колеи: непонятно, что натворил сервер, а хостер уже намекает на сроки. Если промолчать или отписаться шаблонной фразой «у нас всё чисто», аккаунт может уйти в саспенд — иногда за сутки, иногда за пару часов, в зависимости от тяжести жалобы. Разберём, что делать по шагам: как ответить быстро и по существу, как за 30-60 минут собрать факты по своим логам, и как написать ответ, после которого хостер снимает вопрос, а не эскалирует его.

Почему на abuse-жалобу нельзя не реагировать

Abuse-отдел хостинга работает не по своей инициативе — жалоба почти всегда приходит от третьей стороны: другого провайдера, чей IP вы просканировали, оператора спам-ловушки (spamtrap), сервиса вроде AbuseIPDB или Spamhaus, либо от жертвы DDoS-трафика, которая пожаловалась вашему upstream-провайдеру. Хостер обязан на неё отреагировать перед своим апстримом, поэтому передаёт проблему вам с дедлайном.

Дедлайны у разных хостеров разные, но логика одна:

• Нет ответа в течение 24-72 часов — включается автоматическая эскалация: port 25/80/443 блокируется на файрволе апстрима, либо сервер полностью изолируют от сети (null-route) до выяснения.
• Повторная жалоба того же типа — саспенд может произойти без дополнительного предупреждения, потому что вы уже «предупреждены».
• Жалоба от Spamhaus/SORBS с IP в чёрном списке — здесь на кону не только ваш сервер, а вся подсеть хостера, поэтому реакция обычно жёстче и быстрее.

Игнорирование — худшая стратегия: молчание хостер трактует как подтверждение, что проблема реальна и вы её не контролируете. Вторая по вредности стратегия — отрицание без проверки: «у нас антивирус, такого не может быть» звучит убедительно только для вас, а не для abuse-отдела, который держит перед собой конкретные логи с вашего IP. Правильная последовательность — подтвердить получение, расследовать, ответить фактами.

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

Пока вы разбираетесь в логах, хостер должен видеть, что вопрос не повис. Разошлите короткое подтверждающее письмо в течение 30-60 минут после получения жалобы — это резко снижает шанс автоматической эскалации, потому что большинство систем тикетинга фиксируют именно факт первого ответа, а не его глубину.

Структура подтверждения — три предложения:

Subject: Re: [Ticket #123456] Abuse Complaint - Port Scanning from 203.0.113.45

Здравствуйте,

Подтверждаю получение жалобы по IP 203.0.113.45. Начинаю расследование
логов сервера, ожидаемый срок предоставления результатов — до 4 часов
(до 18:00 UTC). Если потребуется временно ограничить исходящий трафик
для остановки активности, сделаю это немедленно.

С уважением, [имя]

Важные детали этого письма:

• Указан конкретный срок, а не «скоро» — abuse-отделу нужно на что-то ориентироваться, чтобы не запускать эскалацию раньше.
• Не отрицается и не подтверждается факт жалобы — вы ещё не проверили, поэтому не берёте на себя обязательств, которые придётся отзывать.
• Обозначена готовность действовать — если это реально ваш процесс шлёт спам или сканирует порты, вы сигнализируете, что готовы его остановить, не дожидаясь результатов расследования.

Если жалоба пришла в выходной или ночью, а расследование займёт больше пары часов — всё равно отправьте подтверждение сразу, а срок расследования укажите реалистичный (например, «до конца рабочего дня»). Точный срок, который вы держите, работает лучше расплывчатого «в ближайшее время», который вы, скорее всего, не удержите.

Как провести быстрое расследование инцидента

В жалобе почти всегда есть зацепка: IP, порт назначения, временная метка (обычно в UTC), иногда фрагмент лога атакованной стороны. С этого и начинайте — не с общего «просканировать всё антивирусом».

Шаг 1. Сверьте время. Переведите время из жалобы в часовой пояс сервера:

timedatectl
date -u

Если сервер живёт не в UTC, ошибка на этом шаге даст вам совершенно не тот час в логах — самая частая причина «в логах ничего нет», хотя проблема там есть.

Шаг 2. Проверьте исходящие соединения на момент инцидента. Если сервер ещё атакует прямо сейчас, это видно сразу:

ss -tulnp | grep ESTAB
ss -s
netstat -tanp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Резкий всплеск соединений к одному чужому IP или веером к сотням разных IP на 22/23/3389 порт — типичная картина сканирования или брутфорса, запущенного с вашего сервера (а не на него).

Шаг 3. Посмотрите почтовые очереди, если жалоба про спам:

mailq | tail -30
postqueue -p | grep -c '^[A-F0-9]'
grep "$(date -u '+%b %e')" /var/log/mail.log | grep -c 'status=sent'

Аномально большая очередь или тысячи status=sent за час — почти наверняка скомпрометированный веб-скрипт или подобранный SMTP-пароль слал спам через ваш сервер. Отдельная статья про то, как понять, что сервер разослал спам ночью, даёт более подробный разбор именно этого сценария.

Шаг 4. Проверьте процессы и cron, которые могли запустить сканер или флудер:

ps aux --sort=-%cpu | head -20
crontab -l -u www-data
find / -newer /var/log/auth.log -type f -mmin -180 2>/dev/null | grep -v '^/proc'

Последняя команда ищет файлы, изменённые позже последней записи в auth.log — быстрый способ найти свежезалитый веб-шелл или подмененный бинарник.

Шаг 5. Если это про DDoS-трафик исходящий с вашего IP (а не входящий на вас), проверьте, не работает ли сервер как часть ботнета или как открытый reflector:

tcpdump -i eth0 -n -c 200 'udp and (port 53 or port 123 or port 1900)'
iptables -L -v -n | head -30

Открытый DNS-резолвер, NTP-сервер без ограничений или незащищённый memcached — классические источники amplification-атак, которые запускают со стороннего управляющего сервера, а ваш просто отражает трафик. Если разбираетесь с входящей атакой прямо сейчас, а не с исходящим трафиком, пригодится чек-лист первых действий при DDoS-атаке.

Держите в голове бюджет времени: 30-60 минут на первичный сбор фактов достаточно почти всегда. Если через час картина не складывается, а трафик продолжается — временно заблокируйте подозрительный исходящий трафик на файрволе (детали ниже), это остановит жалобу, даже если причина ещё не найдена до конца.

Структура ответа, который устраивает хостера

Итоговый ответ хостеру строится из трёх обязательных частей — именно в таком порядке, потому что abuse-отдел читает по диагонали и должен сразу увидеть, что вы не игнорируете и не отрицаете, а разобрались.

Часть 1 — что вы нашли. Конкретный факт, а не оправдание:

Расследование подтвердило источник: скрипт wp-content/uploads/tmp/cron.php,
загруженный через уязвимость в устаревшем плагине WordPress (обновлён
последний раз в 2021 году), с 02:14 до 03:40 UTC отправлял письма через
локальный Postfix со скоростью около 40 писем в минуту.

Часть 2 — что вы уже сделали. Конкретные действия с таймстампами:

Действия, выполненные к моменту ответа:
- 09:12 UTC — вредоносный файл удалён, директория uploads/tmp закрыта
  от исполнения PHP (deny в конфиге веб-сервера)
- 09:20 UTC — плагин обновлён до актуальной версии, пароли админки
  и БД сброшены
- 09:35 UTC — исходящий SMTP-трафик с сервера временно ограничен
  до 20 писем в час на время проверки остальных сайтов на сервере

Часть 3 — что вы делаете, чтобы это не повторилось. Здесь хостер видит, что вы не просто потушили конкретный костёр:

Дополнительно:
- fail2ban настроен на мониторинг попыток загрузки файлов через
  уязвимые эндпоинты
- запущена проверка остальных сайтов на сервере на предмет похожих
  устаревших плагинов
- настроено уведомление при превышении почтовой очереди 100 писем

Если жалоба касается сканирования портов или DDoS-трафика, а не спама, структура та же, меняется только содержание фактов: какой процесс или IP был источником, когда он остановлен, какое правило файрвола или rate-limit добавлено.

Что важно НЕ включать в ответ:

• Оправдания в духе «сервер арендован клиентом, мы не при чём» — если это ваш VPS/выделенный сервер, ответственность за содержимое лежит на вас, даже если реальный виновник — забытая уязвимость или клиент вашего клиента.
• Общие обещания без цифр («мы усилили безопасность») — abuse-отдел видит десятки таких писем в день и не засчитывает их как закрытие тикета.
• Просьбу прислать больше логов, если вы ещё не попытались найти проблему сами — это тратит ваш же дедлайн.

Разбор частых типов жалоб: спам, сканирование портов, DDoS-трафик

Для спама отдельно стоит проверить, не открыт ли SMTP-релей наружу без авторизации:

grep -i "mynetworks\|smtpd_relay_restrictions" /etc/postfix/main.cf

Если mynetworks включает 0.0.0.0/0 или широкую подсеть — это открытый релей, и жалоба на спам почти гарантирована рано или поздно, даже без взлома конкретного сайта.

Для сканирования портов полезно отличать реальную атаку с сервера от ложного срабатывания: некоторые мониторинговые системы (Zabbix, Nagios с внешними проверками) генерируют трафик, похожий на сканирование, если неправильно настроены интервалы проверки на множество портов подряд.

Если жалоба ошибочна или сервер скомпрометирован

Не всякая жалоба означает взлом. Иногда источник — легитимный, но агрессивно настроенный инструмент на вашей стороне:

• скрипт мониторинга, проверяющий доступность десятков портов на внешних хостах;
• бэкап-система, которая ошибочно резолвит адрес и стучится не туда;
• shared-хостинг, где скомпрометирован не ваш аккаунт, а соседний сайт на том же IP (актуально для виртуального хостинга, не для отдельного VPS).

В этом случае в ответе прямо укажите: «Проверка показала, что источник трафика — легитимный сервис X, конфигурация которого будет скорректирована к [время], чтобы исключить ложные срабатывания на стороне получателя». Это не отрицание жалобы, а объяснение с конкретным действием — abuse-отдел принимает такие ответы, потому что видит, что вы разобрались, а не отмахнулись.

Если расследование подтвердило компрометацию — не пытайтесь просто удалить найденный файл и закрыть тикет. Один найденный веб-шелл почти всегда означает, что атакующий мог оставить запасные точки входа: ещё один шелл в другой директории, изменённый cron, добавленный SSH-ключ в ~/.ssh/authorized_keys, новую учётную запись пользователя. Минимальный чек-лист после находки:

find / -name "authorized_keys" -newer /var/log/auth.log 2>/dev/null
awk -F: '$3 >= 1000 {print $1, $3}' /etc/passwd
crontab -l -u root; for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done

При серьёзном компромиссе (root-доступ, руткит, неясная глубина проникновения) честнее заранее заложить в план переустановку сервера с чистого образа и восстановление из бэкапа, сделанного до инцидента, а не бесконечную чистку системы, в целостности которой вы уже не уверены. Порядок действий при таком сценарии подробно расписан в статье про план реагирования на взлом, а оформить находки для внутреннего разбора и хостера помогает подход из статьи как писать разбор инцидента — тот же формат «что нашли — что сделали — что изменили» подходит и для письма в abuse-отдел, и для внутреннего post-mortem.

Частые вопросы