Смотрим плавность хода с помощью BMW Rheingold

Всем знакома ситуация, когда двигатель немного "троит", но пропусков зажигания нет...

Дельта синхронизация без облака

Ранее мы показывали разные способы синхронизации криптодиска между ПК и Android-устройством.

Дельта-синхронизация крипто-дисков

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

Облачный хостинг VDS за 2 минуты

Настоящий облачный VDS-хостинг от UltraVDS: тестируем производительность

Настройка Postfix или Антиспам без оружия


Лично от demon
Весьма признателен автору этой статьи Сергею Литвиненко.
После настройки postfix по этой статье практически полностью избавился спама.

Пролог: спам - чума 21 века. В данной статье приведены практические рекомендации, позволяющие избавиться от этой чумы.

Имеем:

Любую установку Postfix для сервера example.com, с внутренним интерфейсом 192.168.0.1 и внешним 80.80.80.80 (для примера, везде где встречаются необходиом заменитть на свои).

Задача:

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

Требуемая политика для Postfix:

  • разрешена отправка писем с адресов внутренней сети
  • разрешен прием писем снаружи для адресатов внутри
  • прием писем только от существующих и корректных адресатов
  • прием писем только для имеющихся на сервере адресатов
  • для отправки писем FROM: *@example.com с невнутренних хостов требовать обязательную авторизацию, без авторизации письма отклонять

Применяемые технические решения:

  • разрешать внутренним ип-адресам отправлять письма на несуществующие email-адреса (рассылка рекламного отдела)
  • проверять существование и корректность адреса отправителя
  • проверять существование и корректность адреса получателя
  • проверять корректность IP-адреса сервера передающего письм
  • проверять наличие IP-адреса отправителя в списках DNSBL
  • отклонять письма с IP-адресов, определяемых как динамические (dialup & adsl)
  • для "особо продвинутых" респондентов с кривыми настройками применять "белые списки"

Настройки

файл /etc/postfix/main.cf:

# список подсетей, которым разрешена отправка писем, и на
# письма с которых многие проверки не распространяются.
# здесь не должно быть подсетей, которые не являются "внешними"(80.80.80.80 - везде меняем на свой IP)
mynetworks = 80.80.80.80, 192.168.0.0/24, 127.0.0.0/8

# отсекаем криво настроенные почтовые агенты
strict_rfc821_envelopes = yes

# запрещаем проверку отправителем существование адреса получателя
# на этапе передачи заголовка
disable_vrfy_command = yes

# разрешаем дополнительные проверки пока отправитель
# передает RCPT TO: и MAIL FROM: заголовки. Для детализации mail.log
smtpd_delay_reject = yes

# требуем от отправителя представиться
# (на том, как себя представляет передающий комп,
# основаны многие эффективные проверки "на вшивость"
# автоматических рассылок от зомби и троянов)
smtpd_helo_required = yes

# ограничения на приветствие отправителя HELO/EHLO
smtpd_helo_restrictions =
# разрешаем все для внутренних клиентов
permit_mynetworks, 
# разрешаем все для тех, кто пройдет SASL-авторизацию по SMTP
permit_sasl_authenticated,
# "Белый Список" должен быть впереди остальных проверок
# отсекаем приветствия отправителя от моего имени
# а также прописываем разрешения для "продвинутых"
# пример файлика см ниже
check_helo_access hash:/etc/postfix/helo_access,
# отсекаем тех, кто представляется ИП-адресом.
# это явное нарушение RFC, но практика показала, что это один из явных признаков спама.
check_helo_access regexp:/etc/postfix/helo_regexp,
# также проверям на динамические адреса (спасибо тем ISP, которые прописывают обратные зоны)
check_helo_access regexp:/etc/postfix/dul_checks,
# отсекаем кривые адреса (противоречащие RFC, например бывают и 
# такие helo=<|http://mail.oldartero.com:8888/cgi-bin/put>
reject_invalid_hostname,
# если все вышеперечисленное подошло, идем дальше
permit

# ограничения, проверяемые на этапе MAIL FROM:
smtpd_sender_restrictions =
# принимаем почту на отправку с "чужих" хостов, если пользователь
# авторизовался по логину/паролю
permit_sasl_authenticated,
# "своим" можно и "просто"
permit_mynetworks,
# разрешаем или запрещаем "продвинутым"
check_sender_access regexp:/etc/postfix/sender_access,
# см комментарий к разделу smtpd_helo_restrictions
reject_non_fqdn_sender,
reject_unknown_sender_domain,
# если все вышеперечисленное подошло, идем дальше
permit

# ограничения, проверяемые на этапе RCPT TO:
smtpd_recipient_restrictions =
# запрещаем выдачу писем в поток, как это делают
# нетерпеливые спаммеры
reject_unauth_pipelining,
# разрешаем "своим" все
permit_sasl_authenticated,
permit_mynetworks,
# см комментарий к разделу smtpd_sender_restrictions
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
# запрещаем принимать письма для несуществующих в системе адресов
reject_unlisted_recipient, 
# запрещаем или разрешаем "продвинутым"
check_recipient_access regexp:/etc/postfix/recipient_access,
# !!! !!! !!! !!! !!!
# запрещаем прием и передачу писем, не относящихся к нам
# без этой строчки сервер становится open-relay
reject_unauth_destination,
# !!! !!! !!! !!! !!!
# если все вышеперечисленное подошло, идем дальше
permit

