Тема 6: Безопасность межсетевого взаимодействия и удаленного доступа Занятие 5: Лекция Тема лекции: Принципы обеспечения безопасности виртуальных сетей посредством протоколов защиты сетевого уровня

Вопросы: 1. Назначение и структура протокола IPSec 2. Формат протоколов AH, ESP, IKE

Литература 1. В. Столлингс.Криптография и защита сетей. – М.: Издательский дом «Вильямс», – 672 с. 1. В. Столлингс.Криптография и защита сетей. – М.: Издательский дом «Вильямс», – 672 с. RFC Security Architecture for the Internet Protocol. S. Kent, K. Seo. December RFC Security Architecture for the Internet Protocol. S. Kent, K. Seo. December RFC IP Authentication Header. S. Kent. December RFC IP Authentication Header. S. Kent. December RFC IP Encapsulating Security Payload (ESP). S. Kent. December RFC IP Encapsulating Security Payload (ESP). S. Kent. December RFC Internet Key Exchange Protocol Version 2 (IKEv2). C. Kaufman, P. Hoffman, Y. Nir, P. Eronen. September RFC Internet Key Exchange Protocol Version 2 (IKEv2). C. Kaufman, P. Hoffman, Y. Nir, P. Eronen. September 2010.

Основные требования к виртуальным сетям шифрованной связи (VPN) Требования к защищенной VPN: 1. Весь трафик защищенной VPN должен быть зашифрован и аутентифицирован. 2. Способы защиты в VPN должны быть согласованы между всеми участниками VPN. 3. Никто за пределами VPN не может изменить характеристики VPN. Требования к доверенной VPN: 1. Никто кроме доверенного провайдера VPN не может влиять на создание или модификацию путей в VPN. 2. Никто кроме доверенного провайдера VPN не может изменять, удалять или передавать свои данные в каналах VPN. Требования к смешанным VPN: Границы адресов защищенной VPN внутри доверенной VPN должны быть четко определены. Требования к предоставляемым провайдером VPN: Свойства и границы адресов предоставляемой провайдером VPN должны быть четко определены.

Вопрос 1. Назначение и структура протокола IPSec

IPSec (сокращение от IP Security) - определенный IETF стандарт достоверной/конфиденциальной передачи данных по сетям IP. Чаще всего IPSec используется для создания VPN (Virtual Private Network). IPSec определён в RFC с 2401 по Семейство протоколов IPSec: 1) протокол аутентификации заголовка (Authentication Header (АН), описан в RFC 2402); 2) протокол безопасности инкапсулируемых данных (полезной нагрузки) (Encapsulating Security Payload (ESP), описан в RFC 2406); 3) протоколы управления криптографическими ключами: протокол обмена ключами между сетями (Internet Key Exchange (IKE), описан в RFC 2409); протокол обмена ключами между сетями (Internet Key Exchange (IKE), описан в RFC 2409); протокол защищенных связей и управления ключами в Интернет (Internet Security Association and Key Management Protocol (ISAKMP). протокол защищенных связей и управления ключами в Интернет (Internet Security Association and Key Management Protocol (ISAKMP).

Возможности IPSec: формирование аутентифицированного защищенного канала с помощью протокола Internet Key Exchange; формирование аутентифицированного защищенного канала с помощью протокола Internet Key Exchange; обеспечение целостности данных с помощью протокола Authentication Header; обеспечение целостности данных с помощью протокола Authentication Header; шифрование и целостность данных передаваемых между двумя узлами с помощью протокола Encapsulating Security Payload. шифрование и целостность данных передаваемых между двумя узлами с помощью протокола Encapsulating Security Payload.

Протокол инкапсулирующей защиты содержимого (ESP) Протокол управления ключами Протокол аутентифицирую чего заголовка Алгоритмы шифрования Алгоритмы аутентификации данных Домен интерпретации Рис.1. Основные составляющие архитектуры средств безопасности протокола IР Sec Алгоритмы формирования ключей Архитектура IPSec

Протокол аутентифицируючего заголовка - Authentication Header, AH – для обеспечения аутентификации. Протокол инкапсулирующей защиты содержимого - Encapsulating Security payload, ESP – для обеспечения конфиденциальности, целостности и управления криптографическими ключами. Алгоритмы шифрования, контроля целостности, аутентичности и формирования ключей. Domain of Interpretation, DOI (домен интерпретации) – выполняет роль фундамента выполняет и являющийся, по сути, базой данных, хранящей сведения об алгоритмах, их параметрах, протокольных идентификаторах. Архитектура IPSec

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

Применяемые алгоритмы (RFC 4835) Требования RFC 4305 ESP Алгоритм шифрования ESP MUST обязательно NULL MUST- обязательно, но может утратить статус Triple DES-CBC [RFC2451] SHOULD+ следует, но может стать обязательным AES-CBC с ключами размером 128 битов [RFC3602] SHOULD следует AES-CTR [RFC3686] SHOULD NOT не следует DES-CBC [RFC2405] Требования RFC 4305 ESP Алгоритм идентификации ESP MUST обязательно HMAC-SHA1-96 [RFC2404] MUST обязательно NULL SHOULD+ следует, но может стать обязательным AES-XCBC-MAC-96 [RFC3566] MAY возможно HMAC-MD5-96 [RFC2403] Требования RFC 4305 AH Алгоритм идентификации AH MUST обязательно HMAC-SHA1-96 [RFC2404] SHOULD+ следует, но может стать обязательным AES-XCBC-MAC-96 [RFC3566] MAY возможно HMAC-MD5-96 [RFC2403]

Способы аутентификации: 1. Проверка подлинности при помощи системы и протокола Kerberos V ) Проверка подлинности при помощи сертификатов. 3. 3) Проверка подлинности по паролю (pre-shared secret заранее распределенной или обговоренной секретной последовательности используемой для формирования секретных ключей).

Варианты аутентификации в IPSec Рис. Использование парольной фразы для проверки подлинности и защиты обмена ключами

Security Association (SA) В рамках соединения взаимодействующих сторон возникает ситуация согласования некоторых параметров соединения в обиходе можно сказать «будем говорить на одном языке», т.е. выработка предварительного согласования набора применяемых алгоритмов и их параметров, поддерживаемых обеими сторонами. В результате, стороны должны выработать общий контекст безопасности (Security Association, SA) и затем использовать такие его элементы, как алгоритмы и их ключи.

Ассоциация безопасности SA Ассоциация безопасности Ассоциация безопасности (Security Associations (SA) - RFC 2401) включает: Ассоциация безопасности SA (Security Associations (SA) - RFC 2401) включает: 1) Индекс параметра безопасности (Security Parameter Index (SPI)); 2) IP-адрес системы назначения; 3) Тип SA – либо АН, либо ESP. Протоколы АН и ESP не могут вместе использовать одну и ту же ассоциацию безопасности SA (при этом в рамках соединения может быть до 4 SA (2 одной стороны и 2 другой)). Различают два вида контекста безопасности: 1) управляющий для аутентификации и выработки ключей (этап установления соединения); 2) протокольный – для защиты передаваемых данных (этап передачи данных).

Формирование контекстов безопасности в IPSec разделено на две фазы Сначала создается управляющий контекст, назначение которого - предоставить доверенный канал, т. е. аутентифицированный, защищенный канал для выработки (в рамках второй фазы) протокольных контекстов и, в частности, для формирования криптографических ключей, используемых протоколами AH и ESP.

Способы формирования управляючего контекста. Они различаются двумя показателями: - используемым механизмом выработки обчего секретного ключа; - степенью защиты идентификаторов общающихся сторон;

Способы формирования УК В простейшем случае секретные ключи задаются заранее (ручной метод распределения ключей). Для небольших сетей такой подход вполне работоспособен, но он не является масштабируемым. Последнее свойство может быть обеспечено при автоматической выработке и распределении секретных ключей в рамках протоколов, основанных на алгоритме Диффи-Хелмана. Пример тому - "Протокол для обмена ключами в Internet " (The Internet Key Exchange, IKE). При формировании управляючего контекста идентификаторы общающихся сторон (например, IP-адреса) могут передаваться в открытом виде или шифроваться. Поскольку ISAKMP предусматривает функционирование в режиме клиент/сервер (т. е. ISAKMP-сервер может формировать контекст для клиента), сокрытие идентификаторов в определенной степени повышает защищенность от пассивного прослушивания сети. Последовательность передаваемых сообщений, позволяющих сформировать управляющий контекст и обеспечивающих защиту идентификаторов,

Формирование управляючего контекста Этапы Инициатор Партнер 1) Заявка на контекст (предполагаемые алгоритмы и их параметры) 2) Принимаемые алгоритмы и параметры 3) Ключевой материал клиента, одноразовый номер инициатора 4) Ключевой материал сервера, одноразовый номер сервера 5) Зашифрованное и подписанное его секретным ключом сообщение, содержащее идентификатор клиента 6) Зашифрованное и подписанное его секретным ключом сообщение, содержащее идентификатор сервера

1. 1. В первом сообщении (1) инициатор направляет предложения по набору защитных алгоритмов и конкретных механизмов их реализации. Предложения упорядочиваются по степени предпочтительности (для инициатора). 2. В ответном сообщении (2) партнер информирует о сделанном выборе - какие алгоритмы и механизмы его устраивают. Для каждого класса защитных средств (генерация ключей, аутентификация, шифрование) выбирается только один элемент. 3. В сообщениях (3) и (4) инициатор и партнер отправляют свои части ключевого материала, необходимые для выработки обчего секретного ключа (опускаются детали, специфичные для алгоритма Диффи-Хелмана). Одноразовые номера (nonce) представляют собой псевдослучайные величины, служащие для защиты от воспроизведения сообщений. 4. Посредством сообщений (5) и (6) происходит обмен идентификационной информацией, подписанной (с целью аутентификации) секретным ключом отправителя и зашифрованной выработанным на предыдущих шагах общим секретным ключом. Для аутентификации предполагается использование сертификатов открытых ключей. В число подписываемых данных входят одноразовые номера.

Формирование протокольного контекста Этапы Инициатор Сервер 1) Зашифрованные результат хэш-функции, заявка на контекст (предлагаемые алгоритмы и их параметры), одноразовый номер клиента (инициатора) 2) Результат хэш-функции, принимаемые алгоритмы и параметры, одноразовый номер сервера - все в зашифрованном виде 3) Зашифрованный результат хэш-функции, среди аргументов которой - оба одноразовых номера

Формирование SA осуществляется на основе задаваемых администратором правил. Правила IPSec расположены в базе данных политики безопасности (Security Policy Database, SPD). База данных протокольных контекстов безопасности (Security Association Database, SAD).

Политики Безопасности Security Policy Database- SPD Защита основана на требованиях, определенных в Базе Данных Политики Безопасности (Security Policy Database- SPD), определяемой и поддерживаемой системным администратором. Пакеты обрабатываются одним из трех способов на основании соответствия информации заголовка IP или транспортного уровня записям в SPD. Способ фильтрации: 1. отбрасывается сервисом безопасности IPSec; 2. пропускается без изменения; 3. обрабатывается сервисом IPSec на основе применения определенной политики.

Элементы политики безопасности IPSec Рис. Выбор списка фильтров для нового правила

База данных политики безопасности SPD содержит: допустимые операции по обработке пакета, используемые протоколы, режим IPSec, методы аутентификации и шифрования, а также указатель на ассоциацию безопасности. База данных политики безопасности (SPD) представляет собой упорядоченный набор правил. Каждое правило задается как пара: совокупность правил фильтрации (селекторов); совокупность правил фильтрации (селекторов); совокупность протокольных контекстов безопасности. совокупность протокольных контекстов безопасности. Селектор - совокупность анализируемых полей сетевого и более высоких протокольных уровней. Селекторы служат для отбора пакетов. Отбор каждого отдельно взятого входячего или исходячего пакета осуществляется посредством проверки IP- адреса отправителя, IP-адреса получателя, типа используемого протокола и порта. Политика безопасности должна быть задана для каждого сетевого интерфейса с задействованными средствами IPsec и для каждого направления потоков данных (входячего/исходячего). База данных политики безопасности SPD

База данных протокольных контекстов (SAD) содержит : используемый в АН алгоритм аутентификации, его ключи и т.п.; используемый в АН алгоритм аутентификации, его ключи и т.п.; используемый в ESP алгоритм шифрования, его ключи, начальный вектор и т.п.; используемый в ESP алгоритм шифрования, его ключи, начальный вектор и т.п.; используемый в ESP алгоритм аутентификации, его ключи и т.п.; используемый в ESP алгоритм аутентификации, его ключи и т.п.; время жизни контекста; время жизни контекста; режим работы IPsec: транспортный или туннельный; режим работы IPsec: транспортный или туннельный; максимальный размер пакетов (MTU); максимальный размер пакетов (MTU); защиту от воспроизведения пакетов (счетчик определяющий сведения о порядковом номере пакета, окно, флаги). защиту от воспроизведения пакетов (счетчик определяющий сведения о порядковом номере пакета, окно, флаги). База данных протокольных контекстов (SAD)

Политики IPSec в оснастке Редактор объекта групповой политики

Протокол IPSec может работать в одном из двух режимов: транспортном и туннельном. Транспортный режим (Transport mode) как правило устанавливается между двумя оконечными ПЭВМ. В этом случае передаваемые данные шифруются от ПЭВМ источника до ПЭВМ получателя. При соединении в транспортном режиме исходный заголовок сохраняется и служит для маршрутизации пакета. Туннельный режим (Tunnel mode) как правило, устанавливается между двумя специально выделенными защитными шлюзами (в роли которых могут выступать маршрутизаторы). В туннельном режиме данные должны быть защищены при передаче по открытой частной сети. Защищается весь пакет - он инкапсулируется в другой IP-пакет. При этом исходный заголовок IP получает новый заголовок IPSec. В заголовке указывается адрес начала и конца туннеля. Режимы работы IPSec

Транспортный режим (Transport mode)

В этом варианте механизмы безопасности применяются только для протоколов, начиная с транспортного (TCP) уровня и выше, оставляя данные самого сетевого уровня (заголовок IP) без дополнительной защиты. Места размещения дополнительной информации, вставляемой протоколами в пакет Транспортный режим (Transport mode)

Туннельный режим (Tunnel mode)

Данный режим обеспечивает защиту также и данных сетевого уровня путем добавления нового IP-заголовка. После определения ассоциаций безопасности (например, между двумя шлюзами) истинные адреса хостов отправления и назначения (и другие служебные поля) полностью защищаются от модификаций для АН или вообще скрываются для ESP, а в новый заголовок выставляются адреса и другие данные для шлюзов (отправления/получения).

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

Вопрос 2 Вопрос. Формат протоколов AH, ESP, IKE

Протокол аутентифицируючего заголовка служит в IPsec для обеспечения целостности пакетов и аутентификации источника данных, а также для защиты от атаки воспроизведения ранее посланных пакетов. Структура AH: 1) Следующий заголовок; 2) Длина; 3) SPI; 4) Порядковый номер; 5) Данные аутентификации Заголовок аутентификации (Authentication Header, АН) содержит криптографическую контрольную сумму целой дейтаграммы и добавляется в дейтаграмму IPSec после обычного IP-заголовка, как показано на рис. 4. АН обеспечивает как целостность данных, так и защиту от ложного воспроизведения (получатель отслеживает дейтаграммы с помощью 64-битного счетчика). Authentication Header

Рис. 4. Дейтаграмма IPSec с заголовком аутентификации

Заголовок АН содержит следующие данные: Next Header (Следующий заголовок) - номер протокола обычного заголовка 4 уровня. Payload Length (Длина заголовка) – длина заголовка АН. Security Parameter Index (Индекс параметра безопасности, SPI) – 32-битное число, позволяющее отличать АН-содинения от других соединений с той же целевой системой. Sequence Number (Последовательный номер) – последовательный номер дейтаграммы АН, обеспечивающий защиту ответа. Integrity Chech Value (Контрольная сумма целостности, ICV) Криптографическая контрольная сумма дейтаграммы АН.

