Блокировать спам с помощью фильтра Geoip?

Из этого исследования SNARE я представляю этот самородок:

Для ветчины 90% сообщений проходят около 4000 км или меньше. С другой стороны, для спама, только 28% сообщений остаются в этом диапазоне.

Мои личные наблюдения отражают ваши и отмечают, что даже сейчас, в 2014 году, географическое положение продолжает быть отличным предиктором спама. Как указывали другие, само местоположение GeoIP (страна или расстояние) не является достаточно надежной основой для блокировки соединений. Однако объединение расстояния GeoIP с несколькими другими частями данных о соединении, такими как FCrDNS, достоверность имени хоста HELO, ОС отправителя (через p0f) и SPF, обеспечивает надежную основу на 99,99% (например, вероятность 0,01% для FP) для отклонения 80% соединений перед фазой DATA.

В отличие от некоторых SMTP-тестов (таких как листинг DNSBL в zen.spamhaus.org), которые имеют очень низкие показатели FP, ни один из вышеупомянутых тестов в отдельности не является достаточной основой для отклонения соединений. Вот еще один шаблон, который попадает в эту категорию -пользователь отправителя конверта совпадает с пользователем получателя конверта . Я заметил, что около 30% спама следует этому шаблону: от: matt@spammer-controlled-domain.tld до: matt@my-domain.com. Это происходит гораздо чаще в спаме, чем в действительных почтовых потоках. Другой шаблон спамера - это несоответствующий конверт и заголовок домена.

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

Все тесты, которые я перечислил в первом абзаце, выполняются перед SMTP DATA. Объединение этих ранних тестов формирует достаточную основу для отклонения спам-соединений перед SMTP DATA без каких-либо ложных срабатываний. Отклонение соединения до данных SMTP позволяет избежать затрат на пропускную способность при передаче сообщения, а также более высокую нагрузку на ЦП и сеть для фильтров на основе контента (SpamAssassin, dspam, проверка заголовков, DKIM, URIBL, антивирус, DMARC и т. Д.) Для подавляющего большинства соединений. Выполнение намного меньшего количества работы за соединение масштабируется намного лучше.

Для меньшего подмножества сообщений, которые не определены в SMTP DATA, соединение разрешено устанавливать, и я оцениваю сообщение с результатами из фильтров содержимого.

Чтобы выполнить все, что я описал, я немного взломал SMTP-сервер на базе node.js под названием Haraka. Масштабируется очень и очень хорошо. Я написал собственный плагин под названием Karma, который выполняет эвристическую оценку, и я поместил все весовые оценки в файл конфигурации. Чтобы понять, как работает карма, взгляните на файл конфигурации karma.ini. Я получаю результаты фильтрации "лучше, чем gmail".

Взгляните также на тесты, запускаемые FCrDNS, helo.checks и data.headers. Они могут предоставить вам дополнительные идеи фильтрации. Если у вас есть идеи для надежного обнаружения спама с помощью дешевых (до DATA) тестов, мне интересно их услышать.

Другие вопросы, которые вам нужно задать: каков ваш приемлемый уровень ложноположительного и ложноотрицательного (сколько легальной почты вы готовы потерять и сколько нежелательной почты вы готовы принять?)

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

Подумайте о том, сколько вы хотите, чтобы ваши расходы на внешний вид при планировании системы защиты от спама. Например, черные списки на основе ipfilter не прощают, но не оказывают существенного влияния на любую другую систему. Greylisting сохраняет пропускную способность отправителя и получателя, но дольше сохраняет почту в удаленных очередях. Сообщения о пересылке почты и системы вызова / ответа могут (ab) использоваться для почтовой бомбардировки несвязанной третьей стороны. Такие методы, как tarpitting, активно выводят издержки за счет намеренного удержания открытых SMTP-соединений в течение длительных периодов времени. DNSBL требуют, чтобы вы передали некоторую часть контроля третьей стороне (сторонникам черного списка), но в конечном итоге вы, как почтовый администратор, несете ответственность за разъяснение политики блокирования своим пользователям и руководству. В результате есть этические соображения, которые согласуются с каждой технологией, и важно знать о вашем влиянии на других.