# проверяем, а не является (по признакам ДНС-имен) ли
# динамически-назначаемым IP-адрес хоста-отправителя (определяемого
# по соединению, а не по приветствию или разрешенному ДНС/IP-адресу)
smtpd_client_restrictions =
# разрешаем "своим" все
permit_mynetworks,
# прописываем адреса "продвинутых" в белом списке (пример файлика ниже)
check_client_access hash:/etc/postfix/client_access,
# в файле dul_checks регулярные выражения доменных имен,
# наиболее часто используемых для обратных зон блоков
# динамически назначаемых адресов и
# широкополосных клиентских подключений
check_client_access regexp:/etc/postfix/dul_checks,
# проверяем IP-адрес отправителя по спискам DNSBL (www.ordb.org)
reject_rbl_client bl.spamcop.net, 
reject_rbl_client list.dsbl.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client relays.ordb.org,
reject_rbl_client relays.ordb.org,
permit

остальное вообщем-то на усмотрение или стандартно.

теперь указанные в кач-ве параметров файлы:

файл /etc/postfix/helo_access:

example.com REJECT you are not in my local networks
80.80.80.80 REJECT you are not in my local networks
dc.DOM OK broken M$ Widnows server

последняя строка иллюстрирует пример "продвинутого" респондента, чей компьютер выдает бесмысленное приветствие helo, а почту от такого респондента все равно принимать надо.

файл /etc/postfix/dul_checks:

/81-177-70-6\.donnetwork\.ru/i             OK 81-177-70-6.donnetwork.ru (@aaanet.ru)
/([0-9]*-){3}[0-9]*(\..*){2,}/i            553 SPAM_ip-add-rr-ess_networks
/([0-9]*\.){4}(.*\.){3,}.*/i               553 SPAM_ip-add-rr-ess_networks
/.*\..*\...\.comcast\.net/i                553 SPAM_comcast-net
/.*yahoobb.*\.bbtec\.net/i                 553 SPAM_yahoobb_bbtec-net
/[0-9]{12}\.bbtec\.net/i                   553 SPAM_host_bbtec-net
/.*\.broadband\.hu/i                       553 SPAM_broadband-hu
/client.*\..*\..*/i                        553 SPAM_CLIENT
/cable.*\..*\..*/i                         553 SPAM_CABLE
/pool.*\..*\..*/i                          553 SPAM_POOL
/dial.*\..*\..*/i                          553 SPAM_DIAL
/ppp.*\..*\..*/i                           553 SPAM_PPP
/dslam.*\..*\..*/i                         553 SPAM_DSLAM
/dhcp.*\..*\..*/i                          553 SPAM_DHCP
/adsl\.r61\.net/i                          OK adsl.r61.net
/adsl\.infotecstt\.ru/i                    OK adsl.infotecstt.ru
/[\.-]dsl.*\..*\..*/i                      553 SPAM_DSL
/[ax]dsl.*\..*\..*/i                       553 SPAM_XDSL
/.*([0-9]*\.){4}cableonline\.com\.mx/i     553 SPAM_IP-cableonline-com-mx
/.*\.([0-9]*\.){4}ip\.holtonks\.net/i      553 SPAM_ip-holtonks-net
/([0-9]*-){3}[0-9]*\.fibertel\.com\.ar/i   553 SPAM_IP-fibertel-com-ar
/.*[0-9]*-[0-9]*\.fibertel\.com\.ar/i      553 SPAM_IP-fibertel-com-ar
/[0-9]*\.user\.veloxzone\.com\.br/i        553 SPAM_user-veloxzone-com-br
/[0-9]*\.customer\.alfanett\.no/i          553 SPAM_customer-alfanett-no
/.*([0-9]*-){3}[0-9]*\.telecom\.net\.ar/i  553 SPAM_host-telecom-net-ar
/.*(-[0-9]*){2}\.telpol\.net\.pl/i         553 SPAM_host-telpol-net-pl
/(.*\.){2}maxonline\.com\.sg/i             553 SPAM_host-maxonline-com-sg
/(.*-){2}.*\.fairgamemail\.us/i            553 SPAM_host-fairgamemail-us
/[0-9]*[0-9]*-\.wispnet\.net/i             553 SPAM_host-wispnet-net
/.*-.*(\..*){2}\.ne\.jp/i                  553 SPAM_host-ne-jp
/[0-9]*\..*\.ne\.jp/i                      553 SPAM_h09t-ne-jp
/(.*\.){3}ad\.jp/i                         553 SPAM_host-ad-jp
/(.*\.){4}revip\.asianet\.co\.th/i         553 SPAM_revip-asianet-co-th
/[0-9]*\..*\.virtua\.com\.br/i             553 SPAM_host-virtua-com-br
/([0-9]*-){3}[0-9]*\.exatt\.net/i          553 SPAM_host-exatt-net
/([0-9]*\.){4}ip\.alltel\.net/i            553 SPAM_host-ip-alltel-net
/[0-9]{6,}\.chello\.../i                   553 SPAM_host-chello
/.*[0-9]*\..*\.chello\.../i                553 SPAM_host-chello-xx
/.*\..*\.t-dialin\.net/i                   553 SPAM_t-dialin-net
/.*\..*\.t-ipconnect\.de/i                 553 SPAM_t-ipconnect-de
/([0-9]*-){2,3}[0-9]*\..*\.cgocable\.net/i 553 SPAM_host-cgocable-net
/.*\..*\.shawcable\.net/i                  553 SPAM_host-shawcable-net
/p[0-9]*\.mp[0-9]*\.aaanet\.ru/i           553 SPAM_aaa_modem_pool
/([0-9]*-){2}[0-9]*\.ip\.adsl\.hu/i        553 SPAM_ip-adsl-hu
/([0-9]{1,3}\.){2}broadband4\.iol\.cz/i    553 SPAM_broadband-iol-cz
/.*\.yandex\.ru/i                          OK yandex.ru
первая строка - исключение, с тем же успехом этот адрес можно было внести в /etc/postfix/client_access

