Смарт ТВ 

Протоколы IPSec. Как работает ipSec

Посмотрело: 7391

0 Давайте рассмотрим детали технологий, составляющих суть IPSec. Стандарты, используемые в рамках IPSec, являются достаточно сложными для понимания, поэтому в этом разделе мы рассмотрим каждую из составляющих IPSec подробно. Для понимания того что такое IPSEC используйте документ "IPSEC как протокол защиты сетевого трафика", опубликованный ранее на этом сайте. Данная статья является продолжением вышеуказанного документа.

В IPSec используются следующие технологии:

  • протокол АН;
  • протокол ESP;
  • стандарт шифрования DES;
  • стандарт шифрования 3DES;
  • протокол IKE;
  • метод согласования ключей по схеме Диффи-Хеллмана;
  • хэшированные коды аутентичности сообщений (НМАС);
  • защита RSA;
  • центры сертификации.

Протокол АН

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

  1. Выполняется хэширование IP-заголовка и полезного груза пакета.
  2. Полученный хэш-код используется при построении нового заголовка АН, который подсоединяется к исходному пакету между заголовком и блоком полезного груза.
  3. Новый пакет передается второй стороне IPSec.
  4. Сторона-получатель вычисляет значение хэш-кода для заголовка IP и полезного груза, извлекает переданное значение хэш-кода из заголовка АН и сравнивает эти два значения. Соответствующие значения хэш-кода должны в точности совпадать. Если в пути изменится хотя бы один бит пакета, вычисленный получателем хэш-код пакета не будет совпадать со значением, указанным в заголовке АН.
Протокол АН обеспечивает аутентификацию для максимально возможного числа полей заголовка IP, как и для полей данных протоколов высших уровней. Однако некоторые поля заголовка IP могут изменяться в пути. Значения изменяемых полей (например, поля TTL, указывающего время существования пакета) изменяются промежуточными сетевыми устройствами, через которые проходит пакет, и такие изменения отправитель прогнозировать не может. Значения изменяемых полей не должны защищаться протоколом АН. Таким образом, защита, которая обеспечивается заголовку IP протоколом АН, оказывается несколько ограниченной. Протокол АН может также дополнительно обеспечить защиту от воспроизведения пакетов, для чего в заголовке IP указывается порядковый номер пакета. Полное описание протокола АН со¬держится в документе RFC 2402.

Протокол ESP

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

Протокол ESP обеспечивает конфиденциальность с помощью шифрования на уровне пакетов IP. При этом поддерживается множество алгоритмов симметричной схемы шифрования. Алгоритмом по умолчанию для IPSec является DES с 56-битовым ключом. Этот шифр должен присутствовать для гарантии совместимости между всеми поддерживающими IPSec продуктами. Продукты Cisco поддерживают также алгоритм 3DES, обеспечивающий более стойкое шифрование. Конфиденциальность может быть выбрана независимо от других сервисов.

Аутентификация источника данных и поддержка целостности без установления соединений используются совместно и являются опциями (т.е. необязательны). Эти возможности можно также объединить с сервисом конфиденциальности.
Сервис защиты от воспроизведения можно выбрать только в том случае, если выбрана аутентификация источника данных, и выбор этого сервиса является исключительной прерогативой получателя. Хотя по умолчанию от отправителя и требуется ав¬томатически увеличивать порядковый номер, используемый для защиты от воспроизведения, этот сервис оказывается эффективным только в том случае, если получатель проверяет этот порядковый номер. Конфиденциальность трафика требует выбора тун¬нельного режима. Наиболее эффективным это оказывается в шлюзе защиты, где маскировка источника-адресата может быть выполнена сразу для всего трафика. Здесь следует отметить, что хотя и конфиденциальность, и аутентификация являются опциями, должен быть выбран по крайней мере один из этих сервисов.
Набор сервисов, обеспечиваемых протоколом ESP, зависит от параметров, которые указываются в конфигурации IPSec и выбираются при создании ассоциации защиты IPSec. Однако выбор конфиденциальности без целостности/аутентификации (или в рамках ESP, или отдельно с помощью АН) оставляет противнику возможность для проведения атак определенного вида, что может ограничить пользу применяемого та¬ким образом сервиса конфиденциальности.
Заголовок ESP вставляется в пакет после заголовка IP перед заголовком протокола высшего уровня (в транспортном режиме) или перед инкапсулированным заголовком IP (в туннельном режиме). Полное описание протокола ESP содержится в документе RFC 2406.

Шифрование ESP с применением НМАС

В рамках протокола ESP может также обеспечиваться аутентификация пакетов с помощью необязательного поля аутентификации. В программном обеспечении Cisco IOS и в брандмауэрах PIX Firewall этот сервис называется ESP НМАС. Значения аутентификации вычисляются после того, как выполнено шифрование. Используемый сегодня стандарт IPSec описывает алгоритмы SHA1 и MD5 как обязательные для НМАС.
Главное различие между аутентификацией ESP и аутентификацией АН заключается в области их охвата. ESP не защищает никаких полей заголовка IP, если только не предполагается инкапсуляция ESP (туннельный режим). На рис указано, какие поля защищаются при использовании ESP НМАС.


Обратите внимание на то, что шифрование охватывает только данные полезного груза, a ESP с хэшированием ESP НМАС - заголовок ESP и данные полезного груза. Заголовок IP не защищается. Сервис ESP НМАС не может использоваться самостоя¬тельно, а должен быть объединен с протоколом шифрования ESP.

Туннельный и транспортный режимы IPSec

IPSec действует или в туннельном, или в транспортном режиме. На рис показана схема реализации туннельного режима. В этом режиме вся исходная дейтаграмма IP шифруется и становится полезным грузом в новом пакете IP с новым заголовком IP и дополнительным заголовком IPSec (на рис. заголовок обозначен аббревиатурой HDR). Туннельный режим позволяет сетевому устройству (например, брандмауэру PIX Firewall) выступать в роли шлюза IPSec или прокси-сервера, выполняющего шифрование для хостов, размещенных за брандмауэром. Маршрутизатор источника шифрует пакет и передает его по туннелю IPSec. Брандмауэр PIX Firewall адресата дешифрует полученный пакет IPSec, извлекает исходную дейтаграмму IP и передает ее системе адресата. Главное преимущество туннельного режима заключается в том, что не требуется модифицировать конечные системы, чтобы обеспечить им возможность использования IPSec. Туннельный режим также не позволяет противнику анализировать поток данных. При обмене в туннельном режиме противник имеет возможность определить только конечные точки туннеля, но не истинных источника и адресата проходящих через туннель пакетов, даже если конечные точки туннеля находятся как раз в системах источника и адресата.


Схема на рис ниже иллюстрирует транспортный режим. Здесь шифруется только полезный груз IP, а исходный заголовок IP остается нетронутым.
Добавляется заголовок IPSec. Преимуществом этого режима является добавление только нескольких байтов к каждому пакету. Кроме того, устройства открытой сети могут видеть истинные адреса отправителя и получателя пакета.


Это позволяет использовать специальные возможности промежуточных сетей (например, гарантированное качество сервиса), основанные на информации в заголовке IP. Однако заголовок уровня 4 шифруется, что ограничивает возможности анализа пакета. К сожалению, передача заголовка IP в открытом виде в транспортном режиме позволяет нарушителю в определенной мере выполнить анализ потока данных. Например, нарушитель может выяснить, сколько пакетов было передано сторонами IPSec, действующими в транспортном режиме. Но нарушитель может узнать только о том, что пакеты IP пересылались. Он не сможет определить, были ли они сообщением электронной почты или каким-то другим приложением, если использовался протокол ESP.

Использование туннельного и транспортного режимов

Рассмотрим несколько примеров, иллюстрирующих правила выбора туннельного или транспортного режима. На рис ниже показаны ситуации, в которых используется туннельный режим. Этот режим чаще всего используется для шифрования потока данных между шлюзами защиты IPSec - например, между маршрутизатором Cisco и брандмау эром PIX Firewall. Шлюзы IPSec выполняют функции IPSec для устройств, находящихся за такими шлюзами (на указанном рисунке это персональный компьютер Алисы и серверы HR). В этом примере Алиса получает защищенный доступ к серверам HR через туннель IPSec, установленный между шлюзами.

Туннельный режим используется и для связи конечных станций, в которых выполняется программное обеспечение IPSec, например для связи клиента CiscoSecure VPN и шлюза IPSec.
В данном примере туннельный режим применяется для создания туннеля IPSec между маршрутизатором Cisco и сервером, на котором выполняется программное обеспечение IPSec. Обратите внимание на то, что в программном обеспечении Cisco IOS и брандмауэра PIX Firewall туннельный режим для связей IPSec является режимом, устанавливаемым по умолчанию.
Транспортный режим используется между конечными станциями, поддерживающими IPSec, или между конечной станцией и шлюзом, если шлюз интерпретируется как хост. На рис. ниже показан пример Г, иллюстрирующий применение транспортного режима для создания шифрованного туннеля IPSec от компьютера Алисы, на котором выполняется программное обеспечение клиента Microsoft Windows 2000, к концентратору Cisco VPN 3000, что позволяет Алисе использовать L2ТР-туннель над IPSec.

Использование АН и ESP

В определенных ситуациях проблема выбора между АН и ESP может показаться сложной для решения, но ее можно упростить, если следовать нескольким правилам. Если вам необходимо знать, что данные из идентифицированного источника передают¬ся без нарушения целостности, а их конфиденциальность обеспечивать не требуется, используйте протокол АН, который защищает протоколы высших уровней и поля заголовка IP, не изменяемые в пути. Защита означает, что соответствующие значения нельзя изменить, потому что это будет обнаружено второй стороной IPSec и любая модифицированная дейтаграмма IP будет отвергнута. Протокол АН не обеспечивает защиту от прослушивания канала и просмотра нарушителем заголовка и данных. Но поскольку заголовок и данные незаметно изменить нельзя, измененные пакеты отвергаются.

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

    pre-shared key : Два даемона racoon подключаются друг к другу, подтверждают, что они именно те, за кого себя выдают (используя секретный ключ, заданный вами, по умолчанию в файле /etc/racoon/psk.txt). Затем даемоны генерируют новый секретный ключ и используют его для шифрования трафика через VPN. Они периодически изменяют этот ключ, так что даже если атакующий сломает один из ключей (что теоретически почти невозможно) это не даст ему слишком много – он сломал ключ, который два даемона уже сменили на другой. Предварительный ключ(pre-shared key) не используется для шифрования трафика через VPN соединение это просто маркер, позволяющий управляющим ключами даемонам доверять друг другу. Права на файл psk.txt должны быть 0600 (т.е. запись и чтение только для root).

    IPsec состоит из двух протоколов:

    Encapsulated Security Payload (ESP), защищающей данные IP пакета от вмешательства третьей стороны путем шифрования содержимого с помощью симметричных криптографических алгоритмов (таких как Blowfish,3DES, AES).

    Authentication Header (AH), защищающий заголовок IP пакета от вмешательства третьей стороны и подделки путем вычисления криптографической контрольной суммы и хеширования полей заголовка IP пакета защищенной функцией хеширования. К пакету добавляется дополнительный заголовок с хэшем, позволяющий аутентификацию информации пакета.

ESP и AH могут быть использованы вместе или по отдельности, в зависимости от обстоятельств.

esp и ah - пакеты ipsec, формируются ядром после того как хосты, при помощи racoon, договорятся о ключе по протоколу isakmp (500/udp).

Режимы работы IPsec(транспортный, туннельный)

Существует два режима работы IPsec: транспортный режим и туннельный режим(когда в транспортном режиме работают только маршрутизаторы).

IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения "виртуальных туннелей" между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Туннельный режим обычно называют виртуальной частной сетью (Virtual Private Network, vpn).

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

В туннельном режиме IP-пакет шифруется целиком. Для того, чтобы его можно было передать по сети, он помещается в другой IP-пакет. По существу, это защищённый IP-туннель. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей виртуальной частной сети. В туннельном режиме инкапсулируется весь исходный IP пакет, и добавляется новый IP заголовок.

Если используется IPsec совместно с GRE туннели , который инкапсулирует исходный пакет и добавляет новый IP заголовок, логично использовать транспортный режим.

Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые SA могут использовать транспортный режим, а другие - туннельный.

Security Associations (SA) . Для возможности проводить инкапсуляцию/декапсуляцию стороны участвующие в процессе обмена должны иметь возможность хранить секретные ключи, алгоритмы и IP адреса. Вся эта информация хранится в Ассоциациях Безопасности (SA), SA в свою очередь хранятся в Базе данных Ассоциаций Безопасности (SAD). Конфигурирование Security Association , позволяет задать например mode transport | tunnel | ro | in_trigger | beet - режим безопасной ассоциации. Соответственно, может принимать одно из значений, означающих транспортный, тоннельный, beet (Bound End-to-End Tunnel), оптимизации маршрута (route optimization) или in_trigger режимы. (последние два используются в контексте mobile ipv6).

Security Policy (SP) - политика безопасности, хранится в SPD (База данных политик безопасности). SA специфицирует, как IPsec предполагает защищать трафик, SPD в свою очередь хранит дополнительную информацию, необходимую для определения какой именно трафик защищать и когда. SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA. SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.

IPSec (сеть-сеть) между серверами FreeBSD

    Шаг 1 : Создание и тестирование "виртуального" сетевого подключения.

    • Настройте оба ядра с device gif . В версии FreeBSD поддержка gif включена в ядро.

      Отредактируйте /etc/rc.conf на маршрутизаторах и добавьте следующие строки (подставляя IP адреса где необходимо). A.B.C.D - реальный IP первого маршрутизатора, W.X.Y.Z - реальный IP второго маршрутизатора. # IPsec №1 gateway > ee /etc/rc.conf ... # IPsec to S through ISP_V gif_interfaces="gif0" # gifconfig_gif0="local-ip(A.B.C.D) remote-ip (W.X.Y.Z)" gifconfig_gif0="194.x.x.x 91.x.x.x" ifconfig_gif0="inet 10.26.95.254 192.168.1.254 netmask 255.255.255.255" static_routes="vpn vpn1" route_vpn="-net 192.168.1.0/24 192.168.1.254" route_vpn1="-net 192.168.35.0/24 192.168.1.254" # IPsec №2 gateway > ee /etc/rc.conf ... # IPsec na G through ISPGate gif_interfaces="gif0" # gifconfig_gif0="W.X.Y.Z A.B.C.D" gifconfig_gif0="91.x.x.x 194.x.x.x" ifconfig_gif0="inet 192.168.1.254 10.26.95.254 netmask 255.255.255.255" static_routes="vpn" route_vpn="-net 10.26.95.0/24 10.26.95.254"

      Отредактируйте скрипт брандмауэра на обеих маршрутизаторах и добавьте # IPFW ipfw add 1 allow ip from any to any via gif0 # PF set skip on gif0

Теперь ping должны ходить между сетями.

    Защита соединения с помощью IPsec

    Шаг 2 : Защита соединения с помощью IPsec

    • Настройте оба ядра: > sysctl -a | grep ipsec

      если команда ничего не вывела, значит нужно пересобрать ядра на обоих маршрутизаторах с параметрами

      # IPSEC for FreeBSD 7.0 and above options IPSEC options IPSEC_FILTERTUNNEL device crypto # IPSEC for FreeBSD 6.3 options IPSEC # IP security options IPSEC_ESP # IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG # Необязательно. debug for IP security

      Устанавливаем порт ipsec-tools. > cd /usr/ports/security/ipsec-tools > make config > make install clean > ee /etc/rc.conf racoon_enable="YES" ipsec_enable="YES" > mkdir -p /usr/local/etc/racoon/cert > cp /usr/local/share/examples/ipsec-tools/racoon.conf /usr/local/etc/racoon/racoon.conf > cd /usr/local/etc/racoon/cert/

      Создаем SSL сертификаты на каждом хосте. Копируем с одной на другую файлики *.public. В принципе, имена ключей неважны, можно называть и по IP, с соответствующими расширениями.

      > openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout your.key1.private -outform PEM -out your.key1.pem > openssl x509 -req -in your.key1.pem -signkey your.key.private -out your.key1.public

    Создаем файл ipsec.conf. Настройка на шлюзе #1 (где есть публичный IP адрес A.B.C.D) для включения шифрования всего предназначенного W.X.Y.Z трафика. A.B.C.D/32 и W.X.Y.Z/32 это IP адреса и сетевые маски, определяющие сети или хосты, к которым будет применяться данная политика. В данном случае мы хотим применить их к трафику между этими двумя хостами. Параметр ipencap сообщает ядру, что эта политика должна применяться только к пакетам, инкапсулирующим другие пакеты. Параметр -P out сообщает, что эта политика применяется к исходящим пакетам, и ipsec – то, что пакеты будут зашифрованы.

Оставшаяся часть строки определяет, как эти пакеты будут зашифрованы. Будет использоваться протокол esp, а параметр tunnel показывает, что пакет в дальнейшем будет инкапсулирован в IPsec пакет. Повторное использование A.B.C.D и W.X.Y.Z предназначено для выбора используемых параметров безопасности, и наконец параметр require разрешает шифрование пакетов, попадающих под это правило.

Это правило соответствует только исходящим пакетам. Вам потребуется похожее правило, соответствующее входящим пакетам.

> ee /etc/ipsec.conf spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

Настройка на шлюзе #2 аналогична только меняются IP местами.

Настройка утилиты racoon

> ee /usr/local/etc/racoon/racoon.conf path include "/usr/local/etc/racoon"; path certificate "/usr/local/etc/racoon/cert/"; # following line activates logging & should deactivated later log debug; # если директива listen не задана, racoon слушает все доступные # адреса интерфейсов. listen { #isakmp::1 ; isakmp 202.249.11.124 ; #admin ; # administrative port for racoonctl. #strict_address; # requires that all addresses must be bound. } # описываем удалённый хост (на второй машине - идентично, # тока другой IP и ключи) remote 217.15.62.200 { exchange_mode aggressive,main; my_identifier asn1dn; peers_identifier asn1dn; # сертификаты этой машины certificate_type x509 "via.epia.public" "via.epia.private"; # сертификат удлённой машины peers_certfile x509 "test.su.public"; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2 ; } } sainfo anonymous { pfs_group 2; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; }

    Настройка пакетного фильтра PF, где esp_peers шлюз с которым создается шифрованный туннель. Разрешаем прохождение пакетов ESP и IPENCAP в обе стороны.

#pass IPSec pass in on $ext_if_a inet proto udp from { $esp_peers } to ($ext_if_a) port isakmp pass in on $ext_if_a inet proto esp from { $esp_peers } to ($ext_if_a) # pass out on $ext_if_a inet proto udp from { $esp_peers } to ($ext_if_a) port isakmp pass out on $ext_if_a inet proto esp from { $esp_peers } to ($ext_if_a)

Cмотрим логи /var/log/security и /var/log/messages.

Как только параметры безопасности установлены, вы можете просмотреть их используя setkey(8). Запустите

> /etc/rc.d/ipsec start > /usr/local/etc/rc.d/racoon start > setkey -D # список созданных защищенных каналов > setkey -DP # покажет список политик безопасности

на любом из хостов для просмотра информации о параметрах безопасности.

    Проверка работоспособности:

    ping между сетями должен работать

    Запускаем для прослушки физического интерфейса на котором построен туннель (а не виртуального gif0). В другом окне например ping -ем удаленную серую сеть (например, ping 192.168.1.11) tcpdump -i em0 -n host 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x >

tcpdump Linux примеры использования должен показывать ESP пакеты.

IPSec (сеть-сеть) между серверами Linux

# aptitude install ipsec-tools racoon

    Алгоритм настройки IPsec

    Настройка пакета racoon

    Создание политики безопасности

    Виртуальные интерфейсы. Они нужны для маршрутизации сетей находящихся в локальных сетях. Два соединенных сервера будут видеть себя без интерфейсов(иногда без них не заводится и между серверами, странно вообще-то).

Ниже приведены конфиги для случая с предопределёнными ключами.

> nano /etc/racoon/racoon.conf path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; #path certificate "/etc/racoon/certs"; remote 10.5.21.23 { exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address; #Определяет метод идентификации, который будет использоваться при проверке подлинности узлов. lifetime time 2 min; initial_contact on; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; # Определяет метод проверки подлинности, используемый при согласовании узлов. dh_group 2; } proposal_check strict; } sainfo anonymous # Отмечает, что SA может автоматически инициализировать соединение с любым партнёром при совпадении учётных сведений IPsec. { pfs_group 2; lifetime time 2 min ; encryption_algorithm 3des, blowfish 448, des, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; }

Создадим политику безопасности

> nano pol.cfg #!/sbin/setkey -f flush; spdflush; spdadd 10.5.21.24 10.5.21.23 any -P out ipsec esp/transport//require; spdadd 10.5.21.23 10.5.21.24 any -P in ipsec esp/transport//require; > chmod +x pol.cfg > ./pol.cfg

Создадим выполняемый файл для создания интерфейсов и запустим его.

>nano tun.sh #!/bin/sh ip tunnel del tun0 ip tunnel add tun0 mode ipip remote 10.5.21.23 local 10.5.21.24 dev eth0 # создаем интерфейс tun0 и устанавливаем туннель # между хостами (здесь нужно использовать реальные IP адреса сетевых интерфейсов). ifconfig tun0 10.0.9.1 pointopoint 10.0.9.2 # назначаем интерфейсу IP адреса, для текущего хоста и для другого конца # туннеля (не обязательно). ifconfig tun0 mtu 1472 ifconfig tun0 up # ниже можно прописать нужные нам маршруты, например так route add -net ... netmask 255.255.255.0 gw ... route add -net ... netmask 255.255.255.0 gw ... > ./tun.sh

Для автоматической загрузки правил файл tun.sh правильно поместить для Debian в директорию /etc/network/if-up.d

Все IPSec тунель между сетями настроен.

iptables IPSec

$IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 500 -j ACCEPT $IPT -A INPUT -p esp -j ACCEPT $IPT -A INPUT -p ah -j ACCEPT $IPT -A INPUT -p ipencap -j ACCEPT $IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 4500 -j ACCEPT

IPsec «узел-узел» без виртуальных интерфесов

Задача . При помощи IPSec (pre_shared_key) соединить два сервера (Debian 5 и Debian 7). У обоих реальные IP. Никаких сетей пробрасывать не надо. Должен шифроваться трафик между этими IP. То есть строим транспортный режим (между двумя хостами).

Настройка сводится к двум пунктам

    Настройка пакета racoon

    Создание политики безопасности: нужно указать режим transport и any spdadd x.x.x.x/32 y.y.y.y/32 any -P out ipsec esp/transport//require; spdadd y.y.y.y/32 x.x.x.x/32 any -P in ipsec esp/transport//require;

IPSec (GRE) (узел-сеть) между Debian и Cisco

Задача: построить IPsec в туннельном режиме. Описание RFC протокола SIP сигнализация между поставщиком (Cisco) и клиентом (Debian 5) шифруется IPsec, а RTP минуя туннель идет кратчайшим маршрутом через обычный Интернет.

    Клиент tunnel-endpoint is: 193.xxx.xxx.xxx

    Сервер tunnel-endpoint is: 62.xxx.xxx.xxx

    Клиент Sip Server is: 193.xxx.xxx.xxx

    Сервер SIP Servers are: 62.xxx.237.xxx/26 and 62.xxx.246.xxx/26

да и перед настрокой туннеля (перед auto tun0) прописать pre-up modprobe ip_gre

# modprobe ip_gre

Скрипт для создания GRE туннели туннеля в Debian:

#!/bin/sh -e modprobe ip_gre #ip tunnel del tun0 ip tunnel add tun0 mode gre remote 62.xxx.xxx.xxx local 193.xxx.xxx.xxx dev eth0 ifconfig tun0 mtu 1472 ifconfig tun0 up route add -net 62.xxx.237.xxx netmask 255.255.255.192 dev tun0 route add -net 62.xxx.246.xxx netmask 255.255.255.192 dev tun0

Утилиты

    Для управления можно использовать утилиту racoonctl racoonctl show-sa esp

    Cписок созданных защищенных каналов > setkey -D

    список политик безопасности > setkey -DP

Мониторинг IPsec

Мониторинг IPsec в Debian 5.0 2.6.26-2-686-bigmem i686. В уровень детализации логов log notify или log debug устанавливается в файле racoon.conf.

# tail -F /var/log/syslog | grep racoon

IPSec Openswan

OpenSWAN начал разрабатываться как форк прекратившего в настоящее своё существование проекта FreeS/WAN (Free Secure Wide-Area Networking), релизы продолжают выпускаться под свободной GNU General Public License. В отличие от проекта FreeS/WAN, OpenSWAN разрабатывается не только специально под операционную систему GNU/Linux. OpenSWAN обеспечивает стек протоколов IpSec: AH и ESP для ядра Linux,а также инструментарий для управления ими.

OpenSWAN для ветки ядра 2.6 предоставляет встроенную, NETKEY реализацию IpSec, так и собственную KLIPS.

CentOS 6.6 поддерживает только Openswan в основных пакетах.

