zimbra 8 policyd привел счетчик квоты инкрементов входа в систему SMTP к сбою
Я пытаюсь настроить policyd политику в Zimbra, который определяет макс. номер исходящих электронных писем для данного отправителя (user@domain). Я тестировал его с простым сценарием, чтобы войти в сервер SMTP и отправить тестовую почту. Я заметил, если я опустил данные для входа, запрос SMTP был отклонен (Неудавшаяся Авторизация), но policyd счетчик квоты был все еще увеличен!
Там некоторый путь состоит в том, чтобы помешать отказавшим попыткам входа в систему достигнуть политики? Я волнуюсь, что это могло использоваться в качестве DoS-атаки.
Введение
Zimbra - это электронная почта и костюмы для совместной работы. Он использует постфикс как MTA. Вы можете дополнительно включить policyd для предоставления ограничивающих функций, таких как квота или дроссель.
Каждая конфигурация может быть изменена через веб-интерфейс или интерфейс командной строки. Прямое редактирование файла конфигурации / базы данных не должно выполняться. Zimbra может перезаписать его при обновлении или перезапуске.
Включение policyd
Согласно этой странице , мы можем включить policyd, выполнив только две командные строки.
В фоновом режиме zimbra изменит постфикс конфигурация. Здесь вывод postconf -n до и после включения policyd.
smtpd_client_restrictions = reject_unauth_pipelining
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_end_of_data_restrictions =
smtpd_etrn_restrictions =
smtpd_helo_restrictions =
smtpd_recipient_restrictions = yreject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unlisted_recipient, reject_invalid_helo_hostname, reject_non_fqdn_sender, permit
smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination
smtpd_restriction_classes =
smtpd_sender_restrictions =
После
smtpd_client_restrictions = reject_unauth_pipelining
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_end_of_data_restrictions = check_policy_services 127.0.0.1:10031
smtpd_etrn_restrictions =
smtpd_helo_restrictions =
smtpd_recipient_restrictions = check_policy_services 127.0.0.1:10031, reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unlisted_recipient, reject_invalid_helo_hostname, reject_non_fqdn_sender, permit
smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination
smtpd_restriction_classes =
smtpd_sender_restrictions = check_policy_services 127.0.0.1:10031
анализа
Поведение, которое произошло в вашей zimbra, можно объяснить после анализа вывода postconf -n . На этапе smtpd_sender_restrictions zimbra уже связывается с policyd (с помощью check_policy_services). На этом этапе счетчик уже увеличивал . На этапе smtpd_relay_restrictions постфикс отклоняет электронное письмо, выдав сообщение об ошибке «авторизация не удалась».
Решение
На основе анализа выше, поведение можно предотвратить, удалив check_policy_services в smtpd_sender_restrictions. Postfix по-прежнему вызывает check_policy_services в smptd_recipient_restrictions.
Отказ от ответственности:
- Это относится к версии Zimbra 8.0.7. Другая версия может не иметь этой ошибки.
- Как указано выше, прямое редактирование файла конфигурации официально не поддерживается. Может быть, есть дизайнерская причина, по которой Zimbra разместила политику раньше, и прямое редактирование может ее нарушить. В целях безопасности вы можете опубликовать его в службе поддержки zimbra и обсудить с разработчиками zimbra.