дек 06, 16 | Ура, у нас новый сайт!

Подробнее…

ноя 01, 16 | График работы на ноябрьские праздники

Подробнее…

ноя 01, 16 | Новый график работы магазина. Теперь без выходных!

Подробнее…

сен 12, 16 | Старт продаж iPhone 7 и iPhone 7 Plus

Подробнее…

авг 29, 16 | Больше и Больше. Скидки при покупке аксессуаров.

Подробнее…

авг 26, 16 | Внимание! 27 августа магазин и технический отдел c 15:00 не работают

Подробнее…

авг 18, 16 | Внимание! 20 августа магазин и технический отдел не работают

Подробнее…

авг 15, 16 | Скидки для школьников и студентов

Подробнее…

июн 14, 16 | За хорошую учёбу.

Подробнее…

июн 09, 16 | График работы в праздничные дни июня

Подробнее…

Антиспам без оружия, или настройка Postfix в MacOS X [от гуру]

Опубликовал: Сергей Литвиненко / июл 29, 05 /
2 Комментария

Реклама: Наши новости - теперь и в Facebook!

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

Имеем: стандартную конфигурацию почтовой системы, поставляемой в составе Mac OS X Server: Postfix + SASL + CYRUS.

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

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

  • разрешена отправка писем с адресов внутренней сети
  • разрешен прием писем снаружи для адресатов внутри
  • прием писем только от существующих и корректных адресатов
  • прием писем только для имеющихся на сервере адресатов
  • для отправки писем FROM: *@mysite.ru с невнутренних хостов требовать обязательную авторизацию, без авторизации письма отклонять
Применяемые технические решения:
  • разрешать внутренним ип-адресам отправлять письма на несуществующие email-адреса (рассылка рекламного отдела)
  • проверять существование и корректность адреса отправителя
  • проверять существование и корректность адреса получателя
  • проверять корректность IP-адреса сервера передающего письм
  • проверять наличие IP-адреса отправителя в списках DNSBL
  • отклонять письма с IP-адресов, определяемых как динамические (dialup & adsl)
  • проверять заголовок письма на предмет наличия аттачя, содержащего файлы с неразрешенными типами расширений
  • для “особо продвинутых” респондентов применять “белые списки”

Настройки: файл /etc/postfix/main.cf: --- main.cf --- # список подсетей, которым разрешена отправка писем, и на # письма с которых многие проверки не распространяются. # здесь не должно быть подсетей, которые не являются “внешними” mynetworks = my.public.ip.address, 192.168.0.0/24, 10.0.14.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

# ограничения на приветствие отправителя smtpd_helo_restrictions =
# отсекаем кривые адреса reject_invalid_hostname,
# разрешаем “своим” почти все
permit_mynetworks, # “Белый Список” должен быть впереди остальных проверок # отсекаем приветствия отправителя от моего имени # а также прописываем разрешения для “продвинутых” check_helo_access hash:/etc/postfix/helo_access, # отсекаем почту с хостов (вида вроде news.intranet.), # не имеющих полноценного доменного # имени вида что-то.домен.домен_верхнего_уровня reject_non_fqdn_hostname, # требуем отправителя представиться доменным именем, # имеющим полноценный IP-адрес reject_unknown_hostname, # если все вышеперечисленное подошло, идем дальше permit

ограничения, проверяемые на этапе MAIL FROM:

smtpd_sender_restrictions =
# принимаем почту на отправку с “чужих” хостов, если пользователь # авторизовался по логину/паролю permit_sasl_authenticated, # “своим” можно и “просто” permit_mynetworks, # разрешаем или запрещаем “продвинутым” 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, # см комментарий к разделу smtpd_sender_restrictions
reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_sasl_authenticated, permit_mynetworks, # запрещаем или разрешаем “продвинутым” regexp:/etc/postfix/recipient_access, # !!! !!! !!! !!! !!! # запрещаем прием и передачу писем, не относящихся к нам # без этой строчки сервер становится open-relay rejectunauthdestination, # !!! !!! !!! !!! !!! # если все вышеперечисленное подошло, идем дальше
permit

проверяем, а не является (по признакам ДНС-имен) ли

динамически-назначаемым IP-адрес хоста-отправителя (определяемого

по соединению, а не по приветствию или разрешенному ДНС/IP-адресу)

