7 (Ответики к экзамену), страница 4

Протокол SMTP хорош, когда обе машины находятся в Internet. Однако это не всегда так. Многие компании в целях сетевой защиты соединяют свои сети через надлежащие средства, либо используют другие протоколы. Например, отправитель или получатель могут использовать протокол Х.400. Такая ситуация показана на рисунке 7-55. Отправитель передает сообщение шлюзу, тот его буферизует и позднее передает получателю. Звучит просто, но на деле все сложнее. Первая проблема – соответствие адресов. Вторая – соответствие конвертов и заголовков. Третья – соответствие тела сообщения. Например, в случае, если тело содержит аудиофайл, а на стороне получателя с ним работать не умеют. Или отправитель поставил следующее условие: если передача сообщения не пройдет по почтовому соединению, то нужно повторить его по факсу, а получатель не умеет работать с факсом. Однако для простых неструктурированных ASCII-сообщений SMTP-шлюз – решение проблемы.

7.4.4.3. Доставка получателю

До сих пор мы предполагали, что машина пользователя может и отправлять сообщения, и получать их. Однако часто машина пользователя – это персональный компьютер или ноутбук, которая время от времени связывается с почтовым сервером, чтобы отправить или получить почту. Как это происходит? Простой протокол для изъятия почты из удаленного почтового ящика – РОР3 (Post Office Protocol – RFC 1225). Он позволяет входить в удаленную систему и выходить из нее, передавать письма и принимать их. Главное - он позволяет забирать почту с сервера и хранить ее на машине пользователя.

Более сложный протокол IMAP – Interactive Mail Access Protocol (RFC 1064). Он позволяет одному и тому же пользователю заходить с разных машин на сервер, чтобы прочесть или отправить почту. Это по существу удаленное хранилище писем. Он, например, позволяет получать доступ к письму не только по его номеру, но и по содержанию.

Третий часто используемый протокол – DMSP (Distributed Mail System Protocol RFC 1056). Этот протокол не предполагает, что пользователь работает все время с одной и той же почтовой службой. Пользователь может обратиться к серверу и забрать почту на свою локальную машину, после чего разорвать соединение. Обработав почту, он может ее отправить позже, когда будет установлено очередное соединение.

Важными почтовыми сервисами являются:

• Фильтры

• Пересылка поступающей почты на другие адреса

• Демон отсутствия

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

7.4.5. Конфиденциальность почты

Пославший почту, естественно, предполагает, что ее никто не читает кроме адресата. Однако если об этом специально не позаботиться, то гарантировать этого нельзя. Далее мы рассмотрим две широко распространенных безопасных почтовых системы - PGP и PEM.

PGP – Pretty Good Privacy

PGP – дословно: «вполне хорошая конфиденциальность» – разработка одного человека - Фила Зиммермана (Phil Zimmermann, 1995). Это полный пакет безопасности, который включает средства конфиденциальности, установления подлинности, электронной подписи, сжатия, и все это в удобной для использования форме.PGP использует алгоритмы шифрования RSA, IDEA и MD5. PGP поддерживает компрессию передаваемых данных их секретность, электронную подпись и средства управления доступом к ключам. Схема работы PGP показана на рисунке 7-56. На этом рисунке DA, DB - личные (закрытые) ключи А и В соответственно, а EA, EB – их открытые ключи. Отметим, что секретный ключ для IDEA строится автоматически в ходе работы PGP на стороне А и называется ключом сессии - KM, который затем шифруется алгоритмом RSA с открытым ключом пользователя В. Также следует обратить внимание на то, что медленный алгоритм RSA используется для шифрования коротких фрагментов текста: 128-разрядного ключа для MD5 и 128-разрядного ключа для IDEA.

PEM – почтовая служба с повышенной конфиденциальностью

PEM имеет статус Internet-стандарта (RFC 1421, 1424). Сообщения, пересылаемые с помощью PEM, сначала преобразуются в каноническую форму. В этой форме соблюдены соглашения относительно спецсимволов типа табуляции, последовательных пробелов и т.п. Затем сообщение обрабатывается MD5 или MD2, шифруется с помощью DES (56-разрядный ключ) и передается с помощью кодировки base64. Передаваемый ключ защищается либо с помощью RSA, либо с помощью DES по схеме EDE.

7.5. Протокол передачи файлов - FTP

FTP (File Transfer Protocol, Протокол передачи данных) - это один из первых и все еще широко используемых интернет-сервисов. Первые спецификации FTP относятся к 1971 году. С тех пор FTP претерпел множество модификаций и значительно расширил свои возможности.

Протокол FTP предназначен для решения следующих задач:

• разделение доступа к файлам на удаленных абонентских машинах

• прямое или косвенное использования ресурсов удаленных компьютеров

• обеспечение независимости клиента от файловых систем удаленных абонентских машин

• эффективная и надежная передача данных

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

7.5.1. Модель работы FTP

Простейшая модель работы протокола FTP представлена на рисунке 7-59, где введены следующие обозначения:

• «User Interface» - пользовательский интерфейс работы с FTP.

