Jump to content

Recommended Posts

Умеет-ли последняя версия Mail Gateway устраивать ловушки для спама?

И где можно взять полную триальную версию "на попробовать"?

 

Спасибо за внимание.

Share this post


Link to post
Умеет-ли последняя версия Mail Gateway устраивать ловушки для спама?

И где можно взять полную триальную версию "на попробовать"?

 

Спасибо за внимание.

Возможности приложения - http://support.kaspersky.ru/mail_gw5.6/common?qid=208635942.

Триалка - http://www.kaspersky.ru/kaspersky_security_mail_server_trial.

 

Share this post


Link to post

А там написано "организовывать "белые" и "черные" списки адресатов, применяемые при обработке почтового трафика;"

Вот я и спрашиваю, может-ли шлюз автоматически создавать эти "черные" списки с помощью спам-ловушек?

Я и мануал читал, не просветило ... ;-)

 

Еще вопрос. В мануале сказано:

2.2. Схема работы приложения

Предусмотрен следующий алгоритм работы приложения (см. рис. 2):

1. Почтовый трафик поступает почтовому агенту по SMTP-протоколу. Почтовая система передает всю поступившую почту модулю Receiver.

Получается, что шлюз будет принимать ВСЮ почту? И только потом с ней разбираться?

 

 

За триалку спасибо, что-то я тормознул с ней.

Но в свете вышеизложенного, наверно она мне не понадобиться. :(

Share this post


Link to post
А там написано "организовывать "белые" и "черные" списки адресатов, применяемые при обработке почтового трафика;"

Вот я и спрашиваю, может-ли шлюз автоматически создавать эти "черные" списки с помощью спам-ловушек?

Я и мануал читал, не просветило ... ;-)

 

Еще вопрос. В мануале сказано:

 

Получается, что шлюз будет принимать ВСЮ почту? И только потом с ней разбираться?

За триалку спасибо, что-то я тормознул с ней.

Но в свете вышеизложенного, наверно она мне не понадобиться. :(

если вы настроите ConnectRule и HeloRule то не всю почту

читайте мануал

Share this post


Link to post

Хмм...

Может стОит переписать мануал? Я понимаю, что в мире *nix ответ "RTFM" - это святое, тем не менее.

Я его прочитал несколько раз. Разные части его противоречат друг-другу.

 

Ну ладно, может я тупой, всякое бывает.

Ответьте пожалуйста, спам-ловушки можно организовать?

Edited by Colonel

Share this post


Link to post

Я конечно жутко извиняюсь, но кто-нибудь сможет ответить на поставленный выше вопрос?

Share this post


Link to post

1) Настройкой *Rule обеспечивается прием для существующих адресатов - пример есть в документации, очевидно что по-дефолту принимается все по причине разных методов хранения пользователей

2) Что вы подразумеваете по словом "спамтрап", есть как минимум 2 варианта

- прием сообщений на заранее раскиданные почтовые адреса с целью дальнейшего анализа приходящего на них спама

- автоматический блэклист всех IP адресов шлющих на эти mail адреса

Share this post


Link to post
Ответьте пожалуйста, спам-ловушки можно организовать?

 

Можно.

 

Опишите плз поподробнее, что вы понимаете под спам-ловушкой, может мы говорим о разных вещах...

 

Share this post


Link to post

Извиняюсь за долгое молчание - проблемы с электропитанием :ireful3:

Еще раз перечитал мануал:

- упоминаний про спам-ловушки нет

- шлюз не проверяет существование почтовго ящика на сервере, а ориентируется на конфигурационный файл и списки.

 

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

Я правильно понял?

 

Что я понимаю под спам-ловушкой.

Это - "автоматический блэклист всех IP адресов шлющих на эти mail адреса"

Пример. Почтовый сервер - Коммунигейт. Всевозможные проверки включены - и по DNS, и по Helo, и RBL, и т.д.

Тем не менее спамеры регулярно пытаются пропихнуть письма на адреса вида buhgalter@****.ru, manager@****.ru и т.д. (свой домен я забил звездочками). Таких ящииков у меня нет и не было.

Сервер конечно дает им отлуп, но они пытаются снова и снова.

Я занес эти адреса в в список спам-ловушек, количество спама резко сократилось.

 

Share this post


Link to post
Извиняюсь за долгое молчание - проблемы с электропитанием :ireful3:

Еще раз перечитал мануал:

- упоминаний про спам-ловушки нет

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