smtpdclientrestrictions =
# разрешаем “своим” почти все
permit_mynetworks, # прописываем адреса “продвинутых” в белом списке hash:/etc/postfix/client_access, # в файле dul_checks регулярные выражения доменных имен, # наиболее часто используемых для обратных зон блоков # динамически назначаемых адресов и # широкополосных клиентских подключений regexp:/etc/postfix/dul_checks, # проверяем IP-адрес отправителя по спискам DNSBL (www.ordb.org) rejectrblclient list.dsbl.org, rejectrblclient bl.spamcop.net, rejectrblclient cbl.abuseat.org, rejectrblclient psbl.surriel.com, rejectrblclient spamsources.fabel.dk, rejectrblclient opm.blitzed.org, rejectrblclient combined.njabl.org, rejectrblclient relays.ordb.org, rejectrblclient dul.ru, rejectrblclient dialup.balcklist.jippg.org, rejectrblclient relays.mail-abuse.org, rejectrblclient dnsbl.sorbs.net,

# требуем определяемого обратного ДНС-имени IP-адреса хоста-client
reject_unknown_client

запрещаем прием писем с вирями (по расширениям файлов) в атачах

headerchecks = regexp:/etc/postfix/headerchecks

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

bodychecks = regexp:/etc/postfix/bodychecks

--- / main.cf ---

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

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

/etc/postfix/helo_access: --- helo_access --- mysite.ru REJECT you are not in my local networks my.public.ip.address REJECT you are not in my local networks --- / helo_access --- последняя строка иллюстрирует пример “продвинутого” респондента, чей компьютер выдает бесмысленное приветствие helo, а почту от такого респондента принимать надо.

/etc/postfix/dul_checks: --- dul_checks --- /.dsl.....*/i 553 AUTO_DSL spam /[ax]dsl.....*/i 553 AUTO_XDSL spam /client.....*/i 553 AUTO_CLIENT spam /cable.....*/i 553 AUTO_CABLE spam /pool.....*/i 553 AUTO_POOL spam /dial.....*/i 553 AUTO_DIAL spam /ppp.....*/i 553 AUTO_PPP spam /dslam.....*/i 553 AUTO_DSLAM spam /node.....*/i 553 AUTO_NODE spam /dhcp.....*/i 553 AUTO_DHCP spam --- / dul_checks ---

/etc/postfix/sender_access: --- sender_access --- /.*@aaanet.ru/i OK /.@.tele2.../i REJECT --- / sender_access --- здесь задаем маски адресов, от кого мы хотим получать корреспонденцию несмотря на то, что домены этих адресов могут быть неопределены. Нижняя строчка также иллюстрирует блокировку распространненного спама, якобы от пользователей Tele2.

/etc/postfix/recipient_access: --- recipient_access --- /.*@aaanet.ru/i OK --- / recipient_access --- разрешаем отправку писем на эти адреса

/etc/postfix/header_checks: --- header_checks --- /^content-(type|disposition):.name[[:space:]]=.*.(dll|vbs|pif|com|bat|scr|lnk)/ REJECT Prohibited attachement file name extension: $2 --- / header_checks --- конечно, вирь может прийти в виде файла с расширением EXE или ZIP, но это могут быть и нормальные файлы

/etc/postfix/body_checks: --- body_checks --- /^ < iframe src=(3D)?cid:.* height=(3D)?0 width=(3D)?0>$/ REJECT IFRAME vulnerability exploit --- / body_checks ---

после создания файлов heloaccess, clientaccess и dul_checks необходимо выполнить server# postmap helo_access server# postmap client_access server# postmap dul_checks server# postfix check и если все прошло без ругани, то server# postfix reload и можно смотреть лог-файл на предмет ошибок и наличие ошибочных срабатываний (if ever any :) ).

В моем примере я несколько дней изучал журналы /var/log/mail.log на предмет ложных срабатываний, и не обнаружил ни одного случая блокировки нормальной почты по вине нашего сервера (один из респондентов пытался отправлять письма с просроченного домена, записи о котором оставались в whois и были убраны из DNS). Следует отметить, что встречались очень искусные попытки мимикрии под реальные емайл-адреса, которые тем не менее легко проверялись с помощью whois-запросов.

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

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

Удивительное рядом, но на проверках HELO/EHLO отсекается большинство хитрых спаммеров, которые пытаются замаскироваться под приличный сервер(10% от общего числа писем). А на проверках по выражениям dul_checks вместе с требованием существования и корректности обратного ДНС-имени хоста-отправителя эффективно отсекаются хосты-зомби с динамическими адресами.

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

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

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

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

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

Теги: macosx и статьи
Комментарии
Сообщение Автор Дата

Использовал эти настройки, всё нормально работает. Спама стало значительно меньше, но есть вопрос. У нас один клиент хочет получать всю почту без какой либо фильтрации - как это реализовать?

varlog янв 18, 06 14:28

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

Идея в том, чтобы все настройки из client_restrictions, helo_restrictions, sender_restictions с некоторым изменением синтаксиса перед списками доступа перенести в recipient_restrictions, а в ACL recipient_acces s добавить строку вида <адрес настырного любителя спама> OK

должно сработать, но проверить сейчас не могу.

isl янв 21, 06 14:46
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.