Письмо от хостера про абузу: регламент ответа за 24 часа

MAATRIX

Письмо с темой вроде "Abuse complaint regarding your server" приходит обычно не вовремя — вечером в пятницу или посреди рабочего дня, когда заняты совсем другим. Первый порыв — отложить на потом или отписаться формальной фразой "разберёмся". Оба варианта плохие: хостер не ждёт неделю, у него есть собственный регламент, и молчание с вашей стороны читается как отказ сотрудничать. Дальше — сюрприз в виде заблокированного сервера посреди рабочего дня. Разберём, как реагировать на такое письмо так, чтобы закрыть вопрос за одни сутки и не потерять сервер.

Почему скорость реакции решает, останется ли сервер у вас

Хостинг-провайдер получает abuse-репорт не по своей инициативе — его прислал кто-то извне: получатель спама через свой почтовый сервис, оператор блок-листа (Spamhaus, SORBS, UCEPROTECT), правообладатель через DMCA-агента, автоматическая система жертвы DDoS-атаки. У хостера есть договорные обязательства перед своим апстрим-провайдером и перед регистраторами блок-листов — если он игнорирует репорты, весь его IP-диапазон рискует попасть в чёрные списки, а это бьёт по всем его клиентам сразу, не только по вам. Поэтому у любого адекватного хостинга есть внутренний регламент реакции на abuse, и молчание клиента запускает этот регламент по худшему сценарию для вас.

Типичная эскалация выглядит так: письмо с описанием жалобы и сроком ответа → если ответа нет, повторное письмо с более коротким сроком → блокировка сетевого доступа сервера (иногда только исходящего трафика на 25/2525 порт, иногда полная) → в крайних случаях приостановка аккаунта целиком до выяснения. Конкретные сроки у каждого провайдера свои — где-то это действительно 24 часа, где-то 48-72, но исходить стоит из худшего варианта и не полагаться на то, что "обычно дают неделю". У некоторых провайдеров автоматизированные системы блокируют исходящий SMTP-трафик ещё до того, как человек вообще прочитает вашу жалобу на несправедливость.

Отдельная ловушка — молчание не потому что вы игнорируете, а потому что письмо попало в спам или ушло на неактуальный технический email. Регламент снимает и эту проблему: если реакция на abuse — не личная инициатива дежурного, а прописанный процесс с понятным владельцем, риск потерять письмо падает.

Первые 30 минут: подтвердить получение и не удалять улики

Первое, что нужно сделать — не расследование, а короткий формальный ответ. Он не требует найденной причины, только подтверждает, что письмо получено и работа началась:

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

Подтверждаем получение жалобы. Начали расследование, приступили
к анализу логов и трафика с указанного IP/аккаунта. Ожидаем
предоставить содержательный ответ с деталями и принятыми мерами
в течение 24 часов.

С уважением,
<имя>, <компания>

Это письмо снимает основное давление: у провайдера появляется формальный отчёт "клиент в курсе, работает", и это обычно откладывает автоматическую эскалацию. Отправляйте его с адреса, на который зарегистрирован аккаунт хостинга, или сразу укажите номер договора/ID клиента — иначе ответ потеряется в общей очереди тикетов.

Второе важное действие — до того, как начнёте чистить систему, зафиксировать состояние "на момент инцидента":

# копия очереди почты (если жалоба про спам)
mailq > /root/incident-$(date +%F)/mailq-snapshot.txt
postqueue -p >> /root/incident-$(date +%F)/mailq-snapshot.txt

# снимок активных процессов и соединений
ps auxf > /root/incident-$(date +%F)/ps-snapshot.txt
ss -tulpn > /root/incident-$(date +%F)/ss-snapshot.txt

# копия релевантных логов до ротации
cp /var/log/mail.log /var/log/auth.log /var/log/nginx/access.log \
   /root/incident-$(date +%F)/ 2>/dev/null

