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

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

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

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

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

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

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

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

Настройка 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)