Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

• Название: TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
• Автор: Сидни Фейт
• Издательство: Лори
• Жанр: Программное обеспечение
• Год: 2000
• ISBN: 5-85582-072-6

 Второе издание популярного справочника полностью переработано и расширено с целью предоставить читателю наиболее полное описание средств разработки, конфигурирования, использования и обслуживания сетей TCP/IP и соответствующих служб.

Книга написана увлекательно и доступно. Она содержит дополнительные материалы о нескольких протоколах Интернета, используемых серверами и браузерами WWW, а также рассматривает все последние изменения в этой области. В книгу включены главы о новом стандарте безопасности IP и протоколе IP следующего поколения, известном как IPng или IPv6. Рисунки и таблицы наглядно показывают влияние средств безопасности IP и IPng на существующие сетевые среды.

Издание содержит следующие дополнительные разделы:

• Безопасность IP и IPv6

• Описание средств WWW, новостей Интернета и приложений для работы с gopher

• Подробное описание серверов имен доменов (DNS), маски подсети и бесклассовой маршрутизации в Интернете

• Таблицы и протоколы маршрутизации

• Руководство по реализации средств безопасности для каждого из протоколов и приложений

• Примеры диалогов с новыми графическими инструментами

Новое издание бестселлера по TCP/IP станет незаменимым помощником для разработчиков сетей и приложений, для сетевых администраторов и конечных пользователей.

---

15.9.3 Аутентификация DCS

Стандарт шифрования данных (Data Encryption Standard — DES) использует симметричный алгоритм шифрования. DES — это федеральный стандарт обработки информации (Federal Information Processing Standard — FIPS), который был определен Национальным бюро стандартов США, в настоящее время называемым Национальным институтом стандартов и технологий (National Institute of Standards and Technology — NIST).

Аутентификация DES для RPC основана на сочетании асимметричных общедоступных и личных ключей с симметричным шифрованием DES:

■ Имя пользователя связано с общедоступным ключом.

■ Сервер шифрует ключ сеанса DES с помощью общедоступного ключа и посылает его клиентскому процессу пользователя.

■ Ключ сеанса DES используется для шифрования аутентификационной информации клиента и сервера.

15.9.4 Аутентификация в Kerberos

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

■ использования секретных ключей (клиента и сервера), зарегистрированных на сервере безопасности Kerberos и распространяемых как ключи сеансов DES для клиентов и серверов

■ применения ключа сеанса DES для шифрования аутентификационной информации клиента и сервера

15.10 Пример сообщении RPC версии 2

На рис. 15.6 показан результат обработки монитором Sniffer компании Network General заголовка UDP и полей RPC из сообщения запроса к NFS о выводе атрибутов файла. Заголовки уровня связи данных и IP опущены, чтобы не загромождать рисунок.

UDP: -- UDP Header --

UDP:

UDP: Source port = 1023 (Sun RPC)

UDP: Destination port = 204 9

UDP: Length = 124

UDP: No checksum

UDP:

RPC: -- SUN RPC header --

RPC:

RPC: Transaction id = 641815012

RPC: Type = 0 (Call)

RPC: RPC version = 2

RPC: Program = 100003 (NFS), version = 2

RPC: Procedure = 4 (Look up file name)

RPC: Credentials: authorization flavor = 1 (Unix)

RPC: len = 32, stamp = 642455371

RPD: machine = atlantis

RPC: uid = 0, gid = 1

RPC: 1 other group id(s) :

RPC: gid 1

RPC: Verifier: authorization flavor = 0 (Null)

RPC: [Verifier: 0 byte(s) of authorization data]

RPC:

RPC: [Обычное завершение заголовка "SUN RPC".]

RPC:

NFS: -- SUM NFS --

NFS:

NFS: [Параметры для процедуры 4 (Look up file name) follow]

NFS: File handle = 0000070A00000001000A0000000091E3

NFS: 5E707D6A000A0000000044C018F294BE

NFS: File name = README

NFS:

NFS: [Обычное завершение "SUN NFS".]

NFS:

Рис. 15.6. Формат сообщения RPC с запросом к NFS

Заметим, что запрос RPC имеет тип сообщения 0. Ответ будет иметь тип 1. Протокол RPC периодически обновляется, поэтому в сообщении указывается версия RPC (в нашем случае это версия 2).

Вызывающая сторона использует мандат Unix, определяющий реальные идентификаторы пользователя и группы (userid и groupid). Имеется дополнительный идентификатор группы. Штампом служит произвольный идентификатор, созданный вызывающей стороной. Поле проверочных сведений аутентификации имеет оттенок 0 (не обеспечивает никакой дополнительной информации). NFS часто реализуется с частичной аутентификацией, поскольку более полная зашита снижает производительность.

