Каковы лучшие методы для ловли спама снегоступа?
Я использую Smartermail для своего маленького mailserver. У нас была проблема в последнее время получения волн спама снегоступа, которые следуют за тем же шаблоном. Они прибывают в пакеты 3 или 4 за один раз. Тела являются почти идентичным сохранением для доменного имени, с которым они связываются. Исходный дюйм/с имеет тенденцию быть от того же/24 блока некоторое время, затем они переключаются на другой/24. Домены имеют тенденцию быть совершенно новыми. Они имеют допустимый PTR и записи SPF и имеют случайный мусор у основания тела для спуфинга байесовских фильтров.
Я использую приблизительно дюжину различных РУБЛЕЙ включая Барракуду, Spamhaus, SURBL и URIBL. Они делают достойное задание, ловя большинство из них, но мы все еще получаем много промах через, потому что дюйм/с и домены не были помещены в черный список.
Есть ли какие-либо стратегии, которые я могу использовать, включая РУБЛИ, что блок недавно создал домены, или имейте дело конкретно с snoeshow спамом? Я надеюсь избежать необходимости использовать сторонний сервис фильтрации.
Становится ли это реальной проблемой для ваших пользователей?
Я бы порекомендовал на данный момент полнофункциональный сервис фильтрации почты. Байесян уже не так горяч. Репутация, RBL, анализ заголовков/вопросов и другие факторы, кажется, помогают больше. Рассмотрим облачный сервис фильтрации, чтобы объединить несколько подходов (и коллективный объем) для обеспечения лучшей защиты (Я использую облачное решение ESS Barracuda для моих клиентов).
И конечно же: Борьба со спамом - что я могу сделать: Администратор электронной почты, владелец домена или пользователь?
На нас не оказали негативного влияния атаки на снегоступы. Я видел период, когда объем почты утроился с каждым днем в результате этих атак. Но ни одна из плохих вещей не выдержала. За 3 дня Барракуда снизил объем до нормального уровня.
Я думаю, что решения фильтрации, которые имеют широкий взгляд на мировую почтовую активность, могут реагировать на атаки лучше, чем отдельные почтовые фильтры.
Правка:
Это также обсуждалось недавно в списке рассылки LOPSA:
Мой вклад: https://www.mail-archive.com/tech
Другое мнение: _COPY4@lists.lopsa.org/msg04181.html
Я парень из DNS Ops, который работает в тесном контакте с группой, которая часто подвергается таким атакам. Борьба с атаками на снегоступы - это в первую очередь технологическая проблема, и, как указывает Уэуайт, ее решение может выйти за рамки возможностей вашей компании. Я бы сказал, что если у вас нет большой операции и нескольких коммерческих RBL-каналов, вам , вероятно, не стоит пытаться решить эту проблему самостоятельно, используя коммерческую службу фильтрации.
Тем не менее, у нас есть некоторый опыт работы с этим, и более интересно поделиться им, чем не поделиться с вами. Некоторые точки соприкосновения:
- Если возможно, обучение вашей почтовой платформы определению характеристик атаки на снегоступы и временное отклонение сообщений из рассматриваемых сетей. Хорошо себя зарекомендовавшие клиенты будут пытаться повторно отправлять сообщения при временном сбое, другие, как правило, этого не делают.
- Убедитесь, что ваши DNS-администраторы отслеживают
UDP-MIB::udpInErrorsпо протоколу SNMP, потому что почтовые платформы очень способны переполнять очереди приема UDP-послушателей во время проведения атаки на снегоступы. Если это не так, то быстрый способ определить это под Linux - запуститьnetstat -s | grep 'packet receive errors'на соответствующих DNS-серверах; большой подсчет указывает на то, что им нужно снять напряжение и начать обращать на это внимание. При частой утечке им нужно будет добавить емкость или увеличить размер буферов приема. (что означает потерянные DNS запросы, и потерянные возможности для предотвращения спама) - Если вы часто видите эти атаки с использованием только что созданных доменов, то RBL, которые выделяют их, действительно существуют. Примером является FarSight NOD (люди, читающие это, должны проводить свои собственные исследования), но это не бесплатно.
Полное раскрытие: Farsight Security был основан Полом Викси (Paul Vixie), у которого у меня дурная привычка проветривать, когда люди нарушают стандарты DNS
.Я установил Declude (который является бесплатным) и анализатор сообщений (который не является), и за последние 4 дня я заметил одно спам-сообщение, пришедшее на мою тестовую учетную запись электронной почты,в отличие от десятков, которые он получал в день. Насколько я могу судить, нам не удалось отфильтровать хорошие электронные письма. Spamassassin, вероятно, также был бы хорошим решением, хотя мне не повезло с ним, когда я попробовал Spam Assassin in a Box ..
Многие ответы здесь относятся к общей защите от спама. В некоторой степени это имеет смысл, поскольку спамеры, похоже, предпочитают использовать снегоступы в качестве предпочтительного метода доставки.
Изначально Snowshoe всегда отправлялся из центров обработки данных в небольшом объеме (на основе IP) и всегда содержал ссылку для отказа от подписки (на ничего не сказать о том, работает ли). В настоящее время snowshoe почти никогда не имеет информации об отказе от подписки и отправляется в большом объеме со своих IP-адресов, но отправляется пакетно, так что к тому времени, когда IP-адрес попадает в черный список, он уже отправил почту. Это называется грозовым спамом .
Из-за этого DNSBL и даже жесткие подписи на основе шаблонов ужасны при обнаружении спама на снегоступах. Есть некоторые исключения, такие как список CSS Spamhaus (который специально предназначен для сетей на снегоступах и является частью как SBL, так и ZEN), но в целом вам понадобится серый список / tarpitting (который может задерживать доставку до тех пор, пока DNSBL не догонит) и, что наиболее важно, система машинного обучения, управляемая токенами, такая как байесовская фильтрация спама . Байес особенно хорош в обнаружении снегоступов.
В ответе Эндрю Б. упоминаются Новые домены и имена хостов (NOD) Farsight Security, которые пытаются предвидеть появление сетей на снегоступах, но до того, как они появятся. начать рассылать спам. Spamhaus CSS, вероятно, делает нечто подобное. CSS готов к использованию в среде блокировки, в то время как NOD действительно предназначен для подачи в пользовательскую систему, а не в автономную / блокирующую систему.