И еще - потому что под спам-ловушкой можно понимать совсем разное. Даже вы понимаете совсем иное (см. ниже).

 

- шлюз не проверяет существование почтовго ящика на сервере, а ориентируется на конфигурационный файл и списки.

Да, шлюз он на то и шлюз, что ничего не знает о том, что в конфигурации у стоящего за ним почтового сервера организации, который заведует ящиками и осуществляет в них финальную доставку письма. На шлюзе никаких ящиков нет. Но - он *может* знать об адресах в ваших доменах, если ему об этом сказать (правильно - в конфигурационном файле).

 

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

Я правильно понял?

Не совсем. Переносить адреса "вручную" не обязательно. Это вполне может делать скрипт. Который подходящим для вашей организации образом получает список адресов (из AD ли, из конфига postfix'а или какого-то imap-сервера, еще как то - все зависит от того, каким образом вы ведете список адресатов в организации), и подставляет его в конфигурационный файл mailgw для настройки правил allow/deny. У вас тут - полная свобода выбора того, как вы этот список получаете на хосте с работающим mailgw и по какой политике вы его обновляете (запуском явно такой синхронизации при добавлении\удалении адресата либо периодически в определенное время в cron) - запретов тут никаких нет.

 

Более того, для упрощения формирования такого списка, тут очень удобно использовать конструкцию "file:", а именно - записываем в конфиге

 

[mailgw.access]

RelayRule=allow for any to file:path/my-recipients.list

RelayRule=deny for any to *

 

и достаточно формировать список "своих", "существующих", "разрешенных" адресатов в отдельном файле

path/my-recipients.list формата "один адрес на одной строке" этим вашим скриптом из произвольного источника данных. И все. Это описано в приложении B.2

 

Что я понимаю под спам-ловушкой.

Это - "автоматический блэклист всех IP адресов шлющих на эти mail адреса"

Пример. Почтовый сервер - Коммунигейт. Всевозможные проверки включены - и по DNS, и по Helo, и RBL, и т.д.

Тем не менее спамеры регулярно пытаются пропихнуть письма на адреса вида buhgalter@****.ru, manager@****.ru и т.д. (свой домен я забил звездочками). Таких ящииков у меня нет и не было.

Сервер конечно дает им отлуп, но они пытаются снова и снова.

Я занес эти адреса в в список спам-ловушек, количество спама резко сократилось.

 

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

 

А то, что вы дальше описали - просто список blacklisted-адресов получателей и делается просто в том же правиле RelayRule и такой же конструкцией "file:"

Просто запишите, например

 

[mailgw.access]

...

RelayRule=deny for any to file:path/denied-recipients.list

...

 

и записывайте в файл path/denied-recipients.list адреса (и маски), прием почты для которых вы хотите исключить.

(Осторожно с пустыми строками - см. предупреждение в мануале при описании конструкции "file:")

 

 

Т.е., когда мы разобрались, что именно вы понимаете под спам-ловушкой, получается что у вас есть 2 варианта организации контроля приема почты по адресам получателей:

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

--- либо allow на свой домен, плюс deny для адресов из списка "плохих" (в вашей терминологии - спам-ловушек), плюс deny остальным. Список плохих - формируйте как угодно.

 

Все, что описано выше с использованием конструкции "file:" можно сделать и без нее - но тогда списки будут не в отдельном файле, а в основном конфигурационном файле, что менее удобно для модификации больших списков.

 

Да - после изменения конфигурации (в частности списков в отдельных файлах используемых при помощи конструкции "file:") необходим релоад приложения с тем, чтобы он подобрал новую конфигурацию (релоад отличается несколько от рестарта).

 

Share this post


Link to post

На счёт изменения списков с помощью скриптов я и сам думал. Это вполне реально.

Но почему не сделать более прозрачно:

telnet 192.168.2.2 25

220 fmt.mydomen.ru ESMTP MDaemon 9.6.5; Fri, 04 Jul 2008 16:22:48 +0400

ehlo boss

250-fmt.mydomen.ru Hello boss, pleased to meet you

250-VRFY

250-EXPN

250-ETRN

250-AUTH=LOGIN

250-AUTH LOGIN CRAM-MD5

250-8BITMIME

250-STARTTLS

250 SIZE 0

mail from:colonel@fmt.mydomen.ru

250 <colonel@fmt.mydomen.ru>, Sender ok

rcpt to:admin@fmt.mydomen.ru

550 <admin@fmt.mydomen.ru>, Recipient unknown

quit

221 See ya in cyberspace

telnet 192.168.1.2 25

220 mydomen.ru ESMTP CommuniGate Pro 4.3.7 is glad to see you!

ehlo fmt

250-mydomen.ru we trust you fmt

250-DSN

250-SIZE

250-STARTTLS

250-AUTH=MSN

250-AUTH=LOGIN

250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 MSN

250-ETRN

250-TURN

250-ATRN

250-NO-SOLICITING

250-HELP

250-PIPELINING

250 EHLO

mail from:colonel@mydomen.ru

250 colonel@mydomen.ru sender accepted

rcpt to:coloneltest

250 coloneltest will leave the Internet

rcpt to:admin

550 admin unknown user account

quit

221 mydomen.ru CommuniGate Pro SMTP closing connection

или (если сервер поддерживает)

220 fmt.mydomen.ru ESMTP MDaemon 9.6.5; Fri, 04 Jul 2008 16:26:46 +0400

VRFY colonel

250 Yeah, I know that one. He (or she) is Кочетов Михаил Владимирович <colonel@fmt.mydomen.ru>.

VRFY admin

550 <admin@fmt.mydomen.ru>? Never heard of 'em

 

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

Я может бестолково и не полностью написал (не писатель чукча, не писатель...):

Я занес эти адреса в в список спам-ловушек, количество спама резко сократилось.

Надо было продолжить - "После этого Коммунигейт автоматически заносит в блэклист все IP адреса шлющих на эти mail адреса"

Пэтому утверждение

Т.е., когда мы разобрались, что именно вы понимаете под спам-ловушкой
неверно.

Вот что происходит после добавления в файл конфигруации роутера строчки <sale@mydomen.ru> = spamtrap

17:46:21.41 4 SMTPI-07667([190.210.15.177]) cmd: RCPT TO: <sale@mydomen.ru>

17:46:21.41 1 SMTPI-07667([190.210.15.177]) a message from [190.210.15.177] addresses the spamtrap 'sale@nsma.ru'

17:46:21.41 4 SMTPI-07667([190.210.15.177]) rsp: 250 sale@mydomen.ru accepted

17:46:21.41 4 SMTPI-07667([190.210.15.177]) cmd: DATA

17:46:23.41 4 SMTPI-07667([190.210.15.177]) rsp: 597 we have a reason to believe this message is unwanted here

17:46:23.73 3 SMTPI-07667([190.210.15.177]) read failed. Error Code=connection closed by peer

17:46:23.73 4 SMTPI-07667([190.210.15.177]) closing connection

17:46:23.73 4 SMTPI-07667([190.210.15.177]) releasing stream

Edited by Colonel

Share this post


Link to post
rcpt to:admin@fmt.mydomen.ru

550 <admin@fmt.mydomen.ru>, Recipient unknown

 

именно это и произойдет при настройке

[mailgw.access]

...

RelayRule=deny for any to file:path/denied-recipients.list

 

VRFY colonel

250 Yeah, I know that one. He (or she) is Кочетов Михаил Владимирович <colonel@fmt.mydomen.ru>.

прямое нарушение стандарта 822/821

 

Надо было продолжить - "После этого Коммунигейт автоматически заносит в блэклист все IP адреса шлющих на эти mail адреса"

безсмысленный и вредный функционал, таким образом вы очень быстро занесете в блэклист все IP адреса крупных релеев, когда инфицированнай компьютер шлет через релей провайдера почту (это давно уже не новость), и занесете массу серверов которые используют sender verify/callout.

Share this post


Link to post

Курил RFC, много думал ...

именно это и произойдет при настройке

[mailgw.access]

...

RelayRule=deny for any to file:path/denied-recipients.list

При этом шлюз будет сверяться со списком. А почему бы ему не сверяться с защищаемым почтовым сервером?

прямое нарушение стандарта 822/821

Если можно - поясните, какие именно положения RFC при этом нарушаются?

безсмысленный и вредный функционал, таким образом вы очень быстро занесете в блэклист все IP адреса крупных релеев, когда инфицированнай компьютер шлет через релей провайдера почту (это давно уже не новость), и занесете массу серверов которые используют sender verify/callout.
Но ведь это проблема релея? С исходящим спамом должен бороться и MTA на передающей стороне, нет?

За несколько лет использования spamtrap было пару случаев, когда люди безвинно попадали в черные списки. Все это решалось либо телефонным звонком, либо (что более правильно), письмом на postmaster@mydomen.ru.

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

 

Share this post


Link to post
При этом шлюз будет сверяться со списком. А почему бы ему не сверяться с защищаемым почтовым сервером?

есть масса кривых серверов отвечающих как попало на rcpt to, пример - ваша сессия с VRFY

 

Если можно - поясните, какие именно положения RFC при этом нарушаются?

неенкоженные 8bit символы в командной smtp сессии.

 

Но ведь это проблема релея? С исходящим спамом должен бороться и MTA на передающей стороне, нет?

За несколько лет использования spamtrap было пару случаев, когда люди безвинно попадали в черные списки. Все это решалось либо телефонным звонком, либо (что более правильно), письмом на postmaster@mydomen.ru.

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

с таким подходом да, мне задача посмастера представляется как

1) минимизировать число ложных срабатываний

2) минимизировать ручную донастройку по каждому звонку

Share this post


Link to post

Про нарушение RFC - это Максим говорил про русские буквы, которых там быть не должно (не посути, тем самым, этой команды, а по синтаксису того, что вы написали). В Mail Gateway команда VRFY не поддерживается принципиально как потенциально опасная. Это дыра для спаммеров. Именно поэтому она не поддерживается на приеме почты, и не реализуется при отправке. Это, еще раз подчеркну - принципиальное решение.

 

"Почему бы Mail Gateway не сверяться с защищаемым почтовым сервером?" А посредством какого протокола он будет это делать? Через тот же VRFY следующему серверу? Так во-первых это дополнительные задержки, и плюс - архитектурно Mail Gateway устроен так что SMTP-приемщик и SMTP-сендер разрезаны очередью полностью, посему никаким образом при приеме нельзя потребовать от сендера отбратиться к следующему серверу с командой VRFY без существенного изменения архитектуры (чего для такой сомнительной ф-ции делать не будут). Остается - другие протоколы, LDAP, и проч. По сути же - это и есть формирование списков и вы это можете реализовать внешним скриптом и подсунуть список приложению.

 

Про Spam Traps, итого: CGPro реализует похожие на правду ящики-ловушки (Spam Traps). Про их вредность\полезность\сомнительность - могут быть разные мнения. Если вам это подходит как метод борьбы со спамом и вы не испытываете неудобств от излишне заблокированных адресов провайдеров - наверное для вас это действенный метод.

 

