linuxdv-static/articles/2014/10/15/postfix_and_spam/index.markdown

title	tags
postfix и спамеры	mail, postfix

В этой заметке собраны практические наработки по противодействию спаму для систем, использующих postfix в качестве MTA.

---

Штатные средства

Первое и главное, на что нужно смотреть в конфиге по-умолчанию - это для кого и от кого принимается почта. Основные опции, которые нужно посмотреть:

• mydestination -- домен или конкретное имя этого хоста. Ничего лишнего. Если вы используете виртуальные домены - оставьте только localhost.
• mynetworks[_style] -- ни в коем случае не 0.0.0.0/0, юзеры из этих сетей получают больше прав "по умолчанию", в частности доступ к использованию пересылки почты на внешние адреса.
• relay_domains -- пересылать почту для этих доменов, по умолчанию - то же самое что и mydestination
• virtual_mailbox_domains -- то же самое что и mydestination, но для виртуальных доменов. см. VIRTUAL_README в документации, чтобы понять чем они отличаются от "обычных".

Полный список опций с их описанием можно посмотреть в postconf(5).

Далее, начинаем рубить спамеров ещё "на подлёте":

HELO/EHLO

smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
                          permit_sasl_authenticated,
                          reject_non_fqdn_helo_hostname,
                          reject_unknown_helo_hostname,
                          permit

Ограничения:

• reject_non_fqdn_helo_hostname -- требовать, чтобы в HELO/EHLO было что-то похожее на hostname
• reject_unknown_helo_hostname -- ...и этот хостнейм должен ресолвится по dns'у в ipv4/v6 адрес

Первое помогает от совсем тупых ботов, второе - частично от vps'ок с ломанным wordpress'ом.

Адрес клиента, IPv4/IPv6

smtpd_client_restrictions = permit_mynetworks,
                            permit_sasl_authenticated,
                            reject_unauth_pipelining,
                            check_client_access hash:/etc/postfix/relay_access,
                            reject_unknown_client_hostname,
                            check_reverse_client_hostname_access pcre:/etc/postfix/reverse_hostname_access.pcre,
                            reject_multi_recipient_bounce,
                            permit

Ограничения:

• reject_unauth_pipelining -- сбрасывать сессию, если клиент пытается отправлять команды не дождавшись ответа на предыдущую команду
• reject_unknown_client_hostname -- сбрасывать сессию, если не совпадают записи IP -> DNS/PTR или DNS/A -> IP для того хостнейма, что указан в EHLO см также. reject_unknown_reverse_client_hostname, более слабую альтернативу этой проверки.
• reject_multi_recipient_bounce -- сбрасывать сессию, если не указан отправитель и указано несколько получателей.
• check_reverse_client_hostname_access -- позволяет дать отлуп заведомо левым хостам на основе ненастроенной PTR записи

Помогает от биомассы с завирусованным виндузом, дырявых CMS на VPS'ках и просто кулхацкеров на диалапе. Примерное содержимое файлика:

/.*(dynamic|broadband|\.dyn\.|\.ddns|\.vps\.).*/i       421 Dynamic hostname. Fix it and try again.
/.*(\.adsl|\.cdma\.|\.pptp|\.pppoe|\.cable).*/          421 Dynamic hostname. Fix it and try again.
/.*(\d+[-.]){4}.*/                                      421 Dynamic hostname. Fix it and try again.

Исключения:

• check_client_access -- позволяет вводить исключения для произвольных хостов.

Адрес отправителя

smtpd_sender_restrictions = reject_non_fqdn_sender,
                            permit_auth_destination,
                            reject_unknown_sender_domain,
                            permit

Ограничения:

• reject_non_fqdn_sender -- в MAIL FROM: должно быть что-то похожее на email
• reject_unknown_sender_domain -- проверить через dns, что домен отправителя действительно существует

Также, можете задействовать это:

• reject_unverified_sender -- сбросить сессию, если обратное письмо отправителю заведомо не будет доставлено

Это достаточно хардкорная опция, и должна применяться ограниченно. Суть такова: наш сервер соединяется с доменом отправителя и пытается отправить ему письмо, сбрасывая отправку в последний момент. Можно легко нарваться на тот же кривонастроенный fail2ban, и почта к этому домену перестанет ходить вовсе. Кроме того, эта опция вносит ощутимую задержку в доставку письма - до 20 секунд.

Адрес получателя

smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                               permit_sasl_authenticated,
                               check_client_access hash:/etc/postfix/relay_access,
                               reject_unauth_destination,
                               permit_mynetworks,
                               check_policy_service unix:private/policy,
                               permit_auth_destination,
                               sleep 5,
                               reject

• reject_non_fqdn_recipient -- в RCPT TO: должно быть что-то похожее на email
• reject_unauth_destination -- "у нас нет такого юзера"/"это не наш домен"
• check_policy_service -- проверять SPF, если он есть у домена отправителя
• задержка в конце - добавлена для противодействию перебору адресов

Внешние средства

Средства самого постфикса - это хорошо, но явно недостаточно. Я могу выделить 2 категории внешних средств, работающих со входящей почтой.

Первая из них - средства, работающие до принятия письма к доставке. (Перечислены только основные и широко используемые)

• fail2ban -- бан особо назойливых ботов, срабатывание настраивается на множественные сбои авторизации, "relay denied" и "no such recipient"
• dnsbl -- проверка по dns'у ip-адресов клиента. Опция достаточно спорная, листы могут просто не успевать обновляться.
• SPF -- сейчас уже "must have". Требует достаточно мало ресурсов, очень эффективна для доменов отправителя с политикой "-all", в крайнем случае "~all" поможет спамфильтру. Важно: следует использовать только reject'ы от этой проверки. См wide-mask vulnerability
• DKIM -- в какой-то мере аналог SPF, но применяется для проверки отправителя/получателя вместо ip-адресов. Тоже - использовать только reject'ы.
• postscreen -- специализированный фаервол для postfix'а, расширяет возможности встроенных проверок

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

• весь спектр байесовских спам-фильтров (dspam, spamasassin, и что полегче: bogofilter, crm114, и т.д.)
• антивирусы
• DCC, razor и прочие контент-блэклисты.
• обратная связь от юзера со спамфильтром

На последнем пункте стоит остановиться отдельно. Использование такой связи не должно быть сложнее "переслать это письмо"/"переместить в Спам", иначе оно просто не будет использоваться юзерами. Первый вариант, с пересылкой - реализуется на postfix'е отдельным транспортом или условием в procmail'е, второй - через dovecot или что вашем конкретном случае отдаёт юзеру его почту.

Раскладывание почты по INBOX/Spam реализуется на procmail'е или том же dovecot'е (плагин lda), после прогона по всем спамфильтрам/антивирусам.

Отдельно подчёркиваю, что средства второй категории не должны слать ничего наружу, и крайне неохотно - админу почтовой системы. Первый случай может использоваться для спама через bounce, второй - для DOS атаки.