Насколько вы будете терпимы к неверно настроенным внешним системам? (например, те, у которых нет FCrDNS, поврежденные строки HELO/EHLO, несанкционированная конвейерная обработка, те, которые не повторяют попытки после временного сбоя с кодом 4xx и т. д.)

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

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

Если в последнее время ничего не изменилось, занесение в черный список IP-адресов по странам происхождения не слишком эффективно. У меня была идея использовать отпечаток ASN и ОС (через p0f) для оценки качества входящего соединения, но я не преследовал его; статистику было бы интересно посмотреть, но я не уверен, что она будет более полезной, чем стандартные методы, уже описанные. Преимущество использования информации об отпечатках пальцев GeoIP, ASN и OS заключается в том, что, хотя они могут быть индивидуально слабыми предикторами качества соединения, они доступны во время соединения TCP/IP задолго до того, как вы достигнете уровня SMTP (fsvo "long".) В сочетании они могут оказаться полезными, и это было бы полезно, поскольку спам становится дороже блокировать при приближении к конечному пользователю.

Я не пытаюсь быть скептиком; Кодировки символов "странный" и информация GeoIP, вероятно, хорошо коррелируют со спамом, но могут быть недостаточно надежными, чтобы использовать их в качестве единого критерия для блокировки почты. Однако они могут быть полезными индикаторами в системе, подобной Spamassassin. Вывод заключается в том, что защита от спама представляет собой сложную проблему в анализе затрат-рисков и выгод, и важно знать, каковы ваши ценности перед внедрением или изменением системы.

Использование комбинации DNSBL на уровне почтового сервера / приложения и GEOIP на уровне сервера должно удалить для вас большую часть вашего спама, не прибегая к скорингу спама, быстрому положительному результату и т. Д.

Это особенно верно, если ваш почтовый сервер / компания получает электронную почту только от нескольких известных стран, таких как США, Канада.

Почтовый сервер Argosoft для Windows хорошо справляется с этой задачей, но я не знаю подобного решения на основе Linux. Вот почему я рекомендую использовать доверенный MTA в Linux (предпочтительно с DNSBL), а затем использовать решение GEOIP на уровне сервера.

Надеюсь это поможет.

Разве вам не лучше использовать что-то вроде черного списка Spamhaus ZEN ( http://www.spamhaus.org/zen/)? Это бесплатно, если трафик электронной почты вашей организации составляет менее 100 000 SMTP-соединений и 300 000 DNSBL-запросов в день.

Разумеется, их требования к использованию ( http://www.spamhaus.org/organization/dnsblusage.html) могут требовать подписки на фид данных, если вы используете намного больше ежедневного трафика электронной почты, но на этом уровне использования (читайте в порядке. напечатайте внизу страницы) вы, вероятно, не хотите административного бремени управления вашим собственным черным списком в любом случае.

Я использую Sendmail вместе с milter-greylist именно для этой цели в течение нескольких лет на нескольких средних почтовых серверах без каких-либо проблем. Легко настроить требуемые правила GeoIP, SPF, белого списка, DNSBL и т. Д. В greylist.conf для выборочного принудительного применения серого списка.

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

Может быть, тариф хорошо интегрирован со SpamAssassin, например?

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

Что касается реализации - есть несколько недорогих, коммерчески доступных баз данных гео-IP. Я был бы склонен объединить их "вручную" - так что вы можете, по крайней мере, позволить сообщению дойти до точки, где вы знаете пару получателей отправителя, для ведения журнала.

НТН,

Том

Это встроенное устройство, которое работает с маршрутизаторами и брандмауэрами, чтобы блокировать IP-трафик по странам и черные списки IP-адресов на линейной скорости. И Arclight верен, если вы не хотите допускать увеличения задержки и потери TCP-соединений, вам нужно специальное устройство, такое как IP Blocker, от TechGuard для обеспечения защиты скорости линии. TechGuard также только что опубликовал данные о влиянии ACL на маршрутизаторы и брандмауэры.