Max Kostikov

Публичные чёрные и белые списки являются давно и широко используемой технологией в борьбе с рассылкой несанкционированной электронной почты или спамом. Наиболее распространённым вариантом таких списков являются так называемые DNSBL (они же RBL), когда доступ к информации предоставляется посредством особым способом оформленного DNS-запроса и ответа, на основании которого можно произвести оценку относится ли данный узел сети Интернет к добросовестным или, соответственно, наоборот отправителям электронной почты. Также к своего рода чёрным спискам, которые, в отличие от DNSBL, не используют систему DNS для доступа к данным, автор относит и службы оценки сообщений на основе контрольных сумм. Среди них наиболее известны Rhyolite DCC, Vipul's Razor и Pyzor. Неплохим подспорьем в оценке эффективности того или иного публичного списка может служить рейтинг Blacklist Monitor от немецкой компании Intra2net.

Max Kostikov

Вернуться к теме обучения антиспам-фильтров в Dovecot, которая ранее уже затрагивалась в одной из статей на этом сайте, меня заставило недавнее сообщение от всё помнящего "Charlie Root" прекращении поддержки широко используемого для этих нужд расширения Antispam plugin.

To: root@my.server
Subject: my.server weekly security run output
Message-Id: <E1dObLP-000MHX-25@my.server>
From: Charlie Root <root@my.server>
Date: Sat, 24 Jun 2017 05:02:43 +0200

Checking for packages with security vulnerabilities:
dovecot2-antispam-plugin-20130429_29: Tag: expiration_date Value: 2017-07-31
dovecot2-antispam-plugin-20130429_29: Tag: deprecated Value: Use pigeonhole instead. See https://wiki2.dovecot.org/HowTo/AntispamWithSieve

-- End of security output --

Greylisting используя Exim ratelimit

Greylisting using Exim ratelimit

Max Kostikov

Составление "серых списков" (greylising) отправителей электронной почты в том или ином виде и работа с ними в почтовых системах являются одной из популярных методик борьбы со спамом. Вкратце, её суть состоит в ограничении и / или откладывании приёма сообщения от подозрительных хостов.

Список этих хостов может формироваться на основании синтаксического разбора начальной сессии или, к примеру, на основании ранее накопленной статистики антиспам-подсистемы на данном сервере (см. статью "Использование статистики Spamassassin в конфигурации Exim"). Главным критерием при этом должно стать обеспечение беспрепятственной и быстрой доставки корреспонденции от хостов с хорошей репутацией и создание трудностей для тех отправителей, которые по принятым критериям потенциально (или реально) могут быть отнесены к рассыльщикам несанкционированной почты. При этом предпологается, то корректно настроенные серверы будут осуществлять повторную отправку через не слишком короткие, со временем увеличивающиеся интервалы, а спамеры будут пытаться осуществлять массированную отправку в кратчайшие сроки, стремясь накрыть как можно больший набор адресатов до момента блокировки и / или включения в общедоступные списки оценки саммеров, такие как DNSBL и на базе контрольных сумм.

Max Kostikov

Тема особенностей использования Domain-based Message Authentication, Reporting and Conformance или DMARC уже затрагивалась в рамках этого блога. Теперь хотелось бы остановиться на уже упомянутой в статье "DMARC для борьбы со спам на локальном и глобальном фронтах" особенностью обработки DMARC связанной с использованием возможности постепенного введения в действие политик типа quarantine и reject через использование их процентного модификатора.

К примеру, для отправителей из домена kostikov.co в соответствующей DMARC DNS-записи мы имеем следующее описание.

root@beta:~ # host -t txt _dmarc.kostikov.co
_dmarc.kostikov.co descriptive text "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-rua@kostikov.co"
Max Kostikov

В предыдущей статье "Подсистема оценки репутации антиспам пакета Spamassassin", помимо отражённых в заголовке, были затронуты вопросы того, как антиспам пакет Spamassassin накапливает и хранит данные об отправителях сообщений.

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

Итак, рассмотрим пример использования данного подхода на базе использования его при конфигурировании Exim.

Подсистема оценки репутации антиспам пакета Spamassassin

Spamassassin's anit-spam software reputatin scoring subsystem

Max Kostikov

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

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

Spamassassin включает в себя два модуля для оценки репутации - старый используемый по умолчанию в стандартной конфигурации AWL и новый TxRep.

Max Kostikov

В ходе попытки разобраться с одной из проблем коллеги всплыл интересный момент связанный с работой модуля проверки DKIM в пакете защиты от спама Spamassassin.

В расшифровке начисления Spamassassin баллов входящему письму была замечена строка T_DKIM_INVALID DKIM Signature header exists but is not valid. Несмотря на то, что DKIM подпись у письма была и была корректной, о чём можно было сделать вывод, например, из лога Exim.

Max Kostikov

Возможно, да и наверняка, кому-то будет полезный мой опыт настройки защиты против всевозможных bruteforce'ров и spam'еров посредством использования популярного fail2ban отличным от использования firewall путём - через TCP wrappers.

Подробнее о TCP wrappers я писать не буду, ибо желающие могут прочитать о них, например, в FreeBSD handbook. Хочу лишь сказать о причинах, побудивших меня использовать именно этот механизм ограничения доступа к интернет-сервисам.