Спам в ВК или как ракскрутить хостинг без денег! Хостинг без спама

Неприступный почтовый сервер, или жизнь без спама / Хабр

Борьба со спамом — это головная боль всех ответственных администраторов почты. Чего только они не изобретают, чтобы любимым пользователям лучше жилось. Однако, как показала практика общения со многими системными администраторами, почему-то далеко не все представляют как правильно фильтровать спам.

Чаще всего встречается подход «добавим кучу RBL (DNSBL) и будем радоваться жизни». Подход не верный чуть более, чем полностью. Второй по популярности — контент-фильтры, зачастую купленные за бешеные деньги. Такой подход тоже в большинстве случаев совершенно неоправдан.

А ведь всё так просто, для спокойной жизни достаточно всего лишь пристально присматриваться к трём заголовкам входящей SMTP сессии. Порывшись на Хабре и в закоулках интернета так и не нашёл исчерпывающей статьи на тему правильной настройки SMTP сервера с точки зрения противодействия спаму. Поэтому решил расписать всё, что знаю на эту тему сам и чем успешно пользуюсь.

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

Итак, если вы хотите обезопасить своих пользователей от спама или наоборот, хотите чтобы кто-то случайно не обезопасил пользователей от ваших писем — добро пожаловать под кат.Небольшая замечание: статья написана с прицелом на настройку почтового сервера Postfix, но в целом носит скорей теоретический характер. Описанные опции Postfix нужно указывать в соответствующих *_restriction параметрах конфигурационного файла, за подробностями обращайтесь к любому руководству по настройке Postfix.

Немного об SMTP протоколе

Электронная почта имеет много аналогий с почтой обычной. Самое для нас главное сейчас то, что вся информация на электронном «конверте» представляет из себя всего лишь два адреса: получателя и отправителя, а также штампик почтальона, конверт доставившего.

Немного отвлечёмся: представьте, что к вам придёт лицо крайне отталкивающей наружности и вручит плотно запечатанную посылку с обратным адресом «Трям из Тилимилитрямдии». Рискнёте принять и открыть? Вряд ли. Так вот, электронную почту можно тоже легко проверять и отсеивать исходя только из адресной информации, причём простор для возможных действий тут гораздо шире.

Как вам должно быть известно, почта в интеренете передаётся между почтовыми серверами по протоколу SMTP. Любое общение по этому протоколу начинается с трёх обязательных заголовков: HELO, MAIL FROM и RCPT TO. То есть перед тем, как начать передавать какие-либо данные, сервер сначала представляется (HELO), потом сообщает обратный адрес отправителя (MAIL FROM) и затем — адрес получателя (RCPT TO). Эти три заголовка и есть подпись на электронном конверте, и практически весь спам можно отсеять только исходя из их анализа. Большинство попыток передать что-то моему серверу не доходят дальше MAIL FROM, то есть письма отсеиваются ещё до фактического принятия, что значительно снижает нагрузку. То есть вместо того, чтобы открыть посылку от Тряма и обнаружить там споры сибирской язвы, я сразу посылаю почтальона куда подальше.

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

Немного о DNS

Когда-то на заре Интернета почта доставлялась непосредственно на узлы, указанные в почтовом адресе. То есть для доставки письма для [email protected] почтовый сервер искал IP адрес domain.com и пытался послать посылочку по найденному IP. Потом появились MX записи, которые разом решили большинство проблем подобной организации почтового взаимодействия. Однако некоторые программы всё ещё могут работать с A записями при доставке почты. Но у вас, конечно, есть хотя бы одна MX запись для вашего домена, не так ли?

MX записи содержат адреса серверов, на которые должны доставляться письма для указанного домена. Однако в целях борьбы со спамом появилась технология, позволяющая указывать в DNS также адреса серверов, с которых могут приходить письма от указанного домена. Имя ей — Sender Policy Framework.

Подробно вдаваться во все тонкости технологии я не буду, скажу лишь, что TXT запись

v=spf1 +mx -all для вашего домена скажет всем клиентам, поддерживающим проверку SPF, что письма из вашего домена могут приходить исключительно с серверов, указанных в MX записях. Можно сделать правило мягче, написав вместо -all ~all. За подробностями обращайтесь в Google и на официальный сайт SPF.

Всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах. Я рекомендую жёстко запрещать отправку писем из вашего домена со всех хостов, кроме ваших MX серверов. Вкупе с проверкой SPF на вашем сервере подобная настройка сразу срежет все письма, посылаемые со сторонних хостов от имени пользователей вашего домена на адреса пользователей вашего же домена. А такого спама чуть ли не половина, поскольку обычно SMTP серверы очень плохо защищены от писем из своего же собственного домена, и спамеры этим активно пользуются. SPF раз и навсегда избавит вас от писем Васе Пупкину, написанных судя по конверту Васей же Пупкиным, но пришедших с сервера в каком-нибудь Никарагуа.

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

Есть ещё пару крайне важных замечаний по поводу DNS. Скорее всего вы знаете, что основные записи DNS, так называемые A записи, преобразуют имя в IP адрес. Кроме них есть ещё CNAME записи, которые назначают псевдоним уже существующему имени. Именно эти два типа записей составляют основу всей системы доменных имён.

Но мало кто из пользователей знает, что есть так же обратные записи, которые преобразуют IP в доменное имя. Они носят название PTR. Так вот, есть два неписаных (строго говоря) правила, которым всё же все следуют:

Для каждой A записи должна существовать зеркальная PTR запись, то есть по имени хоста через DNS получаем IP, а по IP — обратно то же имя хоста.
В качестве адреса в MX записи всегда должно стоять имя (не IP!) хоста, для которого существует A запись. То есть нельзя, чтобы в MX записи стоял IP или псевдоним (CNAME).

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

Ну а чтобы включить проверку PTR у себя, используйте опцию

reject_unknown_client_hostname Она требует, чтобы IP, с которого совершается соединение, резолвился в имя через PTR, а это имя резолвилось в свою очередь обратно в искомый IP.

Есть и менее жёсткое ограничение, задаваемое опцией

reject_unknown_reverse_client_hostname В этом случае сервер будет проверять только наличие PTR записи, но не будет требовать существования соответствующей записи A.

Проверяем приветствие

Итак, кто-то захотел передать вашему серверу письмо. Передача начинается с приветствия — заголовка HELO. В HELO должно быть указано полное доменное имя (FQDN) отправителя, соответственно если это не так — можете смело сразу же отказывать в принятии. В Postfix для этого служат две опции:

reject_invalid_helo_hostname reject_non_fqdn_helo_hostname Первая запрещает приём писем от хостов, передающих приветствие с некорректным синтаксисом, вторая — от хостов, передающих не FQDN в HELO запросе.

Однако не FQDN передают только самые глупые спамеры (и продукты MS, но им, как известно, законы не писаны), в конце концов представиться gmail.com не составляет труда. Поэтому надо ещё немного присмотреться к HELO. Для этого служат опция

reject_unknown_helo_hostname Которая запрещает приём писем от серверов, представляющихся адресом, для которого не существует A или MX записи.

Отправитель — а стоит ли ему доверять?

Итак, сервер успешно вам представился, следующим пунктом программы идёт адрес отправителя. Из него тоже можно извлечь массу полезной информации. Сразу хочу заметить, что адрес отправителя вовсе не обязан быть из того же домена, что и сам сервер. Это распространённое заблуждение, поэтому имейте ввиду, что это не так. Один почтовый сервер спокойно может обслуживать несколько доменов.

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

reject_non_fqdn_sender reject_unknown_sender_domain Первая — проверка адреса на написание, вторая — проверка существования домена.

Уже неплохо, но можно сделать кое-что ещё. Можно запросить сервер, обслуживающий указанный адрес отправителя, на предмет существования на нём пользователя с этим адресом. Действительно, вроде бы неплохая идея удостовериться в том, что обратный адрес действительно существует, иначе нам вполне может придти письмо от эфемерного фантома, о котором никто и не слыхивал.

Технически это реализуется очень просто: наш сервер открывает встречную SMTP сессию, пытаясь послать письмо по адресу отправителя. Если удаётся успешно пройти этап посылки RCPT TO с этим адресом, т.е. если принимающий сервер вдруг не заявляет, что указанного ящика на нём нет, то считается, что присланный нам обратный адрес существует. Данные (то есть письмо) при проверке естественно никакие не передаются, сессия прерывается после RCPT TO.

За такую проверку обратного адреса отвечает опция

reject_unverified_sender Из сказанного выше следует, что для любого адреса, с которого вы рассылаете почту из своего домена, должен существовать ящик на вашем сервере. Иначе ваши письма не пройдут проверку обратного адреса на стороне получателя и соответственно не будут доставлены по назначению. Это актуально для всяких рассылок и прочей вроде как односторонней коммуникации, не требующей ответа. Всегда создавайте ящики для всех адресов, с которых вы рассылаете почту. Если вы не хотите получать ответы на какой-то адрес, то просто посылайте письма на него в /dev/null, но принимать эти письма вы обязаны.

А получатель-то вообще существует?

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

reject_non_fqdn_recipient Кроме того нам бы не хотелось принимать почту на адреса, для которых у нас нет почтовых ящиков. Чтобы настроить такое поведение надо сначала создать список обслуживаемых ящиков, дальше рассказать о нём Postfix через один из *_recipient_maps параметров конфигурационного файла, ну а дальше либо воспользоваться параметром конфигурационного файла

smtpd_reject_unlisted_recipient = yes Либо запрещающей опцией, имеющей тот же эффект:

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

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

reject_unauth_destination Она запрещает отсылку писем всем незарегистрированным пользователям (да, вам придётся настроить SMTP авторизацию). Всегда используйте эту опцию! Иначе быстро попадёте во всякие DNSBL.

В качестве промежуточного итога

Вот так только на основе анализа трёх заголовков конверта можно отсеять огромное количество спама. Однако спамеры хитрые, поэтому этого всё же недостаточно.

Грейлистинг

Иногда почтовые серверы бывают перегружены и не могут принять письмо. Как вы думаете, что они отвечают на входящие запросы в этом случае? Как ни странно так и отвечают — сервер временно недоступен, попробуйте позже. Ни один нормальный отправитель никогда в этом случае не посчитает, что письмо доставить нельзя со всеми вытекающими последствиями. Напротив, отправитель предпримет попытки доставить письмо позже, поставив его в свою очередь на отправку. Этот факт можно (и без сомнения нужно!) очень эффективно использовать: при каждой первой попытке соединения с незнакомого хоста наш сервер будет отправлять сообщение о временной ошибке, а пропускать письмо только со второго раза. Это отсеит сразу чуть ли не весь оставшийся спам, поскольку спамсерверы практически никогда не предпринимают больше одной попытки доставки письма (иначе они бы просто «упали» от переполнения очереди). Эта технология называется Greylisting, и использовать её в современных реалиях просто необходимо.

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

О настройке грейлистинга в Postfix так же предлагаю прочитать в Google, это несложно и ошибиться не получится.

Блоклисты, или как делать не надо

Некоторые администраторы почты при фильтрации спама полагаются на так называемые DNSBL (RBL) — чёрные списки узлов, замеченных в рассылке спама. Так вот, никогда не добавляйте никаких проверок DNSBL на ваши почтовые сервера. Тому есть две причины: первая, и самая основная, кроется во второй части первого предложения этого раздела. В эти списки узлы заносятся совершенно беспорядочно и нет никаких гарантий, что туда не попадёт нормальный хост (на котором, может быть, в какой-то момент поселился вирус, рассылающий спам, но теперь вирус уже вылечили, или проще и гораздо реальней — один внешний IP для большой сети, в которой завёлся спамер). Вторая причина более банальна: предложенный выше механизм фильтрации гораздо эффективней любых DNSBL и при этом не полагается на непроверенные данные от третьих лиц.

С ног на голову, или посмотрим с другой стороны баррикад

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

Для администраторов почтовых серверов:

Всегда делайте MX записи ссылающимися на записи A.
Запись A для почтового сервера всегда должна иметь зеркальную PTR запись.
Хост из HELO заголовка должен иметь A или MX запись.
Всегда создавайте SPF записи (да-да, это-то как раз не обязательно, но просто правило хорошего тона).
Для всех писем, рассылаемых из обслуживаемого домена, ящик для обратного адреса должен существовать и принимать почту.

Для тех, кто рассылает почту (из программ, с сайтов и т.д.):

Всегда посылайте почту только с существующим обратным адресом.
Никогда не посылайте почту с неподконтрольного вам домена, не проверив правила SPF для него. Например gmail.com в текущий момент позволяет посылать письма от его имени любому серверу, а вот yandex.ru и mail.ru сообщают через SPF о том, что посылка от их имени со сторонних серверов должна вызывать на себя пристальное внимание, что истолковывается умными спамфильтрами как увеличение уровня оценки спама для данного письма.
Никогда не посылайте почту через неправильно настроенные SMTP серверы. Проверить сервер на вшивость по списку выше — дело 5 минут, вам поможет утилита dig или nslookup.

Резюме

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

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

UPD: Во-первых спасибо Vanav за критически важные замечания. Во вторых подразумеваемое изначально мной, но видимо всё же не до конца понятое резюме по приведённым опциям:

Вы должны сами решить, какие ограничения вы готовы поставить на свой сервер, а какие — нет. Многие скептически относятся ко многим представленным выше проверкам. Однако все они используются на реальных SMTP серверах в интернете, поэтому даже если вы включите вообще всё — вы будете далеко не одиноки. Поэтому если вы заметили сервер, который настроен неверно, не поленитесь отправить его администратору письмо на эту тему, возможно вы поможете ему избежать гнева со стороны пользователей, чья корреспонденция не дошла (если его уже не выгнали взашей с работы к моменту написания вами письма). И никогда не забывайте, что ломанные хосты можно добавить в вайтлист, дабы принимать от них почту без проверок.

Актуальная версия статьи

Самая последняя и наиболее актуальная версия этой статьи находится на официальном русскоязычном Wiki-ресурсе документации по Ubuntu. Там вы можете свободно улучшать и дополнять выложенные справочные и обучающие материалы, а также добавлять свои собственные. Если вам есть, что рассказать другим пользователям Ubuntu, то огромная просьба — напишите или отредактируйте соответствующую статью на help.ubuntu.ru. Даже небольшими улучшениями и дополнениями вы поможете тысячам людей, а кто-то из них, в свою очередь, опишет что-нибудь полезное и интересное для вас.

habr.com

Причины рассылки спама с сайта

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

Диаграмма источников и причин рассылки спама представлена ниже:

Рассмотрим все возможные причины рассылок почтового спама с сайта (или сервера) и варианты решения этой проблемы.

Спам-рассылка в результате взлома

Взлом сайта или сервера - это наиболее популярная причина возникновения несанкционированной рассылки. Как все происходит? Сайт взламывается хакерами через уязвимости в скриптах или в результате раскрытия доступов (учетных записей) к FTP/SSH/админ-панели сайта или панели хостинга. Получив возможность загружать файлы, хакер (или его бот) размещает спам-скрипты в каталогах сайта или сервера и рассылает спам через них. Обнаружить источник спам-рассылки данном случае поможет анализ служебных заголовков спам-письма (или логов почтового сервиса) и журнала access_log.

Иногда взламывают не сам сайт, а сервер (например, арендованный VPS), загружают по SSH скрипты Perl или Python и через них организуют рассылку почтового спама или туннель.

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

Спам-рассылка без взлома

Рассмотрим более интересные варианты: как спам может рассылаться без взлома сайта (сервера) и спам-скриптов. Их пять.

Спам через уязвимости в скриптах отправки писем
Если на сайте есть скрипты, которые не проверяют значения, передаваемые в запросе, то велика вероятность эксплуатации уязвимости и рассылки спама через легитимные скрипты. Так было, например, с рассылкой спама через рекомендательный компонент плагина virtuemart в Joomla, где любой желающий мог отправить произвольный текст произвольному адресату.
Второй популярный вариант рассылки спама – это использование форм обратной связи, у которых не реализован механизм защиты от ботов (captcha) или со слабой защитой (стандартная captcha). Слабые капчи легко обходятся современными спам-ботами, а если форма не содержит никаких механизмов защиты от ботов, то вероятность спама близка к 100%. Например, проблемы часто возникают у сайтов с формами “Позвоните мне” или “Быстрый заказ”, которые реализованы в виде всплывающего окна с ajax-обработчиком.
Проблема спам-рассылки решается посредством добавления к форме специального поля со сложным механизмом проверки “я не бот”, например, от Google Recaptcha2.
Спам из-за массовых регистраций пользователей или атак на сайт
На многих сайтах, где (возможно и неявно) активирована функция регистрации пользователей, большой поток писем может генерироваться в результате отправки уведомлений о регистрации. Как это работает: специальный бот несколько раз в секунду отправляет специально сформированные запросы на сайт, в результате чего в базе данных создаются новые пользователи, а администратору на email отправляется уведомление о том, что необходимо одобрить или отклонить регистрацию (или просто письмо-уведомление с информацией о том, что на форуме или сайте появился новый пользователь). Таких писем может отправляться несколько сотен в час. Данная проблема часто встречается на сайтах Joomla с активным компонентом K2 или на форумах, где администратор включил опцию отправки уведомлений о регистрации.
Казалось бы, спам-рассылки как таковой с сайта нет, но хостинг-компания все равно может заблокировать работу почтового сервиса для сайта из-за превышения лимита на число отправляемых сообщений.
Проблема решается посредством добавления механизма защиты от авторегистраций (например, через Google Recaptcha2) или (в качестве временного решения) отключения уведомлений о регистрации пользователей.
Еще одним источником несанкционированной рассылки писем может быть проактивная защита или плагин мониторинга на сайте. Правда жизни в том, что на все публичные веб-ресурсы (например, если сайт проиндексирован в поисковой системе) идут постоянные атаки: сканеры, боты и хакеры ищут “чувствительные” файлы и уязвимости в скриптах. И если на сайте есть плагин, отслеживающий веб-атаки, то любой хакерский запрос к страницам сайта формирует отправку уведомления администратору сайта по электронной почте. Учитывая, что атак в секунду может быть несколько десятков, то подобные уведомления быстро превращаются в спам и забивают очередь почтового сервиса, а за это хостер может блокировать почтовый сервис или даже целиком сайт. Часто проблема наблюдается на Битрикс-сайтах, если включена проактивная защита и уведомления администратора по email.
Отправка писем через SMTP другого сервера
К счастью, некорректно настроенный SMTP на VPS или выделенном сервере - явление сейчас редкое, но тем не менее возможное. Проблема называется “Open Relay” – это почтовый сервер, через который любой неавторизованный пользователь может отправлять почту по SMTP протоколу.
Если на вашем выделенном сервере в результате некорректных настроек присутствует SMTP-relay, то сервер будет активно эксплуатироваться для спам-рассылок и, скорее всего, его заблокирует обслуживающая компания по жалобе от SpamCop или другого мониторингового сервиса. Проверить корректность настройки SMTP на сервере можно на этой странице. Если у вас обнаружена некорректная настройка почтового сервера, обратитесь к администратору.
Рассылка спама через взлом почтового ящика домена
Последнее, что приходит в голову владельцу сайта, которого заблокировали за спам – это проверить свои почтовые ящики домена на взлом.В последнее время все чаще подвергаются компрометации именно корпоративные email, зарегистрированные в домене сайта. Доступ к почте хакеры получают в результате подбора/перехвата/кражи паролей, а это, в свою очередь, случается при работе пользователя по небезопасному сетевому подключению, в результате работы троянских программ или клавиатурных шпионов на компьютере и мобильном устройстве. Взломать могут email бухгалтера или менеджера по работе с клиентами – тех, кто не особенно посвящен в тему информационной безопасности.
Если почта размещена в серверах хостера, то спам, отправляемый через взломанный email, будет идти также через почтовый сервер хостинг-компании, и владелец сайта получит уведомление о спам-рассылке. По анализу служебных заголовков отправляемых писем можно определить, с какого именно email отправляются письма.
В качестве превентивной меры следует как можно чаще менять пароли от почтовых ящиков, устанавливать их сложными и разными.
Отправка спама с подменой отправителя
Часто владельцы сайтов, у которых почта находится на почтовых серверах хостера, получают так называемые NDR (Non Delivery Report) – уведомления о недоставленных почтовых письмах. При этом текст письма может содержать спам-сообщение (рекламный текст, фишинговая ссылка или вредоносный аттач). Естественно, данные письма пользователь почтового ящика не отправлял. В каких случаях данная проблема может возникать?
Варианта два:1. Взлом почтового ящика, про который мы писали в пункте №4.2. Отправка писем с фальшивого email.
Например, в качестве email отправителя хакеры могут использовать случайную последовательность символов вместо имени пользователя: [email protected] В этом случае, если письмо не доставлено получателю (а в случае спам-рассылки таких писем сотни или даже тысячи), то email возвращается на [email protected]. Конечно, вероятнее всего данного почтового ящика не будет зарегистрировано в домене и письмо попадет или в ящик, который назначен как обработчик “по-умолчанию” для всех недоставленных писем (например, email администратора или владельца сайта), или будет удалено. Это еще полбеды. Но зачастую злоумышленники используют существующие email для отправки спама. Ничто не мешает хакеру отправить email, указав в поле From чей-нибудь существующий адрес, например, [email protected] . Особенно, если для домена mysite.ru, на котором зарегистрирован email, не настроены соответствующие аутентификационные механизмы SPF и DKIM. Тогда все недоставленные письма вернутся на [email protected] и единственный вариант борьбы с ними – это настройка антиспам-фильтра на почтовом сервере или фильтра, который будет удалять NDR письма автоматически.

В качестве заключения

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

Обсуждаем и комментируем

revisium.com

Спам в ВК или как ракскрутить хостинг без денег! | Bukkit по-русски

[23:18:00] Создатель сервера [Magic Diamond]: Мда... Здравствуйте! Нас интересует сотрудничество с вашим проектом. Мы можем предоставить бесплатный хостинг для ваших серверов и техническую поддержку в обмен на рекламу и партнерство. skype:a.rchier vk.com/id6757316 www.mr-hosting.com [23:18:24] Роман Support: ?? [23:18:24] Создатель сервера [Magic Diamond]: Зачем им это? [23:18:29] Создатель сервера [Magic Diamond]: )) [23:18:33] Создатель сервера [Magic Diamond]: не по теме конечно [23:18:48] Роман Support:

[23:18:51] Создатель сервера [Magic Diamond]: вы же "общались" с mr-hosting [23:18:53] Создатель сервера [Magic Diamond]: они мне такое пишут [23:18:55] Создатель сервера [Magic Diamond]:

[23:18:56] Роман Support: жесть [23:19:01] Роман Support: видимо плохи дела [23:19:08] Создатель сервера [Magic Diamond]: всмысле? [23:19:12] Роман Support: а что за реклама [23:19:14] Роман Support: где [23:19:16] Создатель сервера [Magic Diamond]: хз [23:19:16] Создатель сервера [Magic Diamond]: )) [23:19:22] Роман Support: а откудапришло [23:19:25] Создатель сервера [Magic Diamond]: вконтакте [23:19:29] Создатель сервера [Magic Diamond]: меня в друзья [23:19:31] Создатель сервера [Magic Diamond]: и сообщение [23:19:34] Создатель сервера [Magic Diamond]: http://vk.com/id67573167 [23:19:45] Создатель сервера [Magic Diamond]: сайт их [23:19:52] Роман Support: вам в вк написали? [23:19:55] Создатель сервера [Magic Diamond]: да [23:20:02] Роман Support: а рекламить где хотят [23:20:06] Роман Support: у вас группаили что [23:20:13] Создатель сервера [Magic Diamond]: я незнаю [23:20:16] Создатель сервера [Magic Diamond]: в группе у меня 1к [23:20:18] Создатель сервера [Magic Diamond]: людей) [23:20:24] Роман Support: странные [23:20:30] Создатель сервера [Magic Diamond]: Угу) [23:20:33] Роман Support: жмите спам [23:20:35] Роман Support: ) [23:20:37] Создатель сервера [Magic Diamond]:

[23:21:07] Создатель сервера [Magic Diamond]: я щас напишу) [23:21:09] Создатель сервера [Magic Diamond]: им [23:21:24] Роман Support:

[23:21:39] Создатель сервера [Magic Diamond]: Почему именно я, есть же более крупные проекты 23:21:01

АндрейУ крупных проектов и так все свое есть, им ничего не нужно[23:23:09] Создатель сервера [Magic Diamond]: мдааа[23:23:11] Создатель сервера [Magic Diamond]: скатились они[23:23:12] Создатель сервера [Magic Diamond]: [23:23:23] Роман Support: вообще жесть[23:23:24] Создатель сервера [Magic Diamond]: много текста, отправить?[23:23:27] Роман Support: ?[23:23:29] Создатель сервера [Magic Diamond]: 1. Ссылки в блоке ссылок в группе:vk.com/mr_hostingЗаведи СоВОЙ сервер! Рекордно экономный хостинг!www.mr-hosting.com7.5р/слот Multicraft,850р VDS6GB,2599р i7-4770,32GB.2. Видео в видеозаписях:https://vk.com/mr_hosting?z=video-57975952_1660090523. репост вот этого поста:https://vk.com/mr_hosting?w=wall-57975952_226+ репосты важных новостей 3-5 раз в месяц.4. Баннер на сайте + ссылка на сайт www.mr-hosting.comhttp://mr-hosting.com/Sova-468x60.gifhttp://mr-hosting.com/Owl-200x120a.gifhttp://mr-hosting.com/Owl-120x600.gifhttp://mr-hosting.com/Owl-140x560.gifhttp://mr-hosting.com/Owl-120x600sm.gif5. automessage на серверах"www.mr-hosting.com! 7.5р/слот на Мультикрафте, 850р - VDS 6GB RAM, 2599р - выделенный сервер i7-4770!!!"

MrHosting 8:2323:22:42поставьте вот это, и я вам выделю небольшой хост, либо хорошую скидку на наши услуги[23:23:48] Создатель сервера [Magic Diamond]: [23:23:51] Создатель сервера [Magic Diamond]: вообще[23:23:52] Создатель сервера [Magic Diamond]: жесть[23:24:51] Роман Support: ахаха[23:24:53] Роман Support: скотились[23:25:02] Роман Support: на дно)[23:25:04] Создатель сервера [Magic Diamond]: я могу вам выделить 2гб оперативы[23:25:05] Создатель сервера [Magic Diamond]: [23:25:06] Создатель сервера [Magic Diamond]: пздц[23:25:25] Роман Support: на своих лагучих машинах выделят[23:25:27] Роман Support: [23:25:51] Роман Support: скажи что реклама у тебя стоит дороже[23:25:58] Роман Support: а не лошовские 2 гб места[23:26:02] Роман Support: (rofl)[23:26:06] Создатель сервера [Magic Diamond]: Ахах[23:27:00] Создатель сервера [Magic Diamond]: я просто тут смеюсь, пздц как)))[23:27:15] Создатель сервера [Magic Diamond]: пишет может дать панель 2гб[23:27:19] Создатель сервера [Magic Diamond]: типо это 48 слотов[23:27:22] Роман Support: (rofl)[23:27:43] Создатель сервера [Magic Diamond]: ну без плагинов вообще мб и 48

Нажмите, чтобы раскрыть...

rubukkit.org

Свой smtp сервер под спам | Страница 2

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

Greylist (серый список) достаточно эффективное средство для борьбы со спамом. Метод основан на том, что когда письмо приходит на почтовый сервер, сервер его не принимает а выдает предупреждение о временной недоступности, а координаты отправителя заносит в специальный список (базу данных). Если почтовый сервер отправителя настроен правильно, то в самое ближайшее время произойдет вторая попытка отправить это-же письмо, которое на этот раз обработается нашим почтовым сервером. Информация о том принять или отклонить письмо берется из базы временных списков. Первый раз отклоняем, если видим что второй раз приходит это же письмо, то принимаем.

как показала практика, 98% спама не доходят до адресата только при использовании серых списков.оставшиеся сообщения отправляются на SpamAssasin, и после проверки доходят до адресатов. Спойлер

В основе Spamassassin лежит метод детектирования спама по ряду характерных признаков. Каждому признаку назначается определенное количество баллов. В процессе анализа сообщения баллы для найденных соответствий суммируются, и окончательное решение принимается в зависимости от того, превысил ли итоговый результат некоторое пороговое значение. Помимо простых признаков, наподобие приведенных выше, Spamassassin использует и ряд довольно сложных, основанных на других методах детектирования спама. Так, в состав Spamassassin входит статистический обучаемый анализатор, работающий на основе байесового классификатора. В отличие от таких инструментов, как DSPAM, письмо не признается однозначно спамом в случае «положительного результата» такого анализа, а лишь получает некоторый «довесок» к общему баллу. Причем вы можете самостоятельно настраивать величину этого довеска в зависимости от того, насколько вы доверяете статистическим анализаторам.