• «User-PI» - интерпретатор команд пользователя (User Protocol Interpretator). Этот объект взаимодействует с «Server-PI», чтобы обмениваться командами управления передачей данных по каналу передачи команд и с «User-DTP» - модулем, который осуществляет непосредственную передачу данных по каналу передачи данных.

• «User-DTP» - модуль, осуществляющий обмен данными (User Data Transfer Process) между клиентом и сервером FTP по каналу передачи данных на основании команд модуля «User-PI». Этот объект взаимодействует с файловой системой пользователя и объектом «Server-DTP».

• «Server-PI» - модуль управления обменом данных со стороны сервера (Server Protocol Interpretator) по каналу передачи команд.

• «Server-DTP» - модуль, осуществляющий обмен данными со стороны сервера (Server Data Transfer Process) по каналу передачи данных

• «Сервер FTP» - модуль, осуществляющий работу FTP-сервера. Он состоит из модуля управления передачей - «Server-PI» и модуля, осуществляющего передачу, - «Server-DTP».

• «Пользователь FTP» - модуль клиента FTP. Он состоит из модуля управления передачей - «User-PI» - и модуля, осуществляющего передачу - «User-DTP».

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

Алгоритм работы протокола FTP состоит в следующем:

1. Сервер FTP использует в качестве управляющего соединение на TCP порт 21, который всегда находится в состоянии ожидания соединения со стороны FTP-клиента.

1. После того как устанавливается управляющее соединение модуля «User-PI» с модулем сервера - «Server-PI», клиент может отправлять на сервер команды. FTP-команды определяют параметры соединения передачи: роли участников соединения (активный или пассивный), порт соединения (как для «User-DTP», так и для «Server-DTP»), тип передачи, тип передаваемых данных, структуру данных и управляющие директивы, обозначающие действия, которые пользователь хочет совершить, например, сохранить, считать, добавить или удалить данные или файл.

1. После того как согласованы все параметры канала передачи данных, один из участников соединения, который является пассивным (например, клиентский модуль «User-DTP»), становится в режим ожидания открытия соединения на заданный для передачи данных порт. После этого активный модуль (например, «Server-DTP») открывает соединение и начинает передачу данных.

1. После окончания передачи данных соединение между «Server-DTP» и «User-DTP» закрывается, но управляющее соединение «Server-PI» - «User-PI» остается открытым. Пользователь, не закрывая сессии FTP, может еще раз открыть канал передачи данных, передать необходимую информацию и т.д.

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

Основу передачи данных FTP составляет механизм установления соединения между соответствующими портами и механизм выбора параметров передачи. Каждый участник FTP-соединения должен поддерживать 21 порт передачи данных по умолчанию. По умолчанию «User-DTP» использует тот же порт, что и для передачи команд (обозначим его «U»), а «Server-DTP» использует порт номер (L-1), где L-управляющий порт. Однако, как правило, участниками соединения используются порты передачи данных, выбранные для них «User-PI», поскольку из управляющих процессов, участвующих в соединении, только он может изменить порты передачи данных как у «User-DTP», так и у «Server-DTP». Пассивная сторона соединения должна до того, как будет подана команда начать передачу, слушать свой порт передачи данных. Активная сторона, подающая команду к началу передачи, определяет направление перемещения данных. После того как соединение установлено, между «Server-DTP» и «User-DTP» начинается передача. Одновременно по каналу «Server-PI» - «User-PI» передаются уведомления о получении данных. Протокол FTP требует, чтобы управляющее соединение было открыто, пока по каналу обмена данными идет передача. Сессия FTP считается закрытой только после закрытия управляющего соединения. Как правило, сервер FTP ответственен за открытие и закрытие канала передачи данных. Сервер FTP должен самостоятельно закрыть канал передачи данных в следующих случаях:

1. Сервер закончил передачу данных в формате, который требует закрытия соединения.

2. Сервер получил от пользователя команду прервать соединение.

3. Пользователь изменил параметры порта передачи данных.

4. Было закрыто управляющее соединение.

5. Возникли ошибки, при которых невозможно возобновить передачу данных.

FTP-протокол имеет двух «младших братьев»: TFTP - Trivial FTP и SFTP - Simple FTP.

Управление сетями. Протокол SNMP. Вопросы производительности сетей.

SNMP – протокол управления сетью

Когда сеть из компьютеров охватывает небольшие пространства - несколько комнат, этаж – то в случае возникновения каких-то неполадок можно обойти все помещения и проверить работоспособность оборудования и программного обеспечения каждого устройства в сети. Когда сеть охватывает большие территории и включает оборудование, принадлежащее нескольким разным организациям, то так уже не поступишь. Например, много времени уйдет на согласование доступа в помещения, а при больших территориях – просто чтобы обойти все устройства и найти плохо работающее. Поэтому, когда Интернет стал охватывать большие территории, потребовались адекватные средства для управления сетью. Под словом «управление» в данном случае мы будем понимать возможность оперативно получать информацию о каждом устройстве в сети: о его работоспособности, состоянии, истории его функционирования. Позднее на понятии управления в сети мы остановимся подробнее. В 1990 году была опубликована первая версия протокола Simple Network Management Protocol (SNMP v.1). Эта версия описана в RFC 1155 и RFC 1157. В этих документах было описано систематическое наблюдение за сетью (какая информация могла накапливаться, как и где) и управление ею (как и какие параметры работы устройств сети можно было менять). Этот протокол получил широкое распространение и был реализован практически во всех устройствах, используемых в сетях. Опыт использования протокола SNMP v.1 выявил ряд недостатков. Например, в первой версии недостаточно были проработаны вопросы безопасности. При опросе устройств явно указывался пароль, глядя на который, устройство аутентифицировало запрашивающее устройство. Во второй версии протокола SNMP v.2 (RFC 1441-1452) была введена криптографическая защита механизма аутентификации. Далее будет кратко описана именно вторая версия протокола SNMP.

