Атака на telnet и rlogin -сервера
Ø В этой главе:
Ø Ошибки реализации telnet-серверов
Ø Перехват пароля, передаваемого протоколом telnet
Ø Манипуляция переменными окружения
Ø Модификация файла rhosts
Сегодня протокол telnet используется в основном для удаленного администрирования, но, кроме этого, telnet‑серверы часто устанавливаются на многих служебных узлах сети, например, маршрутизаторах. Многие операционные системы, устанавливают telnet‑сервер по умолчанию, даже когда он совсем не нужен. Распространенность telnet не так уж и велика, но и он иногда становится объектом атак злоумышленников.
Как и любая другая программа, telnet‑сервер подвержен угрозе срыва стека, что позволяет выполнить на удаленной машине любой код или, по крайней мере, заблокировать сервер («завесить» его). Атаки, основанные на срыве стека, подробно описаны в главе «Технология срыва стека», здесь же будут рассмотрены уязвимости, характерные именно для telnet.
Кстати, относительная простота реализации telnet‑сервера и его медленное, эволюционное развитие, не испещренное внезапными глобальными изменениями и нововведениями, создают благоприятные условия для отлаживания кода, поэтому, грубые ошибки маловероятны, хотя и возможны.
Например, InterAccess TelnetD Server 4.0, работающий под управлением Windows NT, помещает имя, введенное пользователем при регистрации, в буфер фиксированного размера, но не контролирует его длину. Это позволяет злоумышленнику исполнить свой код на удаленном сервере. Сервер BFTelnet Server v1.1 содержит практически идентичную ошибку, за исключением того, что не позволяет злоумышленнику «подсунуть» свой код, но допускает «завешивание» системы.
Другой пример: если на CISCO 2621при включенном NAT (Network Address Translation) злоумышленник, находящийся во внешней сети, устанавливает TCP соединение во внутреннюю сеть по 23 порту, то система скидывает ласты. Эту ошибку впервые обнаружил Blue Boar, связаться с которым можно, написав по адресу [email protected]
Ошибки, описанные выше, демонстрируют принципиальную возможность атак на telnet‑службы, но уже давно неактуальны. Однако, помимо ошибок реализаций, сам протокол telnet содержит концептуальные уязвимости, две их которых рассмотрены ниже.
В базовой спецификации telnet‑протокола, декларированной в RFC‑854, не содержится никаких средств аутентификации. Пароль и имя пользователя посылаются открытым текстом (причем в зависимости от режима каждый символ может либо помешаться в отдельный пакет, либо в пакет упаковывается вся строка целиком, но, поскольку используется алгоритм Нагла, даже в символьном режиме пароль может быть передан всего в двух пакетах, подробнее об этом рассказано в главе «Протоколы telnet и rlogin»).
Если канал связи не защищен от прослушивания (а практически всегда так и есть), то злоумышленник, перехватив пакеты, сможет восстановить имя пользователя и пароль. Широковещательная среда локальных Ethernet сетей позволяет осуществить такой перехват без труда, а в глобальных сетях существует угроза «подмятия» DNS сервера и подмены адреса узла, с которым пользователь пытается установить соединение. Подробнее об этом рассказано в главе «Атака на DNS сервер», которая находится во втором томе настоящей книги.
Современные реализации telnet, однако, уже поддерживают шифрование паролей при аутентификации. Например, клиент от Windows 2000, поддерживает NTLM шифрование, которое достаточно надежно. Перехват канала связи не позволяет злоумышленнику восстановить пароль (подробнее об этом рассказано в главе «Атака на Windows NT»). Однако до сих пор во многих случаях на сервер передаются незашифрованные пароли, и вся атака сводится к их перехвату.
Другая уязвимость заключается в возможности клиента манипулировать переменными окружения сервера до аутентификации. Впервые такая возможность упоминается в RFC‑1408, затем в RFC‑1572, и поддерживается многими современными telnet‑серверами. Если атакующий имеет доступ к серверу на запись (например, на нем установлен ftp-сервис, позволяющий анонимному пользователю закачивать файлы), то изменением переменных окружения, таких, как PATH, легко добиться, чтобы вместо легальных программ, запускались программы злоумышленника. Таким образом, злоумышленник получает право удаленного запуска программ, от имени другого пользователя, а иногда и системы!
Известен случай, когда злоумышленник изменил стандартную Си-библиотеку libc, таким образом, чтобы при вызове некоторых функций активировался скрытый в ней троянский конь, который выполнял задуманные действия, а затем уничтожал модифицированную библиотеку, заметая следы. Затем он помещал ее в любой каталог, доступный для записи по ftp и с помощью telnet-сервера менял переменную окружения, указывающую путь к библиотечным файлам. Когда один из пользователей сервера компилировал очередную программу, линкер использовал подложенную библиотеку! Обнаружить такую атаку оказалось нелегко. Ведь злоумышленник выполнял легальные, не привлекающие внимания действия, а изучать откомпилированный код никому бы и в голову не пришло! На переменные же окружения редко кто обращает внимание, как и на захламленные каталоги incoming.
Но даже после этого случая далеко не все администраторы запретили удаленную модификацию переменных, поэтому, в сети существует множество узлов, уязвимых перед описанной атакой.
Сервера, поддерживающие протокол rlogin, значительно меньше распространены, но все же иногда встречаются. Аналогично ранним реализациям telnet, протокол rlogin передает пароль в открытом виде (если передает). Это позволяет похитить его тривиальным перехватом. Но, в отличие от telnet, с помощью rlogin нельзя войти на сервер с правами администратора. Такое ограничение уменьшает интерес злоумышленников, но, разумеется, не исключает возможности атаки.
В файле “.rhosts”, хранящемся на удаленном сервере, содержатся имена доверенных узлов, аутентификация которых не требуется. Если удастся каким-то образом модифицировать этот файл, например, используя ошибки реализаций других протоколов (а такая ситуация действительно, порой имеет место), злоумышленник сможет внести себя в список доверенных узлов и войти на сервер без предъявления пароля!
Точно так, если злоумышленник сумеет проникнуть в один из доверенных узлов (или в доверенный доверенного), он автоматически получит доступ на сервер. Часто администраторы оказываются не очень щепетильны в выборе своих «друзей» и доверяют плохо защищенным (или совсем не защищенным) узлам.
Таким образом, протоколы telnet и rlogin очень плохо защищены и могут быть подвержены атаке.
Атака на telnet-клиента
Ø В этой главе:
Ø Атака на штатного клиента Windows 95 (Windows 98)
Ø Использование ANSI драйвера для атаки
Ø Атака rlogin клиента лавиной срочной данных
Точно как и сервера, telnet‑клиенты подвержены угрозе срыва стека. В частности, telnet‑клиент, входящий в состав Windows 95, Windows 98 и даже Windows 98 SE, не проверяя длину аргументов командной строки, копирует ее в буфер фиксированного размера. Специальным образом подобранная строка позволяет злоумышленнику выполнить любой код на компьютере клиента.
Один из возможных способов атаки заключается в размещении на WEB страничке ссылки следующего вида: telnet://server.com/xxxxxxxx. Стоит жертве кликнуть по ней мышкой, как браузер автоматически запустит telnet‑клиента, передав ему аргументы в командной строке (поэтому не стоит кликать по чему попало – простым кликом можно подпустить лапти на свой компьютер).
Однако, присутствие одной и той же ошибки на клиенте всех трех платформ, возводит эту атаку, основанную на заурядном срыве стека, в ранг актуальных угроз. От пользователя не требуется никаких экзотических или настораживающих действий, большинство переходит по ссылкам, абсолютно не интересуясь их содержимым, поэтому значимость этой уязвимости для злоумышленников очень велика.
Подробнее об этом можно прочитать в Microsoft Security Bulletin (MS99‑033)[189]. Фирма Microsoft выпустила заплатки, которые находятся на ее сервере. Для Windows 95 здесь: http://www.microsoft.com/windows95/downloads/contents/WUCritical/Telnet/Default.asp, а для Windows 98 и Windows 98 SE здесь: http://www.microsoft.com/windows98/downloads/contents/WUCritical/Telnet/Default.asp . С 10 сентября 1999 года заплатки доступны и через Windows Update. Однако большинство пользователей оказалось не осведомлено об этой проблеме и лишь у немногих из них установлены необходимые обновления. Поэтому, возможность атаки все еще остается.
Если telnet‑клиент работает с драйвером ANSI, поддерживающим макрокоманды, то существует возможность выполнять любые команды на компьютере клиента. Однако, такая ситуация встречается достаточно редко. Большинство ANSI терминалов ограничиваются поддержкой цветов и дополнительных наборов символов, но не позволяют удаленному компьютеру передавать макросы.
Клиенты rlogin в силу своей простоты обычно не содержат грубых ошибок и в общем случае не могут быть атакованы. Однако некоторые реализации не ограничивают длину буфера запоминаемых данных. Клиенты rlogin, получив сигнал срочности, должны запоминать принимаемые данные до тех пор пока с последним байтом срочных данных не получат от сервера команду. Если же сервер злоумышленника станет забрасывать клиента огромным количеством бессмысленных данных, и «забудет» передать команду, то рано или поздно вся оперативная и виртуальная память клиента истощатся и наступят ласты. Впрочем, учитывая тот факт, что большинство клиентов не обладают быстрыми каналами потребуется чрезвычайно длительный промежуток времени чтобы эффект от такого воздействия стал заметным.
История вообще пишется ретроспективно, и чем дальше от описываемых событий, тем она выглядит значительнее и красивее.
Het Monster. Тринадцать врат
Протокол POP3
Ø В этой главе
Ø История возникновения POP3
Ø Основные команды
Ø Механизмы аутентификации
Ø Недостатки механизмов аутентификации
Ø Анализ заголовков сообщений
Ø Почтовый формат MIME
Протокол POP3 (Post Office Protocol version 3) был разработан для удаленного управления почтовыми ящиками и доставке корреспонденции с сервера-почтальона на компьютер клиента.
Лет десять – двадцать тому назад количество абонентов сети еще не измерялось астрономическими цифрами, а большинство узлов представляли собой круглосуточно работающие майнфреймы. Если возникала необходимость отправить письмо, устанавливали соединение с компьютером получателя, на котором был заведен особый, так называемый, «почтовый» файл и дописывали свое сообщение в его конец. В любое время получатель мог открыть этот файл средствами операционной системы и просмотреть его содержимое.
Но с разрастанием сети такой подход становился все менее и менее удобным: компьютер получателя мог быть перегружен или вовсе отсоединен от сети, – иной раз проходило немало времени, пока до него удавалось «достучаться». Сегодня подавляющее большинство абонентов Internet составляют «персональные» пользователи, которые не могут позволить себе держать круглосуточную связь и входят в сеть лишь на короткое время. Поэтому, появились специализированные почтовые сервера, занимающиеся приемом и накоплением почты. В любой момент пользователь мог подсоединиться к такому серверу и разом принять всю поступившую на его имя корреспонденцию. Несмотря на то, что существующие протоколы позволяли осуществить такое взаимодействие без труда, необходимость стандартизации общения клиента с сервером, привела к возникновению новых, узкоспециализированных протоколов.
Наибольшую популярность на сегодняшний день завоевал протокол POP3, который поддерживает несколько простейших команд, обеспечивающих базовые операции управления почтовым ящиком и доставку почты на локальный компьютер, перекладывая все заботы по ее обработке клиентскому программному обеспечению.
Протокол POP3 ведает исключительно доставкой корреспонденции с сервера на компьютер клиента, а отправкой почты занимаются другие протоколы (как правило, для этой цели используется протокол SMTP, описанный в одноименной главе).
Здесь не будут рассматриваться механизмы регистрации нового клиента на сервере, поскольку обсуждение этого вопроса выходит за рамки возможностей протокола POP3. Для всех последующих экспериментов необходимо иметь уже существующий почтовый ящик, причем, желательно непустой (а, если писем все нет и нет, на худой конец можно послать пару сообщений самому себе).
Врезка «для начинающих» *
Множество серверов предоставляют бесплатный почтовый сервис с доступом по POP3. Хорошо себя зарекомендовали www.chat.ru, www.mail.ru, www.freemail.ru, www.null.ru и многие другие.
Для всех экспериментов, описанных ниже, необходимо подключится к почтовому серверу любым telnet‑клиентом, например, тем, который входит в поставку Windows 95 (Windows 98). Эту операцию можно осуществить, выполнив следующие шаги: выбрав пункт «Параметры» меню «Терминал», установить галочку «Отображение ввода»; затем вызвать диалог «Подключение», активировав пункт «Удаленная система» меню «Подключить»; в поле «Имя узла» указать адрес сервера, с которым требуется установить соединение, а в поле «Порт» задать сто десятый порт или символьное наименование протокола “POP3”.
Если используется telnet‑клиент из поставки Windows 2000, то подготовительные операции могут выглядеть так: нажатие комбинации клавиш “<Ctrl-]>” переводит клиента в командный режим, где команда “set LOCAL_ECHO” включает локальное эхо-отображение символов; вызов “open имя узла 110” устанавливает соединение с выбранным узлом по 110 порту и автоматически переводит клиента в рабочий режим.
Оба клиента запоминают последнюю используемую конфигурацию и в дальнейшем их можно вызывать из командной строки, например, следующим образом: “telnet.exe имя узла 110”.
Рисунок 008 Подключение к почтовому серверу
Если адрес сервера и порт указаны правильно, а сам сервер не находится в глубоком «дауне», через некоторое время (в зависимости от загруженности и скорости канала связи) будет установлено TCP‑соединение, и на экране появится приветствие, приглашающее к началу работы (смотри рисунок 000).
Содержимое приветствия может варьироваться в широких пределах. Так, например, в приведенном примере сервер возвратил название и версию реализации программного обеспечения.
С этого момента сервер готов принимать запросы пользователя, если же тот в течение длительного времени не проявит никакой активности, соединение будет разорвано (на жаргоне это звучит «выгнали по тайм-ауту»). Чаще всего время бездействия ограничивается десятью минутами, но администраторы некоторых интенсивно используемых серверов, иногда уменьшают его до десятков секунд!
Рисунок 000 Приветствие сервера
В дальнейшем, дабы не приводить расточительные копии экрана, в книге будет использоваться содержимое окна telnet, представленное в удобочитаемой текстовой форме. Во избежание путаницы, команды, набираемые пользователем, будут выделяться таким, а ответы сервера - таким шрифтом.
Сразу же с момента выдачи приглашения сервер переходит в состояние аутентификации (Authorization state) – ожиданию имени пользователя и пароля, открывающего доступ к почтовому ящику. Команда «user» служит для передачи имени пользователя, которое должно быть отделено от команды пробелом. Например, это может выглядеть так:
· +OK QPOP (version 2.52) at mail.computerra.ru starting.
· USER ORION
· +OK Password required for user ORION
Если сервер подтверждает наличие указанного пользователя в системе, он требует сообщить пароль. Для передачи пароля предусмотрена команда “PASS”. В отличие от имени пользователя, пароль необходимо вводить с соблюдением регистра – в большинстве случаев (но не всегда) строчечные и заглавные символы различаются. Ниже приведен пример аутентификации пользователя с регистрационным именем “Orion” и паролем “Ngc1976”:
· +OK QPOP (version 2.52) at mail.computerra.ru starting.
· USER ORION
· +OK Password required for user ORION
· PASS Ngc1976
· +OK ORION's maildrop has 4 messages (789046 octets)
Если сервер подтверждает корректность пароля, он открывает доступ к ящику и сразу же информирует о его состоянии. В приведенном выше примере в ящике содержатся четыре письма с общим объемом в 789 046 байт[190].
Врезка «замечание»
При перегрузке сервер может разорвать соединение, попросив пользователя повторить попытку немного позже.
Например:
· -ERR Unable to service you now. Try again later. If problem persist, contact system administrator
Иногда, по каким-то причинам почтовый ящик бывает временно недоступен. К примеру, при разрыве соединения, сессия с пользователем может удерживаться до десяти (а иногда и свыше тридцати!) минут – в течение этого времени попытки входа на ящик будут блокироваться.
В случае несовпадения пароля сервер, выдержав паузу (предусмотренную для предотвращения перебора паролей), сообщит об ошибке и разорвет соединение. Например, это может выглядеть так:
· +OK QPOP (version 2.52) at mail.computerra.ru starting.
· USER ORION
· +OK Password required for user ORION
· PASS M42
· -ERR Password supplied for "ORION" is incorrect
С момента подтверждения корректности пароля, сервер переходит в, так называемое, состояние транзакции (Transaction state), и ожидает от пользователя команд управляющих почтовым ящиком или доставляющих корреспонденцию на его локальный компьютер.
С пересылкой сообщений связано одно существенное ограничение протокола POP3, которое особенно неприятно для неанглоязычных корреспондентов. Стремясь увеличить скорость обмена между сервером и клиентом, американские разработчики (а протокол POP3 разработали именно они) решили пожертвовать одним битом, отводя на каждый символ семь бит, вместо положенных восьми.
Врезка «замечание»
По причине семибитной кодировки протокола POP3 объем сообщений стало удобнее измерять не в байтах, а в октетах. Следующий пример позволяет продемонстрировать, в чем заключается различие.
Пусть, передается приветствие “Hello, my world!”, занимающее шестнадцатьбайт. Но, в силу обрезания одного бита, по сети физически будет передан о только 16 х 7 = 112 бит или 112 / 8 = 14 – четырнадцать октетов.
Тем не менее, это не мешает считать байты и октеты тождественно равными друг другу, если идет речь об объеме информации, передаваемой от одного узла к другому. Технически безграмотно, но удобно.
Английский алфавит вместе со всеми спецсимволами и знаками препинания полностью умещается в первой половине таблицы ASCII, но передача кириллицы приводит к значительным искажениям текста: в каждом символе старший бит окапается обрезанным.
Например:
· Исходный текст:
· Я Крипер ... поймай меня, если сможешь
· Тот же текст, в каждом байте которого, обрезан старший бит:
· X x`(/%` ... /.), ) ,%-o, %a+( a,.&%hl
Поэтому, первые эксперименты с почтовым ящиком, описанные этой главе, проводятся с англоязычными письмами, не содержащими ни одного символа кириллицы. (Использование национальных алфавитов сопряжено с хитроумными алгоритмами, которые будут описаны несколько позднее).
Для получения списка сообщений, хранящихся в почтовом ящике, предусмотрена команда “LIST”, пример использования которой продемонстрирован ниже:
· +OK QPOP (version 2.52) at mail.computerra.ru starting.
· LIST
· +OK 4 messages (789046 octets)
· 1 4363
· 2 6078
· 3 4933
· 4 4644
· .
Чтение корреспонденции осуществляется командой “RETR” с указанием номера выбранного сообщения.
Например:
· RETR 1
· +OK 1254 octets
· From [email protected] Mon Feb 14 22:07:48 2000
· Received: from baldrick.eia.brad.ac.uk ([143.53.48.11])
· by camel.mail.ru with esmtp (Exim 3.02 #107)
· id 12KQqZ-000AmG-00
· for [email protected]; Mon, 14 Feb 2000 22:07:47 +0300
· Received: by baldrick.eia.brad.ac.uk (8.9.3/8.9.0) id TAA21004;
· Mon, 14 Feb 2000 19:04:23 GMT
· Date: Mon, 14 Feb 2000 19:04:23 GMT
· Message-Id: <[email protected]>
· To: Kris Kaspersky <[email protected]>
· From: Bradford Robotic Telescope <[email protected]>
· Errors-To: Bradford Robotic Telescope <[email protected]>
· Subject: Registration
· Reply-To: [email protected]
·
· This is an automatic message.
·
· Thank you for registering as a guest user with the Bradford Robotic Telescope.
·
· In order to verify yourself you need to go to the following URL within the next 7 days.
· If you do not go to this URL your guest user status will be removed.
· Once verified you can also enter jobs for the telescope.
·
· To verify yourself, use your Web browser to go to the following address:
· http://www.telescope.org/rti/exp/kpnc/6606
· Your details:
· [48] kpnc
· Email address: [email protected]
· Institution: Desolate
·
·
· The URL for the telescope main menu: http://www.telescope.org/
· If you ever forget your password: http://www.telescope.org/rti/cpass/c.cgi
· .
Ответ сервера состоит из следующих частей:
· строки статуса
· заголовка письма
· тела письма
· завершающей письмо точки
Строка статуса указывает на успешность (неуспешность) операции и может принимать значение либо “+OK”, либо “+ERR” соответственно.
Более сложную структуру имеет заголовок письма. Современные почтовые клиенты скрывают от пользователя большую часть его содержимого. А жаль! Порой заголовок содержит много интересного и даже способен выдать маленькие тайны отправителя письма.
Заголовок состоит из полей – ключевых слов и параметров, разделенных знаком двоеточия. Существуют поля двух видов. Одни формируются отправителем письма (или его почтовым клиентом), а вторые – серверами, обрабатывающими письмо в ходе его отправления – доставки.
Существует возможность подделки и фальсификации содержимого заголовка. Так, поле обратного адреса заполняется отправителем и может указывать куда угодно. Аналогичным образом заголовок может быть искажен во время пересылки письма (в главе «Анонимная рассылка корреспонденции» показано, как написать простейший скрипт, умеющий пересылать письма с уничтожением или фальсификацией всей информации об отправителе). Поэтому, никогда нельзя полагается на достоверность заголовка, но не стоит забывать о скидке «на дурака» – далеко не каждый пользователь умеет грамотно подделывать заголовки.
Первым в заголовке обычно указывается поле ‘Received’, вставляемое транзитными серверами, пересылающими почту. Какова роль промежуточных узлов? Не проще ли устанавливать соединение непосредственно с почтовым сервером получателя? Да, когда-то именно так все и происходило, но с ростом потока сообщений пришлось усложнить схему пересылки. Появились серверы – ретрансляторы, специализирующиеся на пересылке почты. Подробнее о них рассказано в главах «Протокол SMTP» и «Почтовый сервер изнутри».
Содержимое поля “Received” произвольно и меняется от сервера к серверу. В той или иной форме оно должно указывать на адреса серверов отправившего и получившего письмо с сообщением времени отправления - доставки.
Каждый последующий сервер в цепочке добавляет новую запись в начало заголовка, и самая верхняя строка оставляется почтовым сервером адресата, получившим письмо. В приведенном выше примере она выглядит так:
· Received: from baldrick.eia.brad.ac.uk([143.53.48.11])
· by camel.mail.ruwith esmtp (Exim 3.02 #107)
· id 12KQqZ-000AmG-00
· for [email protected]; Mon, 14 Feb 2000 22:07:47 +0300
Анализ заголовка позволяет установить, что в приведенном примере, сообщение было передано сервером baldrick.eia.brad.ac.uk(в скобках указан его IP адрес), но… удивительно, кем оно было получено! В заголовке значится доменное имя camel.mail.ru, принадлежащее популярной бесплатной службе mail.ru, а пути немотивированного возникновения письма на сервере mail.computerra.ru становятся весьма загадочными. Вероятно, заголовок был модифицирован, – удалена, по крайней мере, одна строка. Действительно, изначально письмо адресовалось [email protected]. Оно было благополучно доставлено адресату, но хитрый mail.computerra.ru перебросил его в свой ящик, ни словом не обмолвившись этим фактом в заголовке. Впрочем, сервера с таким поведением большая редкость.
Врезка «замечание»
Две бесплатные почтовые службы mail.ru и aport.ru на самом деле являются одной службой в разных лицах!
Следующее (и последнее в цепочке) поле “Received” содержит адрес сервера-отправителя, но не сообщает никакой информации о самом отправителе. Поэтому достоверно определить кем было отправлено письмо не представляется возможным.
· Received: by baldrick.eia.brad.ac.uk (8.9.3/8.9.0) id TAA21004;
· Mon, 14 Feb 2000 19:04:23 GMT
Если собственноручно добавить к заголовку еще одно поле “Received” с некоторой информацией и передать письмо на baldrick.eia.brad.ac.uk, то получатель, анализируя заголовок, извлечет последнюю строчку «Received», содержащую подложный адрес. Подробнее о фальсификации содержимого поля “Received” рассказано в главе «Анонимная рассылка корреспонденции».
Поле «Data» заполняется сервером-отправителем сообщения, но его достоверность не гарантирована, ведь злоумышленник способен передать письмо непосредственно на ретранслятор от имени почтового сервера-отправителя.
Поле «Message-Id» служит для идентификации сообщений, позволяя из одних писем ссылаться на другие. Для обеспечения непротиворечивости каждый идентификатор должен быть уникален для всей сети Internet, то есть необходимо гарантировать существование всего лишь одного письма с данным идентификатором. Но как можно согласовать работу множества несвязанных друг с другом серверов? Организовать банк данных, отслеживающий все выданные идентификаторы возможно только теоретически. Но, поскольку каждый сервер обладает уникальным IP адресом (и, вероятнее всего, доменным именем), достаточно включить его в идентификатор, дополнив уникальной для данного сервера последовательностью, что обеспечит единственность такой комбинации во всей сети. Поэтому, идентификатор обычно состоит из имени узла-отправителя сообщения и буквенно-числовой последовательности, как правило[191], включающей в себя дату и время пересылки сообщения.
Ниже приведен пример типичного идентификатора (локальная уникальная последовательность выделена жирным шрифтом):
· Message-Id: <[email protected]>
Поле “From:” содержит обратный адрес отправителя сообщения, который пожелал оставить сам отправитель. При отправке письма сервер проверяет лишь синтаксическую корректность содержимого поля “From”, но не гарантирует подлинность представленных данных. Так, в приведенном примере, отправитель создает впечатление, что он находится на узле telescope.org, но анализ идентификатора Message-Id позволяет установить истинный адрес сервера-отправителя.
· From [email protected] Mon Feb 14 22:07:48 2000
· ...
· Message-Id: <[email protected]>
Такое поведение не является чем-то ненормальным, поскольку для посылки и приема сообщений допускается использовать разные серверы, но в то же время это создает возможность фальсификации адреса отправителя с целью рассылки корреспонденции от чужого имени. Подробнее о подделке заголовков сообщений рассказывается в главе «Анонимная рассылка корреспонденции».
Поле “To” указывает на получателя сообщения и состоит из двух частей – имени пользователя и адреса узла почтового сервера получателя. В общем виде оно выглядит так: username@servername. В качестве имени сервера допускается использовать его IP адрес, например: [email protected]
Все остальные поля являются факультативными и заполняются отправителем сообщения по желанию.
Тело письма отделено от заголовка одной пустой строкой и завершается точкой. В простейшем случае тело сообщения представляет собой читабельный ASCII текст, не требующий дополнительной перекодировки. Передача символов кириллицы невозможна без дополнительных ухищрений, о которых наступило время рассказать.
Существует огромное множество самых разнообразных форматов, из которых ниже будет в общих чертах рассмотрен лишь один – самый популярный из них MIME-формат (Multipurpose Internet Mail Extensions). Сообщение, закодированное в формате MIME, может выглядеть следующим образом:
· From [email protected] Fri Mar 03 23:32:48 2000
· Received: from pol-156.polaris-int.ru ([195.94.226.156] helo=mail.agama.com)
· by mx4.mail.ru with esmtp (Exim 3.02 #116)
· id 12Qvxa-0004PG-00
· for [email protected]; Fri, 03 Mar 2000 20:33:55 +0300
· Received: from 195.94.226.130 - 195.94.226.130 by mail.agama.com with Microsoft SMTPSVC(5.5.1774.114.11);
· Fri, 3 Mar 2000 20:13:13 +0300
· Received: from agama.com ([195.94.226.130])
· by "eMedia e-mail list robot" <[email protected]>
· with SMTP id <D0000028149.MSG>; Fri, 3 Mar 2000 20:10:17 +0300
· Received: from [195.94.226.155] by agamaweb.agama.com (NTMail 4.01.0008/AB3703.63.3e8112ca) with ESMTP id dvmhaaaa for <[email protected]>; Fri, 3 Mar 2000 20:11:07 +0300
· Message-ID: <[email protected]>
· From: "emedia" <[email protected]>
· Date: Fri, 3 Mar 2000 20:10:17 +0300
· MIME-Version: 1.0
· Content-Type: multipart/alternative;
· boundary="----=_NextPart_000_008D_01BF854C.7E35D890"
· X-Priority: 3
· X-MSMail-Priority: Normal
· X-Mailer: Microsoft Outlook Express 5.00.0810.800
· X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
· Subject: =?windows-1251?B?xOv/IMLg8Swg9+jy4PLl6/zt6Pb7?=
· Errors-To: [email protected]
· Reply-To: "" <[email protected]>
· To: [email protected]
· This is a multi-part message in MIME format.
·
· ------=_NextPart_000_008D_01BF854C.7E35D890
· Content-Type: text/plain;
· charset="windows-1251"
· Content-Transfer-Encoding: quoted-printable
·
· =C4=EE=F0=EE=E3=E8=E5 =F7=E8=F2=E0=F2=E5=EB=FC=ED=E8=F6=FB!=20
·
· =D0=E5=E4=E0=EA=F6=E8=FF =E6=F3=F0=ED=E0=EB=E0 eMedia www.emedia.ru =
· =EE=F2 =E2=F1=E5=E9 =E4=F3=F8=E8 =EF=EE=E7=E4=F0=E0=E2=EB=FF=E5=F2 =
· =C2=E0=F1 =F1 =ED=E0=F1=F2=F3=EF=E0=FE=F9=E8=EC =
· =EF=F0=E0=E7=E4=ED=E8=EA=EE=EC =E2=E5=F1=ED=FB =E8 =EB=FE=E1=E2=E8 - 8 =
· =CC=E0=F0=F2=E0.=20
· =C6=E5=EB=E0=E5=EC =C2=E0=EC =EC=EE=F0=E5 =F6=E2=E5=F2=EE=E2 =E8 =
· =F1=F7=E0=F1=F2=FC=FF =ED=E5 =F2=EE=EB=FC=EA=EE =E2 =FD=F2=EE=F2 =
· =E4=E5=ED=FC, =ED=EE =E8 =E2=EE =E2=F1=E5=E9 =C2=E0=F8=E5=E9 =
· =E6=E8=E7=ED=E8!!!
· =D7=E8=F2=E0=E9=F2=E5 =ED=E0=F8 =E6=F3=F0=ED=E0=EB, =E8 =
· =EF=F0=E5=EA=F0=E0=F1=ED=EE=E5 =E2=E5=F1=E5=ED=ED=E5=E5 =
· =ED=E0=F1=F2=F0=EE=E5=ED=E8=E5 =C2=E0=EC =EE=E1=E5=F1=EF=E5=F7=E5=ED=EE. =
·
·
· =C8=F2=E0=EA, =E2 12-=EE=EC =ED=EE=EC=E5=F0=E5:
·
· =CF=EE=E4=E0=F0=EA=E8 =EA 8 =EC=E0=F0=F2=E0 =F7=E5=F0=E5=E7 =
· =F2=E5=EB=E5=F4=EE=ED =E8 =EC=EE=E4=E5=EC=20
·
· =C3=EB=FF=E4=FF =ED=E0 =EE=E3=F0=EE=EC=ED=FB=E5 =EE=F7=E5=F0=E5=E4=E8 =
· =E2 =EC=E0=E3=E0=E7=E8=ED=E0=F5, =F2=EE=EB=EF=FB =EC=F3=E6=F7=E8=ED =F3 =
· =EF=F0=E8=EB=E0=E2=EA=EE=E2 =F1 =EF=E0=F0=F4=FE=EC=E5=F0=E8=E5=E9, =
· =ED=E5=E1=FB=E2=E0=EB=FB=E5 =F6=E5=ED=FB =ED=E0 =
· =E1=E5=E7=E4=E5=EB=F3=F8=EA=E8 =E8 =E6=E8=E2=FB=E5 =F6=E2=E5=F2=FB, =
· =E2=FB =F3=E6=E5 =E4=E0=E2=ED=EE =E4=EE=EB=E6=ED=FB =E1=FB=EB=E8 =E1=FB =
· =EF=EE=ED=FF=F2=FC, =F7=F2=EE =EE=EF=FF=F2=FC =F7=F3=F2=FC =ED=E5 =
· =E7=E0=E1=FB=EB=E8 =EF=F0=EE 8 =EC=E0=F0=F2=E0. =C4=E0=E2=E0=E9=F2=E5 =
· =EF=EE=F1=EF=E5=F8=E8=EC, - =F1 =ED=EE=E2=FB=EC=E8 =
· =F2=E5=F5=ED=EE=EB=EE=E3=E8=FF=EC=E8 =EC=FB =F2=E5=EF=E5=F0=FC =E2=F1=E5 =
· =F3=F1=EF=E5=E5=EC.
· http://www.emedia.ru/n12/8.asp=20
·
·
· =D1=CE=C1=DB=D2=C8=DF
· .
Поле “MIME-Version: 1.0” (в тексте оно выделено жирным шрифтом) указывает на способ кодирования сообщения.
Пара символов, расположенных справа от знака равенства, интерпретируется как шестнадцатеричный код символа исходного текста. Такая кодировка получила название “quoted‑printable” и завоевала широкое распространение. Она удобна тем, что символы первой половины таблицы ASCII [0x0 – 0x7F] представлены в своем естественном виде. Это сохраняет читабельность англоязычных сообщений, но оказывается крайне неэкономичным при кодировании кириллицы, – почти каждый символ исходного текста заменяется тремя, отчего письмо здорово «распухает». Но даже такая избыточность ничуть не уменьшает популярности формата MIME.
Ниже показано, как можно расшифровать такое сообщение. Для этого потребуется любой шестнадцатеричный редактор, например, QVIEW. Запустите его и перейдите в режим открытия файла <ALT-F6>, выберете «Новый файл» нажатием клавиши <F4> и назовите его, например, «letter.txt». Затем, разрешите редактирование его содержимого нажатием клавиши <F3>. До начала расшифровки необходимо выбрать соответствующую кодировку (выбор кодировки в QVIEW осуществляется нажатием клавиши <F6>). Вид кодировки, используемой при написании письма, содержится в его заголовке[192]. В данном случае это “windows‑1251” (в тексте она выделена жирным шрифтом):
· Content-Type: text/plain;
· charset="windows-1251"
Если теперь в правом окне начать вводить шестнадцатеричные значения символов, в левом окне станет появляться исходный текст письма (смотри рисунок 006):
Рисунок 006 Декодирование сообщения, переданного в формате MIME
Детальное описание формата MIME выходит за пределы данной книги, но может быть найдено в техническом руководстве RFC-1341.
Врезка «для начинающих» *
Что такое RFC (Request For Comments)? В силу открытости архитектуры сети Internet и необходимости поддерживать общие соглашения между независимыми разработчиками появился набор стандартов и соглашений, доступный для массового использования.
Любой разработчик имеет право внести свое предложение. Оно будет подвергнуто тщательной экспертной оценке и, если не встретит никаких возражений, будет добавлено в RFC.
За каждым соглашением закреплен определенный номер, так, например, POP3 протокол описывается в RFC-1081, RFC-1082, RFC-1225, RFC-1725, RFC-1939.
Для удаления сообщений из почтового ящика предусмотрена команда “DELE”, которая принимает в качестве аргумента порядковый номер уничтожаемого сообщения. Один из примеров ее использования продемонстрирован ниже:
· +OK QPOP (version 2.52) at mail.computerra.ru starting.
· LIST
· +OK 4 messages (789046 octets)
· 1 4363
· 2 6078
· 3 4933
· 4 4644
· .
· DELE 1
· +OK message 1 deleted
· LIST
· +OK 3 messages (16655 octets)
· 2 6078
· 3 4933
· 4 4644
· .
Внимание: непосредственно после операции удаления перенумерации сообщений не происходит! Т.е. уничтоженное сообщение просто «выпадает» из списка, а следующие за ним сообщение не занимает этот индекс, и не сдвигается вверх. Сообщения будут перенумерованы только при следующем сеансе работы с сервером.
Сеанс завершает команда “QUIT”. Сервер переходит в состояние обновления транзакции (transaction update) и разрывает соединение. Выглядеть это может следующим образом:
· +OK QPOP (version 2.52) at mail.computerra.ru starting.
· QUIT
· +OK POP3 server at mail.ru signing off
Если до обновления транзакции произойдет обрыв соединения, сервер выполнит откат транзакции, т.е. приведет почтовый ящик в тот вид, каким он был до начала последнего сеанса связи и все удаленные сообщения окажутся восстановленными (вернее, правильнее было бы сказать, не удаленными, поскольку команда “DELE” физически не уничтожает письма, а лишь помечает их для удаления, которое происходит в процессе обновления транзакции; если же связь оборвется, и обновление транзакции не будет выполнено, – все сообщения так и остаются не удаленными).
Ниже будут рассмотрены некоторые дополнительные возможности протокола POP3. Для проведения описанных экспериментов потребуется подключиться к серверу, поддерживающему такие расширения. Одним из подходящих серверов является бесплатная служба электронной почты mail.ru.
Рисунок 007 Подключение к серверу mail.ru
После успешного установления TCP-соединения, сервер mail.ru возвращает приглашение, содержащее уникальный идентификатор (на рисунке 004 он обведен вокруг пером):
Рисунок 004 Приглашение сервера mail.ru
Выше уже отмечалась незащищенность пароля, открытым текстом передаваемого по сети. Если злоумышленник перехватит информационный поток, он сможет восстановить оригинальный пароль и вплоть до его смены несанкционированно проникать в систему. Для аутентификации, осуществляемой по нестойким к подслушиванию каналам связи, были разработаны специальные алгоритмы, которые обеспечивают однонаправленное шифрование и постоянную смену паролей.
Один из таких алгоритмов, именуемый «запрос-отклик», работает следующим образом: сервер посылает клиенту случайную последовательность условно именуемую меткой. Клиент зашифровывает ее, используя в качестве ключа свой пароль, и полученный результат отправляет серверу. При этом алгоритм шифрования специальным образом подобран так, чтобы, зная зашифрованный пароль и метку, было бы невозможно найти ключ шифрования иначе, чем прямым перебором. Затем сервер самостоятельно шифрует метку хранящимся у него паролем пользователя и сравнивает полученные результаты. Если они идентичны, следовательно, пользователь ввел правильный пароль и наоб