Украинская Баннерная Сеть

Аренда сервера. Выделенные серверы в Украине и Нидерландах
Аренда сервера

VPS, VDS, Windows VPS - от $10
VPS
Как не превратить свой почтовый сервер в рассадник спама

В последнее время приходится наблюдать определенное увеличение числа спама, рассылаемого при помощи вредоносного ПО через почтовые сервера провайдеров и организаций. В этом случае сами провайдеры и организации, чьи сервера используются для рассылки, страдают в гораздо большей мере, чем получатели спама. Чем чревата рассылка спама через Ваш почтовый сервер и как с этим бороться? Обо всем по порядку.

Когда раньше зомби машины рассылали письма напрямую, то с ними было относительно легко бороться. Часть из них не имела обратной записи и отфильтровывалась на проверках ip, часть на грейлистинге, часть на других фильтрах. Сейчас вредоносное ПО умнеет и в некоторых случаях зомби машины рассылают сообщения через почтовые сервера, которые указаны в настройках почтовых клиентов (Outlook, The Bat! и т.д.). Поскольку почтовый сервер имеет очередь сообщений, корректные DNS записи и т.д. – это позволяет спам сообщению проходить грейлистинг и многие другие фильтры, что доставляет лишних хлопот получателям таким сообщений. Но несоизмеримо больше хлопот такой спам доставляет тем администраторам, через чьи сервера он рассылается.

Как правило у провайдеров и организаций почтовые сервера настроены таким образом, что сообщение от компьютеров из внутренних подсетей принимаются к отправке без всяких ограничений и любой компьютер из внутренней подсети, если будет заражен вредоносным ПО, сможет осуществить спам рассылку через почтовый сервер. Результатом такой спам рассылки будет рост очереди почтовых сообщений, вплоть до десятков тысяч и более писем. Сервер будет заниматься рассылкой десятков и сотен тысяч писем спама в то время как легитимная корреспонденция будет ожидать своей очереди. Таким образом одна единственная рассылка может парализовать нормальное хождение почты на срок от нескольких часов и более в зависимости от объема рассылки. Как же с этим бороться?

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

Поясню на примере postfix’а. Я не буду объяснять как настроить postfix с поддержкой виртуальных пользователей и авторизации, вместо этого я буду полагать, что Вы уже имеете postfix настроенный таким образом. Так вот, если перед рестрикшном “permit_sasl_authenticated” добавить рестрикшн “reject_authenticated_sender_login_mismatch”, чтобы они выглядели примерно так:

...
reject_authenticated_sender_login_mismatch,
permit_sasl_authenticated,
...

то будет следующая картина: если пользователь авторизуется как [email protected] и попытается передать письмо в котором в качестве обратного адреса указан [email protected], то в ответ получит ошибку:

5.7.1 <[email protected]> Sender address rejected: not owned by user [email protected]

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

Фильтруем спам правильно. С примерами для postfix.

Содержание:


Структура SMTP сессии

Перед тем как заняться фильтрацией спама нужно четко представлять себе как происходит взаимодействие почтовых серверов при передаче писем. Когда один почтовый сервер пытается передать другому письмо, то между ними всегда происходит диалог, который можно наглядно продемонстрировать. Для того, чтобы продемонстрировать этот диалог воспользуемся утилитой telnet на нашем сервере и попробуем при ее помощи отправить почтовое сообщение на ящик [email protected] от имени [email protected]:

# telnet examplereceiver.com 25
Connected to examplereceiver.com.
Escape character is ‘^]’.
220 examplereceiver.com ESMTP
helo examplesender.com
250 examplereceiver ready to serve
mail from:[email protected]
250 OK
rcpt to:[email protected]
250 OK
data
354 Go ahead
Hello world!
.
250 OK id=1Lu83v-0002nd-Su

Строки выделенные красным – это команды, которые мы посылаем серверу examplereceiver.com, строки выделеныне зеленым – это ответы сервера examplereceiver.com на наши команды. Давайте подробнее разберем что мы передаем и что получаем в ходе SMTP сессии.

Подробнее »

Почему я не использую DNSBL. В помощь начинающему постмастеру

Вы системный-администратор компании и перед Вами стоит задача настроить почтовый сервер для компании так, чтобы спама было как можно меньше. Первым делом Вы идете на google и ищете способы решения проблемы спама. Гугл Вам вываливает кучу ссылок на статьи на различных сайтах. Вы переходите по ссылкам и начинаете читать. Готов спорить на что-то не очень ценное, что в первой же статье одним из решений будет использование DNS Blacklists. И Вы, зачарованный словосочетанием blacklist, в надежде на то, что коллективный разум постмастеров планеты уже знает обо всех спамерах, полагаете, что Вам остается только воспользоваться результатами их работы и тут же добавляете в конфиг своего MTA десяток-другой блеклистов. И, казалось бы, вот он счастье… но не тут-то было. Пользователи начинают регулярно жаловаться на недошедшие к ним письма. Вы, конечно же, первым делом спрашиваете от кого было письмо, затем смотрите в логи и гордо сообщаете пользователю: “Ваш отправитель попал в черный список, ничего поделать не могу, проблема на их стороне”. С Вас взятки гладки, поскольку это ведь не Вы, а отправитель попал в черный список, но тем не менее вопрос недоставки честных писем остается не решенным.

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

Подробнее »


Украинская Баннерная Сеть
Hosting Catalog Rambler's Top100