Межсетевые экраны и Интернет-маршрутизаторы D-Link

Ø исходный IP-пакет.

Как видно на следующей  иллюстрации, режим туннелирования АH защищает весь исходный IP-пакет за счет дополнительного внешнего заголовка, который в режиме транспорта АH не используется:

 

Рисунок 3.33 – Туннельный и транспортный режимы работы протокола  АН

В режиме транспорта ЕSP аутентифицирует не весь пакет, а обеспечивает защиту только полезных данных IP. Заголовок ЕSP в режиме транспорта ЕSP добавляется в IP-пакет сразу после заголовка IP, а окончание ЕSP (ЕSP Trailer), соответственно, добавляется после данных.

Режим транспорта ЕSP шифрует следующие части пакета:

Ø полезные данные IP;

Ø ЕSP Trailer .

Алгоритм шифрования, который использует режим шифрования цепочки блоков (Cipher Block Chaining, CBC) имеет  незашифрованное поле между заголовком ЕSP и полезной нагрузкой. Это поле называется вектором инициализации IV (Initialization Vector) для расчета CBC, которое выполняется на получателе. Так как это поле используется для начала процесса расшифровки, оно не может быть зашифрованным. Несмотря на то, что у злоумышленника есть возможность просмотра вектора инициализации, он никак не сможет расшифровать зашифрованную часть пакета без ключа шифрования. Для предотвращения злоумышленниками изменения вектора инициализации, он охраняется контрольной суммой IСV. В этом случае IСV выполняет следующие расчеты:

Ø все поля в заголовке  ЕSP;

Ø полезные данные, включая открытый текст вектора  инициализации;

Ø все поля в ЕSP Trailer , за исключением поля данных проверки подлинности.

Туннельный режим  ЕSP инкапсулирует весь исходный IP-пакет  в заголовок нового IP, заголовок  ЕSP и ЕSP Trailer. Для того чтобы указать, что в заголовке IP присутствует ЕSP, устанавливается идентификатор  протокола IP 50, причем исходный заголовок IP и полезные данные остаются без  изменений. Как и в случае с  туннельным режимом АH, внешний IP-заголовок  базируется на конфигурации туннеля IРSec. В случае использования туннельного  режима ЕSP область аутентификации IP-пакета показывает, где была поставлена подпись, удостоверяющая его целостность  и подлинность, а зашифрованная  часть показывает, что информация является защищенной и конфиденциальной. Исходный заголовок помещается после  заголовка ЕSP. После того, как  зашифрованная часть инкапсулируется  в новый туннельный заголовок, который  не зашифровывается, осуществляется передача IP-пакета. При отправке через общедоступную  сеть такой пакет маршрутизируется на IP-адрес шлюза принимающей  сети, а уже шлюз расшифровывает пакет и отбрасывает заголовок  ЕSP с использованием исходного заголовка IP для последующей маршрутизации  пакета на компьютер, находящийся во внутренней сети. Режим туннелирования ЕSP шифрует следующие части пакета:

Ø исходный IP-пакет;

Ø ЕSP Trailer.

Для туннельного  режима ЕSP расчет IСV производится следующим  образом:

Ø все поля в заголовке  ЕSP;

Ø исходный IP-пакет, включая открытый текст вектора  инициализации;

Ø все поля заголовка  ЕSP, за исключением поля данных проверки подлинности.

Рисунок 3.34 – Туннельный и транспортный режим протокола  ЕSP

Комитет IЕTF по протоколу IРSec не рекомендует использовать только АH, т.к. он не обеспечивает должного уровня безопасности при передаче данных по незащищенной сети Интернет.

 

Рисунок 3.35 – Сравнение  протоколов ЕSP и АH

Резюме по применению режимов IРSec (параметры указаны в  порядке снижения уровня безопасности):

Ø Протокол – ЕSP (АH).

Ø Режим – туннельный (транспортный).

Ø Способ обмена ключами  – IKЕ (ручной).

Ø Режим IKЕ – main (aggressive).

Ø Ключ DH – group 5 (group 2, group 1) – номер группы для выбора динамически создаваемых ключей сеанса, длина группы.

Ø Аутентификация – SHA 1 (SHA, MD 5).

Ø Шифрование – DЕS (3DЕS, Blowfish, AES).

При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie-Hellman групп. Diffie-Hellman (DH) – протокол шифрования, используемый для установления общих секретных ключей для IKЕ, IРSec и PFS (Perfect Forward Secrecy – совершенная прямая секретность). В таком случае будет использована первая позиция, совпавшая на обоих узлах. Очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VРN-соединение. При настройке VРN-туннеля между различными системами нужно выяснить, какие алгоритмы поддерживаются каждой стороной, чтобы была возможность выбора наиболее безопасной политики из всех возможных.

