Средства программы sendmail для борьбы со спамом
Категория: Электронная почта | Автор: admin | 1-06-2010, 03:31 | Просмотров: 4320

Спам — это жаргонное слово, обозначающее "мусорную", навязчивую электронную почту коммерческого характера. Спам стал серьезной проблемой, в основном из-за того, что отправитель сообщения (по крайней мере, в США) платит не за переданное количество байтов, а за факт соединения. Если же плата взимается за объем трафика, то создается одно сообщение, адресуемое тысяче получателей, но ретранслируемое через другой компьютер. При этом пользователь того компьютера платит высокую цену за весь объем спама, а сам спамер (т.е. отправитель оригинала письма) оплачивает только одну копию. Конечные пользователи во многих странах, естественно, тоже весьма недовольны тем, что они получают спам и вынуждены оплачивать его побайтово.

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

В США провайдеры стали ощущать влияние спама, когда их службы технической поддержки начали сталкиваться со все возрастающим числом злоупотреблений спамом со стороны своих собственных клиентов. Один провайдер в Колорадо, имеющий около 150 подчиненных клиентов Т1 (многие из которых сами являются провайдерами), вынужден тратить половину рабочего времени своих сотрудников на то, чтобы разбираться с проблемами спама.

С точки зрения маркетологов, спам — очень полезное дело. Эффективность применения спама высока, плата за его использование, наоборот, низкая, а доставка — мгновенная. Отправка сообщения по списку, содержащему 30 миллионов электронных адресов, стоит всего около 40 долларов.

Многие спамеры пытаются изображать невинность, помещая в свое послание ссылку "remove" (удалить), тем самым предлагая получателям возможность удалить себя из списка рассылки. Казалось бы, все честно, но отвечая на их письмо, получатель тем самым подтверждает наличие действующего электронного адреса. Удалив получателя из одного списка, спамеры могут тут же внести его в другой список. Спамеры любят также менять заголовки своих сообщений, пытаясь тем самым замаскировать автора послания и то, с какого компьютера оно было отправлено.

Люди, которые продают электронные адреса спамерам, недавно начали применять новый вид "словарной" атаки для поиска неизвестных ранее адресов. Берется список наиболее часто встречающихся фамилий, и при помощи программы-сканера к ним добавляются разные инициалы в надежде случайно образовать действительный адрес электронной почты. Для проверки адресов программа связывается с почтовыми серверами, скажем, 50-ти крупных провайдеров и выполняет команду VRFY для каждого из несметного числа образованных ею адресов.

Такое зондирование подвергает почтовый сервер огромной нагрузке и отрицательно сказывается на его способности обрабатывать почту реальных клиентов. Программа sendmail может бороться с этой проблемой, если для переменной PrivacyOption будет задано значение goaway. Однако умно написанная программа-сканер поступает следующим образом: если команда VRFY заблокирована, сканер пытается выполнить команду EXPN, а если заблокированы обе команды, то будет опробована команда RCPT. В результате опрашиваются миллионы адресов, и хотя не было послано ни одного сообщения, почтовый сервер гарантированно окажется загруженным.

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

Существует четыре типа средств, предназначенных для борьбы со спамом.

  • Правила управления ретрансляцией, под которой понимается использование почтового сервера при отправке почтового сообщения одним сторонним пользователем другому, тоже стороннему. Спамеры часто прибегают к ретрансляции, пытаясь таким способом замаскировать действительного адресата сообщения и тем самым избежать обнаружения со стороны своих собственных провайдеров.
  • База доступа позволяет фильтровать почту согласно адресам, содержащимся в базе. Это напоминает применение брандмауэра для электронной почты.
  • "Черные" списки открытых ретрансляторов и известных спамеров используются программой sendmail для борьбы со спамом.
  • Проверка заголовков — это мощное средство, поддерживаемое в программе sendmail версии 9. Оно заключается в произвольном сканировании сообщений с последующим отбрасыванием сообщений, удовлетворяющих определенным критериям.

 

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

 

Ретрансляция

 

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

До появления программы sendmail версии 8.9 по умолчанию задавался режим "беспорядочной" рассылки (известный как открытая ретрансляция). Программа sendmail принимала любые сообщения через порт 25 и пыталась осуществить доставку самым оптимальным способом. В те времена считалось, что Internet — это дружественная среда.

К сожалению, ретрансляцией начали злоупотреблять спамеры. Они использовали ее для своей маскировки и, что более существенно, для перекладывания нагрузки (в том числе финансовой) на другие компьютеры. Поэтому конфигурирование почтового сервера в режиме открытой ретрансляции считается в настоящее время дурным тоном.

Позаботиться следует не только о своей собственной политике ретрансляции: нужно знать, кому вообще можно доверять. В конце концов, любые сообщения, полученные с серверов открытой пересылки, оказываются спамом. Пол Викси, пламенный борец со спамом, и организаторы проекта ORBS (Open Relay Behavior-modification System — система модификации поведения серверов открытой ретрансляции) собрали базы данных IP-адресов тех серверов, где используется открытая ретрансляция. Эти базы данных можно легко подключить к программе sendmail в виде "черного" списка, в соответствии с которым сообщения, поступающие от одного из этих адресов, будут игнорироваться. Создатели проекта ORBS позволяют организациям, устранившим проблему открытой ретрансляции, автоматически удалять себя из такого списка.

На одном Web-узле подсчитали, что от трети до половины всех почтовых серверов сконфигурированы в режиме открытой ретрансляции (по состоянию на весну 2000 года). Статистика ORBS показывает, что количество таких серверов составляет как минимум 15%.

В программе sendmail начиная с версии 8.9 ретрансляция отключена по умолчанию. Только узлам, помеченным ключевым словом RELAY в базе доступа, или узлам, перечисленным в файле /etc/mail/relay-domains, разрешается предоставлять почту для ретрансляции. Доля серверов открытой ретрансляции будет снижаться в течение следующих нескольких лет, и произойдет это вследствие упомянутого выше изменения в программе sendmail, а также благодаря повышению степени осведомленности публики по этому вопросу и профилактической деятельности проекта ORBS.

Таким образом, ясно, что "беспорядочная" ретрансляция — это плохо. Но ясно и то, что некоторые типы ретрансляции и нужны, и легитимны. Как определить, какое сообщение необходимо ретранслировать, а какое — отклонить? Ретрансляция действительно нужна лишь в двух случаях.

  • Когда транспортный агент функционирует в качестве шлюза для узлов, недоступных никаким другим способом. Это могут быть UUCP-системы, периодически выключаемые компьютеры (РРР-узлы, персональные компьютеры, работающие под управлением Windows) и виртуальные узлы. В данном случае все получатели, которым требуется переслать сообщение, должны быть расположены внутри того же домена.
  • Когда транспортный агент служит сервером исходящей почты для других узлов. В этом случае имена и IP-адреса всех узлов-отправителей являются локальными.

Любые другие случаи ретрансляции, вероятнее всего, свидетельствуют о плохой конфигурации сервера. Настройка в соответствии с первым из упомянутых вариантов подразумевает отмену протокола UUCP (он и так почти не используется) и конфигурирование центрального сервера на прием почты (с использованием протокола POP или IMAP для клиентского доступа). Второй вариант должен быть всегда допустим, но только для локальных узлов. Лучше проверять IP-адреса, чем имена компьютеров, так как последние легко подделать.