Протокол инкапсулирующей защиты (Encapsulating Security Payload, ESP) обеспечивает: конфиденциальность (шифрование) содержимого IP-пакетов, а также частичную защиту от анализа трафика путем применения туннельного режима); конфиденциальность (шифрование) содержимого IP-пакетов, а также частичную защиту от анализа трафика путем применения туннельного режима); целостность IP-пакетов и аутентификацию источника данных; целостность IP-пакетов и аутентификацию источника данных; защиту от воспроизведения IP-пакетов. защиту от воспроизведения IP-пакетов. Протокол инкапсулирующей защиты (Encapsulating Security Payload, ESP)

Формирование защищенных данных в IP пакете при применении протокола ESP семейства протоколов IPSec

Структура заголовка ESP: 1) SPI; 2) Порядковый номер Структура трейлера ESP: 1) Дополнение (отступ); 2) Длина дополнения (отступа); 3) Следующий заголовок (TCP/UDP).

Рис. 7. Формат заголовка ESP.

Сравнение форматов PPTP/MPPE и L2TP/IPSec

Процедуры обмена ключами IKE

Обмен ключами IKEv2 IKE выполняет взаимную идентификацию партнеров и организует защищенную связь IKE SA, включающую разделяемый секретный ключ, который может эффективно использоваться при организации SA для протоколов ESP [RFC4303] и/или AH [RFC4302], и набор криптографических алгоритмов, которые будут использоваться SA для защиты передаваемого трафика. IKE выполняет взаимную идентификацию партнеров и организует защищенную связь IKE SA, включающую разделяемый секретный ключ, который может эффективно использоваться при организации SA для протоколов ESP [RFC4303] и/или AH [RFC4302], и набор криптографических алгоритмов, которые будут использоваться SA для защиты передаваемого трафика. Инициатор предлагает один или несколько наборов, перечисляя поддерживаемые им алгоритмы, которые могут быть объединены в наборы или использоваться «вперемешку». IKE может также согласовывать использование сжатия IP (IPComp) совместно в ESP и/или AH SA. Инициатор предлагает один или несколько наборов, перечисляя поддерживаемые им алгоритмы, которые могут быть объединены в наборы или использоваться «вперемешку». IKE может также согласовывать использование сжатия IP (IPComp) совместно в ESP и/или AH SA. Весь обмен информацией IKE организован в форме парных сообщений запрос отклик. Первые сообщения при организации IKE_SA включают обмен IKE_SA_INIT и IKE_AUTH, а за ними следуют обмены CREATE_CHILD_SA или INFORMATIONAL. В общем случае для организации IKE_SA и первой связи CHILD_SA используется один обмен IKE_SA_INIT и один обмен IKE_AUTH (всего 4 сообщения). В исключительных случаях оба обмена могут использоваться неоднократно. В любом случае все обмены IKE_SA_INIT должны быть завершены до начала обмена любого другого типа, после этого должны быть завершены все обмены IKE_AUTH и далее могут выполняться в любом порядке обмены CREATE_CHILD_SA и INFORMATIONAL. В некоторых сценариях между конечными точками IPsec требуется только один обмен CHILD_SA и, следовательно, не возникает дополнительных обменов. Последующие обмены могут использоваться для организации дополнительных CHILD_SA между теми же идентифицированными парами конечных точек и для выполнения вспомогательных функций. Весь обмен информацией IKE организован в форме парных сообщений запрос отклик. Первые сообщения при организации IKE_SA включают обмен IKE_SA_INIT и IKE_AUTH, а за ними следуют обмены CREATE_CHILD_SA или INFORMATIONAL. В общем случае для организации IKE_SA и первой связи CHILD_SA используется один обмен IKE_SA_INIT и один обмен IKE_AUTH (всего 4 сообщения). В исключительных случаях оба обмена могут использоваться неоднократно. В любом случае все обмены IKE_SA_INIT должны быть завершены до начала обмена любого другого типа, после этого должны быть завершены все обмены IKE_AUTH и далее могут выполняться в любом порядке обмены CREATE_CHILD_SA и INFORMATIONAL. В некоторых сценариях между конечными точками IPsec требуется только один обмен CHILD_SA и, следовательно, не возникает дополнительных обменов. Последующие обмены могут использоваться для организации дополнительных CHILD_SA между теми же идентифицированными парами конечных точек и для выполнения вспомогательных функций. Поток сообщений IKE всегда состоит из запросов, за которыми следует соответствующий отклик. Ответственность за обеспечение надежности возлагается на запрашивающую сторону. Если отклик не получен в течение заданного времени ожидания, запрашивающая сторона должна повторить запрос (или прервать попытку соединения). Поток сообщений IKE всегда состоит из запросов, за которыми следует соответствующий отклик. Ответственность за обеспечение надежности возлагается на запрашивающую сторону. Если отклик не получен в течение заданного времени ожидания, запрашивающая сторона должна повторить запрос (или прервать попытку соединения). Первый запрос/отклик в сеансе IKE (IKE_SA_INIT) согласует параметры защиты для IKE_SA, передает специальные сигналы nonce и значения Diffie-Hellman. Первый запрос/отклик в сеансе IKE (IKE_SA_INIT) согласует параметры защиты для IKE_SA, передает специальные сигналы nonce и значения Diffie-Hellman. Вторая пара запрос/отклик (IKE_AUTH) передает идентификацию, обеспечивает информацию о секретах идентифицированных сторон и организует защищенную связь для первой (зачастую, единственной) AH или ESP CHILD_SA. Вторая пара запрос/отклик (IKE_AUTH) передает идентификацию, обеспечивает информацию о секретах идентифицированных сторон и организует защищенную связь для первой (зачастую, единственной) AH или ESP CHILD_SA. Последующие обмены относятся к типу CREATE_CHILD_SA (создание CHILD_SA) и INFORMATIONAL (удаление SA, сообщения об ошибках и другие служебные функции). Каждый запрос требует отклика. Запросы типа INFORMATIONAL, не содержащие информации (кроме пустого поля Encrypted payload, требуемого синтаксисом) обычно используются для проверки сохранности соединения. Последующие обмены не могут осуществляться, пока не будут завершены начальные обмены. Последующие обмены относятся к типу CREATE_CHILD_SA (создание CHILD_SA) и INFORMATIONAL (удаление SA, сообщения об ошибках и другие служебные функции). Каждый запрос требует отклика. Запросы типа INFORMATIONAL, не содержащие информации (кроме пустого поля Encrypted payload, требуемого синтаксисом) обычно используются для проверки сохранности соединения. Последующие обмены не могут осуществляться, пока не будут завершены начальные обмены.

Сравнительные параметры некоторых отечественных и зарубежных средств защиты для построения VPN Параметр Windows 2003 Cisco 1OS 12. x CheckРoint FW-1 МШ «ШИП» ЗАСТАВА 2.5 Протокол, реали­зующий виртуаль­ ные туннели PPTP L2TP/IPSeс IPSecSKIPIPSec/SKIP Поддерживаемые аппаратные плат­ формы IntelCisco Intel, Sun-SPARC, HP и др. IntelIntel, Sun-SPARC Поддерживаемые ОС-IOS 12. x Windows; Solaris; Linux, HP FreeBSD Windows 2000; Solaris Аутентификация и поддержка целост­ности пакетов Нет/Да Да Используемые алгоритмы шифро­ вания RC4; 3DESAES; 3DES AES; 3DES; CAST; IDEA и др. ГОСТ ГОСТ ; ВЕСТА- 2М; 3DES Максим. криптостойкость (длина ключа, бит) Максимальная производительность (АП –аппаратная платформа) зависит от АП 250 МБайт/с зависит от АП 8 МБайт/с зависит от АП Средства построения собственной ключевой системы Нет Да Поддержка внешних систем распределения ключей и сертификатов (PKI) Да Нет Да