Антиспамовые решения и безопасность, часть вторая

Др. Неал Краветз

1. Общий обзор

SMTP протокол не был разработан для обеспечения безопасности. Он был создан в 1973 году как расширение к FTP протоколу. [1]. В то время сетевая безопасность не вызывала особого беспокойства, и разработчики не были четко уверенны о необходимости внедрения отдельного почтового протокола. Например, в документации RFC 524 описывались основания для выделения SMTP в отдельный протокол. Автор предостерегал:

"Я уверен, что указанном протоколе, существуют дефекты, и надеюсь, что читатели, обнаружив их, укажут на них через RFC документацию".

Хотя набор команд для этого протокола был создан спустя некоторое время, его создатели предполагали, что к существующие недостатки протокола будут исправлены позже. Но, к сожалению, и 2004 году продолжают обращаться к оплошностям, допущенным в RFC 524, а протокол SMTP слишком популярен, чтобы полностью избавиться от него и заменить на более безопасный. Спам является одним из примеров злоумышленного использования протокола - большинство спамприложений разработано для подделки заголовков писем, маскирования отправителей и скрытия систем происхождения.

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

1.2 Терминология

• Отправитель. Человек или процесс, ответственный за генерирование электронной почты.
• Получатель. Любой e-mail адрес, получающий электронную почту.

2. Отклики

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

Существует два основных типа такого вида систем: отклик-отзыв и системы увеличения времени отправки.

1.2.1 Отклик-отзыв

Системы отклики-отзыва (CR системы) сохраняют список разрешенных отправителей. Электронное сообщение, посланное новым пользователем, временно блокируется. Такому отправителю отправиться сообщение, содержащее запрос на отклик (обычно щелчок на URL адресе или ответное сообщение). После завершения отклика новый отправитель добавляется в список разрешенных адресатов и после этого происходит доставка первоначального сообщения. Такие системы основаны на том, что спамеры используют поддельные адреса электронной почты и соответственно не смогут получить запрос на отклик, а спамеры, использующие реальные адреса просто не будут в состоянии ответить на запросы. Но, такие системы тоже имеют множество ограничений, включая:

• Взаимоблокировка в CR системе. К примеру, Алиса говорит Биллу послать сообщение её другу Чарли. Билл отсылает e-mail Чарли. CR система Чарли блокирует сообщение и отсылает Биллу запрос на отклик. Но CR система Билла, в свою очередь блокирует сообщение, посланное CR системой Чарли, и генерирует ответный запрос на отклик. Получается ситуация, что никто из пользователей не получит ни запроса на отклик ни электронного сообщения. А так как электронные сообщенияв большистве случаев неожиданны и незапрашиваемы, то пользователь не будет знать, что необходимо искать ожидающий решения отклик. По сути, если два человека используют CR систему, то у них не будет возможности связаться между собой.
• Автоматизированные системы. Рассылки и автоматизированные системы (типа "Отослать другу") не могут отвечать на запросы на отклик. Параметр "Вы можете вручную добавить отправителя", работает только, когда вы знаете, что должно прийти сообщение. Я часто получаю новости и статьи, которые мои друзья находят интересными и переправляют мне их из различных сайтов. Такие сообщения неожиданны и незапрашиваемы, но не являются спамом.
• Анализ запросов на отклик. Много CR систем осуществляют анализ запросов. Такие комплексные системы включают распознавание символов или сопоставление с шаблоном, которое может быть легко автоматизировано. Например, CR система, используемая Yahoo для создания новых адресов, легко уязвима даже самым простым системам искусственного интеллекта, выполняющим распознавание символов. CR система электронной почты Hushmail, требует определения пользователем изображения расположенного на синем фоне (анализируете фон, находите изображение, отсылаете координаты – и никаких проблем)

Рисунок 1. Запрос на отклик при создании новой учетной записи в системе Yahoo. Эта система уязвима к интеллектуальным программам, обеспечивающим распознавание символов.

Рисунок 2. Графическое генерирование отклика в системе Hushmail. Пользователь должен нажать на изображении замочной скважины. Такая система уязвима даже при простой обработке изображения.

Сейчас распространены два неправильных представления о CR системах: (1) пользователь должен подтвердить отклик, и (2), такие проблемы слишком сложны для автоматизированных решений. По правде говоря, спамеры игнорируют такие CR системы, потому что не они представляют собой слишком большие базы рассылок, а не потому что такие системы слишком сложны. Многие спамеры используют реальные адреса для своих махинаций или для проверки правильности списков рассылок. Когда CR системы начинают мешать рассылке спама, то спамеры автоматизируют ответы на запросы CR систем.

1.2.2 Дополнительные временные затраты.

Существует много систем, добавляющих дополнительное время к отправке электронного сообщения (СС систем). Большинство СС систем используют сложные алгоритмы, предназначенные для задержки времени при отправке. Для отдельного пользователя, это время вряд ли будет замечено, но при отправке миллионов писем, каждая маленькая задержка выльется в большие потери времени. Примером СС систем могут быть Hash Cash [2] и Microsoft Black Penny [3]. Но СС системы имеют проблемы, которые препятствуют их широкому распространению и вряд ли смогут предотвратить спам:

