Спам, передаваемый по электронной почте, стал настоящим проклятием Internet. Некоторые специалисты всерьез полагают, что если не предпринять срочных мер, то лет через пять Internet превратится в «помойку».
Письма с коммерческой рекламой, с посулами крупных и быстрых денег, послания с вирусами, подложные письма заполонили почтовые ящики. За примерами далеко ходить не надо: из сотни полученных мною за обычный рабочий день писем меньше десяти оказались по делу.
Разумеется, на каждое действие находится противодействие, и сейчас повсеместно применяются самые разнообразные методы борьбы со спамом. Но, к сожалению, они либо не слишком эффективны, поскольку рассчитаны на сдерживание спамеров-дилетантов, либо препятствуют работе «законопослушных» пользователей.
В этой статье мне хотелось бы показать, что, по большому счету, борьба с этим злом — занятие неблагодарное и малоперспективное. Проблемы спама вызваны, во-первых, малыми затратами на пересылку электронной почты, во-вторых, техническим несовершенством принятой почтовой модели и, в-третьих, чрезмерной гибкостью протокола SMTP. В общем случае SMTP позволяет отправлять сообщения любого содержания от имени кого угодно кому угодно, да еще с передачей в третьи руки.
Недостатки модели почтовой системы Internet в целом и протокола SMTP в частности неустранимы, если только не пересмотреть всю нормативную базу, связанную с электронной почтой. Для того чтобы воспользоваться недостатками SMTP, не надо быть семи пядей во лбу, достаточно самых элементарных знаний.
НЕМНОГО О ТЕРМИНОЛОГИИ
Классификации спама посвящена масса статей и документов. С моей точки зрения, спам — это все те почтовые отправления в адрес пользователя, на которые он не подписывался и не желал бы получать. Помимо уже надоевшей рекламы, предложений способов быстрого обогащения, писем счастья/несчастья, наподобие «разошлите это письмо 20 своим знакомым, иначе...», сюда следует отнести почтовые вирусы. Этот вид спама очень быстро развивается, заявив о себе как о преобладающей тенденции в «вирусологии». Так, издательство «Открытые системы» за последние полгода подвергалось вирусным атакам около 6000 раз, причем 98% из них осуществлялось по почте. Кстати сказать, в отличие от прочих, послания с вирусами в большинстве своем инициируются не спамерами, а невинными жертвами уже зараженных компьютеров.
К спаму, притом самому страшному и опасному, относятся подложные письма, когда злоумышленник от чужого имени шлет послания третьим лицам. Недавно я получил несколько писем от возмущенных сограждан, из которых выяснилось, что кто-то отправлял послания с моим обратным адресом, предлагая вступить в «Московский клуб группового секса».
Но это еще цветочки. Гораздо неприятнее другой случай. Некто от имени президента нашего издательства (с его настоящими реквизитами и адресом) распространил среди партнеров издательства письмо, где, скажем так, некорректно выражался о деятельности издательства. К сожалению, SMTP позволяет с легкостью проделывать подобные трюки.
Теперь представьте, что кто-то от вашего лица послал вашему начальнику письмо с хамским содержанием. Поверьте, оправдаться будет нелегко. А если тот промолчит (и тогда даже не будет шанса выявить факт подлога) и просто возьмет на заметку ваше мнение о нем? Ведь не все осведомлены о «богатых» возможностях SMTP.
Условно можно выделить такое понятие, как вторичный спам. Некоторые почтовые вирусы используют подложные обратные адреса (в том числе и реально существующие), между тем как большинство почтовых антивирусных программ отсылает «отправителю» сообщение об обнаруженном вирусе. Подобный спам вводит в нервное возбуждение «отправителя», который в экстренном порядке начинает поиск вируса.
Еще один вид спама может порождаться почтовыми системами, где предусмотрена возможность автоматического ответа на почтовые сообщения. Например, пользователь Иванов уходит в отпуск и активизирует процедуру, которая при поступлении нового сообщения посылает отправителю послание вида «Ваше письмо получено и будет обработано. Но, к сожалению, я в отпуске».
Руководящие документы Internet (см. RFC 2505) настоятельно призывают не задействовать такие системы. И вот почему. Если, уходя в отпуск, Петров инициализировал систему автоматического ответа, а затем послал письмо Иванову, то почтовые системы начинают обмениваться сообщениями о том, что адресаты в отпуске. Эти письма, если не предпринять специальных мер, не только переполнят ящики Иванова и Петрова, но и вызовут серьезную нагрузку на почтовые серверы и линии связи. Даже если Петров не пошлет начального сообщения Иванову, такое письмо Иванову от имени Петрова может отправить злоумышленник. Подобной опасности потенциально подвержены любые почтовые системы, автоматически отвечающие на послания без анализа их содержимого.
КАК РАБОТАЕТ ПОЧТА
Прежде чем более конкретно говорить о несовершенстве почтовой системы Internet, рассмотрим типичную схему работы электронной почты (см. Рисунок). Пусть пользователь Петров с почтовым адресом petrov@a.ru посылает сообщение Иванову (адрес ivanov@z.ru) с таким текстом (используем английский для простоты):
Subject: Test Hello, how are you?
При этом Петров использует популярную программу Microsoft Outlook Express (OE), предварительно настроив ее следующим образом:
Имя: Peter Petrov Адрес: petrov@a.ru Сервер исходящей почты (SMTP): source.a.ru IP-адрес компьютера Петрова - 123.45.67.89 доменное имя - petrov.a.ru.
В свою очередь Иванов также пользуется Outlook Express, установив свои параметры:
Имя: Ivan Ivanov Адрес: ivanov@z.ru Сервер входящей почты (POP3): target.z.ru
Остальные параметры Иванова и Петрова для нас сейчас не существенны.
Пусть на сервере source.a.ru (IP-адрес 123.45.67.1) установлен сервис Microsoft SMTP, который по умолчанию входит в комплект Windows 2000 Server и задействуется почтовой системой Microsoft Exchange 2000. А на сервере target.z.ru (IP-адрес 199.99.99.99) установлен Linux с почтовыми программами sendmail и gnu-pop3d: первая из них реализует службу SMTP, а вторая — POP3. Впрочем, все это не суть важно, поскольку почта работает схожим образом и на других системах. Но нам нужна отправная точка.
В электронной почте Internet приняты термины «почтовый пользовательский агент» (Mail User Agent, MUA) и «почтовый транспортный агент» (Mail Transport Agent, MTA). MUA — это обычная клиентская программа, она отвечает за создание (прием) почтового сообщения, при этом передача (прием) сообщения осуществляется через MTA. В нашем случае в качестве MUA выступает Outlook Express. В свою очередь, MTA пересылает сообщения по Internet с помощью протокола SMTP и имеет развитые возможности работы сразу со множеством сообщений. В рассматриваемом примере в роли MTA выступают Microsoft SMTP и sendmail.
Любое электронное письмо состоит из двух частей: заголовков (headers) и тела (body). Заголовки располагаются в начале письма и отделены от тела пустой строкой. На Листинге 1 показано, как выглядит письмо в момент его отправки (заголовка Received: на самом деле не будет, поскольку его вставит сервер source.a.ru, но об этом чуть ниже).
Заголовки, начинающиеся с символов X-, не регламентируются стандартами и называются свободными (user-defined). Они служат для вспомогательных целей, в частности для идентификации клиентской программы.
Остальные заголовки в Листинге 1 самоочевидны (впрочем, сюда не вошло еще несколько интересных заголовков). Отметим, что заголовки From: и To: заполняются клиентской программой. Для рассылки копий используются Cc: и Bcc:, а Reply-To: указывает адрес, на который должны идти ответы. Он часто применяется, когда пользователь отправляет письмо не со своего рабочего места. Более подробную информацию о заголовках можно найти в руководящих документах RFC 2821 и RFC 2822.
В Outlook Express, как и во многие другие MUA, встроен клиент SMTP, правда, с ограниченными возможностями. OE пользователя Петрова соединяется с хостом source.a.ru, являющимся сервером SMTP, и передает ему письмо.
В свою очередь, по получении письма source.a.ru добавляет в сообщение заголовок Received:, после чего письмо принимает в точности такой вид, как на Листинге 1. В данном случае заголовок описывает, что хост source.a.ru, на котором установлен Microsoft SMTP, получил сообщение от хоста petrov.a.ru (IP-адрес 123.45.67.89) такого-то числа в такое-то время. Во время путешествия письма по Internet каждый MTA, через который проходит сообщение, добавляет в него свой заголовок Received:.
Теперь подробно рассмотрим процедуру установления соединения и переговоры между source.a.ru и target.z.ru (процедура связи между petrov.a.ru и source.a.ru происходит похожим образом, но она менее информативна, так как IP-адрес сервера SMTP был заранее известен). Сервер source.a.ru знает адрес электронной почты получателя (ivanov@z.ru), но ему надо определить, куда конкретно (по какому IP-адресу) посылать письмо. Для этого source.a.ru выделяет из адреса получателя электронного письма доменную часть (z.ru) и посылает запрос серверу DNS примерно такого содержания (в переводе с машинного языка на человеческий): «Требуется узнать записи MX для домена z.ru». Записи MX (Mail eXchanger) в доменной системе используются для обозначения почтовых серверов, обслуживающих домен. Не вдаваясь в детали, скажем только, что для одного домена может быть несколько записей MX, для каждой из которых администратор назначает приоритет.
Допустим, сервер DNS ответил на запрос таким образом:
«Для домена z.ru записи MX имеют следующие хосты:
target.z.ru (IP-адрес 199.99.99.99) с приоритетом 10 vol.z.ru (IP-адрес 199.99.99.98) с приоритетом 20"
Приоритет почтового сервера тем выше, чем меньше номер. Поэтому source.a.ru, в первую очередь, попытается связаться с target.z.ru и, только если он не ответит, обратится к vol.z.ru. Бывает и так, что администратор не использует записи MX. В таком случае хост source.a.ru попробует установить соединение с сервером z.ru.
Допустим, target.z.ru функционирует и подключен к Internet. Тогда source.a.ru соединяется с портом 25 (через который работает сервер SMTP) по транспортному протоколу TCP. В этом соединении source.a.ru выступает клиентом SMTP, а target.z.ru — сервером. Протокол SMTP удивительно прост и довольствуется всего десятью командами, а для наших примеров потребуется и того меньше. Поэтому нелишне рассмотреть процесс переговоров между source.a.ru и target.z.ru (см. Листинг 2).
Ответы target.z.ru всегда начинаются с трехзначного числа, значение которого идентифицирует факт выполнения/невыполнения команд. В первой строке сервер target.z.ru сообщает данные о своем почтовом сервисе. Следующая строка — команда HELO, в которой source.a.ru идентифицирует себя. В ответ сервер target.z.ru сообщает собственную информацию. Часто HELO заменяет команда EHLO; она имеет тот же смысл, но разрешает использование расширения SMTP. Посредством команды MAIL хост source.a.ru информирует о почтовом адресе отправителя, а с помощью команды RCPT сообщает почтовый адрес получателя. Непосредственно текст письма, включая заголовки и тело, передается командой DATA. Факт окончания передачи текста письма обозначается точкой, стоящей на отдельной строке. Завершение сеанса связи хост source.a.ru осуществляет командой QUIT.
Команды HELO (EHLO), MAIL и RCPT формируют то, что принято называть конвертом письма. Например, именно командой RCPT задается реальный получатель письма, и он может не совпадать с тем, что указано в заголовках To:, Cc: или Bcc:. Содержимое письма (т. е. то, что передается командой DATA) MTA вообще никак не контролирует.
После получения письма target.z.ru добавляет несколько новых заголовков, в результате оно принимает вид, как в Листинге 3. Прежде всего, это заголовок Received:. Имя хоста, от которого получено сообщение (в нашем случае, source.a.ru), берется из конверта от команды HELO/EHLO, а адрес получателя — из команды RCPT (некоторые MTA не указывают адрес получателя в заголовке Received: по соображениям безопасности).
Кроме того, сервер target.z.ru добавляет в начало письма заголовок From, он носит название «отправитель конверта» и вставляется исключительно на конечном сервере SMTP. Обратите внимание, что «отправитель конверта» отличается от обычного заголовка From: отсутствием двоеточия. Информация в заголовок «Отправитель конверта» помещается из команды MAIL протокола SMTP. Назначение заголовка «Отправитель конверта» состоит в отделении писем друг от друга, когда они находятся в одном почтовом ящике.
Далее, с помощью протокола POP3 пользователь Иванов считывает свое письмо с сервера target.z.ru. Обычно при этом заголовок «Отправитель конверта» не передается на клиентскую машину. По умолчанию Иванов в Outlook Express увидит только тело письма, для того чтобы ознакомиться с заголовками он должен вызвать для письма «Свойства» (Properties) —> «Подробно» (Details).
Протокол SMTP очень гибок с точки зрения возможности транспортировки почтовой корреспонденции. Помимо передачи писем напрямую между двумя конечными MTA, он позволяет использовать эстафетную передачу сообщений (Relay), когда письмо сначала передается на промежуточный (промежуточные) MTA и лишь затем на конечный MTA. Это удобный сервис для больших компаний со множеством филиалов. Допустим, компания ACME имеет несколько отделений и филиалов, но хочет для всех своих сотрудников поддерживать общее доменное имя @acme.com. Тогда она организует единый сервер входящей почты, а он уже распределяет далее почту по почтовым серверам подразделений.
К сожалению, именно эстафетная передача лежит в основе трудно распознаваемого спама. Для этого нередко применяется технология открытой эстафетной передачи (Open Relay). В правильно настроенной почтовой системе отправление почты должно осуществляться только с компьютеров, входящих в состав организации. Принимать же почту система может лишь для внутренних получателей. Например, сервер source.a.ru обязан передавать почту наружу от petrov.a.ru, но ни как не от sidorov.b.ru. В то же время, сервер target.z.ru должен принимать почту исключительно для своих пользователей @z.ru, а не для некоего sidorov@b.ru. Кстати говоря, Петров мог бы в своем Outlook Express указать в качестве сервера SMTP машину target.z.ru и передавать письма Иванову напрямую, минуя source.a.ru. Безусловно, это возможно, если в организации a.ru не установлен межсетевой экран (firewall). Но Петров не сможет тогда передавать письма в другие домены, включая свой собственный.
Открытая эстафетная передача подразумевает то, что почта передается от кого угодно кому угодно. Обычно серверы Open Relay появляются либо из-за некомпетентности администраторов, либо организуются специально для целей спама. Кроме того, определенная группа компьютерных специалистов намеренно устанавливает серверы Open Relay, поскольку они пропагандируют идеи «свободы слова» и «защиты анонимности личности» в Internet.
Ко всему прочему, сервис SMTP позволяет в поле адреса получателя почты задавать цепочку серверов, через которые должна передаваться почта, а не только конечный адрес.
ТЕХНОЛОГИЯ ПОДЛОГА
Те, кто внимательно проанализировал приведенный выше пример, могут отметить, что для Иванова действительно подлинной и несомненной информацией является то, что сервер target.z.ru получил послание от хоста с IP-адресом 123.45.67.1. То есть он может доверять только самому последнему (верхнему в Листинге 3) заголовку Received:. Все остальное может быть подлогом! Если же внутри домена z.ru имела место эстафетная передача, то получатель может доверять и другим заголовкам Received:, но только тем, что сгенерировали серверы, расположенные в сети z.ru.
Давайте теперь рассмотрим технологию подмены на конкретном примере, не самом сложном, но и не совсем тривиальном. Допустим, сидя за компьютером 212.188.21.17 с Windows 2000, кому-то захотелось послать сообщение якобы от главы Microsoft Билла Гейтса Президенту России В.В. Путину, но так, чтобы письмо попало по адресу admin@opensystems.ru. Заранее позаботимся, чтобы данный компьютер не значился в DNS-зоне in-addr.arpa, т. е. чтобы по его IP-адресу нельзя было установить доменное имя. Сначала необходимо выявить почтовый сервер домена opensystems.ru, т. е. записи MX этого домена. Проще всего это можно сделать с помощью программы nslookup, входящей в комплект многих ОС. Оказывается, что почтовый сервер домена opensystems.ru (запись MX) — nserv.osp.ru.
Далее, используя обычную программу telnet, подключаемся к порту 25 сервера nserv.osp.ru. В Листинге 4 представлен процесс пересылки почты. Все команды и само письмо набираются вручную, хотя процедуру можно легко автоматизировать. Обратите внимание: в telnet задан параметр LOCAL_ECHO для отображения на экране вводимого текста.
Что касается непосредственно SMTP, то команда HELO позволяет представиться как fw.microsoft.com (т. е. машина 212.188.21.17 объявляется под этим доменным именем). В команде MAIL сообщается, что письмо идет от Билла Гейтса (Bill.Gates@microsoft.com); командой RCPT задается настоящий получатель письма (admin@ opensystems.ru), а затем с помощью команды DATA передается само подложное письмо. Для того чтобы запутать следы, в начало письма добавляется несколько заголовков Received:, указывающих на настоящие серверы Microsoft (кроме fw.microsoft.com), как будто письмо уже прошло ряд почтовых серверов. Посредством остальных заголовков создается видимость, что сообщение было создано в Outlook Express 6. Главное — согласовать временные отметки в разных заголовках, при этом необходимо учитывать часовые пояса и то обстоятельство, что почтовое сообщение не могло где-то застрять на полгода или даже на неделю.
В итоге пользователь admin@opensystems.ru получит письмо, как это представлено в Листинге 5. Он сможет однозначно утверждать лишь то, что письмо пришло с адреса 212.188.21.17. И больше ничего! Все остальное может оказаться, а в нашем случае и оказалось, «липой».
Чтобы еще больше затруднить попытки поиска, злоумышленник может воспользоваться сервером Open Relay или даже цепочкой серверов Open Relay, списки которых ходят по Internet и счет которым идет на десятки тысяч.
Конечно, набирать вручную команды SMTP, да еще для множества адресатов — занятие, мягко выражаясь, для идиотов. Любой системный программист без особого труда может написать нужную программку.
МЕТОДЫ БОРЬБЫ СО СПАМОМ
Обнаружить спам часто очень легко, а иногда весьма затруднительно. Нередко это можно сделать только после знакомства с содержанием или при тщательном анализе заголовков. Я не буду акцентировать внимание на проблемах идентификации спама, на эту тему существует множество литературы, а сконцентрируюсь на методах борьбы с ним.
Писать письма «отправителю» с мольбами или угрозами просто глупо. Даже в обычных MUA, хотя бы в том же Outlook Express, можно всегда задать «липовый» адрес отправителя. Чаще всего подделывается именно он, и, скорее всего, ваши письма с требованием прекратить спам попадут либо в никуда, либо непричастным к этой акции людям. Более результативной может оказаться жалоба администратору сервера/домена, откуда пришел спам. Но многие компании, особенно работающие в рекламном бизнесе, в своей деятельности преднамеренно используют такой метод привлечения клиентов, и их жалобами не проймешь.
Все методы противодействия спаму можно разделить на две категории: предпринимаемые на уровне пользователя или на уровне всей почтовой системы.
Наиболее распространены средства борьбы на уровне пользователя. Помимо простого нажатия кнопки Delete, которое скорее можно считать жестом отчаяния, чем реальной борьбой, чаще всего прибегают к разного рода фильтрам. Как правило, письма отфильтровывают по адресу отправителя (заголовок From:) или по его доменной части, но эффективность этого метода невелика. Мне, к примеру, долго досаждал спам, приходящий с периодичностью два-три раза в день, с рекламой некоего страхового общества в США. Причем каждый раз обратный адрес был иным.
Другие фильтры работают более «интеллектуально». В поле Subject: («Тема») или в теле письма они отфильтровывают сообщение по определенным комбинациям слов (например, sex, lolita, cool в одном предложении). Такие фильтры уже встроены в некоторые MUA, но пользователь может добавить свои. К сожалению, о них прекрасно осведомлены спамеры и поэтому часто их обходят. К тому же фильтры рассчитаны на английский язык, так что российским спамерам не о чем особенно беспокоиться. Немалую часть спама составляют письма в формате рисунков. Им подобные фильтры не страшны. Кстати говоря, хотя и нечасто, отбраковке подвергаются письма, никакого отношения к спаму не имеющие. Например, моя почтовая программа постоянно отфильтровывает письма, приходящие с Центрального телеграфа.
Если пользователь для получения почты задействует протокол POP3 (а это повсеместная практика), то, прежде чем будет запущена фильтрация, письмо необходимо переместить на клиентскую машину. А теперь представьте, что вы работаете по коммутируемому соединению и вам прислали по почте рекламный буклет объемом мегабайт эдак на пять? Мало того, что от спама страдают почтовые серверы, так и линии связи до клиента оказываются загруженными всяким хламом. Это справедливо также для протоколов IMAP4, MAPI и других, когда фильтрация осуществляется по телу письма.
Гораздо привлекательнее выглядят методы борьбы на уровне почтовой системы. Во всяком случае, они позволяют разгрузить линии связи от системы до клиентов. Самыми эффективными с точки зрения нагрузки на серверы являются методы, при которых поступление спама блокируется еще до приема содержания писем (до команды DATA). Разумеется, при этом все попытки спама должны отражаться в журнале событий. Именно такие методы и будут рассматриваться ниже, поскольку у остальных проблемы те же, что и у методов борьбы на уровне пользователя.
Недостаток противодействия спаму на уровне почтовой системы состоит в том, что способы борьбы реализуются для всей системы. Невозможно сделать так, чтобы часть пользователей могла получать сообщения от какого-то адресата, а часть — нет. Всем или никому! Если в обычной коммерческой организации такая политика вполне приемлема, то для провайдеров Internet она весьма сомнительна и вызывает нарекания. И правда, кто, помимо меня самого, может ограничить мои конституционные права по доступу к информации? Быть может, мне нравится читать рекламные объявления от службы новостей?!
Начинающие администраторы любят отфильтровывать спам по адресу «отправителя конверта» или по его доменной части. Но, как уже было показано выше, это поле (в команде MAIL) легко подделывается. С моей точки зрения, такой подход — самый бесперспективный, поскольку требует большого объема ручной работы при минимуме эффекта. Кстати, по руководящему документу RFC 2505 пустой адрес «отправителя конверта» не должен отбраковываться, поскольку он генерируется почтовыми системами при обнаружении ошибок.
Некоторые почтовые системы по доменной части адреса «Отправителя конверта» проверяют факт существования домена. К примеру, во время выполнения команды SMTP:
MAIL From: bbb@ddd.com
почтовый сервер проверит, существует ли домен ddd.com. Если нет, прием будет прекращен. Недостатки подхода очевидны: ничто не мешает спамеру поставить реальный, но подложный доменный адрес «отправителя». Тем не менее такой метод борьбы имеет право на жизнь, поскольку позволяет отфильтровывать совершенно очевидный спам. Но, к сожалению, все, что в почтовой системе связано с DNS, не заслуживает доверия. Для приведенного выше примера это некритично, но другие методы страдают от несовершенства доменной модели Internet.
Все дело в том, DNS позволяет подменять доменные имена (DNSspoofing). С помощью нехитрых манипуляций сервер DNS можно заставить отобразить существующее или несуществующее доменное имя на изначально заданный IP-адрес (или запись MX) и наоборот. Я не буду рассматривать это подробно, проблеме DNS посвящено немало документов, которые заинтересованные читатели смогут найти как в архиве «Журнала сетевых решений/LAN», так и в Internet.
Кроме того, серверам DNS в общем случае требуется доступ к корневым (root) серверам DNS. А если нарушена линия связи вашего провайдера с заграницей?
Еще один способ борьбы состоит в том, чтобы по IP-адресу хоста, с которого получено письмо, определить его доменное имя. И если такового не существует (т. е. хост не занесен в доменную зону in-addr.arpa), то письма отбраковываются. В частности, подобная возможность реализуется по умолчанию в некоторых дистрибутивах sendmail. Я считаю данное решение безответственным. Это не борьба, а вредительство! От подготовленных злоумышленников метод не спасет, а вот почту от многих «законопослушных» отправителей заблокирует.
Если говорить о злоумышленниках, то уже упомянутый DNSspoofing позволяет обойти барьер. Когда же спамер является администратором домена либо в сговоре с ним, ситуация еще проще. В администрируемое пространство IP-адресов зоны in-addr.arpa заносится нужный IP-адрес (да еще он, возможно, указывает на несуществующий домен). К тому же компьютер злоумышленника сам по себе может быть зарегистрирован в зоне in-addr.arpa.
С другой стороны, во многих малых и даже средних сетях, где ни о какой рассылке спама никогда не помышляли, зона in-addr.arpa не задействуется. Дело в том, что обычно им выделяется только часть сети класса C в пространстве Internet, которую спецификация DNS хотя и позволяет регистрировать в in-addr.arpa, но сделано это так неуклюже, что по сути решение не работает. Да и тратить время на регистрацию подсети маленьким организациям не с руки. Кроме того, проблемы с отображением IP-адресов в доменные имена возникают там, где используется DHCP без привязки к DNS.
Все описанные выше способы борьбы на уровне почтовой системы служат скорее для компрометации самой идеи защиты от спама. Настоящие методы должны основываться только на информации, заслуживающей доверия. А в нынешней модели электронной почты Internet единственной такой информацией является IP-адрес хоста за пределами зоны ответственности сети принимающей стороны. На признании этого факта построено противодействие несанкционированной почте на основе «черных списков» IP-адресов.
Как уже говорилось, спам поступает либо напрямую (пусть даже с фиктивными заголовками Received: о якобы длительной цепочке промежуточных узлов), либо от серверов Open Relay. Возможен и вариант, когда рассылка осуществляется через ряд подконтрольных серверов, что, впрочем, почти одно и то же, что и прямая рассылка.
Самый трудоемкий и неэффективный способ — заносить IP-адреса в «черный список» вручную. Любая почтовая система предоставляет такой сервис. Основной недостаток этого метода в том, что если администратор отправляющей стороны заблокировал спамера или закрыл Open Relay, то вряд ли об этом можно узнать, продолжая отфильтровывать весь трафик от данного почтового сервера. А если это сервер mail.ru или yahoo.com?
Но данную задачу можно облегчить. В Internet доступны списки уже обнаруженных спамеров или серверов Open Relay. Их можно найти с помощью какой-либо поисковой машины и затем периодически обновлять. Кроме того, имеющиеся утилиты позволяют в автоматическом режиме находить в Internet списки спамеров и серверов Open Relay.
Наиболее продвинутые средства борьбы реализованы в «черных списках реального времени». Эти средства основаны на DNS и, как следствие, подвержены проблемам DNS. Суть метода в том, что на самой почтовой системе нет никаких «черных списков», они хранятся на серверах компании, предоставляющей услуги противодействия спаму.
Во время получения письма, сразу же после идентификации IP-адреса хоста-отправителя, почтовая система получателя обращается по DNS в центр борьбы со спамом с запросом об определении доменного имени по этому IP-адресу. Если IP-адреса нет в «черном списке», сервер возвращает некое имя, в противном случае сообщает об ошибке. Все достаточно элегантно. Одно условие: связь с серверами провайдеров услуг по борьбе со спамом должна быть устойчивой и постоянной.
Некоторые «черные списки» содержат адреса только серверов Open Relay, другие ведут еще и списки хостов спамеров (подробности можно узнать на http://www.antispam.ru, http://spamcop.net, http://www.ordb.org и многих других). К большому сожалению, самые продвинутые «черные списки» предоставляются на коммерческой основе, что ограничивает их применение.
Интерес представляет процесс занесения хоста в «черный список». Процедура обычно следующая. Когда кто-либо получает спам, он пересылает письмо провайдеру услуг по борьбе со спамом. Тот, в свою очередь, «включает счетчик» для IP-адреса машины, и, когда количество жалоб превысит некий заданный предел, помещает IP-адрес в «черный список» (серверы Open Relay заносятся в «черный список» сразу, без всякого счетчика). При этом администратору почтового сервера, с которого шел спам, высылается уведомление для принятия соответствующих мер по обузданию спамера или по закрытию Open Relay. Если же поток жалоб прекратился, то по истечении определенного времени IP-адрес изымают из списка. Вроде бы все продумано. Все, да не совсем. Во-первых, тем, кто не пользуется услугами подобных компаний, нет резона сообщать о спаме. Во-вторых, ничто не мешает злоумышленникам использовать какой-либо компьютер для массовой разовой рассылки спама, а затем на время затаиться, пока его не исключат из «черного списка», и повторить все снова. В-третьих, у каждого понятие о спаме свое, некоторые считают спамом даже то, на что сами подписались. В-четвертых, такая процедура позволяет выдвигать ложные обвинения против добропорядочных организаций. Поясню, о чем речь. Злоумышленник может обратиться в антиспамовский центр с жалобой на якобы полученный им спам, который сам же и сгенерирует, чтобы в «черный список» занесли ту или иную компанию.
Вдобавок существует еще одна проблема, о которой почти нигде не упоминается, но она способна свести на нет все плюсы «черных списков».
В Internet имеется большое количество бесплатных и общедоступных почтовых серверов, работающих через интерфейс Web. На первый взгляд злоумышленнику достаточно зарегистрироваться где-либо, чтобы рассылать спам по всему «виртуальному пространству». Конечно, это не так: после обнаружения спама учетную запись заблокируют. Но и спамеры не лыком шиты. Написать программу автоматической генерации учетных записей для почты Web, да добавить сюда еще программку для рассылки спама в интерфейсе Web совсем не сложно. Вроде, дело в шляпе. Ан нет. Из сообщений в прессе можно заключить, что администраторы почтовых порталов (я думаю, не все) в курсе проблемы. Поэтому они фиксируют IP-адреса хостов, с которых идет подключение к почте Web, и при обнаружении спама или активной генерации учетных записей блокируют связь с ними. Ну, теперь-то все, победа осталась за нами? Ничего подобного!
Существует такое понятие, как Web-cache, в простонародье часто называемое «прокси» (proxy), хотя это не совсем одно и то же. Web-cache позволяет кэшировать трафик Web, оптимизируя запросы в Internet. Так вот, немалое количество серверов Web-cache доступны из Internet, поскольку администраторы либо по неграмотности, либо, не предвидя опасности, не закрывают к ним доступ извне. Списки доступных серверов Web-cache можно найти в Internet.
Проблема в том, что для регистрации учетных записей и распространения спама злоумышленник будет обращаться к почте Web не напрямую, а через эти серверы. По сути, почтовым порталам необходимо вести списки общедоступных серверов Web-cache.
Мне не хотелось бы затрагивать технологию шифрования трафика SMTP на транспортном уровне. Все это настолько непроработано для Internet как единого пространства, что жаль тратить драгоценное место. Для защиты от подложных писем применяют шифрование почты уже на прикладном уровне, с помощью таких средств, как PGP. Однако подобная практика реальна лишь в корпоративной среде или среди доверенных лиц.
Недавно в России был принят закон об электронной цифровой подписи, но в нем никак не регламентировано создание общенациональных сертификационных (доверительных) центров. А без этого закон немногого стоит. А что делать при общении с зарубежными партнерами? Зарубежные сертификаты получить можно, но, во-первых, для россиян их использование не вполне законно, а во-вторых, услуга стоит денег.
По большому счету, единственный известный мне надежный способ борьбы со спамом — периодическая смена своего почтового имени. А новый адрес необходимо сообщать лишь тем, с кем продолжаете сотрудничать. К сожалению, это красиво на бумаге, но не в жизни. Администраторам почтовых систем, в том числе провайдерам Internet, вряд ли понравится такое решение. У многих пользователей проблем не меньше. К тому же некоторые почтовые имена невозможно или затруднительно менять, например postmaster, abuse, webadmin и т. д. Но на общедоступных почтовых порталах метод себя оправдывает.
В качестве полумер можно предложить такое решение. Свои рабочие реквизиты предоставлять только по служебным надобностям или тем, кто заслуживает доверия. Для других целей рекомендуется использовать почтовые адреса на общедоступных почтовых серверах. И менять их (создавать новые) по мере того, как будет донимать спам.
ПОДВОДЯ ИТОГИ
Фундамент спама — низкая стоимость рассылки почты. И его невозможно разрушить никакими способами, не подорвав всю систему. Вместе с тем, проблем добавляет и хаотичная природа самого Internet. Часто проводят аналогию между электронной и обычной почтой. Такая аналогия хромает на обе ноги. Если бы в модели электронной почты была принята схема уполномоченных почтовых отделений (как в обычной почтовой системе), контролировать поток сообщений было бы проще.
Что же касается средств борьбы со спамом, то все они в той или иной мере неэффективны и рассчитаны на защиту от спамеров-дилетантов. Впрочем, лучше хоть что-то, чем ничего.
Константин Пьянзин — обозреватель «Журнала сетевых решений/LAN». С ним можно связаться по адресу: koka@lanmag.ru