IP попал в чёрные списки: восстановление репутации по шагам

MAATRIX

Однажды утром письма с вашего сервера перестают доходить, а в логах Postfix вместо привычного 250 OK появляется 550 5.7.1 Service unavailable, blocked с упоминанием Spamhaus или SORBS. Или того хуже — часть посетителей жалуется, что сайт у них не открывается, хотя у вас всё работает. Это почти всегда значит одно: IP-адрес сервера попал в один или несколько чёрных списков (DNSBL). Ниже — рабочий план, как это исправить: сначала устранить причину, потом снять сам блок, и на будущее не допустить повтора.

Как понять, что дело именно в чёрном списке

Симптомы делятся на два типа — почтовые и веб-фильтрационные, и они требуют разной диагностики.

Почта. Отправленное письмо возвращается bounce-сообщением, в котором принимающий сервер прямо называет причину. Типичные строки в логе:

550 5.7.1 Service unavailable; Client host [203.0.113.45] blocked using Spamhaus SBL
554 5.7.1 <адрес>: Recipient address rejected: Access denied, listed in zen.spamhaus.org
450 4.7.1 Client host blocked using Barracuda Reputation, reason: SORBS.net

Смотрите mail.log или maillog на сервере (grep 'blocked\|rejected\|refused' /var/log/mail.log) — почтовые сервисы почти всегда пишут название списка прямо в ответе, это не нужно угадывать.

Веб. Часть корпоративных прокси и антивирусов (Cisco Talos, Fortinet, Symantec, McAfee SiteAdvisor) фильтрует не только почту, но и обычный HTTP(S)-трафик по репутации IP. Тогда пользователи с определённых провайдеров или в офисах с корпоративным фильтром получают заглушку "This site has been blocked" — при этом с домашнего интернета сайт открывается нормально. Если жалобы приходят выборочно и без видимой связи с географией, стоит проверить IP по репутационным базам — вероятно, туда же, откуда приходят проблемы с почтой.

Важно не путать: если сайт не открывается вообще ни у кого, дело почти наверняка не в чёрных списках, а в firewall, DNS или самом сервере — тут смотрите в сторону чеклиста безопасности нового сервера и базовой диагностики, а не делистинга.

Шаг 1. Найдите и устраните причину — иначе делистинг бессмысленен

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

Типичные причины попадания в блок-листы:

• Скомпрометированный сайт или CMS. Взломанный WordPress/Joomla с бэкдором рассылает спам через mail() или встроенный SMTP-клиент. Проверьте wp-content/uploads и временные директории на подозрительные .php-файлы, обновите CMS и все плагины, смените пароли админки и БД.
• Открытый relay или неправильно настроенный Postfix/Exim. Проверьте, что smtpd_relay_restrictions не пропускает анонимную отправку наружу:

  postconf smtpd_relay_restrictions
  # должно быть permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Если там пусто или стоит permit без ограничений — это open relay, и его найдут спамеры за считаные часы после старта сервера.

• Скомпрометированный аккаунт почты. Утёкший пароль от одного ящика на сервере — рассылка идёт через легитимную аутентификацию, антиспам её не блокирует до момента массовой жалобы. Смотрите логи авторизации (grep sasl_authentication_failure и наоборот — успешные логины из необычных стран/IP через journalctl -u postfix или dovecot-логи).
• Уязвимый скрипт на сайте (form-to-mail без капчи, старый PHPMailer, дырявый контакт-форм плагин) — злоумышленники слали спам через ваш sendmail, даже не имея доступа к серверу напрямую.
• Заражённый сервер / вредоносный процесс. Проверьте исходящий трафик на порт 25 и 587 от процессов, которые не должны его использовать: ss -tnp | grep :25 и ss -tnp | grep :587. Неожиданный процесс, слющий десятки соединений — сигнал компрометации.

Только после того как источник найден и закрыт (обновлены CMS, сменены пароли, закрыт relay, убит вредоносный процесс), переходите к самому делистингу — иначе результат будет временным.

