Загрузка...



  • 24.1 Введение
  • 24.2 Безопасность
  • 24.3 Стратегия безопасности
  • 24.4 Сценарии обеспечения безопасности
  • 24.4.1 Сценарий 1
  • 24.4.2 Конфигурирование аутентификационной информации для сценария 1
  • 24.4.3 Односторонняя безопасность
  • 24.4.4 Количество ключей аутентификации
  • 24.4.5 Сценарий 2
  • 24.4.6 Сценарий 3
  • 24.4.7 Обобщение
  • 24.5 Элементы протокола безопасности
  • 24.5.1 Ассоциации безопасности
  • 24.5.2 Authentication Header
  • 24.5.3 Режимы транспорта и туннеля
  • 24.5.4 Инкапсуляция защищенной полезной нагрузки
  • 24.5.5 Аутентификация в режиме туннеля
  • 24.5.6 Обслуживание ключей
  • 24.6 Дополнительная литература
  • Глава 24

    Безопасность в IP

    24.1 Введение

    Необходимость разработки новой версии IP стала дополнительным стимулом для решения проблем безопасности TCP/IP. Предлагаемый механизм обеспечивает безопасность на уровне IP. Он разработан для совместимости как с версией 4, так и с версией 6. Для упрощения все сценарии этой главы предполагают использование версии 4.

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

    Почему не подходит физический уровень? Весь трафик связи должен шифроваться. Это позволит решить проблему с "подсматриванием", однако приведет к необходимости автоматического дешифрирования в каждом маршрутизаторе. Сегодня мы еще не можем доверять каждому маршрутизатору.

    Кроме того, в этом случае не решается проблема с аутентификацией, равно как и с перегрузкой высокоскоростного трафика, когда шифрование/дешифрирование реализуется на аппаратном уровне. Более того, каждый интерфейс локальной сети должен быть способен шифровать и дешифрировать данные, а это серьезно увеличит стоимость оборудования.

    24.2 Безопасность

    В главе 3 мы уже отмечали три атрибута безопасности:

    Аутентификация Проверка подлинности пользователя, клиентского процесса или серверного приложения
    Целостность Проверка отсутствия изменений в данных
    Конфиденциальность Предотвращение несанкционированного доступа к информации

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

    24.3 Стратегия безопасности

    Интеграция безопасности в IP стала одной из наиболее сложных работ, выполненных IETF. Аутентификация, целостность данных и конфиденциальность стали насущными и необходимыми. Стратегия безопасности предполагает:

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

    ■ Разработку основ безопасности, позволяющих перейти на новые механизмы безопасности.

    В качестве исходных были выбраны следующие механизмы:

    ■ MD5 для аутентификации и целостности данных (в настоящее время проявились проблемы с MD5 при реализации высокоскоростных коммуникаций, поскольку требуется большой объем вычислений).

    ■ Симметричное шифрование в режиме Cipher Block Chaining американского стандарта Data Encryption Standard (CBC-DES) для обеспечения конфиденциальности.

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

    24.4 Сценарии обеспечения безопасности

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

    Сценарий 1. Компания XYZ хочет обезопасить свои внешние коммуникации клиент/сервер. Ей нужно устранить возможность фальсификации своих данных при подделке исходного IP-адреса или изменения данных при пересылке.

    Сценарий 2. Администратор компании XYZ копирует очень важные файлы между хостами. Эту операцию должен выполнять только этот администратор и никто другой. Кроме того, важно предотвратить "подглядывание", т.е. захват и несанкционированное использование данных из файлов.

    Сценарий 3. Компания XYZ соединила по Интернету свои производственные подразделения с удаленным главным офисом. Она хочет скрыть все свои коммуникации от остального мира.

    Для простоты можно считать, что каждый клиентский или серверный хост имеет единственный IP-адрес и один интерфейс. Однако механизмы безопасности должны работать и для систем с несколькими интерфейсами и несколькими IP-адресами.

    24.4.1 Сценарий 1

    Технология Message Digest (резюме сообщения) подойдет для сценария 1 — аутентифицировать отправителя и определить изменения в данных. Рассмотрим, как работает этот механизм (см. рис. 24.1):

    ■ Источник и назначение знают секретный ключ.

    ■ Источник выполняет вычисление, используя данные и секретный ключ.

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

    ■ В точке назначения выполняются те же самые вычисления и сравниваются результаты.

    Рис. 24.1. Использование Message Digest

    24.4.2 Конфигурирование аутентификационной информации для сценария 1

    Предположим, что компания XYZ имеет важный сервер с IP-адресом 130.15.20.2. В рамках работ по безопасности администратор сервера нумерует хосты клиентов и присваивает секретные ключи аутентификации каждому клиентскому IP-адресу.

    Серверу нужно хранить информацию о безопасности. Для этого можно воспользоваться таблицей (например, 24.1). В ней индексируются все присвоенные клиентским хостам номера, называемые индексами параметров безопасности (Security Parameters Index — SPI). Если сервер имеет несколько IP-адресов, таблица индексируется и по адресам точек назначения.


    Таблица 24.1 Информация безопасности в точке назначения 130.15.20.2

    SPI (для хоста клиента) IP-адрес источника Ключ аутентификации клиента Метод аутентификации клиента
    301 130.15.24.4 X'2E-41-43-11-5A-5A-74-53-E3-01-88-55-10-15-CD-23 MD5
    302 130.15.60.10 X35-14-4F-21-2B-2C-12-34-82-22-98-44-C0-1C-33-56 MD5

    Конечно, каждый клиент должен быть конфигурирован с SPI и секретным ключом, используемым при доступе к серверу. Таблица 24.2 показывает конфигурационные данные второго клиента. Клиент нуждается в отдельных вхождениях для каждой точки назначения, к которой будет обращаться.


    Таблица 24.2 Информация безопасности в источнике 130.15.60.10

    IP-адрес назначения SPI IP-адрес источника Ключ аутентификации клиента Метод аутентификации клиента
    130.15.20.2 302 130.15.60.10 X'35-14-4F-21-2B-2C-12-34-82-22-98-44-C0-1С-33-56 MD5
    130.15.65.4

    Что происходит, когда клиентский хост хочет послать аутентифицированную датаграмму серверу?

    ■ Клиент выбирает IP-адрес точки назначения из своей таблицы.

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

    ■ Номер SPI и резюме сообщения помещаются в заголовок Authentication

    ■ Датаграмма отсылается.

    При получении сервером датаграммы выполняются следующие действия:

    ■ Сервер использует SPI из заголовка Authentication, чтобы найти в таблице запись для клиента.

    ■ IP-адрес источника сообщения сравнивается с адресом источника в таблице.

    ■ По ключу аутентификации из таблицы вычисляется резюме сообщения.

    ■ Результат сравнивается со значением из заголовка Authentication.

    24.4.3 Односторонняя безопасность

    На данный момент выполнена только половина работы. Мы установили аутентификацию только для одного направления обмена данными. Аутентифицируются только датаграммы, отправляемые от клиента на сервер.

    Такой метод называется односторонней ассоциацией безопасности (Security Association). Для идентификации используемого элемента таблицы важно обеспечить ассоциацию комбинации IP-адреса назначения и SPI как в источнике, так и в точке назначения, т.е. ассоциация безопасности связана с точкой назначения и с SPI.

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

    ■ Иметь таблицу безопасности, когда он является источником датаграммы

    ■ Иметь таблицу безопасности, когда он является получателем датаграммы

    На рис. 24.2 показаны пары ассоциаций безопасности.

    Рис. 24.2. Пары ассоциаций безопасности

    24.4.4 Количество ключей аутентификации

    Сколько ключей аутентификации нужно для работы сервера с клиентами? Может показаться, что серверу достаточно иметь один ключ MD5, с помощью которого он может сказать: "Я тот самый сервер".

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

    24.4.5 Сценарий 2

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

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

    Рис. 24.3. Несколько ассоциаций безопасности для клиента и сервера

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


    Таблица 24.3 Информация безопасности об источнике в 130.15.20.2

    SPI IP-адрес источника Клиентский ключ аутентификации Клиентский метод аутентификации Клиентский ключ шифрования Клиентский метод шифрования
    301 130.15.24.4 MD5 Нет Нет
    2 130.15.60.10 ..xxx.. MD5 Нет Нет
    72 130.15.60.10 ..JJJ.. MD5 #$ВВ7&% CBC-DES

    Таблицы 24.3 и 24.4 включают параметры безопасности для однонаправленных ассоциаций безопасности с источником, находящимся в клиенте 130.15.60.10, и точкой назначения на сервере 130.15.20.2. Отдельный набор параметров должен быть определен для обратного направления — от сервера-источника к клиенту-приемнику. Здесь снова разработчики конкретной системы должны решить, использовать ли те же самые ключи в обоих направлениях или присвоить различные ключи для трафиков клиент-сервер и сервер-клиент.


    Таблица 24.4 Информация безопасности об источнике в 130.15.60.10

    IP-адрес назначения Роль или идентификатор пользователя SPI IP-адрес источника Клиентский ключ аутентификации Клиентский метод аутентификации Клиентский ключ шифрования Клиентский метод шифрования
    130.15.20.2 Хост 2 130.15.60.10 ..xxx.. MD5 Нет Нет
    130.15.20.2 Администратор 72 130.15.60.10 ..JJJ.. MD5 #$ВВ7&% CBC-DES
    130.15.65.4 Хост MD5

    24.4.6 Сценарий 3

    Сценарий 3 показан на рис. 24.4. Цель состоит в том, чтобы сделать невидимым для внешнего мира весь трафик, который компания XYZ посылает через недоверенную сеть. Для этого используется инкапсуляция в режиме туннеля, т.е. датаграммы шифруются и инкапсулируются внутри других датаграмм.

    Рис. 24.4. Трафик в туннеле между двумя сетями

    Когда датаграмма с точкой назначения в сети 193.40.3 достигает граничного маршрутизатора для сети 130.15, он зашифровывает всю эту датаграмму, включая заголовки. Он подставляет временный (открытым текстом) IP-заголовок и пересылает датаграмму через сеть провайдера на граничный маршрутизатор сети 193.40.3. Можно подставить и другие заголовки (например, отдельный заголовок аутентификации для взаимодействия маршрутизатор-маршрутизатор). В маршрутизаторе-приемнике временный заголовок удаляется, датаграмма дешифрируется и отправляется в истинную точку назначения. В данном случае ассоциации безопасности устанавливаются между двумя граничными маршрутизаторами.

    24.4.7 Обобщение

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

    ■ Между хостами

    ■ Между маршрутизаторами

    ■ Между хостом и маршрутизатором

    ■ Между маршрутизатором и хостом

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

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

    24.5 Элементы протокола безопасности

    Рассмотрим реализацию безопасности более детально.

    24.5.1 Ассоциации безопасности

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

    ■ Адрес источника

    ■ Используемый алгоритм аутентификации и целостности данных

    ■ Используемый алгоритм конфиденциальности

    ■ Секретные ключи и другую необходимую для алгоритмов информацию

    ■ Ограничения по времени на ключи

    ■ Ограничение по времени на ассоциации безопасности

    ■ Гриф секретности (например, "не секретно" или "совершенно секретно")

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

    ■ Хост источника может применять один набор параметров для пересылки данных в точки назначения.

    ■ Хост может использовать несколько ассоциаций безопасности для различных хостов точек назначения. Ассоциации выбираются на основе идентификатора пользователя, роли или важности информации.

    Каждому набору параметров безопасности в каждой из точек назначения присваивается цифровой идентификатор, называемый индексом параметров безопасности (Securuty Parameter Index — SPI). Некоторым наборам стандартных параметров значение SPI присваивает IANA.

    Одинаковые SPI могут использоваться для различных точек назначения. Наборы параметров (Назначение=A, SPI=300) и (Назначение=В, SPI=300), скорее всего, будут различными. Другими словами, набор параметров идентифицируется как SPI, так и точкой назначения.

    Для реализации безопасности в IP версий 4 и 6 применяются заголовки Authentication Header и Encapsulating Security Payload Header.

    24.5.2 Authentication Header

    Если для аутентификации используется резюме сообщения, заголовок Authentication Header (заголовок аутентификации) выполняет две задачи:

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

    ■ Проверяет, не были ли данные изменены при пересылке.

    Формат Authentication Header показан на рис. 24.5. Получатель использует SPI для выбора требуемого протокола и ключа аутентификации. Ключ служит для вычисления приемником резюме по алгоритму MD5.

    Рис. 24.5. Формат заголовка Authentication Header

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

    24.5.3 Режимы транспорта и туннеля

    Рассмотрим способы реализации конфиденциальности. Формат датаграммы IP версии 6 с шифрованной полезной нагрузкой более высокого уровня показан на рис. 24.6. Такой формат определяет режим транспорта (Transport-mode).

    Рис. 24.6. Шифрование для режима транспорта

    На рис. 24.7 показан формат для режима туннеля (Tunnel-mode). Шифруется вся датаграмма, включая все ее заголовки. Для пересылки подставляется новый заголовок. Режим туннеля между хостами может не сработать, если по пути следования попадутся фильтрующие маршрутизаторы со средствами защиты. Такие системы будут проверять информацию, подобную IP-адресам источника и назначения либо порты, а эти сведения будут скрыты внутри зашифрованного сообщения.

    Рис. 24.7. Шифрование для режима туннеля

    24.5.4 Инкапсуляция защищенной полезной нагрузки

    Заголовок инкапсуляции защищенной полезной нагрузки протокола IP (IP Encapsulating Security Payload) применяется как для режима транспорта, так и для режима туннеля.

    Формат этого заголовка показан на рис. 24.8. Получатель использует индекс SPI для выбора алгоритма и ключа (ключей). Оставшиеся данные зависят от выбранного алгоритма.

    Рис. 24.8. Заголовок Encapsulating Security Payload

    При использовании CBC-DES формат заголовка Encapsulating Security Payload и оставшаяся часть сообщения будут выглядеть как на рис. 24.9.

    Рис. 24.9. Заголовок и полезная нагрузка при использовании алгоритма CBC-DES

    Вектор инициализации (Initialization Vector) — это блок данных, необходимых для начала работы алгоритма CBC-DES. Затененная область на рисунке представляет зашифрованные данные. Тип 4 означает инкапсулирование в полезной нагрузке всей датаграммы (режим туннеля).

    Хотя первоначально планируется использование CBC-DES, в будущем могут появиться другие протоколы для инкапсуляции полезной нагрузки, комбинирующие аутентификацию и целостность данных с шифрованием.

    24.5.5 Аутентификация в режиме туннеля

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

    24.5.6 Обслуживание ключей

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

    Существует много литературы по управлению ключами. Но ни один из методов управления ключами не специфицирован, поэтому имеются возможности для экспериментирования.

    Использование асимметричных общедоступных/личных пар ключей вместо симметричного метода CBC-DES может значительно уменьшить количество администрируемых ключей.

    24.6 Дополнительная литература

    Следующий список RFC являлся актуальным на момент выхода книги. Последние изменения можно найти в индексе RFC.

    RFC 1825 Security Architecture for the Internet Protocol (Архитектура безопасности для протокола Интернета). Справочный раздел этого документа содержит список множества других публикаций по теме безопасности.

    RFC 1826 IP Authentication Header (Заголовок аутентификации протокола IP)

    RFC 1828 IP Authentication using Keyed MD5 (Аутентификация в IP по ключам MD5)

    RFC 1321 The MD5 Message-Digest Algorithm (Алгоритм вычисления резюме сообщения MD5)

    RFC 1827 IP Encapsulating Security Payload — ESP (Инкапсуляция защищенной полезной нагрузки в протоколе IP)

    RFC 1829 The ESP DES-CBC Transform (Преобразование ESP по алгоритму DES-CBC)








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх