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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мог бы достигнуть хорошего результата интегрированный с SpamAssassin, например?

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

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

HTH,

Tom

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

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

From this research paper on SNARE, I present this nugget:

For ham, 90% of the messages travel about 4,000 km or less. On the other hand, for spam, only 28% of messages stay within this range.

My personal observations mirror yours and note that even now in 2014, geographic location continues to be an excellent predictor of spam. As others pointed out, GeoIP location (country or distance) alone is not a sufficiently reliable basis for blocking connections. However, combining GeoIP distance with a few other pieces of data about the connection, such as FCrDNS, HELO hostname validity, sender OS (via p0f), and SPF provides a 99.99% reliable basis (as in, a .01% chance of a FP) for rejecting 80% of connections before the DATA phase.

Unlike some SMTP tests (such as a DNSBL listing in zen.spamhaus.org) which have very low FP rates, none of the aforementioned tests individually are a sufficient basis for rejecting connections. Here's another pattern that falls into that category–-the envelope sender user matches the envelope recipient user. I've noticed that about 30% of spam follows this pattern: from: 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) тестов, мне интересно их услышать.