Задача . Создать шифрованный туннель между CentOS 6.6 и Debian 7.8 Wheezy. GRE туннели + Openswan (type=transport)

    Openswan будет шифровать наш трафик в транспортном режиме(host-to-host), не вмешиваясь в маршрутизацию. Установим пакеты на обоих серверах yum install openswan aptitude install openswan

    На обоих концах туннеля настраиваем Правила iptables . Открыть 500 порт, по которому идет обмен сертификатам и ключами. iptables -A INPUT -p udp --dport 500 -j ACCEPT iptables -A INPUT -p tcp --dport 4500 -j ACCEPT iptables -A INPUT -p udp --dport 4500 -j ACCEPT # Более строго выпишем правила для IPSec IPT ="/sbin/iptables" $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 500 -m comment --comment "IpSec" -j ACCEPT $IPT -A INPUT -p tcp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT

    Подготовка конфигурационных файлов. Используемые файлы и директории / etc/ ipsec.d/ / etc/ ipsec.conf

    Проверка системы на правильность окружения для IPsec ipsec verify

    Добавить в конец файла sysctl.conf

    # IPSec Verify Compliant # Разрешить пересылку пакетов между интерфейсами для IPv4 net.ipv4.ip_forward = 1 # отключаем icmp redirect net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0

    Применим параметры ядра без перезагрузки

    Первым конфигурационным файлом является /etc/ipsec.conf. Задаем явно в разделе config setup config setup protostack =netkey plutoopts ="--perpeerlog" dumpdir =/ var/ run/ pluto/ nat_traversal =yes virtual_private =% v4:10.0.0.0/ 8 ,% v4:192.168.0.0/ 16 , % v4:172.16.0.0/ 12 ,% v4:25.0.0.0/ 8 ,% v6:fd00::/ 8 ,% v6:fe80::/ 10 oe =off #plutostderrlog=/dev/null

    В первую очередь вам необходимо сформировать ключи, используемые шлюзами для аутентификации. В Debian это ключ можно создать при инсталляции. Запускаем на обеих системах ipsec newhostkey, генерируя нужные нам ключи. ipsec newhostkey --output / etc/ ipsec.secrets ipsec showhostkey --left ipsec showhostkey --right

    Независимо от того, как вы сконфигурируете сервер, всегда рассматривайте вашу подсеть как расположенную «слева» (left), а подсеть, к которой доступ осуществляется дистанционно, сайт, как расположенный «справа» (right). Следующая конфигурация выполняется на сервере VPN на стороне Left. На другом сервере должен быть точно такие настройки для этого соединения. conn gagahost-to-miraxhost auto =start left =188 .x.x.x leftrsasigkey =0sN4vI6ooUyMyL ... right =91 .x.x.x rightrsasigkey =0sfAhuo4SQ0Qt ... type =transport scp / etc/ ipsec.conf admin@ 192.168.35.254:/ home/ admin/

Диагностика IPSec Openswan

Запуск сервиса и поиск возникающих проблем.

Openwan logs (pluto) : /var/log/auth.log /var/log/syslog /var/log/pluto/peer/a/b/c/d/a.b.c.d.log

Если на обоих серверах нет ошибок, то туннель должен сейчас подняться. Вы можете проверить туннель с помощью команды ping с следующим образом. Если туннель не поднят, то частная подсеть на стороне B не должна быть доступна со стороны А, т. е. команда ping не должна работать. После того, как туннель будет поднят, попробуйте команду ping для доступа к частной подсети на стороне B со стороны A. Это должно работать.

Кроме того, в таблице маршрутизации сервера должны появиться маршруты к частной подсети.

# ip route via dev eth0 src default via dev eth0

    Команды проверки состояний соединений: ipsec verify service ipsec status ip xfrm state list - управления SAD, возможности шире, чем у setkey ipsec addconn --checkconfig - проверка конфигурации ipsec auto --status - подробное состояние ip xfrm monitor

    Политики ipsec, согласно которым принимается решение какой трафик направлять в туннель ip xfrm pol show

    tcpdump Linux примеры использования запускаем для прослушки физического интерфейса на котором построен туннель (а не виртуального GRE). В другом окне например ping -ем удаленную серую сеть (например, ping 192.168.1.11). tcpdump должен показывать ESP пакеты. tcpdump -i em0 -n host 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x > 91 .x.x.81: ESP(spi =0x01540fdd,seq =0xa20) , length 92 ...