Шаг 2. Проверьте, в каких именно списках вы числитесь

DNSBL-списков десятки, и попадание в один не означает попадание во все. Универсальный способ проверки — DNS-запрос к зоне списка с реверсированным IP. Для IP 203.0.113.45 и списка Spamhaus ZEN:

dig +short 45.113.0.203.zen.spamhaus.org

Если возвращается NXDOMAIN (пусто) — IP чист для этого списка. Если возвращается адрес вида 127.0.0.x — IP числится, а последний октет обычно кодирует причину (например, у Spamhaus 127.0.0.2 — SBL за спам/фишинг, 127.0.0.4 — CBL за компрометацию/ботнет, 127.0.0.3 — XBL). Тот же принцип работает для любой другой зоны, только меняется суффикс:

dig +short 45.113.0.203.bl.spamcop.net
dig +short 45.113.0.203.dnsbl.sorbs.net
dig +short 45.113.0.203.b.barracudacentral.org

Проверять вручную по десяткам зон долго, поэтому удобнее агрегаторы, которые бьют сразу по 100+ спискам и показывают результат в одном отчёте:

• MXToolbox (mxtoolbox.com/blacklists.aspx) — самый популярный, показывает статус по основным DNSBL и ссылки на форму делистинга каждого списка.
• multirbl.valli.org — больше списков в выдаче, полезен, если MXToolbox показал "чисто", а проблема осталась.
• whatismyipaddress.com/blacklist-check — альтернативный агрегатор с похожим покрытием.
• Google Postmaster Tools (postmaster.google.com) — не DNSBL, но показывает репутацию домена/IP именно у Gmail, что часто важнее любого публичного списка, если основная переписка идёт с Gmail-адресами.
• Microsoft SNDS (Smart Network Data Services, sendersupport.olc.protection.outlook.com/snds) — аналог для Outlook/Hotmail, требует регистрации IP-диапазона, но даёт данные напрямую от Microsoft.

Запишите себе список конкретных зон, где вы засветились — дальше делистинг вы будете подавать отдельно в каждую, и в некоторых потребуется точно указать имя зоны.

Шаг 3. Подайте заявку на делистинг в каждый конкретный список

У каждого DNSBL — своя процедура, свои требования к описанию проблемы и свои сроки рассмотрения; универсального рецепта "снимут через N часов" не существует, потому что правила и нагрузка на модерацию у всех разные. Что можно сказать предметно:

• Spamhaus. Форма делистинга на spamhaus.org/lookup/ — вводите IP, система показывает, в каком именно из под-списков (SBL, XBL, CSS, PBL) вы числитесь, и даёт релевантную форму или инструкцию. SBL обычно требует ручного review с описанием, что именно исправлено; XBL/CBL во многих случаях снимается автоматически после того, как источник заражения устранён и повторные пробы от IP прекращаются — но сроки снятия зависят от их внутренней логики повторных проверок, а не от фиксированного таймера.
• Spamcop (bl.spamcop.net). Список построен на пользовательских жалобах и "стареет" сам по себе — если жалобы прекращаются, запись протухает без ручного запроса. Ручного делистинга как такового у него, по сути, нет: важно перестать давать поводы для новых репортов.
• SORBS. У SORBS есть отдельная форма делистинга по каждому под-списку (спам, open relay, dynamic IP и т.д.), и там прямо просят описать, что было исправлено технически, а не просто "please remove".
• Barracuda Reputation (b.barracudacentral.org). Форма на barracudacentral.org/rbl/removal-request, обычно просит указать домен/организацию и подтвердить исправление.
• UCEPROTECT. Известен тем, что блокирует не только конкретный IP, но иногда весь подсеть провайдера (Level 2/3) — если ваш собственный IP чист, но виноват сосед по подсети того же хостера, обращаться нужно и провайдеру тоже, ускорить это со своей стороны часто нельзя.

