Виртуальная частная сеть (VPN)



Рис.5.3 Модель надежности ПК пользователя.

Для определения коэффициента готовности ПК пользователя используются формулы

где л - интенсивность отказов,

µ - интенсивность восстановлений.

где , - среднее время жизни элемента,

- среднее время восстановления элемента.

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

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

Рис.5.4. Модель надежности линии доступа пользователя.

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

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

Рис.5.5. Модель надежности транспортной сети

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

Рис.5.6. Модель надежности пограничного маршрутизатора

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

Рис.5.7 Модель надежности серверов, сертификатов аутентификации и политики.

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

Рис.5.8 Модель надежности межсетевого экрана.



6. Оценка безопасности услуги VPN

В сетевой безопасности используются следующие термины.

Уязвимость (vulnerability) системы - это любая характеристика системы, использование которой нарушителем может привести к реализации угрозы.

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

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

Результатом атаки могут быть:

· расширение прав доступа,

· искажение информации,

· раскрытие информации,

· кража сервисов,

· отказ в обслуживании.

Риск (risk) - возможность проведения захватчиком успешной атаки в отношении конкретной слабой стороны системы.

Оценка риска (risk assessment) - количественная оценка повреждения, которое может произойти.Таким образом, оценка риска - это количественная мера опасности. Любой риск представляет собой многокритериальную величину и не может оцениваться по одной компоненте. Этим объясняется многообразие подходов и методов оценки риска.

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

Экспертная модель

Уровень серьезности последствий оценивается с точки зрения владельца системы по некоторой шкале. Концепция оценки серьезности последствий представлена на рис.6.1.

Рис.6.1. Общие представления об уровне серь?зности последствий

Для оценки условия серьезности последствий используется формула:

уровень серь?зност и =( важность цели вредность атаки ) ( системные контрмеры сетевые контрмеры ) (6.1)

Параметры формулы (1) оцениваются по пятибалльной шкале.

Таблица 6.1. Экспертные оценки параметров.

Оценка	Важность цели	Вредность атаки	Контролеры системы	Контролеры сети
5 баллов	Брандмауэр, сервер DNS, основной маршрутизатор	Получен корневой доступ к сети	Современная операционная система, дополнительная защита типа TCP Wrappers и Secure Shel	Ограничительный брандмауэр, работающий в одну сторону
4 балла	Ретранслятор, средство обмена электронной почтой	Отказ в обслуживании		Ограничительные брандмауэры с внешними соединениями (модемами)
3 балла		Пользовательский доступ через узнанный пароль	Старая операционная система
2 балла	Пользовательская настольная система UNIX			Разрешительный брандмауэр
1 балл	MS-DOS 3.11		Нет TCP Wrappers, разрешены фиксированные нешифрованные пароли

Экономическая модель

Экономическая модель позволяет оценить стоимость ущерба от атаки.

Стоимость потерь от снижения производительности сотрудников атакованного узла или сегмента равна

, (6.2)

где - время простоя вследствие атаки, час

- зарплата сотрудников атакованного узла, доллары за месяц ($/месяц)

- число сотрудников атакованного узла.

Стоимость восстановления работоспособности атакованного узла или сегмента

(6.3)

где - стоимость повторного ввода информации

- стоимость восстановления узла (переустановка системы, конфигурирование и т.д.)

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

, (6.4)

, (6.5)

где - время повторного ввода потерянной информации, час

- зарплата обслуживающего персонала (администраторов)

- время восстановления после атаки, час

- число обслуживающего персонала.

Упущенная выгода от простоя атакованного узла или сегмента

, (6.6)

, (6.7)

где O - объ?м продаж атакованного узла или сегмента (в долларах США за год)

Общий ущерб от атаки равен

, (6.8)

где I - число атакованных узлов,

n - число атак в год.

Вероятностная модель

