Comments 13
Спасибо за статью, полезная.
Около 2-3 месяцев назад была атака на хостинг. На некоторых сайтах использовали уязвимость и спам как раз сыпался через sendmail прямо в очередь. Пришлось извращаться со spamassassinon и скриптом в кроне, который мониторил очередь и убивал сообщения от определенных адресов. Костыль конечно корявый, но хотя бы закрыл поток спама и дал время для устранения дыры программистам.
Около 2-3 месяцев назад была атака на хостинг. На некоторых сайтах использовали уязвимость и спам как раз сыпался через sendmail прямо в очередь. Пришлось извращаться со spamassassinon и скриптом в кроне, который мониторил очередь и убивал сообщения от определенных адресов. Костыль конечно корявый, но хотя бы закрыл поток спама и дал время для устранения дыры программистам.
Проверяем, что в конфигурационном файле /etc/default/postfwd отсутствет параметр permit_mynetworks в smtpd_recipient_restrictions
Наверное, имелся ввиду /etc/postfix/main.cf?
А так, до описания заглушки — ничего особенного, всё штатно. А дальше костыли, хардкод и уныние.
Штатными средствами Postfix сделать подобное лимитирование в принципе нельзя.
Если предложенную заглушку обозвать «костылем», менее полезной от этого она не становится ;-) Код на GitHub в помощь, никто не мешает сделать более гибкое решение с DBI и т.д.
А вот когда из-за спамеров почтовый сервер оказывается DNSBL — тогда начинается уныние и хардкор.
Если предложенную заглушку обозвать «костылем», менее полезной от этого она не становится ;-) Код на GitHub в помощь, никто не мешает сделать более гибкое решение с DBI и т.д.
А вот когда из-за спамеров почтовый сервер оказывается DNSBL — тогда начинается уныние и хардкор.
Что-то не понимаю, зачем делать обязательную SASL-аутентификацию для локальных пользователей. Что это даёт? Ведь она в любом случае пройдёт успешно. Так зачем жечь энергию и время?
Не понял, зачем нужен setuid. Вроде бы он нигде не используется.
Для остального более вменяемо выглядит mini_sendmail
Не понял, зачем нужен setuid. Вроде бы он нигде не используется.
Для остального более вменяемо выглядит mini_sendmail
SASL-авторизация для локальных пользователей дает возможность установить необходимый лимит количества отправляемых сообщений для каждого пользователя, а также идентифицировать сообщения от пользователей, сайты которых работают под одним именем пользователя (например, www-data).
mini_sendmail и подобные заглушки работают только с серверами, которые не требуют аутентификации от локальных пользователей. В этом случае можно лишь сделать общее правило для всех неавторизированных пользователей.
SETUID нужен для того, чтобы скрипт заглушки был executable, но не readable — пользователи не смогут увидеть данные конфигурации, такие, как пароли.
mini_sendmail и подобные заглушки работают только с серверами, которые не требуют аутентификации от локальных пользователей. В этом случае можно лишь сделать общее правило для всех неавторизированных пользователей.
SETUID нужен для того, чтобы скрипт заглушки был executable, но не readable — пользователи не смогут увидеть данные конфигурации, такие, как пароли.
То, что отправляется через sendmail с сервера, в почтовую очередь в итоге попадает через сервис Postfix cleanup. У него нет похожих фич, есть кое-какие проверки на спам, но ограничение количества писем в час через них не реализуешь.
check_policy_service, вокруг которой в топике всё построено — фича сервиса smtpd в составе Postfix. Чтобы использовать эту фичу для локальных пользователей, необходимо, чтобы почта от них входила в систему через smtpd, то есть, через протокол smtp поверх tcp (или tcp6, если кому-то угодно).
Но, при передаче локалхосту через tcp теряется информация о том, какому локальному пользователю принадлежит процесс, сделавший это. Эта информация нужна, чтобы знать, чьё мы письмо видим, надо ли его задержать или можно отправить, кому увеличить счётчик и так далее.
Чтобы эту информацию иметь, придётся организовать для локальных процессов дополнительную аутентификацию, которая в протоколе ESMTP реализована через SASL.
check_policy_service, вокруг которой в топике всё построено — фича сервиса smtpd в составе Postfix. Чтобы использовать эту фичу для локальных пользователей, необходимо, чтобы почта от них входила в систему через smtpd, то есть, через протокол smtp поверх tcp (или tcp6, если кому-то угодно).
Но, при передаче локалхосту через tcp теряется информация о том, какому локальному пользователю принадлежит процесс, сделавший это. Эта информация нужна, чтобы знать, чьё мы письмо видим, надо ли его задержать или можно отправить, кому увеличить счётчик и так далее.
Чтобы эту информацию иметь, придётся организовать для локальных процессов дополнительную аутентификацию, которая в протоколе ESMTP реализована через SASL.
Виноват, сам мутно сформулировал вопрос. Это было к тому, что я вот смотрю на код и документашку mini_sendmail и там ясно видно, что он вполне себе сохраняет информацию о локальном пользователе (определяет имя через getlogin и, опционально, getpwuid) и выставляет её в виде MAIL FROM. Так что AUTH как бы и не нужен. Или я ошибаюсь и MAIL FROM недостаточно для postfwd и нужен обязательно AUTH?
P.S.: просто ещё не смотрел доки на postfwd, а с mini_sendmail проще оказалось читать исходники.
P.S.: просто ещё не смотрел доки на postfwd, а с mini_sendmail проще оказалось читать исходники.
Спасибо за статью. А как сформировать письмо отчет что пользователь превысил лимит отправки?
Sign up to leave a comment.
Лимитирование исходящих сообщений на сервере с postfix и postfwd