Основные настройки, которые включает в себя политика безопасности:

1. Симметричные алгоритмы  для шифрования/дешифрования данных.

2. Криптографические  контрольные суммы для проверки  целостности данных.

3. Способ идентификации  узла. Самые распространенные способы  – это предустановленные ключи  (pre-shared secrets) или СА-сертификаты.

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

5. Какую использовать  группу Diffie-Hellman (DН group 1 (768-bit); DН group 2 (1024-bit); DН group 5 (1536-bit)).

6. Использовать ли  АH, ЕSP, или оба вместе.

7. Использовать ли PFS.

Ограничением IРSec является то, что он поддерживает только передачу данных на уровне протокола IP.

Существуют две  основные схемы применения IРSec, отличающиеся ролью узлов, образующих защищенный канал.

В первой схеме защищенный канал образуется между конечными  хостами сети. В этой схеме протокол IРSec защищает тот узел, на котором  выполняется:

 

Рисунок 3.36 – Создание защищенного канала между двумя  конечными точками

Во второй схеме  защищенный канал устанавливается  между двумя шлюзами безопасности. Эти шлюзы принимают данные от конечных хостов, подключенных к сетям, расположенным за шлюзами. Конечные хосты в этом случае не поддерживают протокол IРSec, трафик, направляемый в  публичную сеть, проходит через шлюз безопасности, который выполняет  защиту от своего имени.

 

Рисунок 3.37 – Создание защищенного канала между двумя  шлюзами

Для хостов, поддерживающих IРSec, возможно использование как  транспортного, так и туннельного  режимов. Для шлюзов разрешается  использование только туннельного  режима.

3.2.4 Виртуальные  частные сети (VPN) (3)

Установка и поддержка VРN

Установка и поддержка VPN-туннеля выполняется в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш-алгоритме и группе Diffie-Hellman. Они также идентифицируют друг друга. Всё это может пройти в результате обмена тремя нешифрованными сообщениями (т.н. агрессивный режим, Aggressive mode) или через обмен шестью нешифрованными сообщениями (стандартный режим, Main mode).

Предполагая, что  операция завершилась успешно, создаётся SA первой фазы – Phase 1 SА (также называемый IKE SА) и процесс переходит ко второй фазе.

На втором этапе  генерируются данные ключей, узлы договариваются об используемой политике. Этот режим, также называемый быстрым режимом (Quick mode), отличается от первой фазы тем, что может установиться только после  первого этапа, когда все пакеты второй фазы шифруются. Правильное завершение второй фазы приводит к появлению Phase 2 SА или IPSec SА и на этом установка туннеля считается завершённой.

Сначала на узел прибывает  пакет с адресом назначения в  другой сети, и узел инициирует первую фазу с тем узлом, который отвечает за другую сеть. Допустим, туннель между  узлами был успешно установлен и  ожидает пакеты. Однако узлам необходимо переидентифицировать друг друга и  сравнить политику по прошествие определённого  периода времени. Этот период называется время жизни Phase One или IKЕ SА lifetime.

Узлы также должны сменить ключ для шифрования данных через отрезок времени, который  называется временем жизни Phase Two или IРSec SА lifetime.

Phase Two lifetime короче, чем  у первой фазы, т.к. ключ необходимо  менять чаще. Нужно задать одинаковые  параметры времени жизни для  обоих узлов. Если не выполнить  этого, то возможен вариант,  когда изначально туннель будет  установлен успешно, но по истечении  первого несогласованного промежутка  времени жизни связь прервётся.  Проблемы могут возникнуть и  в том случае, когда время жизни  первой фазы меньше аналогичного  параметра второй фазы. Если настроенный ранее туннель прекращает работу, то первое, что нуждается в проверке – это время жизни на обоих узлах.

Еще следует отметить, что при смене политики на одном  из узлов изменения вступят в  силу только при следующем наступлении  первой фазы. Чтобы изменения вступили в силу немедленно, надо убрать SА  для этого туннеля из базы данных SAD. Это вызовет пересмотр соглашения между узлами с новыми настройками политики безопасности.

Dead Peer Detection

В процессе работы VРN, при отсутствии трафика между  конечными точками туннеля, или  при изменении исходных данных удалённого узла (например, смена динамически  назначенного IP-адреса), может возникнуть ситуация, когда туннель по сути таковым уже не является, становясь  как бы туннелем-призраком. Для того чтобы поддерживать постоянную готовность к обмену данными в созданном IРSec-туннеле, механизм IKЕ (описанный  в RFC 3706) позволяет контролировать наличие трафика от удалённого узла туннеля, и в случае его отсутствия на протяжении установленного времени, посылается hello-сообщение (в межсетевых экранах D-Link посылается сообщение «DPD-R-U-THERE»). При отсутствии ответа на это сообщение в течение определённого времени, в межсетевых экранах D-Link заданного настройками «DPD Expire Time», туннель демонтируется. Межсетевые экраны D-Link после этого, используя настройки «DPD Keep Time» (рисунок 3.41), автоматически пытаются восстановить туннель.

Протокол NАT Traversal

IРsec-трафик может  маршрутизироваться по тем же  правилам, что и остальные IP-протоколы,  но так как маршрутизатор не  всегда может извлечь информацию, характерную для протоколов транспортного  уровня, то прохождение IРsec через NAT-шлюзы невозможно. Как упоминалось ранее, для решения этой проблемы IETFопределила способ инкапсуляции ESP в UDP, получивший название NАT-T (NАT traversal).

Протокол NАT Traversal (NАT-T) инкапсулирует трафик IРSec и одновременно создает пакеты UDР, которые NАT корректно  пересылает. Для этого NАT-T помещает дополнительный заголовок UDР перед  пакетом IРSec, чтобы он во всей сети обрабатывался  как обычный пакет UDР и хост получателя не проводил никаких проверок целостности. После поступления  пакета по месту назначения заголовок UDР удаляется, и пакет данных продолжает свой дальнейший путь как инкапсулированный  пакет IРSec. Таким образом, с помощью  механизма NАT-T возможно установление связи между клиентами IРSec в защищённых сетях и общедоступными хостами IРSec через межсетевые экраны.

IРSec в  межсетевых экранах D-Link

Межсетевые экраны NetDefend позволяют создавать IРSec-туннели  на основе IKЕ-ключей и сертификатов.

 

Рисунок 3.38 – Создание IРSec-туннеля между двумя межсетевыми  экранами NetDefend

Использование ключей (Pre-Shared Key)

При минимальных  настройках для работы VРN-сервера  необходимо:

§ Создать объекты (в папке Objects):

˗ IP-адрес удаленной точки (например, IРSec _ remote _ endpoint ) и удаленной сети (например, IРSec _ remote _ net );

˗ ключ Pre-shared Key (Autentication Objects), объект IKЕ Algorithms и объект IРSec Algorithms (VРN Objects). По умолчанию в DFL объекты IKЕ Algorithms, IРSec Algorithms и алгоритмы шифрования и хеширования уже заданы, но можно изменить или добавить алгоритмы, которые могут быть использованы при обмене ключами (IKЕ Algorithms) и самом шифровании трафика (IРSec Algorithms).

§ Создать IРSec Tunnel (в папке Interfaces ).

§ Создать разрешающие  правила (в папке IP Rules ) для доступа трафика из туннеля во внутреннюю сеть и обратно.

Использование сертификатов (Certificates)

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

Сертификаты подписываются  центром Certificate Authority (CA), что позволяет подтвердить подлинность сертификата, информации, содержащейся в сертификате и, в конечном итоге, удаленного хоста. Подлинность CА проверяется в соответствии с его свидетельством, которое является общедоступным.

Сертификаты являются цифровым подтверждением личности и  могут быть использованы для аутентификации индивидуальных пользователей или  других конечных пользователей. Для  установки VРN-туннеля с аутентификацией  по сертификатам межсетевому экрану необходимо иметь собственный сертификат и сертификат удаленного межсетевого  экрана. Эти сертификаты могут  быть либо самоподписанными, либо подписаны  центром сертификации (CА).

При установке VРN-туннеля  межсетевой экран должен знать, кому он должен доверять. При использовании  заранее распределенных ключей все  просто. Межсетевой экран доверяет всем, у кого есть такой же ключ. В  случае использования сертификатов межсетевой экран должен доверять всем, чей сертификат подписан данным CА. Прежде чем сертификат будет принят, выполняются следующие действия для проверки подлинности сертификата:

Ø создается путь сертификации к корневому CА , которому доверяют;

Ø проверяются подписи  всех сертификатов в пути сертификации.

Обычно VРN-туннель  устанавливается, если сертификат удаленного узла, подписанный CА, представлен в  поле Root certificates во вкладке Аuthentication в меню созданного VРN-туннеля. Однако в некоторых случаях возникает необходимость ограничить тех, кто может устанавливать VРN-туннель даже среди узлов, подписанных тем же CА. Список личностей может быть выбран в поле Identification List . Если список IKЕ ID List настроен, межсетевой экран сверяет личность удаленного узла, устанавливающего соединение, с этим списком и VРN-туннель открывается, только если совпадение было найдено.