Вероятностная модель позволяет оценить вероятность успешной атаки. Оценим вероятность успешной атаки для услуги виртуальной частной сети (Virtual Private Networks, VPN). Структурная модель риска VPN показана на рис.6.2.29

Рис.6.2. Структурная модель риска VPN.

Рис.6.3. Модель риска типа «узла». - объекты риска.

Структурная модель риска VPN относится к моделям типа «узла». Объектами риска () является ПК, сервер доступа, брандмауэр, сервер политики, сервер сертификатов. Злоумышленник получает доступ к ресурсам объекта, если успешно преодолевает последовательность преград. С каждым объектом риска связан свой набор преград ().

В таблице 6.2 приведены преграды для защиты от несанкционированного доступа и отображены характеристики преград и среднее время их возможного преодоления подготовленным нарушителем. Таким образом, таблица 6.2 отражает сценарий перехода системы VPN в опасное состояние. Таблица 6.2 может быть дополнена. Кроме того, для каждого объекта риска должна быть разработана своя таблица. Однако мы будем пользоваться таблицей 6.2 для всех серверов VPN. Подчеркнем лишь важность составления сценариев перехода системы в опасное состояние.



Таблица 6.2. Преграды для защиты от несанкционированного доступа к серверу.

Преграда	Частота смены значений параметров преграды	Среднее время преодоления преграды нарушителем	Возможный способ преодоления преграды
1. Охраняемая территория со сменой охраны	Через 2 часа	30 мин.	Скрытое проникновение на территорию
2. Пропускная система в здании	Через сутки	10 мин.	Подделка документов, сговор, обман
3. Электронный ключ для включения компьютера	Через 5 лет (наработка до замены)	1 неделя	Кража, сговор
4. Пароль для входа в систему	Через 1 месяц	1 месяц	Подсматривание, сговор, подбор
5. Пароль для доступа к программным устройствам	Через 1 месяц	10 суток	Подсматривание, сговор, подбор
6. Пароль для доступа к требуемой информации в БД	Через 1 месяц	10 суток	Подсматривание, сговор, подбор
7.Шифрование информации со сменой ключей	Через 1 месяц	2 года	Расшифровка, сговор

Вероятность успешной атаки равна

, (6.9)

где - вероятность сохранения защищенности ПК,

- вероятность сохранения защищенности сервера доступа,

- вероятность сохранения защищенности сервера политики,

- вероятность сохранения защищенности сервера сертификатов,

- вероятность сохранения защищенности пограничного маршрутизатора,

- вероятность сохранения защищенности брандмауэра,

- вероятность защищенности от атак протоколов VPN.

Вероятность сохранения защищенности объекта риска услуги VPN равна

, (6.10)

где - количество преград, которое необходимо преодолеть нарушителю, чтобы получить доступ к i -объекту риска,

- вероятность преодоления нарушителем r -ой преграды i -объекта риска.

Вероятности преодоления преград определяются по статистическим данным анализаторами атак или комплексами обнаружения и защиты от атак.

Основными угрозами ПК пользователя являются вирусные угрозы.

Для случайных вирусных угроз сравнительно редкое использование профилактической диагностики незначительно ухудшает вероятностно-временные характеристики системы. Вероятность безопасного функционирования при диагностике 2 раза в неделю составит 0.77 -0.90, а при диагностике 1 раз в сутки она повышается до 0.90 - 0.96.

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

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



7. Криптографические протоколы

7.1 Классификация криптографических протоколов

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

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

В криптографических протоколах используются стандарты шифрования, представленные на рис 7.1.

Рис.7.1. Криптографические методы и шифры.

Классификация криптографических протоколов представлена на рис 7.2.

Рис.7.2. Криптографические протоколы.

На рис 7.3 показаны основные типы протоколов.32



Рис.7.3. Типы протоколов.

На рис 7.4 показаны протоколы сетевой защиты.

Рис.7.4. Протоколы сетевой защиты.

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

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

Для описания протоколов примем обозначения:

A, B - участники протокола,

