 |
|
|
|
OpenBSD: особенности организации VPN на основе набора протоколов IPsec
OpenBSD: особенности организации VPN Одной из задач, с которыми приходится иметь дело системным администраторам (администраторам сети) развивающихся многофилиальных бизнес-структур или организаций, является обьединение территориально разграниченных подсетей в единую сетевую инфраструктуру. Как правило, эта задача решается путем организации VPN (Virtual Private Network), соединяющей разрозненные подсети защищенным каналом передачи данных поверх существующего небезопасного канала (как правило, Интернета). На данный момент существует несколько протоколов, стандартизирующих процесс организации VPN, и большое количество их программных реализаций. Наиболее известными среди них являются: IPsec (FreeS/WAN, Openswan, strongSwan, KAME/racoon, Isakmpd), SSL/TLS/OpenVPN (OpenVPN), PPTP/L2TP (poptop, OpenL2TP) и другие. Среди перечисленных выше набор протоколов IPsec выделяется благодаря сочетанию высокого уровня защиты передаваемых конфиденциальных данных и гибкости использования. Высокий уровень защиты достигается благодаря использованию надежных механизмов аутентификации и шифрования, гибкость – благодаря использованию 3-го (сетевого) уровня модели OSI, а следовательно, возможности защиты протоколов высших уровней, таких как TCP и UDP. Следует также отметить, что большой популярностью пользуется протокол L2TP или «L2TP поверх IPsec», который обеспечивает инкапсуляцию данных по протоколу PPP и последующее шифрование средствами IPsec. Основными задачами набора протоколов IPsec являются:
Выполнение вышеперечисленных задач связано с использованием специальных протоколов ESP (Encapsulating Security Payload) и AH (Authentication Header). Различия между протоколами заключаются в том, что протокол AH обеспечивает проверку целостности, аутентификацию и защиту от воспроизведения (т.е. выполнение 2-4 задач), но при этом не обеспечивает шифрование/дешифрование передаваемых данных. В свою очередь протокол ESP обеспечивает выполнение всех четырех задач, включая криптографическую защиту передаваемых данных. Возможно отдельное или комбинированное использование протоколов. Существует два режима работы IPsec: транспортный и туннельный. В транспортном режиме защите (шифрованию и хешированию) подвергается только поле данных IP-пакета, при этом заголовок IP-пакета остается незащищенным, что облегчает маршрутизацию таких пакетов, однако это также делает доступной для злоумышленника информацию об объемах и направлениях передачи данных, расположении участников сеанса. Транспортный режим применяется для соединений типа «хост-хост». В туннельном режиме защите подвергается IP-пакет в целом. При этом заголовок IP-пакета формируется пограничным маршрутизатором (одним из тех, которые непосредственно формируют «туннель») и не содержит информации о конкретном отправителе пакета. Все пакеты извне (т.е. из других подсетей VPN), предназначенные для абонентов, находящихся внутри подсети, подключенной к VPN, маршрутизируются пограничному маршрутизатору этой подсети и только после расшифровки маршрутизатором пакет направляется получателю. Туннельный режим применяется при организации соединений типа «сеть-сеть», «хост-сеть» и «хост-хост». Одним из существенных недостатков IPsec является то, что IPsec-трафик не может маршрутизироваться через шлюзы, осуществляющие NAT-преобразования (Network Address Translation) пакетов без дополнительной инкапсуляции ESP в UDP (NAT-T, NAT Traversal in the IKE). Это происходит из-за того, что в случае использования протокола АН в процессе передачи контролируется целостность данных (в том числе и заголовка IP-пакета), а поскольку NAT изменяет заголовок пакета, то это приводит к возникновению ошибок при проверке целостности передаваемых пакетов. Поэтому данные, передаваемые с использованием протокола АН, не могут быть подвержены NAT-преобразованиям. При работе по протоколу ESP в туннельном режиме шифруются и данные и заголовок IP-пакета, после этого он повторно инкапсулируется в IP-пакет. Заголовок IP остается нетронутым и может быть преобразован. Такая ситуация характерна только в случае динамического NAT-преобразования, когда изменяется только IP-адрес источника. Однако на практике очень часто применяется NAT-преобразование на уровне портов (NAPT), при котором изменению подвергается не только адрес источника в заголовке IP-пакета, но и порт источника, значение которого хранится в заголовке пакета TCP/UDP. В таком случае маршрутизатор, осуществляющий NAPT-преобразование, не может получить доступ к содержимому заголовка TCP- или UDP-пакета, и, следовательно, не может осуществить преобразование. В транспортном режиме шифрованию подвергаются только данные, содержащиеся в IP-пакете. Заголовок пакета остается открытым, что позволяет беспрепятственно подвергать такие пакеты динамическому NAT-преобразованию. В случае NAPT-преобразования ситуация аналогична туннельному режиму, поскольку данные, включая и содержимое заголовка TCP- или UDP-пакета, зашифрованы. При NAT-T-преобразовании IP-пакеты, защищенные IPSec, предварительно упаковываются в UDP-пакеты и только после этого подвергаются NAT-преобразованию [5, 6]. В данной статье речь пойдет о isakmpd (ISAKMP/Oakley a.k.a IKE key management daemon) и ipsecctl, программной реализации набора протоколов IPsec, входящей в набор пользовательского программного обеспечения (userland) ОС OpenBSD. Схема развертывания VPN приведена на рисунке. На схеме изображен типовой сегмент VPN. Сети А и Б являются территориально отделенными подсетями, входящими в состав сетевой инфраструктуры многофилиальной организации. Сеть А использует диапазон IP-адресов 10.10.10.0/24, а сеть Б – 10.10.99.0/24. Шлюзами для данных подсетей являются маршрутизатор сети А (IP-адрес: ххх.ххх.ххх.1) и маршрутизатор сети Б (IP-адрес: ххх.ххх.ххх.2) соответственно. Шлюзы также являються пограничными маршрутизаторами или конечными точками (end-point) VPN. Защита передаваемых данных осуществляется только между пограничными маршрутизаторами. Организация VPN с использованием утилиты ipsecctl Ipsecctl – специализированная утилита OpenBSD, предназначенная для управления потоками (flows), которые формируют правила, определяющие, какие пакеты необходимо обрабатывать IPsec. Она позволяет создавать VPN-соединения на основе набора правил, хранящегося в конфигурационном файле /etc/ipsec.conf, а также отображать информацию о состоянии SPD (Security Policy Database) и SAD (Security Association Database), куда, собственно, и загружается информация о потоках и SA из конфигурационного файла. Для организации VPN между двумя подсетями (см. рисунок) с использованием ipsecctl необходимо выполнить следующие действия:
Общая схема развертывания VPN Активировать перенаправление пакетов на каждом из маршрутизаторов можно, используя утилитой sysctl: #sysctl net.inet.ip.forwarding=1 или раскоментировав соответствующую строку в файле /etc/sysctl.conf: net.inet.ip.forwarding=1 Перед тем как приступить к генерации ключей, необходимо выбрать алгоритмы шифрования и хеширования, которые будут использоваться при организации VPN. Информацию о возможных вариантах можно получить на странице руководства IPSEC.CONF(5) или по адресу: http://www.openbsd.org/cgi-bin/man.cgi. Для приведенного примера были выбраны алгоритм хеширования hmac-sha2-512, подразумевающий использование ключа аутентификации длиной 512 бит, и blowfish в качестве алгоритма шифрования данных, использующий ключ длинной 160 бит. Для генерации псевдослучайных ключей можно воспользоватся утилитой dd. Ключи рекомендуется разместить в директории /etc/ipsec (созданной предварительно), правами на которую владеет только пользователь root. #mkdir -m 700 /etc/ipsec Генерация ключей аутентификации и шифрования трафика для маршрутизатора сети А: #dd bs=64 count=1 if=/dev/urandom | hexdump -e '64/1 "%02x"' >/etc/ipsec/akey.local #dd bs=20 count=1 if=/dev/urandom | hexdump -e '20/1 "%02x"' >/etc/ipsec/ekey В данном примере первая команда предназначена для генерации ключа аутентификации длиной 64 байта (512 бит), результаты работы команды перенаправляются в файл /etc/ipsec/akey.local. Вторая команда – для генерации ключа шифрования трафика /etc/ipsec/ekey длиной 160 бит (20 байт). Для генерации ключа аутентификации для удаленного маршрутизатора (маршрутизатора сети Б) необходимо повторить первую команду, сменив имя файла для перенаправления вывода на akey.remote. #dd bs=64 count=1 if=/dev/urandom | hexdump -e '64/1 "%02x"' >/etc/ipsec/akey.remote Для обмена ключами между пограничными маршрутизаторами можно использовать утилиту для удаленного защищенного копирования файлов scp. Подразумевается, что к удаленному маршрутизатору имеется доступ по протоколу SSH (конфигурация по умолчанию в OpenBSD). #scp /etc/ipsec/akey.local xxx.xxx.xxx.2:/etc/ipsec/akey.remote #scp /etc/ipsec/akey.remote xxx.xxx.xxx.2:/etc/ipsec/akey.local #scp /etc/ipsec/ekey xxx.xxx.xxx.2:/etc/ipsec/ekey В данном примере копирование производилось с маршрутизатора сети А на маршрутизатор сети Б с IP-адресом ххх.ххх.ххх.2. На файлы, содержащие ключевую информацию, которые находятся в директории /etc/ipsec на каждом из маршрутизаторов, необходимо установить соответствующие права доступа. #chmod 600 /etc/ipsec/{akey*,ekey} После завершения процедуры генерации ключей необходимо задать параметры VPN-соединения в файле /etc/ipsec.conf. flow esp from 10.10.10.0/24 to 10.10.99.0/24 local xxx.xxx.xxx.1 peer xxx.xxx.xxx.2 type require esp from xxx.xxx.xxx.1 to xxx.xxx.xxx.2 spi 0xc9dbb83d:0xabd9da39 \ auth hmac-sha2-512 enc blowfish \ authkey file "/etc/ipsec/akey.local:/etc/ipsec/akey.remote" \ enckey file "/etc/ipsec/ekey:/etc/ipsec/ekey" В приведенном примере файла конфигурации для маршрутизатора сети А первая строка задает параметры потока (flow) с использованием специального протокола ESP между подсетями 10.10.10.0/24 и 10.10.99.0/24, локальной конечной точки VPN (local end-point) с IP-адресом ххх.ххх.ххх.1 (указывается для машин с несколькими интерфейсами), удаленной конечной точки VPN (remote end-point) с IP-адресом ххх.ххх.ххх.2, с режимом работы require (незашифрованый трафик запрещен). Вторая строка задает параметры ассоциаций безопасности (SA), а именно: направление и IP-адреса участников (peer-ов), значение Security Parameter Index (SPI), которое представляет собой произвольное уникальное 32-битное значение, идентифицирующее конкретную SA, параметры криптографических преобразований (аутентификация – hmac-sha2-512, шифрование – blowfish), расположение файлов, содержащих ключевые данные. Файл конфигурации для маршрутизатора сети Б будет отличатся значениями IP-адресов и параметра SPI. flow esp from 10.10.99.0/24 to 10.10.10.0/24 local xxx.xxx.xxx.2 peer xxx.xxx.xxx.1 type require esp from xxx.xxx.xxx.2 to xxx.xxx.xxx.1 spi 0xabd9da39:0xc9dbb83d \ auth hmac-sha2-512 enc blowfish \ authkey file "/etc/ipsec/akey.local:/etc/ipsec/akey.remote" \ enckey file "/etc/ipsec/ekey:/etc/ipsec/ekey" Во избежание ошибки чтения конфигурационного файла /etc/ipsec.conf утилитой ipsecctl он обязательно должен заканчиваться пустой строкой. Для правильной маршрутизации транзитного трафика на пограничных маршрутизаторах в таблицу маршрутизации ядра необходимо внести соответствующие записи для маршрутизатора сети А: #route add -net 10.10.99.0/24 xxx.xxx.xxx.2 и для маршрутизатора сети Б: #route add -net 10.10.10.0/24 xxx.xxx.xxx.1 Для автоматического добавления этих маршрутов после загрузки операционной системы необходимо добавить соответствующие команды в файл /etc/rc.local. Для «поднятия» VPN можно использовать следующую команду: #ipsecctl -vf /etc/ipsec.conf После успешного «поднятия» VPN при просмотре состояния SPD и SAD с помощью следующей команды должна отображаться подобная информация: #ipsecctl -sa
.2 spi 0xc9dbb83d auth hmac-sha2-512 enc blowfish А при просмотре таблицы маршрутизации ядра в выводе этой команды должны появиться следующие строки: #netstat -rnf encap
Следующая команда, запущенная на одном из маршрутизаторов во время «пингования» хостами из одной подсети хостов другой подсети, должна показать следующее: #tcpdump esp
Для автоматического «поднятия» VPN при запуске системы необходимо добавить в файл /etc/rc.conf.local строку: ipsec=YES Преимуществами данного способа являются быстрота развертывания VPN и простота синтаксиса конфигурационного файла. К его недостаткам можно отнести невысокую степень защиты передаваемых данных вследствии установки вручную параметров SA, отсутствия механизма автоматической смены ключевых данных. Организация VPN с использованием IKE, демона isakmpd Демон isakmpd предназначен для автоматического управления ключевыми данными и параметрами ассоциаций безопасности (SA) IPsec-трафика. Основным применением данного ПО является организация VPN. При запуске демон считывает конфигурационные параметры из файлов /etc/isakmpd/isakmpd.conf и /etc/isakmpd/isakmpd.policy. Файл /etc/isakmpd/isakmpd.conf является конфигурационным файлом isakmpd, а файл /etc/isakmpd/isakmpd.policy содержит параметры политики безопасности, определяющие требования к участникам. В режиме аутентификации с помощью общего ключа или PSK (Pre-shared Key) общий ключ используется для инициализации обмена данными, происходящего в первой фазе автоматического обмена ключевой информацией, аутентификации участников и создания защищенного канала между сторонами, позволяющего начать непосредственный обмен. В качестве PSK будет использована парольная фраза. Для организации VPN согласно схеме (см. рисунок): 1. Активировать перенаправление пакетов на пограничных маршрутизаторах (см. выше). 2. Сформировать конфигурационный файл /etc/isakmpd/isakmpd.conf. 3. Сформировать конфигурационный файл /etc/isakmpd/isakmpd.policy. 4. Добавить маршруты на удаленные подсети на пограничных маршрутизаторах (см. выше). Пункты 1-й и 4-й приведенной выше последовательности выполняются аналогично случаю с утилитой ipsecctl. Конфигурационный файл isakmpd.conf состоит из секций, название которых заключено в квадратные скобки, и наборов «параметр = значение» для каждой секции. Ниже приведено содержимое конфигурационного файла /etc/isakmpd/isakmpd.conf маршрутизатора сети А: [General]Listen-on= ххх.ххх.ххх.1 [Phase 1] ххх.ххх.ххх.2= ISAKMP-peer-B [Phase 2] Connections= IPsec-A-B [ISAKMP-peer-B] Phase= 1 Local-address= ххх.ххх.ххх.1 Address= ххх.ххх.ххх.2 Configuration= Default-main-mode Authentication= great_password [IPsec-A-B] Phase= 2 ISAKMP-peer= ISAKMP-peer-B Configuration= Default-quick-mode Local-ID= Net-A Remote-ID= Net-B [Net-A] ID-type= IPV4_ADDR_SUBNET Network= 10.10.10.0 Netmask= 255.255.255.0 [Net-B] ID-type= IPV4_ADDR_SUBNET Network= 10.10.99.0 Netmask= 255.255.255.0 [Default-main-mode] DOI= IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA [Default-quick-mode] EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-PFS-SUITE В приведенном примере в секции [General] параметр Listen-on указывает IP-адрес интерфейса, на котором isakmpd ожидает запросы на соединение. В секции [Phase 1], в которой задаются параметры SA для демона автоматического обмена криптографическими ключами, для удаленного участника с IP-адресом ххх.ххх.ххх.2 устанавливается имя ISAKMP-peer-B. В секции [Phase 2], в которой задаются параметры SA для IPsec, параметр Connections задает название IPSec-соединения (IPsec-A-B), которое должно быть «поднято» автоматически после запуска демона isakmpd. Далее следуют секции, раскрывающие использованые ранее значения (ISAKMP-peer-B и IPsec-A-B). Секция [ISAKMP-peer-B] вмещает ряд параметров, описывающих участника ISAKMP-peer-B, в частности: фазу соединения (Phase), во время которой используются эти параметры, локальный IP-адрес (Local-address), на котором осуществляется взаимодействие с участником для системы с несколькими адаптерами, IP-адрес (Address) участника, имя секции, содержащей параметры конфигурации (Configuration) для участника, Authentication – непосредственное значение PSK (т.е. пароль, для примера использовано значение great_password). Секция [IPsec-A-B] содержит подобные параметры, касающиеся IPsec-соединения с участником, за исключением параметров: ISAKMP-peer – указывает имя участника, с которым устанавливается соединение, Local-ID и Remote-ID – имена секций, описывающих значения, которые должны быть переданы участнику в качестве дополнительных локальных и удаленных параметров. В последующих секциях [Net-A] и [Net-В] перечислены, упомянутые выше дополнительные параметры, а именно параметры подсетей (возможно также описание единого IP4- или IP6-адреса), находящихся по разные стороны туннеля. Секция [Default-main-mode] задает конфигурационные параметры для организации процесса автоматического обмена криптографическими ключами с удаленным участником, а именно: DOI и EXCHANGE_TYPE – стандартные значения, Transforms – задает список предлагаемых крипторгафических преобразований для защиты трафика автоматизированного обмена ключевыми данными (алгоритм шифрования 3DES, алгоритм хеширования SHA). Секция [Default-quick-mode] устанавливает конфигурационные параметры IPsec: EXCHANGE_TYPE – стандартное значение, Suites – задает список протоколов и алгоритмов, используемых для защиты трафика (протокол ESP, алгоритм шифрования 3DES, алгоритм хеширования SHA, протокол согласования ключей PFS). Более детальную информацию о комбинациях протоколов и алгоритмов, которые можно использовать для защиты трафика и аутентификации можно почерпнуть на страничке руководства ISAKMPD.CONF(5). Конфигурационный файл /etc/isakmpd/isakmpd.conf маршрутизатора сети Б отличается от приведенного выше значениями, использованными в секциях, задающих параметры удаленного участника, IPsec-соединения: [General]Listen-on= ххх.ххх.ххх.2 [Phase 1] ххх.ххх.ххх.1= ISAKMP-peer-A [Phase 2] Connections= IPsec-B-A [ISAKMP-peer-A] Phase= 1 Local-address= ххх.ххх.ххх.2 Address= ххх.ххх.ххх.1 Configuration= Default-main-mode Authentication= great_password [IPsec-B-A] Phase= 2 ISAKMP-peer= ISAKMP-peer-A Configuration= Default-quick-mode Local-ID= Net-B Remote-ID= Net-A [Net-A] ID-type= IPV4_ADDR_SUBNET Network= 10.10.10.0 Netmask= 255.255.255.0 [Net-B] ID-type= IPV4_ADDR_SUBNET Network= 10.10.99.0 Netmask= 255.255.255.0 [Default-main-mode] DOI= IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA [Default-quick-mode] EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-PFS-SUITE Особое внимание необходимо обратить на параметр Authentication, который устанавливает значение пароля (PSK). Его значение должно быть одинаковым для обеих сторон. Для создания пароля можно воспользоваться утилитой dd аналогично случаю с генерацией ключевых файлов. Содержимое файла /etc/isakmpd/isakmpd.policy является одинаковым для обеих сторон: KeyNote-Version: 2Authorizer: "POLICY" Licensees: "passphrase:great_password" Conditions: app_domain == "IPsec policy" && esp_present == "yes" && esp_enc_alg != "null" -> "true"; Формат файла isakmpd.policy отличается от формата isakmpd.conf и содержит пары параметр/значение, при этом параметры могут иметь сложные значения. В приведенном выше примере параметры KeyNote-Version и Authorizer принимают стандартные значения (более подробно смотрите страницы руководства ISAKMPD.POLICY(5) и KEYNOTE(4,5)). Параметр Licensees устанавливает значение пароля, который является ключем к началу первой фазы (автоматический обмен ключевыми данными) установления VPN-соединения. Параметр Conditions содержит перечень требований к входящему IPsec-трафику. Требования простые: наличие протокола ESP и обязательное использование одного из алгоритмов криптографической защиты (более подробно см. ISAKMPD.POLICY(5)). С целью ограничения доступа необходимо выставить права с маской 600 на конфигурационные файлы isakmpd: #chmod 600 /etc/isakmpd/isakmpd* иначе запуск isakmpd завершится с ошибкой. Для «поднятия» VPN достаточно выполнить команду: #isakmpd -d Для автоматического «поднятия» VPN при загрузке системы в файле /etc/rc.conf.local для строки, начинающейся словом isakmpd, необходимо сменить значение флага на -d: isakmpd="-d" По сравнению с предыдущим данный способ является более надежным благодаря применению механизма автоматического обмена параметрами безопасности (SA, SPI). К числу его недостатков можно отнести использование общего ключа (PSK), который является узким местом механизма аутентификации сторон, а также наличие двух конфигурационных файлов и их более сложный синтаксис. Организация VPN с использованием IKE, демона isakmpd и механизма аутентификации на основе сертификатов стандарта X.509 Стандарт X.509 – является стандартом инфраструктуры открытого ключа (PKI, Public Key Infrastructure) и управления полномочиями (PMI, Privilege Management Infrastructure) международного института связи и телекоммуникации ITU-T. Стандарт X.509 определяет форматы сертификатов открытого ключа, механизмы отзыва сертификатов, атрибуты сертификатов и алгоритм проверки подлинности сертификата (принадлежности к определенной PKI). Для производства сертификатов используется четко определенная структура ответственных узлов или CA (Certificate Authorities). Возможны варианты организации как одно-, так и многоуровневой (иерархической) структуры СА. Как правило, на больших предприятиях, где широко применяется инфраструктура открытого ключа, используется структура СА, состоящая из нескольких уровней. В данном случае будет рассмотрена одноуровневая структура CA с одним узлом, обладающим полномочиями корневого СА и самоподписанным сертификатом. Для организации VPN с использованием сертификатов Х.509 согласно схеме (см. рисунок) необходимо выполнить следующие действия: 1. Активировать перенаправление пакетов на пограничных маршрутизаторах (см. выше). 2. Сформировать PKI (сгенерировать необходимые секретные ключи и сертификаты, произвести обмен сертификатами). 3. Сформировать конфигурационный файл /etc/isakmpd/isakmpd.conf. 4. Сформировать конфигурационный файл /etc/isakmpd/isakmpd.policy. 5. Добавить маршруты на удаленные подсети на пограничных маршрутизаторах (см. выше). Для создания PKI необходимо с помощью утилиты OpenSSL сгенерировать набор Х.509-сертификатов, которые обеспечат аутентификацию узлов-участников в рамках инфраструктуры. Сначала необходимо создать сертификат корневого СА, которым будут подписаны сертификаты участников, а его атрибуты – использованы для аутентификации. Для создания самоподписанного сертификата сроком действия 365 дней необходимо выполнить команду: #openssl req -x509 -days 365 -newkey rsa:1024 -keyout /etc/ssl/private/ca.key -out /etc/ssl/ca.crt В результате выполнения команды, на основании созданого секретного ключа /etc/ssl/private/ca.key длиной 1024 бита, дополнительно закрытого с помощью шифрования и пароля, будет создан самоподписанный сертификат /etc/ssl/ca.crt, действительный на протяжении 365 дней. В ходе формирования CSR-файла необходимо ответить на ряд стандартных вопросов. В качестве узла с полномочиями корневого СА для описанного случая может выступать любой доверенный хост, на котором установлен пакет OpenSSL. Следующим этапом является формирование секретных ключей и запросов на сертификацию для каждого участника (в данном случае маршрутизаторов сетей А и Б). Аналогично для маршрутизаторов сетей А и Б (с использованием в качестве имени IP-адресов xxx.xxx.xxx.1 и xxx.xxx.xxx.2 соответственно): $openssl req -new -newkey rsa:1024 -nodes -keyout xxx.xxx.xxx.1.key -out xxx.xxx.xxx.1.csr Особенностью формирования секретных ключей является то, что они не могут быть дополнительно защищены шифрованием (опция -nodes), такая защита повлечет отказ isakmpd во время запуска вследствие ошибки чтения содержимого ключа. Созданый ключ необходимо поместить в директорию /etc/isakmpd/private соответствующего хоста и установить на него права доступа по маске 600. Для правильной работы isakmpd необходимо, чтобы сертификаты, подписанные CA, содержали дополнительное поле subjectAltName, которое содержит IP-адрес или FQDN (Fully Qualified Domain Name) и позволяет isakmpd определить принадлежность сертификата: $export CERTIP=xxx.xxx.xxx.1 $openssl x509 -req -days 365 -in $CERTIP.csr -CA /etc/ssl/ca.crt -CAkey /etc/ssl/private/ca.key \ -CAcreateserial -extfile /etc/ssl/x509v3.cnf -extensions x509v3_IPAddr -out $CERTIP.crt В ходе выполнения команд на основании CSR-файла $CERTIP.csr (т.е. ххх.ххх.ххх.1.csr) будет создан сертификат $CERTIP.crt, включающий дополнительное поле subjectAltName, содержащее значение переменной $CERTIP (ххх.ххх.ххх.1), подписанный ключом ca.key (более подробно см. ISAKMPD(8)). Таким способом необходимо создать сертификаты для каждого участника (т.е. для маршрутизаторов сетей А и Б). После создания соответствующие сертификаты необходимо поместить в директории /etc/isakmpd/certs на каждом из маршрутизаторов. Также необходимо скопировать корневой сертификат ca.crt на каждый из маршрутизаторов и поместить в директорию /etc/isakmpd/ca. После этого необходимо сформировать конфигурационный файл /etc/isakmpd/isakmpd.conf. Рассмотрим его отличия от файла, созданного для случая использования PSK: [General]Listen-on= xxx.xxx.xxx.1 [X509-certificates] CA-directory= /etc/isakmpd/ca/ Cert-directory= /etc/isakmpd/certs/ Private-key= /etc/isakmpd/private/xxx.xxx.xxx.1.key [Phase 1] xxx.xxx.xxx.2= ISAKMP-peer-B [Phase 2] Connections= IPsec-A-B [ISAKMP-peer-B] Phase= 1 Local-address= xxx.xxx.xxx.1 Address= xxx.xxx.xxx.2 Configuration= Default-main-mode [IPsec-A-B] Phase= 2 ISAKMP-peer= ISAKMP-peer-B Configuration= Default-quick-mode Local-ID= Net-A Remote-ID= Net-B [Net-A] ID-type= IPV4_ADDR_SUBNET Network= 10.10.10.0 Netmask= 255.255.255.0 [Net-B] ID-type= IPV4_ADDR_SUBNET Network= 10.10.99.0 Netmask= 255.255.255.0 [Default-main-mode] DOI= IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA-RSA_SIG [3DES-SHA-RSA_SIG] ENCRYPTION_ALGORITHM= 3DES_CBC HASH_ALGORITHM= SHA AUTHENTICATION_METHOD= RSA_SIG [Default-quick-mode] EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-PFS-SUITE В отличие от конфигурационного файла маршрутизатора сети А, предназначенного для рассмотренного ранее случая, данный файл, также предназначенный для маршрутизатора сети А, содержит секцию [X509-certificates], задающую расположение директорий, содержащих СА-сертификат (CA-directory), сертификат(ы) пограничных маршрутизаторов (Cert-directory) и файл, содержащий секретный ключ (Private-key). Из секции [ISAKMP-peer-A] за ненадобностью удалена строка, содержащая параметр Authentication. В секции [3DES-SHA-RSA_SIG] дано подробное описание предлагаемых криптографических преобразований для защиты трафика автоматизированного обмена ключевыми данными (алгоритма шифрования, алгоритма хеширования и метода аутентификации). Аналогичные изменения необходимо внести и в конфигурационный файл маршрутизатора сети Б. Конфигурационный файл маршрутизатора сети Б: [General]Listen-on= ххх.ххх.ххх.2 [X509-certificates] CA-directory= /etc/isakmpd/ca/ Cert-directory= /etc/isakmpd/certs/ Private-key= /etc/isakmpd/private/ххх.ххх.ххх.2.key [Phase 1] ххх.ххх.ххх.1= ISAKMP-peer-A [Phase 2] Connections= IPsec-B-A [ISAKMP-peer-A] Phase= 1 Local-address= ххх.ххх.ххх.2 Address= ххх.ххх.ххх.1 Configuration= Default-main-mode [IPsec-B-A] Phase= 2 ISAKMP-peer= ISAKMP-peer-A Configuration= Default-quick-mode Local-ID= Net-B Remote-ID= Net-A [Net-A] ID-type= IPV4_ADDR_SUBNET Network= 10.10.10.0 Netmask= 255.255.255.0 [Net-B] ID-type= IPV4_ADDR_SUBNET Network= 10.10.99.0 Netmask= 255.255.255.0 [Default-main-mode] DOI= IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA-RSA_SIG [3DES-SHA-RSA_SIG] ENCRYPTION_ALGORITHM= 3DES_CBC HASH_ALGORITHM= SHA AUTHENTICATION_METHOD= RSA_SIG [Default-quick-mode] EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-PFS-SUITE В содержимое файла isakmpd.policy также необходимо внести изменения с целью обеспечения аутентификации только тех участников, чьи сертификаты подписаны «местным» корневым CA. Для этого в качестве значения параметра Licensees необходимо использовать содержимое аттрибута subject сертификата корневого СА (/etc/isakmpd/ca/ca.crt). Для получения содержимого можно воспользоваться следующей командой: $openssl x509 -in /etc/isakmpd/ca/ca.crt -noout -subject
subject=/C=RU/ST=MW/L=MOSCOW/O=SMPL/OU=IT DEPT/CN=RootCA/emailAddress=admin@pki.lan Как и в предыдущем случае, содержимое файла isakmpd.policy идентично для обоих маршрутизаторов: KeyNote-Version: 2Authorizer: "POLICY" Licensees:"DN:/C=RU/ST=MW/L=MOSCOW/O=SMPL/OU=IT DEPT/CN=RootCA/emailAddress=admin@pki.lan" Conditions: app_domain == "IPsec policy" && esp_present == "yes" && esp_enc_alg != "null" -> "true"; Параметры, использованные в данном случае, аналогичны параметрам в случае с PSK. Элемент DN (Distinguished Name), используемый при установке значения параметра Licensees, является обязательным, так как указывает на тип выражения, следующего за ним (passphrase в случае с PSK). Дальнейшая настройка автозапуска аналогична случаю с PSK, а методика тестирования – методике, предложенной для всех описанных выше случаев. Благодаря применению механизма аутентификации на основе стандарта Х.509 данный способ организации VPN является наиболее безопасным из числа перечисленных. К его преимуществам можно отнести использование централизованного механизма создания временных сертификатов. Как и предыдущие, данный способ также не лишен недостатков, среди них: сложность конфигурационных файлов, необходимость выделения административных ресурсов на поддержание PKI, уязвимость системы в случае компроментации ответственного узла (СА). Заключение В статье были рассмотрены три способа организации VPN на основе набора протоколов IPsec согласно предложеной схеме (см. рисунок) с помощью встроенного инструментария, предоставляемого OpenBSD. Предложенная схема не охватывает все разнообразие возможных ситуаций, однако является типичной схемой одного из сегментов сложной VPN многофилиальной организации. Следует также отметить, что в качестве ОС на сетевых узлах, обеспечивающих «поднятие» VPN с помощью ПО isakmpd, может быть использована любая ОС, для которой данное ПО портировано разработчиками. В статье не были затронуты вопросы настройки сетевых (пакетных) фильтров на пограничных маршрутизаторах. Несмотря на это, необходимо учитывать, что правильная конфигурация пакетного фильтра является важным аспектом при рассмотрении вопросов сетевой безопасности. Каждый из описаных выше способов имеет свои преимущества и недостатки, однако, поскольку уровень безопасности соединений «точка-точка», каковыми являются VPN-туннели, определяется не только длиной используемых криптографических ключей, но и свойствами самой структуры криптозащиты, то неоспоримыми преимуществами для многофилиальной бизнес-структуры или организации становятся повышенная по сравнению с PSK криптостойкость, а также наличие централизованного механизма управления средствами криптографической защиты каналов передачи данных, связывающих территориально разграниченные подсети. И в этом отношении преимущества способа с использованием инфраструктуры открытого ключа очевидны.
|
Максим Гришков
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