За идентификатором программы 100003 (NFS) и процедуры 4 (просмотр имен файлов) следуют параметры: описатель файла (file handle) и имя файла.

Описатель файла — это специальный идентификатор, связанный с каталогом или файлом сервера. В версии 2 протокола RPC описатель файла представлен строкой фиксированной длины в 32 бита, в версии 3 он задается строкой переменной длины с максимальной длиной в 64 бита. В запросе указан файл README, расположенный в каталоге, идентифицированном описателем файла.

Поля в сообщении запроса кодируются по правилам форматирования XDR (см. следующий раздел).

Мы можем получить представление о работе XDR, рассмотрев некоторые шестнадцатеричные коды в сообщении запроса:

Тип сообщения = 0, кодируется (в шестнадцатеричных значениях) как:

00 00 00 00

Версия RPC = 2, кодируется как:

00 00 00 02

Машина = atlantis, кодируется как:

(длина строки =8) atlantis

00 00 00 08 61 74 6С 61 6E 74 69 73

RPC: -- SUN RPC header --

RPC:

RPC: Transaction id = 641815012

RPC: Type = 1 (Reply)

RPC: Status = 0 (Accepted)

RPC: Verifier: authorization flavor = 0 (Null)

RPC: [Verifier: 0 byte(s) of authorization data]

RPC: Accept status = 0 (Success)

RPC:

RPC: [Обычное завершение заголовка "SUN RPC" .]

RPC:

NFS: -- SUN NFS --

NFS:

NFS: Proc = 4 (Look up file name)

NFS: Status = 0 (OK)

NFS: File handle = 0000070A00000001000A000000005AC9

NFS:               3298621C000A0000000044C018F294BE

NFS: File type = 1 (Regular file)

NFS:  Mode = 0100644

NFS:  Type = Regular file

NFS:  Owner's permissions = rw-

NFS:  Group's permissions = r-

NFS:  Others; permissions = r-

NFS: Link count = 1, UID = 303, GID = 1

NFS: File size = 130, Block size = 8192, No. of blocks = 2

NFS: File system id = 1802, File id = 23241

NFS: Access time = 23-Oct-95 16:35:01 GMT

NFS: Modification time = 20-Oct-95 12:10:43 GMT

NFS: Inode change time = 20-Oct-95 12:10:43 GMT

NFS:

NFS: [Обычное завершение "SUN NFS".]

NFS:

Рис. 15.7. Формат сообщения RPC с ответом от NFS

В показанном на рис. 15.7 ответе присутствует тот же идентификатор транзакции. Указана нулевая аутентификационная информация. Запрос был принят, и его обработка завершилась успешно. Ответ содержит много полезной информации о файле README:

■ Идентификатор описателя файла. Любые дальнейшие операции с этим файлом будут использовать указанный в ответе описатель.

■ Режим (mode) описывает тип файла и указывает, кто может получить доступ к этому файлу (владелец, группа или любой пользователь). Режим объявляет, может ли пользователь читать или записывать файл. Если файл представляет собой прикладное программное обеспечение, режим показывает, могут ли пользователи запускать такое приложение.

■ Имеются дополнительные атрибуты файла, например его размер, время последнего обращения и обновления. Можно ожидать, что эти атрибуты поддерживаются в любой файловой системе.

15.11 XDR

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

Все параметры в сообщениях Sun RPC определены и кодируются по протоколу представления внешних данных (external Data Representation — XDR). Этот протокол специфицирует:

■ Язык описания данных XDR, определяющий тип данных в запросах и ответах

■ Правила кодирования XDR по форматированию данных при пересылке

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

15.11.1 Язык описания данных XDR

Описания данных XDR похожи на описания данных в языках программирования и не являются слишком сложными. Существует несколько основных типов данных XDR: целые числа со знаком и без знака, последовательные (или порядковые) целые числа, строки ASCII, логические значения и числа с плавающей точкой. Для пересылки строк октетов общего вида применяется тип данных opaque (непрозрачный, без преобразования). В полях с этим типом данных может пересылаться зашифрованная информация. К более сложным типам данных относятся массивы, структуры и объединенные типы данных (union datatypes), построенные на основе базовых типов.

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

enum msg_type {

 CALL = 0,

 REPLY = 1

};

В данном поле может появляться только одно из целых чисел: 0 или 1. Ввод любого другого целого числа приведет к ошибке.

Структура определения тела сообщения запроса RPC: