Защита почтового шлюза от спама

DVS · Сообщение **DVS** » 27 янв 2006, 17:56

Здравствуйте!
Ситуация следующая. Собираюсь строить почтовый шлюз на базе Sendmail+clamav+spamassassin+spamas-milter.
Почитав темы на этом форуме, я так и не понял будет ли экономия почтового трафика при использовании этой связки?
Слышал, что спамеров желательно давить на этапе RCPT TO, тогда выходит реальная экономия трафика. Все что просачивается сквозь эти правила уже далее обрабатывается clamav+spamassassin.
Тогда получается, что эти правила надо настраивать на Sendmail. Или Spamassassin тоже сможет помочь?
Собрать Sendmail с поддержкой regexp я смогу. А вот что дальше?
Какие FEATURE или define надо прописать в sendmail.mc? Какие рег. выражения и куда?
Думал защитить свой шлюз от спама, идущего на несуществующие адреса моих доменов, но шлюз не хранит имен пользователей, да и много их.
Хотелось бы еще защитить от dial-up и dsl хостов типа <ip-address>-dsl.com.
Проверку по MX делать не хочу, т.к. сам был в такой ситуации, когда не мог сделать обратную зону для своей маленькой подсетки.
Подскажите, пожалуйста, как реализовать такую защиту?

Сообщение **corvax** » 27 янв 2006, 22:51

DVS писал(а):Здравствуйте!
Ситуация следующая. Собираюсь строить почтовый шлюз на базе Sendmail+clamav+spamassassin+spamas-milter.
Почитав темы на этом форуме, я так и не понял будет ли экономия почтового трафика при использовании этой связки?

экономия трафика может быть при фильтрации по HELO/EHLO, A/PTR записи рилея отпраителя, envelope from и их комбинациям

при использовании spamassassin экономии трафика быть не может

DVS писал(а):Слышал, что спамеров желательно давить на этапе RCPT TO, тогда выходит реальная экономия трафика. Все что просачивается сквозь эти правила уже далее обрабатывается clamav+spamassassin.

причем тут clamav? или просто речь идет о том, что clamav получает письмо только после полного его приема?

DVS писал(а):Тогда получается, что эти правила надо настраивать на Sendmail.

да

DVS писал(а):Или Spamassassin тоже сможет помочь?

с помощью spamassassin траффик можно только одним способом - вносить в access_db рилеи, с которых за определенный период времени пришло определенное кол-во писем, распознанных spamassassin'ом как спам. но готового решения такого нет ни в sendmail, ни в spamassassin. его придется реализовать самостоятельно

DVS писал(а):Собрать Sendmail с поддержкой regexp я смогу. А вот что дальше?
Какие FEATURE или define надо прописать в sendmail.mc? Какие рег. выражения и куда?
Думал защитить свой шлюз от спама, идущего на несуществующие адреса моих доменов, но шлюз не хранит имен пользователей, да и много их.

можно поставить последнюю из бесплатных реализаций milter-ahead

кстати, если sendmail будет шлюзом перед чем? он просто будет frontend'ом перед каким-нить ms exchange или lotus domino?

DVS писал(а):Хотелось бы еще защитить от dial-up и dsl хостов типа <ip-address>-dsl.com.

вот для этого вам регулярные выражения и понадобятся

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

а причем тут "проверка по MX" к обратной зоне?

DVS писал(а):Подскажите, пожалуйста, как реализовать такую защиту?

какую? пока из конкретных вопросов тут я видел вопрос по регулярным выражениям, PTR записям dsl'ных клиентов и проверке получателей на bext MX'ах

на третий вопрос я ответил
первые два вопроса связаны
можно по ним посмотреть на такой вот hack:
http://mta.org.ua/sendmail/m4-releases/ ... p_regex.m4
он потребует еще несколько из того же каталога

либо надо самому почитать доку на счет regex и написать свой ruleset

Сообщение **corvax** » 28 янв 2006, 12:35

Spam Filtering for Mail Exchangers
How to reject junk mail in incoming SMTP transactions.
Tor Slettnes tor@slett.net
Edited by Joost De Cock, Devdas Bhagat, Tom Wright
http://slett.net/spam-filtering-for-mx/
http://www.tldp.org/HOWTO/Spam-Filtering-for-MX/

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

DVS · Сообщение **DVS** » 30 янв 2006, 10:04

Спасибо, Corvax, за советы.
Шлюз будет стоять перед qmail, который реализует доступ клиентов по POP3 к своим ящикам, является для внутренних пользователей SMTP-сервером, а также пересылку для некоторой группы пользователей почты на Exchange (он сейчас пока в тестовом режиме).
Кстати, пользовательские пароли для доступа к почтовым ящикам будут храниться в БД MySQL. Мне кажется, при таком раскладе все таки есть возможность для шлюза проверять существование получателей.
Буду разбираться с hack'ами и штудировать regexp в sendmail.

экономия трафика может быть при фильтрации по HELO/EHLO, A/PTR записи рилея отпраителя, envelope from и их комбинациям

Первый пункт мне понятен, по второму есть сомнения в применении, т.к. читал дискуссии по проверке A/PTR-записей рилея отправителя. К сожалению сам был в ситуации, когда для своего почтаря не мог прописать PTR-запись. И это было не потому, что я не знал зачем она нужна. Уже прекрасно понимал ее необходимость, просто не все зависило от меня в этой ситуации. Поэтому понимаю админов, у которых схожие обстоятельства.
А по третьему пункту есть вопрос. Envelope from - имеется в виду проверка обратного адреса?

Сообщение **Stranger03** » 30 янв 2006, 10:15

DVS писал(а):Спасибо, Corvax, за советы.
Шлюз будет стоять перед qmail, который реализует доступ клиентов по POP3 к своим ящикам, является для внутренних пользователей

Не совсем понял, речь все-таки идет о сендмыле или qmail? На том же sendmail я на шлюзе с помощью virtualusertable делал проверку существования пользователей до того, как они попадали на внутренний ексченж. Хоть небольшая экономия получалась.

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

Понимаете какая штука, по статистике примерно 30-40% почтовых серверов настроены либо некорректно, либо совсем не имеют обратных записей. Если вы у себя сделаете подобную проверку, то готовьтесь к тому, что 30-40% почты будет исчезать, пользователи будут кричать, мол не ходит нифига.
ИМХО, почтовик, ну кроме разве что проверки существования адреса получателя, должен принимать всю почту, а уж потом на основе своих правил принимать решение о доставке.

DVS · Сообщение **DVS** » 30 янв 2006, 10:34

Речь идет о Sendmail 8.13.5. У меня большое количество пользователей, которые регулярно добавляются/удаляются. Можно, конечно, внести их на шлюз, но тогда при добавлении/удалении новых пользователей необходимо будет делать правки еще и на шлюзе. Вот если бы тягать их из БД...
Согласен, что было бы правильным принимать всю почту, а уж потом ее фильтровать, но когда имеешь большой почтовый трафик, то много времени будет уходить на такую сортировку, проще основных самых известных вредителей давить при попытке.

Сообщение **corvax** » 30 янв 2006, 10:37

DVS писал(а):Спасибо, Corvax, за советы.
Шлюз будет стоять перед qmail,

sendmail как шлюз перед qmail?!?!
это более чем сильно!

DVS писал(а):который реализует доступ клиентов по POP3 к своим ящикам, является для внутренних пользователей SMTP-сервером, а также пересылку для некоторой группы пользователей почты на Exchange (он сейчас пока в тестовом режиме).

у вас еще и exchange есть?!
я еще понимаю корпоративную почту и groupware на exchange, а перед ним в качестве шлюза exim/sendmail (может быть postfix)
но ваша схема более чем удивительна своей избыточностью

DVS писал(а):Кстати, пользовательские пароли для доступа к почтовым ящикам будут храниться в БД MySQL. Мне кажется, при таком раскладе все таки есть возможность для шлюза проверять существование получателей.

если qmail сможет ответить 5xx при RCPT TO на несуществующего пользователя, то шлюзовому MTA совершенно все равно, где хранятся списки пользователей и паролей

DVS писал(а):Буду разбираться с hack'ами и штудировать regexp в sendmail.

экономия трафика может быть при фильтрации по HELO/EHLO, A/PTR записи рилея отпраителя, envelope from и их комбинациям
Первый пункт мне понятен, по второму есть сомнения в применении, т.к. читал дискуссии по проверке A/PTR-записей рилея отправителя. К сожалению сам был в ситуации, когда для своего почтаря не мог прописать PTR-запись.

речь не идет о проверке совпадения записей в прямой и реверсной зонах, речь идет о черных списках по A записям рилеев и сетям, в которые они входят, а также по PTR записям рилеев и доменным зонам, в которые они входят.

DVS писал(а): И это было не потому, что я не знал зачем она нужна. Уже прекрасно понимал ее необходимость, просто не все зависило от меня в этой ситуации.

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

