«серые списки» — новый метод борьбы со спамом
Очевидно, что правильнее всего бороться со спамом на стороне сервера, то есть SMTP-релея, а не на стороне клиента, настраивая фильтры в почтовой читалке. Выгода очевидна — экономия трафика и бОльшая точность работы в первом случае, чем во втором.
Наиболее распространенные и простые методы борьбы со спамом имеющиеся сегодня, вроде составления черных и белых списков, являются негибкими. Черные списки легко обходятся сменой почтовых адресов и использованием альтернативных серверов, а белые списки не дают принимать почту с адресов, не разрешенных пользователем. Однако существует ряд более удачных техник с использованием блэк-листов, фильтрации по user-agentу и др. Спамеры применяют некоторые хитрые методы, типа добавления мусора в текст, или добавления html-тегов, не влияющих на отображаемый текст, или передачу информации в виде рисунков. Все эти и многие другие хитрости призваны вводить в заблуждение антиспамерские системы, работающие по принципу анализа содержимого сообщения. Но и развитие таких систем и алгоритмов происходит очень активно. Поэтому применение специализированных пакетов типа spamassassin, spamoracle или bogofilter крайне рекомендуется и неоднократно описывалось. Результатом озабоченности проблемой является возникновение все новых и новых аналитических методов борьбы со спамом. Например, в России тоже не стоят на месте — убедится в этом можно на сайте www.antispam.ru. А применение www.spamtest.ru позволяет однозначно выделять спам, и что самое приятное — переложить эту задачу на других.
Одним из таких перспективных методов является метод "серых списков", предложенный Эваном Гаррисом. Свое название метод получил из-за того, что он является промежуточным между методами черных и белых списков. Важным достоинством метода является то, что он почти не требует вмешательства пользователя и не отнимает больших ресурсов серверной системы. Не менее важно и то, что система практически не имеет ложных срабатываний.
Идея метода похожа на ряд уже имеющихся систем, которые направляют запросы неизвестным отправителям, требуя подтвердить намерение отправить письмо. Однако человек в этом процессе не участвует, и все взаимодействие происходит на уровне общения MTA-агентов. Почему это работает, как это работает, какие есть техники у спамеров, и как с ними справляется фильтр можно прочитать по ссылке http://projects.puremagic.com/greylisting/ Там-же можно взять сам фильтр и детали по его конфигурации. Поддержка фильтра для postfix тоже уже реализована, но в настоящий момент наиболее успешно эксплуатируется фильтр для sendmail.
Рассмотрим подробнее предлагаемую конфигурацию.
После установки фильтра, сервер выполняет следующую цепочку передачи данных:
sendmail — libmilter — perl_milter — perl — graylist_filter — perl_DBI — DBD_MySQL — MySQL и обратно. Причем, если принимается решение о необходимости доставки, могут срабатывать другие мильтер-фильтры, например антивирусная защита. Современные антивирусы для серверных MTA как правило сами имеют несколько простых антиспам-фильтров, типа reject для undisclosed recipient или mass sender. Не смотря на использование MySQL и сложной цепочки передачи данных от MTA к базе, нагрузка на систему и CPU очень невелика.
Оперирование производится триплетами — IP адрес релэя, @ сендера, @ рецепиента. Когда поступит новое (по триплету) для базы письмо, сервер говорит удаленной стороне TEMPFAIL в течение 58 минут. То есть письмо не доходит. По прошествии этого времени, открывается 4-часовое окно, в течение которого база ждет подтверждения триплета (повторной передачи письма).
Если триплет не подтверждается, запись удаляется из базы. То-есть наш сервер надо уговорить принять почту. Теоретически некто, посылающий напрямую (без релея) на наш сервер почту раз в пять часов (или релэй с ETRN=5ч.), может никогда ее не доставить. Но такая ситуация почти невероятна, так как релеи всегда делают ретрансмиссию по таймауту, а напрямую человек (спамер) устанет слать письма именно с такой периодичностью. Кроме того, фильтр имеет функции проверки почтового клиента в случае отправки напрямую. Даже если такая ситуация возникнет, есть белый список для ее обхода.
Если триплет подтверждается (resend or other mail), фильтр заносит триплет в белый список на 36 дней. Разумеется, все таймауты можно изменить на свое усмотрение. Кроме того, существует список рассылки, в котором люди обсуждают эти таймауты и тонкости настройки. В результате обсуждений, в последней версии фильтра таймауты отличаются от приведенных в статье.
Локальные сети прописываются в "пожизненный" белый список. Это означает, что наши клиенты могут спамить без проблем ;-). То есть почта, отправляемая от нас, никогда не будет задерживаться.
После запуска, база набирает валидные триплеты, по которым будут пропускаться задержки. По ним будут проходить в том числе и urgent-письма, не терпящие задержек. Очевидно, что врядли кто-то будет слать urgent и больше ничего раз в два месяца.
В качестве обоснования выбранных по умолчанию таймаутов можно назвать следующие причины:
Задержку в 58 минут не имеет смысла уменьшать, потому что:
1. Час задержки не заметит большинство пользователей и ни один почтовый сервер. Для пользователей — это происходит только первый раз для триплета. Далее задержек не будет. Для серверов — инсталляции по умолчанию сконфигурированы таким образом, что делают попытки ретрансмиссии в течение 5-7 дней! О каком часе речь?
2. Если релэй взломан, час необходим админу для обнаружения и решения этой проблемы. Если это сознательный спамерский открытый релей, час необходим чтобы кто-то занес его в блэклисты. Подчеркну, что graylisting не удаляет почту, а только задерживает ее. То есть, если спамер будет очень настойчивым, он таки "уговорит" наш MTA принимать спам. То-есть мы примем рано или поздно все, что нам послали, если оно будет посылаться с чьего-то релея вновь и вновь. Чтобы однозначно отвергать спам, сервер должен параллельно использовать другие техники, названные выше. Проще всего использовать проверку по блэклистам + антивирусную защиту. Ниже я приведу примерную конфигурацию блэклистов для sendmail.
3. Задерживаемая почта может иметь разные envelops в случае listservers, поэтому часовая задержка является оптимальной для серверов подписок, т.к. это не критичная почта. Впрочем эта ситуация редка, subscribe.ru, например, к ней не относится.
4. Часовая задержка необходима, чтобы обломать спамерский софт, который попытается обойти graylisting.
5. Если ее снизить хотя бы в два раза, эффективность защиты упадет, а особого толку не будет. Хотя надо признать, что основная защита осуществляется в первые минуты, так как у спамеров в основном действует принцип — "послал и забыл".
6. Стандартная установка sendmail и других MTA подразумевает попытку ретрансмисии раз в час, иногда полчаса. Такая настройка характерна для подавляющего большинства MTA в Интернет. Поэтому за таймаут в 58 минут на второй раз почта пройдет. Спамерский софт или испуганный юзер может долбить и долбить. Час нужен чтобы охладить пыл. Из этого правила есть одно досадное исключение — tut.by. Если вы получаете много почты с tut, то, при использовании graylisting, некоторые письма могут не доходить. Как вариант — закатать весь этот домен в белый список, и ловить спам с него другими методами.
Четырехчасовое окно определено опытным путем на основе шестимесячной эксплуатации фильтра и дебатов в списке рассылки на эту тему. Делать его бОльшим опасно, т.к. спамер может возобновлять активность через 5-8 часов, имитируя рабочий день. Делать его меньше — увеличится процент задерживаемой полезной почты.
36-дневный белый список гарантирует прохождение почты, которая идет один раз в месяц, с запасом. При этом удаляются старинные записи, что обеспечивает ротацию базы. Повторю, что пока почта по триплету идет, запись в базе обновляется и висит в белом списке без удаления. Удаляются только записи о том, что почта прошла по триплету пару раз и уже больше месяца не ходит, и устаревшие not whitelisted записи.
Анализ эффективности по результатам тестирования в течение 6 недель утверждает, что было задержано только 4% полезной корреспонденции, не считая списков рассылок. Конечно, основная их масса приходится на начало формирования базы валидных триплетов, т.е. сразу после ее запуска. В течение некоторого короткого времени она начнет содержать только актуальные триплеты, и новые задержки будут происходить редко. Там-же приводятся ОЧЕНЬ впечатляющие цифры экономии трафика.
Можно по крону освобождать базу от expired records и оптимизировать ее. В процессе оптимизации создается копия рабочей таблицы. Если фильтр не запущен, sendmail благополучно его не замечает. Если фильтр не видит MySQL, он всем рассылает TEMPFAIL (это можно изменить). Поэтому надо мониторить жизнедеятельность базы. Файл dbdef.sql не используется, однако он описывает структуру базы, некоторые интересные запросы к ней и процедуру добавления в белый лист. Добавлять в белый список следует в случае, когда клиент обратится с конкретной просьбой на конкретный relay или почтовый адрес. Если он не знает чего хочет — можно разъяснить политику защиты от спама, предложить просто подождать, пообещать что такого больше не будет, сослаться на проблемы в сети, предложить не пользоваться нашим сервером, придумать другие варианты. :-)
Андрей Горев, вед. инженер, Авилинк ISP.
Сетевые решения. Статья была опубликована в номере 02 за 2004 год в рубрике sysadmin
