Каковы лучшие методы для ловли спама на снегоступах?

Я использую Smartermail для своего небольшого почтового сервера. В последнее время у нас возникла проблема получения волн спама на снегоступах, которые следуют той же схеме. Они приходят партиями по 3 или 4 за один раз. Тела почти идентичны, за исключением доменного имени, на которое они ссылаются. Исходные IP-адреса, как правило, некоторое время находятся в одном и том же блоке / 24, а затем переключаются на другой / 24. Домены имеют тенденцию быть совершенно новыми. Они имеют действительные записи PTR и SPF и имеют случайную тарабарщину внизу тела, чтобы подделать байесовские фильтры.

Я использую дюжину разных RBL, включая Barracuda, Spamhaus, SURBL и URIBL. Они делают приличную работу, отлавливая большинство из них, но мы по-прежнему часто сталкиваемся с ошибками, поскольку IP-адреса и домены не попали в черный список.

Могу ли я использовать какие-либо стратегии, в том числе RBL, которые блокируют вновь созданные домены или имеют дело со спамом в snoeshow? Я надеюсь избежать использования сторонней службы фильтрации.

Это становится реальной проблемой для ваших пользователей?

Я бы порекомендовал полный сервис фильтрации почты на этом этапе. Байесовский уже не такой горячий. Репутация, RBL, анализ заголовка / намерения и другие факторы, кажется, помогают больше. Рассмотрим службу облачной фильтрации, которая объединяет несколько подходов ( и общий объем ) для обеспечения лучшей защиты ( я использую облачное решение ESS от Barracuda для своих клиентов ).

И конечно: Борьба со спамом - Что я могу сделать как: администратор электронной почты, владелец домена или пользователь?

На нас не повлияло отрицательное влияние нападений на Снегоступах. Я действительно видел период, когда объем почты увеличивался в день с этими атаками. Но ничего плохого не удалось. За 3 дня Барракуда снизил объемы до нормального уровня.

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

Редактировать:

Это также обсуждалось недавно в списке рассылки LOPSA :

Мой вклад: https://www.mail-archive.com/tech@lists.lopsa.org/msg04180.html
Другое мнение: https://www.mail-archive.com/tech@lists.lopsa.org/msg04181 .html

Я парень DNS Ops, который тесно сотрудничает с группой, которая часто подвергается этим атакам. Работа с атаками на снегоступах - это, прежде всего, проблема процесса, и, как указывает ewwhite, решение вашей компании может выходить за рамки вашей компании. Я бы даже сказал, что если у вас нет значительной операции и нескольких коммерческих каналов RBL, вам, вероятно, не следует пытаться решить эту проблему самостоятельно, используя коммерческую службу фильтрации.

Тем не менее, у нас есть некоторый опыт в этом, и поделиться им интереснее, чем нет. Некоторые точки соприкосновения:

• Если возможно, обучите свою почтовую платформу определению характеристик выполняемой атаки Snowshoe и временно отклоните сообщения от рассматриваемых сетей. Клиенты с хорошим поведением будут пытаться пересылать сообщения при временном сбое, другие, как правило, этого не делают.
• Убедитесь, что ваши администраторы DNS осуществляют мониторинг UDP-MIB::udpInErrorsчерез SNMP, потому что почтовые платформы очень способны переполнять очереди приема прослушивателей UDP, когда идет атака Snowshoe. Если это не так, быстрый способ определить это в Linux - запустить netstat -s | grep 'packet receive errors'на рассматриваемых DNS-серверах; большое количество указывает на то, что им нужно снять свои брюки и начать обращать внимание. Им потребуется увеличить емкость или увеличить размер приемных буферов, если происходит частая утечка. (что означает потерянные DNS-запросы и потерянные возможности для предотвращения спама)
• Если вы часто видите эти атаки с использованием только что созданных доменов, RBL, которые их выделяют, существуют. Пример одного из них есть Farsight NOD (люди , читающие это должны выполнять свои собственные исследования), но это не бесплатно.

Полное раскрытие: Farsight Security была основана Полом Викси, у которого есть плохая привычка высказываться, когда люди нарушают стандарты DNS.

Я установил Declude (который бесплатен) и Message Sniffer (который не является), и за последние 4 дня я видел одно спам-сообщение, приходящее в мою тестовую учетную запись электронной почты, в отличие от десятков, которые он получал в день. Насколько я могу судить, мы не отфильтровали хорошую почту. Spamassassin, вероятно, также будет хорошим решением, хотя мне не повезло с ним, когда я попробовал Spam Assassin in a Box ...

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

Первоначально Snowshoe всегда отправлялась из центров обработки данных в небольшом объеме (для отдельных IP-адресов) и всегда включала ссылку для отмены подписки (не говоря уже о том, работает ли она). В настоящее время снегоступы почти никогда не имеют информации о подписке и отправляются в большом объеме со своих IP-адресов, но отправляются в виде пакета, так что к тому времени, когда IP-адрес занесен в черный список, он уже завершил отправку почты. Это называется градом спама .

Из-за этого DNSBL и даже жесткие подписи на основе шаблонов ужасны при ловле спама на снегоступах. Есть некоторые исключения, такие как список CSS Spamhaus (который специально направленных на снегоступах сетей и является частью как SBL и ZEN), но в целом вы будете нуждаться в серый список / искусственной задержки ответов (которые могут задержать доставку до тех пор , DNSBLs не догнать ) и, самое главное, система машинного обучения, основанная на использовании токенов, такая как байесовская фильтрация спама . Байес особенно хорош в обнаружении снегоступов.

В ответе Эндрю Б. упоминаются новые домены и имена хостов (NOD) Farsight Security , которые пытаются предвидеть сети на снегоступах, когда они раскручиваются, но до того, как начинают рассылаться спам. Spamhaus CSS, вероятно, делает что-то подобное. CSS готов к использованию в блокирующей среде, в то время как NOD действительно предназначен для подачи в пользовательскую систему, а не в автономную / блокирующую систему.