7.3.1. Модель управления

Предполагается, что сеть состоит из четырех категорий компонентов:

• Станции управления

• Управляемые устройства

• Управляющая информация

• Протокол управления

Управление сетью осуществляют станции управления. Это компьютеры, на которых выполняются процессы, собирающие и накапливающие информацию об управляемых устройствах в сети. Сбор этой информации происходит по запросу от управляющей станции управляемому устройству. Запросы, передача и другие действия выполняются с помощью команд протокола SNMP. На управляемых устройствах работают специальные SNMP-агенты (далее для краткости просто «агенты»), которые выполняют команды, передаваемые с помощью SNMP-протокола, фиксируют определенный набор параметров функционирования управляемого устройства. Управляемым устройством может быть маршрутизатор, мост, рабочая станция, устройство печати – любое устройство, где может работать SNMP-агент. Каждый агент поддерживает локальную базу данных MIB (Management Information Base), где хранится информация о состоянии агента, история его функционирования и переменные, характеризующие работу устройства, где функционирует агент.

7.3.2. SMI – структура управляющей информации

В сети используется аппаратура сотен различных производителей. Естественно агент должен формировать данные о функционировании управляемого устройства в некотором унифицированном виде, например, по составу, способу представления независимо от того, кто изготовил это устройство. В соответствии с терминологией, принятой в стандарте протокола SNMP, переменную, в которой агент накапливает информацию, будем называть объектом. Все объекты собраны в группы, определяемые стандартом, а группы – в модули. Чтобы все объекты имели единые правила идентификации, поступают следующим образом. Строят дерево стандарта, в котором отражают иерархию понятий, используемых в стандарте. Это дерево стандарта является поддеревом дерева стандартов. На рисунке 7-30 показана часть такого дерева. На первом ярусе этого дерева расположены названия организаций, имеющих право выпускать международные стандарты – это ISO и МКТТ (теперь МСТ – международный союз телекоммуникаций). Есть в этом дереве и место для Интернета – ярус 4. На последнем ярусе указаны группы. В скобках рядом с именем каждой группы указано количество объектов в группе. Объекты имеют тип, определяемый через Object Identifier. Все объекты в этом дереве могут быть заданы указанием пути в дереве. SMI в определенном смысле представляет собой язык для определения структур данных, представляющих объекты в базе данных MIB. В таблице 7-31 указаны типы данных, используемые для определения объектов, отслеживаемых протоколом SNMP.

7.3.4. Протокол SNMP

SNMP-протокол определяет пять типов сообщений, которыми обмениваются станция управления и устройство. Все они показаны на рисунке 7-44.

• get-request - получить значение одной или нескольких переменных.

• get-next-request - получить одну или несколько переменных, следующих после указанной переменной.

• set-request - установить значение одной или нескольких переменных.

• get-response - выдать значение одной или нескольких переменных. Это сообщение возвращается агентом станции управления в ответ на операторы get-request, get-next-request и set-request.

• оператор trap - уведомить станцию управления, когда что-либо произошло с агентом.

Первые три сообщения отправляются от станции управления к устройству, а последние два - от устройства к станции управления. Так как четыре из пяти SNMP-сообщений реализуются простой последовательностью «запрос-ответ», в SNMP-протоколе используют UDP-протокол. Это означает, что запрос от станции управления может не дойти до устройства, а отклик от устройства – до станции управления. В этом случае будет задействован механизм тайм-аута и повторная передача. Станция управления отправляет все три запроса на UDP-порт 161. Устройство устанавливает ловушки (программные прерывания trap) на UDP-порт 162. Так как используются два разных порта, одна и та же система может выступать и как станция управления, и как устройство. На рисунке 7-45 показан формат пяти SNMP-сообщений, инкапсулированных в UDP-дейтаграмму. При взаимодействии между станцией управления и устройством используют пароль. Пароль - это 6-символьная строка, которую передавали в SNMP v.1 в открытом виде. В операторах get, get-next и set станция управления устанавливает идентификатор запроса (request ID), который возвращается устройством в сообщении get-response. Это повышает безопасность при взаимодействии. Это поле также позволяет станции управления выдать несколько запросов одному или нескольким устройствам, а затем отсортировать полученные отклики. Статус ошибки (error status) - это целое число, которое возвращается агентам и указывает на ошибку.

17