Практический совет: заявку подавайте только после реального устранения причины и с конкретным описанием — что именно было не так (например: "скомпрометированный WordPress-плагин рассылал спам, плагин удалён, пароли сброшены, установлен fail2ban") — расплывчатые запросы вида "please unblock" разбирают дольше или отклоняют.

Таблица для ориентира, куда смотреть по каждому списку:

Шаг 4. Пока ждёте — временные меры, чтобы почта продолжала ходить

Делистинг может занять от часов до нескольких дней в зависимости от списка, а бизнес не может ждать, пока письма не доходят до клиентов. Рабочий вариант — временно (или постоянно) отправлять почту не напрямую с IP сервера, а через сторонний SMTP-релей с уже наработанной репутацией:

# пример relayhost в main.cf Postfix
relayhost = [smtp.релей-провайдера.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

В качестве релея подойдут транзакционные почтовые сервисы (Amazon SES, SendGrid, Mailgun, Postmark, SMTP2GO и аналогичные) — они держат отдельные пулы IP именно под транзакционную почту и активно мониторят репутацию сами, поэтому доставляемость с их стороны обычно выше, чем у свежего IP собственного VPS. Это не бесплатно и не безлимитно, но как временная (а для многих проектов и постоянная) мера снимает проблему уже сегодня, пока с чёрными списками разбирается параллельно другой процесс.

Если проблема касается не почты, а веба (сайт режут корпоративные фильтры), временного обхода почти нет — единственный практичный путь тот же: устранить причину и ждать переоценки репутации, либо, если критично, переехать на новый IP у хостера уже после того, как причина устранена (иначе история повторится и на новом адресе).

Шаг 5. Как не попасть в списки повторно

Восстановленный IP так же уязвим к повторному занесению, если не закрыть системные причины:

• Rate limiting на исходящую почту. Ограничьте, сколько писем один аккаунт/скрипт может отправить в час — это первое, что останавливает скомпрометированный скрипт от масштабной рассылки до того, как его заметят вручную.
• Антиспам-фильтр на входе, а не только на выходе. Rspamd с DKIM/SPF/DMARC снижает риск, что через контакт-форму или взломанный аккаунт пройдёт массовая рассылка незамеченной.
• fail2ban на SMTP-аутентификацию — банит IP после нескольких неудачных попыток логина в почтовый ящик, закрывая брутфорс паролей от учёток.
• Регулярные обновления CMS и плагинов — большинство компрометаций идёт через устаревший WordPress/Joomla, а не через сам сервер.
• Мониторинг репутации на будущее. Настройте регулярную (например, раз в сутки через cron) проверку своего IP по ключевым зонам:

  #!/bin/bash
  IP="203.0.113.45"
  REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
  for zone in zen.spamhaus.org bl.spamcop.net dnsbl.sorbs.net b.barracudacentral.org; do
    result=$(dig +short $REV.$zone)
    [ -n "$result" ] && echo "ВНИМАНИЕ: $IP найден в $zone ($result)"
  done

Скрипт можно повесить в cron и слать вывод на почту или в Telegram — так вы узнаете о попадании в список раньше, чем об этом сообщат клиенты через тикет "не доходят письма". Подобным же образом стоит переиспользовать подход, описанный в статье про мониторинг доступности сайта — только вместо HTTP-пинга здесь DNS-запрос к зонам.

• Google Postmaster Tools и Microsoft SNDS держите зарегистрированными постоянно, а не только когда уже что-то сломалось — они показывают тренд репутации до того, как она рухнёт до блокировки.

Если проблема с доставляемостью повторяется у вас регулярно, вне зависимости от чёрных списков, вероятно дело не только в репутации IP, но и в самой настройке почтового сервера — тут стоит отдельно свериться со статьёй почему письма уходят в спам с Postfix и с общей диагностикой почему не отправляется почта с сервера — часто в игре сразу несколько факторов: SPF/DKIM/DMARC, репутация и содержимое писем.

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