В программе sendmail функция ретрансляции отключена по умолчанию, но с помощью специальных средств ее можно включить либо в полном объеме, либо в ограниченном и контролируемом режиме. Эти средства перечислены ниже. Их можно использовать, но мы рекомендуем проявлять максимум осторожности и не злоупотреблять ими. Средство access_db, рассматриваемое в следующем разделе, — это наиболее безопасный метод задействования ограниченной ретрансляции.

  • FEATURE ('relay_entire_domain') — разрешает ретрансляцию для узлов текущего домена;
  • RELAY_DOMAIN (‘домен, ... ') — добавляет дополнительные домены к списку ретрансляции;
  • RELAY_DOMAIN_FILE (‘имя_файла') — то же самое, но список доменов берется из файла;
  • FEATURE (‘relay_hosts_only') — влияет на макрос RELAY_DOMAIN и средство access_db.

Придется сделать исключение, если с помощью макроконстант SMART_HOST и KAIL_HUB почта направляется на конкретный почтовый сервер. Этот сервер должен быть настроен на ретрансляцию всей почты, поступающей от локальных компьютеров:

FEATURE ('relay_entire_domain')

 

Организациям, предоставляющим услуги виртуального хостинга, потребуется активизировать также макрос RELAY_DOMAIN, чтобы ретрансляция поддерживалась для виртуальных доменов, хотя средство

FEATURE ('use_cw_file')

 

выполняет, по сути, те же самые действия.

 

Ниже представлено еще несколько средств, но их использование связано с существенным риском.

  • FEATURE ('promiscuous_relay') — разрешает "беспорядочную" ретрансляцию;
  • FEATURE (relay_based_on_MX) — разрешает ретрансляцию для всех узлов, записи MX которых ссылаются на текущий компьютер;
  • FEATURE ('loose_relay_check') — разрешает "процентную" адресацию;
  • FEATURE (relay_local_from') — разрешает ретрансляцию для локальных адресов, указанных в поле "From" сообщения.

 

Средство promiscuous_relay позволяет осуществлять пересылку почты из какого-либо узла на любой другой узел. Активизируя это средство, вы неминуемо попадете в черные списки Пола Викси. Не пользуйтесь этим средством.

Средство relay_based_on_MX опасно по той причине, что не позволяет контролировать, какие узлы ссылаются в своих записях MX на данный компьютер. Обычно соответствующие записи MX имеют только локальные компьютеры, но ничего не мешает другим узлам поменять установки своего сервера DNS. Спамеры обычно не могут менять записи MX, но организации с сомнительной репутацией вольны в своем выборе.

Средство loose_relay_check разрешает применять "процентный" тип адресации, которым спамеры с удовольствием пользуются.

Средство relay_local_from заставляет программу sendmail доверять адресу отправителя, указанному в конверте сообщения, и осуществлять ретрансляцию тех сообщений, которые якобы поступают от локальных адресов. Естественно, и конверт, и заголовки почтовых сообщений подделать легко, а спамеры — специалисты в области подделки.

Планируя использовать ретрансляцию, не поленитесь сначала обратиться к документации на программу sendmail (файл cf/README), чтобы нечаянно не стать лучшим другом спамеров. Активизировав функцию ретрансляции, проверьте, не включен ли случайно режим открытой пересылки. Для этого следует обратиться на узел ordb.org или abuse.net.

При неправильной конфигурации компьютер может осуществлять ретрансляцию сообщений со странными адресами, основанными на искажении синтаксиса адресации UUCP. Чтобы предупредить появление такой "дыры", отключите протокол UUCP (а также BITNET и DECnet):

 

FEATURE (‘nouucp’,   'reject')

undefine('UUCP_RELAY')

undefine('BITNET_RELAY')

undefine('DECNET_RELAY')

 

 

Лучше всего разместить эти строки в доменном файле.

Еще один тип ретрансляции, который часто определяется в доменном файле, задается макроконстантой LUSER_RELAY. Этот тип предназначен для локальных пользователей, которые на самом деле не существуют. Узел, на котором работает неправильно сконфигурированная программа sendmail, иногда допускает "утечку" сообщений с не полностью определенными именами локальных пользователей (обычно содержатся в поле "Сс"). Тот, кто попытается ответить на такое сообщение, на самом деле укажет в качестве адресата мнимого, несуществующего локального пользователя. Такая почта направляется агенту доставки error:

define ('LUSER_RELAY',   'error:No such user')

 

База доступа

 

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

База доступа подключается следующим образом:

FEATURE('access_db',   'тип имя_файла')

 

Если параметры тип и имя_файла не указаны, то по умолчанию принимается тип hash и файл /etc/mail/access. Как обычно, база доступа создается с помощью команды makemap:

# makemap hash /etc/mail/access < /etc/mail/access

 

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

 

cyberspammer.com          550 Spam not accepted

okguy@cyberspammer.com    OK

badguy@aol.com            REJECT

sendmail.org              RELAY

128.32                    RELAY

170.201.180.16            REJECT

hotlivesex@               550 Spam not accepted

friend@                   550 You are not my friend!

 

 

В поле значения должен находиться один из элементов, представленных в табл. 19.14.

Таблица 19.14. Элементы, которые могут присутствовать в поле значения

Значение

Что означает

ок

Прием и доставка почты в обычном режиме

RELAY

Прием почты и пересылка ее получателю

REJECT

Отклонение почты с выдачей типового сообщения об ошибке

DISCARD

Удаление почты без выдачи соответствующего уведомления

ххх     сообщение

Выдача сообщения об ошибке; вместо ххх должен стоять числовой код, определенный в документе RFC8211

ERROR:ххх сообщение

То же, что и предыдущее, но сообщение об ошибке помечается более явно

ERROR:х.х.х сообщение

Вместо хх.х должен стоять один из кодов состояния доставки, определенных в документе RFC 1893

1   550 — код единичной ошибки.

 

Показанная выше база доступа пропускает сообщения от пользователя okguy узла cyberspammer.com, но отклоняет все остальные сообщения из данного узла, выдавая сообщение об ошибке. Почта, приходящая из домена sendmail.org или сети 128.32.0.0/16 (сеть Калифорнийского университета в Беркли), будет ретранслироваться. Почта от пользователя badguy узла aol.com. а также почта, приходящая от пользователей hotlivesex и friend любых доменов, будет отклоняться.

В поле ключа могут стоять адреса IPv6 с разделителями в виде двоеточий. Символ @ после имен hotlivesex и friend нужен для того, чтобы отличать имена пользователей от имен доменов.

Код 550 задан в документе RFC821. Кодов состояния доставки, определенных в документе RFC1893, гораздо больше. Первая цифра 4 означает временную ошибку, цифра 5 — постоянную ошибку. Несколько кодов приведено в табл. 19.15.

Таблица 19.15. Коды состояния доставки (документ RFC1893)

Временная ошибка

Постоянная ошибка

Значение

4.2.1

5.2.1

Почтовый ящик недоступен

4.2.2

5.2.2

Почтовый ящик переполнен

4.2.3

5.2.3

Сообщение слишком велико

4.2.4

5.2.4

Проблема с раскрытием списка рассылки

4.3.1

5.3.1

Почтовая система переполнена

4.4.4

5.4.4

Маршрутизация невозможна

4.4.5

5.4.5

Перегрузка почтовой системы

 

Поле ключа может содержать теги Connect, То и From, позволяющие задавать более точные критерии фильтрации. Тег Connect содержит информацию о соединении, например адрес или имя клиента. Теги То и Frorr ссылаются на адреса конверта, а не заголовков. С помощью данных тегов можно переопределять другие установки.

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

Вот несколько примеров:

 

From: spammer@some.domain       REJECT

To: friend.domain               RELAY

Connect: friend.domain          OK

 

 

Из этого примера видно, что почта, приходящая от имени spammer@some.domain, будет заблокирована, но по данному адресу все равно можно будет посылать почту, даже если он помещен в "черный" список. Разрешается ретранслировать почту, посылаемую по адресу friend.domain, но это не относится к сообщениям, поступающим от данного адреса (предполагается, что ретрансляция запрещена где-то в другом месте). Соединение с узлом friend.domain допускается, даже если этот адрес помещен в один из "черных" списков DNS.

Базы доступа используются многими организациями с целью контроля над спамом. Наш сервер входящей почты на факультете вычислительной техники университета Колорадо отклоняет почту от более чем 500 известных спамеров, определяемых по именам, доменам или IP-адресам.

 

Занесение пользователей или узлов в «черные» списки

 

Если необходимо блокировать почту каких-либо локальных пользователей или узлов, воспользуйтесь средством

FEATURE ('blacklist_recipients’)

 

которому в базе доступа соответствуют следующие записи:

 

nobody@                      550 Mailbox disabled for this user

printer.mydomain.edu         550 This host does not accept mail

user@host.mydomain.edu       550 Mailbox disabled for this user

 

 

Эти записи блокируют почту, приходящую на адрес пользователя nobody на любом узле, а также почту, адресованную сетевому принтеру и одному из пользователей.

С помощью средства dnsbl можно подключить "черные" списки, которые ведет Пол Викси в своем проекте MAPS (Mail Abuse Prevention System — система предотвращения почтовых злоупотреблений; обратитесь на Web-узел mail-abuse.org), а также любые DNS-списки блокируемых адресов:

FEATURE ('dnsbl’)

 

Это средство заставляет программу sendmail отклонять почту, приходящую с того узла, IP-адрес которого имеется в списке Realtime Blackhole List. В него занесены адреса спамеров, известных проекту MAPS. В других списках указаны спамеры, работающие по коммутируемым линиям, и узлы, поддерживающие открытую ретрансляцию.

"Черные" списки распространяются через службу DNS. Например, специальная DNS-запись

IP-адрес.rbl.maps.vix.com   in   a    127.0.0.2

 

введенная в базу данных DNS домена rbl.maps.vix.com, блокирует почту от указанного узла, если средство dnsbl включено (программа sendmail явно проверяет, существует ли такая запись). В данном примере IP-адрес — это сетевой адрес в обратной точечной нотации.

 

Средство dnsbl можно активизировать всякий раз, когда необходимо проверить тот или иной список злоумышленников. Достаточно добавить второй аргумент, задающий сервер имен для "черного" списка, и третий аргумент, содержащий требуемое сообщение об ошибке. Если третий аргумент опущен, будет выдано фиксированное сообщение (из базы данных DNS, содержащей проверяемые записи). Ниже даны примеры трех списков: rbl (стандартный), dul — список спамеров, работающих по коммутируемым линиям, и rss — список узлов, поддерживающих открытую ретрансляцию.

 

FEATURE ('dsnbl’,   'rbl.maps.vix.com',   'Rejected - see

          www.mail-abuse.org/rbl/')

FEATURE ('dsnbl',   'dul.maps.vix.com',   'Dialup - see

          www.mail-abuse.org/dul/')

FEATURE ('dnsbl',   'relays.mail-abuse.org',   'Relay - see

         www.mail-abuse.org/rss/')

 

 

Проверка заголовков

 

Проверка заголовков — мощный механизм борьбы со спамом, в основе которого лежит использование синтаксиса низкоуровневого файла конфигурации программы sendmail; мы не рассматриваем этот файл в данном издании книги. Выполняя проверку заголовков, программа sendmail сверяет их с имеющимися образцами (например, "То: friend@public.com") и отклоняет подозрительные сообщения до того, как они будут доставлены в пользовательские почтовые ящики.

Проверка заголовков может также применяться для распознавания почтовых вирусов при условии, что они имеют характерную строку заголовка. Например, вирус Melissa (1999 г.) содержал тематическую строку вида "Important Message From...". В пределах нескольких часов, пока вирус Melissa распространялся, на узле sendmail.com был опубликован локальный набор правил по идентификации вируса и отбрасыванию содержащих его сообщений. То же самое происходит в отношении других почтовых вирусов: как только выясняются отличительные особенности вируса и появляется возможность выразить их в виде правил программы sendmail, быстро публикуются исправления к почтовой системе (как на Web-узле sendmail.com, так и на узле www.sendmail.org).

Характерный образец правил фильтрации, предназначенных для борьбы со спамом и вирусами, можно найти в файле конфигурации программы sendmail для домашнего компьютера Эрика Оллмана (knecht). Эта конфигурация включена в дистрибутив sendmail (файл cf/cf/knecht.mc). Позаимствуйте из нее правила фильтрации спама и добавьте их в конец своего mc-файла.

Разбирая различные примеры, мы встречали следующие правила проверки заголовков:

  • почта, адресованная любому пользователю в домене public.com;
  • почта, адресованная пользователям "friend" или "you";
  • почта, имеющая заголовок X-Spanska, который указывает на наличие вируса-червя Нарру99;
  • почта с тематической строкой "Important Message From..." (вирус Melissa):
  • почта с тематической строкой "all.net и Fred Cohen..." (вирус Papa);
  • почта с тематической строкой "ILOVEYOU" (вирус "iloveyou" и его варианты);
  • почта от узлов aol.com и msn.com с числовыми именами пользователей:
  • почта от узла juno.com с именами пользователей, начинающимися с цифры.

 

Все правила проверки заголовков задаются макросами LOCAL_CONFIG и LOCAL_RULESETS, расположенными в конце mc-файла. С помощью команды divert препроцессора m4 программа sendmail размещает эти правила в нужном месте низкоуровневого файла конфигурации.

В ответ на получение спама вызывайте агент доставки error (с сообщением об ошибке "user unknown"), а не discard. Многие спамеры "подчищают" свои списки рассылки, оставляя только коммерчески ценные адреса, поэтому можно легко удалить себя из списка, записав в него сообщение об ошибке.

 

Обработка спама

 

Борьба со спамом может оказаться трудным и часто безрезультатным занятием. Не нужно тратить усилия на поимку отдельных спамеров. Время, затраченное на анализ заголовков спама и прочие переживания, — это потерянное время. Да, это благородная борьба, но объем поступающего спама она вряд ли уменьшит.

Постоянных спамеров можно нейтрализовать довольно быстро, вычислив их провайдера. Однако спамеры, работающие по принципу "напакостил и удрал", используют учетную запись на узле провайдера только один раз, после чего избавляются от нее. Их поймать трудно. Если они рекламируют свой Web-узел, то ответственность можно возложить на него. Если же они объявляют номер телефона или почтовый адрес, то идентифицировать отправителя спама будет тяжело, но вполне возможно. Впрочем, многие из таких "мобильных" спамеров могут оказаться вообще недосягаемыми для наказания.

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

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

Если вам все же нравится вести борьбу со спамом, воспользуйтесь помощью, предлагаемой соответствующими Web-узлами. В первую очередь следует упомянуть узлы mail-abuse.org и abuse.net. На узле www.spamrecycle.com вас попросят направить им образец спама; они перешлют его федеральным властям, которые могут предпринять какие-то законодательные меры. Этот Web-узел также публикует правила защиты от спама. Узел производит анализ спама и использует результаты анализа для усовершенствования спам-фильтров. Три других Web-узла, заслуживающих внимания, — это ordb.org, spamcop.net и www.cauce.org. На первом из них содержатся наиболее полные базы данных серверов, поддерживающих открытую ретрансляцию. На втором предлагаются средства анализа заголовков почтовых сообщений и определения действительного отправителя. На третьем приведена хорошая информация о законах, касающихся спама.

 

Примеры спама

 

Хотя мы не рекомендуем читателям заниматься анализом спама, иногда все же полезно знать, как это делается. Например, вас могут вызвать для объяснений в связи с тем, что генеральный директор компании получил сообщение порнографического характера (необходимо доказать, что оно не поступило от кого-то из служащих компании).

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

  • Заголовки "Received" образуют последовательную цепочку, начиная от верхней части сообщения и заканчивая его нижней частью.
  • Любые заголовки "Received", расположенные ниже заголовка "Date", — поддельные.
  • Обращайте внимание на любой заголовок "Received", в котором имена двух узлов не совпадают. Вероятно, почтовое сообщение было ретранслировано через первый узел (узел, имя которого заключено в круглые скобки, является действительным источником сообщения).
  • Заголовок "Received", имеющий старую дату, вероятнее всего, подделан.
  • Сетевая часть заголовка "From" должна согласоваться с последним заголовком "Received".
  • Домен заголовка "Message-Id" должен совпадать с доменом заголовка "From".
  • Проверьте, нет ли в заголовках "Received" признаков того, что сообщение ретранслировано через посторонний узел.
  • Убедитесь, что все перечисленные узлы действительно существуют в базе данных DNS.

 

В качестве первого примера возьмем сообщение, авторы которого предлагают будущим спамерам купить компакт-диск, содержащий 10000000 электронных адресов. Этот компакт-диск представляет определенный интерес: гарантируется, что он не содержит дублирующиеся адреса, а также "отравленные" адреса (вероятно, те, где отправитель автоматически заносится в один из "черных" списков).

С целью упрощения комментариев мы пронумеровали строки заголовков. Сами номера в письме отсутствуют.

 

1: From mrktnet77@kayak.msk.ru Thu Nov   4 22:10:48 1999

2: Received: fromgaia.es  ([195.55.166.66]) byxor.com (8.9.3/8.9.3)

with ESMTP id WAA26343 for <evi@xor.com>; Thu,  4 Nov 1999 22:10:42

-0700   (MST)

3: From: mrktnet77@kayak.msk.ru

4: Received: fromdefaultbygaia.es (8.8.8+Sun/SMI-SVR4) id GAA03907;

Fri, 5 Nov 1999 06:31:10 -0100   (Etc/GMT)

5: Date:  Fri,   5 Nov 1999 06:31:10 -0100   (Etc/GMT)

6: Received:  from login_011556.wgukas.com (mail.wgukas.com

[233.214.241.87])  by  (8.8.5/8.7.3)  with SMTP id XAA01510 for

fraklin321@thaxghklo.um.de; Thu, 4 November 1999 00:21:59 -0700 (EDT)

7: To: mrktnet77@kayak.msk.ru

8: Subject: Just Released! Millions CD Vol. 6A

9: Comments: Authenticated Sender is <userll556@wgukas.com>

10:Message-Id:  02202108722648597456@sa_ghklo.um.de

/* Несколько страниц маркетинговой информации */

*********************************

Do not reply to this message -

To be removed from future mailings:

mailto:gregll4 8@usa.net?Subject=Remove ***

******************************

 

 

Строка 1 была добавлена программой /bin/mail в процессе локальной доставки. Домен msk.ru существует, а узел kayak.msk.ru — нет. Строка 2 содержит достоверный заголовок "Received". Это единственная заголовок "Received", которому можно доверять, поскольку он добавлен на нашем собственном узле xor.com. Строка 3 — это заголовок "From", добавленный программой sendmail где-то "в пути", поскольку оригинал сообщения не имел его.

Строка 4 содержит достоверный заголовок "Received" от ничего не подозревающего узла gaia.es, сыгравшего роль козла отпущения. На этом узле выполняется программа sendmail 8.8, которая по умолчанию поддерживает ретрансляцию (в такой конфигурации ее поставляет компания Sun). Строка 6 — это поддельный заголовок "Received". Он находится ниже заголовка "Date", следовательно, был создан до того, как первый экземпляр программы sendmail получил сообщение. Кроме того, формат заголовка неверен, а адрес 233.214.241.87 не имеет обратной записи в DNS.

Строка 7 (заголовок "То") также поддельная. Адреса получателей были только на конверте.

Строка 9, по идее, идентифицирует истинного отправителя, что иногда является ключом к разгадке источника сообщения. В данном случае подразумевается, что сообщение отправлено из домена wgukas.com, но такого домена не существует. Эта строка в действительности была добавлена пользовательским почтовым агентом на персональном компьютере и, следовательно, может быть поддельной.

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

Невозможно сказать, откуда пришло это сообщение. Оно было ретранслировано через узел gaia.es, очевидно без разрешения. Этот узел еще не попал в "черный" список сервера mail-abuse.org, но может вскоре там оказаться. Пользователь greg1148. возможно, действительно является спамером, но может быть и обычным пользователем, имевшим неосторожность пожаловаться на полученный спам. Во втором случае пользователя gregll48 следует рассматривать как жертву, так как в скором будущем он получит сотни, а то и тысячи сердитых посланий от пользователей с требованием удалить их из списка рассылки.

Тело сообщения призывает получателей делать заказ по телефону или факсу. Типичный случай: вся информация, касающаяся того, как связаться со спамером и купить предлагаемый им продукт, приведена в теле сообщения. Заметьте, что адрес в заголовке "From" такой же, как и в заголовке "То". Вероятно, оба они поддельные.

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

 

1: From jimdelno@apexmail.com Thu Nov 11 10:31:41 1999

2: Received:  from saturn.globalcon.com (saturn.globalcon.com

[209.5.99.8])  by xor.com  (8.9.3/8.9.3)  with ESMTP id KAA15479;

Thu,  11 Nov 1999 10:31:30 -0700  (MST)

3: Received: from hamilton ([168.191.61.20]) by saturn.globalcon.com (Post.Office MTA v3.1.2 release (PO205-101c)  ID# 0-35881U1500L100S0) with SMTP id AAA148;  Thu,   11 Nov 1999 12:33:24 -0500

4:  Date:  Thu,   11 Nov 1999 02:39:57 +0000

5: Subject: Free Information On "Debt Reduction!"

6: Message-Id: <yjsul.lnmqgaasnjymgqaac@hamiiton>

7: From: F.Pepper@pmail.net

8: To: benfranklin@onehundred.net

 

 

Строка 2 содержит достоверный заголовок "Received". Строка 3 также правдоподобна, но команда traceroute, выполненная из домена xor.com на узлы hamilton (168.191.61.20) и saturn.globalcon.com (209.5.99.8), показала, что эти два узла не имеют никакого отношения друг к другу. Адрес 168.191.61.20 находится в коммутируемой сети Sprint, причем где-то в Европе, судя по формату отображения времени. Адрес 209.5.99.8 принадлежит канадской компании, находящейся в Онтарио. Очевидно, сервер saturn.globalcon.com поддерживает открытую ретрансляцию. На нем работает не программа sendmail, а транспортный агент Post.Office версии 3.1.2 (его можно получить на узле www.openwave.com).

В строке 4, добавленной пользовательским агентом отправителя, говорится о том, что текущее время — примерно 1 часа ночи. Лишь через несколько часов это сообщение было принято компьютером на узле saturn.globalcon.com. Возможно, список получателей был слишком длинным, поэтому процесс пересылки занял так много времени. Или, что вероятнее, сообщение было составлено заранее на персональном компьютере спамера и только потом, спустя пару часов, было отправлено в Internet. Судя по формату отображения времени (если только это не подделка), разница составляет 5 часовых поясов — это как раз разница между часовыми поясами Европы и восточного побережья США.

В строке 6 сетевая часть заголовка "Message-Id" должна быть полностью определенным именем домена, а не локальным именем "hamilton". Узел hamilton, возможно, неправильно сконфигурирован, поскольку неполное имя появляется также в строке 3. Часть заголовка "Message-Id" слева от символа '<@>' обычно состоит из цифр, но в данном случае она содержит наугад взятые буквы. Это указывает на то, что строка может быть поддельной.

Строка 8 явно подделана. Действительный адрес получателя присутствует только на конверте сообщения и больше нигде в заголовках.

Это сообщение действительно могло быть получено от пользователя F.Pepper@pmail.net. Доменному имени pmail.net соответствует реальный IP-адрес, а программа whois сообщает о том, что узел pmail.net принадлежит компании British telecom. Среди примерно двадцати экземпляров спам-сообщений, которые мы проверили при подготовке данного раздела, только это сообщение содержит достаточно информации для того, чтобы можно было составить обоснованную жалобу (в адрес компьютера hostmaster, который указан в базе данных DNS для IP-адреса, приведенного в строке 3 заголовка). Никогда не нужно посылать жалобу непосредственно спамеру или в домен спамера.

SpamCop — это программа, выполняющая синтаксический анализ заголовков почтовых сообщений и определяющая, какие строки реальные, какие — могут быть подделаны, а какие — безусловно подделаны. Программа выдает пользователю, который присылает пример спама по электронной почте или на Web-узел spamcop.net, пошаговое описание заголовков и разъясняет, какие компоненты подтверждаются, а какие — нет. На этом узле можно легко составить жалобу на спам. В жалобу следует включить всю относящуюся к делу информацию, которая была собрана путем синтаксического анализа заголовков.

Мы запустили программу SpamCop для анализа нашего первого спам-сообщения, в котором нам пытались продать компакт-диск со списком адресов. Программа обнаружила, что заголовок "Received" с адресом gaia.es подлинный, но домен wgukas.com — фиктивный. Затем программа определила, что узел gaia.es не имеет IP-адреса, о котором говорится в письме, и что действительный виновник, возможно, находится на узле ttd.net. Ясно, что анализ с помощью программы SpamCop оказался намного лучше, чем наш, и занял он всего несколько секунд.

Ниже приведен небольшой фрагмент из результатов анализа относительно свежего спама. Анализ выполнен программой SpamCop.

 

Received: from sunl.cskwam.mil.pl (cskwam.mil.pl) [148.81.119.2] by maill.es.net with smtp (Exim 1.81 #2) id 12oBHL-000494-00; Sat, 6 May 2000 13:34:23 -0700

Possible spammer:  148.81.119.2

"nslookup cskwam.mil.pl"  (checking ip)   [show] ip not found;

cskwam.mil.pl discarded as fake, "dig cskwam.mil.pl mx"  (digging for Mail exchanger)   [show] "nslookup

cskwam.mil.pl"  (checking ip)   [show] cskwam.mil.pl not 148.81.119.2,

discarded as fake, "nslookup sunl.cskwam.mil.pl"  (checking ip)   [show] ip = 148.81.119.2

Taking name from IP... "nslookup 148.81.119.2"  (getting name)   [show]  148.81.119.2 =

sunl.cskwam.mil.pi "nslookup sunl.cskwam.mil.pl"  (checking ip)   [show] ip = 148.81.119.2 "nslookup 2 .119 . 81.148.rbl.maps.vix.com. "   (checking ip)   [show]

not found

"nslookup 2.119.81.148. relays.orbs . org ."  (checking ip)   [show]  ip =

127.0.0.2 blocked by ORBS

Chain test:mai11.es.net =? maill.es.net Chain verified maill.es.net = maill.es.net 148.81.119.2 has already been sent to ORBS Received line accepted

 

 

Каждое слово [show] является ссылкой на Web-страницу программы SpamCop. Там показана команда, которая была выполнена, и ее результат.


 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page