(Internet Security Association and Key Management Protocol (ISAKMP)) - Управление ключами и аутентификаторами защищенных соединений.

  • RFC 2409 (The Internet Key Exchange (IKE)) - Обмен ключами.
  • RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) - Нулевой алгоритм шифрования и его использование.
  • RFC 2411 (IP Security Document Roadmap) - Дальнейшее развитие стандарта.
  • RFC 2412 (The OAKLEY Key Determination Protocol) - Проверка соответствия ключа.

    • Архитектура IPsec

    Протоколы IPsec, в отличие от других хорошо известных протоколов SSL и TLS , работают на сетевом уровне (уровень 3 модели OSI). Это делает IPsec более гибким, так что он может использоваться для защиты любых протоколов, базирующихся на TCP и UDP . IPsec может использоваться для обеспечения безопасности между двумя IP-узлами , между двумя шлюзами безопасности или между IP-узлом и шлюзом безопасности. Протокол является "надстройкой" над IP-протоколом, и обрабатывает сформированные IP-пакеты описанным ниже способом. IPsec может обеспечивать целостность и/или конфиденциальность данных передаваемых по сети.

    IPsec использует следующие протоколы для выполнения различных функций:

    • Authentication Header (АН) обеспечивает целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и дополнительную функцию по предотвращению повторной передачи пакетов
    • Encapsulating Security Payload (ESP) может обеспечить конфиденциальность (шифрование) передаваемой информации, ограничение потока конфиденциального трафика. Кроме этого, он может обеспечить целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и дополнительную функцию по предотвращению повторной передачи пакетов (Всякий раз, когда применяется ESP, в обязательном порядке должен использоваться тот или иной набор данных услуг по обеспечению безопасности)
    • Security Association (SA) обеспечивают связку алгоритмов и данных, которые предоставляют параметры, необходимые для работы AH и/или ESP. Internet Security Association and Key Management Protocol (ISAKMP) обеспечивает основу для аутентификации и обмена ключами, проверки подлинности ключей.

    Security Association

    Концепция "Защищенного виртуального соединения" (SA, "Security Association") является фундаментальной в архитектуре IPsec. SA представляет собой симплексное соединение , которое формируется для транспортирования по нему соответствующего трафика. При реализации услуг безопасности формируется SA на основе использования протоколов AH или ESP (либо обоих одновременно). SA определен в соответствии с концепцией межтерминального соединения (point-to-point) и может функционировать в двух режимах: транспортный режим (РТР) и режим тунелирования (РТУ). Транспортный режим реализуется при SA между двумя IP-узлами. В режиме туннелирования SA формирует IP-туннель .

    Все SA хранятся в базе данных SADB (Security Associations Database) IPsec-модуля. Каждое SA имеет уникальный маркер, состоящий из трех элементов:

    • индекса параметра безопасности (SPI)
    • IP-адреса назначения
    • идентификатора протокола безопасности (ESP или AH)

    IPsec-модуль, имея эти три параметра, может отыскать в SADB запись о конкретном SA. В список компонентов SA входят:

    Последовательный номер 32-битовое значение, которое используется для формирования поля Sequence Number в заголовках АН и ESP. Переполнение счетчика порядкового номера Флаг, который сигнализирует о переполнении счетчика последовательного номера. Окно для подавления атак воспроизведения Используется для определения повторной передачи пакетов. Если значение в поле Sequence Number не попадает в заданный диапазон, то пакет уничтожается. Информация AH используемый алгоритм аутентификации, необходимые ключи, время жизни ключей и другие параметры. Информация ESP алгоритмы шифрования и аутентификации, необходимые ключи, параметры инициализации (например, IV), время жизни ключей и другие параметры Режим работы IPsec туннельный или транспортный MTU Максимальный размер пакета, который можно передать по виртуальному каналу без фрагментации.

    Так как защищенные виртуальные соединения(SA) являются симплексными , то для организации дуплексного канала, как минимум, нужны два SA. Помимо этого, каждый протокол (ESP/AH) должен иметь свою собственную SA для каждого направления, то есть, связка AH+ESP требует наличия четырех SA. Все эти данные располагаются в SADB.

    • AH: алгоритм аутентификации.
    • AH: секретный ключ для аутентификации
    • ESP: алгоритм шифрования.
    • ESP: секретный ключ шифрования.
    • ESP: использование аутентификации (да/нет).
    • Параметры для обмена ключами
    • Ограничения маршрутизации
    • IP политика фильтрации

    Помимо базы данных SADB, реализации IPsec поддерживают базу данных SPD (Security Policy Database- База данных политик безопасности). Запись в SPD состоит из набора значений полей IP-заголовка и полей заголовка протокола верхнего уровня. Эти поля называются селекторами. Селекторы используются для фильтрации исходящих пакетов, с целью поставить каждый пакет в соответствие с определенным SA. Когда формируется пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся SPD. Находятся соответствующие SA. Затем определяется SA (в случае, если оно имеется) для пакета и сопряженный с ней индекс параметров безопасности(SPI). После чего выполняются операции IPsec(операции протокола AH или ESP).

    Примеры селекторов, которые содержатся в SPD:

    • IP-адрес места назначения
    • IP-адрес отправителя
    • Протокол IPsec (AH, ESP или AH+ESP)
    • Порты отправителя и получателя

    Authentication Header

    Authentication Header format
    Offsets Octet 16 0 1 2 3
    Octet 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    0 0 Next Header Payload Len Reserved
    4 32
    8 64 Sequence Number
    C 96 Integrity Check Value (ICV)
    …
    … …
    Next Header (8 bits) Тип заголовка протокола, идущего после заголовка AH. По этому полю приемный IP-sec модуль узнает о защищаемом протоколе верхнего уровня. Значения этого поля для разных протоколов можно посмотреть в RFC 1700 . Payload Len (8 bits) Это поле определяет общий размер АН-заголовка в 32-битовых словах, минус 2. Несмотря на это, при использовании IPv6 длина заголовка должна быть кратна 8 байтам. Reserved (16 bits) Зарезервировано. Заполняется нулями. Security Parameters Index (32 bits) Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяет защищенное виртуальное соединение(SA) для данного пакета. Диапазон значений SPI 1...255 зарезервирован IANA. Sequence Number (32 bits) Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может отказаться от услуги по защите от повторной передачи пакетов, оно является обязательным и всегда присутствует в AH-заголовке. Передающий IPsec-модуль всегда использует это поле, но получатель может его и не обрабатывать. Integrity Check Value

    Протокол AH используется для аутентификации, то есть для подтверждения того, что мы связываемся именно с тем, с кем предполагаем, и что данные, которые мы получаем, не искажены при передаче.

    Обработка выходных IP-пакетов

    Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает AH-обработку, то он начинает обработку. В зависимости от режима (транспортный или режим туннелирования) он по-разному вставляет AH-заголовок в IP-пакет. В транспортном режиме AH-заголовок располагается после заголовка протокола IP и перед заголовками протоколов верхнего уровня (Обычно, TCP или UDP). В режиме туннелирования весь исходный IP-пакет обрамляется сначала заголовком AH, затем заголовком IP-протокола. Такой заголовок называется внешним, а заголовок исходного IP-пакета- внутренним. После этого передающий IPsec-модуль должен сгенерировать последовательный номер и записать его в поле Sequence Number . При установлении SA последовательный номер устанавливается в 0, и перед отправкой каждого IPsec-пакета увеличивается на единицу. Кроме того, происходит проверка- не зациклился ли счетчик. Если он достиг своего максимального значения, то он снова устанавливается в 0. Если используется услуга по предотвращению повторной передачи, то при достижении счетчика своего максимального значения, передающий IPsec-модуль переустанавливает SA. Таким образом обеспечивается защита от повторной посылки пакета - приемный IPsec-модуль будет проверять поле Sequence Number , и игнорировать повторно приходящие пакеты. Далее происходит вычисление контрольной суммы ICV. Надо заметить, что здесь контрольная сумма вычисляется с применением секретного ключа, без которого злоумышленник сможет заново вычислить хэш, но не зная ключа, не сможет сформировать правильную контрольную сумму. Конкретные алгоритмы, использующиеся для вычисления ICV, можно узнать из RFC 4305 . В настоящее время могут применяться, например, алгоритмы HMAC-SHA1-96 или AES-XCBC-MAC-96. Протокол АН вычисляет контрольную сумму(ICV) по следующим полям IPsec-пакета:

    • поля IP-заголовка, которые не были подвержены изменениям в процессе транслирования, или определены как наиболее важные
    • АН-заголовок (Поля: "Next Header", "Payload Len, "Reserved", "SPI", "Sequence Number", "Integrity Check Value". Поле "Integrity Check Value" устанавливается в 0 при вычислении ICV
    • данные протокола верхнего уровня
    Если поле может изменяться в процессе транспортировки, то его значение устанавливается в 0 перед вычислением ICV. Исключения составляют поля, которые могут изменяться, но значение которых можно предугадать при приеме. При вычислении ICV они не заполняются нулями. Примером изменяемого поля может служить поле контрольной суммы, примером изменяемого, но предопределенного может являться IP-адрес получателя. Более подробное описание того, какие поля как учитываются при вычислении ICV, можно найти в стандарте RFC 2402 .

    Обработка входных IP-пакетов

    После получения пакета, содержащего сообщение АН-протокола, приемный IPsec-модуль ищет соответствующее защищенное виртуальное соединение(SA) SADB (Security Associations Database), используя IP-адрес получателя, протокол безопасности (АН) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищенное виртуальное соединение(SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, т.е. на необходимость проверки поля Sequence Number . Если услуга используется, то поле проверяется. Для этого используется метод скользящего окна. Приемный IPsec-модуль формирует окно с шириной W. Левый край окна соответствует минимальному последовательному номеру(Sequence Number ) N правильно принятого пакета. Пакет с полем Sequence Number , в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем приемный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле "Integrity Check Value". Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным и принимается для дальнейшей IP-обработки. Если проверка дала отрицательный результат, то приемный пакет уничтожается.

    Encapsulating Security Payload format
    Offsets Octet 16 0 1 2 3
    Octet 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    0 0 Security Parameters Index (SPI)
    4 32 Sequence Number
    8 64 Payload data
    … …
    … …
    … … Padding (0-255 octets)
    … … Pad Length Next Header
    … … Integrity Check Value (ICV)
    …
    … …
    Security Parameters Index (32 bits) Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности(АН-протокол), однозначно определяет защищенное виртуальное соединение(SA) для данного пакета. Диапазон значений SPI 1...255 зарезервирован IANA для последующего использования. Sequence Number (32 bits) Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может и отказаться от услуги по защите от повторной передачи пакетов, оно всегда присутствует в AH-заголовке. Отправитель(передающий IPsec-модуль) должен всегда использовать это поле, но получатель может и не нуждаться в его обработке. Payload data (variable) Это поле содержит данные в соответствии с полем "Next Header". Это поле является обязательным и состоит из целого числа байтов. Если алгоритм, который используется для шифрования этого поля, требует данных для синхронизации криптопроцессов (например, вектор инициализации - "Initialization Vector"), то это поле может содержать эти данные в явном виде. Padding (0-255 octets) Дополнение. Необходимо, например, для алгоритмов, которые требуют, чтобы открытый текст был кратен некоторому числу байтов), например, размеру блока для блочного шифра. Pad Length (8 bits) Размер дополнения(в байтах). Next Header (8 bits) Это поле определяет тип данных, содержащихся в поле "Payload data". Integrity Check Value Контрольная сумма. Должна быть кратна 8-байтам для IPv6, и 4-байтам для IPv4.

    Обработка выходных IPsec-пакетов

    Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает ESP-обработку, то он начинает обработку. В зависимости от режима(транспортный или режим туннелирования) исходный IP-пакет обрабатывается по-разному. В транспортном режиме передающий IPsec-модуль осуществляет процедуру обрамления(инкапсуляции) протокола верхнего уровня(например, TCP или UDP), используя для этого ESP-заголовок и ESP-концевик, не затрагивая при этом заголовок исходного IP-пакета. В режиме туннелирования IP-пакет обрамляется ESP-заголовком и ESP-концевиком, после чего обрамляется внешним IP-заголовком. Далее производится шифрование- в транспортном режиме шифруется только сообщение протокола выше лежащего уровня (т.е. все, что находилось после IP-заголовка в исходном пакете), в режиме туннелирования- весь исходный IP-пакет. Передающий IPsec-модуль из записи о SA определяет алгоритм шифрования и секретный ключ. Стандарты IPsec разрешают использование алгоритмов шифрования triple-DES, AES и Blowfish. Так как размер открытого текста должен быть кратен определенному числу байт, например, размеру блока для блочных алгоритмов, перед шифрованием производится еще и необходимое дополнение шифруемого сообщения. Защифрованное сообщение помещается в поле Payload Data . В поле Pad Length помещается длина дополнения. Затем, как и в AH, вычисляется Sequence Number . После чего считается контрольная сумма(ICV). Контрольная сумма, в отличие от протокола AH, где при ее вычислении учитываются также и некоторые поля IP-заголовка, в ESP вычисляется только по полям ESP-пакета за вычетом поля ICV. Перед вычислением контрольной суммы оно заполняется нулями. Алгоритм вычисления ICV, как и в протоколе AH, передающий IPsec-модуль узнает из записи об SA, с которым связан обрабатываемый пакет.

    Обработка входных IPsec-пакетов

    После получения пакета, содержащего сообщение ESP-протокола, приемный IPsec-модуль ищет соответствующее защищенное виртуальное соединение(SA) в SADB (Security Associations Database), используя IP-адрес получателя, протокол безопасности (ESP) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищенное виртуальное соединение(SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, т.е. на необходимость проверки поля Sequence Number. Если услуга используется, то поле проверяется. Для этого, так же как и в AH, используется метод скользящего окна. Приемный IPsec-модуль формирует окно с шириной W. Левый край окна соответствует минимальному последовательному номеру(Sequence Number) N правильно принятого пакета. Пакет с полем Sequence Number, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем, если используется услуга аутентификации, приемный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле "Integrity Check Value". Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным. Если проверка дала отрицательный результат, то приемный пакет уничтожается. Далее производится расшифрование пакета. Приемный IPsec-модуль узнает из записи об SA, какой алгоритм шифрования используется и секретный ключ. Надо заметить, что проверка контрольной суммы и процедура расшифрования могут проводиться не только последовательно, но и параллельно. В последнем случае процедура проверки контрольной суммы должна закончиться раньше процедуры расшифрования, и если проверка ICV провалилась, процедура расшифрования также должна прекратиться. Это позволяет быстрее выявлять испорченные пакеты, что, в свою очередь, повышает уровень защиты от атак типа "отказ в обслуживании"(DOS-атаки). Далее расшифрованное сообщение в соответствии с полем Next Header передается для дальнейшей обработки.

    Использование

    Протокол IPsec используется, в основном, для организации VPN-туннелей . В этом случае протоколы ESP и AH работают в режиме туннелирования. Кроме того, настраивая политики безопасности определенным образом, протокол можно использовать для создания межсетевого экрана. Смысл межсетевого экрана заключается в том, что он контролирует и фильтрует проходящие через него пакеты в соответствии с заданными правилами. Устанавливается набор правил, и экран просматривает все проходящие через него пакеты. Если передаваемые пакеты попадают под действие этих правил, межсетевой экран обрабатывает их соответствующим образом. Например, он может отклонять определенные пакеты, тем самым прекращая небезопасные соединения. Настроив политику безопасности соответствующим образом, можно, например, запретить интернет-трафик. Для этого достаточно запретить отсылку пакетов, в которые вкладываются сообщения протоколов HTTP и HTTPS . IPsec можно применять и для защиты серверов - для этого отбрасываются все пакеты, кроме пакетов, необходимых для корректного выполнения функций сервера. Например, для Web-сервера можно блокировать весь трафик, за исключением соединений через 80-й порт протокола TCP, или через порт TCP 443 в случаях, когда применяется HTTPS .

    См. также

    Ссылки

    • Описание конфигурирования IPSec (cisco.com) (англ.)

    Сети VPN с IPsec обеспечивают гибкую и масштабируемую связь. Межфилиальные соединения могут обеспечивать безопасную, высокоскоростную и надёжную удалённую связь. При помощи VPN с IPsec информация из частной сети передаётся в защищённом режиме по публичной сети. Благодаря этому можно создать виртуальную сеть, а не использовать выделенное подключение на 2 уровне, как показано на рисунке. Для обеспечения конфиденциальности данных трафик шифруется.

    IPsec - это стандарт IETF, который определяет способ настройки сети VPN в защищённом режиме с помощью протокола IP.

    IPsec представляет собой структуру открытых стандартов, определяющую правила для организации защищённой связи. Протокол IPsec не связан с конкретными методами шифрования и аутентификации, алгоритмами обеспечения безопасности или технологией обмена ключами. Для обеспечения безопасной связи в протоколе IPsec используются существующие алгоритмы. IPsec позволяет создавать новые, более качественные алгоритмы, для разработки которых корректировать существующие стандарты IPsec не потребуется.

    IPsec функционирует на сетевом уровне, обеспечивая защиту и аутентификацию пакетов IP между взаимодействующими устройствами IPsec, которые также называются узлами (peer). IPsec позволяет защитить путь между парой шлюзов, парой компьютеров или между шлюзом и компьютером. В результате IPsec может защищать практически любой трафик приложений, так как можно реализовать защиту на уровнях с 4-го по 7-й.

    Во всех реализованных решениях протокола IPsec применяется незашифрованный заголовок 3-го уровня, поэтому никаких проблем с маршрутизацией не существует. IPsec функционирует поверх любых протоколов 2-го уровня, таких как Ethernet, ATM и Frame Relay.

    Ниже указаны основные особенности протокола IPsec:

    • IPsec - это структура открытых стандартов, независимая от алгоритмов.
    • IPsec обеспечивает конфиденциальность и целостность данных, а также аутентификацию источника.
    • IPsec действует как протокол сетевого уровня, защищая пакеты IP и проверяя их подлинность.

    • Защита IP

      • На рисунке показано, что сервисы безопасности IPsec выполняют следующие важные функции:


      • Конфиденциальность (шифрование) - в сети VPN частные данные передаются по публичной сети. Поэтому ключевой задачей является обеспечение конфиденциальности данных. Для этого перед передачей данных по сети выполняется шифрование данных. Шифрование - это процесс кодирования всех данных, отправляемых с одного компьютера на другой, в ту форму, которую может декодировать только принимающий компьютер. В случае перехвата сообщения злоумышленник (хакер) не сможет его прочесть. IPsec предоставляет расширенные функции безопасности (например, криптостойкие алгоритмы шифрования).
      • Целостность данных - Получатель может убедиться, что данные были нормально переданы через Интернет и никак не были изменены. Важно не только обеспечить шифрование данных в публичной сети, но и убедиться, что они не были изменены в пути. В IPsec предусмотрен механизм проверки отсутствия изменений в шифрованной части пакета, во всём заголовке или в теле данных пакета. IPsec гарантирует целостность данных с помощью контрольных сумм (применяется простая проверка с использованием избыточности). При обнаружении искажений пакет удаляется.
      • Аутентификация - позволяет проверить, кто был источником отправленных данных. Это необходимо для защиты от атак, использующих спуфинг (подмену отправителя). Аутентификация позволяет гарантировать установление подключения к нужному партнеру по связи. Получатель может проверять подлинность источника пакета, сертифицируя источник информации. В IPsec используется технология обмена ключами по Интернету (Internet Key Exchange, IKE) для проверки подлинности пользователей и устройств, которые могут устанавливать связь независимо друг от друга. В IKE применяется аутентификация различного типа (в частности, используются имя пользователя и пароль, одноразовый пароль, биометрия, предварительно распространяемый общий ключ (Pre-Shared Key, PSK) и цифровые сертификаты).
      • Защита от повторов - позволяет обнаруживать и отклонять повторные пакеты, а также предотвращать спуфинг. Благодаря защите от повторов можно убедиться, что пакет является уникальным и не дублированным. Пакеты IPsec защищаются путем сравнения порядкового номера полученных пакетов со «скользящим» окном на узле назначения или шлюзе безопасности. Пакет с порядковым номером, который следует перед скользящим окном, считается задержанным или дублированным. Задержанные и дублированные пакеты удаляются.

      Сокращение CIA во многих случаях позволяет вспомнить три эти функции: конфиденциальность(confidentiality), целостность (integrity), и проверка подлинности (authentication).

    • Структура протокола IPsec

      • Конфиденциальность

      Конфиденциальность трафика VPN поддерживается с помощью шифрования. Открытые (незашифрованные) данные, передаваемые через Интернет, могут быть перехвачены и прочитаны. Для сохранения приватности данных используется шифрование. Благодаря цифровому шифрованию данных они остаются нечитаемыми до тех пор, пока не будут расшифрованы авторизованным получателем.

      Для обеспечения зашифрованного режима связи и отправитель, и получатель должны знать правила, используемые для преобразования исходного сообщения в закодированную форму. Правила основаны на алгоритмах и соответствующих ключах. В контексте шифрования алгоритм представляет собой математическую последовательность действий, в которой сообщение, текст, цифры или все они сочетаются со строкой цифр, называемой ключом. Выходные данные предстают в виде нечитаемой зашифрованной строки. Алгоритм шифрования также определяет способ расшифровки зашифрованного сообщения. Без правильного ключа дешифровать данные практически невозможно.


      • На рисунке видно, что Гейл хочет выполнить электронный перевод денежных средств через Интернет к Джереми. На локальной стороне документ объединяется с ключом и подвергается процедуре шифрования. Выходные данные представляют собой шифртекст. Затем этот шифртекст посылается через Интернет. На удалённой стороне сообщение снова объединяется с ключом и пропускается через алгоритм шифрования в обратном направлении. Выходные данные представляют собой исходный финансовый документ.

      Конфиденциальность достигается шифрованием трафика при передаче через VPN. Степень безопасности зависит от длины ключа в алгоритме шифрования и сложности самого алгоритма. Если хакер попытается взломать ключ посредством атаки методом последовательного перебора, то количество вариантов для перебора будет зависеть от длины ключа. Время обработки всех возможных вариантов зависит от вычислительной мощности компьютера злоумышленника. Поэтому чем короче ключ, тем проще его взломать. Например, если для взлома 64-битового ключа относительно мощному компьютеру понадобится приблизительно один год, то для взлома 128-битового ключа тому же компьютеру может понадобиться от 10 до 19 лет.

    Алгоритмы шифрования IPsec

    Степень безопасности зависит от длины ключа в алгоритме шифрования. По мере увеличения длины ключа вероятность взлома шифра уменьшается. Однако, чем длиннее ключ, тем больше ресурсов процессора будет требоваться при шифровании и расшифровывании данных.

    Алгоритмы DES и 3DES больше не считаются надёжными, поэтому для шифрования в протоколе IPsec рекомендуется использовать AES. Наивысший уровень безопасности для шифрования сетей VPN между устройствами Cisco с помощью протокола IPsec обеспечивается 256-битовым вариантом AES. Кроме того, с учетом взлома 512- и 768-битовых ключей Ривеста-Шамира-Эдльмана (RSA) компания Cisco рекомендует использовать 2048-битовые ключи в варианте RSA (если он применяется на этапе аутентификации IKE).

    Симметричное шифрование

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

    Например, отправитель создаёт кодированное сообщение, где каждая буква меняется на букву, следующую через две буквы ниже в алфавите (то есть A становится C, В становится D и т. д.). В этом случае слово SECRET превращается в UGETGV. Отправитель уже сообщил получателю, что секретный ключ - это смещение на 2. Когда получатель получает сообщение UGETGV, его компьютер раскодирует сообщение путем обратного смещения на две буквы и получает слово SECRET. Любой другой пользователь, смотрящий на это сообщение, видит его в зашифрованном виде. Чтобы такое сообщение не выглядело абракадаброй, необходимо знать секретный ключ.

    Ниже указаны особенности симметричных алгоритмов:

    • используется криптография на основе симметричных ключей;
    • при шифровании и расшифровке используется один и тот же ключ;
    • обычно используется для шифрования содержимого сообщения.
    • Примеры: DES, 3DES и AES

    Каким образом шифрующее и расшифровывающее устройства могут получить информацию об общем секретном ключе? Общие секретные ключи администраторам устройств конечно можно было бы отправлять по электронной почте, по обычной или курьерской почте. Но другим, более надёжным способом является асимметричное шифрование.

    Асимметричное шифрование

    При асимметричном шифровании для шифрования и расшифровки используются разные ключи. Знание одного из ключей не позволяет хакеру вычислить второй ключ и декодировать информацию. Один ключ служит для зашифровывания сообщения, второй для его расшифровывания (см. рисунок 2). Выполнять операцию шифрования и расшифровки с помощью одного и того же ключа нельзя.

    Одним из вариантов асимметричного шифрования является шифрование открытым ключом, где применяется сочетание секретного и открытого (публичного) ключей. Получатель предоставляет открытый ключ любому отправителю, с которым данному получателю нужно общаться. Для зашифровывания сообщения отправитель использует секретный ключ, который объединяется с открытым ключом получателя. Кроме того, отправитель должен сообщить свой открытый ключ получателю. Для расшифровки сообщения получатель будет использовать открытый ключ отправителя вместе со своим собственным секретным ключом.

    Ниже указаны особенности асимметричных алгоритмов:

    • используется криптография с открытым ключом;
    • при шифровании и расшифровке используются разные ключи;
    • обычно применяется при управлении цифровыми сертификатами и ключами.

    Целостность и алгоритмы хеширования

    Для обеспечения целостности и проверки подлинности трафика сети VPN применяются алгоритмы хеширования. Целостность данных и проверка подлинности обеспечиваются хеш-кодами, которые гарантируют отсутствие искажений передаваемых сообщений неавторизованными лицами. Хеш-код, также называемый дайджестом сообщения, представляет собой число, который создаётся из строки текста. Хеш-код имеет меньший размер, чем сам текст. Он создаётся с помощью формулы таким образом, что получение такого же значения хеш-кода из другого текста крайне маловероятно.

    Исходный отправитель создаёт хеш-код сообщения и отправляет его вместе с самим сообщением. Получатель анализирует сообщение и хеш-код, создаёт другой хеш-код на основе полученных сообщений и сравнивает оба хеш-кода. Если они совпадают, то получатель может быть с достаточным основанием уверен в целостности исходного сообщения.

    На рисунке показано, что Гейл отправил Алексу электронный денежный перевод в размере 100 долл. США. Джереми перехватил и изменил данный перевод таким образом, чтобы показать, что он является получателем, а сумма перевода составляет 1000 долл. США. В этом случае, если использовался алгоритм целостности данных, то хеш-коды не совпадут друг с другом, и транзакция окажется недействительной.

    Данные VPN передаются через Интернет общего доступа. Как показано на рисунке, существует вероятность перехвата и изменения этих данных. Для защиты от этой угрозы на компьютерах в сообщение могут добавляться хеш-коды. Если переданный хеш-код совпадает с полученным хеш-кодом, это означает, что обеспечена целостность сообщения. Однако если хеш-коды не совпадают, то сообщение было изменено.

    Для проверки целостности и подлинности сообщения в сетях VPN используется код аутентификации без использования каких-либо дополнительных механизмов.

    Код аутентификации сообщений на основе хешей (Hash-based Message Authentication Code, HMAC) - это механизм аутентификации сообщений с помощью функций хеширования. HMAC с обменом ключами представляет собой алгоритм целостности данных, гарантирующий целостность сообщения. HMAC имеет два параметра: вводимое сообщение и секретный ключ, известный только автору сообщения и предполагаемым получателям. Отправитель сообщения использует функцию HMAC для создания значения (кода аутентификации сообщения), формируемого путем переработки секретного ключа и вводимого сообщения. Код аутентификации сообщения отправляется вместе с сообщением. Получатель вычисляет код аутентификации сообщения в полученном сообщении с помощью того же ключа и функции HMAC, которые использовал отправитель. Затем получатель сравнивает вычисленный результат с полученным кодом аутентификации сообщения. Если оба значения совпадают, это означает, что получено правильное сообщение, а получатель может быть уверен в том, что отправитель является членом сообщества пользователей, применяющих данный общий ключ. Криптографическая стойкость алгоритма HMAC зависит от криптографической стойкости базовой функции хеширования, от размера и качества ключа, а также длины результата хеш-функции (в битах).

    Существуют два наиболее распространённых алгоритма HMAC:

    • MD5 - используется 128-битовый общий секретный ключ. Сообщение произвольной длины и 128-битовый общий секретный ключ объединяются друг с другом и обрабатываются алгоритмом хеширования HMAC-MD5. В результате создаётся 128-битовый хеш-код. Хеш-код добавляется к исходному сообщению и перенаправляется на удалённую сторону.
    • SHA - в SHA-1 используется 160-битовый общий секретный ключ. Сообщение переменной длины и 160-битовый общий секретный ключ объединяются друг с другом и обрабатываются алгоритмом хеширования HMAC-SHA1. В результате создаётся 160-битовый хеш-код. Хеш-код добавляется к исходному сообщению и перенаправляется на удалённую сторону.

    Примечание . В ОС Cisco IOS также поддерживаются 256-, 384- и 512-битовые варианты SHA.

    Аутентификация IPsec

    В сетях IPsec VPN поддерживается функция аутентификации. Если ваши партнеры по бизнесу находятся от вас на большом расстоянии, то важно знать, с кем вы говорите по телефону, кто отправляет вам электронное сообщение или факс. Это же справедливо и для сетей VPN. Как указано на рисунке, подлинность устройства на другом конце туннеля VPN должна быть проверена, прежде чем можно будет считать, что канал связи является защищённым. Существуют два метода аутентификации собеседника:

    • PSK - секретный ключ, заранее известный двум пользователям, которые общаются по защищённому каналу. В методе предварительно распространённых общих ключей (PSK) используются криптографические алгоритмы с симметричным ключом. Ключ PSK вручную вводится на каждом из взаимодействующих узлов (пиров) и используется для аутентификации друг друга. На каждой стороне ключ PSK объединяется с другой информацией, что позволяет сформировать ключ аутентификации.

    В алгоритме IPsec для аутентификации в контексте IKE используется алгоритм RSA (криптографическая система с открытым ключом). В RSA применяется схема цифровой подписи, благодаря которой каждое устройство прикрепляет цифровую подпись к набору данных и передаёт его другому пользователю. Для создания цифрового сертификата с уникальным идентификатором, назначаемого каждому равноправному узлу для аутентификации, в алгоритме подписывания RSA используется центр сертификации (CA). Сам цифровой сертификат идентификации похож на ключ PSK, но обеспечивает гораздо более высокий уровень безопасности. Каждые инициатор и ответчик в сеансе IKE, использующие подписи RSA, отправляют собственное значение идентификатора, свой цифровой сертификат идентификации и значение подписи RSA, состоящее из нескольких значений IKE. Для шифрования всех этих данных применяется согласованный IKE способ шифрования (например AES).

    Ещё одним методом аутентификации является алгоритм цифровой подписи (Digital Signature Algorithm, DSA).

    Структура протокола IPsec

    Как указано выше, набор протоколов IPsec описывает способ обмена сообщениями для защиты сеансов связи, но он основан на применении существующих алгоритмов.

    На рисунке 1 показаны два основных протокола IPsec:

    • Аутентифицирующий заголовок (Authentication Header, AH) - AH представляет собой специальный протокол, применяемый в тех случаях, когда обеспечение конфиденциальности не требуется или запрещено. Он обеспечивает аутентификацию и целостность данных для пакетов IP, передаваемых между двумя системами. Однако AH не обеспечивает конфиденциальность (шифрования) данных в пакетах. Весь текст передаётся в открытом виде (без шифрования). Если используется только протокол AH (а другие механизмы не применяются), то он обеспечивает слабую защиту.
    • Протокол шифрования полезной нагрузки (Encapsulating Security Payload, ESP) - это протокол безопасности, который обеспечивает конфиденциальность и аутентификацию путем шифрования пакета IP. В процессе шифрования пакета IP скрываются данные и идентификаторы источника и назначения. В ESP проверяется подлинность внутреннего пакета IP и заголовка ESP. Аутентификация обеспечивает проверку подлинности источника данных и целостность данных. Хотя процедуры шифрования и аутентификации не являются обязательными в ESP, необходимо выбрать как минимум одну из них.

    На рис. 2 показаны компоненты настройки IPsec. Существует четыре основных компоновочных блока структуры IPsec, которые необходимо выбрать.


    • Конфиденциальность (если выбран вариант использования IPsec с протоколом ESP) - выбранный алгоритм шифрования должен наилучшим образом обеспечивать требуемый уровень безопасности: DES, 3DES или AES. Настоятельно рекомендуется применять AES (наивысший уровень безопасности обеспечивает схема AES-GCM).
    • Целостность - гарантирует, что содержимое не было изменено в процессе передачи. Для выполнения данной функции применяются алгоритмы хеширования. Можно выбрать MD5 и SHA.
    • Аутентификация - определяет способ проверки подлинности устройств на обоих концах туннеля VPN. Доступные варианты: PSK или RSA.
    • Группа алгоритмов DH - определяет способ генерации общего секретного ключа между узлами. Существует несколько вариантов, но DH24 обеспечивает наивысший уровень безопасности.

    Благодаря сочетанию этих компоновочных блоков обеспечиваются конфиденциальность, целостность и аутентификация сетей VPN на IPsec.

    Примечание . В этом разделе приводится общее описание протокола IPsec, которое позволяет понять, каким образом IPsec защищает туннели VPN. Процесс настройки сетей IPsec VPN в рамках этого курса не рассматривается.

    IPSec опирается на ряд технологических решений и методов шифрования, но действие IPSec в общем можно представить в виде следующих главных шагов:

      Шаг 1. Начало процесса IPSec . Трафик, которому требуется шифрование в соответствии с политикой защиты IPSec, согласованной сторонами IPSec, начинает IКЕ-процесс.

      Шаг 2. Первая фаза IKE . IKE-процесс выполняет аутентификацию сторон IPSec и ведет переговоры о параметрах ассоциаций защиты IKE, в результате чего создается защищенный канал для ведения переговоров о параметрах ассоциаций защиты IPSec в ходе второй фазы IKE.

      Шаг 3. Вторая фаза IKE . IKE-процесс ведет переговоры о параметрах ассоциации защиты IPSec и устанавливает соответствующие ассоциации защиты IPSec для устройств сообщающихся сторон.

      Шаг 4. Передача данных. Происходит обмен данными между сообщающимися сторонами IPSec, который основывается на параметрах IPSec и ключах, хранимых в базе данных ассоциаций защиты.

      Шаг 5. Завершение работы туннеля IPSec . Ассоциации защиты IPSec завершают свою работу либо в результате их удаления, либо по причине превышения предельного времени их существования.

    Режимы работы ipSec

    Существует два режима работы IPSec: транспортный и туннельный.

    В транспортном режиме шифруется только информативная часть IP-пакета. Маршрутизация не затрагивается, так как заголовок IP-пакета не изменяется. Транспортный режим, как правило, используется для установления соединения между хостами.

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

    Согласование преобразований IPSec

    В ходе работы протокола IKE ведутся переговоры о преобразованиях IPSec (алгоритмах защиты IPSec). Преобразования IPSec и связанные с ними алгоритмы шифрования являются следующими:

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

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

      Стандарт DES (Data Encription Standard -- стандарт шифрования данных). Алгоритм шифрования и дешифрования данных пакетов. Алгоритм DES используется как в рамках IPSec, так и IKE. Для алгоритма DES используется 56-битовый ключ, что означает не только более высокое потребление вычислительных ресурсов, но и более надежное шифрование. Алгоритм DES является симметричным алгоритмом шифрования, для которого требуются идентичные секретные ключи шифрования в устройствах каждой из сообщающихся сторон IPSec. Для создания симметричных ключей применяется алгоритм Диффи-Хеллмана. IKE и IPSec используют алгоритм DES для шифрования сообщений.

      "Тройной" DES (3DES). Вариант DES, основанный на использовании трех итераций стандартного DES с тремя разными ключами, что практически утраивает стойкость DES. Алгоритм 3DES используется в рамках IPSec для шифрования и дешифрования потока данных. Данный алгоритм использует 168-битовый ключ, что гарантирует высокую надежность шифрования. IKE и IPSec используют алгоритм 3DES для шифрования сообщений.

      AES (advanced encryption standard ). Протокол AES использует алгоритм шифрования Rine Dale4, который обеспечивает существенно более надежное шифрование. Многие криптографы считают, что AES вообще невозможно взломать. Сейчас AES яв­ляется федеральным стандартом обработки информации. Он определен как алгоритм шифрования для использования правительственными организациями США для защи­ты важных, но несекретных сведений. Проблема, связанная с AES, состоит в том, что для его реализации требуется большая вычислительная мощность по сравнению с аналогичными протоколами.

    При преобразовании IPSec используется также два стандартных алгоритма хэширования, обеспечивающих аутентификацию данных.

      Алгоритм MD5 (Message Digest 5). Алгоритм хэширования, применяемый для аутентификации пакетов данных. В продуктах Cisco используется вычисляемый с помощью MD5 код НМАС (Hashed Message Authentication Code -- хэшированный код аутентичности сообщения)- вариант кода аутентичности сообщения, которому обеспечивается дополнительная защита с помощью хэширования. Хэширование представляет собой процесс одностороннего (т.е. необратимого) шифрования, в результате которого для поступающего на вход сообщения произвольной длины получается вывод фиксированной длины. IKE, АН и ESP используют MD5 для аутентификации данных.

      Алгоритм SHA-1 (Secure Hash Algorithm-1 -- защищенный алгоритм хэширования 1). Алгоритм хэширования, используемый для аутентификации пакетов данных. В продуктах Cisco применяется вариант кода НМАС, вычисляемый с помощью SHA-1. IKЕ, АН и ESP используют SHA-1 для аутентификации данных.

    В рамках протокола IKE симметричные ключи создаются с помощью алгоритма Диффи-Хеллмана, использующего DES, 3DES, MD5 и SHA. Протокол Диффи-Хеллмана является криптографическим протоколом, основанным на применении открытых ключей. Он позволяет двум сторонам согласовать общий секретный ключ, не имея достаточно надежного канала связи. Общие секретные ключи требуются для алгоритмов DES и НМАС. Алгоритм Диффи-Хеллмана используется в рамках IKE для создания сеансовых ключей. Группы Diffie-Hellman (DH) – определяют «силу» ключа шифрования, который используется в процедуре обмена ключами. Чем выше номер группы, тем «сильнее» и безопаснее ключ. Однако следует учитывать тот факт, что при увеличении номер группы DH увеличивается «сила» и уровень безопасности ключа, однако одновременно увеличивается нагрузка на центральный процессор, так как для генерации более «сильного» ключа необходимо больше времени и ресурсов.

    Устройства WatchGuard поддерживают DH группы 1, 2 и 5:

      DH group 1: 768-bit key

      DH group 2: 1024-bit key

      DH group 5: 1536-bit key

    Оба устройства, которые обмениваются данными через VPN должны использовать одну и ту же группу DH. Группа DH, которая будет использоваться устройствами, выбирается во время IPSec Phase 1 процедуры.