1. Обобщенная структура территориально распределенной корпоративной сети Типовые методы объединения отдельных сетей офисов в единую кспд
 Скачать 3.9 Mb.
|
|
2 вариант: IPsec является набором стандартов Интернет и своего рода «надстройкой» над IP-протоколом. Его ядро составляют три протокола: Authentication Header (АН) обеспечивает целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и функцию по предотвращению повторной передачи пакетов Encapsulating Security Payload (ESP) обеспечивает конфиденциальность (шифрование) передаваемой информации, ограничение потока конфиденциального трафика. Кроме этого, он может исполнять функции AH: обеспечить целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и функцию по предотвращению повторной передачи пакетов. При применении ESP в обязательном порядке должен указываться набор услуг по обеспечению безопасности: каждая из его функций может включаться опционально. Internet Security Association and Key Management Protocol (ISAKMP) — протокол, используемый для первичной настройки соединения, взаимной аутентификации конечными узлами друг друга и обмена секретными ключами. Протокол предусматривает использование различных механизмов обмена ключами, включая задание фиксированных ключей, использование таких протоколов, как Internet Key Exchange, Kerberized Internet Negotiation of Keys (RFC 4430) или записей DNSтипа IPSECKEY (RFC 4025). Также одним из ключевых понятий является Security Association (SA). По сути, SA является набором параметров, характеризующим соединение. Например, используемые алгоритм шифрования и хэш-функция, секретные ключи, номер пакета и др. Протокол AH Протокол AH используется для аутентификации, но не для шифрования IP трафика, и служит для подтверждения того, что мы связаны именно с тем, с кем предполагаем, что полученные данные не искажены и не подменены при транспортировке. Аутентификация выполняется путем вычисления зашифрованного аутентификационного хэш- кода сообщения. Хэширование охватывает практически все поля IP пакета (исключая только те, которые могут модифицироваться при транспортировке, например, TTL или контрольная сумма заголовка). Этот код записывается в AH заголовке и пересылается получателю. Формат AH заголовка представлен на рис. 2. Рис. 2. Формат заголовка протокола AH Этот AH заголовок содержит пять важных полей. Следующий заголовок Идентифицирует тип протокола, используемого для следующего поля данных. Фактически это тип пакета, инкапсулированного в AH IPsec. AH len Определяет длину заголовка пакета, измеренную в 32-битовых словах, за вычетом двух слов (это диктуется RFC 1883 для IPv6). Зарезервировано Поле зарезервировано на будущее и должно содержать нули. Индекс параметров безопасности (SPI) 32-битовый идентификатор, который помогает получателю выбрать, к какому из входных обменов относится этот пакет. Каждый обмен, защищенный AH, использует хэш-алгоритм (MD5, SHA-1 и т.д..), какие-то секретные и возможно некоторые иные данные. SPI может рассматриваться как индекс таблицы наборов таких параметров, чтобы облегчить выбор нужного набора. Номер по порядку 91 Монотонно увеличивающийся идентификатор, который позволяет установить соответствие между посланным пакетом и откликом подтверждения его получения. Этот код включается в аутентификационные данные, что позволяет детектировать любые модификации, а также атаки воспроизведения. Аутентификационные данные Это контрольная сумма ICV (Integrity Check Value), вычисленная для всего пакета, включая большинство полей заголовка (см. рис. 3). Получатель повторно вычисляет тот же хэш. Если значения кодов не совпадут, пакет был поврежден в пути или не соответствует секретному ключу. Такие пакеты отбрасываются. ICV часто называется также МАС (Message Authentication Code). Для вычисления МАС используются следующие поля: Поля IP-заголовка, которые не меняются при транспортировке. Заголовок АН, кроме поля данных аутентификации Поле данных протокола верхнего уровня, которые остаются неизменными при транспортировке. ESP (Encapsulating Security Payload – поле данных безопасной инкапсуляции) На рис. 5 показан формат заголовка пакета ESP. Первое поле заголовка имеет длину 32 бита и содержит значение индекса параметров безопасности (SPI), которое определяет конкретный набор таких параметров, используемый для данного пакета. За ним следует 32-битовое поле номера по порядку. Рис. 5. Формат ESP-пакета без аутентификации Далее размещается поле зашифрованных данных, для выравнивания его длины (+ 2 октета Pad len и Next hdr) до кратного размеру блока шифрования может использоваться поле заполнитель, которое, как и поле данных, может иметь переменную длину. После поля заполнителя размещается хвостовик, содержащий два однооктетных поля: длины заполнителя (Pad len) и кода следующего заголовка (Next hdr). Поле Next hdr характеризует тип поля данных, расположенного выше на рисунке. Протокол ESP требует, чтобы поля Pad len и Next hdr были выровнены по правому полю 32-битового слова. Для решения этой задачи также может использоваться поле заполнитель. Добавление шифрования делает ESP несколько более сложным, из-за того, что служебные поля ESP окружают поле данных, а не предшествует ему, как это сделано в протоколе AH: ESP включает в себя поля заголовка и хвостовика. Этот протокол предоставляет также туннельный и транспортный режимы обмена. Документы RFC IPsec не регламентируют конкретный алгоритм шифрования, но допускают использование DES, triple-DES, AES и Blowfish для шифрования поля данных. Алгоритм, используемый для конкретного соединения, специфицируетсяассоциацией безопасности SA (рассмотренной ниже), SA включает в себя не только алгоритм, но и используемый ключ. В отличие от протокола AH, который вводит небольшой заголовок перед полем данных, ESP ―окружает‖ защищаемое поле данных. Поля индекс параметров безопасности (Security Parameters Index) и номер по порядку служат для тех же целей, что и в случае AH, но в ESP имеются также поля заполнителя, следующего заголовка, и опционно аутентификационных данных в конце, в хвостовике ESP (см. рис. 6). Возможно использование ESP без какого-либо шифрования (чтобы применить NULL алгоритм). Этот режим не обеспечивает конфиденциальности, и его имеет смысл использовать в сочетании с аутентификацией ESP. Неэффективно использовать ESP без шифрования или аутентификации (если только это не делается для тестирования протокола). Заполнение делается для того, чтобы сделать возможным применение блочных алгоритмов шифрования, длина поля заполнителя определяется значением поля pad len. Поле next 92 hdr определяет тип протокола поля данные (IP, TCP, UDP и т.д.). Следует иметь в виду, что поле данные размещено до этого указателя (см. рис. 6). Помимо шифрования, ESP может опционно предоставлять возможность аутентификации, с привлечение алгоритма HMAC. В отличие от AH, однако, эта аутентификация производится только для ESP заголовка и зашифрованного поля данных. При этом не перекрывается весь IP пакет. Это не существенно ослабляет безопасность аутентификации, но дает некоторые важные преимущества. Когда посторонний рассматривает IP пакет, содержащий данные ESP, принципиально невозможно определить IP адреса отправителя и получателя. Атакер конечно узнает, что это ESP данные (это видно из заголовка пакета), но тип поля данных и сами данные зашифрованы. Глядя на сам пакет, невозможно даже определить, присутствуют или нет аутентификационные данные (это можно сделать лишь, используя индекс параметров безопасности). ISAKMP и управление ключами Для управления ключами используется несколько протоколов. IPsec был бы бесполезным без шифрования и аутентификации, которые в свою очередь невозможны без секретных ключей, известных партнерам обмена и неизвестных больше никому. Наиболее простым способом задания этих секретных ключей является ручная конфигурация: один партер генерирует набор ключей и передает ключи другим партерам. Но такая схема плохо масштабируется, кроме того, кто-то из партнеров может пренебречь мерами безопасности и в результате вся сеть будет скомпрометирована. В больших системах с большим числом узлов такая схема обычно не приемлема. Система IKE (Internet Key Exchange) позволяет двум партнерам динамически аутентифицировать друг друга, согласовать использование ассоциации безопасности (Security Association), включая секретные ключи, и генерировать сами ключи. Система IKE использует ISAKMP (Internet Security Association Key Management Protocol – протокол управления ключами ассоциации безопасности Интернет, разработан Национальным агентством безопасности США - NSA). Протокол ISAKMP сам по себе не регламентирует какой-либо конкретный алгоритм обмена ключами, он содержит в себе описание ряда сообщений, которые позволяют согласовать использование алгоритмов обмена ключами. Согласование осуществляется в два этапа: Узлы ISAKMP согласуют механизмы защиты дальнейшего обмена данными, путем установления SA. Эта ассоциация служит для защиты последующих операций и отличается от прочих SA. Протокол ISAKMP устанавливает SA для других протоколов, например, из семейства IPsec. Механизм обмена ключами в IKE берется из протокола Oakley (RFC-2412). Основой протокола обмен ключами Oakley является алгоритм Диффи-Хелмана (см. http://book.itep.ru/6/difi_646.htm), дополненный некоторыми усовершенствованиями. В частности в каноническом алгоритме Диффи- Хелмана отсутствует аутентификация партнеров, что допускает возможность атаки с подменом ключей. В IPsec версии алгоритма, аутентификация партнеров является обязательной процедурой. Заметим, что IPsec осуществляет пересылку ключей через порт 500/udp. В IPsec при обмене ключами предусмотрено использование сертификатов. Для получения сертификата посылается запрос в сертификационный центр СА (Certificate Authority). Сертификация включает в себя следующие операции: Клиент генерирует пару ключей (общедоступный и секретный). Далее он готовит неподписанный сертификат, который содержит идентификатор клиента и его общедоступный ключ. После этого клиент посылает этот сертификат в СА, шифруя его открытым ключом СА. СА формирует хэш для присланного неподписанного сертификата и шифрует его своим секретным ключом. СА добавляет сформированную так электронную подпись к неподписанному сертификату и посылает уже подписанный сертификат клиенту. Клиент теперь может послать свой подписанный сертификат любому другому пользователю. Получатель сертификата может легко его проверить, если располагает общедоступным ключом СА. Клиенты могут пользоваться одним и тем же СА или быть клиентами разных СА. На практике обычно реализуется иерархическая структура СА. В Интернет имеется огромное количество материалов по проблематике IPsec, но начинать всегда лучше с документов RFC (Requests for Comment), которые со временем обретают статус стандартов. В декабре 2005, весь набор документов RFC по IPsec был обновлен IETF, а серия RFC 43xx по большей части заменила серию RFC 24xx. 93 3 вариант: Протокол IPsec – это открытый промышленный стандарт IP-сетей для защиты передаваемых по сетям IP-пакетов. IPsec является неотъемлемой частью протокола IPv6 и расширением существующей версии протокола IPv4. Протокол IPsec работает на сетевом уровне (уровень 3 модели OSI). Это делает IPsec гибким, поскольку он может использоваться для защиты любых протоколов, базирующихся на транспорте TCP/UDP. IPSec обеспечивает аутентификацию источника данных, шифрование передаваемых IP пакетов, проверку их целостности и подлинности, защиту от навязывания повторных сообщений, а также частичную защиту от анализа трафика. протокол IPsec представляет собой комбинацию нескольких групп протоколов: - Протокол согласования параметров виртуального канала и управления ключами (Internet Security Association Key Management Protocol — ISAKMP) обеспечивает общее, управление защищенным виртуальным соединением, включая согласование используемых алгоритмов криптозащиты, а также генерацию и распределение ключевой информации. - аутентификации(AH), - шифрования данных(ESP). Протокол ISAKMP сам по себе не регламентирует какой-либо конкретный алгоритм обмена ключами, он содержит в себе описание ряда сообщений, которые позволяют согласовать использование алгоритмов обмена ключами. Согласование осуществляется в два этапа: - Узлы ISAKMP согласуют механизмы защиты дальнейшего обмена данными, путем установления SA(Security Association - ассоциация безопасности - определяет параметры и процедуры, специфические для конкретного соединения.). Эта ассоциация служит для защиты последующих операций и отличается от прочих SA. - Протокол ISAKMP устанавливает SA для других протоколов, например, из семейства IPsec. Протокол AH обеспечивает проверку подлинности, целостность и отсутствие повторов для всего IP - пакета (заголовка IP и полезных данных). AH подписывает весь пакет. Данные не шифруются, поэтому конфиденциальность не обеспечивается. Данные доступны для чтения, но защищены от изменения. Протокол AH использует для подписания пакетов алгоритмы хэширования HMAC. Протокол ESP. Обобщенно все функции защиты, поддерживаемые протоколом инкапсуляции защищенных данных ESP, можно свести к аутентификации и криптографическому закрытию передаваемых IP-пакетов. В протоколе ESP функции аутентификации и криптографии могут быть задействованы либо вместе, либо отдельно друг от друга. При выполнении шифрования без аутентификации появляется возможность использования механизма трансляции сетевых адресов NAT, поскольку в этом случае адреса в заголовках IP-пакетов можно модифицировать. Независимо от режима использования протокола ESP его заголовок формируется как инкапсулирующая оболочка для зашифрованного содержимого. 94 82. Обеспечение безопасного доступа пользователей Internet к ресурсам частной (private) сети 82. Обеспечение безопасного доступа пользователей Internet к ресурсам частной (private) сети Работу любой технологии, обеспечивающей защищенную передачу данных через неподконтрольную, а потому всегда потенциально опасную среду, можно условно разделить на две фазы. Первая фаза представляет собой установление соединения с обязательной проверкой подлинности взаимодействующих сторон (аутентификацию), применением политик безопасности (авторизацию) и установлением ключей шифрования для второй фазы. На второй фазе происходит непосредственно передача зашифрованных ранее установленными ключами данных, целостность (неизменностьФ) которых обязательно проверяется при приеме. Первая фаза на примере технологии IPSec Easy VPN Перед тем, как пользователь сможет передавать зашифрованные данные в удаленную сеть, он должен осуществить процесс подключения. При этом происходит процедура аутентификации, во время которой пользователь должен подтвердить, что он именно тот, за кого себя выдает, и действительно имеет право произвести удаленное подключение. Аналогом этого процесса из реальной жизни является предъявление паспорта сотруднику банка. В IPSec VPN сетях для аутентификации удаленных пользователей может использоваться заранее заданное на клиентских устройствах и сервере секретное значение (ключ), цифровые сертификаты формата x.509, основанные на использовании технологий цифровой подписи, групповые и персональные имена пользователей и пароли, а так же различные комбинации этих методов. В настоящее время наиболее защищенным способом аутентификации является использование цифровых сертификатов. Аутентификация с использованием цифровых сертификатов не подвержена наиболее совершенному методу атак «man in the middle» (MITM, человек посередине). Суть этого метода состоит в том, что злоумышленник некоторым образом получает возможность пропустить через себя весь трафик между двумя взаимодействующими устройствами. При этом он выступает в качестве своеобразного proxy-сервера, который может выборочно пропускать через себя трафик легитимных устройств, подменяя часть данных на собственные. Из перечисленных методов только использование цифровых сертификатов позволяет полностью исключить возможность успешного проведения подобного типа атак. Но для того, чтобы использовать цифровые сертификаты, в сети обязательно должен присутствовать сервер цифровых сертификатов (Certification Authority). Операционная система Cisco IOS, под управлением которой работают все маршрутизаторы Cisco, содержит встроенный сервер цифровых сертификатов, предназначенный для использования совместно с технологиями IPSec VPN и SSL VPN. Remote Access VPN Представь себе следующую ситуацию. Тебе нужно обеспечить удаленный доступ к корпоративной сети нескольким десяткам сотрудников. Ты можешь использовать для этого технологию шифрованных VPN. Но чем больше сотрудников будет пользоваться удаленным доступом, тем больше компьютеров со всеми детальными политиками безопасности нужно будет настроить. Лучше Cisco Easy VPN. Ее основное преимущество - использование «глупых» клиентов, 95 конфигурирование которых сведено к минимуму. Когда пользователю уже выдан цифровой сертификат, для создания VPN-соединения в Cisco Easy VPN Client достаточно настроить IP-адрес маршрутизатора компании, подключенного к интернету. Никаких настроек, связанных с использованием алгоритмов шифрования, аутентификации, хеширования для обеспечения целостности, распространения ключей шифрования для протоколов второй фазы и т.п., производить не нужно. Причем для установления VPN-соединения клиентским устройствам совсем не обязательно иметь публичные IP-адреса. За счет передачи IPSec трафика поверх протокола TCP или UDP пользователи могут находиться за устройствами, осуществляющими трансляцию адресов с использованием технологий NAT/PAT. При выдаче сертификата пользователю, ему автоматически передается корневой сертификат сервера цифровых сертификатов, содержащий только публичный ключ. Он будет использоваться при подключении перед аутентификацией, для проверки подлинности сервера, к которому производится подключение, и исключения атаки MITM. Итак, есть задача — в короткие сроки развернуть для сотрудников компании защищенную по последнему слову техники сеть удаленного доступа. При этом нужно постараться избежать использования дополнительных компонентов, усложняющих и удорожающих решение. Для этого возьмем маршрутизатор Cisco 857W. Помимо всех функций маршрутизации и обеспечения безопасности, у этого устройства есть еще и встроенная беспроводная точка доступа и RADIUS-сервер. Наличие RADIUS-сервера позволяет защитить небольшую сеть на несколько точек доступа в соответствии с последними рекомендациями WiFi-форума по защите корпоративных беспроводных сетей. 83. Подключение удаленного VPN-клиента по протоколу IPSec Описанные ниже действия выполняются при попытке подключения VPN-клиента, использующего протокол L2TP/IPSec (Layer Two Tunneling Protocol over Internet Protocol security, туннельный протокол второго уровня поверх безопасности протокола IP), к VPN-серверу с протоколом L2TP/IPSec под управлением Windows Server 2003. · На основе сертификатов компьютеров и процесса согласования обмена ключами в Интернете создается сопоставление безопасности IPSec. · VPN-клиент создает туннель L2TP к VPN-серверу. · Сервер отправляет запрос клиенту. · Клиент отправляет зашифрованный ответ серверу. · Сервер сверяет ответ с базой данных учетных записей пользователей. · Если учетная запись действительна, а подключение авторизовано, сервер использует политику удаленного доступа и параметры учетной записи пользователя для VPN-клиента. Примечание Пункты 3 - 4 предполагают, что VPN-клиент и VPN-сервер используют протокол проверки подлинности MS-CHAP v1 или CHAP. Отправка учетных данных пользователей для других протоколов проверки подлинности может отличаться от описанной выше. 96 |