Это нужно по двум причинам: содержательный ответ хостеру требует конкретики, а логи ротируются и перезаписываются; а если разбирательство дойдёт до судебного спора (актуально для DMCA-жалоб), сохранённые логи с таймстампами — единственное доказательство ваших действий. Только после снятия снимка переходите к устранению причины — иначе рискуете затереть улику. Похожая логика описана в регламенте первых 15 минут инцидента: сначала зафиксировать масштаб и состояние, потом чинить.

Что реально написано в abuse-репорте — учимся его читать

Большинство репортов приходит в одном из двух форматов: обычным текстом с описанием проблемы или в формате X-ARF (машиночитаемый Abuse Reporting Format, вложением к письму). Независимо от формата, ключевые поля одни и те же — их нужно выцепить из письма до того, как начинать поиск:

Частая ошибка — сверять время из письма с локальным временем сервера напрямую. Если жалоба пришла в UTC, а сервер живёт в московском времени, разница в три часа собьёт весь дальнейший поиск по логам. Первым делом проверьте:

timedatectl
date -u

Если в письме приложен образец спам-письма (.eml), в его заголовках Received: можно найти реальный путь письма — через какой IP и хост оно прошло, что часто указывает точнее, чем общее описание в теле жалобы. Полезно также проверить, не попал ли ваш IP в публичные блок-листы уже сейчас — это подтверждает масштаб и даёт независимую метку времени:

# быстрая проверка по нескольким DNSBL
for bl in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do
  ip=$(echo 203.0.113.45 | awk -F. '{print $4"."$3"."$2"."$1}')
  echo -n "$bl: "; host $ip.$bl 2>&1 | grep -q NXDOMAIN && echo "OK" || echo "LISTED"
done

(вместо 203.0.113.45 подставьте свой реальный IP; результат зависит от конкретной DNSBL и может отличаться, это ориентировочная проверка, а не гарантия точности конкретного списка).

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

Это ключевой развилка регламента, и здесь чаще всего теряют время, начиная сразу "тушить пожар" вместо диагностики. На практике abuse-жалоба почти никогда не означает, что вы или ваш клиент намеренно рассылали спам или атаковали кого-то — гораздо чаще источник один из трёх:

• Скомпрометированный аккаунт или CMS. Утёкшие SSH/FTP-пароли, уязвимый плагин WordPress, взломанная панель управления, украденный API-ключ почтового сервиса. Сервер продолжает работать штатно, но параллельно кто-то использует его ресурсы (почтовую очередь, cron, веб-сокет) для своих целей.
• Неверная конфигурация, открывающая функцию для злоупотребления. Открытый relay в Postfix, форма обратной связи без капчи и rate-limit, через которую рассылают спам, PHP-скрипт с mail() без проверки входных данных.
• Ложное срабатывание. Легитимная email-рассылка (например, транзакционные письма интернет-магазина) попала под фильтр получателя, или сканер уязвимостей ошибочно классифицировал обычный трафик как атаку.

Порядок проверки, от быстрого к медленному:

# 1. Кто и что реально шлёт через почтовую очередь
postqueue -p | tail -n 30
grep 'to=' /var/log/mail.log | tail -n 100

# 2. Необычные процессы и соединения (высокая CPU/сеть без видимой причины)
ps aux --sort=-%cpu | head -n 15
ss -tulpn | grep -E ':25|:587|:465'

# 3. Недавно изменённые файлы в веб-директории — частый след вебшелла
find /var/www -type f -mtime -5 -printf '%T@ %p\n' | sort -n | tail -n 30

# 4. Подозрительные cron-задачи (часто источник постоянной рассылки)
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u $u 2>/dev/null; done

# 5. Явные признаки вебшелла в PHP-коде
grep -rl "eval(base64_decode\|gzinflate(base64_decode\|assert(\$_" /var/www 2>/dev/null

Если очередь почты забита письмами от неизвестного отправителя (from=<random@yourdomain>), а не от вашего почтового сервиса — это почти наверняка компрометация. Если в веб-директории находится файл вроде wp-content/uploads/xyz.php, изменённый вчера ночью, — это вебшелл, а не совпадение. Похожие диагностические признаки разбираются в статье как отличить взлом от кривого обновления — там же список типичных ложных тревог.