• Неравные условия. СС системы, основаны на быстродействии процессора, памяти или сети и ставят в невыгодное положение пользователей с медленными системами, перед более производительными системами. Например, отклик процессора на 1 Ггц системе, занимающий 10 секунд, займет 20 секунд на 500 Мгц компьютере.[4]
• Списки рассылок. Существует много списков рассылок, имеющих в своей базе тысячи и даже миллионы подписчиков, и все они будут наказаны так же сильно, как и спамеры. СС системы делают непрактичным создание рассылок. И если есть путь для обхода откликов для легальных списков, то спаммеры смогут точно также обойти необходимость формирования отклика.
• Армии роботов. Как мы уже могли видеть в случае с вирусом Sobig и другими вирусами спам-поддержки, много спамеров контролируют сотни тысяч взломанных систем. Спамеры могут легко распределять любые дополнительные задержки времени между "своими" системами.
• Легальные армии роботов. Спамеры генерируют спам, потому что это приносит существенный доход. Большие спам-группы могут позволить себе покупку сотен систем для распределения дополнительных затрат времени. Причем это может быть сделано легально, без взлома чьих-то систем с помощью вирусов.

Предлагаемые в настоящее время СС системы наврядли получат широкое распространение, т.к. они не только не уменьшают проблему спама, но даже мешают легальной отправке электронной почты.

1.3 Шифрование

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

AMTP.

MTP.

S/MIME и PGP/MIME.

Существующий почтовый протокол (SMTP) не имеет никакой явной поддержки зашифрованной идентификации. Некоторые из этих предложенных решений расширяют возможности SMTP протокола (например, S/MIME, PGP/MIME, и AMTP), в то время как другие нацелены на полную замену почтовой инфраструктуры (например, MTP). Интересно высказывание автора MTP: "Протоколу SMTP уже более 20 лет, тогда как современные требования развивались в течение прошедших 5-10 лет. Было показано большое количество дополнений к синтаксису и семантике SMTP, но чистый SMTP протокол не выполняет эти требования и является слишком неизменяемым, чтобы быть дополненным без модификации синтаксиса"[5].

При использовании сертификатов типа X.509 или TLS, должны быть доступны некоторые типы источников выдачи сертификатов. К сожалению, если сертификаты сохранены в DNS, тогда для проверки подлинности должны быть доступны секретные ключи. (А если спамер имеет доступ к секретным ключам, то он может генерировать правильные открытые ключи). Вариантом может быть использование централизованной системы выдачи сертификатов. Но, к сожалению, электронная почта является распределенной системой, и навряд ли кто-то захочет иметь единственный центр сертификации для управления всей электронной почтой.

Когда нет никаких источников выдачи сертификатов, то должен быть какой-нибудь метод для распределения ключей между отправителем и получателем. PGP, например, требует наличия общедоступных открытых ключей. Такой метод эффективен в закрытых сетях и между группами хорошо знакомых людей и неэффективен в больших группах пользователей, особенно когда новые контакты могут быть установлены между любым отправителем и любым получателем. По существу общедоступные ключи сталкиваются с теми же проблемами, что и "белые списки" - только известные и установленные отправители могут войти в контакт с получателем.

К сожалению, эти криптографические системы, вряд ли, остановят спам. Например, давайте предположим, что одно из таких решений было повсеместно применено. При таком подходе не проверяется правильность адреса отправителя, а только проверяется, имел ли отправитель правильные ключи для электронной почты. Все это создает несколько, перечисленных ниже, проблем:

• Автоматизированный взлом. При глобальном применении данных систем, должен быть способ генерирования сертификатов или ключей для всех пользователей (почтовые серверы или почтовые клиенты, в зависимости от выбранного решения). Но реальнее всего предположить, что спамер взломает такую систему через неделю, после её развертывания и после этого будет её использовать для отсылки "заверенного" спама.
• Проблемы в практичности применения. Существуют также некоторые беспокойства в практичности таких систем. Например, что произойдет, если будет недоступен сервер выдачи сертификатов? Передача электронной почты была бы сорвана или вся почта принималась бы как "заверенная"? Недавно спамеры провели длительную DDos атаку на почти полдюжины сайтов, поддерживающих "черные списки"[7]. Понятно, что спамеры нападали на эти сервера, чтобы воспрепятствовать пользователям получать обновления "черных списков". Но наивно предполагать, что одиночный сервер выдачи сертификатов (или даже сеть таких серверов) не будет восприимчивы к подобным нападениям.

Итоги обсуждения различных антиспамных решений

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

В первой части этой статьи мы увидели, что спамфильтры будучи эффективными для идентификации спама, в тоже время не могут бороться его распространением, и требуют постоянного обслуживания. Системы обратного поиска пытаются идентифицировать подделанные адреса отправителей, но при этом препятствуют пользователям host-less и доменов третьего уровня, а также ограничивают возможности пользователей мобильных компьютеров, мешая им отправлять электронную почту с любого, удобного для них места. Во второй части мы обратили наше внимание на системы откликов и системы задержки времени, и пришли к выводу, что они эффективны только при небольшом распространении и вряд ли смогут сдерживать спам. Криптографические решения, точно идентифицируя подделанную электронную почту, не могут расширяться в глобальных масштабах.

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

Ссылки

[1] RFC 458 (Feb. 20, 1973): Mail retrieval via FTP. RFC 510 (May 30, 1973): Network mailbox addresses (user@system). RFC 524 (June 13, 1973): Branching from FTP to a standalone protocol. RFC 561 (Sept. 5, 1973): Standard mail headers.

[2] Source: http://www.cypherspace.org/adam/hashcash/.

[3] Source: http://groups.yahoo.com/local/service-spamguard.html.

[4] The delay is actually more than double due to operating system overhead.

[5] Source: http://www.ietf.org/internet-drafts/draft-danisch-email-mtp-00.txt.

[6] Source: Nua Internet How Many Online http://www.nua.ie/surveys/how_many_online/index.html, 5-February-2004.

[7] Source: "Virus and dDoS Attacks on Spamhaus", http://www.spamhaus.org/cyberattacks/index.html.