 |
|
|
|
Greylisting: панацея от спама или «мыльный пузырь»?
Greylisting: панацея от спама или «мыльный пузырь»? Хуже спама – только борьба со спамом.
Админская мудрость Проблема спама, несмотря на затрачиваемые усилия на борьбу с ним, не теряет своей остроты. Попытки покончить с ним всё больше похожи на попытки достичь горизонта – чем быстрее мы к нему движемся, тем быстрее он от нас отдаляется... Методов борьбы со спамом за последние годы разработано множество – от технических, таких как «чёрные списки», Байесовые классификаторы, комплексный анализ заголовков, до юридических, когда за рассылку спама предусматриваются всё более жестокие наказания вплоть до уголовной ответственности. Один из этих методов, получивший название «greylisting», или «серых списков», в последнее время приобретает всё большую популярность. Для удобства восприятия, я буду использовать транслитерированный термин «грейлистинг». На различных форумах всё чаще даётся совет настроить фильтрацию по «серым спискам» чуть ли не как окончательное решение любых проблем со спамом. Но так ли хорош этот метод на самом деле и достаточно ли у него сил, чтобы справиться с одной из серьёзнейших проблем современного Интернета? Идея «серых списков» Суть работы грейлистинга основана на предположении, что спамеры, осуществляя рассылку, далеко не всегда выполняют предусмотренные протоколом SMTP требования. В частности, этот протокол требует, чтобы при получении ответа с кодом 4xx, означающим временную проблему на сервере-получателе, сообщение помещалось в очередь отправителя, и спустя некоторое время предпринимались повторные попытки выполнить доставку. Очевидно, что для спамеров выполнение этого требования обойдётся слишком дорого в плане затрачиваемых ресурсов потребуется вести очередь сообщений, а учитывая, что в базах адресов, как правило, многие получатели уже не существуют, а то и вовсе не существовали, дисковое пространство для такой очереди и ресурсные затраты на её обработку будут неоправданно высоки. Конечно, в случае «лобовой атаки», когда все адреса указываются в одном письме, такой проблемы не возникнет. Но поскольку подобная рассылка – слишком лёгкая добыча для различных фильтров, то спамеры всё чаще вносят в рассылаемые сообщения случайные фрагменты. А это уже будет означать отдельное сообщение на каждого получателя. Безусловно, можно модифицировать программу рассылки, чтобы она не вела очередь, а просто помечала проблемные адреса и выполняла на них повторную отправку, но в любом случае для спамера это означает дополнительные трудозатраты. Как следствие многие спамеры просто игнорируют любые ошибки, в том числе и временные, продолжая отсылать сообщения дальше по своей базе. То есть если на первую попытку соединения возвращать код 4xx, то спамер его проигнорирует и оставит ваш сервер в покое (либо наоборот, если окажется очень настойчивым, будет непрерывно отправлять сообщения, не утруждая себя различными паузами). В то время как добропорядочный сервер, «выругавшись про себя», терпеливо положит письмо в очередь и чуть позже попытается ещё раз его отправить. На этом и основана фильтрация по «серым» спискам – «правильные» серверы будут предпринимать повторную попытку доставки спустя некоторое время (обычно это 30 минут или 1 час), а «неправильные» либо сделают повтор сразу же, либо не сделают вообще. Пример практической реализации Чтобы было понятнее, рассмотрим работу грейлистинга на конкретном примере. Для Sendmail существует программа milter-greylist. Её установка из портов FreeBSD труда не составит: root# cd /usr/ports/mail/milter-greylist root# make install Подправьте под свои требования конфигурационный файл /usr/local/etc/mail/greylist.conf. Я рекомендую здесь изменить значение параметра greylist на более доброжелательную по отношению к удалённым серверам цифру, например, на 15 минут. По умолчанию используется 1 час, что вынудит большинство серверов тщетно выполнять не одну, а две-три попытки отослать сообщение (а то и больше, если отправитель наивно надеется снизить латентность очереди и тем самым повысить качество обслуживания своих клиентов за счёт более частой обработки очереди), прежде чем ваш сервер снизойдёт до его рассмотрения. Впрочем, есть разумные соображения и по поводу используемого по умолчанию значения (см. врезку «Сколько можно ждать?!»), так что окончательное решение оставляю за вами. Также на первое время можно раскомментировать строку verbose, чтобы получать более полную информацию о работе фильтра. Ну и полезным будет дополнить представленный в конфигурационном файле список «белых» адресов теми серверами, с которых вы регулярно получаете «легальную» корреспонденцию. Это опять-таки некоторый «акт милосердия» по отношению к отправителям: acl whitelist domain donpac.ru acl whitelist domain rostel.ru acl whitelist domain mail.ru acl whitelist domain rambler.ru acl whitelist domain yandex.ru acl whitelist domain freebsd.org Туда же не забудьте добавить обслуживаемые вашим сервером подсети, чтобы клиенты не надоедали вам претензиями типа: «Я пытаюсь отправить письмо, а оно не уходит» или «Я отправил почту семь минут назад, а её до сих пор не получили». Ещё пропишите в /etc/rc.conf такую строку: miltergreylist_enable="YES" Теперь соответствующий демон будет запускаться сценарием /usr/local/etc/rc.d/milter-greylist.sh автоматически. Из текста этого же сценария можно узнать точный путь к сокету, который должен использовать Sendmail для взаимодействия с milter-greylist. Этот сокет и нужно указать в вашем mc-файле для настройки Sendmail: INPUT_MAIL_FILTER(`miltergreylist', `S=local:/var/milter-greylist/milter-greylist.sock, F=, T=S:4m;R:4m')dnl Теперь, пересобрав конфигурационный cf-файл и перезапустив Sendmail, вы получите работающий «серый» фильтр. В /var/log/maillog (если не менялись настройки по умолчанию демона Syslog) вы сможете отследить то, как этот фильтр работает:
Этот фрагмент демонстрирует, что первая попытка сервера mail.server.ru доставить почту для пользователя user завершилась задержкой сообщения на 5 минут. Спустя час сервер повторил свою попытку, за что был награждён правом находиться в «белом» списке 24 часа. Нужно сказать, что по умолчанию, чтобы попытка доставки была признана повторной, а не новой, с зафиксированными в базе должны совпасть три параметра – почтовый адрес отправителя, адрес получателя и IP-адрес хоста-отправителя. Использование конфигурационного параметра subnetmatch позволяет понизить требования к соответствию IP-адреса, признавая совпадающими все адреса, входящие в заданную подсеть. Это может быть полезно в том случае, если сервер-получатель использует FallbackMX для того, чтобы разгрузить очередь основного сервера, или если используется пул SMTP-серверов (т.е. в тех случаях, когда повторная отправка может предприниматься с другого хоста). Есть ещё один параметр – lazyaw, – активация которого приведёт к тому, что в автоматически формируемых «белых» списках будет учитываться только IP-адрес, а адреса получателя и отправителя приниматься во внимание не будут. Продолжим рассмотрение лог-файла. Так будет выглядеть подключение со стороны сервера, представленного в «белом» списке, т.е. в правилах acl whitelist:
Как видите, ему никаких препятствий в работе не создаётся. Ну и, наконец, для спамеров (к сожалению, не для всех) будет представлена только одна запись про «delayed for 00:05:00». Что и требовалось доказать. Плюсы грейлистинга Как показывает практика, значительную долю нежелательной почты действительно удаётся отсечь с помощью грейлистинга (см. врезку «Немного статистики»). При этом почтовый трафик может ощутимо снизиться, поскольку в отличие от различных статистических и сигнатурных анализаторов предварительный приём спамерского сообщения не осуществляется. В то же время грейлистинг практически полностью исключает ложные срабатывания, когда добропорядочное письмо блокируется фильтром и не попадает к адресату. Исключение может составить разве что случай, когда почтовый сервер отправителя по тем или иным причинам не вполне следует установленным стандартам. Но это, как говорится, не наши проблемы. Также отмечу сравнительную нетребовательность к ресурсам вашего сервера. Конечно, всё не так просто, как в случае «чёрных» списков на основе DNS, но по сравнению с тем же SpamAssassin грейлистинг может считаться очень простым и незатратным методом, поскольку требует анализа только конверта сообщения и ведения несложной базы, в которой будут фиксироваться состояния «триплетов» (IP-адрес, почтовый адрес отправителя, почтовый адрес получателя) – занесён ли этот триплет в «белый» список, была ли в недалёком прошлом попытка доставить такое же сообщение и т. д. Ну и ещё можно отметить «юридическую» чистоту этого метода. Если блокирование почты на основании DNSBL может вступить в противоречие с обязательством провайдера обеспечивать надёжную и бесперебойную работу обслуживаемой сети, а различные анализаторы при известной сноровке можно рассматривать как покушение на конституционное право пользователей на тайну их личной жизни (особенно если копии сообщений, признанных спамом, доставляются администратору или помещаются в общедоступный карантин), то грейлистинг не нарушает ни того ни другого, работая строго в соответствии с техническими требованиями. Поскольку любой сервер может при тех или иных обстоятельствах вернуть временную ошибку, то ничего криминального в этом нет. Минусы грейлистинга С другой стороны, грейлистинг при всей своей идеальности обладает и рядом отрицательных моментов. Прежде всего эта технология относится к «невежливым», поскольку вынуждает сервер отправителя тратить свои ресурсы на дополнительное обслуживание искусственно создаваемой очереди. Только представьте себе, что произойдет с сервером типа mail.ru, если каждое исходящее сообщение он будет вынужден ставить в очередь и отсылать повторно? Далее отправитель, получив временную ошибку, скорее всего попытается отправить сообщение на резервный сервер для вашего домена. Если Backup-сервер (т.е. хост с менее приоритетной MX-записью) у вас есть и он не включён в ваш «белый» список, то львиная доля нагрузки по обслуживанию очереди будет переложена на его плечи (в смысле на дисковую подсистему). И кстати говоря, ваш Backup-сервер наверняка будет скрупулёзно придерживаться протокола, так что любой спамер, додумавшийся использовать резервную MX-запись, может быть уверен, что его сообщение будет доставлено. Если же резервный сервер занести в «белый» список, то нагрузка на него, конечно же, значительно снизится. Но вот сам он станет прекрасным способом гарантированно доставить вам любое сообщение (впрочем, он его в любом случае доставит, как было показано выше). То есть, чтобы грейлистинг работал, все Backup-серверы тоже должны использовать эту технологию. А следовательно, нагрузка на отправителя возрастёт ещё больше, поскольку он будет не только держать сообщение в очереди, но и безнадёжно «ломиться» на несколько хостов, вместо того чтобы «успокоиться» после одной неудачной попытки. Рассмотренный выше milter-greylist позволяет настроить синхронизацию между различными MX-хостами (см. комментарии к опциям peer и syncaddr в конфигурационном файле, а также man greylist). Благодаря этому все настроенные таким образом почтовые серверы будут использовать общую базу. То есть отправитель, обратившийся на резервный хост после неудачной попытки пробиться на основной, уже будет известен Backup-серверу, и соответственно его обработают успешно. Правда, опять-таки сработает это лишь в том случае, если повторная попытка будет выполняться не сразу, а спустя некоторое время. Ну и к сожалению, не каждый администратор имеет полный доступ к настройке машин, определённых как Backup-серверы для его домена. Ещё одна проблема связана с серверами, на которых эксплуатируется «конкурирующая» система борьбы со спамом – так называемый обратный звонок (callback). Суть этого метода заключается в следующем: при получении входящего соединения сервер на стадии RCPT TO приостанавливает сессию и имитирует рабочую сессию с сервером, указанным в команде MAIL FROM. Если эта попытка из-за несуществующего адреса отправителя или по другим причинам завершается неудачей, то и приостановленное соединение разрывается без дальнейшей обработки. Нетрудно догадаться, что если вы будете использовать грейлистинг, то у вас наверняка возникнут проблемы с отправкой почты на серверы, где настроен callback: в ответ на ваше подключение удалённый сервер попытается установить с вами «встречное» соединение, а вы его отправите «попробовать немного позже». Кому от этого будет хуже – неизвестно. В нашем «наглядном пособии» – milter-greylist – эта проблема тоже известна, и для её решения предусмотрен ещё один параметр – delayedreject. При его активации milter-greylist будет возвращать ошибку 4xx не после команды RCPT TO, как это предусмотрено по умолчанию, а после получения команды DATA. Это вынуждает удалённый сервер надеяться на успех чуть дольше, но зато не создаёт препятствий для «обратного звонка», который, как правило, завершается после ответа сервера на команду RCPT TO. Ну и кто знает, как будут реагировать на ошибку 4хх службы «легальной» рассылки. Для них тоже не доставит удовольствия по полдня возиться с обработкой задержанных по тем или иным причинам сообщений. Прогнозы на будущее Можно сделать вывод, что грейлистинг при всех своих недостатках на данный момент – вполне эффективная технология. Но её эффективность определяется исключительно низкой распространённостью. Звучит парадоксально, но это так и есть – чем больше серверов станут использовать «серые» списки в своей практике, тем менее эффективной и более проблемной для законопослушных отправителей станет эта технология. Так, по мере распространения грейлистинга всё больше ресурсов будет тратиться на доставку почты. Хорошо, если ваши пользователи имеют ограниченный и регулярный список адресатов, большая часть которых будет постоянно присутствовать в «белом» списке, не влияя на эффективность работы. А если нет? Не исключено, что крупные почтовые провайдеры будут вынуждены устанавливать специальные Fallback-серверы исключительно для обслуживания «серой» почты, что естественно приведёт к удорожанию услуг или снижению их качества (впрочем, о каком качестве может идти речь, если каждое новое письмо в среднем будет задерживаться минут на сорок). Конечно, можно возразить, что «своя рубашка ближе к телу» и что дополнительные затраты на грейлистинг с лихвой компенсируются значительным снижением спам-трафика и нагрузки на оборудование, им создаваемой. Только вот действительно ли это снижение будет столь уж значительным? Ведь что требуется от спамера, чтобы с лёгкостью обойти грейлистинг? Всего-навсего через час провести повторную рассылку с теми же параметрами... И дальше пожинать плоды попадания в «белый» список. Даже не нужно ничего менять в программах рассылки. Так что как только грейлистинг станет серьёзной помехой для спамеров, он, как это ни странно прозвучит, вообще потеряет свою актуальность, лишившись большинства преимуществ, но сохранив все недостатки. Поэтому не стоит возлагать такие надежды на использование «серых» списков. И уж конечно же, не нужно всюду пропагандировать эту технологию – чем меньше людей о ней знают, тем больше преимуществ она принесёт лично вам. Ложка мёда Ну и немножко оптимизма напоследок. Да, сам по себе грейлистинг эффективен лишь в небольших дозах. Но в тандеме с такими методами, как сигнатурные анализаторы или «чёрные» списки на основе DNS, он может оказаться весьма полезен. Ведь он вынуждает спамеров делать задержку в своей рассылке, необходимую для того, чтобы обнаружить столь странную активность и занести их адреса или сигнатуры сообщений в соответствующие базы. А дальше, как говорится, дело техники. Так что будем надеяться, что когда-нибудь в наших почтовых ящиках будут «оседать» только действительно нужные нам письма. Приложение Сколько можно ждать?! По умолчанию для задержки сообщений рекомендуется использовать значение, равное 1 часу. Мне оно кажется слишком «невежливым», и потому я рекомендую его снизить. Впрочем, это лишь моё мнение. Вас же вполне могут убедить часто приводимые доводы в защиту именно этого значения:
Немного статистики Испытания milter-greylist на небольшом, но очень «боевом» почтовом сервере показали, что пользователи стали получать спама примерно в десять раз меньше, чем до внедрения этой системы (при том, что для обслуживания домена используется неподконтрольный мне Backup-сервер без грейлистинга). Показатели по вирусам ещё лучше – их число снизилось примерно в 30 раз (как правило, они автоматически рассылаются вирусами же, которые менее сообразительны, чем живые спамеры). Здесь учитывался лишь спам, источники которого не попали в DNSBL-списки, используемые на сервере (в первую очередь срабатывает блокировка по DNSBL, а затем уже выполняется проверка по greylist.db). Конечно, это не 99%, теоретически достижимые для тщательно настроенного (и регулярно подстраиваемого) SpamAssassin или DSPAM, но с учётом заметно более низкой нагрузки на сервер и отсутствия «сопутствующих» проблем выглядит эта технология весьма привлекательно. По крайней мере пока... Не «мильтером» единым... Упомянутый здесь инструмент, milter-greylist, не единственный. Существует масса фильтров и модулей к различным MTA, есть самостоятельные (не зависящие от конкретной почтовой программы) пакеты, такие как фильтр Spamd (см. журнал №7, 2005 г., http://www.samag.ru/cgi-bin/go.pl?q=articles;n=07.2005;a=05), работающий в паре с пакетным фильтром pf, или упомянутый в ссылках в конце статьи SMTP-прокси Spey. Некоторые из этих инструментов перечислены на страницах специализированного сайта, посвящённого пропаганде грейлистинга – http://greylisting.org. Впрочем, не забывайте, что если для лечения болезни существует огромный выбор различных препаратов, значит, болезнь неизлечима.
|
СЕРГЕЙ СУПРУНОВ
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