Так вот, CGPro реализует подобный функционал только потому, что в нем совмещены и финальная доставка и проверка и шлюзование. В Mail Gateway никаких ящиков (т.е. финальной доставки) нет. Соотв. нет и ничего в Mail Gateway подобного спам-ловушкам в понимании CGPro.

Можно было бы реализовать подобный функционал при помощи maildrop/procmail, сейчас этому мешает отсутствие в Mail Gateway поддержки команды XFORWARD - придется парсить заголовки Received для извлечения адресов клиентов-спаммеров.

 

"С исходящим спамом должен бороться и MTA на передающей стороне, нет?"

Нет - ибо там не добрый такой же админ, а злой спамо-бот.

Share this post


Link to post
есть масса кривых серверов отвечающих как попало на rcpt to, пример - ваша сессия с VRFY

неенкоженные 8bit символы в командной smtp сессии.

Ну, дык, это же MDaemon... Они там увлеклись русификацией, аж жуть берет ;-)

CommuniGate этим не страдает, просто у него VRFY заглушено, на все запросы - 252 (в полном соответствии с RFC 2821)

с таким подходом да, мне задача посмастера представляется как

1) минимизировать число ложных срабатываний

2) минимизировать ручную донастройку по каждому звонку

3) Экономить трафик и нервы пользователей.

В конце концов, Mail Gateway, после установки все равно требует доработки напильником. Почему-бы не предоставить администратору возможность выбора: использовать списки или обращение к защищаемому серверу, использовать ручные блэклисты или spamtrap?

 

2hinote

Слишком долго я думал над ответом, не заметил Ваше сообщение.

Насчёт списков - согласен.

 

Насчет ловушек. Я не программист и даже не полноценный сисадмин, так приблудный ;-) На мой взгляд, для реализации ловушек в MG все есть - определение исходящего IP почтовой сессии, правила RelayRule, черные списки. Осталось объединить... Вам конечно виднее, что можно и нужно.

Не буду утомлять Вас обоих своими фантазиями, возможности я уяснил, большое спасибо за терпение.

Edited by Colonel

Share this post


Link to post

×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.