Краткое введение в технологию IPSec (GRE, L2TP) с примерами применения.

1. IPSec Introduction
Введение в IPSec
Володимир Літовка (doka.ua@gmail.com)
Этот документ доступен по лицензии Creative Commons
“Attribution 4.0 International” (CC-BY 4.0)
Вы можете свободно копировать и распространять этот материал в любом виде и
формате, а также переделывать его и брать в качестве основы для любых (в том
числе коммерческих) целей при условии указания авторства и переченя изменений в
авторский материал.
(https://creativecommons.org/licenses/by/4.0/deed.uk)
При написании данного материала использовались фрагменты из материала Steve
Friedl “An Illustrated Guide to IPSec” (http://www.unixwiz.net/techtips/iguide-ipsec.html)
CC-BY-4.0 p.61

2. IPSec Introduction
Содержание
IPSec для защиты передаваемой информации 3.................................................
Authentication Header (АН) 3...................................................................................................................
Encapsulating Security Payload (ESP) 4....................................................................................................
Internet Security Association and Key Management Protocol (ISAKMP) 5.............................................
Описания протоколов и рекомендации по применению 10..................................................................
Конфигурация и работа IPSec 12............................................................................
Конфигурация ISAKMP Phase 1 13.........................................................................................................
Конфигурация ISAKMP Phase 2 (шифрование данных) 14..................................................................
Организация связи с использованием GRE 17.....................................................
Совместное использование GRE и IPSec 19..........................................................................................
Организация связи с использованием L2TP 20....................................................
Совместное использование L2TP и IPSec 23.........................................................................................
Дополнительные рекомендации по увеличению стойкости IPSec 27.............
Perfect Forward Secrecy 27........................................................................................................................
Traffic Flow Confidentiality 28..................................................................................................................
Заключение 30............................................................................................................
CC-BY-4.0 p.62

3. IPSec Introduction
IPSec для защиты передаваемой информации
Изначально, стандарты протокола TCP/IP не были предназначены для защиты IP-
пакетов, поэтому их можно легко интерпретировать, изменять и воспроизводить, что
делает как общественные, так и частные сети уязвимыми для несанкционированного
наблюдения и доступа.
Для защиты IP трафика была разработана инфраструктура Internet Protocol Security
(IPSec). Она представляет собой систему открытых стандартов, обеспечивающую
защиту сетей, используя для этого криптографические протоколы безопасности и
динамическое управление ключами. Основными функциями IPSec являются:
• обеспечение конфиденциальности. Отправитель должен иметь возможность
шифровать пакеты перед тем, как передавать их по сети.
• Обеспечение целостности. Получатель должен быть уверенным в том, что
передаваемые данные не были изменены в пути и иметь возможность
аутентифицировать стороны, участвующие в процессе обмена информацией.
• Обеспечение защиты от воспроизведения пакетов. Получатель должен иметь
возможность обнаруживать и отбрасывать воспроизведенные пакеты, исключая
таким образом проведение атак внедрения посредника.
Реализация IPsec располагается на уровне IP. Это делает IPsec настолько гибким, что он
может использоваться для защиты любых протоколов, базирующихся на IP. В то же
время, он прозрачен для большинства приложений.
Ядро IPSec составляют три протокола: AH, ESP, ISAKMP.
Authentication Header (АН)
Обеспечивает целостность виртуального соединения (передаваемых данных),
аутентификацию источника информации и функцию по предотвращению повторной
передачи пакетов. Формат заголовка AH следующий:
6
Рассмотрим важные поля этого заголовка:
• Next Header – тип пакета, защищаемого протоколом AH (например, TCP);
• Security Parameter Index (SPI) – указатель на набор параметров безопасности.
Значение этого поля вместе с IP-адресом получателя и используемым в AH
протоколом безопасности однозначно определяет защищённое виртуальное
соединение (SA) для данного пакета.
CC-BY-4.0 p.63

4. IPSec Introduction
• Sequence Number – порядковый номер, служит для защиты от повторной
передачи пакета.
• Authentication Data – цифровая подпись пакета. Служит для аутентификации и
проверки целостности пакета. Для вычисления этого параметра используется
алгоритм хеширования, который гарантирует уникальный результат для каждого
отличающегося набора входных данных и невозможность восстановления
исходных данных по результату.
Encapsulating Security Payload (ESP)
Обеспечивает конфиденциальность (шифрование) передаваемой информации (включая
скрытие характера данных с целью усложнения статистического и/или поведенческого
анализа перехваченных данных). Кроме этого, он может выполнять функции AH,
обеспечивая целостность передаваемых данных, аутентификацию источника
информации и функцию по предотвращению повторной передачи пакетов. При
применении ESP в обязательном порядке должен указываться набор услуг по
обеспечению безопасности: каждая из его функций может включаться по
необходимости.
Формат пакета ESP следующий:
6
Поля SPI, Sequence Number, Next Header и Authentication Data означают то же самое,
что и в заголовке AH.
Encrypted Payload – собственно зашифрованные данные. Данные шифруются с
помощью алгоритмов с симметричным ключом. Тип этих данных идентифицируется
заголовком Next Header (который скрыт в зашифрованной части и используется для
восстановления оригинального пакета только после расшифровки).
Выравнивание пакета по определенному размеру необходимо для алгоритмов, которые
требуют, чтобы блока данных был кратен некоторому числу байтов, например, размеру
блока для блочного шифра.
Цифровая подпись является необязательным атрибутом пакета и присутствует только
если ESP используется для выполнения функций AH (аутентификация, целостность).
CC-BY-4.0 p.64

5. IPSec Introduction
Internet Security Association and Key Management Protocol (ISAKMP)
ISAKMP — протокол, используемый для первичной настройки соединения, взаимной
аутентификации конечными узлами друг друга и обмена секретными ключами.
Протокол предусматривает использование различных механизмов обмена ключами:
Internet Key Exchange (IKE), Kerberized Internet Negotiation of Keys или IPSECKEY в
записях DNS. Поскольку IKE – наиболее распространенный механизм, далее будем
говорить только о нём. Для скрытия обмена между участниками IKE используются
алгоритмы с открытым ключом или алгоритмы эллиптических кривых.
Также, одним из ключевых понятий является Security Association (SA). По сути, SA
является набором параметров, характеризующим защищенное соединение
(используемые алгоритм шифрования и хэш-функция, секретные ключи, номер пакета,
время жизни SA и другие). Каждая SA используется для передачи данных только в
одном направлении, для двунаправленной связи их требуется две. Это означает, что,
например, данные от хоста H1 в сторону хоста H2 могут защищаться одним набором
параметров, а в обратном направлении – другим набором, хотя такой режим является,
скорее, исключением из правил.
Применение IPSec возможно на разных сегментах сети: как между конечными хостами
(компьютерами), так и для защиты данных только в открытых сегментах (например,
между шлюзами локальных сетей с открытыми сетями – в таком случае данные внутри
локальной сети пересылаются в открытом виде, а защищаются шлюзом на выходе в
открытую сеть).
В работе протоколов IPsec можно выделить четыре этапа:
1. Первый этап (инициализация) начинается с создания на каждом узле,
поддерживающим стандарт IPsec, политики безопасности. На этом этапе
определяется, какой трафик подлежит шифрованию, какие функции и
алгоритмы могут быть использованы.
2. Целью второго этапа является организация SA с помощью протокола IKE. В
зависимости от используемой версии IKE, этот этап может проходить в одну или
в две фазы:
a. первая версия IKE (v1) использует две фазы обмена сообщениями: в
первой происходит создание так называемой IKE SA для защищенного
обмена данными во второй фазе, которая отвечает за согласование
параметров и создание основной SA (IPSec SA).
b. Вторая версия IKE (v2) является улучшенной версией IKEv1, в которой
реализована только одна фаза, а также уменьшено количество, увеличена
устойчивость и защищенность обмена сообщениями. Использование
IKEv2 является более предпочтительным, чем IKEv1.
3. Рабочий этап. После создания IPSec SA начинается обмен информацией между
узлами через соединение IPsec, используются протоколы и параметры,
установленные в IPSec SA.
CC-BY-4.0 p.65

6. IPSec Introduction
4. Прекращание действия текущей IPSec SA . Это происходит при её удалении или
при истечении времени жизни (указывается либо в объеме переданной через SA
информации, либо в секундах). Если требуется продолжить передачу, то вновь
запускается IKE (полностью или частично) и создается новая IPSec SA. Процесс
создания новых IPSec SA может происходить и до завершения действия
текущих, если требуется непрерывная передача данных.
IPsec может функционировать в двух режимах – транспортном и туннельном.
В транспортном режиме:
• протокол AH вставлет свой заголовок между заголовком и полем данных IP-
пакета, вычисляет хэш всех неизменяемых полей получившегося пакета и
использует полученный результат в качестве цифровой подписи:
6
CC-BY-4.0 p.66

7. IPSec Introduction
• протокол ESP шифрует только поле данных IP-пакета и, если выполняет
функции AH, подписывает зашифрованный блок и собственный заголовок:
6
Транспортный режим ESP требует меньше вычислительных ресурсов, но, в
случае перехвата данных, позволяет злоумышленнику получить представление о
структуре защищаемой сети, адресации внутри неё и роли хостов (не видя при
этом передаваемых данных), поскольку не скрывает IP-адреса в обмене
данными.
CC-BY-4.0 p.67

8. IPSec Introduction
В туннельном режиме:
• протокол AH формирует новый IP-пакет, добавляет в него свой заголовок и
переносит оригинальный IP-пакет (в неизменном виде, со всеми заголовками) в
поле данных. Затем вычисляет хэш всех неизменяемых полей созданного пакета
и использует полученный результат в качестве цифровой подписи:
6
CC-BY-4.0 p.68

9. IPSec Introduction
• протокол ESP формирует новый IP-пакет, добавляя в него свой заголовок и
помещая оригинальный IP-пакет (в зашифрованном виде) в поле данных. Если
ESP выполняет фунцкию AH, то дополнительно он подписывает
зашифрованный блок и собственный заголовок:
6
Туннельный режим ESP обеспечивает наиболее высокий уровень защиты данных от
всех несанкционированных воздействий и чаще всего используется для подключения
удалённых хостов (компьютеров) к закрытой сети или для организации безопасной
передачи данных через открытые каналы связи (например, Интернет) между шлюзами
для объединения разных частей закрытой сети.
Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые
SA могут использовать транспортный режим, а другие — туннельный.
Как видно из сказанного выше, протокол AH может быть использован в случае, если
сами по себе передаваемые данные не представляют секрета, но чрезвычайно важно
быть уверенным в том, что они получены именно с того источника, с которого
ожидаются и не были изменены в процессе передачи (например, разного рода
телеметрия). Во всех остальных случаях требуется применение ESP, как
обеспечивающего более высокую степень защиты. Несмотря на то, что механизм
цифровой подписи формально не является обязательным для ESP, настоятельно
рекомендуется его включать, поскольку без него ESP подвержен атакам и взломам.
CC-BY-4.0 p.69

10. IPSec Introduction
Описания протоколов и рекомендации по применению
Протоколы IPsec (ESP, AH, IKE) разработаны таким образом, что не зависят от
алгоритмов и предусматривает возможность использования сторонами нескольких
алгоритмов и параметров аутентификации и шифрования, а также различных схем
распределения ключей.
Криптографические алгоритмы, в целом, можно разделить на четыре категории.
• Алгоритмы с симметричным ключом используют одинаковый ключ для
шифрации и дешифрации. Примерами таких алгоритмов являются DES (Data
Encryption Standart), 3DES, AES (Advanced Encryption Standart).
• Алгоритмы с открытым ключом используют различные ключи для шифрации
и дешифрации. Эти ключи называются закрытым (private, он доступен только
владельцу) и открытым ключом (public key, доступен публично). Они
генерируются одновременно и связаны между собой. Тем не менее, из закрытого
ключа невозможно получить открытый и информацию, зашифрованную
открытым ключом, можно расшифровать только соответствующим закрытым
ключом. Примерами таких алгоритмов являются RSA (сокр. от Rivest, Shamir,
Adleman – фамилий разработчиков), DSA (Digital Signature Algorythm), DH
(Diffie-Hellman, фамилии разработчиков).
• Алгоритмы эллиптических кривых (Elliptic Curves) являются относительно
новой альтернативой классическим алгоритмам открытого ключа. Основным
преимуществом алгоритмов эллиптических кривых является их эффективность
и более высокая производительность. Примерами таких алгоритмов являются
ECDH и ECDSA.
• Алгоритмы хеширования (hashing, также известен как digital fingerprinting)
предназначены для получения уникального значения фиксированной длины
(hash, хеш) для каждого отличающегося набора входных данных и
невозможность восстановления исходных данных по полученному значению.
Примерами таких алгоритмов являются MD5 (Message Digest), SHA (Secure
Hash Algorythm).
Механизм HMAC (Hashed Message Authentication Code) не является алгоритмом
хеширования. Это механизм, который применяется для проверки целостности
данных и использует комбинацию секретного ключа и хеша (MD5 или SHA).
Приведенная таблица является рекомендацией по использованию алгоритмов в работе:
Алгоритм Функция Статус Альтернатива QCR(*) Рекомендации
DES Шифрация Избегать AES - -
3DES Шифрация Устаревший AES - короткое время
жизни ключа
RC4 Шифрация Избегать AES - -
AES-CBC Шифрация Допустим AES-GCM +
(256 bit)
-
AES-GCM Шифрация +
аутентификация
NGE(**) - +
(256 bit)
-
CC-BY-4.0 p.610

11. IPSec Introduction
Помимо озвученных выше рекомендаций, добавим еще одну. Современные методики
взлома IPSec в основном используют уязвимости в IKE, потому при настройке IKE
пользуйтесь следующими рекомендациями:
• если возможно, используйте ECDH-256 (DH Group 19) и ECDH-384 (DH Group
20) для обмена ключами;
• никогда не используйте ключи длиной до 2048 бит (DH Groups 1, 2, 5);
• используйте IKEv2 c AES-256 для организации SA.
Применение IPSec в государственных службах Украины разрешено и основано на
положительном экспертном заключении Администрации Государственной службы
специальной связи и защиты информации Украины. В соответствии с ним,
“симметричный блочный шифр AES (AES-128, AES-192, AES-256) является
рекомендуемым и может быть использован в средствах криптографической защиты
информации для защиты информации с ограниченным доступом (кроме служебной
DH-768, -1024
RSA-768, -1024
DSA-768, -1024
Обмен ключами
Шифрация
Аутентификация
Избегать DH-3072 (Group
15)
RSA-3072
DSA-3072
-
-
-
-
-
-
DH-2048
RSA-2048
DSA-2048
Обмен ключами
Шифрация
Аутентификация
Допустим ECDH-256
-
ECDSA-256
-
-
-
-
-
-
DH-3072
RSA-3072
DSA-3072
Обмен ключами
Шифрация
Аутентификация
Допустим ECDH-256
-
ECDSA-256
-
-
-
-
-
-
MD5 Ц е л о с т н о с т ь
(хеш)
Избегать SHA-256 - -
SHA-1 Целостность Устаревший SHA-256 - -
SHA-256
SHA-384
SHA-512
Целостность NGE SHA-384
-
-
-
+
+
-
-
-
HMAC-MD5 Целостность Избегать HMAC-SHA-256 - короткое время
жизни ключа
HMAC-SHA-1 Целостность Допустим HMAC-SHA-256 - -
H M A C -
SHA-256
Целостность NGE - + -
ECDH-256
ECDSA-256
Обмен ключами
Аутентификация
Допустим ECDH-384
ECDSA-384
-
-
-
-
ECDH-384
ECDSA-384
Обмен ключами
Аутентификация
NGE -
-
-
-
-
-
(*) QCR – устойчив к квантовым вычислениям
(**) NGE – Next Generation Encryption Algorythms (алгоритмы шифрования нового поколения),
ожидается, что они будут устойчивы ко взлому в ближайшие 15-20 лет
Алгоритм Функция Статус Альтернатива QCR(*) Рекомендации
CC-BY-4.0 p.611

12. IPSec Introduction
информации и информации, являющейся государственной тайной) и открытой
информации, требование по защите которой установлено законом.”
Конфигурация и работа IPSec
Для понимания работы IPSec, рассмотрим пример организации шифрованой передачи
данных между двумя узлами, подключенными к сети Интернет. Сетевая топология
приведена на схеме:
6
В этом примере узел №2 использует сеть Интернет только для организации
шифрованного канала связи к узлу №1. Фактически, узел №2 использует
маршрутизатор R1 как для доступа к сервисам Интернет, так и для доступа к локальной
сети узла №1.
Конфигурация состоит из двух частей: настройка параметров ISAKMP Phase 1
(установление Security Association – SA) и настройка параметров шифрования данных
– ISAKMP Phase 2 (включая определение данных, подлежащих шифрованию).
Этот материал строится на примерах конфигураций. В качестве платформы
для примеров выбраны маршрутизаторы производства компании Cisco
Systems под управлением операционной системы Cisco IOS (Internetwork
Operating System). Для настройки устройств других производителей следует
обратиться к соответствующей документации. Также, приведенные примеры
содержат только команды, относящиеся непосредственно к рассматриваемому
примеру и не затрагивают остальные параметры работы маршрутизатора
(например, настройку NAT или правил маршрутизации).
6
CC-BY-4.0 p.612

13. IPSec Introduction
Конфигурация ISAKMP Phase 1
В примере ниже определяется конфигурация параметров для ISAKMP Phase 1:
Приведенные выше команды определяют следующие параметры:
• encryption: метод шифрования, используемый в первой фазе ISAKMP.
• hash: алгоритм хеширования (аутентификации, цифровой подписи) сообщений в
первой фазе ISAKMP.
• authentication: метод аутентификации узлов IPSec, участвующих в
формировании SA. В данном примере указано использование общего ключа
(Pre-shared key).
• group: идентификатор группы Диффи-Хеллмана (Diffie-Hellman (DF) group),
который два узла IPsec используют для получения общего ключа, не передавая
его друг другу. Номер группы определяет устойчивость ключа – чем выше
номер, тем устойчивее ключ:
o DH group 1: 768 bit
Во всех приведенных ниже примерах красным цветом выделены значения,
которые необходимо изменить в соответствии с конкретными требованиями
решаемой задачи и рекомендациями по выбору алгоритмов, которые
доступны в материале предыдущего номера.
Во всех приведенных ниже примерах используется механизм общего ключа
(pre-shared key). Он считается надёжным, поскольку ключ никогда и ни в
каком виде не передается через каналы связи. Тем не менее, для установления
защищённого соединения также может использоваться механизм цифровых
сертификатов. Он сложнее в реализации, но легче управляется и
масштабируется и позволяет быстрее реагировать на риски, связанные с
утечкой информации, поэтому рекомендуется более, чем механизм общего
ключа. Целью данного материала является рассказ о методах построения
VPN, поэтому мы не будем в ней рассматривать механизм использования
цифровых сертификатов.
Во всех приведенных ниже примерах все общие ключи хранятся в
конфигурации в открытом виде и, в случае утечки конфигурационного файла,
будут доступны третьим сторонам. Для увеличения безопасности,
обязательно следуйте инструкциям из следующего документа (англ.) – http://
tinyurl.com/z5gu9xp , но следует помнить, что это всё равно не даёт никаких
гарантий безопасности при наличии физического доступа к устройству.
6
R1# config terminal
R1(config)# crypto isakmp policy 10
R1(config-isakmp)# encryption 3des
R1(config-isakmp)# hash md5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2
R1(config-isakmp)# lifetime 86400
CC-BY-4.0 p.613

14. IPSec Introduction
o DH group 2: 1024 bit
o DH-group 5: 1536 bit
o DH Group 14: 2048 bit
o DH Group 15: 3072 bit
o DH Group 19: 256 bit (алгоритм Elliptic Curve)
o DH Group 20: 384 bit (алгоритм Elliptic Curve)
o DH Group 21: 512 bit (алгоритм Elliptic Curve)
o DH Group 24: 2048 bit, 256 bit subgroup
• lifetime: длительность жизни SA в секундах (вообще говоря, может быть указана
также и в килобайтах, но, по странной прихоти разработчиков, в Cisco IOS это
указывается в другой части конфигурации – см. далее). При превышении
заданного параметра происходит переключение на новую SA. Узлы IPSec
создают новую SA до достижения порогового значения lifetime, чтобы к
моменту исчерпания lifetime новая SA уже была готова к использованию. По
умолчанию, длительность жизни составляет либо 8 часов, либо 10 мегабайт.
Общий ключ определяется следующей командой:
Обратите внимание, что секция crypto isakmp policy может содержать несколько групп
параметров, описываемых под разными порядковыми номерами (в примере выше –
используется только группа с номером 10) и является общей для всех SA данного узла.
Когда узел начинает установление SA с удалённым узлом (в нашем примере – R1 с R2),
он информирует удалённый узел обо всех описанных группах (в отсортированном по
номеру порядке). Для установления SA используется первая совпавшая группа
параметров. Группа совпадает, если в ней совпадают параметры encryption, hash,
authentication и group и если значение lifetime на удаленном узле (R2) равно или
меньше значения lifetime на узле, который инициирует соединение (R1).
Конфигурация ISAKMP Phase 2 (шифрование данных)
Для настройки шифрования данных необходимо определить: подлежащие
шифрованию данные, параметры шифрования, адрес удалённого узла IPSec и указать
исходящий интерфейс, на котором будет происходить шифрование.
Подлежащие шифрованию данные определяется с помощью списка доступа (Access
Control List – ACL), например:
который будет идентифицировать данные, направляющиеся из сети 10.10.10.0/24 в сеть
20.20.20.0/24. Для того, чтобы ISAKMP Phase 2 установила SA, список доступа на
удаленной стороне должен быть зеркальным и, для нашего примера, описывать
данные, направляющиеся из сети 20.20.20.0/24 в сеть 10.10.10.0/24.
R1(config)# crypto isakmp key mykey address 2.2.2.2
R1(config)# ip access-list extended TO_ENCRYPT
R1(config-ext-nacl)# permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
CC-BY-4.0 p.614

15. IPSec Introduction
Параметры шифрования (которые согласовываются узлами во второй фазе ISAKMP)
определяются следующей командой:
где myTS – название списка параметров, esp-3des – метод шифрования и esp-md5-
hmac – алгоритм хеширования (аутентификации) сообщений.
Защищённое соединение между узлами будет установлено только в том случае, если
параметры шифрования и аутентификации будут совпадать на обоих узлах.
Теперь необходимо собрать вместе все описанные параметры шифрования данных и
применить их на исходящем интерфейсе:
Описанный набор команд сообщает маршрутизатору о необходимости установить SA с
узлом 2.2.2.2 (в нашем примере это – R2) и, впоследствии, любые данные, (а)
обнаруженные на выходе интерфейса FastEthernet 0/1 и (б) идентифицируемые списком
доступа TO_ENCRYPT, шифровать с использованием параметров, описанных в списке
myTS и отправлять через ранее созданную SA на узел 2.2.2.2.
Как и в случае с секцией crypto isakmp policy, секция crypto map тоже может
содержать несколько групп параметров, описываемых под разными порядковыми
номерами (в примере выше – используется только группа с номером 15). В случае, если
в одной такой секции указано несколько групп, то для шифрования данных будет
использована группа с соответствующим списком доступа.
Если идентификаторы данных не соответствуют ни одному из описанных списков
доступа, они не будут шифроваться и передаваться на удалённый узел. Их обработка
будет происходить в соответствии с другими правилам на данном маршрутизаторе (в
соответствии с правилами маршрутизации, если не настроено никаких других). В
нашем примере, список доступа TO_ENCRYPT идентифицирует только данные,
исходящие из сети 10.10.10.0/24, поэтому если в локальной сети узла №1 настроить
дополнительную сеть, например, с адресом 10.11.0.0/24, то данные с устройств из этой
сети не попадут в зашифрованный туннель.
В рассматриваемом нами примере, конфигурация на узле R2 будет идентичной за
исключением списка доступа (поскольку данные движутся в обратном направлении,
Маршрутизаторы под управлением Cisco IOS не позволяют использовать
ключевое слово “any” в списках доступа для шифрования. Запись permit ip
any 20.20.20.0 0.0.0.255 и, зеркальная на удаленной стороне, permit ip any
10.10.10.0 0.0.0.255 не даст желаемого результата. Сети источников и
назначений необходимо указывать в явном виде.
6
R1(config)# crypto ipsec transform-set myTS esp-3des esp-sha-hmac
R1(config)# crypto map myCryptoMap 15 ipsec-isakmp
R1(config-crypto-map)# set peer 2.2.2.2
R1(config-crypto-map)# set transform-set myTS
R1(config-crypto-map)# set security-association lifetime kilobytes
102400
R1(config-crypto-map)# match address TO_ENCRYPT
R1(config-crypto-map)# exit
R1(config)# interface FastEthernet0/1
R1(config- if)# crypto map myCryptoMap
CC-BY-4.0 p.615

16. IPSec Introduction
адреса источников и назначения данных необходимо поменять местами) и адресов
удалённого конца соединения (вместо адреса R2 должен быть указан адрес R1):
Проверить установление соединений и идентифицировать проблемы можно с
помощью следующих команд:
• show crypto ipsec sa – показывает параметры установленных SA
• show crypto isakmp sa – показывает параметры установленных ISAKMP SA
• debug crypto isakmp – показывает в деталях в реальном режиме времени работу
ISAKMP Phase 1
• debug crypto ipsec – показывает в деталях в реальном режиме времени работу
ISAKMP Phase 2
Как видно из данного примера, инфраструктура IPSec может обеспечивать как
выборочное, так и полное шифрование данных (в соответствии со списками доступа)
на исходящем интерфейсе маршрутизатора. Внешне это выглядит, как
непосредственное соединение между узлами (R1---R2), независимо от количества
промежуточных маршрутизаторов в сети Интернет (как будто их нет вообще).
Есть, однако, два нюанса. Во-первых, поскольку выбор данных для шифрования
определяется списком доступа, то любое изменение в адресации локальной сети
(добавление новых адресов, изменение существующих адресов) требует обновления
списков доступа и если этого не сделать (или ошибиться при изменении
конфигурации), то налаженный механизм разрушится. В целях надежности было бы
удобнее уйти от списков доступа, безусловно шифруя все данные между узлами.
Во-вторых, некоторые механизмы, расширяющие функциональность IP-сети
(например, Multiprotocol Label Switching (MPLS), многоадресные рассылки (Multicast)
или протоколы динамической маршрутизации, например, OSPF), требуют не только
непосредственного соединения между маршрутизаторами, но также и отдельного
интерфейса, обслуживающего это соединение.
В рассмотренном выше примере такие интерфейсы не создаются – шифрование
трафика происходит на интерфейсах FastEthernet0/1 маршрутизаторов R1 и R2, которые
подключены не друг к другу, а к сетевым интерфейсам провайдеров доступа к сети
Интернет. В такой конфигурации добавить, например, динамическую маршрутизацию
между узлами невозможно.
Для решения этих проблем могут быть использованы механизмы туннелирования
Generic Routing Encapsulation (GRE) или Layer 2 Tunneling Protocol (L2TP) совместно с
шифрованием IPSec.
crypto isakmp key mykey address 1.1.1.1
crypto map myCryptoMap 15 ipsec-isakmp
set peer 1.1.1.1
[ … ]
ip access-list extended TO_ENCRYPT
permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
CC-BY-4.0 p.616

17. IPSec Introduction
Организация связи с использованием GRE
GRE (Generic Routing Encapsulation) - протокол туннелирования сетевых пакетов,
разработанный компанией Cisco Systems и впоследстии стандартизованный в RFC2784.
GRE выполняет инкапсуляцию IP-пакетов (шире – пакетов сетевого уровня сетевой
модели OSI) в другие IP-пакеты (внешние) и пересылает их на удалённый
маршрутизатор, где происходит декапсуляция и дальнейшая обработка оригинального
пакета в соответствии с локальными правилами.
Для понимания работы туннелирования с помощью GRE рассмотрим пример
организации туннеля между двумя узлами, подключенными к сети Интернет.
Конфигурация R1:
Конфигурация R2:
R1(config)# interface FastEthernet 0/0
R1(config-if)# ip address 10.10.10.1 255.255.255.0
R1(config)# interface FastEthernet 0/1
R1(config-if)# ip address 1.1.1.1 255.255.255.0
R1(config)# interface Tunnel1
R1(config-if)# ip address 3.3.3.1 255.255.255.252
R1(config-if)# tunnel source 1.1.1.1
R1(config-if)# tunnel destination 2.2.2.2
R1(config-if)# ^Z
R1(config)# ip route 20.20.20.0 255.255.255.0 3.3.3.2
R2(config)# interface FastEthernet 0/0
R2(config-if)# ip address 20.20.20.1 255.255.255.0
R2(config)# interface FastEthernet 0/1
R2(config-if)# ip address 2.2.2.2 255.255.255.0
R2(config)# interface Tunnel1
R2(config-if)# ip address 3.3.3.2 255.255.255.252
R2(config-if)# tunnel source 2.2.2.2
R2(config-if)# tunnel destination 1.1.1.1
R2(config-if)# ^Z
R2(config)# ip route 10.10.10.0 255.255.255.0 3.3.3.1
CC-BY-4.0 p.617

18. IPSec Introduction
Топология сети и формат пакета в такой конфигурации выглядит следующим образом:
6
Из локальной сети узла №1 на маршрутизатор R1 поступает пакет с адресом источника
(И) 10.10.10.2 и адресом назначения (Н) 20.20.20.3. На маршрутизаторе настроен
туннельный интерфейс Tunnel1, который формирует новый пакет – с адресом
источника 1.1.1.1 и адресом назначения 2.2.2.2, помещая оригинальный пакет
(полностью) в тело нового пакета. В соответствии с правилами маршрутизации, новый
пакет пересылается через сеть Интернет и попадает на маршрутизатор R2.
Настроенный на нём туннельный интерфейс снимает внешний заголовок и получает
оригинальный пакет с адресом источника (И) 10.10.10.2 и адресом назначения (Н)
20.20.20.3. В соответствии с локальными правилами маршрутизации, оригинальный
пакет пересылается в локальную сеть узла №2 через интерфейс FastEthernet0/0 и
попадает на хост назначения.
Как видно из приведенного выше примера, данная конфигурация решает проблему
отсутствия отдельного интерфейса из примера с IPSec – интерфейсы Tunnel1 на
маршрутизаторах R1 и R2 дают возможность использовать расширенные механизмы
IP-сетей (динамическая маршрутизация и прочие).
В этой конфигурации, однако, тоже есть один нюанс. Инкапсуляция пакетов в пакетах
не скрывает передаваемые данные и не защищает их от модификации – то есть, не
выполняет функций IPSec. Поэтому, если в этом есть необходимость, инкапсуляцию
Механизм GRE не поддерживает передачу состояния, поэтому, если по каким-
то причинам удаленная сторона туннеля недоступна, интерфейс не изменит
своего состояния (иными словами, он всегда остается в активном режиме) и в
таком случае передаваемые туда данные будут теряться без уведомления. При
проектировании сети на основе GRE необходимо учитывать этот факт и
наилучшим решением является использование протоколов динамической
маршрутизации для управления передачей данных на удалённый узел через
туннельный интерфейс.
6
CC-BY-4.0 p.618

19. IPSec Introduction
GRE можно использовать совместно с IPSec, что решает обе проблемы – и защиту
данных, и организацию отдельных интерфейсов для расширения функциональности.
Совместное использование GRE и IPSec
В данном примере показана конфигурация маршрутизатора R1, которая реализует
передачу GRE внутри зашифрованного туннеля IPSec:
Отличия в этой конфигурации от примера с IPSec состоит в отсутствии секции crypto
map, поскольку адрес удалённого узла доступен из конфигурации туннельного
интерфейса, а список доступа для идентификации данных не нужен – шифроваться
будут все данные, проходящие через туннельный интерфейс. Алгоритм шифрования
данных, определяемый в секции transform-set, указывается в конфигурации
туннельного интерфейса именем профиля, определяемого секцией crypto ipsec profile.
crypto isakmp policy 10
encryption 3des
hash md5
authentication pre-share
group 2
lifetime 86400
crypto isakmp key mykey address 2.2.2.2
!
crypto ipsec transform-set MyTS esp-3des esp-sha-hmac
!
crypto ipsec profile tunCryptoProfile
set security-association lifetime kilobytes 205000
set transform-set MyTS
!
interface Tunnel1
ip mtu 1400
ip tcp adjust-mss 1360
ip address 3.3.3.1 255.255.255.252
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
tunnel protection ipsec profile tunCryptoProfile
В случае совместного использования GRE и IPSec, во избежание появления
разнообразных неожиданных непонятных проблем, настоятельно
рекомендуется явно указывать параметры размеров IP пакетов.
Интересующиеся могут найти в Интернете много информации про правила
установки MTU / MSS в случае использования туннельных технологий, мы
же предложим воспользоваться следующим простым алгоритмом расчёта
параметров на туннельном интерфейсе:
• MTU устанавливать на 100 байт меньше, чем MTU интерфейса, на
котором строится туннель (определяется командой tunnel source),
• TCP MSS устанавливать на 40 байт меньше MTU,
что, в нашем примере, дает ip mtu 1400 и ip tcp adjust-mss 1360.
Детальнее – тут: http://ciscomaster.ru/content/ip-mtu-i-tunneli-ipsec-i-gre
6
CC-BY-4.0 p.619

20. IPSec Introduction
Организация связи с использованием L2TP
Более громоздкий и не слишком удобный, но всё же возможный вариант организации
защищённого соединения между узлами связи состоит в использовании механизма
Layer 2 Tunneling Protocol (L2TP). Корни этого протокола уходят в историю.
В далёком 1990 году была опубликована первая спецификация протокола PPP (Point-to-
Point Protocol), предназначенного для организации канала связи между двумя
непосредственно соединёнными устройствами (например, между компьютерами,
подключенными друг к другу по телефонному кабелю посредством модемов). PPP –
протокол второго уровня модели OSI и так же, как Ethernet, обладает возможностью
инкапсулирования других протоколов верхнего уровня, в том числе IP. В отличие от
Ethernet, PPP является сессионным протоколом, что позволяет устанавливать разные
параметры для каждой сессии (аутентификация, компрессия, мультиплексирование
сессий, права доступа, безопасность) и полностью контролировать её состояние.
Дополнительным преимуществом PPP является его расширяемость, которая позволяет
добавлять ему новые функции без изменения самого протокола.
Благодаря возможностям полного контроля над сессией и её параметрами, основным
применением протокола PPP стало подключение конечных абонентов к сети оператора.
Со временем, однако, подключение абонентов мигрировало от непосредственных
соединений до использования сетей совместного доступа (например, Ethernet или
DOCSIS) и возникла необходимость в механизмах туннелирования протокола PPP от
абонентского устройства до сервера доступа (т.н. BRAS – Broadband Access Server или
BNG – Broadband Network Gateway) через сети совместного доступа.
Одним из таких протоколов является L2TP. Спецификация L2TP v2 была опубликована
в 1999 году и описывала транспортировку фреймов PPP поверх сетей IP внутри пакетов
UDP. В 2005 году была опубликована спецификация L2TP v3 (RFC3931) с
возможностью транспортировки фреймов других протоколов (в том числе Ethernet), но
она запоздала и не получила широкого распространения: к этому моменту уже
сложилась устойчивая модель, в которой PPP и L2TPv2 были массово реализованы в
абонентских устройствах и использовались только для подключения конечных
абонентов к сети, а для объединения сегментов сети Ethernet использовались
механизмы на основе MPLS (EoMPLS, VPLS).
Также, широко распространён механизм транспортировки фреймов PPP
внутри фреймов Ethernet. Он называется PPPoE (PPP over Ethernet), описан в
RFC2516 и не рассматривается в данном материале.6
CC-BY-4.0 p.620

21. IPSec Introduction
Общая архитектура подключения с использованием PPP / L2TP приведена на схеме:
6
В этой архитектуре всегда присутствуют следующие роли:
• “PPP client”, “BNG” – устройства, устанавливающие между собой PPP-сессию;
• “LAC” (L2TP Access Concentrator), “LNS” (L2TP Network Server) – устройства,
устанавливающие между собой L2TP туннель для обслуживания PPP сессий.
Как правило, пары ролей “PPP client” и “LAC”, а также “LNS” и “BNG” совмещены в
одном устройстве, но это не означает их отсутствия.
Теперь Вы понимаете, почему в начале этого раздела мы сказали, что механизм L2TP –
громоздкий:
1. в нем присутствует большое количество компонентов, протоколов и
инкапсуляций, что затрудняет и замедляет диагностику проблем в случае их
появления;
2. в конфигурации BNG нет заранее настроенных интерфейсов для подключения
удаленных точек – интерфейс создается динамически из шаблона, в ответ на
запрос удалённой стороны, при этом каждый раз для одного и того же
удалённого узла его интерфейсу будет присваиваться новый номер. Это
существенно затрудняет обслуживание, мониторинг и диагностику системы.
3. И это Вы еще пример конфигурации не видели!
Несмотря на то, что выше мы рассмотрели более удобные механизмы организации
таких соединений, L2TP должен применяться в случаях, когда у подключающегося
узла нет постоянного IP-адреса и, таким образом, настроить GRE-туннель нет
возможности.
Пример собирался и проверялся в эмуляторе GNS3 на основе образа Cisco
IOS v15.2(4)S7 Advanced Enterprise Services для маршрутизатора Cisco 7200.
Для других моделей маршрутизаторов и других версий IOS команды могут
незначительно отличаться.
6
CC-BY-4.0 p.621

22. IPSec Introduction
Настройка ролей BNG / LNS на центральном узле (R1).
aaa new-model
! ===== Локальное (local) хранение имен и паролей ======
aaa authentication ppp default local
!
interface Loopback0
ip address 9.9.9.1 255.255.255.255
! ===== Включение ролей BNG / LNS =====
vpdn enable
! ===== Конфигурация для подключения узла R6 ======
! указание имени / адреса узла и соответствующего ему шаблона
vpdn-group R6
accept-dialin
protocol l2tp
virtual-template 6
terminate-from hostname R6
! не защищать l2tp-сессию паролем, будем использовать PPP auth
no l2tp tunnel authentication
! шаблон для создания интерфейса
interface Virtual-Template6
ip unnumbered Loopback0
ip mtu 1400
ip tcp adjust-mss 1360
peer default ip address pool R6-address
ppp mtu adaptive
ppp authentication pap
! имя / пароль для установления PPP сессии
username r6 password 0 r6pass
! IP адрес и маршрут для локальной сети узла R6
ip local pool R6-address 9.9.9.6
ip route <R6’s LAN address/mask> 9.9.9.6
! ===== Конфигурация для подключения узла R3 ======
vpdn-group R3
accept-dialin
protocol l2tp
virtual-template 3
terminate-from hostname R3
no l2tp tunnel authentication
!
CC-BY-4.0 p.622

23. IPSec Introduction
interface Virtual-Template3
ip unnumbered Loopback0
ip mtu 1400
ip tcp adjust-mss 1360
peer default ip address pool R3-address
ppp mtu adaptive
ppp authentication pap
!
username r3 password 0 r3pass
ip local pool R3-address 9.9.9.3
ip route <R3’s LAN address/mask> 9.9.9.3
В случае успешной установки всех соединений, Вы сможете увидеть следующую
картину:
Так же как и с GRE, протоколы PPP и L2TP не шифруют данные, поэтому для скрытия
передаваемых данных необходимо использовать защищенный канал IPSec для
пересылки фреймов L2TP.
Совместное использование L2TP и IPSec
Настройка IPSec на центральном узле (R1).
В этом разделе мы рассмотрим способ организации IPSec SA, который несколько
отличается от рассмотренного в первом разделе (Конфигурация и работа IPSec). Этот
способ (использование dynamic-map) более удобен для организации большого
количества IPSec туннелей и может использоваться вместо описанного в первом
разделе.
Основная идея этой конфигурации заключается в том, что заранее неизвестно, каким IP
адресом будет пользоваться удалённая сторона для установления шифрованого
R1#show l2tp tunnel
L2TP Tunnel Information Total tunnels 2 sessions 2
LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/
Count VPDN Group
23197 55540 R6 est 6.6.6.2 1 R6
40212 21846 R3 est 2.2.2.2 1 R3
R1#show ppp all
Interface/ID OPEN+ Nego* Fail- Stage Peer Address Peer Name
------------ --------------------- -------- --------------- --------------------
Vi2.2 LCP+ PAP+ IPCP+ LocalT 9.9.9.3 r3
Vi2.1 LCP+ PAP+ IPCP+ LocalT 9.9.9.6 r6
R1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Loopback0 9.9.9.1 YES manual up up
[ … ]
Virtual-Access2 unassigned YES unset up up
Virtual-Access2.1 9.9.9.1 YES unset up up
Virtual-Access2.2 9.9.9.1 YES unset up up
Virtual-Template3 9.9.9.1 YES unset down down
Virtual-Template6 9.9.9.1 YES unset down down
CC-BY-4.0 p.623

24. IPSec Introduction
соединения и какие данные необходимо будет шифровать. В первой части эти
параметры явно указывались с помощью команд crypto isakmp key mykey address
x.x.x.x (которая явно указывала адрес удалённой стороны и ключ) и ip access-list
extended TO_ENCRYPT (в которой явно указывались параметры данных, подлежащих
шифрованию) и при несовпадении, в частности, этих параметров установление сессии
не происходило. В приведенном ниже примере этих команд нет и установление сессии
происходит только при совпадении параметров ISAKMP Phase 1 (crypto isakmp
policy), ISAKMP Phase 2 (crypto ipsec transform-set), а также общего ключа. При этом,
адрес удалённой стороны может быть любым, а параметры шифруемых данных
передаются при установлении соединения.
Также, введем еще одно новшество. Возможно, Вы обратили внимание, что в примерах
выше мы использовали IKEv1, хотя в предыдущем материале рекомендовали
использовать более быстрый и более надёжный IKEv2. Мы исправим это в
приведенном ниже примере и покажем, как настраивать IKEv2. Настройка его состоит
из большего числа секций, но функционально они соответствуют настройкам IKEv1,
что легко обнаруживается при внимательном сопоставлении фрагментов примера.
Отличия от конфигурации, которая дана в первой части, выделены цветом:
! ===== ISAKMP Phase 1 (IKEv1) =====
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
lifetime 3600
! ===== Определить ключ для любого адреса (0.0.0.0/0)
crypto keyring IKEv1-ring
pre-shared-key address 0.0.0.0 0.0.0.0 key mykey
! ===== Разрешить установление соединения с любого адреса
crypto isakmp profile IKEv1-profile
keyring IKEv1-ring
match identity address 0.0.0.0
Поскольку адрес удалённой стороны и параметры данных, подлежащих
шифрованию, неизвестны, то защищённый канал установится только после
того, как удалённая сторона инициирует соединение.
Поскольку в такой конфигурации общий ключ (pre-shared key) не связывается
с конкретным IP-адресом удалённой стороны, то утечка конфигурационного
файла с ключём приведет к возможности установления зашифрованного
соединения с любого другого узла. Для увеличения безопасности,
обязательно следуйте инструкциям из следующего документа (англ.) – http://
tinyurl.com/z5gu9xp , но следует помнить, что это всё равно не даёт никаких
гарантий безопасности при наличии физического доступа к устройству.
6
CC-BY-4.0 p.624

25. IPSec Introduction
! ===== ISAKMP Phase 1 (IKEv2) =====
crypto ikev2 proposal IKEv2-proposal
encryption 3des
integrity sha1
group 2
!
crypto ikev2 policy IKEv2-policy
match address local 1.1.1.1
proposal IKEv2-proposal
! ===== Разрешить ключ для любого адреса (0.0.0.0/0)
crypto ikev2 keyring IKEv2-ring
peer R1
address 0.0.0.0 0.0.0.0
pre-shared-key mykey
! ===== Разрешить установление соединения с любого remote address
crypto ikev2 profile IKEv2-profile
match address local 1.1.1.1
match identity remote address 0.0.0.0
authentication remote pre-share
authentication local pre-share
keyring local IKEv2-ring
!
! ===== Параметры ISAKMP Phase 2 =====
! ===== общие для IKEv1 и IKEv2 =====
crypto ipsec transform-set myTS esp-3des esp-sha-hmac
! === будет использована 1-я или 2-я секция в зависимости от
! === настроек удалённого узла – IKEv1 или IKEv2
crypto dynamic-map myDynaMap 1
set transform-set myTS
set isakmp-profile IKEv1-profile
crypto dynamic-map myDynaMap 2
set transform-set myTS
set isakmp-profile IKEv2-profile
! ===== Использовать динамически устанавливаемые параметры =====
crypto map myCryptoMap 10 ipsec-isakmp dynamic myDynaMap
!
interface FastEthernet0/0
ip address 1.1.1.1 255.255.255.0
crypto map myCryptoMap
CC-BY-4.0 p.625

26. IPSec Introduction
Настройка удалённого узла (для примера – R6).
В целом, конфигурации удалённых узлов идентичны. Поскольку примеры IKEv1 уже
доступны в предыдущих разделах, мы еще раз покажем конфигурацию для IKEv2:
! ===== Настройка ролей PPP client / LAC =====
! ===== Выбор L2TPv2 для туннелирования данных (роль LAC)
pseudowire-class myLAC
encapsulation l2tpv2
ip local interface FastEthernet1/0
! ===== виртуальный интерфейс (роль PPP-client)
interface Virtual-PPP1
ip address negotiated
ip mtu 1400
ip tcp adjust-mss 1360
ppp pap sent-username r6 password 0 r6pass
! == указание использовать роль LAC для туннелирования фреймов PPP
pseudowire 1.1.1.1 1 encapsulation l2tpv2 pw-class myLAC
!
! === настройка необходимых сетевых маршрутов
ip route <R1’s LAN address / mask> Virtual-PPP1
ip route <R3’s LAN address / mask> Virtual-PPP1
!
! ===== ISAKMP Phase 1 (IKEv2) =====
crypto ikev2 proposal IKEv2-proposal
encryption 3des
integrity sha1
group 2
!
crypto ikev2 policy IKEv2-policy
match address local 6.6.6.2
proposal IKEv2-proposal
! ===== ключ и адрес центрального узла (R1)
crypto ikev2 keyring IKEv2-ring
peer R1
address 1.1.1.1
pre-shared-key mykey
!
crypto ikev2 profile IKEv2-profile
match address local 6.6.6.2
match identity remote address 1.1.1.1 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local IKEv2-ring
CC-BY-4.0 p.626

27. IPSec Introduction
! ===== ISAKMP Phase 2
crypto ipsec transform-set myTS esp-3des esp-sha-hmac
!
crypto map myCryptoMap 15 ipsec-isakmp
set peer 1.1.1.1
set transform-set myTS
set ikev2-profile IKEv2-profile
match address 100
!
interface FastEthernet1/0
ip address 6.6.6.2 255.255.255.252
crypto map myCryptoMap
!
! ===== настройка параметров данных для шифрования
! ===== данные передаются внутри L2TP туннеля
! ===== L2TP туннель строится между узлами 6.6.6.2 и 1.1.1.1
! ===== туннелирование L2TP работает поверх UDP на портах 1701
access-list 100 permit udp host 6.6.6.2 eq 1701 host 1.1.1.1 eq 1701
Обратите внимание, что параметры трафика, подлежащего шифрованию, определяются
списком доступа access-list 100 и на каждом удаленном узле он должен быть другим.
Например, для узла R3 (адрес 2.2.2.2) он будет таким:
Просмотреть состояние установленный IKEv2 SA можно командой
show crypto ikev2 sa.
Дополнительные рекомендации по увеличению стойкости
IPSec
Perfect Forward Secrecy
Идея механизма Forward Secrecy (также, широко распространено название Perfect
Forward Secrecy – PFS) заключается в следующем: если что-то было зашифровано и
считается теперь находящимся в безопасности, оно должно оставаться таковым и в
будущем. Суть действия механизма заключается в периодической смене ключа
шифрования данных на новый, никогда не повторяющийся. В таком случае, если вдруг
злоумышленник каким-либо способом получит ключ шифрования текущей сессии, он
не сможет с помощью этого ключа расшифровать перехваченные и сохранённые ранее
данные предыдущих сессий.
В инфраструктуре IPSec механизмом PFS называется генерация нового ключа
шифрования всякий раз при окончании действия текущей SA (определяется
параметром lifetime seconds / kilobytes) и переустановлении следующей SA в рамках
ISAKMP Phase 2. Это увеличивает надёжность сохранности данных в будущем, но
также увеличивает нагрузку на шифрующие узлы, поскольку приводит к
периодическому выполнению обмена Diffie-Hellman с ключом заданной длины.
access-list 100 permit udp host 2.2.2.2 eq 1701 host 1.1.1.1 eq 1701
CC-BY-4.0 p.627

28. IPSec Introduction
В маршрутизаторах под управлением Cisco IOS, PFS включается в секциях crypto map
или crypto dynamic-map, в качестве аргумента указывается группа Diffie-Hellman,
которая будет использоваться при генерации каждого нового ключа шифрования:
Traffic Flow Confidentiality
Множество исследований продемонстрировало, что статистический анализ даже
зашифрованных данных может дать достаточно большое количество информации о
передаваемых данных, например об используемых сервисах и приложениях, о типах
физических устройств в сети и даже о Web-сервисах, к которым осуществлялся доступ.
Причём, для получения этой информации совсем необязательно анализировать трафик
на протяжении долгого периода – во многих случаях для относительно точной
идентификации данных достаточно нескольких первых пакетов зашифрованного
потока. Владение этой информацией не является взломом как таковым, однако
существенно помогает в разработке стратегии проникновения в защищаемую сеть.
Поэтому, противодействие статистическому анализу потоков данных является важной
частью обеспечения защиты сети.
Последние доступные базовые спецификации IPSec (RFC4301 – 4303) описывают два
механизма противодействия статистическому анализу зашифрованных данных,
которые позволяют изменить статистические параметры трафика до неузнаваемости:
1. Генерация и передача фиктивных (dummy) пакетов в зашифрованном потоке,
перемежая их с реальными пакетами. Достаточно мощный инструмент сам по
себе, особенно помогающий в ситуациях, когда используемые в сети протоколы
и/или приложения не позволяют выполнять задержку реальных пакетов с целью
изменения шаблона трафика.
2. Traffic Flow Confidentiality (TFC) Padding увеличивает размер пакета (не меняя
оригинального значения размера пакета в заголовке), что позволяет скрыть
истинный размер передаваемого пакета данных, при этом корректно
восстановить пакет на принимающей стороне.
Для увеличения устойчивости сети ко взломам настоятельно рекомендуется включать
эти механизмы.
На момент написания этого материала, маршрутизаторы производства Cisco
поддерживают только генерацию и передачу фиктивных пакетов и настраивается это
следующими командами:
crypto dynamic-map myDynaMap 1
[ … ]
set isakmp-profile IKEv2-profile
set pfs group2
!
crypto map myCryptoMap 15 ipsec-isakmp
[ … ]
set ikev2-profile IKEv1-profile
set pfs group14
CC-BY-4.0 p.628

29. IPSec Introduction
Убедиться в том, что механизмы PFS и генерация dummy-пакетов работают, можно
командой ‘show crypto ipsec sa’:
! настройка для всех SA, на глобальном уровне
! количество пакетов в секунду
crypto ipsec security-association dummy pps N
! или один пакет в указанное количество секунд
crypto ipsec security-association dummy seconds M
!
! либо то же самое может быть указано для отдельных SA
! в секции crypto map или crypto dynamic-map:
crypto map myCryptoMap 15 ipsec-isakmp
[ … ]
set security-association dummy { pps N | seconds M }
R6#show crypto ipsec sa
Crypto map tag: myCryptoMap, local addr X.X.X.X
[ … ]
#send dummy packets 110323, #recv dummy packets 114386
[ … ]
PFS (Y/N): Y, DH group: group14
Dummy packet: Enabled: target rate = 5 pps
Обратите внимание на то, что для IKEv2 сессий вывод команды будет
содержать “PFS (Y/N): N, DH group: none’ в течение времени жизни первой
установленной SA. После переустановления SA (по окончании времени
жизни предыдущей SA) вывод команды покажет корректные значения.
6
CC-BY-4.0 p.629

30. IPSec Introduction
Заключение
В этом материале мы рассмотрели три способа организации защищённой связи между
удалёнными локальными сетями узлов связи (site-to-site VPN), каждый из которых
имеет свои преимущества и недостатки. В целом, их применимость может быть
описана таким резюме:
Есть еще один способ организации защищённых каналов связи – использование
механизма TLS (Transport Layer Security).
Технологически, TLS может предоставлять те же возможности шифрования данных,
что и IPSec. Однако, в отличие от IPSec:
• стандарты TLS описывают шифрование только содержимого UDP и TCP
протоколов (не меняя заголовки IP, TCP и UDP). Такое поведение подобно
транспортному режиму IPSec, при котором информация об источнике и
назначении данных передаётся в открытом виде.
• Все протоколы, работающие непосредственно поверх IP (например, ICMP) не
поддерживаются механизмом TLS.
• Стандарты TLS не описывают применение механизма Traffic Flow
Confidentiality, что позволяет выполнять статистический анализ даже
зашифрованных данных.
• TLS не работает с протоколом IP и, соответственно, не поддерживает
туннелирование, работая в уже сформированном контексте IP-обмена. Для
создания полноценного туннеля, аналогичного туннельному режиму IPSec,
требуется наличие дополнительного прикладного программного обеспечения,
которое должно реализовать собственную, не описанную в стандартах и
несовместимую с другими модель туннелирования на основе собственных же
компонентов – VPN-клиента и VPN-сервера (шлюза).
1
IPSec: подходит для небольших узлов с фиксированной
конфигурацией, которые не выполняют транзитные
фу н к ц и и и кото р ы м н е н уж н а р а с ш и р е н н а я
функциона льно сть, например, динамиче ская
маршрутизация.
2
GRE over IPSec: наилучший выбор для стационарных
узлов связи, которые подключаются к сети с постоянным
IP-адресом и могут выполнять функции транзита данных
между другими узлами.
3
L2TP over IPSec: наиболее громоздкий из трёх способ, но
единственный подходящий для транзитных узлов, которые
при каждом подключении к сети получают новый IP-адрес.
Впрочем, для упрощения обслуживания сети, его можно
использовать вместо “чистого” IPSec (п.1), уменьшив
таким образом количество используемых в сети
механизмов.
6
6
6
CC-BY-4.0 p.630

31. IPSec Introduction
В связи со сказанным выше, производители систем защиты данных не используют TLS
для создания защищённых соединений между сетевыми узлами, предлагая
использование описанных выше способов на основе IPSec. На момент написания
статьи, использование TLS для создания таких сетей возможно только с продуктами c
открытым исходным кодом (например, OpenVPN, Quagga на основе Linux), но со всеми
свойственными платформе x86 ограничениями в производительности, а также со
свойственной открытому ПО сложностью сопровождения.
На практике, TLS используется для организации защищённого обмена данными на
уровне приложений (например, между Web-браузером и Web-сервером или между
почтовой программой и почтовым сервером), а также для организации защищённого
подключения конечных хостов (компьютеров) к VPN на основе компонентов одного
производителя (например, Cisco AnyConnect и ASA5000 или OpenVPN клиент и
сервер).
В сухом остатке – механизмы GRE over IPSec и L2TP over IPSec предоставляют всю
необходимую и достаточную функциональность для организации защищённой связи
между узлами любых типов.
CC-BY-4.0 p.631