файл /etc/postfix/sender_access:

/.*@friends\.ru/i OK
/.*evil\.org/i REJECT

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

файл /etc/postfix/recipient_access:

/.*@friends\.ru/i OK
/.*evil\.org/i REJECT

разрешаем или запрещаем отправку писем на эти адреса

файл /etc/postfix/helo_regexp:

/([0-9]{1,3}(\.|-)){3}[0-9]{1,3}/i      REJECT IP-able helo SPAM

запрещаем ИП-адрес в качестве HELO. Это явное нарушение RFC, но практика показала, что это работает без сбоев.

после создания файлов helo_access, client_access и dul_checks необходимо выполнить

server# postmap helo_access
server# postmap client_access
server# postfix check

и если все прошло без ругани, то

server# postfix reload

и можно смотреть лог-файл на предмет ошибок и наличие ошибочных срабатываний (if ever any :) ). Для удобства можно grep'ить по ключевому слову SPAM

server# tail -f /var/log/maillog | grep SPAM

В моем примере я несколько дней изучал журналы /var/log/mail.log на предмет ложных срабатываний, и еще в течение нескольких месяцев наблюдал за всем отсеянным по dul_cheсks письмам, и не обнаружил ни одного случая блокировки нормальной почты по вине нашего сервера.

Следует отметить, что встречались очень искусные попытки мимикрии под реальные емайл-адреса, которые тем не менее легко проверялись с помощью whois-запросов.

После настроек периодически всплывали "продвинутые" респонденты, которые отсылали письма с адресов, не имеющих ДНС-имен или с некорректным HELO. Для них всех были добавлены записи в "белые списки", что также решило проблему.

Как показал опыт, DNSBL-проверки отсекают примерно 40% спама в процессе приема заголовков, еще 30% отсекается с помощью dul_checks, и на этом экономится трафик не принятых тел писем спамов (примерно 20-50 kb на каждой попытке, а их может быть примерно 30-50 тыс в неделю).

Удивительное рядом, но на проверках HELO/EHLO отсекается большинство хитрых спаммеров, которые пытаются замаскироваться под приличный сервер(10% от общего числа писем).

Это особенно актуально в связи с тем, что динамически выделяемые IP-адреса технически не очень эффективно попадают в DNSBL-списки, так как часто к моменту проверки на open-relay′ность некоторого адреса на нем уже "сидит" совершенно другой комп. Зато по обратным доменным именам такие адреса легко распознаются :), и это не зависит от спаммеров, а только от ISP.

Однако, оказалось неэффективным требовать обязательного разрешение ИП-адрес отправителя в ДНС. Хотя это тоже режет спам, часто попадаются сервера небольших фирм, чьи ISP поленились расписать раздаваемые для подключений ИП-адреса в DNS. От опции reject_unknown_client пришлось отказаться совсем.

Приведенные настройки обеспечили эффективную фильтрацию спама, уменьшив его кол-во на порядок (с 300-500 спамов в сутки до 10-15 на один ящик электронной почты).

Для сервера с 30 почтовыми ящиками (примерно 5 тыс принятых и 10 тыс отклоненных писем в неделю) кумулятивная экономия трафика составляет примерно 300 мб в неделю, или около полутора гигабайт в месяц.

Стоит отметить, что вместе с "закручиванию гаек" для проверок на этапе SMTP-соединений осуществлялись offline-меры по борьбе со спамом. Среди них анализ тенденций по журналу mail.log и отсылка spam-report'ов на www.spamcop.net

"Спам - явление социальное, и только объединившись и действуя сообща, мы сможем его победить" (Кто-то из великих)

Буду признателен за любую критику и статистику эффективности, на sergey @ rsu точка ru Автор: Сергей Литвиненко (sergey@reclamy.net)