Отдельно стоит проверить журнал авторизаций на предмет входов из необычных мест или в необычное время — это подтверждает или опровергает версию с утёкшими учётными данными:

last -a | head -n 20
grep "Accepted" /var/log/auth.log | tail -n 30

Устранить причину: конкретные шаги в зависимости от типа жалобы

Дальнейшие действия зависят от того, что показала диагностика — но общий принцип один: сначала остановить утечку/атаку, потом разбираться в деталях, не наоборот.

Если это спам через скомпрометированный аккаунт или сайт:

# остановить рассылку немедленно, не дожидаясь полной диагностики
systemctl stop postfix   # или exim4, в зависимости от MTA

# после диагностики — очистить очередь от мусорных писем,
# оставив легитимные (если можете их отличить по адресу отправителя)
mailq | grep "spam-source@" | awk '{print $1}' | tr -d '*!' | postsuper -d -

# удалить найденный вебшелл, сохранив копию для анализа
mkdir -p /root/incident-$(date +%F)/evidence
mv /var/www/site/wp-content/uploads/xyz.php /root/incident-$(date +%F)/evidence/

# сменить все пароли и ключи, которые могли утечь
passwd www-data
# для WordPress — сменить соли и пароли БД через wp-cli
wp config shuffle-salts --allow-root

Если причина в открытом relay или дырявой форме на сайте:

Проверьте smtpd_relay_restrictions в Postfix — если там разрешён relay без аутентификации для внешних сетей, это открытая дверь:

postconf smtpd_relay_restrictions
# правильное значение обычно:
# permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Если проблема в PHP-скрипте формы обратной связи — добавьте капчу, rate-limit по IP и проверку заголовков письма на инъекции (\r\n в полях формы — классический вектор для email injection).

Если это исходящий DDoS-трафик (сервер используется как часть ботнета):

# найти процесс, генерирующий аномальный исходящий трафик
iftop -P
nethogs

# временно ограничить исходящий трафик, пока идёт расследование
iptables -A OUTPUT -p tcp --dport 80 -m limit --limit 100/sec -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j DROP

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

Написать хостеру ответ, который закроет тикет, а не откроет новый виток

Содержательный ответ — тот, который отвечает на три вопроса: что произошло, что вы сделали, что сделано, чтобы это не повторилось. Абстрактные фразы вроде "мы всё проверили, проблема решена" саппорт хостинга видит десятками в день и обычно не принимает как основание закрыть тикет — это выглядит как отписка, а не как расследование.

Рабочий шаблон ответа:

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

Расследование по жалобе завершено. Ниже — итог.

Причина: скомпрометирован плагин Contact Form 7 (устаревшая версия
5.4.2) на сайте example.com, размещённом на сервере. Через
уязвимость был загружен вебшелл (wp-content/uploads/2026/08/xyz.php),
через который с 26.08 по 27.08 рассылались спам-письма от имени
случайных адресов на домене example.com.

Принятые меры:
1. Почтовая служба остановлена в 14:20 (UTC+3), очередь очищена
   от вредоносных писем.
2. Вебшелл обнаружен и удалён в 14:45, сохранена копия для анализа.
3. Плагин обновлён до версии 5.9.1 (устраняет использованную CVE).
4. Пароли admin-панели WordPress и учётной записи БД сброшены.
5. Добавлено ограничение частоты исходящей почты на уровне Postfix
   (smtpd_client_message_rate_limit = 30/час) как дополнительная
   защита от повторной рассылки в случае нового инцидента.

Готовы предоставить логи или дополнительную информацию по запросу.

С уважением,
<имя>

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

Если жалоба оказалась ложной (например, антиспам-система получателя ошибочно пометила легитимную транзакционную рассылку), в ответе стоит показать доказательства легитимности: DKIM/SPF-записи домена, скриншот из панели рассылки с согласием получателя на подписку, объяснение, почему объём писем вырос именно в этот период. Спор с хостером "вы неправы" без доказательств редко работает — а с конкретикой обычно снимается быстро.

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