Перебор паролей к почтовым ящикам: увидеть до того, как уйдёт спам

MAATRIX

Обычно про компрометацию почтового ящика узнают не из логов, а из письма от хостинг-провайдера: домен попал в чёрный список, IP заблокирован, клиенты жалуются, что письма не доходят. К этому моменту скомпрометированный аккаунт уже отправил тысячи спам-писем через ваш SMTP, а откатывать репутацию домена — недели. Признаки подбора пароля видны в логах Dovecot и Postfix задолго до того, как это случится — вопрос в том, смотрите ли вы туда вообще.

Что оставляют в логах Dovecot и Postfix попытки подбора пароля

Перебор пароля к почтовому ящику — это не абстрактная угроза, а конкретные строки в /var/log/mail.log (или journalctl -u dovecot -u postfix на системах с systemd-journal). Dovecot логирует каждую неудачную попытку аутентификации с указанием IP, метода и имени пользователя:

Aug 29 03:14:02 mail dovecot: imap-login: Disconnected (auth failed, 3 attempts in 4 secs): user=<info@example.com>, method=PLAIN, rip=185.220.101.47, lip=10.0.0.5, session=<abc123>
Aug 29 03:14:05 mail dovecot: pop3-login: Disconnected (auth failed, 1 attempts in 1 secs): user=<admin@example.com>, method=PLAIN, rip=185.220.101.47, lip=10.0.0.5

Postfix со включённым SASL (когда почтовый клиент авторизуется для отправки через SMTP) пишет похожие предупреждения:

Aug 29 03:14:07 mail postfix/smtpd[28841]: warning: unknown[185.220.101.47]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Aug 29 03:14:09 mail postfix/smtpd[28841]: warning: unknown[185.220.101.47]: SASL PLAIN authentication failed: generic failure

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

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

Как отличить целевой перебор от шума обычных ошибок

Фоновый шум есть всегда: боты сканируют весь интернет по портам 25, 143, 465, 587, 993, 995 и пробуют случайные логины вроде admin, test, info — это не таргетированная атака на ваш конкретный ящик, а массовое сканирование. Игнорировать его нельзя (он может перейти в целевую фазу), но реагировать нужно по-разному.

Признаки, что это уже не фоновый шум, а нацеленный перебор конкретного ящика:

• Десятки и сотни неудачных попыток на один и тот же user= за короткое время (минуты, а не сутки).
• Один IP методично перебирает список логинов из адресной книги компании — то есть атакующий уже знает структуру почты (ivanov@, petrov@, sales@, info@) вместо случайного перебора.
• Успешная авторизация сразу после серии неудач с того же или соседнего IP — это уже не разведка, а взлом.
• Резкий рост исходящих SMTP-сессий от одного ящика сразу после успешного логина — верный признак, что скомпрометированный аккаунт уже начал слать спам.

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

grep "auth failed" /var/log/mail.log | grep "$(date +'%b %e')" | wc -l

Ориентируйтесь на свою историю, а не на чужие цифры — на маленьком сервере с парой ящиков и десять попыток в час уже необычны, на крупном почтовом сервере с сотнями пользователей фоновый шум может быть заметно выше. Важна не абсолютная цифра, а резкое отклонение от вашей же нормы.

Алерты в реальном времени: от grep по логам до Telegram

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

Уровень 1 — скрипт по cron. Самый быстрый способ получить сигнал: скрипт раз в 5 минут проверяет свежие строки лога на превышение порога неудачных попыток по одному IP или логину и шлёт уведомление в Telegram.

#!/bin/bash
# /usr/local/bin/mail-auth-watch.sh
THRESHOLD=10
LOGFILE=/var/log/mail.log
BOT_TOKEN="ваш_токен"
CHAT_ID="ваш_chat_id"

# Смотрим только последние 5 минут лога
SINCE=$(date -d '5 minutes ago' '+%b %e %H:%M')

FAILS=$(awk -v since="$SINCE" '$0 >= since' "$LOGFILE" | grep -E "auth failed|SASL.*authentication failed")

echo "$FAILS" | grep -oP 'rip=\K[0-9.]+|unknown\[\K[0-9.]+' | sort | uniq -c | sort -rn | while read count ip; do
  if [ "$count" -ge "$THRESHOLD" ]; then
    curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
      -d chat_id="${CHAT_ID}" \
      -d text="Почта: $count неудачных попыток входа с IP $ip за последние 5 минут"
  fi
done

Добавьте в cron: */5 * * * * /usr/local/bin/mail-auth-watch.sh. Это не элегантно, зато работает без дополнительной инфраструктуры и ловит атаку в первые минуты, а не когда домен уже в чёрном списке. Подробный разбор настройки самих уведомлений — в статье про алерты в Telegram с сервера.

Уровень 2 — rsyslog + собственное правило. Если логи уже собираются централизованно (например, в Grafana Loki), добавьте alert-правило на паттерн authentication failed с агрегацией по IP за окно в несколько минут — это снимает нагрузку с cron-скрипта и даёт графики динамики атак, а не только точечные уведомления.

Уровень 3 — fail2ban с оповещением. Fail2ban не просто банит — он же может слать уведомление о каждом бане через action с почтовым или Telegram-хуком. Это удобно тем, что вы получаете сигнал о срабатывании автоматической защиты, а не только о попытках — то есть видите именно те случаи, когда порог реально превышен.

Для небольшого сервера с 1-3 доменами достаточно уровня 1. Если ящиков десятки и почта критична для бизнеса — стоит сразу закладывать централизованный сбор логов, иначе через полгода разбираться в разрозненных cron-скриптах станет больнее, чем настроить нормальный алертинг с самого начала.

Ограничение попыток и временная блокировка: fail2ban и встроенные лимиты

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

Встроенные лимиты Dovecot. В /etc/dovecot/conf.d/10-auth.conf есть параметр, который специально существует для замедления перебора:

auth_failure_delay = 2 secs

Это не блокировка, а задержка ответа после каждой неудачной попытки — превращает быстрый автоматизированный перебор в медленный. В связке с ограничением одновременных соединений с одного IP в /etc/dovecot/conf.d/20-imap.conf и 20-pop3.conf:

mail_max_userip_connections = 10

это не остановит целевую атаку полностью, но резко снизит скорость перебора и даст время сработать внешней блокировке.

fail2ban поверх логов. Это основной инструмент временной блокировки IP по факту превышения числа неудачных попыток. Стандартный дистрибутив fail2ban уже включает готовые jail'ы для Dovecot и Postfix — их нужно только включить и настроить пороги под себя:

# /etc/fail2ban/jail.local
[postfix-sasl]
enabled = true
port = smtp,465,submission
filter = postfix-sasl
logpath = /var/log/mail.log
maxretry = 5
findtime = 600
bantime = 3600

[dovecot]
enabled = true
port = imap,imaps,pop3,pop3s
filter = dovecot
logpath = /var/log/mail.log
maxretry = 5
findtime = 600
bantime = 3600

Для повторных нарушителей имеет смысл настроить прогрессивный бан — увеличивать bantime при повторной блокировке того же IP (параметр bantime.increment = true в секции [DEFAULT]), чтобы не тратить ресурс на разбан ботов, которые вернутся через час и продолжат с той же точки. Базовую настройку fail2ban с нуля и типовые грабли разбирали отдельно — см. установку и настройку защиты от брутфорса на VPS.

Важный нюанс: если почта работает через контейнер или за обратным прокси (например, Traefik перед Dovecot-контейнером), в логах может оказаться IP прокси вместо реального адреса атакующего — тогда бан просто не сработает или заблокирует сам прокси. Проверяйте, что rip= в логах Dovecot — это действительно внешний IP, а не адрес docker-моста.

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

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

Практически это можно закрыть на нескольких уровнях:

• GeoIP-фильтрация на файрволе. Модуль xtables-addons с базой GeoIP позволяет закрыть порты 143/993/110/995/587/465 для стран, из которых у вас нет и не должно быть легитимных пользователей. Это грубый инструмент — используйте его только если аудитория почты реально ограничена географически, иначе рискуете отрезать себе или клиентам доступ в командировке.
• Alert на смену страны для одного ящика. Если вы уже собираете логи централизованно, полезно определять страну по IP (через локальную GeoIP-базу, не внешний API — чтобы не утекали адреса пользователей на сторону) и слать уведомление, когда один и тот же логин авторизуется из двух разных стран в течение короткого окна — классический признак того, что пароль либо украден, либо расшарен туда, куда не должен.
• CrowdSec вместо статичных списков. В отличие от fail2ban, который реагирует только на события своего сервера, CrowdSec может использовать репутационные списки IP, замеченных в атаках на другие серверы сообщества — это ловит атакующих ещё до первой неудачной попытки на вашем сервере. Сравнение подходов — в статье fail2ban или CrowdSec: что выбрать для сервера.

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

Двухфакторная аутентификация для почты: что реально работает, а что нет

Здесь важно честно проговорить ограничение: классические протоколы IMAP и POP3, а также базовая SMTP AUTH, не умеют интерактивно запрашивать второй фактор — они рассчитаны на однократную передачу логина и пароля почтовым клиентом, без диалога "введите код из приложения". Поэтому "включить 2FA на Dovecot" в том же смысле, что 2FA на SSH, напрямую невозможно — и любой материал, который обещает такое простое включение, скорее всего описывает не то, что вы думаете.

Что реально работает:

• 2FA на веб-интерфейсах. Roundcube, SOGo и панели управления почтой (включая панели хостинг-провайдеров) — обычные веб-приложения, и для них двухфакторная аутентификация настраивается штатно, через плагины или встроенный функционал. Если основной канал доступа сотрудников — веб-почта, это закрывает большую часть риска. Подход тот же, что и для 2FA на панелях управления серверами — принцип идентичен, меняется только защищаемый сервис.
• OAuth2 / XOAUTH2 вместо пароля. Dovecot и современные почтовые клиенты поддерживают механизм XOAUTH2, когда клиент аутентифицируется не паролем, а токеном, выданным внешним identity-провайдером (Keycloak, Azure AD и подобные) — сам провайдер уже может требовать второй фактор при выдаче токена. Это правильное решение, но требует поднятия и поддержки отдельного OIDC-провайдера — оправдано для организации с десятками сотрудников, избыточно для личного почтового сервера на пару ящиков.
• Пароли приложений (app passwords) как компромисс. Если полноценный OAuth2 разворачивать не хотите, для IMAP/SMTP-клиентов можно выдавать отдельные длинные сгенерированные пароли, не совпадающие с паролем от веб-интерфейса — тогда компрометация одного канала не даёт доступа к другому, а сами app-пароли проще отозвать точечно, не трогая основной пароль пользователя.

Практический вывод: раз протокольного 2FA для IMAP/SMTP в общем случае нет, вес переносится на мониторинг и лимиты попыток из предыдущих разделов — они и есть ваш фактический "второй рубеж" для протоколов, где второго фактора нет физически.

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