- сеансовый ключ,

- ключ A(B), совместный с посредником,

- открытый ключ A(B),

- закрытый ключ A(B),

- шифрование,

- дешифрование,

- хэш-функция,

- код аутентичности,

- случайное число (оказия), сгенерированное A(B),

S - секретное слово,

T - метка даты/времени,

M - сообщение.

В таблицах 7.1-7.5 приведены элементы криптографических протоколов.

Таблица 7.1. Шифрование сообщений.

Традиционное шифрование
	· обеспечивает конфиденциальность (только A и B знают ключ K ) · обеспечивает определенный уровень аутентификации ( источником может быть только A ) · не обеспечивает подпись ( B может фальсифицировать получение сообщения, A имеет возможность отрицать отправку сообщения)
Шифрование с открытым ключом
	· обеспечивает конфиденциальность (только B имеет ключ ) · не обеспечивает аутентификацию (кто угодно может использовать ключ
	· обеспечивает аутентификацию и подпись (только A имеет ключ , кто угодно может использовать , чтобы проверить подпись)



Таблица 7.2. Использование кодов аутентичности.

	· обеспечивает аутентификацию
	· обеспечивает аутентификацию (только A и B знают K1 ) · обеспечивает конфиденциальность (только A и B знают K2 )
	· обеспечивает аутентификацию · обеспечивает конфиденциальность

Таблица 7.3. Использование функций хэширования.

	· обеспечивает конфиденциальность (только A и B знают K) · обеспечивает аутентификацию (H(M) криптографически защищено)
	· обеспечивает аутентификацию и цифровую подпись (H(M) криптографически защищено, только A может создать [H(M)])
	· обеспечивает аутентификацию и цифровую подпись · обеспечивает конфиденциальность (только A и B знают K)
	· обеспечивает аутентификацию (только A и B знают S)
	· обеспечивает аутентификацию (только A и B знают S) · обеспечивает конфиденциальность (только A и B знают K)

Таблица 7.4. Использование запросов/ответов.

	обозначает оказию, сгенерированную стороной A. Ключ K совместно используется A и B. - функция типа приращения. Запросы/ответы используются для предотвращения воспроизведения сообщений.

Таблица 7.5. Использование арбитражной цифровой подписи.

Традиционное шифрование, арбитр может видеть сообщение
Традиционное шифрование, арбитр не видит сообщения
Шифрование с открытым ключом, арбитр не видит сообщения
В таблице приняты обозначения: X - отправитель, Y - получатель, A- арбитр, M - сообщение

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

Пример 1. Протокол распределения сеансовых ключей с помощью центра распределения ключей

(ЦРК).

1.

2.

3.

4.

5.

Целью протокола является защищенная передача сеансового ключа сторонам A и B. Сторона A получает на шаге 2. Сообщение, передаваемое на шаге 3, может быть зашифровано и прочитано только стороной B. Шаг 4 отражает знание ключа стороной B. Шаг 5 убеждает сторону B в том, что ключ известен A и в том, что сообщение является новым, так как в нем используется .

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

1. А отсылает В свое имя и случайное число .

2. В отсылает серверу свое имя и зашифрованное общим с В ключом сообщение, в котором конкатенируется имя А, случайное число и собственное число

3. Сервер генерирует А два сообщения. В первое сообщение входит имя В, сеансовый ключ К и случайные числа и . Это сообщение шифруется общим ключом S и А. Второе сообщениевключает имя А и сеансовый ключ К. Сообщение шифруется общим ключом S и В.

4. А расшифровывает первое сообщение, извлекает ключ К, убеждается в том, что совпадает со значение, отправленным на этапе 1. Затем посылает В два сообщения. Первое сообщение - это сообщение сервера, зашифрованное ключом В. Второе сообщение содержит случайное число , зашифрованное сеансовым ключом.

5. В расшифровывает первое сообщение, извлекает ключ К, убеждается в том, что совпадает со значение отправленным на этапе 2.

7.2 Атаки на протоколы

Атаки на протоколы можно разделить на два класса:

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

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

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

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

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

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

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

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

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

Помешать атаке на систему часов можно, связывая между собой метки даты/времени всех сообщений.

7.3 Протоколы VPN

Для независимости от прикладных протоколов и приложений защищ?нные виртуальные сети формируются на одном из более низких уровней модели OSI -- канальном, сетевом или сеансовом. Канальному (второму) уровню соответствуют такие протоколы реализации VPN, как PPTP, L2F, L2TP, сетевому (третьему) уровню -- IPSec, SKIP, а сеансовому (пятому) уровню --SSL/TLS и SOCKS. Чем ниже уровень эталонной модели, на котором реализуется защита, тем она прозрачнее для приложений и незаметнее для пользователя. Но при снижении этого уровня уменьшается набор реализуемых услуг безопасности и становится сложнее организация управления. Чем выше защитный уровень, тем шире набор услуг безопасности, над?жнее контроль доступа и проще конфигурирование системы защиты, но в этом случае усиливается зависимость от используемых протоколов обмена и приложений [1].

Канальный уровень

Для стандартного формирования криптозащищ?нных туннелей на канальном уровне компанией Microsoft при поддержке других компаний был разработан протокол туннелирования РРТР (Pointto-Point Tunneling Protocol), представляющий собой расширение протокола РРР (Point-to-PointProtocol). Протокол РРТР предусматривает как аутентификацию удал?нного пользователя, так и зашифрованную передачу данных, однако в этом протоколе не специфицируются конкретные методы аутентификации и шифрования.

Протокол L2F (Layer-2 Forwarding) разработан компанией Cisco Systems при поддержке компаний Shiva и Northern Telecom в качестве альтернативы протоколу РРТР. В отличие от протокола РРТР протокол L2F позволяет использовать для удал?нного доступа к провайдеру Интернет не только протокол РРР, но и другие протоколы, например, SLIP. При формировании защищ?нных каналов по глобальной сети провайдерам Интернет не нужно осуществлять конфигурацию адресов и выполнять аутентификацию. Кроме того, для переноса данных через защищ?нный туннель могут использоваться различные протоколы сетевого уровня, а не только IP. В данном протоколе также не специфицируются конкретные методы аутентификации и шифрования.

Протокол L2TP (Layer-2 Tunneling Protocol) разработан в организации Internet Engineering TaskForce (IETF) при поддержке компаний Microsoft и Cisco Systems как протокол защищ?нного туннелирования РРР-трафика через сети общего назначения с произвольной средой. L2TP, в отличие от РРТР, не привязан к протоколу IP, а потому может быть использован в сетях с коммутацией пакетов(в сетях АТМ). L2TP также предусматривает управление потоками данных,отсутствующее в L2F. Как и предшествующие протоколы канального уровня, спецификация L2TPне описывает методы аутентификации и шифрования.

Протоколы формирования защищ?нного туннеля на канальном уровне независимы от проколов сетевого уровня модели OSI. Они позволяют создавать защищ?нные каналы между удал?нными компьютерами и локальными сетями, работающими по различным протоколам сетевого уровня (IP, IPX или NetBEUI). Многопротокольность -- основное преимущество инкапсулирующих протоколов канального уровня. Однако формирование защищ?нных туннелей на канальном уровне приводит к сложности конфигурирования и поддержки виртуальных каналов связи. Кроме того, протоколы канального уровня не специфицируют конкретные методы шифрования, аутентификации, проверки целостности каждого передаваемого пакета, а также средств управления ключами.

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

Сетевой уровень

Спецификацией, где описаны стандартные методы для всех компонентов и функций защищ?нных виртуальных сетей, является протокол IPSec (Internet Protocol Security), соответствующий сетевому уровню модели OSI и входящий в состав IPv6. Протокол IPSec предусматривает стандартные методы аутентификации пользователей или компьютеров при инициации туннеля, стандартные способы шифрования конечными точками туннеля, формирования и проверки цифровой подписи, а также стандартные методы обмена и управления криптографическими ключами между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнения каждой задачи. Выбранные методы для одной задачи обычно не зависят от методов реализации других задач. Для функций аутентификации IPSec поддерживает цифровые сертификаты популярного стандарта Х.509.

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

Протокол IPSec может использоваться вместе с протоколом L2TP. Совместно эти протоколы обеспечивают наиболее высокий уровень гибкости при защите виртуальных каналов.

Для управления криптографическими ключами на сетевом уровне наиболее широкое распространение получили такие протоколы, как SKIP (Simple Key management for InternetProtocols) и ISAKMP (Internet Security Association and Key Management Protocol). SKIP проще в реализации, но он не поддерживает переговоров по поводу алгоритмов шифрования. Протокол ISAKMP поддерживает такие переговоры и выбран в качестве обязательного протокола для управления ключами в IPSec для IPv6, то есть ISAKMP является составной частью протокола IPSec.

Сеансовый уровень

Для шифрования информации на сеансовом уровне наибольшую популярность получил протокол SSL/TLS (Secure Sockets Layer/ Transport Layer Security), разработанный компанией NetscapeCommunications. Этот протокол созда?т защищ?нный туннель между конечными точками виртуальной сети, обеспечивая взаимную аутентификацию абонентов, а также конфиденциальность, подлинность и целостность циркулирующих по туннелю данных. Ядром протокола SSL/TLS является технология комплексного использования асимметричных и симметричных криптосистем компании RSA Data Security. Для аутентификации взаимодействующих сторон и криптозащиты ключа симметричного шифрования используются цифровые сертификаты открытых ключей пользователей (клиента и сервера), заверенные цифровыми подписями специальных Сертификационных Центров. Поддерживаются цифровые сертификаты, соответствующие общепринятому стандарту Х.509.

С целью стандартизации процедуры взаимодействия клиент-серверных приложений TCP/IP через сервер-посредник (брандмауэр) комитет IETF утвердил протокол SOCKS. Данный протокол поддерживает приложения, требующие контроля над направлениями информационных потоков и настройки условий доступа в зависимости от атрибутов пользователя и/или информации. В соответствии с SOCKS клиентский компьютер устанавливает аутентифицированный сеанс с сервером, исполняющим роль посредника (proxy). Посредник в свою очередь проводит любые операции, запрашиваемые клиентом. Поскольку посреднику известно о трафике на уровне сеанса, он может осуществлять тщательный контроль.

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

Протокол IPSec

Стандартные способы защиты информационного обмена на сетевом уровне модели OSI для IP-сети, являющейся основным видом публичных сетей, определяется протоколом IPSec (InternetProtocol Security). IPSec обеспечивает аутентификацию источника данных, криптографическое закрытие передаваемых пакетов сообщений, проверку их целостности и подлинности после при?ма, защиту от навязывания повторных сообщений, а также частичную защиту от анализа трафика. Стандартизированными функциями IPSec-защиты могут и должны пользоваться протоколы более высоких уровней, в частности, управляющие протоколы, протоколы конфигурирования, а также протоколы маршрутизации.

В соответствии с протоколом IPSec архитектура средств безопасностиинформационного обмена на три уровня (рис 7.1).

На верхнем уровне расположены следующие протоколы:

· протокол согласования параметров виртуального канала и управления ключами (InternetSecurity Association Key Management Protocol -- ISAKMP), обеспечивающий общее управление защищ?нным виртуальным соединением, включая согласование используемых алгоритмов криптозащиты, а также генерацию и распределение ключевой информации;

Рисунок 7.1 -- Архитектура средств безопасности IPSec

· протокол аутентифицирующего заголовка (Authentication Header -- AH), предусматривающий аутентификацию источника данных, проверку целостности и подлинности после при?ма, а также защиту от навязывания повторных сообщений;

· протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload -- ESP), обеспечивающий криптографическое закрытие передаваемых пакетов сообщений и предусматривающий также выполнение всех функций протокола аутентифицирующего заголовка (AH).

