Программно-аппаратные средства обеспечения информационной безопасности вычислительных сетей

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

Первая цель семейства протоколов IPSecсостоит в обеспечении конфиденциальности, целостности и аутерификации информации, передаваемой посредством IP - протокола АН. Комбинация этих трех протоколов обеспечивает безопасный обмен информации.

Второй целью семейства протоколов IPSec является предоставление разработчиками ПО набора стандарта.

Установление безопасного соединения начинается с формирования ассоциации обеспечения безопасности (Security Association, SA) между двумя сообщающимися сторонами.

5.3.1 Ассоциация обеспечения безопасности

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

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

Прежде чего договаривается об ассоциации обеспечения безопасности, необходимо локальное конфигурирование элементов протокола IPSec, которые данный партнер собирается поддерживать. Эти параметры настройки хранятся в базе данных политики безопасности (Securiti Policy Databese, SPD).

После согласования ассоциации обеспечения безопасности содержится в базе данных ассоциации обеспечения безопасности (Secyrity Association Databese, SAD). Это необходимо, поскольку узел сети может инициировать несколько сеансов, каждому из которых может соответствовать своя SA.

Поскольку для каждого сетевого устройства доступно множество сеансов протокол в IPSec, для правильного функционирования процесса необходимо, чтобы каждый сеанс согласования SA имел свой собственный уникальный идентификатор. Этот идентификатор составляется из уникального индекса параметры обеспечения безопасности(Security Parametr Index, SPI), который определяет, какая запись БД SA соответствует рассматриваемому подключению. Кроме того, учитывается адрес назначения и идентификатор используемого протокола (УЫЗ или ФР). Приведем пример выбора из базы данных ассоциации обеспечения безопасности маршрутизатора Cisco, использующей протокол ESP:

Inbound esp sas:

Spi:0x71BB425D (1908097629)

Transform: esp-des esp-md5-hmas,

In use settings={tunnel,}

Slot:0, conn id:2000,flow_id: 1, cryto map:mode

Sa timing: remaning key lifetime (k/sec): (4600800/3500)

IV size: 8 bytes

Replay detection support:Y

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

5.3.2 Протокол обмена интернет - ключами

Протокол обмена интернет - ключами предназначен для аутерификации и согласования параметров обмена протокола IPSec. Протокол IKE представляет собой комбинацию двух протоколов: протокола управления ассоциациями и протокола управления ключами обеспечения безопасности в сети Интернет (Internet Security Association and Key Management Protocol, ISAKMP), называемых фазами установления. Управления ключами можно выполнять вручную или используется альтернативы протокола IKE, такие как безопасная служба доменных имен (Secure DNS), Photuris или простой протокол обмена интернет - ключами(Simple Key Internet Protocol, SKIP). Первая фаза протокола IKE. На первой фазе протокола IKE удаленный пользователь начинает сеанс со шлюзовым устройством VPN. Первая фаза выполняет две функции: аутерификацию удаленного пользователя и обмен информацией об открытых ключах, которые будут использоваться во второй фазе.

Аутерификацию можно выполнять несколькими различными способами. Наиболее часто используются технологии предварительно распространяемых ключей и технология цифровых сертификатов. Термин «предварительно распространяемые ключи» означает, что значения ключей предварительно задается на всех компьютерах, которые собираются установить соединения через VPN (что является существенным недостатком). При повторном способе используются цифровые удостоверения (цифровые сертификаты, digital certificates), которые могут назначается отдельно для каждого объекта, который соединяется с VPN. Цифровые сертификатами можно удаленно управлять и администрировать из уполномоченного центра сертификации(Sertificate Authority, CA).

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

В первой фазе при обмене аутерификации информацией и параметрами безопасности могут использоваться два режима: основной (main mode) и агрессивный (aggressive mode). Различия между ними заключаются в количестве сетевых пакетов, которыми обмениваются стороны, и во времени, за которые генерируется открытый ключ.

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

Вторая фаза протокола IKE. Dj второй фазе протокола IKE согласовываются конкретные параметры ассоциации обеспечения безопасности IPSec. Данное согласование подобно агрессивному режиму обмена информацией первой фазы. После завершения второй фазы формируется SA и пользователь получает подключение к VPN.

Dj второй фазе возможен единственный режим согласования -быстрый режим(qick mode). Быстрый режим представляет собой короткий обмен, использующий три пакета. Все обмены второй фазы зашифрованы с помощью согласованных во время первой фазы протоколов и типов кодирования. При этом используется только защита, основанная на использовании хэш-функций и нонсе (nonce), включаемых в сетевые пакеты для подтверждения оригинальности (нонсе является подтверждением этого факта что информация о ключе исходит из ожидаемого источника. Нонсе - это слуяайное число, генерируемое инициатором связи, которое заверяется респондентом цифровой подписью и посылается обратно).

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

После создания ассоциации обеспечения безопасности, испольуемой протоколом IKE, можно применять протоколы обеспечения безопасности. При построении VPN, основанной на протоколе IPSec, можно выбрать использовать из одновременно.

Управление ключами. Применяемый по умолчанию для IPSec протокол автоматизированного управления ключами называется ISAKMP/Oakley и состоит из следующих элементов:

1) Протокол определения ключей Oakley- протокол на основе алгоритма Диффи - Хеллмана, но обеспечивающий дополнительно защиту. Протокол Oakley называется общим, так как он не диктует использования каких-либо конкретных форматов;

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

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

Протокол Oakley разработан в целях сохранения преимущества алгоритма Диффи - Хеллмана и устанавливает его недостатков. Алгоритм Oakley характеризуется следующими особенностями:

1) Использование механизмов рецептов (cookies) для защиты от атак засорения;

2) Соглашение двух сторон о группе, которая определяет параметры алгоритма обмена ключами Диффи - Хеллмана;

3) Использование оказаний для противостояния атакам повтора сообщений;

4) Обмен открытыми ключами Диффи - Хеллмана;

5) Аутерификация обмена для противостояния атакам «человек посередине».

Рассмотрим эти способности применительно к возможны атакам.

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

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

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

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

Возведение в степень в арифметике классов вычетов с 768 - битовым модулем:

Возведение в степень в арифметике классов вычетов с 1024 - битовым модулем:

Q=2768-2704-1+264([2638??]+149 686), d=2

Возведем в степень в арифметике классов вычетов с 1024 - битовым модулем:

Q =21024-2960-1+264([2894??] +129093), a=2

Группа эллиптической кривой над конечным полем из 2 элементов; генератор (в шестнадцатизначном виде) -Х=7B, Y=1C8; параметры эллиптической кривой -А =0, Y=7338F. 185

Группа эллиптической кривой над конечным полем из 2 элементов: генератор -X=18, Y=D; параметры эллиптической кривой - A=0, Y=1EE9.

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

С алгоритмом Oakley могут применятся три различных метода аутерификации.

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

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

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

Спецификация Oakley включает в себя ряд примеров обмена, допустимых для данного протокола. Рассмотрим пример аггресивного обмена ключами(aggressive key exchange) между абонентами А и В, в котором требуется обмен только тремя сообщениями:

A>B: CKY A, OK_KEYX, GRP, gx, EHAO, NIDP, IDA , IDB ,

NA, S KA [IDA¦¦ IDB ¦¦NA¦¦GRP ¦¦GX¦¦ENAO];

B> A: CKYB, CKY A, OK)KEYX, CRP, GY, AHAS, NIDP, IDB,

IDANB, SKB[IDB¦¦ IDA¦¦NB¦¦NA¦¦GRP¦¦ GY¦¦EHAS];

A>B: CKY A, CKYB, OK_KEYX, GRP, GX, EHAS, NIDP, IDA,

IDB, NA, NB, S KA [IDA¦¦ IDB¦¦NA¦¦NB¦¦ GRP¦¦GX¦¦ GY¦¦EHAS]

