Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
- Название:TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
- Автор:
- Жанр:
- Издательство:Лори
- Год:2000
- Город:Москва
- ISBN:5-85582-072-6
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) краткое содержание
Второе издание популярного справочника полностью переработано и расширено с целью предоставить читателю наиболее полное описание средств разработки, конфигурирования, использования и обслуживания сетей TCP/IP и соответствующих служб.
Книга написана увлекательно и доступно. Она содержит дополнительные материалы о нескольких протоколах Интернета, используемых серверами и браузерами WWW, а также рассматривает все последние изменения в этой области. В книгу включены главы о новом стандарте безопасности IP и протоколе IP следующего поколения, известном как IPng или IPv6. Рисунки и таблицы наглядно показывают влияние средств безопасности IP и IPng на существующие сетевые среды.
Издание содержит следующие дополнительные разделы:
• Безопасность IP и IPv6
• Описание средств WWW, новостей Интернета и приложений для работы с gopher
• Подробное описание серверов имен доменов (DNS), маски подсети и бесклассовой маршрутизации в Интернете
• Таблицы и протоколы маршрутизации
• Руководство по реализации средств безопасности для каждого из протоколов и приложений
• Примеры диалогов с новыми графическими инструментами
Новое издание бестселлера по TCP/IP станет незаменимым помощником для разработчиков сетей и приложений, для сетевых администраторов и конечных пользователей.
TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
■ Мандат аутентификации
■ Проверочные сведения (verifier) аутентификации
■ Входные параметры
Рис. 15.5.Сообщения RPC
Если процедура выполнена успешно, ответ содержит результаты. Если при выполнении выявлены проблемы, ответ будет содержать информацию об ошибках.
15.9 Аутентификация в RPC
Некоторые службы не нуждаются в защите. Для вывода времени дня на сервере служба RPC может быть оставлена открытой для общего доступа. Однако клиент, обращающийся к личным данным, должен обеспечить некоторую опознавательную информацию (проходить аутентификацию). В некоторых случаях важно, чтобы сервер также подтверждал свою подлинность. Не следует посылать номер своей кредитной карточки через систему интерактивных заказов, если не будет гарантии в подлинности сервера. Таким образом, в некоторых случаях аутентификационные данные должен предоставлять как клиент, так и сервер (они будут как в запросах, так и в ответах).
В сообщении запроса аутентификационные сведения RPC пересылаются в двух полях:
■ Поле мандата (credentials) — содержит идентификационную информацию.
■ Поле проверочных сведений аутентификации (verifier) — содержит дополнительную информацию и позволяет проверить идентификатор. Например, verifier мог бы содержать зашифрованный пароль и штамп времени.
Для аутентификации не существует единого стандарта. Реализовать проверку аутентификации должен разработчик каждого приложения. Именно он должен решить, что необходимо в каждом конкретном случае. Однако продолжаются работы по созданию единых стандартов для этой процедуры.
В настоящее время каждый метод аутентификации называется flavor (оттенок). Тип такого оттенка, используемый в мандатах или полях verifier, идентифицирован целым числом в начале поля. Новые типы аутентификации могут быть зарегистрированы таким же образом, что и новые программы. Поля мандата и verifier начинаются с целого числа.
15.9.1 Нулевая аутентификация
Нулевая аутентификация полностью соответствует своему названию. Не используется никакой аутентификационной информации — в полях мандата и verifier сообщений запросов и ответов содержатся одни нули.
15.9.2 Аутентификация систем
Аутентификация систем моделирует аналогичную информацию операционной системы Unix. Мандат системы содержит:
| stamp (штамп) | Случайный идентификатор, сгенерированный вызывающим компьютером |
| machinename (имя машины) | Имя запрашивающей машины |
| uid (идентификатор пользователя) | Реальный номер идентификации пользователя, инициировавшего запрос |
| gid (идентификатор группы) | Реальный номер идентификации группы пользователя, инициировавшего запрос |
| gids (идентификаторы групп) | Список групп, к которым принадлежит пользователь |
Поле проверочных сведений аутентификации — нулевое.
Проверочные сведения аутентификации (verifier), возвращаемые сервером, могут быть пустыми или иметь оттенок short (краткие), означающий возвращение октета, определяющего систему. В некоторых реализациях этот октет используется как мандат в последующем сообщении от вызывающей стороны (мандат будет заменять информацию о пользователе и его группе).
Отметим, что этот способ не обеспечивает защиты. Следующие два метода применяют шифрование для защиты аутентификационной информации. Однако приходится выбирать между обеспечением безопасных служб RPC и достижением удовлетворительной производительности. Шифрование даже одного поля приводит к существенному снижению быстродействия службы, например NFS.
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 часто реализуется с частичной аутентификацией, поскольку более полная зашита снижает производительность.
Читать дальшеИнтервал:
Закладка:
