Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК
Протокол SMTP
O В этой главе:
O Основные команды протокола
O Серверы-ретрансляторы
O Непосредственная пересылка
O Автоматизация почтовой рассылки и спам
O Анонимная рассылка писем
Для доставки почты в большинстве случаев используется протокол SMTP (Simple Mail Transfer Protocol).
При его создании протокола SMTP разработчиками была допущена грубая ошибка, испортившая немало крови, как системным администраторам, так и простым пользователям. Суть ее заключается в том, что протокол SMTP не требует аутентификации пользователя перед отправкой сообщения, и это позволяет использовать чужие сервера для массовой рассылки.
Современные SMTP-сервера используют различные защитные механизмы, препятствующие отправке корреспонденции неизвестными пользователями. Подробно об этом рассказывается в главе «Почтовый сервер изнутри».
В терминологии SMTP-протокола нет таких понятий как «клиент» и «сервер». Вместо этого говорят об отправителе (sender) и получателе (receiver). То, что большинство называют «SMTP-сервером», является одновременно и отправителем, и получателем. Когда клиент устанавливает с ним соединение для передачи письма, сервер выступает в роли получателя, а когда доставляет сообщение абоненту, становится отправителем.
Каждый почтовый ящик представляет собой SMTP-получатель, связавшись с которым напрямую, можно передать сообщение без посредников. Однако такой способ не обрел большой популярности. Связь с далекими узлами может быть медленной и ненадежной, поэтому миссию доставки сообщения удобно возложить на специальный сервер, часто называемый сервером исходящей почты. Если связь с сервером исходящей почты быстрая и надежная, то такой подход вполне оправдан. Напротив, рассылать письма через далекие, тормозные и нестабильно работающее сервера не имеет никакого смыла. В таком случае лучше положить сообщение непосредственно в ящик получателя. Однако немногие почтовые клиенты поддерживают такую возможность.
Приведенный ниже пример демонстрирует, как посредством протокола SMTP отправить абоненту сообщение. Первым шагом необходимо запустить telnet-клиента и, установив соединение с выбранным SMTP-сервером (например, mail.aport.ru) по двадцать пятому порту, дождаться выдачи приглашения.
Рисунок 009 Подключение к серверу mail.aport.ru· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400
Первые три символа возвращенной сервером строки представляют собой код завершения операции. Полный перечень кодов всевозможных ошибок содержится в RFC-821, и здесь не приводится.
Для передачи корреспонденции одного лишь TCP-соединения не достаточно, и необходимо установить еще одно, так называемое SMTP-соединение. Это достигается возвращением ответного приветствия серверу [193] с указанием имени узла клиента (если у него есть имя) или IP-адреса (если у клиента нет имени).
Далеко не всегда требуется указывать свой точный адрес. Часто достаточно ввести произвольную текстовую строку, например “ABDCEF”
· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400· HELO ppp-15.krintel.ru· 250 camel.mail.ru Hello ppp-15.krintel.ru [195.161.41.239]Ответное приветствие осуществляется командой “HELO [194]”. Сервер, установив SMTP-соединение, возвращает код успешного завершения операции (250) и в большинстве случаев определяет IP-адрес клиента или его доменное имя.Следующим шагом требуется указать отправителя сообщения. Для этого необходимо воспользоваться командой «MAIL FROM» с указанием собственного почтового адреса при желании заключенного в угловые скобки.Например:· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400· HELO ppp-15.krintel.ru· 250 camel.mail.ru Hello ppp-15.krintel.ru [195.161.41.239]· MAIL FROM:«[email protected]»· 250 «[email protected]» is syntactically correctЗатем указывается получатель сообщения, передаваемый с помощью команды “RCPT TO”, пример использования которой продемонстрирован ниже:· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400· HELO ppp-15.krintel.ru· 250 camel.mail.ru Hello ppp-15.krintel.ru [195.161.41.239]· MAIL FROM:«[email protected]»· 250 «[email protected]» is syntactically correct· RCPT TO:«[email protected]»· 250 «[email protected]» verified
При возникновении потребности в отправке одного и того же сообщения нескольким респондентам, достаточно вызвать “RCPT TO” еще один (или более) раз (максимальное количество получателей обычно не ограничено). Если кому-то из них сервер не возьмется доставить сообщение, он вернет ошибку, никак, однако не сказывающуюся на остальных получателях.
Команда “DATA”, вызываемая без аргументов, переводит сервер в ожидание получения текста письма.
· DATA· 354 Enter message, ending with "." on a line by itself
Последовательность завершения ввода представляет собой обыкновенную точку, «окаймленную» с двух сторон переносами строк. Если такая последовательность встретится в тексте сообщения, формирование письма будет немедленно завершено. Почтовые клиенты, обычно распознают такую ситуацию и прибегают к перекодировке, но при работе с telnet-клиентом эта забота ложиться на пользователя.
Пример использования команды “DATA” приведен ниже:
· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400· HELO ppp-15.krintel.ru· 250 camel.mail.ru Hello ppp-15.krintel.ru [195.161.41.239]· MAIL FROM:«[email protected]»· 250 «[email protected]» is syntactically correct· RCPT TO:«[email protected]»· 250 «[email protected]» verified· Hello, Sailor!·.· 250 OK id=12ZDEd-000Eks-00
Команда “QUIT” завершает сеанс и закрывает соединение.
· quit· 221 camel.mail.ru closing connection
Содержимое полученного сообщения (механизм получения сообщений на локальный компьютер пользователя рассмотрен в главах «Протокол POP» и «Протокол IMAP4») может выглядеть, например, следующим образом:
· From [email protected] Sun Mar 26 17:38:03 2000· Received: from ppp-15.krintel.ru ([195.161.41.239])· by camel.mail.ru with smtp (Exim 3.02 #107)· id 12ZDEd-000Eks-00· for [email protected]; Sun, 26 Mar 2000 17:37:59 +0400· Message-Id: «[email protected]»· From: [email protected]· Date: Sun, 26 Mar 2000 17:37:59 +0400·· Hello,Sailor!
Ниже будет показано, каким образом злоумышленники находят и используют чужие сервера исходящей почты. Один из способов поиска общедоступных SMTP-серверов заключается в анализе заголовков приходящей корреспонденции. Среди узлов, оставивших свои адреса в поле “Received”, порой встречаются сервера, которые не требуют аутентификации пользователя для отправки писем.
Например, ниже показан заголовок письма, вытащенного автором этой книги из его собственного почтового ящика:
· From [email protected] Wed Mar 22 16:57:03 2000
· Received: from gate.chiti.uch.net ([212.40.40.141])
· by msk2.mail.ru with esmtp (Exim 3.02 #116)
· id 12Xld1-0008jx-00
· for [email protected]; Wed, 22 Mar 2000 16:56:59 +0300
· Received: from 13.chiti.uch.net ([192.168.223.13])
· by gate.chiti.uch.net (8.8.8/8.8.8) with SMTP id PAA29678
· for «[email protected]»; Wed, 22 Mar 2000 15:51:47 +0200 (EET)
· From: "irt" «[email protected]»
Анализ заголовка позволяет установить, что письмо было отправлено с адреса 13.chiti.uch.net через сервер исходящей почты gate.chiti.uch.net. Если попробовать установить с ним соединение, то результат может выглядеть так:
· 220 gate.chiti.uch.net ESMTP Sendmail 8.8.8/8.8.8; Sun, 26 Mar 2000 16:21:53 +0300 (EEST)
Для проверки возможности пересылки сообщения необходимо послать серверу приглашение, а затем идентифицировать отправителя и получателя письма. Например, это может выглядеть так:
· 220 gate.chiti.uch.net ESMTP Sendmail 8.8.8/8.8.8; Sun, 26 Mar 2000 16:21:53 +0300 (EEST)· HELO kpnc.krintel.ru· 250 gate.chiti.uch.net Hello kpnc.krintel.ru [195.161.41.239], pleased to meet you· MAIL FROM:«[email protected]»· 250 «[email protected]»… Sender ok· RCPT TO:«[email protected]»· 250 «[email protected]»… Recipient ok
Код успешного завершения операции (250) и срока «Recipient ok» свидетельствуют о том, что сервер согласился на пересылку. Остается ввести текст послания и можно отправлять письмо. Спустя какое-то время (обычно не превышающее одной минуты) сообщение должно прийти по назначению. А его заголовок может выглядеть, например, так:
· From [email protected] Sun Mar 26 17:28:33 2000· Received: from gate.chiti.uch.net ([212.40.40.141])· by camel.mail.ru with esmtp (Exim 3.02 #107)· id 12ZD5a-000Dhm-00· for [email protected]; Sun, 26 Mar 2000 17:28:30 +0400· Received: from kpnc.krintel.ru (kpnc.krintel.ru [195.161.41.239])· by gate.chiti.uch.net (8.8.8/8.8.8) with SMTP id QAA02468· for «[email protected]»; Sun, 26 Mar 2000 16:22:44 +0300 (EEST)· (envelope-from [email protected])· Date: Sun, 26 Mar 2000 16:22:44 +0300 (EEST)· From: [email protected]· Message-Id: «[email protected]»
Жирным шрифтом выделен адрес отправителя, показывая, что он не смог остаться анонимным. Если это оказывается неприемлемо, среди входящих писем своего почтового ящика можно попробовать отыскать такие, в чьих заголовках нет никаких сведений об отправителе, за исключением той информации, которую он пожелал сообщить сам.
Один из анонимных серверов расположен (точнее, был когда-то расположен на момент написания этой главы) по адресу dore.on.ru. Однако его использование посторонними лицами запрещено, что и демонстрирует следующий эксперимент:
· 220 WITHELD FTGate server ready -Fox Mulder· HELO kpnc.krintel.ru· 250 Ready· MAIL FROM:«[email protected]»· 250 «[email protected]» Sender Ok· RCPT TO:«[email protected]»· 550 Relaying denied for «[email protected]»
Сервер, действительно, не делает никаких видимых попыток определить адрес клиента, но в то же время пересылать его корреспонденцию за пределы сервера наотрез отказывается. Причем достоверно известно, что владельцы этого сервера используют его для рассылки сообщений по нелокальным адресам. Отсюда вытекает существование механизма, позволяющего отличить «своих» от «чужих». Права «чужих» ограничиваются доставкой писем по локальным адресам, а «своим» разрешается отправлять сообщения и за пределы сервера. Ввиду отсутствия в протоколе SMTP средств аутентификации пользователей, отличить одних от других помогает IP адрес клиента. Локальные пользователи, находящиеся в одной подсети с сервером, считаются «своими», и наоборот [195].