DVS писал(а):Поэтому понимаю админов, у которых схожие обстоятельства.
А по третьему пункту есть вопрос. Envelope from - имеется в виду проверка обратного адреса?

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

Сообщение **corvax** » 30 янв 2006, 10:51

Stranger03 писал(а):
DVS писал(а):Спасибо, Corvax, за советы.
Шлюз будет стоять перед qmail, который реализует доступ клиентов по POP3 к своим ящикам, является для внутренних пользователей
Не совсем понял, речь все-таки идет о сендмыле или qmail? На том же sendmail я на шлюзе с помощью virtualusertable делал проверку существования пользователей до того, как они попадали на внутренний ексченж. Хоть небольшая экономия получалась.

получается, что приходилось периодически из AD выгружать список пользователей и формировать из него virtusertable?

у меня в свое время не получилось выполнять прямо из sendmail ldap запрос к AD, пришлось через map program запускать шелловый скрипт, который выполнял ldap запрос посредством ldapsearch, на основании ответа ldapsearch'а отвергал письмо или продолжал проверки. слабым местом оказалась лишь реализация обработки defer'ов. но это были уже чисто мои проблемы

Stranger03 писал(а):
читал дискуссии по проверке A/PTR-записей рилея отправителя. К сожалению сам был в ситуации, когда для своего почтаря не мог прописать PTR-запись.
Понимаете какая штука, по статистике примерно 30-40% почтовых серверов настроены либо некорректно, либо совсем не имеют обратных записей. Если вы у себя сделаете подобную проверку, то готовьтесь к тому, что 30-40% почты будет исчезать, пользователи будут кричать, мол не ходит нифига.
ИМХО, почтовик, ну кроме разве что проверки существования адреса получателя, должен принимать всю почту, а уж потом на основе своих правил принимать решение о доставке.

это жестковато таки... видимо, вам сыпется не так уж много совсем левого контента...

а на счет проверки наличия записи рилея в реверсной зоне или проверки соответствия записей в прямой и реверсной зонах - можно таких товарищей наказывать грейлистингом

Сообщение **corvax** » 30 янв 2006, 10:53

DVS писал(а):Речь идет о Sendmail 8.13.5. У меня большое количество пользователей, которые регулярно добавляются/удаляются. Можно, конечно, внести их на шлюз, но тогда при добавлении/удалении новых пользователей необходимо будет делать правки еще и на шлюзе. Вот если бы тягать их из БД...

milter-ahead - и вам будет все равно, где хранятся пользователи на backend'е

DVS писал(а):Согласен, что было бы правильным принимать всю почту,

ню-ню

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

DVS · Сообщение **DVS** » 30 янв 2006, 11:03

Не пинайте меня по поводу такой избыточности

. Это уже было так настроено до меня и старший админ уже привык так работать. Могу только догадываться почему qmail спрятали за Sendmail, возможно не смогли настроить антивирь под qmail, а может еще по какой-то причине. А Exchange появился недавно и пока находится в тестовом режиме. В дальнейшем пользователи нашей компании будут пользоваться Exchange, а арендаторы будут продолжать работать с ящиками на qmail.

если qmail сможет ответить 5xx при RCPT TO на несуществующего пользователя, то шлюзовому MTA совершенно все равно, где хранятся списки пользователей и паролей

Так письмо то уже будет принято шлюзом.

Попробую пока с хаками поработать, подборка на Вашем сайте, Corvax, на мой взгляд замечательная. Буду разбираться с ними. Спасибо!

Сообщение **corvax** » 30 янв 2006, 11:09

DVS писал(а):Не пинайте меня по поводу такой избыточности . Это уже было так настроено до меня и старший админ уже привык так работать. Могу только догадываться почему qmail спрятали за Sendmail, возможно не смогли настроить антивирь под qmail, а может еще по какой-то причине. А Exchange появился недавно и пока находится в тестовом режиме. В дальнейшем пользователи нашей компании будут пользоваться Exchange, а арендаторы будут продолжать работать с ящиками на qmail.

если qmail сможет ответить 5xx при RCPT TO на несуществующего пользователя, то шлюзовому MTA совершенно все равно, где хранятся списки пользователей и паролей
Так письмо то уже будет принято шлюзом.

нет

DVS писал(а):Попробую пока с хаками поработать, подборка на Вашем сайте, Corvax, на мой взгляд замечательная. Буду разбираться с ними. Спасибо!

велкам

но на самом деле под шлюз перед exchange легче заточить exim. у меня есть очень крупная инсталляция такая. exim может либо по smtp проверять у exchange наличие пользователя (как и sendmail), либо с помощью ldap запроса к AD

Сообщение **Stranger03** » 30 янв 2006, 15:50

corvax писал(а):получается, что приходилось периодически из AD выгружать список пользователей и формировать из него virtusertable?

Ну примерно так. Есть еще один вариант, авторизовать локальных юзеров через LDAP и для них же делать пересылку почты внутрь в домен. Но тогда мне проще было забить все в файл и не городить огород. Тем более что правка сего файла занимала 1-у минуту.

это жестковато таки... видимо, вам сыпется не так уж много совсем левого контента...

Жестковато что, принимать почту от всех? Я вам расскажу такую штуку, включил я эту пресловутую проверку обратной зоны. На следующий день некий юзер, директор департамента, говорит, мол с такой-то крутой конторы не ходит почта. Я проверять, ага, обратная зона идет лесом. Говорю мол не наша проблема, описал в чем. Ну и так далее. Причем на это можно было бы забить болт, но когда этих болтов до 100-ни топовых клиентов, ммм. Не говоря уже о десятках сотен или тысяч других...

а на счет проверки наличия записи рилея в реверсной зоне или проверки соответствия записей в прямой и реверсной зонах - можно таких товарищей наказывать грейлистингом

Всех не накажешь, админы ленивые по своей сути и часто даже не знают, что существует RFC.

Сообщение **Stranger03** » 30 янв 2006, 15:54

corvax писал(а):
DVS писал(а):Согласен, что было бы правильным принимать всю почту,
ню-ню

Что ню-ню? Пойдите объясните директору крупной госконторы, что мол ваш сервер не будет принимать от него почту по некоторым причинам, которые только вы сами понимаете. В лучшем случае вы, как исполнитель, будете посланы НА....

Но, да, все-таки ИМХО...

Сообщение **Stranger03** » 30 янв 2006, 15:56

corvax писал(а):но на самом деле под шлюз перед exchange легче заточить exim. у меня есть очень крупная инсталляция такая. exim может либо по smtp проверять у exchange наличие пользователя (как и sendmail), либо с помощью ldap запроса к AD

На опеннет есть ряд статей на тему авторизации с помощью ldap + winbind. А какой почтовик прикручивать - дело вкуса.

Сообщение **corvax** » 30 янв 2006, 16:03

Stranger03 писал(а):
corvax писал(а):получается, что приходилось периодически из AD выгружать список пользователей и формировать из него virtusertable?
Ну примерно так. Есть еще один вариант, авторизовать локальных юзеров через LDAP и для них же делать пересылку почты внутрь в домен. Но тогда мне проще было забить все в файл и не городить огород. Тем более что правка сего файла занимала 1-у минуту.

чисто моя точка зрения - делать все в режиме реального времени. я строил в качестве frontend для exchange и на базе sendmail и на базе exim. в обоих случаях мне показалось более удобным и надежным проверка пользователя ldap запросами в режиме реального времени

Stranger03 писал(а):
это жестковато таки... видимо, вам сыпется не так уж много совсем левого контента...
Жестковато что, принимать почту от всех? Я вам расскажу такую штуку, включил я эту пресловутую проверку обратной зоны.

тьфу... по приемом почты ото всех подразумевался прием почты без проверки записи рилея в реверсной зоне? тогда вопрос снимается

Stranger03 писал(а):На следующий день некий юзер, директор департамента, говорит, мол с такой-то крутой конторы не ходит почта. Я проверять, ага, обратная зона идет лесом. Говорю мол не наша проблема, описал в чем. Ну и так далее. Причем на это можно было бы забить болт, но когда этих болтов до 100-ни топовых клиентов, ммм. Не говоря уже о десятках сотен или тысяч других...

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

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

ну так и почта от них лениво ходить будет

есть одна дружественная контора. они с 20.11.2005 за 30 календарных дней получили 42 с небольшим тысячи вирей Worm.Sober.U (по классификации clamav'а). такое впечатление, что их (контору) кто-то заказал. так вот, поток червей уменьшился более чем в два раза после введения на их exim'е опционального грейлистинга и задержки почты с хостов с кривым реверсом. вот такие случаи бывают. кстати, в средине января поток червей иссяк так же неожиданно, как и появился

Защита почтового шлюза от спама

Защита почтового шлюза от спама

Re: Защита почтового шлюза от спама

Re: Защита почтового шлюза от спама

Кто сейчас на конференции