Использование в IPSec двух различных протоколов защиты виртуального канала (AH и ESP) обусловлено практикой, применяемой во многих странах на ограничение экспорта и/или импорта криптосредств. Каждый из этих протоколов может использоваться как самостоятельно, так и одновременно с другим.

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

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

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

В настоящий момент для протоколов АН и ESP зарегистрировано два алгоритма аутентификации: HMAC-MD5 (Hashed Message Authentication Code -- Message Digest version 5) и HMACSHA1(Hashed Message Authentication Code -- Secure Hash Algorithm version 1). Это алгоритмы аутентификации с секретным ключом. Если секретный ключ известен только передающей и принимающей сторонам, это обеспечит аутентификацию источника данных, а также целостность пакетов, пересылаемых между сторонами. Для обеспечения совместимости работы оборудования на начальной стадии реализации протокола IPSec по умолчанию принято использовать алгоритм аутентификации HMAC-MD5.

Для протокола ESP зарегистрировано семь алгоритмов шифрования. Алгоритм шифрования DES(Data Encryption Standart) принят по умолчанию и необходим для обеспечения IPSecсовместимости. В качестве альтернативы DES определены алгоритмы Triple DES, CAST-128, RC-5, IDEA, Blowfish и ARCFour.

Протоколы АН и ESP поддерживают работу в двух режимах:

· туннельном, при котором IP-пакеты защищаются целиком, включая их заголовки;

· транспортном, обеспечивающим полную защиту только содержимого IP-пакетов.

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

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

Протокол аутентифицирующего заголовка

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

В туннельном режиме защищаются все поля IP-заголовков (рисунок 4.1). При защите каждый обычный IP-пакет помещается целиком в конверт IPSec, а тот, в свою очередь, инкапсулируется в другой IP-пакет. В защищ?нном IP-пакете внутренний (первоначальный) IP-заголовок содержит целевой адрес пакета, а внешний IP-заголовок содержит адрес конца туннеля.

Рисунок 7.2 -- IP-пакет до и после применения протокола АН

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

В формат заголовка АН входит поле переменной длины Authentication Data, содержащее информацию, используемую для аутентификации пакета и называемую МАС-кодом (MessageAuthentication Code). Это поле называют также цифровой подписью, имитовставкой, хэш-значением или криптографической контрольной суммой. Способ вычисления этого поля определяется алгоритмом аутентификации. В настоящее время предписывается обязательная поддержка алгоритмов HMAC-MD5 и HMAC-SHA1, основанных на применении односторонних хэш-функций с секретными ключами. Секретные ключи генерируются в соответствии с протоколом ISAKMP.Таким образом, независимо от режима работы, протокол АН предоставляет меры защиты от атак, ориентированных на нарушение целостности и подлинности пакетов сообщений. С помощью этого протокола аутентифицируется каждый пакет, что делает неэффективной работу программ, пытающихся перехватить управление сеансом. Но следует иметь в виду, что аутентификация по протокол АН не допускает манипулирование основными полями IP-заголовка во время прохождения пакета. Поэтому данный протоколд нельзя применять в среде, где используется механизм трансляции сетевых адресов (Network Address Translation -- NAT), так как манипулирование IP-заголовками необходимо для его работы.

Протокол инкапсулирующей защиты содержимого

Протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload -- ESP) обеспечивает выполнение следующих функций по защите информационного обмена:

· криптографическое закрытие содержимого IP-пакетов;

· частичная защита от анализа трафика пут?м применения туннельного режима;

· формирование и проверка целостности цифровой подписи IP-пакетов для их защиты от нарушений подлинности и целостности;

· защита от воспроизведения IP-пакетов.

Представленный перечень функций по защите информационного обмена показывает, что функциональность протокола ESP шире, чем у протокола АН. Протокол ESP обеспечивает

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

Обобщ?нно все функции защиты, поддерживаемые протоколом ESP, можно свести к аутентификации, которую обеспечивает также протокол АН, и криптографическому закрытию передаваемых IP-пакетов. Спецификация IPSec допускает использование протокола ESP для криптографического закрытия IP-пакетов без использования функций аутентификации. Кроме того, допускается использование фиктивного шифрования при выполнении функций протокола АН. Таким образом, в протоколе ESP функции аутентификации и криптографического закрытия могут быть задействованы либо вместе, либо отдельно друг от друга. При выполнении шифрования без аутентификации появляется возможность использования механизма трансляции сетевых адресов (Network Address Translation -- NAT), поскольку в этом случае адреса в заголовках IP-пакетов можно модифицировать.

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

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

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

В настоящее время спецификация IPSec для криптографического закрытия IP-пакетов по протоколу ESP предписывает обязательную поддержку алгоритма шифрования DES-СВС (DataEncryption Standart in Cipher Block Chaining mode). Данный алгоритм шифрования применяется в протоколе ESP по умолчанию, и он необходим для обеспечения IPSec-совместимости. В качестве альтернативы DES определены алгоритмы Triple DES, CAST-128, RC-5, IDEA, Blowfish и ARCFour.

Алгоритм CAST (стандарт RFC 2144) считается таким же стойким, как алгоритм Triple DES со 128-битовым ключом. Кроме того. CAST быстрее, чем DES. Алгоритм RC5 (стандарт RFC 2040) является алгоритмом шифрования потока данных, использующим ключ переменной длины. Стойкость RC5 зависит от дины ключа, которая может достигать 256 бит. Алгоритм IDEA(Inretnational Data Encryption Algorithm) рассматривают как ''быстрый'' эквивалент Triple DES. Ещ? одним алгоритмом, использующим ключ переменной длины, является Blowfish, который также считается достаточно стойким. Алгоритм ARCFour является общедоступной версией алгоритма RC4.

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

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

Управление защищенным туннелем

Создание и поддержка защищ?нного виртуального канала невозможны без реализации функций управления. В спецификации IPSec такие функции разделяются на две группы:

· общие функции управления, основанные на использовании базы данных политики безопасности (Security Policy Database -- SPD);

· функции управления, ориентированные на согласование параметров туннеля и формирование контекста безопасности (Security Association -- SA), который описывает общие параметры защищ?нного виртуального канала.

В соответствии с общими функциями управления все входящие и исходящие IP-пакеты должны сопоставляться с упорядоченным набором правил политики безопасности, которая зада?тся для следующих объектов:

· для каждого сетевого интерфейса с задействованными средствами IPSec;

· для каждого исходящего и входящего потока данных.

Согласно спецификациям IPSec политика должна быть рассчитана на независимую обработку IP-пакетов на сетевом уровне модели OSI по современной технологии фильтрации. Соответственно должны существовать средства администрирования базы данных политики безопасности, подобные средствам администрирования базы правил межсетевых экранов. База данных политики безопасности (SPD) представляет собой упорядоченный набор правил, каждое из которых 43включает совокупность селекторов и допустимых контекстов безопасности. Селекторы служат для отбора пакетов, а контексты задают требуемую обработку.

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

· исходного и целевого IP-адреса; при этом адреса могут быть индивидуальными и групповыми (допускается также применение в правилах диапазонов адресов и метасимволов ''любой'');

· имени пользователя или узла (в формате DNS или Х.500);

· номеров используемого транспортного протокола;

· номеров исходного и целевого портов (могут применяться диапазоны и метасимволы).

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

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