Где CKY A, CKYB,-рецепты абонентов А и В соответственно; OK_KEYX - тип сообщения обмена ключами; CRP- имя группа для этого обмена; GX, GY -открытые ключи абонентов; gxy- сеансовый ключ для этого обмена; EHAO, EHAS - функции шифрования (Е), хеширования (H), аутерификация (А), предложение (О), и выбранные (S); NIDP - оставшиеся часть сообщения не подлежит; IDA, IDB - идентификаторы абонентов; NA, NB - случайные случаи абонентов для этого обмена; S KA [ ], SKB[ ] - подписи, использующие секретные ключи абонентов; ¦¦ - символ конкатернации.

Протокол ISAKMP определяет процедуры и форматы пакета, используемые для переговоров о создании, изменение или удаление защищенных связей. Как часть процесса защищенной связи ISAKMP определяет полезную нагрузку сообщений обмена ключами и аутерификации данных. Сообщение ISAKMP состоит из заголовка и следующих за ним полезных нагрузок. Все это с помощью транспортного протокола (спецификации требует, чтобы любая реализация поддерживала использование UDP).

Формат заголовка ISAKMP, содержащая следующие поля:

1) Рецепт инициатора (64 бит);

2) Рецепт респондента (64 бит);

3) Следующая полезная нагрузка (8 бит) - указывает тип первой полезной нагрузки в сообщении;

4) Главный номер версии (4 бит) - указывает главный номер используемой версии ISAKMP;

5) Дополнительный номер версии (4 бит) - указывает дополнительный номер используемой версии;

6) Тип обмена (8 бит) - указывает тип обмена;

7) Флаги (8 бит) - указывают параметры, установленные для данного обмена ISAKMP. В настоящее время определено два бита: бит шифрования (устанавливается, когда все имеющиеся полезные нагрузки, следующие за заголовком, зашифрованы с использованием алгоритма шифрования защищенной связи) и бит фиксации (предназначен для гарантии того, что зашифрованный материал не будет получен до начала защищенной связи);

8) Идентификатор сообщения (32 бит) - указанный идентификатор данного сообщения;

9) Длина (32 бит) - длина всего сообщения (заголовка из всех полезных нагрузок в байтах).

Типы полезных нагрузок ISAKMP. Все полезные нагрузки ISAKMP имеют заголовки одного типа. Формат заголовка типовой полезной нагрузки показан на рис ниже.

После следующей полезной нагрузки имеет значение 0, если данная полезная нагрузка является в сообщении последней(иначе значение поля будет тип следующей полезной нагрузки).

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

Полезай груз типа SA (защищенная связь) служит для того, чтобы начать процесс создания защищенной связи. В этом случае параметр Doman of Interpritation идентифицирует область интерпретации (DOI ), в рамках которой выполняется согласование. Параметр Situation (ситуация) определяет политику защиты для процесса согласования, устанавливая степени защиты (например, гриф секретности, уровень безопасности).

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

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

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

Поля Transformation ID (идентификатор трансформации) и Attributes (атрибуты) определяют трансформацию (например, 3DES для ESP или HMAC SHA -1-96 для АН) и связанные с ней параметры (например, длину хэш-кода).

Полезный груз типа КЕ (обмен ключами) может использоваться для целого ряда методов обмена ключами, среди которых Oakley data по Диффи - Хеллману и обмен ключами RSA. После Key Exchange data (данные обмена ключами) содержит данные, необходимые для создания сеансового ключа и зависящее от используемого алгоритма обмена ключами.

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

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

1) Сертификат Х.509 в кодировке KCS#7;

2) Сертификат PGP;

3) Подписанный ключ DNS;

4) Сертификат Х.509 - подпись;

5) Сертификат Х.509 - обмен ключами;

6) Мандаты Kerberos;

7) Список отозванных сертификатов (CRL);

8) Список отозванных полномочий (ARL );

9) Сертификат SPKI.

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

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

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

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

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

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

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

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

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

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

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

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

Информационный обмен предназначен для односторонней пересылки информации, касающийся параметров управления защищенной связь. В этом сообщении полезный груз после заголовка ISAKMP шифруется.

5.3.3 Протокол аутерификации заголовка

Протокол АН - это IP протокол 51. Он поддерживает функциональные возможности аутерификации и проверки целостности, но не поддерживает конфиденциальность содержимого пакета.

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

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

Протокол АН также поддерживает использование порядковых номеров (sequence numbers), помогающих предотвращать нападения основанные на повторном использовании пакета (replay attack), эти номера используются коммуникационными устройствами для отслеживания потока сетевых пакетов сеанса связи.

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

Использование информации IP - заголовка протоколом АН делает аго несовместимым с использованием NAT. Структура заголовка АН - пакета представлена на рис выше.

После следующего заголовка содержит идентификатор, определяющий тип заголовка пакета, следующего за заголовком АН - пакета.

После длины содержимого пакета определяет длину заголовка АН - пакета.

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

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

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

5.3.4 Протокол безопасной инкапсуляции содержимого пакета

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

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

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

В любом режиме протокол ESP использует в каждом сетевом пакете порядковые номера. При работе протокола ESP в туннелированном режиме можно использовать NAT.

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

После следующего заголовка сообщает номер протокола пакета, который инкапсулирован внутри пакета протокола ESP.

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

5.3.5 Пример применения протокола IKE

Проиллюстрируем применение протокола примером для маршрутизатора Cisco, который можно сконфигурировать как часть VPN различными способами. В этом примере создается туннель от одного маршрутизатора к другому с применением протокола ESP и алгоритма SHA-1. В первом фрагменте устанавливается параметры настройки управления ассоциациями и ключами обеспечения безопасности в сети Интернет для конфигурации протокола IKE следующим образом:

Crypto isakmp policy 10

Authentication pre-share

Crypto isakmp key <s3cr3r!> address 192.168.100.100

В данном случае типа аутерификации определено использование предварительного распространяемого (pre-shar) ключа, а в следующей строке задано само значение ключа <s3cr3r!>для заданного адреса 192.168.100.100. далее задаются опции безопасности, которые этот маршрутизатор будет требовать при согласовании ассоциации обеспечения безопасности. Эти опции называют набором преобразования (transform -set):

Crypto ipsec transform -set secure esp-3des esp-shahmac

Набор преобразования secure устанавливается с перечислением допустимых сочетаний протоколов и алгоритмов аутентификации. Следующая команда используется для назначения интерфейсу соответствующей карты шифрования (crupto map), которой присвоено имя cmap:

crypto map cmap local-address Ethernetl

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

crypto map cmap 10 ipsec-isakmp

set peer 192.168.200.200

set transform-set secure

match address 101

Эти команды связывают вместе все компоненты конфигурации VPN, они дают равноправный адрес (peer address) объекта, к которому будет создан туннель,список разрешенных наборов преобразования и определяют список контроля доступа для трафика, имеющего номер 101, который должен быть направлен через VPN (это расширенный список):

Access-list 101 permit ip 192.168.2.0 0. 0.0.255192.168.1.0. 0.0.0.255

Access-list 101 deny ip 192.168.2.0 0.0.0.255 any

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

interface Ethernetl

description external interface

ip address x.x.x.x

crypto map cmap

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

ip nat inside source route-map nonat interface Ethernetl overload

route-map nonat permit 10

match ip address 102

Эта маршрутная карта допускает трафик, который запрещается в списке контроля доступа для обхода трансляции сетевых адресов, в то время как устройство трансляции сетевых адресов, в то время как устройство трансляции разрешает трафик. Далее следует правила списка контроля доступа, которые определены в маршрутной карте nonat:

Access - list 102 deny ip 192.168.2.0 0.0.0.255 192.168.1.0.0.0.0.255

Access - list 102 permit ip 192.168.2.0.0.0.0.255 any

Это список используется для обхода трансляции сетевых адресов и разрешения трафика, связанного с протоколом IPSec, который инициализирует туннель:

Access - list 112 permit udp any any eq isakmp

Access - list 12 permit esp any any

Этот список контроля доступа сконфигурирован таким образом, чтобы разрешить трафики протокола ISAKMP (порт 500/udp) и ESP (IP - протокол 50. Протокол АН имеет номар 51).

5.3.6 Совместное использование протоколов ESP и AH

Отдельная защищенная связь может использовать либо протоколом АН, либо протокол ESP, но ни как не оба эти протокола одновременно. Тем не менее иногда конкретному потоку данных может требоваться и сервис АН, и сервис ESP.

Во всех случаях одному потоку для получения комплекса услуга IPSec требует несколько защищенных связей. Такой набор защищенных

Связей называется пучком защищенных связей (security association bundle), посредством которого потоку должен предоставляться необходимый набор услуг IPSec. При этом защищенные связи в пучке могут завершатся в различных конечных точках.

Защищенные связи могут быть объединены в пучки следующими двумя способами:

1) Трансформационной смежности - в этом случае применяются несколько протоколов защиты к одному IP - пакету без создания туннеля. Эта комбинация АН и ESP эффективна только для одного уровня вложенности, так как обработка выполняется в одной точке - IPSec конечного пользователя;

2) Повторное туннелирования - в этом случае применяются несколько уровней протоколов защиты с помощью туннелирования IP/ этот подход допускает множество уровней вложения, поскольку туннели могут начинаться и завершаться в разных использующихся IPSec узлах сети вдоль маршрута передачи данных.

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

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

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

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

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

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

5.3.7 Основные типы защищенных связей

В PDF 2401 приведены четыре примера защищенных связей, которые должны придерживается использующими IPSec узлами или шлюзами защиты. Рассмотрим эти примеры.

1)Обеспечить защиту связи между конечными системами, использующими IPSec (рис 5.9.). эти конечные системы должны использовать общие секретные ключи. При этом доступны следующие комбинации:

1) АН в транспортном режиме;

2) ESP в транспортном режиме;

3) Сигнала АН, а затем ESP в транспортном режиме;

4) Любая из предыдущих связей внутри АН или ESP в туннельном режиме.

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

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

4) обеспечение защиты удаленного доступа, в этом случае обеспечивается защита удаленного узла, использующего Интернет для связи с МЭ организации в целях получения доступа к узлу локальной вычислительной сети, защищаемому этим МЭ. Между адаленным узлом и МЭ необходимо использовать только туннельный режим. Как и в варианте 1, между удаленными и локальными узлами можно использовать одну или две защитные связи.

5.4 Протоколы VPN транспортного уровня

Проколы транспортного уровня прозрачны для прикладных протоколов представления сервисов (HTTP, FTP, POP3, SMTP, NNTP и др.). так как транспортный уровень отвечает за установку логических соединений и управление этими соединениями, то на этом уровне появляется возможность использования программ - посредников, которые проверяют допустимость соединений и обеспечивают выполнение других функций защиты.

Среди протоколов транспортного уровня наибольшее распространение получил прокол Secure Socket Layer/Transport Layer Security (SSL/TLS, разнообразный компанией Netscape Communications. Для выполнения функции посредничества между двумя взаимодействующими сторонами организацией IETF в качестве стандарта разработан протокол SOCKS.

Прокол SSL. Протокол SSL/TLS(SSL) изначально ориентирован на организацию защищенного обмена между клиентом и сервером. Клиентская часть протокола включена в состав всех популярных Web - браузера, а серверная - большинство Web - серверов как коммерческих, так и свободно распространяемых.

Протокол SSL устанавливает защитные туннели между конечными точками (клиентом и сервером). Формирование защищенного обмена проходит в две стадии:

1) Установление SSL - сеанса;

2) Защищенное взаимодействие;

Процедура установления SSL - сеанса выполняет по протоколу Handshake Protocol, входящему в состав SSL. В процессе установления SSL - сеанса выполняются следующие основные действия:

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

2) Сервер, обработав запрос, предает клиенту согласованный набор параметров, в который входят: идентификатор сеанса, алгоритмы функции из числа предложенных, сертификат сервера и случайная последовательность RAND_SERV;

3) Клиент проверяет сертификат сервера и при положительном результате проверки выполняет следующие операции: генерирует случайные последовательность (48 байт) Premaster Secret, шифрует ее открытым ключом сервера и посылает серверу; с помощью согласованной хэш - функции формирует ключ Master Secret, используя Premaster Secret, RAND_CL, и RAND_SERV; с помощью Master Secret формирует сеансовые ключи;

4) Сервер расшифровывает последовательность PreMasterSecret и выполняет аналогичные клиенту операции;

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

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

Особенностью протокола SSL является то, что при использовании SSL вне США действуют экспортные ограничения на длину ключей шифрования, такие же ограничения относятся и к алгоритмам шифрования Web - браузеров.

Протокол SOCKS. Протокол SOCKS разработан для организации функций посредничества между клиент - серверным приложениями, причем не привязан к протоколу IP и не зависит от OC. Наибольшее распространение получили версии 4 и 5 этого протокола, причем SOCKS v5 одобрен IETF (Internet Engendering Task Force) в качестве стандарта. Протокол SOCKS v5 является расширением четвертой версии и реализует следующие дополнительные возможности:

1) Клиент может передавать серверу Ip адрес назначения или его DNS - имя;

2) Поддержка наравне с TCP и протокола UDP;

3) При аутерификации пользователя сервер может согласовывать с клиентом способ аутерификации, допуская двустороннюю аутерификацию;

4) Возможность использования расширенной схемы адресации;

5) Серверная часть обычно располагается в МЭ сети, а клиентская - на компьютере пользователя. Обобщенная схема установления соединения включает в себя следующие основные действия.

1) Пользователь выдает запрос, перехватываемый SOCKS - клиентом;

2) SOCKS - клиент соединятся с SOCKS - сервером и сообщает ему идентификаторы поддерживаемых методов аутерификации;

3) SOCKS - сервер выбирает метод аутерификации (при невозможности использовать предложенные методы соединения разрывается);

4) В соответствии с выработанным методом SOCKS - сервера аутерифицирует пользователя (при неудаче аутерификации соединение разрывается);

5) При успешной аутерификации SOCKS - клиент предает DNS или IP - адрес запрашиваемого прикладного сервера;

6) На основе имеющихся правил разграничении доступа SOCKS - сервер разрешает или запрещает установление соединения с этим прикладным сервером;

7) При установленном соединении клиент и прикладной сервер взаимодействуют друг с другом, а SOCKS - клиент и SOCKS - сервер ретранслирует данные, выполняя функции посредников.

Аутерификация пользователей может основывается на паролях или шифровых сервисах Х.509. для шифрации трафика могут использоваться любые проколы. Популярные браузеры Netscape Navigator и Internet Explorer поддерживает протокол SOCKS.

5.5 Цифровые сертификаты

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

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

Certificate ::= SEQUENCE {

tbs Certificate TBS Certificate,

Signature Algorithm AlgorithmIndentefier,

SignatureValue BIT STRENG}

TBSCertificate::= SEQUENCE{

Version [0] EXPLICIT Version DEFAULT v1,

serial Number CertificateSerialNumber,

signature Algorithm Identifier,

issuer name,

validity Validity,

subgectPublickey info Subject PublicKeyInfo,

IssuerUniqeID [1] IMPLICIT UniqueIndetifier

Optional,

_ _If present, version shall be v2 or v3

Subject UniqeID [2] IMPLICIT UniqueIndetifier

Optional,

_ _If present, version shall be v2 or v3

Version ::=INTEGER { v1 (0) , v2 (1), v3(2) }

CertificateSerialNumber::=INTEGER

Validity ::= SEQUENCE{

notBefor Time,

notAfter Time}

Time::=CHOICE {

UtcTime UTCTime,

General Time Generalize Time }

UniqIndentifier::= BIT STRING

SubjectPublicKeyInfo::= SEQUENCE{

Algorithm AlgorihmIdentifier,

sudjectPublicKey BIT String }

Extensions ::=SEQUENCE SIZE (1…MAX) OF Extension

Extension ::=SEQUENCE {

EetenID OBJECT IDENTIFIER,

Critical BOOLEAN DEFAULT FALSE,

ExtnValue OCTET STRING }

Каждый пользователь может добавить свой открытый клюя в уполномоченный центр некоторым защищенным образом и получить соответствующий сертификат. Затем он может опубликовать полученный сертификат. Сертификаты Х.509 используются в большинстве приложений сетевой защиты, включая IPSec, SSL, SET, S/MIME и др.

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

Центр сертификации подписывает сертификат с помощью своего секретного ключа. Если все пользователи используют один центр сертификации, то это означает общее доверие данному центру. В Х.509 предусмотрена иерархия центров, что позволяет создавать сложные системы управления ключами.

5.6 Примеры отечественного построения VPN

Протоколы построения защищенных виртуальных сетей могут быть реализованы различными средствами:

1) Серверами удаленного доступа, позволяющими создать защищенные туннели на канальном уровне;

2) Маршуризаторами, которые поддерживают протоколы создания защищенных виртуальных сетей на канальном и сетевом уровнях;

3) Межсетевыми экранами, возможно включающими в свой состав серверы удаленного доступа и позволяющие создать VPN на канальном, сетевом и транспортном уровнях;

4) Специализированным программным обеспечением для создания защищенных туннелей на сетевом и транспортном уровнях;

5) Программно - аппаратные средствами, позволяющими формулировать защищенные туннели на канальном и сетевых уровнях;

В качестве ответственного примера построения VPN рассмотрим особенности системы «Континент -К» НИП «Информазащита» и продукты ViPNet компании Infotexs.

Основными компонентами системы «Континент -К» является криптошлюз, центр управления сетью криптошлюзов, абонентский пункт.

Криптошлюз представляет собой программно - аппаратные устройства операционной системы FreeBSD и обеспечивает:

1) Прием и передачу пакетов (TCP /IP);

2) Шифрование по ГОСТ 28147-89 в режиме гаммирования с обратной связью;

3) Сжатие защищенных данных;

4) Защиту данных от искажения (иммитировка);

5) NAT;

6) Аутерификацию удаленных абонентов;

7) Контроль целостности ПО криптошлюз до загрузки ОС(электронный замок «Соболь»).

Абонентский пункт служит для защищенного подключения к серверу доступа, на котором находится криптошлюз «Континент -К». после установления соединения и получения разрешения на доступ в защищаемую сеть(сервер доступ проводит идентификацию и аутерификацию удаленного пользователя и определяет его уровень доступа) весь трафик между абонентскими пунктом и защищаемой сетью шифруется по ГОСТ 28147-89. Комплекс использует схему сертификатов Х.509.

Продукты ViPNet для организации VPN включает в себя два решения ViPNet [Custom] и ViPNet [Tunnel].

Система ViPNet [Custom] предназначена для объединения в единую защищенную сеть произвольного числа рабочих станций и локальных сетей. В состав системы входят:

1) ViPNet [Администратор] - модуль, создающий инфраструктуру сети, ведущий мониторинг сети и управляющий объектами сети. Он формирует первичную ключевую и парольную информацию для объектов сети и специфицирует ключи, сформулированные этими объектами;

2) ViPNet [Координатор] - модуль, выполняющий маршрутизатор защищенных пакетов, теннелирования пакетов от обслуживаемой группы незащищенных компьютеров локальной сети. Он фильтрует трафик от источников, не входящих в VPN в соответствии с заданной ПБ, обеспечивает возможность работы защищенных компьютеров через межсетевые экраны и proxy - серверы других пользователей;

3) ViPNet [Клиент] - модуль, обеспечивающий защиту при предаче по открытым каналам связи и защиту доступа к ресурсам компьютера из сетей общего пользования. Модуль может быть установлен как на рабочую станцию, так и на сервер (баз данных, файл - сервер, WWW-сервер, SMTP, SQL, и т.д.).

Система ViPNet [Tunnel] предназначена для объединения локальных сетей или офисов в VPN. Система базируется на пакетах программ ViPNet [Координатор], выполняющих роль шлюза и программного обеспечения для компьютеров защищаемых локальных сетей. Система выполняет функции:

1) Сервера IP-адресов;

2) Proxy - сервера защищенных связей;

3) Туннельного сервера;

4) МЭ (фильтрации трафика от источников, не входящих в состав VPN, в соответствии с ПБ).

Во всех пунктах серии используется низкоуровневый драйвер, взаимодействующий непосредственно с драйвером сетевого интерфейса, что обеспечивает независимость от операционной системы. Криптографическим ядром данного семейства продуктов являются средства криптографической защиты «Домен -К».

Рассмотренные отечественные продукты являются сертифицированными.

Контрольные вопросы

1) Какие уровни сетка протокола TCP/IP используются для создания VPN.

2) Назовите основные типы конфигураций VPN.

3) Что понимается под термином «туннелирование»?

4) Назовите основные недостатки применения VPN.

5) Назовите основные этапы теннелирования формирования защищенного канала при использовании протокола L2TP.

6) Назовите основные причины разработки IP - прокола версии 6.

7) Перечислите основные задачи, решаемые ассоциациями безопасности.

8) Перечислите основные различия транспортного уровня и туннельного режимов.

9) Назовите основные этапы инфраструктуры PKI.

10) Оцените порядок «накладных расходов» при применении протоколов ESP и АН.

11) Возможно ли одновременное применение протоколов ESP и АН для организации защищенной связи.

12) Какие варианты защищенной связи поддерживаются протоколом IPSec?

13) Какой из протоколов (ESP и АН) несовместим с NAT?

14) Каковы состав и назначение цифрового сертификата открытых ключей?

15) Для чего в упорядоченном центре ведутся списки отозванных сертификатов и отозванных полномочий?

16) Какие средства могут быть использованы для построения VPN?

Приложение

Система обнаружения вторжений Snort

Сетевая система обнаружений Snort была разработана Мартином Рош (Martin Roesch) как упрощенная СОВ в виде сетевого анализатора (www.snort.org). Благодаря постоянным усовершенствованиям и расширениям Snort все более превращается в полнофункциональную систему анализа IP - трафика и записи пакетов в реальном времени. В настоящее время Snort является одним из примеров совместной работы интернет - сообщества. Поскольку СОВ Snort является открытой разработкой, множество исследователей принимают участие в разработке новых дополнительных модулей и усовершенствовании старых.

По своему смыслу Snort является переносимой системой и работает на многих операционных системах. В настоящее время существует Snort для архитектуры х86 Linux, free BSD, NetBSD, Open BSD и Windows.

Система Snort может работать в трех основных режимах: анализатор пакетов, регистратор пакетов и сетевая система обнаружения вторжений. Кратко рассмотрим основные компоненты Snort. Сначала входные данные (сетевые пакеты) обрабатываются декодером пакетов. Если Snort используется как регистратур пакетов, то декодированные данные формируются и выводятся на консоль . если Snort используется как регистратор пакетов, то декодированные данные, в зависимости от того что задано в командной строке, или сохраняются в двоичном формате, или преобразуется в формат ASCII и записывается файл на диске. Если Snort используется как сетевая СОВ, то обработка продолжается. Декодированные данные передаются процессорам, которые указаны в файле конфигурации snort.conf. затем данные передаются процессору обнаружения. Который, осуществляет их сравнение с параметрами наборов правил, которые заданы в файле конфигурации. В случае совпадения данных происходит пересылка компонентам регистрации и сигнализации (в зависимости от настроек происходит регистрации или генерация сигналов тревоги).

Основным файлом является файл конфигурации, первые строки которого имеют следующий вид:

#__________________________

# http://www.snort.org Snort 2.6.0 confing file

# Constante: snort - sigs@lists.sourceforge.net

#__________________________

# $Id$

#

############################################

# This file contains a sample snort configuration.

# You can take the following steps to create your own custom

# configuration

#

#1) Set the variables for your network

#2) Configure dumanic loaded libraries

#3) Configure preprocessors

#4) Configure output plugins

#5) Add any runtime config directives

#6) Customize your rule set

П1.Декодер пакетов

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

...