Вход в личный кабинет Архитектура средств безопасности ipsec
Основное назначение протоколов IPSec – обеспечение безопасной передачи данных по сетям IP. Применение IPSec гарантирует:
- целостность передаваемых данных, то есть данные при передаче не искажены, не потеряны и не продублированы;
- аутентичность отправителя, то есть данные переданы именно тем отправителем, который доказал, что он тот, за кого себя выдает;
- конфиденциальность передаваемых данных, то есть данные передаются в форме, предотвращающей их несанкционированный просмотр.
Следует отметить, что обычно в понятие безопасности данных включают еще одно требование – доступность данных, что в рассматриваемом контексте можно интерпретировать как гарантию их доставки. Протоколы IPSec не решают данную задачу, оставляя ее протоколу транспортного уровня TCP.
Рис. 1. Структура IP-пакета
Фундаментальной единицей коммуникации в IP-сетях является IP-пакет. Структура IP-пакета показана на рис. 1. IP-пакет содержит S-адрес источника и D-адрес получателя сообщения, транспортный заголовок, информацию о типе данных, переносимых в этом пакете, и сами данные.
Для того чтобы обеспечить аутентификацию, конфиденциальность и целостность передаваемых данных стек протоколов IPSec построен на базе ряда стандартизованных криптографических технологий:
- обмены ключами согласно алгоритму Диффи–Хеллмана для распределения секретных ключей между пользователями в открытой сети;
- криптография открытых ключей для подписывания обменов Диффи–Хеллмана, чтобы гарантировать подлинность двух сторон и избежать атак типа «человек в середине»;
- цифровые сертификаты для подтверждения подлинности открытых ключей;
- блочные симметричные алгоритмы шифрования данных;
- алгоритмы аутентификации сообщений на базе функций хэширования.
Протокол IРSес представляет собой систему открытых стандартов, которая имеет четко очерченное ядро и которую можно дополнять новыми протоколами, алгоритмами и функциями. Стандартизованными функциями IРSес-защиты могут пользоваться протоколы более высоких уровней, в частности управляющие протоколы, протоколы конфигурирования, а также протоколы маршрутизации.
Основными задачами установления и поддержания защищенного канала являются следующие:
- аутентификация пользователей или компьютеров при инициации защищенного канала;
- шифрование и аутентификация передаваемых данных между конечными точками защищенного канала;
- обеспечение конечных точек канала секретными ключами, необходимыми для работы протоколов аутентификации и шифрования данных.
Для решения перечисленных задач система IРSес использует комплекс средств безопасности информационного обмена.
Большинство реализаций протокола IPSec имеют следующие компоненты:
- основной протокол IPSec. Этот компонент реализует протокол инкапсулирующей защиты ESP и протокол аутентифицирующего заголовка AH. Он обрабатывает заголовки, взаимодействует с базами данных SPD и SAD для определения политики безопасности, применяемой к пакету;
- протокол управления обменом ключевой информации IKE (Internet Key Exchange). IKE обычно представляется как процесс пользовательского уровня, за исключением реализаций, встроенных в операционную систему;
- базу данных политик безопасности SPD (Security Policy Database). Это один из важнейших компонентов, поскольку он определяет политику безопасности, применяемую к пакету. SPD используется основным протоколом IPSec при обработке входящих и исходящих пакетов;
- базу данных безопасных ассоциаций SAD (Security Association Database). База данных SAD хранит список безопасных ассоциаций SA (Security Association) для обработки входящей и исходящей информации. Исходящие SA используются для защиты исходящих пакетов, а входящие SA – для обработки пакетов с заголовками IPSec. База данных SAD заполняется SA вручную или с помощью протокола управления ключами IKE;
- управление политикой безопасности и безопасными ассоциациями SA. Это приложения, которые управляют политикой безопасности и SA.
Основной протокол IPSec (реализующий ESP и AH) тесно взаимодействует с транспортным и сетевым уровнями стека протоколов TCP/IP. Фактически протокол IPSec является частью сетевого уровня. Основной модуль протокола IPSec обеспечивает два интерфейса: входной и выходной.
Базы данных SPD и SAD существенно влияют на эффективность работы IPSec. Выбор структуры данных для хранения SPD и SAD является критическим моментом, от которого зависит производительность IPSec. Особенности реализации SPD и SAD зависят от требований производительности и совместимости системы.
Все протоколы, входящие в IPSec, можно разделить на две группы:
- протоколы, непосредственно производящие обработку передаваемых данных (для обеспечения их защиты);
- протоколы, позволяющие автоматически согласовать параметры защищенных соединений, необходимые для протоколов первой группы.
Ядро IPSec составляют три протокола:
- протокол аутентифицирующего заголовка AH (Authentication Header),
- протокол инкапсулирующей защиты ESP (Encapsulating Security Payload),
- протокол согласования параметров виртуального канала и управления ключами IKE (Internet Key Exchange).
Архитектура средств безопасности IРSес представлена на рис. 2.
Рис. 2. Архитектура стека протоколов IPSec
На верхнем уровне расположены следующие протоколы:
- протокол согласования параметров виртуального канала и управления ключами IКЕ, определяющий способ инициализации защищенного канала, включая согласование используемых алгоритмов криптозащиты, а также процедуры обмена и управления секретными ключами в рамках защищенного соединения;
- протокол аутентифицирующего заголовка АН, обеспечивающий аутентификацию источника данных, проверку их целостности и подлинности после приема, а также защиту от навязывания повторных сообщений;
- протокол инкапсулирующей защиты содержимого ЕSР, обеспечивающий криптографическое закрытие, аутентификацию и целостность передаваемых данных, а также защиту от навязывания повторных сообщений.
Разделение функций защиты между двумя протоколами AH и ESP обусловлено применяемой во многих странах практикой ограничения экспорта и/или импорта средств, обеспечивающих конфиденциальность данных путем шифрования. Каждый из протоколов AH и ESP может использоваться как самостоятельно, так и совместно с другим. Из краткого перечисления функций протоколов AH и ESP видно, что возможности этих протоколов частично перекрываются.
Протокол AH отвечает только за обеспечение целостности и аутентификации данных, в то время как протокол ESP является более мощным, поскольку может шифровать данные, а кроме того, способен выполнять функции протокола AH (хотя, как увидим позднее, аутентификация и целостность обеспечиваются им в несколько урезанном виде).
Протокол ESP может поддерживать функции шифрования и аутентификации/обеспечения целостности в любых комбинациях, то есть либо и ту и другую группу функций, либо только аутентификацию/обеспечение целостности, либо только шифрование.
Для шифрования данных в IPSec (протокол ESP) может быть применен практически любой симметричный алгоритм шифрования с секретными ключами. Для обеспечения целостности и аутентификации данных (протоколы АН и ESP) используется один из приемов шифрования – шифрование с помощью односторонней функции (One-way Function), называемой также дайджест-функцией (Digest Function).
Протоколы IКЕ, АН и ЕSР взаимодействуют следующим образом.
Сначала с помощью протокола IКЕ между двумя точками устанавливается логическое соединение, которое в стандартах IРSес получило название «безопасная ассоциация SА». При установлении этого логического соединения выполняется аутентификация конечных точек канала, а также выбираются параметры защиты данных, например, алгоритм шифрования, сессионный секретный ключ и т. п.
Затем в рамках установленной безопасной ассоциации SА начинает работать протокол АН или ЕSР, с помощью которого и выполняется требуемая защита передаваемых данных с использованием выбранных параметров.
Средний уровень архитектуры IРSес образуют алгоритмы согласования параметров и управления ключами, применяемые в протоколе IKE, а также алгоритмы аутентификации и шифрования, используемые в протоколах аутентифицирующего заголовка АН и инкапсулирующей защиты содержимого ЕSР.
Следует отметить, что протоколы защиты виртуального канала верхнего уровня архитектуры IРSес (АН и ЕSР) не зависят от конкретных криптографических алгоритмов. За счет возможности использования большого количества разнообразных алгоритмов аутентификации и шифрования IРSес обеспечивает высокую степень гибкости организации защиты сети.
Гибкость IРSес состоит в том, что для каждой задачи предлагается несколько способов ее решения. Выбранные методы для одной задачи обычно не зависят от методов реализации других задач. Например, выбор для шифрования алгоритма DЕS не влияет на выбор функции вычисления дайджеста, используемого для аутентификации данных.
Нижний уровень архитектуры IPSec образует так называемый домен интерпретации DOI. Необходимость применения домена интерпретации DOI обусловлена следующими причинами. Протоколы АН и ESP имеют модульную структуру, допуская применение пользователями по их согласованному выбору различных криптографических алгоритмов шифрования и аутентификации.
Поэтому необходим модуль, который мог бы обеспечить совместную работу всех применяемых и вновь включаемых протоколов и алгоритмов. Именно такие функции возложены на домен интерпретации DOI. Домен интерпретации DOI в качестве базы данных хранит сведения об используемых в IPSec протоколах и алгоритмах, их параметрах, протокольных идентификаторах и т. п.
По существу, домен интерпретации DOI выполняет роль фундамента в архитектуре IPSec. Для того чтобы использовать алгоритмы, соответствующие национальным стандартам в качестве алгоритмов аутентификации и шифрования в протоколах АН и ESP, необходимо зарегистрировать эти алгоритмы в домене интерпретации DOI.
Для того чтобы протоколы AH и ESP могли выполнять свою работу по защите передаваемых данных, между конечными узлами необходимо установить безопасную ассоциацию SA. Цель SA – обеспечить достоверную идентификацию каждого конечного узла (данный процесс называется взаимной аутентификацией конечных узлов) и установить согласованные параметры защищенного соединения.
Для установления безопасной ассоциации SA между двумя конечными точками используется протокол ISAKMP (Internet Security Association and Key Management Protocol), входящий в состав протокола согласования параметров виртуального канала и управления ключами IКЕ.
Установление SA начинается со взаимной аутентификации сторон. Выбираемые далее параметры SA определяют, какой из двух протоколов, AH или ESP, применяется для защиты данных, какие функции выполняет протокол защиты: например, только аутентификацию и проверку целостности или, кроме того, и защиту конфиденциальности данных.
Важным параметром безопасной ассоциации SA является так называемый ключевой материал, то есть секретные криптографические ключи, используемые в работе протоколов AH и ESP. В целях безопасности IPSec никогда не пересылает ключи по сети; пересылаются данные, необходимые каждому конечному узлу, чтобы локально генерировать ключ.
Параметры безопасной ассоциации должны устраивать обе конечные точки защищенного канала. Поэтому при использовании автоматической процедуры установления SA протоколы IKE, работающие по разные стороны канала, выбирают параметры на основе взаимного согласования.
Безопасная ассоциация SA представляет собой в IPSec однонаправленное логическое соединение, поэтому при двустороннем обмене данными необходимо установить две ассоциации SA. После того как между конечными узлами согласованы параметры шифрования, хэш-алгоритм и методы аутентификации, эти узлы создают одно соединение SA для входящих пакетов данных и другое – для исходящих.
Протоколы AH или ESP функционируют уже в рамках установленного логического соединения SA, с его помощью и осуществляется требуемая защита передаваемых данных с использованием выбранных параметров.
Теория и практика dmvpn
Абстрагируясь от нашей старой сети, возьмём в рассмотрение только Москву, сеть Интернет, которую будет эмулировать маршрутизатор Балаган-Телеком, и собственно филиалы в Новосибирске, Томске и Брно:
Новый IP-план:Подсети, выделенные для подключения к интернету филиалов:
LAN:
Для туннельных интерфейсов возьмём внутреннюю сеть:
И назначим также адреса Loopback для них:
Идея заключается в том, что на центральном узле будет один единственный динамический туннель, который мы настроим в самом начале, а при добавлении новых удалённых точек, здесь не нужны изменения – ни добавлять новые туннельные интерфейсы, ни перенастраивать уже существующий.
Фактически при добавлении новых узлов настраивать нужно только их.Везде запускается протокол NHRP – NBMA Next Hop resolution Protocol.Он позволяет динамически изучать адреса удалённых точек, который желают подключиться к основной.
На нём и основана возможность реализации multipoint VPN. Хаб (центральный узел) здесь выступает как сервер (NHS – Next-Hop Server), а все удалённые узлы будут клиентами (NHC – Next-Hop Client).Звучит это сложно. На пальцах объяснить тоже не получится. Надо лишь один раз настроить и посмотреть, как бегают пакеты.
Конфигурация хаба:
interface Tunnel0
ip address 172.16.254.1 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source FastEthernet0/1.6
tunnel mode gre multipoint
По порядку:
ip address 172.16.254.1 255.255.255.0
– IP-адрес из нужного диапазона.
ip nhrp map multicast dynamic
– Динамическое изучение данных NHRP от клиентов. Поскольку клиентов у нас множество и они могут быть с динамическими адресами, на хабе нельзя задать явное соответствие внутренних и внешних адресов.
ip nhrp network-id 1
– Определяем Network ID – просто идентификатор, который необязательно должен быть одинаковым на всех узлах DMVPN (похож на OSPF Router-ID).
tunnel source FastEthernet0/1.6
– наследие GRE – привязка к физическому интерфейсу.
tunnel mode gre multipoint
– Туннель на центральном узле будет терминировать все туннели от удалённых точек. То есть он будет точка-многоточка (Point-to-MultiPoint).
Конфигурация филиала:
interface Tunnel0
ip address 172.16.254.2 255.255.255.0
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip nhrp registration no-unique
tunnel source FastEthernet0/0
tunnel mode gre multipoint
По порядку:ip address 172.16.254.2 255.255.255.0 – IP-адрес из нужного диапазона. ip nhrp map 172.16.254.1 198.51.100.2 – Статическое соотношение внутреннего и внешнего адресов хаба. ip nhrp map multicast 198.51.100.2 мультикастовый трафик должен получать хаб.
Без этой команды у вас будут довольно интересные симптомы проблемы.
Вот вы запустили OSPF, пиринг поднимается, хаб и филиалы переходят в состояние Full, обменялись маршрутами, и вы уже радуетесь, что всё отлично, и тут бац – пинг пропадает, пиринг падает, но только с одной стороны, мол истёк dead-timer.
*Mar 1 01:51:20.331: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Dead timer expired
msk-arbat-gw1#
*Mar 1 01:51:25.435: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from LOADING to FULL, Loading Done
Что за фигня?
Смотрим дебаг, смотрим дампы
*Mar 1 01:53:44.915: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:44.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:44.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:53:54.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:54.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:54.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:54.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:54.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:54:04.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:54:04.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:54:04.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:54:04.935: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:54:04.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
На 5 OSPF Hello от хаба только один Hello от филиала.
Как вы уже поняли, маршрутизатор просто не может сообразить куда посылать мультикастовые сообщения на адрес 224.0.0.5, хаб их не получает и дёргает OSPF-сессию.
ip nhrp network-id 1 – Network ID. Не обязательно должен совпадать с таким же на хабе. ip nhrp nhs 172.16.254.1 – Статически настроенный адрес NHRP сервера – хаба. Именно поэтому в центре нам нужен статический публичный адрес.
Клиенты отправляют запрос на регистрацию на хаб 172.16.254.1. Этот запрос содержит настроенный локальный адрес туннельного интерфейса, а также свой публичный адрес (случай, когда клиент находится за NAT пока не рассматриваем).Полученную информацию хаб заносит в свою NHRP-таблицу соответствия адресов. Эту же таблицу он распространяет по запросу любому Spoke-маршрутизатору.
ip nhrp registration no-unique – если адрес в филиалах выдаётся динамически, эта команда обязательна. tunnel source FastEthernet0/0 – привязка к физическому интерфейсу. tunnel mode gre multipoint – указываем, что тип туннеля mGRE – это позволит создавать динамически туннели не только до хаба, но и до других филиалов.
У нас ситуация простая – без NAT – и мы можем уже сейчас проверить состояние туннелей.
msk-arbat-gw1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.254.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 198.51.100.2 (FastEthernet0/1.6), destination UNKNOWN
Tunnel protocol/transport multi-GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled