AD+82

91

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

Аутентификационные данные

Это контрольная сумма ICV (Integrity Check Value), вычисленная для всего пакета, включая большинство полей заголовка (см. рис. 3). Получатель повторно вычисляет тот же хэш. Если значения кодов не совпадут, пакет был поврежден в пути или не соответствует секретному ключу. Такие пакеты отбрасываются. ICV часто называется также МАС (Message Authentication Code). Для вычисления МАС используются следующие поля:

Поля IP-заголовка, которые не меняются при транспортировке.

Заголовок АН, кроме поля данных аутентификации

Поле данных протокола верхнего уровня, которые остаются неизменными при транспортировке.

ESP (Encapsulating Security Payload – поле данных безопасной инкапсуляции)

На рис. 5 показан формат заголовка пакета ESP. Первое поле заголовка имеет длину 32 бита и содержит значение индекса параметров безопасности (SPI), которое определяет конкретный набор таких параметров, используемый для данного пакета. За ним следует 32-битовое поле номера по порядку.

Рис. 5. Формат ESP-пакета без аутентификации

Далее размещается поле зашифрованных данных, для выравнивания его длины (+ 2 октета Pad len и Next hdr) до кратного размеру блока шифрования может использоваться поле заполнитель, которое, как и поле данных, может иметь переменную длину. После поля заполнителя размещается хвостовик, содержащий два однооктетных поля: длины заполнителя (Pad len) и кода следующего заголовка (Next hdr). Поле Next hdr характеризует тип поля данных, расположенного выше на рисунке. Протокол ESP требует, чтобы поля Pad len и Next hdr были выровнены по правому полю 32-битового слова. Для решения этой задачи также может использоваться поле заполнитель.

Добавление шифрования делает ESP несколько более сложным, из-за того, что служебные поля ESP окружают поле данных, а не предшествует ему, как это сделано в протоколе AH: ESP включает в себя поля заголовка и хвостовика. Этот протокол предоставляет также туннельный и транспортный режимы обмена.

Документы RFC IPsec не регламентируют конкретный алгоритм шифрования, но допускают использование DES, triple-DES, AES и Blowfish для шифрования поля данных. Алгоритм, используемый для конкретного соединения, специфицируетсяассоциацией безопасности SA (рассмотренной ниже), SA включает в себя не только алгоритм, но и используемый ключ.

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

хвостовике ESP (см. рис. 6).

Возможно использование ESP без какого-либо шифрования (чтобы применить NULL алгоритм). Этот режим не обеспечивает конфиденциальности, и его имеет смысл использовать в сочетании с аутентификацией ESP. Неэффективно использовать ESP без шифрования или аутентификации (если только это не делается для тестирования протокола).

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

шифрования, длина поля заполнителя определяется значением поля pad len. Поле next

92

hdr определяет тип протокола поля данные (IP, TCP, UDP и т.д.). Следует иметь в виду, что поле данные размещено до этого указателя (см. рис. 6).

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

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

Глядя на сам пакет, невозможно даже определить, присутствуют или нет аутентификационные данные (это можно сделать лишь, используя индекс параметров безопасности).

ISAKMP и управление ключами

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

Наиболее простым способом задания этих секретных ключей является ручная конфигурация: один партер генерирует набор ключей и передает ключи другим партерам.

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

Система IKE (Internet Key Exchange) позволяет двум партнерам динамически аутентифицировать друг друга, согласовать использование ассоциации безопасности (Security Association), включая секретные ключи, и генерировать сами ключи. Система IKE использует ISAKMP (Internet Security Association Key Management Protocol – протокол управления ключами ассоциации безопасности Интернет, разработан Национальным агентством безопасности США - NSA). Протокол ISAKMP сам по себе не регламентирует какой-либо конкретный алгоритм обмена ключами, он содержит в себе описание ряда сообщений, которые позволяют согласовать использование алгоритмов обмена ключами. Согласование осуществляется в два этапа:

Узлы ISAKMP согласуют механизмы защиты дальнейшего обмена данными, путем установления SA. Эта ассоциация служит для защиты последующих операций и отличается от прочих SA.

Протокол ISAKMP устанавливает SA для других протоколов, например, из семейства IPsec. Механизм обмена ключами в IKE берется из протокола Oakley (RFC-2412). Основой протокола

обмен ключами Oakley является алгоритм Диффи-Хелмана (см. http://book.itep.ru/6/difi_646.htm),

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

Заметим, что IPsec осуществляет пересылку ключей через порт 500/udp. В IPsec при обмене ключами предусмотрено использование сертификатов. Для получения сертификата посылается запрос в сертификационный центр СА (Certificate Authority). Сертификация включает в себя следующие операции:

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

СА формирует хэш для присланного неподписанного сертификата и шифрует его своим секретным ключом. СА добавляет сформированную так электронную подпись к неподписанному сертификату и посылает уже подписанный сертификат клиенту.

Клиент теперь может послать свой подписанный сертификат любому другому пользователю. Получатель сертификата может легко его проверить, если располагает общедоступным ключом СА.

Клиенты могут пользоваться одним и тем же СА или быть клиентами разных СА. На практике

обычно реализуется иерархическая структура СА.

ВИнтернет имеется огромное количество материалов по проблематике IPsec, но начинать всегда лучше с документов RFC (Requests for Comment), которые со временем обретают статус стандартов.

Вдекабре 2005, весь набор документов RFC по IPsec был обновлен IETF, а серия RFC 43xx по большей части заменила серию RFC 24xx.

93

3 вариант:

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

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

протокол IPsec представляет собой комбинацию нескольких групп протоколов:

-Протокол согласования параметров виртуального канала и управления ключами

(Internet Security Association Key Management Protocol — ISAKMP) обеспечивает общее,

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

-аутентификации(AH),

-шифрования данных(ESP).

Протокол ISAKMP сам по себе не регламентирует какой-либо конкретный алгоритм обмена ключами, он содержит в себе описание ряда сообщений, которые позволяют согласовать использование алгоритмов обмена ключами. Согласование осуществляется в два этапа:

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

- Протокол ISAKMP устанавливает SA для других протоколов, например, из семейства IPsec.

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

хэширования HMAC.

Протокол ESP. Обобщенно все функции защиты, поддерживаемые протоколом инкапсуляции защищенных данных ESP, можно свести к аутентификации и

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

94

82. Обеспечение безопасного доступа пользователей Internet к ресурсам частной (private) сети

82. Обеспечение безопасного доступа пользователей Internet к ресурсам частной (private) сети

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

Первая фаза на примере технологии IPSec Easy VPN

Перед тем, как пользователь сможет передавать зашифрованные данные в удаленную сеть, он должен осуществить процесс подключения. При этом происходит процедура аутентификации, во время которой пользователь должен подтвердить, что он именно тот, за кого себя выдает, и действительно имеет право произвести удаленное подключение. Аналогом этого процесса из реальной жизни является предъявление паспорта сотруднику банка. В IPSec VPN сетях для аутентификации удаленных пользователей может использоваться заранее заданное на клиентских устройствах и сервере секретное значение (ключ), цифровые сертификаты формата x.509, основанные на использовании технологий цифровой подписи, групповые и персональные имена пользователей и пароли, а так же различные комбинации этих методов.

В настоящее время наиболее защищенным способом аутентификации является использование цифровых сертификатов. Аутентификация с использованием цифровых сертификатов не подвержена наиболее совершенному методу атак «man in the middle» (MITM, человек посередине). Суть этого метода состоит в том, что злоумышленник некоторым образом получает возможность пропустить через себя весь трафик между двумя взаимодействующими устройствами. При этом он выступает в качестве своеобразного proxy-сервера, который может выборочно пропускать через себя трафик легитимных устройств, подменяя часть данных на собственные. Из перечисленных методов только использование цифровых сертификатов позволяет полностью исключить возможность успешного проведения подобного типа атак. Но для того, чтобы использовать цифровые сертификаты, в сети обязательно должен присутствовать сервер цифровых сертификатов (Certification Authority).

Операционная система Cisco IOS, под управлением которой работают все маршрутизаторы Cisco, содержит встроенный сервер цифровых сертификатов, предназначенный для использования совместно с технологиями IPSec VPN и SSL VPN.

Remote Access VPN

Представь себе следующую ситуацию. Тебе нужно обеспечить удаленный доступ к корпоративной сети нескольким десяткам сотрудников. Ты можешь использовать для этого технологию шифрованных VPN. Но чем больше сотрудников будет пользоваться удаленным доступом, тем больше компьютеров со всеми детальными политиками безопасности нужно будет настроить. Лучше Cisco Easy VPN. Ее основное преимущество - использование «глупых» клиентов,

95

конфигурирование которых сведено к минимуму.

Когда пользователю уже выдан цифровой сертификат, для создания VPN-соединения в Cisco Easy VPN Client достаточно настроить IP-адрес маршрутизатора компании, подключенного к интернету. Никаких настроек, связанных с использованием алгоритмов шифрования, аутентификации, хеширования для обеспечения целостности, распространения ключей шифрования для протоколов второй фазы и т.п., производить не нужно. Причем для установления VPN-соединения клиентским устройствам совсем не обязательно иметь публичные IP-адреса. За счет передачи IPSec трафика поверх протокола TCP или UDP пользователи могут находиться за устройствами, осуществляющими трансляцию адресов с использованием технологий NAT/PAT.

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

будет использоваться при подключении перед аутентификацией, для проверки подлинности сервера, к которому производится подключение, и исключения атаки MITM.

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

Для этого возьмем маршрутизатор Cisco 857W. Помимо всех функций маршрутизации и обеспечения безопасности, у этого устройства есть еще и встроенная беспроводная точка доступа и RADIUS-сервер. Наличие RADIUS-сервера позволяет защитить небольшую сеть на несколько точек доступа в соответствии с последними рекомендациями WiFi-форума по защите корпоративных беспроводных сетей.

83. Подключение удаленного VPN-клиента по протоколу IPSec

Описанные ниже действия выполняются при попытке подключения VPN-клиента, использующего протокол L2TP/IPSec (Layer Two Tunneling Protocol over Internet Protocol security, туннельный протокол второго уровня поверх безопасности протокола IP), к VPN-серверу с протоколом

L2TP/IPSec под управлением Windows Server 2003.

·На основе сертификатов компьютеров и процесса согласования обмена ключами в Интернете создается сопоставление безопасности IPSec.

·VPN-клиент создает туннель L2TP к VPN-серверу.

·Сервер отправляет запрос клиенту.

·Клиент отправляет зашифрованный ответ серверу.

·Сервер сверяет ответ с базой данных учетных записей пользователей.

·Если учетная запись действительна, а подключение авторизовано, сервер использует политику удаленного доступа и параметры учетной записи пользователя для VPN-клиента.

Примечание

Пункты 3 - 4 предполагают, что VPN-клиент и VPN-сервер используют протокол проверки подлинности MS-CHAP v1 или CHAP. Отправка учетных данных пользователей для других протоколов проверки подлинности может отличаться от описанной выше.

96

97

83. Подключение удаленного VPN-клиента по протоколу IPSec

1 вариант (короткий):

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

IPsec_VPN

С помощью IPsec здесь обеспечивается безопасный доступ пользователей к серверу. При использовании протокола ESP, все обращения к серверу и его ответы шифруются. Однако за VPN шлюзом (в домене шифрования) передаются открытые сообщения. Другие примеры использования IPsec[17] :

• шифрование трафика между файловым сервером и компьютерами в локальной сети, используя IPsec в транспортном режиме.

соединение двух офисов с использованием IPsec в туннельном режиме

98

2 вариант (длинный):

VPN, или Virtual Private Network, что в переводе означает Виртуальная Частная Сеть - это криптосистема, позволяющая защитить данные при передаче их по незащищенной сети, такой как Интернет. Несмотря на то, что данное описание подходит и для криптосистемы SSH, VPN имеет другое предназначение. SSH разрабатывался как средство, позволяющее пользователю безопасно зайти и удалѐнно управлять другим компьютером. Цель VPN - прозрачный доступ к ресурсам сети, где пользователь может делать всѐ то, что он делает обычно независимо от того, насколько он удалѐн. По этой причине VPN приобрѐл популярность среди дистанционных работников и офисов, которые нуждаются в совместном использовании ресурсов территориально разделѐнных сетей.

VPN Туннели

Прежде чем приступить к настройке VPN, необходимо познакомится с общепринятой терминологией и с некоторыми проблемами настройки. Начнѐм с терминологии. VPN соединение всегда состоит из канала типа точка-точка, также известного под названием туннель. Туннель создаѐтся в незащищѐнной сети, в качестве которой чаще всего выступает Интернет. Соединение точка-точка подразумевает, что оно всегда устанавливается между двумя компьютерами, которые называются узлами или peers. Каждый peer отвечает за шифрование данных до того, как они попадут в туннель и расшифровке этих данных после того, как они туннель покинут.

Хотя VPN туннель всегда устанавливается между двумя точками, каждый peer может устанавливать дополнительные туннели с другими узлами. Для примера, когда трѐм удалѐнным станциям необходимо связаться с одним и тем же офисом, будет создано три отдельных VPN туннеля к этому офису. Для всех туннелей peer на стороне офиса может быть одним и тем же. Это возможно благодаря тому, что узел может шифровать и расшифровывать данные от имени всей сети, как это показано на рисунке 1:

Рисунок 1 -- VPN шлюз к сети

99

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

Интересно отметить, что внутри домена шифрования самого шифрования не происходит. Причина в том, что эта часть сети считается безопасной и находящейся под непосредственным контролем в противоположность Интернет. Это справедливо и при соединении офисов с помощью VPN шлюзов. Таким образом гарантируется шифрование только той информации, которая передаѐтся по небезопасному каналу между офисами. Рисунок 2 показывает VPN соединяющую два офиса:

Рисунок 2 -- защищѐнная сеть на основе незащищѐнной сети

Сеть A считается доменом шифрования VPN шлюза A, а сеть B доменом шифрования VPN шлюза B, соответственно. Когда пользователь сети A изъявляет желание отправить данные в сеть B, VPN шлюз A зашифрует их и отошлѐт через VPN туннель. VPN шлюз B расшифрует информацию и передаст получателю в сети B.

Помните режим транспорта и режим туннеля в Терминологии Криптографии 101? Всякий раз, когда соединение сетей обслуживают два VPN шлюза, они используют режим туннеля. Это означает, что шифруется весь пакет IP, после чего к нему добавляется новый IP заголовок. Новый заголовок содержит IP адреса двух VPN шлюзов, которые и увидит пакетный сниффер при перехвате. Невозможно определить компьютер-источник в первом домене шифрования и компьютер-получатель во втором домене.

Посмотрите на рисунок 1, иллюстрирующий типичное использование VPN, которая позволяет удалѐнным пользователям с переносыми компьютерами и пользователям, работающим из дома, иметь доступ к офисной сети. Чтобы эта схема заработала, пользователь должен иметь установленное ПО - VPN клиент, который обеспечит создание VPN туннеля к удалѐнному VPN шлюзу. По сценарию используется режим туннеля, т.к. пользователь хочет получить доступ к ресурсам домена, а не самого шлюза. Единственной случай, когда включается режим транспорта - это если одному компьютеру нужно получить доступ к другому непосредственно.

Существует много вариантов VPN шлюзов и VPN клиентов. Это может быть аппаратное VPN устройство или программное VPN обеспечение, которое устанавливается на маршрутизаторах или на ПК. ОС FreeBSD поставляется вместе с ПО для создания VPN шлюза и для настройки VPN

100

клиента. В коллекции портов существуют и другие приложения, позволяющие соединяться со станциями под управлением других ОС.

К счастью, в Интернет есть много источников информации о VPN, FAQ и варианты настроек. Я

могу порекомендовать Tina Bird's VPN Information, VPN Labs, и Virtual Private Network Consortium (VPNC).

Назависимо от используемого ПО, все VPN работают по следующим принципам:

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

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

•Узлы сверяют политики, чтобы договориться об используемых алгоритмах; если это не получается, то туннель не устанавливается

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

всимметричном алгоритме для шифрования/расшифровки данных

Есть несколько стандартов регламентирующих вышеописанное взаимодействие. Вы, должно быть, слышали о некоторых из них: L2TP, PPTP, и IPSec. Т.к. IPSec - наиболее широко поддерживаемый стандарт, который имеет в арсенале наибольшее количество сокращений, оставшуюся часть статьи стоит посвятить именно ему.

IPSec

Стандарт IPSec был разработан для повышения безопасности IP протокола. Это достигается за счѐт дополнительных протоколов, добавляющих к IP пакету собственные заголовки, которые называются инкапсуляциями. Т.к. IPSec - стандарт Интернет, то для него существуют RFC (Requests For Comments). Если есть интерес покопаться во внутренностях IPSec, то следующие

RFC с http://www.rfc-editor.org/ могут оказаться полезными:

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

AH (Authentication Header) - протокол заголовка идентификации. Обеспечивает целостность путѐм проверки того, что ни один бит в защищаемой части пакета не был изменѐн во время передачи. Не будем вдаваться в подробности, какая часть пакета защищается и где находятся данные AH заголовка, т.к. это зависит от используемого типа шифрования и в деталях, с диаграммами описывается в соответствующем RFC. Отметим лишь, что использование AH может вызвать проблемы, например, при прохождении пакета через NAT устройство. NAT меняет IP адрес пакета, чтобы разрешить доступ в Интернет с закрытого локального адреса. Т.к. пакет в таком случае изменится, то контрольная сумма AH станет неверной. Также стоит отметить, что AH