Защита информации виртуальных частных сетей

После нахождения Р7,...,Р13, восстановление Р0,...,Р6 требует М попыток, где М - число вероятных значений Р0,...,Р6. Опять же, поскольку нет индивидуальной настройки, атака может быть выполнена за N/28 попыток при М предварительно вычисленных значениях.

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

3.3 Криптоанализ МРРЕ

Протокол шифрования в одноранговых сетях (МРРЕ) обеспечивает методологию для шифрования пакетов РРТР. Он предполагает существование секретного ключа, известного обоим участникам соединения, и использует поточный шифр RC4 с 40- либо 128-разрядным ключом. Такой метод установки использования МРРЕ является одной из функций протокола управления сжатием РРР (ССР). После установки режима работы начинается сеанс РРР по передаче пакетов зашифрованных данных. Важно отметить, что шифруются только те пакеты РРР, номера протоколов которых лежат в диапазоне 0x0021-0x00fa. Все остальные пакеты передаются без шифрования, даже если шифрование разрешено. Типы пакетов, шифрование которых осуществляется/не осуществляется, регламентируются документом RFC 1700. Для любых пакетов не обеспечивается аутентификация.

В МРРЕ 40-битовый ключ RC4 определяется следующим образом:

· Генерация определяющего 64-битового ключа из хэш-функции Lan Manager пароля пользователя (известного пользователю и серверу) с помощью SHA.

· Установка старших 24 бит ключа в значение 0xD1269E.

128-битовый ключ RC4 определяется следующим образом:

· Объединение хэша Windows NT и 64-битового случайного значения, выданного сервером при работе по протоколу MS-CHAP. Данное число посылается клиенту по протоколу обмена, потому оно известно и клиенту, и серверу.

· Генерация определяющего 128-битового ключа из результатов предыдущего этапа с помощью SHA.

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

· Генерация определяющего ключа - 64-битового для 40-битового шифрования и 128-битового для 128-битового шифрования - путем хэширования предыдущего ключа и исходного ключа с помощью SHA.

· Если требуется 40-битовый ключ, то установка старших 24 бит ключа в значение 0xD1269E.

· Длина типичного пакета РРТР составляет 200 байт, включая заголовок.

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

3.3.1 Восстановление ключа

В МРРЕ степень защиты ключа не превышает степень защиты пароля. Большая часть паролей имеет существенно меньше 40 бит безопасности и раскрываются с помощью словарных атак. Хэш-функция Lan Manager еще боле уязвима: с учетом максимальной длины порции, ограниченного алфавита и отсутствия символов нижнего регистра, невозможно сгенерировать 128-битовый ключ, даже если пользователь хочет это сделать. В документации по МРРЕ описывается флаг для вычисления 40-битового ключа RC4 на основании хэш-функции Windows NT, а не Lan Manager, но эта функция еще не реализована. Нет способов вычисления 128-битового ключа RC4 на основании хэш-функции Windows NT, хотя такой вариант был бы более безопасным (хотя существенно менее безопасным, чем 128-битовый случайный ключ.)

В любом случае, общая степень защиты составляет не 40 или 128 бит, а количество бит энтропии пароля. На основании экспериментальных данных получено, что английскому языку свойственна энтропия 1,3 бита на символ. Изменения регистра, цифры и специальные символы существенно повышают это значение. Любая атака, которая использует словарь слабых паролей, может быть способна прочитать зашифрованный МРРРЕ трафик. Кроме того, стилизованные заголовки в пакете РРР облегчают сбор известных текстов и базы для проверки угаданного ключа.

40-битовый алгоритм RC4 подвержен более серьезным уязвимостям. Поскольку не предусмотрена индивидуальная настройка, атакующий может подготовить словарь зашифрованных заголовков РРР, а затем быстро найти данный зашифрованный текст в словаре. При поиске мест в пакетах МРРЕ, где может содержаться незашифрованный текст, атакующий может воспользоваться множеством связей по SMB и NetBIOS, которые происходят при стандартных соединениях Microsoft.

Более того, тот же 40-битовый ключ RC4 генерируется всякий раз, когда пользователь инициализирует протокол РРТР. Поскольку RC4 представляет собой способ шифрования с обратной связью по выходу, то просто взломать шифр за два сеанса. Серьезная уязвимость отмечается в большей части свежих спецификаций МРРЕ, хотя она исчезла из предыдущей версии. Ни в одной версии документации Microsoft не указано, что один и тот же ключ используется как в прямом, так и в обратном направлении, что гарантирует, что для шифрования двух разных текстов используется один и тот же поток ключей.

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

3.3.2 Атаки переворота битов

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

3.3.3 Атака путем ресинхронизации

Если в процессе передачи теряется пакет, либо приходит пакет с неверным номером в заголовке МРРЕ, то происходит ресинхронизация ключа. Сторона, принявшая неверный пакет, посылает отправителю запрос на ресинхронизацию. По принятию данного запроса, отправитель реинициализирует таблицы RC4 и устанавливает бит "сброшен" (flushed) в заголовке МРРЕ. Если система обнаруживает в пакете установленный бит "сброшен", она реинициализирует свои таблицы RC4 и устанавливает счетчик пакетов в соответствии с полученным значением.

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

3.4 Другие атаки на MS-PPTP

Несмотря на то, что атаки на протоколы MS-CHAP и МРРЕ приводят к полному отрицанию полезности и безопасности MS PPTP, необходимо упомянуть о нескольких интересных атаках.

3.4.1 Пассивный мониторинг

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

Путем установки стандартных средств просмотра и расшифровки общественных линий связи от серверов Microsoft PPTP была получена следующая информация:

IP-адрес клиента

IP-адрес сервера

Количество доступных на сервере виртуальных каналов РРТР

Версия RAS клиента

Имя клиента NetBIOS

Идентификация производителя клиента

Идентификация производителя сервера

IP-адрес клиента во внутреннем виртуальном туннеле

Внутренние DNS-сервера, обслуживающие клиента

Имя пользователя на клиенте

Достаточно информации для получения значений хэш-функций паролей пользователей

Достаточно информации для получения начального значения МРРЕ

Текущее значение шифрованного пакета для клиента перед реинициализацией RC4

Текущее значение шифрованного пакета для сервера перед реинициализацией RC4

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

3.4.2 Перехват переговоров РРР

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

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

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

3.4.3 Потенциальные утечки информации на клиенте

Клиент Windows 95 не выполняет требуемую очистку буферов, и потому допускается утечка информации в сообщениях протокола. Хотя в документации РРТР сказано, что в пакете PPTP_START_SESSION_REQUEST символы после имени компьютера и производителя должны быть сброшены в 0х00, Windows 95 этого не делает.

080: 0000 6c6f 6361 6c00 0000 3e1e 02c1 0000 ..local...>.....

096: 0000 85c4 03c1 acd9 3fc1 121e 02c1 2e00 ........?.......

112: 0000 2e00 0000 9c1b 02c1 0000 0000 0000 ................

128: 0000 88ed 3ac1 2026 02c1 1049 05c1 0b00 ....:. &...I....

144: 0000 3978 00c0 280e 3dc1 9c1b 02c1 041e ..9x..(.=.......

160: 02c1 0e00 0000 121e 02c1 2e00 0000 2e00 ................

176: 0000 3dad 06c1 74ed 3ac1 1c53 05c1 9c1b ..=...t.:..S....

192: 02c1 041e 02c1 0e00 0000 121e 02c1 2e00 ................

208: 0000 ..

Выше показаны символы, содержащиеся после имени компьютера и строки производителя. В байтах 82-86 содержится имя компьютера, которое для клиента Windows 95 всегда равняется "local". Байт 113 - то место, где должна содержаться строка производителя. При просмотре аналогичного пакета Windows NT обнаружено, что все символы "мусора" сброшены в 0х00.

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

3.5 Выводы

Реализация РРТР от Microsoft уязвима с точки зрения реализации, и обладает серьезными недостатками с точки зрения протокола. Протокол аутентификации имеет известные уязвимости. Шифрование выполнено неверно, в данной реализации используется поточный шифр с обратной связью по выходу, хотя более уместен был бы блоковый шифр "шифр-блок-цепочка" (CBC). Чтобы связать слабую аутентификацию с плохим шифрованием Microsoft задала ключ шифрования как функцию от пароля пользователя вместо использования сильного алгоритма обмена ключами типа Диффи-Хеллмана или ЕКЕ. Наконец, канал управления не аутентифицируется и не сильно защищен.

Криптоанализ не подвергал сомнению протокол РРТР, но лишь реализацию протокола от Microsoft. Хотя Microsoft использует свои собственные расширения (MS-CHAP, МРРЕ, МРРС) в РРР секции РРТР, стандарт РРТР не требует этого. Производители могут включить расширения Microsoft в свои продукты по соображениям совместимости, но они не обязаны ограничиваться их использованием и, наверное, реализуют более безопасные решения. Конечно, новые расширения для корректной работы должны поддерживаться как клиентом, так и сервером.

4 Туннелирование по протоколу L2TP

Протокол L2TP (Layer 2 Tunneling Protocol - сетевой протокол туннелирования канального уровня) сочетает в себе все лучшее из протоколов PPTP и L2F (Layer 2 Forwarding - пересылка данных на канальном уровне). L2F был предложен в качестве протокола передачи для подключения по коммутируемым каналам связи. Используя его, серверы удаленного доступа инкапсулируют поступающий трафик в кадры протокола РРР, а затем передают их по каналам ГВС на сервер L2F, который, в свою очередь, удаляет упаковку пакетов и направляет их в сеть получателя.

Протокол L2TP позволяет прокладывать туннели через любые среды, где возможны пакетно-ориентированные одноранговые подключения. В их число, в частности, входят такие технологии региональных вычислительных сетей, как Х.25, Frame Relay и АТМ. Более того, в L2TP предусмотрена возможность соединения двух конечных точек несколькими туннелями.

При работе в IP-сетях протокол L2TP очень похож на PPTP. Здесь туннель прокладывается между клиентом L2TP и сервером L2TP. При этом не имеет никакого значения, подключен ли клиент к сети (например, к ЛВС) постоянно или для установления IP-подключения ему нужно сначала связаться по коммутируемому каналу с сервером сетевого доступа (так подключаются через Интернет удаленные пользователи).

Рисунок 3 - туннелирование с использованием L2TP

Как PPTP, так и L2TP прежде всего производят первичное инкапсулирование данных по протоколу РРР, а затем добавляют в полученные пакеты дополнительные заголовки, необходимые для их пересылки через промежуточные сети. На этом этапе в работе PPTP и L2TP начинают проявляться некоторые различия.

PPTP способен пересылать пакеты только через IP-сети, тогда как L2TP позволяет прокладывать туннели по любым пакетно-ориентированным средам, где возможна организация одноранговых подключений. Благодаря этому пакеты L2TP могут пересылаться по IP-сетям (с использованием протокола UDP), по частным виртуальным каналам с ретрансляцией кадров Frame Relay, по виртуальным каналам Х.25 и по виртуальным каналам АТМ.

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

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

В L2TP предусмотрена аутентификация туннеля, которой нет в PPTP. Правда, когда в туннеле используется протокол IPSec, аутентификация на канальном уровне становится ненужной, так как и L2TP, и PPTP производят ее именно по протоколу IPSec.

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

5 Протокол безопасности IP Security Protocol

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

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

Поскольку средства безопасности Windows IP Security размещены ниже транспортного уровня, администраторы сетей (и производители программного обеспечения) могут уделить внимание и направить свои усилия на придание и координацию безопасности каждой отдельной программе. Используя Windows 2000 Server, администраторы сетей обеспечивают сильную защиту для всей сети в целом, а приложения автоматически наследуют защитные меры системы безопасности Windows 2000 Server. Поддержка шифрования Windows IP Security распространяется также и на виртуальные частные сети (Virtual Private Networks - VPN).

Администраторы и менеджеры сетей выигрывают от интеграции IPSec с Windows 2000 Server по нескольким причинам, в том числе:

· Открытый промышленный стандарт - IPSec обеспечивает открытый промышленный стандарт в качестве альтернативы «доморощенному» способу шифрования IP. Менеджеры сетей при этом получают выигрыш от получаемой функциональной совместимости.

· Прозрачность - IPSec существует под транспортным уровнем, что делает его прозрачным для приложений и пользователей; а это означает, что при реализации IPSec в брандмауэре или маршрутизаторе нет необходимости вносить изменения в сетевые приложения настольного ПК.

· Проверка прав доступа - Служба аутентификации предотвращает возможность перехвата данных при использовании неправильно объявленных данных идентификации.

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

· Целостность данных - При передачах заголовки аутентификации IP и различные коды аутентификации хеш-сообщений обеспечивают целостность данных.

· Динамический повторный ввод (с клавиатуры) - Динамический повторный ввод во время непрерывной связи помогает противостоять попыткам нарушения защиты.

· Безопасные сквозные связи - Windows IP Security обеспечивает наличие надежных, обозначаемых только конечными точками связей для пользователей частной сети внутри одного домена или между любыми доменами, с которыми установлены доверительные отношения на предприятии.

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

· Гибкость -Протокол Windows IP Security дает возможность распространить политику обеспечения безопасности на все предприятие или на отдельную рабочую станцию.

5.1 Разработка на основе IP Security

Протокол безопасности IP Security использует заголовок аутентификации (authentication header - AH) и инкапсулированную нагрузку безопасности (an encapsulated security payload - ESP). Заголовок AH создает конверт, обеспечивающий аутентификацию источника данных, их целостность и защиту от навязывания повторных сообщений (см. рис. 1).

Рисунок 4 - Формат заголовка AH

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

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

Протокол ESP обеспечивает конфиденциальность данных (см. рис. 2) и выполняет все функции протокола AH по защите зашифрованных неаутентифицируемых потоков данных.

Рисунок 5 - Формат заголовка ESP

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

Протоколы ESP и AH зарегистрированы организацией IANA (Internet Address Naming Authority) и занесены в реестр протоколов под порядковыми номерами 50 и 51 соответственно. Если на пограничных маршрутизаторах уже реализованы какие-либо базовые правила фильтрации пакетов, то необходимо добавить эти два протокола к списку разрешенных протоколов. Поскольку поле "тип протокола" заголовка IP-пакета теперь будет соответствовать конверту IPSec, то первоначальный тип транспортного протокола помещается в следующее поле "тип протокола" внутри заголовка IPSec (см. рис. 3).

Рисунок 6 -Инкапсуляция протоколов

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

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

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

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

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

5.1.1 Полная поддержка промышленных стандартов

Windows 2000 дает возможность полностью использовать стандартные криптографические алгоритмы и методы аутентификации. Они включают следующие:

· Метод Диффи-Хеллмана (Diffie-Hellman) для соглашения о совместно используемом ключе.

· Код аутентификации хеш-сообщения (HMAC) и его разновидности для обеспечения целостности и защиты от несанкционированного воспроизведения.

· Стандарт шифрования данных Цепочка цифровых блоков для обеспечения конфиденциальности.

Метод Диффи-Хеллмана (Diffie-Hellman, DH)

Метод Диффи-Хеллмана (Diffie-Hellman, DH), названный так по именам своих изобретателей Whitfield Diffie и Martin Hellman, представляет собой алгоритм криптографии с открытым ключом, который позволяет двум обменивающимся сообщениями сторонам договариваться о совместно используемом ключе. Метод Диффи-Хеллмана начинается с обмена общедоступной информацией между двумя объектами. Затем каждый объект объединяет общедоступную информацию, полученную от другого объекта, со своей собственной секретной информацией для получения совместно используемого секретного значения.

Код аутентификации хеш-сообщения (HMAC)

Все протоколы, опубликованные группой IETF, полностью поддерживаются и используются Windows 2000. Они реализуются согласно последним предварительным сообщениям IEFT, предложенным рабочей группой IPSec, которые, дополнительно к предварительным документам ISAKMP/Oakley, включают документы по общей архитектуре и документы, определяющие форматы заголовка и преобразований.

Система безопасности IP Windows 2000 реализует протокол Ассоциации безопасности Интернета и управления ключами (Internet Security Association/Key Management Protocol - ISAKMP), используя протокол определения ключа Oakley, который допускает динамическое повторное использование ключа.

Протоколы безопасности выполняют различные сервисные действия для обеспечения безопасных передач в сети. В Windows 2000 используются следующие протоколы безопасности:

· Протокол Ассоциации безопасности Internet и управления ключами (Internet Security Association / Key Management Protocol)

· Протокол определения ключа Oakley

· Заголовок аутентификации IP

· Протокол инкапсулированной безопасности IP

Протокол ISAKMP/Oakley

Задание алгоритмов IPSec - дело непростое, для этого требуется протокол управления сеансом. Протокол ISAKMP (Internet Security Association Key Management Protocol) является рамочной основой для такого протокола, а протокол Oakley -- это уже конкретная реализация его на этой основе, предназначенная для совместного использования с IPSec.

Протокол Oakley имеет более широкий набор функциональных возможностей, чем необходимо для управления IPSec-сеансами. Реализация ISAKMP/Oakley представляет собой функциональное подмножество, достаточное, чтобы обеспечить безопасный способ сообщения аутентификационных данных для генерации ключей и SA-параметров. Обмен по протоколу ISAKMP/Oakley происходит в двух режимах (фазах): основном и быстром. В соответствии с протоколом Oakley, обмен начинается в основном и продолжается в быстром режиме. В первом режиме устанавливаются соглашения SA для обмена данными по протоколу Oakley, а во втором - по протоколу IPSec.

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

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

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

В основном режиме оба участника обмена устанавливают SA-соглашения для безопасного общения друг с другом по протоколу Oakley. В быстром режиме SA-соглашения устанавливаются уже "от лица" протокола IPSec или любой другой службы, которой необходимы данные для генерации ключей или согласования параметров.

Протокол ISAKMP/Oakley не был специально разработан для совместного использования с протоколом IPSec, поэтому возникает необходимость в так называемой области интерпретации (Domain Of Interpretation - DOI), которая обеспечила бы совместную работу протоколов IPSec и ISAKMP/Oakley. Чтобы другие протоколы также могли использовать ISAKMP/Oakley, они должны иметь собственные DOI-области. В настоящий момент таких областей для других протоколов не существует, но ситуация может измениться на очередной конференции группы IETF или в том случае, если частный разработчик, например фирма Netscape, решит использовать этот механизм.

В основном режиме между сторонами согласуются методы шифрования, хэширования, аутентификации и так называемая группа D-H (их всего четыре), которая определяет криптографическую стойкость алгоритма открытого распределения ключей. Первая группа D-H характеризуется высокой стойкостью и позволяет использовать стандарт DES, в то время как для второй и третьей групп следует применять Triple DES. Поскольку в основном режиме иногда требуется передавать до шести пакетов, то, например, при использовании космического сегмента с большой временной задержкой, DES лучше применять с более сильной группой D-H. Тогда перед выполнением очередного основного режима, сопряженного с интенсивными вычислениями и обменом пакетами, удастся выполнить больше обменов в быстром режиме.

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

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

Согласно этим срокам определяется, как скоро, в зависимости от времени или объема переданных данных, потребуется новое согласование в быстром режиме. Есть два разных срока существования SA-соглашения. Основной режим задает его для протокола Oakley, а быстрый - для обмена по протоколу IPSec.

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

5.2 Туннелирование с применением IPSec

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

Главное внимание при разработке IPSec уделялось обеспечению безопасности в IP-сетях на сетевом уровне. Этот протокол хорошо интегрируется с функциями безопасности Windows NT Server, благодаря чему может служить идеальной платформой для защиты потоков информации, проходящих по интрасетям и Интернету.

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

IPSec описывает не только механизмы шифрования IP-трафика, но и формат IP-пакетов, передаваемых по IP-туннелям. Режим такой передачи обычно называют туннельным режимом IPSec (IPSec Tunnel Mode). Туннель IPSec состоит из туннельного клиента и туннельного сервера, которые настроены на применение протокола IPSec, и механизма шифрования по согласованию (negotiated encryption mechanism).

Страницы: 1, 2, 3