1. 1 История tcpIP
 Скачать 340.83 Kb.
|
3.2.9 Планирование подсетей IPv6Адресное пространство IPv6 позволяет гибко планировать схему адресации сети. Документы RFC для IPv6 рекомендуют использовать префикс длиной 64 бита для адресации узлов в локальных сетях. Рассмотрим пример планирования подсетей IPv6. Предположим, что организация планирует использовать в своей сети адреса Unique-Local Unicast и хочет разбить сеть на 5 подсетей. Процесс начинается с формирования 64-битного префикс сети. Напомним, что адреса Unique-Local Unicast начинаются с префикса FD00::/8. Следующий за префиксом идентификатор Global ID (40 бит) получаем с помощью генератора адресов Unique-Local IPv6 Unicast. Например, с помощью генератора получили Global ID, равный 895a473947. Затем назначаются 5 номеров подсети (Subnet ID) длиной 16 бит. Эти номера можно придумать самостоятельно или воспользоваться генератором. После того как получены все значения, объединяем их и формируем 5 префиксов подсетей длиной 64 бита (таблица 3.8). Внутри каждой из полученных подсетей можно адресовать 264 узлов. Таблица 3.8. Формирование подсетей IPv6
3.3 Обзор архитектуры безопасности для протокола IP Одним их недостатков первоначального протокола IP было отсутствие каких-либо механизмовб обеспечивающих аутентификацию и целостность данных, передаваемых через составную сеть. Для обеспечения различных сервисов безопасности на уровне IP для протоколов IPv4 и IPv6 был разработан набор протоколов IP Security или IPSec. IPSec — это набор открытых стандартов для обеспечения частных коммуникаций через IP-сети. В зависимости от того как IPSec реализован и сконфигурирован, он может предоставлять любые комбинации из следующих видов защиты: Конфиденциальность: IPSec может гарантировать, что данные не будут прочитаны неавторизованными сторонами. Это достигается путем шифрования данных с использованием криптографических алгоритмов и секретных ключей. Данные могут быть расшифрованы только с помощью секретных ключей. Целостность: IPSec может определять была ли информация изменена в процессе передачи. Целостность данных обеспечивается генерацией кода идентификации сообщения (message authentication code, MAC), который является криптографической контрольной суммой данных. Если данные были изменены, значения МАС вычисленные на стороне приемника и передатчика будет отличаться. Взаимная аутентификация: каждая конечная точка IPSec подтверждает идентификационную информацию другой конечной точки IPSec, с которой хочет обмениваться информацией. Это гарантирует, что сетевой трафик и данные отправлены ожидаемым узлом. Защита от replay-атак: одна и та же информация не доставляется множество раз, и данные не доставляются не по порядку. Однако IPSec не гарантирует, что данные доставляются строго в том порядке, в котором были отправлены. Управление доступом: конечные точки IPSec могут выполнять фильтрацию, гарантируя, что только авторизованные IPSec пользователи могут получать доступ к определенным сетевым ресурсам. Конечные точки IPSec также разрешают или блокируют прохождение определенного типа сетевого трафика. Перечисленные сервисы предоставляются на уровне IP, обеспечивая защиту для самого протокола IP и всех протоколов более высокого уровня, которые могут передаваться по IP. В большинстве случаев реализации IPSec используются для обеспечения сервисов виртуальных частных сетей (VPN). С помощью протоколов IPSec можно реализовать различные топологии VPN, основными из которых являются следующие: Шлюз безопасности–шлюз безопасности (Security gateway–Security gateway). Узел–шлюз безопасности (Host–Security gateway). Узел–узел (Host–Host). Термин «шлюз безопасности» (security gateway) используется в документах, описывающих IPSec, для обозначения промежуточной системы, которая реализует протокол, например, маршрутизатор, межсетевой экран или сервер. VPN на основе IPSec часто используются для обеспечения безопасной передачи данных между двумя сетями, например, для соединения главного офиса и филиала через Интернет. Это обычно делается путем установки в каждой из сетей шлюзов безопасности и создания между двумя шлюзами VPN-подключения. Шлюзом может быть как выделенное устройство, выполняющее только функции VPN, так и межсетевой экран, маршрутизатор или сервер. Чтобы инициировать подключение, один из шлюзов отправляет другому запрос на установку IPSec-соединения. Два шлюза обмениваются друг с другом информацией и создают IPSec-соединение. В каждой из соединяемых сетей настраивается маршрутизация, так как узлам из разных сетей необходимо взаимодействовать друг с другом. Их трафик будет автоматически маршрутизироваться через IPSec-соединение и соответствующим образом защищаться. Между двумя шлюзами может быть установлено единственное IPSec-соединение, защищающее все виды трафика, или множество IPSec-соединений, которые могут защищать различные типы или классы трафика (в случае QoS). Защита соединений между узлами и локальными шлюзами обычно не выполняется. Для пользователей эта топология прозрачна и не требует установки или настройки никакого специального программного обеспечения на компьютерах или серверах. В последние годы получила широкое распространение модель «узел–шлюз безопасности», которая используется для обеспечения удаленного доступа пользователей через Интернет. Организация устанавливает в своей сети VPN-шлюз; каждый удаленный пользователь создает VPN-подключение между своим локальным компьютером (узлом) и шлюзом безопасности организации. Шлюзом, как и в предыдущем случае, может быть выделенное устройство, выполняющее только функции VPN, межсетевой экран или маршрутизатор. В этой модели IPSec-соединение создается для каждого отдельного удаленного пользователя. Устройства удаленных пользователей должны быть настроены на работу в качестве IPSec-клиента (на них должно быть установлено программное обеспечение клиента IPSec). Когда удаленный пользователь хочет получить доступ к ресурсам организации через VPN, узел инициирует обмен данными со шлюзом безопасности. Прежде чем установить соединение, шлюз выполнят аутентификацию пользователя самостоятельно или с использованием внешних серверов аутентификации. Клиент и шлюз обмениваются информацией и если аутентификация успешна, IPSec-соединение устанавливается. После этого пользователь может получить доступ к ресурсам организации. Трафик, передаваемый между узлом и шлюзом, защищается IPSec. Трафик между пользователем и системами, не контролируемыми организацией, также может маршрутизироваться через шлюз безопасности. Этот трафик, если необходимо, тоже может защищаться с помощью IPSec. Топология узел — шлюз безопасности не прозрачна для пользователей, так как каждый пользователь должен быть аутентифицирован перед использованием VPN-соединения и на каждом узле должно быть установлено и настроено программное обеспечение IPSec-клиента. Последняя топология VPN: модель «узел–узел». Она обычно используется для специальных целей, когда, например, сетевой администратор выполняет удаленное управление одним сервером. В этом случае организация настраивает сервер для обеспечения сервисов IPSec, а компьютер системного администратора исполняет роль клиента. Администратор использует IPSec-клиент, когда к удаленному серверу необходимо установить защищенное соединение. В этой модели IPSec-соединение создается по желанию каждого отдельного пользователя. Когда пользователь хочет получить доступ к ресурсам сервера, он инициирует взаимодействие с ним. Прежде чем установить соединение, сервер выполнят аутентификацию пользователя. Пользователь также может аутентифицировать сервер. Клиент и сервер обмениваются информацией и если аутентификация успешна, IPSec-соединение устанавливается. После этого трафик между узлом пользователя и сервером будет передаваться по защищенному соединению. IPSec является сложной темой, поэтому в данном курсе будет дан только обзор архитектуры безопасности для протокола IP. Подробно IPSec описан в курсе «Основы сетевой безопасности. Часть 2: Технологии туннелирования». Способы реализации IPSec Существует несколько способов реализации IPSec на узле, маршрутизаторе или межсетевом экране (для создания шлюза безопасности). Интеграция IPSec в конкретную реализацию протокола IP. Это требует доступа к исходному коду IP и делается как на узлах, так и на шлюзах безопасности. Реализация «Bump-in-the-stack» (BITS). IPSec создает новый архитектурный уровень, встраивая свою реализацию между стандартной реализацией IP-протоколов (IP-уровнем) и локальными сетевыми драйверами (канальным уровнем). Доступа к исходному коду стека IP в данном случае не требуется. Данный подход обычно применяется на узлах, когда IPSec реализован в виде подключаемой библиотеки. Использование внешнего (аппаратного) криптопроцессора. Обычно это называется реализацией «Bump-in-the-wire» (BITW). Такие реализации могут использоваться как на узлах, так и на шлюзах безопасности. Обычно BITW-устройства являются IP-адресуемыми. 3.3.1 Компоненты IPSec Несколько RFC описывают основные компоненты IPSec (таблица 3.9). Эти компоненты и их взаимодействие определяют логическую архитектуру IPSec. Таблица 3.9. Стандарты IPSec
В архитектуре IPSec можно выделить четыре основных части: Безопасная ассоциация; Протоколы IPSec; Алгоритмы и методы шифрования/хэширования; Безопасная ассоциация и управление ключами. Безопасная ассоциация Безопасная ассоциация (Security Association, SA) представляет собой симплексное (однонаправленное) логическое соединение между двумя конечными точками IPSec, служащее для предоставления сервисов безопасности, передаваемому через него трафику. Другими словами SA — это набор информации о безопасности (алгоритмов и параметров, таких как ключи шифрования), который описывает, как шифровать и аутентифицировать поток данных между двумя устройствами. Набор реализуемых SA сервисов зависит от выбранного протокола IPSec, его режима работы, дополнительных сервисов и конечных точек SA. При обычном двунаправленном соединении между двумя устройствами создаются две SA (по одной на каждое направление). Для предоставления сервисов используются два протокола IPSec: Authentication Header (AH) или Encapsulating Security Payload (ESP). Одновременно на одной SA оба протокола использоваться не могут. В этом случае создаются две отдельные SA. Например, если для IPSec-соединения между двумя устройствами требуется использовать оба протокола IPSec, будет создано четыре SA. SA может переносить как одноадресный, так и многоадресный трафик. В этом разделе будем рассматривать SA только для одноадресных соединений. Весь трафик, передаваемый по SA, обрабатывается в соответствии с политикой безопасности, заданной на концах соединения. Для обеспечения защищенного соединения SA требует наличия двух баз данных: базы данных политики безопасности (Security Policy Database, SPD) и базы данных безопасных ассоциаций (Security Association Database, SAD). База данных политики безопасности (Security Policy Database, SPD) определяет набор правил, описывающих как обрабатывать входящие (inbound) и исходящие (outbound) IP-дейтаграммы. Для любой исходящей или входящей дейтаграммы существует три возможных способа обработки: отбросить дейтаграмму, обойти IPSec или применить IPSec. Первый вариант означает, что трафик не разрешен для узла, не может проходить через шлюз безопасности или не может быть доставлен на уровень приложений. Второй вариант означает, что трафику разрешено проходить без какой-либо обработки IPSec. Третий вариант означает, что к трафику применяется IPSec-защита, и для такого трафика в SPD должны быть указаны необходимые сервисы безопасности, которые содержат информацию о применяемых протоколах, алгоритмах и т. д. При реализации IPSec должна быть создана как минимум одна база SPD. Она представляет собой упорядоченную базу данных (упорядоченный список записей политики), согласующуюся с использованием списков управления доступом (Access Control List, ACL) или пакетными фильтрами. Создается SPD пользователем или администратором сети при настройке устройства. Так как шлюзы безопасности зачастую обладают функциональностью IPSec и межсетевого экрана, то правила фильтрации могут создаваться как для IPSec, так и не-IPSec-трафика. Каждое правило в SPD идентифицируется одним или несколькими селекторами, которые определяют IP-трафик, попадающий под действие этого правила. Возможные селекторы являются набором информации, доступной в заголовках IP и транспортного уровня. Во всех реализациях IPSec поддерживаются следующие параметры селекторов: Remote IP Address (IPv4 или IPv6): список диапазонов адресов IPv4 или IPv6 удаленных устройств. Эта структура позволяет определить один IP-адрес или диапазон IP-адресов. Local IP Address (IPv4 или IPv6): список диапазонов адресов IPv4 или IPv6 локальных устройств. Эта структура позволяет определить один IP-адрес или диапазон IP-адресов. Next Layer Protocol: индивидуальный номер порта, который определяет приложение. Name: имя может использоваться как символьный идентификатор для локального или удаленного IP-адреса. В отличие от других селекторов, имя не берется из пакета. В зависимости от используемого селектора, SA может быть определена детально или грубо. Например, для передачи всего трафика между двумя узлами может быть создана единственная SA и к нему применяться единый набор сервисов безопасности. В другом случае трафик между парой узлов может передаваться через несколько SA, которые создаются для отдельных приложений. Различные SA будут предлагать различные сервисы безопасности. Это может определяться требованиями к безопасности конкретных приложений. Аналогично, весь трафик между двумя шлюзами безопасности может передаваться через единственную SA, или для каждой пары узлов, расположенных за шлюзом безопасности, может быть определена отдельная SA. Для каждого входящего и исходящего пакета с помощью селектора ищется соответствующая ему запись в SPD. Каждая запись SPD указывает действие, в соответствии с которым пакет должен быть пропущен, отброшен или обработан IPSec. Если применяется обработка IPSec, запись содержит информацию о режиме работы, применяемом протоколе IPSec и алгоритме, конечных точках туннеля (для туннельного режима) и необходимые дополнительные параметры. База данных безопасных ассоциаций (Security Association Database, SAD) хранит параметры каждой активной SA. Записи в SAD автоматически создаются протоколом Internet Key Exchange (IKE) или вручную. Для исходящей обработки записи в SAD связаны с записями в SPD. Если при обработке очередного исходящего пакета обнаружено, что запись SPD не ссылается на SA в SAD (SA не найдена в SAD), протокол IKE создает SA и помещает о ней запись в SAD. После этого запись в SPD связывается с записью в SAD. Для IPSec-обработки в SAD должна присутствовать следующая информация: Security Parameters Index (SPI) — 32-битное значение, выбираемое принимающей стороной SA для ее уникальной идентификации. При обработке исходящего трафика, SPI используется для создания заголовка AH или ESP. Для обработки входящего трафика SPI из заголовка AH или ESP используется для поиска соответствующей SA в SAD. Sequence Number Counter: 64-битное значение, используемое для создания поля Sequence Number в заголовках АН или ESP для исходящего трафика. Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence Number Counter; должен вызывать событие аудита и предотвращать передачу дополнительных пакетов по данной SA (используется только для исходящего трафика). Алгоритм обеспечения целостности, ключи и параметры. Алгоритм шифрования, ключи, режим, и вектор инициализации (IV) и т. д. Время жизни данной SA: интервал времени, после которого SA должна быть заменена на новую или завершена. Это может зависеть от времени существования SA или количества байтов, переданных по SA. Режим протокола IPSec: транспортный или туннельный. Для поиска соответствующей SA в SAD используются комбинации следующих параметров: Security Parameters Index (SPI); IP-адреса назначения; IP-адреса источника; Идентификатора протокола IPSec. Безопасная ассоциация и управление ключами IPSec предполагает возможность как автоматического создания SA, так и создания SA вручную. Распределение ключей вручную является простейшим способом создания SA, определения алгоритмов и ключей, при котором администратор вручную конфигурирует каждую систему, указывая ключи и другие параметры. Такая технология применяется в маленьких, статичных окружениях и не масштабируется. Если количество узлов мало, и если все узлы расположены в пределах одного административного домена, то возможно применение ручных технологий распределения ключей. В данном случае трафик будет защищаться с использованием вручную сконфигурированных ключей. Для широкого использования IPSec был разработан протокол Internet Key Exchange (IKE). IKE является гибридным протоколом, который объединяет функции трех других протоколов. Первым из них является протокол Internet Security Association and Key Management Protocol (ISAKMP). Он определяет форматы пакетов для ведения переговоров об установлении, изменении и удалении SA. Эти форматы обеспечивают основу для совместимости оборудования с поддержкой IPSec разных производителей. Протокол ISAKMP не выполняет непосредственный обмен ключами. Он позволяет использовать несколько протоколов обмена ключами внутри одной структуры. Внутри структуры, стандартизованной для IPSec, ISAKMP связывает части протоколов обмена ключами SKEME и Oakley. Большинство процессов обмена ключами протокола IKE основано на протоколе Oakley. Этот протокол позволяет двум аутентифицированным сторонам договориться о безопасной и секретной информации для создания ключей шифрования. Oakley основан на алгоритме обмена ключами Диффи-Хеллмана (Diffie-Hellman). Алгоритм Диффи-Хеллмана может использовать один из номеров групп, которые определяют длину ключей, создаваемых в процессе обмена ключами. Чем больше номер, тем выше стойкость ключа. В протоколе Oakley определено несколько режимов обмена ключами. Эти режимы соответствуют двум фазам переговоров, определенным в протоколе ISAKMP. В первой фазе протокол Oakley определяет два режима работы: основной (main) и агрессивный (aggressive). Во второй фазе Oakley определяет один режим работы: быстрый (quick) режим. При использовании с IPSec IKE ассоциируется с IPsec Domain of Interpretation (DOI). Понятие домена IPSec (DOI) вводится для того, чтобы можно было сгруппировать относящиеся к IPSec протоколы, использующие IKE для ведения переговоров о SA. Протоколы безопасности, относящиеся к одному DOI-домену, выбирают протокол безопасности и криптографические преобразования из общего пространства имен и используют общие идентификаторы в протоколе создания SA. Они также одинаково интерпретирует данные, содержащиеся в различных сообщениях. Протоколы IPSec Сервисы безопасности трафика IPSec реализуются с использованием протоколов Authentication Header (AH) и Encapsulating Security Payload (ESP). Протокол Authentication Header (AH) обеспечивает аутентификацию источника данных и целостность сообщения, дополнительно поддерживая защиту от replay-атак. Протокол Encapsulating Security Payload (ESP) предлагает аналогичные сервисы, к которым добавляется конфиденциальность. Оба протокола обеспечивают контроль доступа, усиленный через механизм распределения ключей шифрования (протоколы Internet Key Exchange (IKE) версии 1 и 2) и управление потоками трафика в соответствии с базой данных политики безопасности (Security Policy Database). IPSecv3 (RFC 4301) требует, чтобы реализация ESP была обязательной. Протокол AH может поддерживаться, но это не обязательно. При использовании протокола ESP без функций конфиденциальности, он обеспечивает аналогичные AH сервисы. Протоколы ESP и AH могут использоваться как отдельно друг от друга, так и вместе. Однако в большинстве случаев, используется только ESP. Каждый протокол поддерживает два режима работы: транспортный (transport mode) и туннельный (tunnel mode). Протоколы ESP и AH обеспечивают защиту, добавляя к дейтаграмме заголовок (и возможно другие поля), содержащий информацию о защите. Выбор режима работы не влияет на метод, с помощью которого эти заголовки генерируются, но влияет на то, какие части IP-дейтаграммы защищаются и как заголовки ESP и AH располагаются для выполнения этого. Режим является основой для создания безопасной ассоциации (SA). Транспортный режим обычно используется для создания VPN между двумя узлами. Как следует из названия режима, он защищает сообщение, передаваемое с транспортного уровня на уровень IP. В IPv4 заголовок протокола ESP или АН добавляется перед заголовком протокола вышележащего уровня (TCP или UDP), т. е. сразу после IP-заголовка. В IPv6 заголовок протокола ESP или АН добавляется перед заголовком протокола вышележащего уровня, т. е. сразу за фиксированным заголовком и выбранными расширенными заголовками. Расширенный заголовок Destination options может быть как до, так и после заголовка протокола безопасности. В протоколе ESP транспортный режим обеспечивает сервисы безопасности только для протоколов вышележащего уровня (нагрузки IP-пакета). В случае АН защита распространяется также и на отдельные части IP-заголовка, расширенных заголовков и опций, предшествующих заголовку протокола безопасности. Туннельный режим полностью защищает IP-дейтаграмму (с заголовком и данными), формируя виртуальный туннель между устройствами с поддержкой IPSec. Заголовок протокола безопасности добавляется перед внутренним IP-заголовком, т. е. IP-заголовком оригинальной дейтаграммы, который содержит адреса ее непосредственного источника и приемника. Перед заголовком протокола безопасности добавляется внешний IP-заголовок, адресами источника и приемника в котором являются адреса шлюзов безопасности, обрабатывающих пакет. Таким образом, оригинальная IP-дейтаграмма защищается и инкапсулируется в другую IP-дейтаграмму. При использовании АН в туннельном режиме защищается весь туннелируемый IP-пакет и части внешнего IP-заголовка. Если применяется ESP, защита обеспечивается только для туннелируемого IP-пакета. Если одним из концов соединения является шлюз безопасности, то по стандартам IPSec SA обязательно должна выполняться в туннельном режиме, но многие производители допускают в этом случае как туннельный, так и транспортный режимы. Заметим, что когда трафик предназначен для шлюза безопасности, например, в случае ping- или SNMP-команд, шлюз безопасности рассматривается как узел, и, как правило, используется транспортный режим. Два узла могут при необходимости устанавливать туннельный режим. Подведем краткий итог: Узел должен поддерживать транспортный и туннельный режимы. Шлюз безопасности должен поддерживать туннельный режим. Если он также поддерживает транспортный режим, то этот режим используется только тогда, когда шлюз рассматривается как узел. Алгоритмы и методы шифрования/хэширования Протоколы AH и ESP используют алгоритмы HMAC (Hash-based Message Authentication Code, код аутентификации (проверки подлинности) сообщений, использующий хеш-функции) для обеспечения целостности сообщений. В IPSecv3 определено использование алгоритмов HMAC-MD5-96, HMAC-SHA1-96, DES-MAC, KPDK-MD5, AES-XCBC-96. Протокол ESP предоставляет возможность шифрования пакетов. Совместно с ним могут использоваться алгоритмы DES, 3DES, AES-CBC, AES-CTR, RC4, RC5, CAST, BLOWFISH и др. Методы аутентификации IPSec, как определено в IKE, делятся на три группы: цифровая подпись (digital signature), аутентификация с открытым ключом (public key) и аутентификация на основе предварительно установленных ключей (pre-shared key). Реализация IKE должна по умолчанию поддерживать следующие алгоритмы: алгоритм шифрования DES; хеш-функции MD5 и SHA1; аутентификацию на основе предварительно установленных ключей. Это требование обусловлено необходимостью обеспечения совместимости оборудования разных производителей между собой. Обработка IP-трафика На рисунке 3.56 показаны описанные ранее компоненты IPSec и их взаимодействие. Давайте подведем краткий итог и опишем процесс обработки IP-трафика. IPSec представляет собой набор открытых стандартов для обеспечения защищенных коммуникаций через IP-сети. Он полагается на два протокола безопасности трафика: AH и ESP. Управление параметрами, необходимыми для работы этих протоколов, выполняется безопасной ассоциацией (SA), т. е. ассоциацией, которая содержит параметры, используемые для защиты данной части трафика. Безопасные ассоциации хранятся в базе данных SAD. Они устанавливаются, изменяются и удаляются с помощью протокола IKE. Защита, предлагаемая IPSec, основана на правилах, определенных в базе данных SPD. Для каждого пакета она позволяет определить, будут ли к нему применены какие-либо сервисы безопасности, или он будет передан без защиты, или отброшен. При обработке исходящего трафика IPSec должен выполнить следующие шаги: При поступлении пакета уровень IPSec обращается к базе SPD, чтобы определить, как его обрабатывать. Поля заголовка пакета проверяются на совпадение с селекторами, заданными в правилах, хранящихся в SPD. Если произошло совпадение, пакет обрабатывается в соответствии с действием, указанным в правиле: отбрасывается, обходит IPSec или к нему применяется защита с помощью AH или ESP. Если к пакету применяется защита, то запись SPD содержит ссылку на соответствующую запись в SAD, которая определяет режим, криптографические алгоритмы, ключи, SPI, PMTU и т. д. Если соответствующая SA существует, трафик аутентифицируется и/или шифруется. Если вызываемая SA не существует, уровень IPSec инициирует работу протокола IKE для создания новой SA. Если SA создана успешно, в базе SPD создается новая запись для обработки исходящего трафика, в базе SAD — новые записи для исходящего и входящего трафика (для двухсторонней обработки создается пара SA). Пакет аутентифицируется и/или шифруется. Если SA не создана, пакет отбрасывается. Пакет передается на сетевой интерфейс. Обработка входящего трафика отличается от обработки исходящего. Когда интерфейс получает пакет из сети, его обработка делится на две категории: если заголовок пакета защищен IPsec, предпринимается попытка найти соответствующую SA в базе SAD; если заголовок пакета не защищен IPsec, идет обращение к базе SPD с целью определения дальнейшей обработки пакета: отбросить его или пропустить. Если пакет защищен протоколом AH или ESP, идет обращение к SAD с целью поиска соответствующей SA. Для поиска записи используется SPI или SPI + идентификатор протокола IPSec из заголовка пакета. Если SA, соответствующая SPI (SPI + идентификатор протокола IPSec) не найдена в SAD, пакет отбрасывается и администратору отправляется соответствующее уведомление. Если запись найдена, проверяется, соответствует ли пакет параметрам SA, через которую он был принят. Пакет аутентифицируется и/или расшифровывается. Если криптографическая обработка неуспешна, пакет отбрасывается и отправляется уведомление. В противном случае из пакета удаляются заголовки и концевики AH и ESP, и он передается вышележащему уровню. 3.3.2 Протокол Encapsulating Security Payload (ESP) В маршрутизаторах серии DIR-xxx и межсетевых экранах DFL-xxx по умолчанию поддерживается только протокол ESP. Поэтому в этом курсе мы будем рассматривать только его. Протокол ESP описан в RFC 4303. Он может обеспечивать следующие сервисы безопасности: Конфиденциальность (необязательно); Целостность (обязательно); Конфиденциальность и целостность (обязательно). Сервисы конфиденциальности и целостности могут использоваться в протоколе ESP независимо друг от друга. Однако это делать не рекомендуется. Использование только шифрования для обеспечения конфиденциальности данных обеспечивает защиту только от пассивных атак. Без использования целостности/аутентификации трафик становится уязвимым для некоторых видов активных атак. Сервис конфиденциальности может использоваться для повышения общей производительности системы в том случае, если вышележащие уровни обеспечивают аутентификацию и целостность. Сервисы аутентификации и целостности данных объединены в термине «целостность». Использование только сервиса целостности является альтернативой использования протокола AH, так как он быстрее в обработке и более приспособлен для встраивания во многие программные реализации. О применении только этого сервиса стороны должны договариваться в процессе работы протокола управления SA. Несмотря на то, что сервисы конфиденциальности и целостности могут использоваться независимо, стандарт рекомендует использовать их одновременно. Формат пакета ESP В пакете ESP можно выделить следующие части: Заголовок ESP (ESP Header); Нагрузка ESP (ESP Payload); Концевик ESP (ESP Tailer) Заголовок ESP разработан для обеспечения комбинаций различных сервисов в IPv4 и IPv6. Он вставляется после IP-заголовка и перед заголовком протокола вышележащего уровня (транспортный режим) или перед IP-заголовком инкапсулированной дейтаграммы (туннельный режим). Поля Протокол (IPv4) или Следующий заголовок (IPv6) в заголовке внешнего по отношению к ESP протокола должны содержать значение 50. Заголовок ESP содержит два поля: Security Parameters Index (SPI) и Sequence Number. Эти поля передаются в открытом виде. Поле Security Parameters Index (SPI) — 32-битное значение, которое вместе с IP-адресом назначения и протоколом безопасности (в данном случае ESP) однозначно идентифицируют SA для данной дейтаграммы. Поле Sequence Number — 32-битное значение монотонно возрастающего счетчика последовательности. Это значение используется для защиты от replay-атак. Обработка поля Sequence Number выполняется на стороне получателя; отправитель должен всегда передавать данное поле. Счетчик отправителя и счетчик получателя имеют значение 0 при установлении SA. Первый пакет, посылаемый с использованием данной SA, имеет Sequence Number, равный 1. Следующей частью пакета ESP является нагрузка. Payload Data является обязательным полем переменной длины, содержащим данные вышележащего протокола, тип которого указан в поле Next Header. Длина данного поля равна целому числу байтов. Если алгоритм, используемый для шифрования, требует криптографически синхронизованных данных, например, вектор инициализации IV, то эти данные также содержатся в этом поле. Третьей частью пакета ESP является концевик. Он включает поля Padding, Pad Length, Next Header и используется для шифрования. Шифруются нагрузка и концевик ESP. Заголовок ESP передается в открытом виде. Использование поля Padding (Добавление) объясняется несколькими факторами. Если используемый алгоритм шифрования требует, чтобы незашифрованный текст был кратен определенному количеству байтов, например, размеру блока для блочных алгоритмов, то поле Padding используется для дополнения незашифрованных данных (состоящих из полей Payload Data, Pad Length и Next Header) до размера, требуемого алгоритмом. Добавление может также требоваться независимо от алгоритма шифрования для гарантирования того, что полученные зашифрованные данные завершаются на 4-байтной границе. Поля Pad Length и Next Header должны быть, таким образом, расположены в 4-байтном слове, чтобы гарантировать, что поле ICV привязано к 4-байтной границе. Добавление может быть использовано для маскирования реальной длины содержимого для обеспечения конфиденциальности потока трафика. Однако следует понимать, что использование такого добавления увеличивает трафик. Поле Pad Length указывает число байтов добавления, которые расположены непосредственно перед этим полем. Next Header является 8-битовым полем, которое указывает тип данных, содержащихся в поле Payload Data, например, заголовок Extension в IPv6 или идентификатор протокола более высокого уровня. Значение данного поля выбирается из множества IP Protocol Number, определяемого IANA. Опциональное поле Integrity Check Value (ICV) переменной длины завершает пакет. Оно вычисляется для полей заголовка, нагрузки и концевика ESP. Это поле добавляется после концевика в том случае, если алгоритм обеспечения целостности использует ICV. Размещение заголовков Протокол ESP может использоваться в двух режимах: транспортном и туннельном. Первый режим применяется в основном для создания VPN между двумя узлами и обеспечивает защиту для протоколов более высокого уровня, но не для заголовка IP. Заметим, что в данном режиме для реализаций «bump-in-the-stack» и «bump-in-the-wire» может потребоваться реассемблирование входящих и исходящих IP-фрагментов. В транспортном режиме заголовок ESP расположен после IP-заголовка и перед заголовком протокола более высокого уровня, например, ТСР, UDP, ICMP и т. д. Следующий рисунок показывает добавление заголовка в транспортном режиме ESP для типичного пакета IPv4. В протоколе IPv6 ESP рассматривается как расширенный заголовок, и, таким образом, он должен появляться после расширенных заголовков Hop-by-Hop, Routing и Fragmentation. Расширенные заголовки Destination Options могут размещаться как до, так и после заголовка ESP. Следующий рисунок показывает добавление заголовка в транспортном режиме ESP для типичного пакета IPv6. Туннельный режим ESP может быть реализован как на узлах, так и на шлюзах безопасности. При использовании ESP на шлюзе безопасности для защиты транзитного трафика должен применяться туннельный режим. В туннельном режиме внутренний IP-заголовок содержит конечные адреса источника и получателя, а внешний IP-заголовок содержит IP-адреса шлюзов безопасности. В туннельном режиме ESP защищает весь внутренний IP-пакет, включая весь внутренний IP-заголовок. Расположение ESP в туннельном режиме относительно внешнего IP-заголовка является тем же самым, что и для транспортного режима. Следующие рисунки иллюстрируют добавление заголовков в туннельном режиме ESP для типичных пакетов IPv4 и IPv6. \Обработка исходящего пакета В транспортном режиме отправитель инкапсулирует информацию протокола верхнего уровня в ESP-заголовок и сохраняет без изменения IP-заголовок (и любые IP-заголовки расширения в протоколе IPv6). В туннельном режиме внешний и внутренний IP-заголовки могут по-разному соотноситься друг с другом. Поиск подходящей SA ESP применяется к исходящему пакету после того, как определено, какой SA он принадлежит. Шифрование пакета Отправитель выполняет следующие действия: Инкапсуляция в поле ESP Payload: для транспортного режима — только исходная информация протокола верхнего уровня; для туннельного режима — вся исходная IP-дейтаграмма. Добавление необходимого дополнения (поле Padding). Шифрование полученных данных (Payload Data, Padding, Pad Length, Next Header), используя ключ, алгоритм шифрования, режим алгоритма, указанные в SA. Первым выполняется шифрование, затем выполняется аутентификация (обеспечение целостности), поэтому поле ICV не зашифровано. Такой порядок обработки дает получателю возможность быстро обнаружить и отбросить повторные или фиктивные пакеты, что потенциально снижает вероятность успешного выполнения DoS-атак. Это также допускает возможность параллельной обработки пакетов получателем, например, расшифровывание может выполняться одновременно с проверкой целостности. Заметим, что, так как ICV не защищено шифрованием, для его вычисления должен применяться алгоритм обеспечения целостности с ключом. Создание Sequence Number Первый пакет, посылаемый по вновь созданной SA, имеет Sequence Number, равный 1. Если используется защита от replay-атак, отправитель проверяет, что значение счетчика не переполнилось перед созданием нового значения в поле Sequence Number. Другими словами, отправитель не должен посылать пакет по SA, если возникает переполнение Sequence Number. Отправитель повторяет пакет, если он не получил уведомления о его получении. Если счетчик переполнился, отправитель должен установить новую SA и вычислить новые ключи. Вычисление значения проверки целостности Если для SA требуется обеспечение целостности, отправитель вычисляет ICV для полей заголовка, нагрузки и концевика ESP. Таким образом, для полей SPI, Sequence Number, Payload Data, Padding (если присутствует) и Next Header вычисляется ICV. Заметим, что последние четыре поля являются зашифрованными, так как шифрование выполняется до вычисления ICV. Для некоторых алгоритмов обеспечения целостности строка байтов, для которой вычисляется ICV, должна быть кратна длине блока выбранного алгоритма. Если длина данной строки байтов не соответствует требуемой длине блока, то до вычисления ICV должно выполняться добавление в конец ESP-пакета (после поля Next Header). Октеты добавления должны иметь нулевые значения. Длина блока (и, следовательно, длина добавления) определяются из спецификации алгоритма. Данное добавление не передается вместе с пакетом. Фрагментация После описанных выше ESP-преобразований при необходимости может выполняться фрагментация пакета. Транспортный режим ESP применяется только к целым IP-дейтаграммам (не к фрагментам IP). Далее IP-пакет, для которого применено ESP-преобразование, может быть фрагментирован маршрутизаторами. Фрагменты должны повторно собираться перед ESP-преобразованием на стороне получателя. В туннельном режиме ESP применяется к IP-пакету, который может быть фрагментом IP-дейтаграммы. Обработка входящего пакета Реассемблирование Если требуется реассемблирование, то оно выполняется до ESP-обработки. Поиск подходящей SA При получении пакета, содержащего ESP-заголовок, получатель определяет подходящую однонаправленную SA, просматривая SAD. Для одноадресных SA это определяется на основе значения SPI в заголовке. В записи SAD указано, следует ли проверять номер последовательности. Также в записи SAD указаны алгоритмы и ключи, используемые для расшифровывания. Если для данного пакета не существует SA, получатель отбрасывает пакет. В этом случае данное событие записывается в лог с указанием SPI, даты и времени получения, адресов отправителя и получателя, номера последовательности и, возможно, другой информации. Заметим, что трафик управления SA, такой как IKE-пакеты, не идентифицируются SPI. Проверка номера последовательности В основе защиты от replay-атак лежит проверка корректного значения номера последовательности. Получатель проверяет, что пакет содержит номер последовательности, который не является дубликатом номера последовательности другого пакета, полученного в данной SA. Такая проверка выполняется первой, после того как найдена соответствующая SA, чтобы как можно быстрее отбросить дублирующие пакеты. |