Почему Fail2ban не блокирует атаки на Zimbra

Fail2ban на Zimbra не начинает блокировать попытки входа сам по себе: сначала нужно правильно передавать исходный IP, выбрать реальные журналы и проверить фильтр на их строках. Официальный гайд Zimbra описывает такую настройку; ниже покажу порядок проверки и объясню, почему зелёный статус службы ничего не доказывает.

Почему Fail2ban запущен, но никого не блокирует

Когда я сопровождаю корпоративную почту, эту проверку начинаю с цепочки: Fail2ban читает журнал, сопоставляет строки с регулярным выражением фильтра и при достижении порога запускает заданное действие. Если хотя бы одно звено не совпало — журнал не тот, шаблон не ловит строку или действие не может применить сетевое правило — служба может оставаться активной, а блокировок не будет. Поэтому фраза «сервис запущен» описывает только состояние процесса, но не результат защиты. Я всегда проверяю цепочку целиком: запись о неудачной авторизации, найденное совпадение, срабатывание jail и фактическое действие для тестового адреса.

В официальном руководстве Zimbra есть отдельная настройка Fail2Ban для веб-входа и SMTP. В ней используются разные фильтры и журналы: для веб-интерфейса приведён /opt/zimbra/log/mailbox.log, для SMTP — /var/log/zimbra.log. Это пример конфигурации, а не гарантия, что те же пути подходят каждому выпуску и каждой схеме развёртывания. Сначала найдите запись именно на своём сервере, затем подбирайте фильтр. Старый фрагмент из блога не становится совместимым только потому, что его скопировали без ошибок.

Ещё одна причина ложного спокойствия — адрес клиента. Если перед Zimbra стоит прокси, в журнале может оказаться адрес самого прокси, а не пользователя или атакующего. Тогда Fail2ban считает попытки от общего адреса и рискует заблокировать нормальных посетителей вместе с нарушителем. В Zimbra это решается корректной настройкой originating IP (OIP) и доверенных адресов. В руководстве производителя прямо сказано выполнить OIP-настройку до подключения Fail2Ban. Порядок здесь важен; иначе фильтр честно обработает неверные данные.

• Проверьте запись неудачного входа
• Сверьте адрес клиента в журнале
• Проверьте совпадение фильтра
• Убедитесь, что действие применилось

Что сначала настроить в Zimbra: originating IP

OIP — это исходный адрес клиента, который Zimbra должна сохранять при работе через прокси или балансировщик. Если доверенные адреса настроены неправильно, mailbox может записывать адрес промежуточного узла. В таком случае Fail2ban видит не источник отдельных попыток, а один общий адрес. Результат предсказуем: либо бан не помогает, либо под ограничение попадают пользователи, которые ходят через тот же прокси. Это не мелкая косметика в логе, а основа корректного решения о блокировке.

В руководстве Zimbra для односерверной схемы показана настройка доверенного адреса через zmprov mcf +zimbraMailTrustedIP, для нескольких серверов отдельно задаются доверенные адреса mailbox и proxy; после изменения авторы руководства перезапускают Zimbra командой zmcontrol restart. Эти примеры привязаны к описанной схеме, поэтому копировать команды с чужими IP нельзя. Составьте список своих узлов, проверьте, кто завершает HTTPS-соединение, и внесите только доверенные адреса по документации для своего развёртывания. Ошибка в списке доверенных узлов меняет интерпретацию клиентских адресов.

Перед настройкой защиты я проверяю адрес в свежей строке mailbox.log после входа через штатный клиентский путь. Если виден адрес прокси, OIP ещё не решён. Если виден адрес клиента, следующий этап — проверить регулярное выражение на реальных строках. В отдельной статье о журналах Zimbra и признаках перебора разобраны сами признаки подозрительной активности; здесь нас интересует другая задача — сделать так, чтобы защитное правило получало достоверный адрес.

На этом этапе полезно записать простую таблицу: какой адрес ожидаем увидеть, какой адрес фактически пишет Zimbra и какой узел должен применить бан. Для одиночной установки эти роли могут совпадать; при отдельном proxy и mailbox — нет. Если Fail2Ban читает журнал на одном сервере, а правило нужно поставить на другом, локальное действие не перекроет трафик на соседнем узле. В официальном гайде Zimbra отдельно отмечено, что Fail2Ban по умолчанию выполняет действие на том сервере, где читает журнал; для распределённой схемы нужна отдельная удалённая action. Я не включаю такую схему без проверки маршрута и прав: лишний SSH-доступ ради бана — отдельная зона риска.

Как выбрать журнал и проверить фильтр

Не начинайте с имени файла zimbra.conf. В официальном примере веб- и SMTP-входы разведены: фильтру zimbra-web назначен mailbox.log, а zimbra-smtp читает /var/log/zimbra.log. Для обоих показаны свои регулярные выражения: веб-фильтр ищет запись с ip=<HOST> и признаком неудачной аутентификации, SMTP-фильтр разбирает сообщения Postfix о провале SASL. Главное здесь не конкретная строка из чужого примера, а раздельная проверка источников событий: веб-вход и SMTP-аутентификация оставляют разные следы.

Установите фактическое расположение журналов на своём сервере и убедитесь, что процесс Fail2Ban может их читать. Затем возьмите несколько свежих строк с неудачной авторизацией и несколько обычных строк рядом. Прогоните фильтр утилитой fail2ban-regex, указав реальный журнал и файл фильтра: fail2ban-regex /путь/к/журналу /etc/fail2ban/filter.d/имя-фильтра.conf. Не публикуйте в отчётах адреса и имена ящиков; для проверки достаточно локального вывода. Если ожидаемая строка не совпала, сначала исправьте шаблон, а не увеличивайте maxretry до абсурда.

Правило должно извлекать адрес из корректного поля, а не просто находить слова «failed» или «authentication». Иначе оно может считать повторные записи одного события, ловить не тот протокол или принимать адрес прокси за адрес клиента. Я проверяю совпадения на старых и новых строках отдельно: журналирование меняется при обновлениях и изменении маршрута трафика, но это не означает, что после каждого обновления формат непременно меняется. Регулярное выражение пересматривают по фактическому журналу, а не по календарю.

При настройке чтения журнала проверьте ротацию. Файл может переименовываться или заменяться, а процесс мониторинга должен продолжить читать актуальные записи. После теста перезапуска и ротации посмотрите, видит ли jail новые события; иначе один удачный fail2ban-regex на архивном файле создаст ложное чувство готовности. Уточните также, не дублируются ли записи в централизованном syslog. Повтор одной неудачной попытки в двух источниках способен быстрее довести счётчик до порога, чем предполагал администратор. Источник истины для регулярного контроля должен быть один, либо пороги нужно рассчитывать с учётом дублей.

Настройка jail и безопасного действия бана

Параметры фильтра и jail — разные части настройки. Фильтр описывает, какие строки считать неудачными входами; jail связывает фильтр с журналом, порогом и действием. В примере Zimbra конфигурация jail вынесена в /etc/fail2ban/jail.d/zimbra.local, а файлы фильтров лежат в /etc/fail2ban/filter.d/. Распространённый путь /etc/fail2ban/filter.d/zimbra.conf допустим лишь если вы действительно создали такой фильтр и сослались на него в jail. Универсального обязательного имени zimbra.conf нет.

Параметры maxretry, findtime и bantime задают число совпадений, временное окно и длительность блокировки. Они не являются готовыми безопасными значениями: учитывайте пользователей за общим NAT, число почтовых клиентов и характер ошибок пароля. Официальная публикация Zimbra для своего примера указывает конкретные значения, но они не превращают их в норму для любой компании. Начните с анализа реальных журналов, внесите исключения для своих доверенных адресов только после проверки и не ставьте длительный бан, пока не проверили, что в поле <HOST> попадает нужный адрес.

Не считайте iptables-allports стандартным выбором для всех серверов. В официальном гайде Zimbra используется действие route, а автор отдельно предупреждает о возможных ошибках при сочетании с UFW или firewalld. Выберите действие, которое соответствует реально работающему сетевому фильтру и поддерживается вашей системой; проверьте его на тестовом адресе и заранее подготовьте способ снять блокировку. Fail2Ban может блокировать IP сетевым действием, но точная реализация зависит от backend и конфигурации. Это место для проверки, а не для копирования команды из статьи десятилетней давности.

Не расширяйте блокировку на все порты автоматически. Такой выбор может оборвать не только веб-вход, но и доступ к другим сервисам с того же адреса. В маленьком офисе за NAT с одного внешнего IP одновременно работают сотрудники, мобильные устройства и подрядчики; ошибка фильтра здесь превращает защиту от перебора в общий отказ доступа. Сверьте список публичных точек входа, исключения и фактический scope сетевого action. Защищённые адреса администраторов добавляйте в ignore list только после инвентаризации: забытый старый адрес в исключениях — это постоянная слепая зона, а не удобство.

• Отделите фильтр от jail
• Сверьте журнал и имя фильтра
• Согласуйте action с firewall
• Подготовьте снятие тестового бана

Как проверить работу без догадок

Начните с fail2ban-client status: команда показывает активные jail. Затем запросите конкретную секцию, например fail2ban-client status zimbra-web, если именно так назван ваш jail. Смотрите не на одну цифру, а на весь результат: сколько совпадений накоплено, сколько адресов сейчас заблокировано и какое действие назначено. Нулевое число блокировок само по себе не доказывает ошибку — возможно, порог ещё не достигнут. Но если в журнале есть попытки входа, а фильтр не находит ни одной подходящей строки, цепочка сломана до этапа бана.

Проверьте синтаксис конфигурации и совпадения на копии журнала до перезапуска службы. После загрузки настройки изучите журнал самого Fail2Ban: он покажет ошибки чтения файла, неизвестные имена фильтров и проблемы запуска action. Производитель Zimbra предлагает проверять jail через клиент Fail2Ban и отдельно показывает fail2ban-regex для тестирования регулярного выражения. Это лучше, чем судить по тому, что процесс виден в списке служб. Утилита отвечает на вопрос «что совпало», статус jail — «что включено», а проверка сетевого правила — «применился ли бан».

Контрольный тест проводите согласованно и с адреса, который можно безопасно заблокировать и разблокировать. Не запускайте перебор паролей на реальном ящике и не проверяйте защиту с адреса офиса, если он используется всей командой. После теста проверьте запись в журнале, статус jail и результат сетевого действия, затем снимите временный бан. Для внешнего мониторинга достаточно фиксировать появление и снятие блокировок; массовые срабатывания требуют проверки, но сами по себе ещё не означают компрометацию. Fail2Ban — один слой, он не заменяет MFA, обновления и контроль паролей.

Для проверки результата сохраните исходную строку события, время, имя jail и результат action без лишних персональных данных. Сравните это с записью в журнале firewall или таблице маршрутизации — конкретный способ зависит от выбранного действия. Убедитесь также, что удаление правила происходит после истечения bantime или ручного unban. Зависшее правило после эксперимента может выглядеть как продолжающаяся атака, хотя блокировка уже не связана с текущими событиями. Если в статусе растут совпадения, а блокировок нет, проверяйте threshold; если бан числится, но подключение продолжается, проверяйте точку применения правила и существующие соединения.

Отдельно оцените последствия ошибки для пользователей. Если корпоративная почта доступна через общий NAT, блокировка одного внешнего адреса затронет несколько устройств; если это адрес мобильного оператора, он может меняться и использоваться разными абонентами. Это не повод отказываться от сетевой защиты, но повод выбирать пороги и область действия осознанно. Там, где допустимо, ограничьте действие нужными сервисами и согласуйте исключения с владельцами сети. Запишите, кто может снять бан, где посмотреть активный список и как быстро восстановить доступ. У правила без понятного отката есть неприятная особенность: первым его проверяет тот, кто сам потерял доступ.

Что проверить после обновления и в типовых ошибках

После обновления Zimbra или изменения прокси-пути я сверяю фактическую строку входа, значение originating IP и совпадение регулярного выражения. Не надо заранее считать, что обновление обязательно поменяло формат логов или расположение файлов. Проверка занимает меньше времени, чем расследование после месяца молчания: сопоставьте свежую запись с шаблоном через fail2ban-regex, проверьте, что jail читает нужный файл, и убедитесь, что action может применить правило. Если менялась только операционная система, дополнительно проверьте совместимость сетевого backend и правила firewall.

Самые частые ошибки — взять фильтр для другой версии, смешать веб- и SMTP-логи, настроить порог до выяснения реального адреса клиента и принять активную службу за работающую защиту. Ещё одна ловушка — проверять исключительно fail2ban.log: файл может быть настроен в другое место, а подробность вывода зависит от конфигурации. Команда fail2ban-client get logtarget подскажет назначение логирования в поддерживаемых версиях. Если бан не срабатывает, идите по цепочке от источника события к action, а не переписывайте всё сразу.

У Zimbra есть собственный DoSFilter, и его не нужно описывать как блокировку одной учётной записи: база знаний по этой части неточна. Официальный материал Zimbra отдельно описывает конфигурацию Fail2Ban для блокировки атакующих адресов, а настройки DoSFilter относятся к контролю HTTP-нагрузки и поведения клиента. Эти механизмы не взаимозаменяемы. В моих разборах я сначала выясняю, что именно фиксирует журнал и где теряется адрес, а уже потом выбираю порог или сетевой action. Если хочется начать с общей диагностики почтовой платформы, полезен материал про администрирование Zimbra.

В условном разборе студии «Центурион-Трейд» я бы не называл настройку успешной по одной строке «служба active». Сначала фиксируем, какой журнал читает jail, проверяем запись неудачной авторизации, подтверждаем клиентский адрес после proxy и только затем делаем контролируемый тест. Если нужный адрес появился в статусе и action установил ожидаемое правило, результат можно считать проверенным для этой точки входа. Для SMTP понадобится отдельно проверить свой фильтр и свой журнал. Я не приписываю этому примеру число атак, срок настройки или якобы достигнутый процент блокировок: без проверяемого журнала такие цифры были бы рекламной декорацией.

• Проверьте свежие строки после изменений
• Сверьте OIP и адрес прокси
• Протестируйте regex и jail
• Проверьте сетевое действие и откат

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