При создании контекста безопасности (SA) взаимодействующие стороны должны аутентифицировать друг друга и согласовать между собой параметры туннеля, включающие типы криптографических алгоритмов и ключи шифрования. Для решения этих задач в IPSecиспользуется протокол согласования параметров виртуального канала и управления ключами (Internet Security Association Key Management Protocol -- ISAKMP), обеспечивающий общее управление защищ?нным виртуальным соединением. Протокол ISAKMP описывает базовую технологию аутентификации, обмена ключами и согласования всех остальных параметров IPSec-туннеля при создании контекстов безопасности (SA). Однако ISAKMP не содержит конкретные алгоритмы обмена криптографическими ключами. Поэтому для обмена ключами могут использоваться другие протоколы. В настоящий момент в качестве такого протокола выбран протокол Oakley, основанный на алгоритме Диффи-Хеллмана. Объединение протоколов ISAKMPи Oakley обозначают как ISAKMP/ Oakley.

Согласно протоколу ISAKMP согласование параметров защищ?нного взаимодействия необходимо как при формировании IPSec-туннеля, так и при формировании в его рамках каждого защищ?нного однонаправленного соединения. Глобальные параметры туннеля образуют управляющий контекст и согласуются по протоколу ISAKMP/ Oakley. Параметры каждого защищ?нного однонаправленного соединения согласуются на основе созданного управляющего контекста и как раз образуют SA. Для идентификации каждого из контекстов безопасности предназначен индекс параметров безопасности (Security Parameters Index -- SPI). Этот индекс включается в заголовки защищ?нных IPSec-пакетов, чтобы принимающая сторона смогла правильно их расшифровать и/или аутентифицировать, воспользовавшись указанным контекстом безопасности (SA).

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

Гибкость политики безопасности при использовании протокола IPSec определяется селекторами и контекстами безопасности, употребл?нными в правилах. Например, в случае, когда в селекторах фигурируют только IP-адреса, пара взаимодействующих компьютеров может применять один набор контекстов безопасности. Если же анализируются номера TCP- и UDP-портов, то набор контекстов может быть своим для каждого приложения. Соответственно, с одной стороны, два защитных шлюза могут организовать единый туннель для всех обслуживаемых компьютеров, а с другой -- могут разграничить туннель пут?м организации разных контекстов по парам компьютеров или даже приложений.



Источники

1. Денисова Т.Б. Надежность и безопасность услуги VPN, Электросвязь №9, 2005, С20-22.

2. Коваленко И.Н. Методы расчета высоконадежных систем. - Киев. Высшая школа, 1988.

3. Рябинин И.А. Надежность и безопасность структурно-сложных систем. - СПб.:Политехника, 2000.

4. Олифер В., Олифер Н. Новые технологии и оборудование IP-сетей.-СПб.:БХВ - Санкт-Петербург, 2000.

5. Шнайер Б. Прикладная криптография. - М.: Триумф, 2002.

6. Столлингс В. Криптография и защита сетей. - М.: Издательский дом «Вильямс», 2001.

7. Петров А.А. Компьютерная безопасность. - М.: ДМК, 2000.

8. Чмора А. Современная прикладная криптография. - М.: Гелиос АРВ, 2002.48

9. Норткатт С., Новак Д. Обнаружение вторжений в сеть. - М.: Лори, 2002.

10. Норткатт С., Купер М., Фирноу М., Фредерик К. Анализ типовых нарушений безопасности в сетях. - М.: Издательский дом «Вильямс», 2001.

11. Лукацкий А. Обнаружение атак. - СПб.: БХВ - Петербург, 2003.

12. Грушо А.А., Тимонина Е.Е. Теоретические основы защиты информации. - М.: Издательское агентство «Яхтсмен», 1996.

13. Безкоровайный М.М., Костогрызов А.И., Львов В.М. Инструментально-моделирующий комплекс для оценки качества функционирования информационных систем «КОК». - М.: СИНТЕГ, 2000.

14. Нечаев В.И. Элементы криптографии. Основы теории защиты информации. - М.: Высшая школа, 1999.

Размещено на Allbest.ru

...