вот по поводу анализатора - есть механизм самообучения. мы регистрируем ящик на бесплатном сервисе, ловим в него килотонны спама, перегоняем его в системный спам-ящик на нашем сервере, специально для этого предназначенный, и его содержимое отдаем SA для изучения и анализа.самый успешный спам, который к нам доходил, это были сообщения в формате html + картинки с текстом. их очень сложно профильтровать.поэтому я бы хотел выделить 2а важных правила:1. необходимо уметь все время генерировать тексты писем уникального содержания, что весьма проблематично. нужно уметь маскировать стоп-слова, которые попадают под фильтры (типа viagra, сialis, xanax), всех не помню))2. необходимо иметь систему сбора и анализа серверов типа "open-relay", для их последующего использования, иначе вы проспамитесь парой тысяч одинаковых сообщений, и через сутки ваш сервер попадет в dnsbl/spamhous, после чего почтовики просто не будут устанавливать с ним соединения. если конечно еще раньше провайдер не отключит его от инета за абузы, которые будут поступать.3. соответственно нужны постоянные списки открытых релеев, которыми можно пользоваться, а так же нужны дедики, т.к. не целесообразно рассылать с места своей локации, это тоже палево. в крайнем случае подойдут socks-сервера, через которые можно слать безнаказанно.т.е. по сути, говоря по делу и вернувшись к теме спама с одного сервера на колокейшене - не долго проживет такое решение, особенно в нашей, цивилизованной части планеты. наиболее эффективное решение - это рассылки спама при помощи бот-сетей, но это уже другие дела, другой бюджет.

www.nulled.cc

Наличие IP в СПАМ базах

Наверняка многие из вас слышали, знают или испытали на себе, что такое СПАМ. Приведем небольшой отрывок текста из Википедии, из которого вы узнаете о происхождении этого термина.

Термин SPAM появился ещё в 1936 г. — так назывались свиные консервы компании «Hornel Foods» (англ. Shoulder of Pork and нAM — «свиные лопатки и окорока») (по другим данным, 1937 г., та же «Hornel Foods», от англ. SPiced hAM — «ветчина со специями»). Консервы были вкусными, питательными и, что немаловажно для того времени, дешёвыми (это был острый колбасный фарш из второсортной свинины). Неудивительно, что очень быстро они стали чуть ли не национальным блюдом Америки. Читать текст полностью

Всемирную известность в применении к назойливой рекламе термин SPAM получил благодаря знаменитому скетчу с одноимённым названием из известного шоу «Летающий цирк Монти Пайтона» (1969) комик-группы Монти Пайтон. Смысл скетча сводится к тому, что в одном кафе все блюда в меню содержат «SPAM», некоторые даже по нескольку раз. Когда главный герой скетча, пришедший в это кафе вместе с женой, просит принести ему блюдо без «SPAM», официантка предлагает ему блюдо с «небольшим количеством SPAMа». Посетитель возмущается и хор викингов, сидящих за соседними столиками, начинает петь хвалебную песню «SPAMу», после чего скетч погружается в хаос. В конце скетча жена героя восклицает: «I don’t like spam!» (англ. Я не люблю «SPAM»!). В титрах к именам действующих лиц также было добавлено слово «SPAM». В общей сложности это слово упоминается в скетче более ста раз.В 1986 г. в конференциях Usenet появилось множество одинаковых сообщений от некоего Дэйва Родеса, который рекламировал новую финансовую пирамиду. Заголовок гласил: «Заработай кучу денег», а в письмах содержалась инструкция, как это сделать. Автор с завидным упорством продолжал дублировать свои тексты, и они настолько приелись подписчикам, что их стали сравнивать с рекламируемыми в скетче консервами.Так за словом «спам» закрепилось новое значение, позднее перешедшее в компьютерную терминологию для обозначения назойливых рекламных рассылок.

Итак, все мы знаем, что СПАМ это плохо. Плохо потому, что мы получаем на наши email адреса горы ненужного нам мусора, а иногда, что еще хуже, вирусы, трояны и т.п. и т.д. С целью защитить простого пользователя от всего этого, создаются базы, которые содержат IP адреса наиболее злостных спамеров. Различные антиспам фильтры наших почтовых программ или почтовых служб, таких как mail.ru, используют эти базы для того, чтобы отделить СПАМ от действительно нужной и ожидаемой нами корреспонденции. Каким образом это происходит? Например, кто нибудь рассылает СПАМ в огромных количествах с определенного IP адреса. Этот IP с очень большой вероятностью попадет в одну или в несколько баз. Затем, получая письмо, например на свой ящик в mail.ru система проверит IP адрес, с которого пришло письмо и проверит его на наличие в СПАМ базах. Если такой IP присутствует хотя бы в одной из них, письмо помечается как СПАМ и либо вообще не принимается, либо перемещается в специальную папку либо удаляется (это зависит от конкретного mail сервиса). В итоге это письмо не доходит до получателя.

Теперь вы примерно представляете каким образом работает вся эта система. А сейчас представьте, что в один прекрасный момент вы получили IP адрес, который находится в одной или в нескольких СПАМ базах. Что это значит? Это значит, что ваши письма могут быть расценены почтовыми сервисам как СПАМ и не будут доставлены получателю. Почему у вас такой IP адрес это уже другой вопрос, возможно раньше с него производилась массовая рассылка.

Наш тест поможет вам определить наличие вашего IP адреса в нескольких десятках самых активных СПАМ базах. Также вы можете проверить не только ваш IP, но и любой другой.

Если ваш IP будет присутствовать в одной из баз, вы получите выделенное красным цветом извещение. Перейдя по адресу в этом извещении вы сможете подать заявку на удаление вашего IP адреса из этой СПАМ базы.

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

Подождите. Идет проверка.

2ip.ru

Как попасть в списки Spamhaus, не рассылая спам / Хабр

Незапрошенная корреспонденция (СПАМ), несомненно, стала неотъемлемой (увы!) частью современной сети Интернет. Конечно же со спамом можно (и нужно!) бороться, но методы такой борьбы могут быть различными. Можно бороться со спамом на этапе отправки писем, можно на этапе получения. При получении писем их можно фильтровать различными способами — проверка SPF, DKIM, спам-листы. Вот о последнем, а именно о спам-листах Spamhaus я и хотел бы написать. В принципе, спам-листы являются полезным изобретением — их использование действительно позволяет отсеять значительную часть спама. Однако, такие листы имеют смысл лишь если в них есть актуальная информация. Вот тут-то и начинаются проблема.

Существует такая организация как Spamhaus, спам-листы от которой являются весьма популярным и, более того, некоторые реестры доменных зон принимают данные из этих списков как основание для блокировки домена. Тем не менее подходы Spamhaus несколько удивляют.

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

Несколько лет назад при таком внесении Spamhaus предоставлял достаточные доказательства с заголовками письма, но не так давно подход изменился. Теперь такое внесение Spamhaus производит не только при обнаружении рассылки спама, но и при обнаружении ботнет-контроллеров, однако доказательства весьма лаконичные. К примеру, в одном из SBL (http://www.spamhaus.org/sbl/query/SBL194743) доказательством такой деятельности был открытый 6522 порт, но был ещё SBL194500 (сейчас, правда, уже удалённый) где порт был 443 и всё доказательство заключалось в подключении к этому порту при помощи telnet.

Таким образом, для попадания в спам-листы достаточно чтобы _один_ клиент разместил ботнет-контроллер (которым последнее время является просто php скрипт). Даже если предоставляющий виртуальный хостинг провайдер непримиримо относится к рассылке спама, он всё равно рано или поздно попадёт в спам-листы Spamhaus и узнает об этом лишь после множественных обращений к нему его клиентов с вопросами вида «почему моя почта теряется». Существует, правда, услуга «DNSBL Datafeed», которую предоставляет Spamhaus и она позволяет получить информацию о внесении в листы несколько раньше, но эта услуга, естественно, платная.

habr.com

BulletProof Хостинг. Что это? | ePochta

Думаю многие встречали в Интернете термин «BulletProof Хостинг», однако уверена большинство не знают его суть и не понимают чем же отличается Bullet Proof хостинг от обыкновенного. Поэтому сегодня решила посвятить сегодняшнюю статью данной теме.

Иногда данный термин употребляется и в других значениях: bulk-friendly хостинг, абузостойкий/абузоустойчивый хостинг. Если вкратце, то BulletProof (с англ. пуленепробиваемый) хостинг предназначен для ресурсов с заведомо запрещенным содержанием, для ресурсов которые нарушают существующие законы и распространяют запрещенные материалы. Чаще всего подобный хостинг используют спамеры, онлайн-казино и порно ресурсы.

В большей степени именно благодаря подобным хостингам сейчас в Интернете такое большое количество спама. BulletProof хостинг позволяет делать массовые почтовые рассылки без боязни быть наказанным за спам-рассылки.

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

Однако в случае с BulletProof хостингом, хостинг-провайдеры игнорируют данные жалобы и сервера имеют беспрепятственный доступ к сети. Каким образом это все функционирует и как канальные операторы не наказывают подобных хостеров, мне не известно, однако полагаю, что есть определенные договоренности. Ведь не секрет, что BulletProof хостинг зачастую в десятки раз дороже обыкновенного. Цены обычно начинаются от 200 долларов в месяц за сервер и доходят до несколько тысяч в случае с 100% гарантией не отключения.

По статистике наибольшее число BulletProof серверов находится в Китае, Южной Америке, России и странах СНГ.

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

Вышел в свет новый ePochta List Manager: теперь все операции над списками выполняются наглядно

Загрузка...