безопасность сетей и каналов передачи данных. Тема Проблемы информационной безопасности сетей Содержание темы
 Скачать 1.46 Mb.
|
|
Протокол инкапсулирующей защиты ESP. Протокол инкапсулирующей защиты содержимого ESP (Encapsulating Security Payload) обеспечивает конфиденциальность, аутентичность, целостность и защиту от повторов для пакетов данных. Следует отметить, что конфиденциальность данных протокол ESP обеспечивает всегда, а целостность и аутентичность являются для него опциональными требованиями. Конфиденциальность данных обеспечивается путем шифрования содержимого отдельных пакетов. Целостность и аутентичность данных обеспечиваются на основе вычисления дайджеста. Из приведенного перечня функций по защите информационного обмена видно, что функциональность протокола ESP шире, чем у протокола АН. Протокол ESP поддерживает все функции протокола АН по защите зашифрованных потоков данных от подлога, воспроизведения и случайного искажения, а также обеспечивает конфиденциальность данных. В протоколе ESP функции аутентификации и криптографического закрытия могут быть задействованы либо вместе, либо отдельно друг от друга. При выполнении шифрования без аутентификации появляется возможность использования механизма трансляции сетевых адресов NAT (Network Address Translation), поскольку в этом случае адреса в заголовках IP пакетов можно модифицировать. Для решения своих задач протокол ESP использует заголовок формата, приведенного на Рис. 37.  Рис. 37. Формат заголовка ESP Заголовок ESP содержит следующие поля: индекс параметров защиты SPI {Security Parameters Index) используется совместно с адресом получателя и протоколом защиты (АН или ESP). Указывает соответствующее соглашение SA. Получатель использует это значение для определения соглашения о защите, с которым идентифицируется этот пакет; порядковый номер SN (Sequence Number) обеспечивает защиту от повторов для SA. Представляет собой 32битное число, первоначально равное 1 и увеличивающееся с шагом 1. Оно не повторяется циклически и указывает номер пакета, отсылаемого по данному соглашению. Получатель проверяет это поле с целью удостовериться, что пакета с таким номером принято еще не было. Если же такой пакет уже был, он не принимается; данные (Payload Data); заполнитель (Padding) дописывается от 0 до 255 байт для 32битного выравнивания с размером блока шифра; длина заполнителя (Padding Length) указывает длину поля заполнителя в байтах; следующий заголовок (Next Header) указывает природу передаваемых данных (например, TCP или UDP); аутентификационные данные (Authentication Data) содержат код проверки целостности ICV (Integrity Check Value) и код аутентичности сообщения, используемые для проверки подлинности отправителя и целостности сообщения. Значение ICV вычисляется для заголовка ESP, передаваемых данных и концевой метки ESP. Поле Authentication Data помещается в заголовок ESP только при включенной аутентификации. Нетрудно заметить, что некоторые поля заголовка ESP аналогичны полям заголовка АН: Next Header, SPI, SN, Authentication Data. Но есть и два дополнительных поля заполнитель (Padding) и длина заполнителя (Pad Length). Заполнитель может понадобиться в трех случаях. Во-первых, для нормальной работы некоторых алгоритмов шифрования необходимо, чтобы шифруемый текст содержал кратное число блоков определенного размера. Во-вторых, формат заголовка ESP требует, чтобы поле данных заканчивалось на границе четырех байтов. В-третьих, заполнитель можно использовать для сокрытия действительного размера пакета в целях обеспечения так называемой частичной конфиденциальности трафика, хотя протокол ESP ограничивает возможности маскировки 255 байтами заполнителя; это сделано для того, чтобы не слишком снижалась полезная пропускная способность канала связи из-за большого объема избыточных данных. Как видно из Рис. 37., заголовок делится на две части, разделяемые полем данных (полезная нагрузка Payload Data). Первая часть, которая далее будет обозначаться как заголовок ESP, образуется двумя полями SPI и SN и размещается перед полем данных. Остальные служебные поля протокола ESP расположены в конце пакета. Непосредственно за полем данных следует так называемый трейлер, в который входят заполнитель (Padding), длина заполнителя (Pad Length), а также указатель на протокол следующего уровня (Next Header). Завершает пакет поле контроля целостности (Authentication Data). В том случае, когда при установлении безопасной ассоциации принято решение не использовать возможности ESP по обеспечению целостности, это поле отсутствует. ПО перечисленных протоколов (утилиты шифрования, цифровой подписи и пр.) может функционировать на серверах или компьютерах конечных пользователей. Однако чаще его устанавливают на маршрутизаторах или специальных устройствах, которые в архитектуре IPSec именуются шлюзами безопасности (security gateway). Протокол ESP также используют в двух режимах транспортном и туннельном. На Рис. 38 показано расположение ESP заголовка в туннельном и транспортном режимах. В транспортном режиме зашифрованные данные транспортируются непосредственно между хостами. В транспортном режиме протокола ESP заголовок исходного IP пакета остается внешним. Заголовок ESP помещается в передаваемый пакет между заголовками протоколов третьего (IP) и четвертого (например, TCP) уровней. Следует заметить, что поля протокола ESP следуют после стандартного IP заголовка, а это означает, что такой пакет может маршрутизироваться в сети с помощью обычного оборудования, поддерживающего IP.  IP пакет после применения протокола ESP в транспортном режиме IP пакет после применения протокола ESP в туннельном режиме:  Рис. 38. IP пакет после применения протокола ESP в транспортном и туннельном режимах Шифрованию подвергаются только данные исходного IP пакета (пакет верхнего уровня) и заключительная часть ESP заголовка (ESP trailer). В этом режиме ESP не шифрует заголовок IP пакета, иначе маршрутизатор не сможет прочитать поля заголовка и корректно осуществить продвижение пакета между сетями. В число шифруемых полей не попали также поля SPI и SN, которые должны передаваться в открытом виде, для того чтобы прибывший пакет можно было отнести к определенной ассоциации SA и защититься от ложного воспроизведения пакета. В отличие от протокола АН, контроль целостности и аутентичности данных в протоколе ESP не распространяется на заголовок исходного пакета, и по этой причине имеет смысл применять оба протокола совместно ESP для шифрования, а АН для контроля целостности. Таким образом, адресная информация (IP адреса отсылающей и принимающей сторон) видна при пересылке пакета по сети, и несанкционированное изменение этих IP адресов не будет замечено. В туннельном режиме основная роль отводится шлюзам безопасности, поскольку предполагается, что клиентские станции (или серверы) могут не поддерживать IPSec и отправляют в сеть обычный IP трафик. Перед тем как достичь каналов глобальной сети, каждый исходный IP пакет сначала попадает в шлюз, который помещает этот пакет целиком в «оболочку» IPSec, зашифровывая его содержимое вместе с исходным IP заголовком. Чтобы обеспечить возможность маршрутизации получившегося пакета, шлюз снабжает его новым IP заголовком и только после этого отправляет в сеть. Шлюз, находящийся на противоположном конце соединения, расшифровывает этот пакет и передает его на оконечное устройство в первоначальном виде. Описанная процедура называется туннелированием. Из Рис. 38. видно, что в туннельном режиме в качестве внешнего заголовка создается новый заголовок IP. Весь исходный IP пакет (и данные и заголовок IP) и заключительная часть заголовка ESP (трейлер ESP) шифруются. Поэтому адресная информация исходного IP пакета не доступна для просмотра. Заголовок внешнего IP пакета протоколом ESP не защищается. Туннелирование позволяет распространить действие средств защиты на сетевой уровень модели OSI и, в частности, скрыть истинные адреса источника и получателя. При этом уменьшается риск атак, основанных на детальном анализе трафика. Сравнивая протоколы ESP и АН можно заметить, что они дублируют функциональность друг друга в области обеспечения аутентификации данных. Главным отличием протокола АН от ESP в данном вопросе является то, что протокол АН обеспечивает аутентификацию всего пакета (и IP заголовка и самих данных), в то время как протокол ESP аутентифицирует только данные из пакета (см. Рис. 38.). При шифровании в протоколе ESP используется симметричный секретный ключ, т. е. передаваемые данные зашифровываются и расшифровываются с помощью одного и того же ключа. Для протокола ESP также определен перечень обязательных алгоритмов шифрования DES, MD5 и SHA1. При аутентификации данных протокол ESP использует те же алгоритмы НМАС, что и протокол АН (использующие MD5 или SHA1 в качестве функции хеширования). Однако способы применения различаются (см. Рис. 38). В транспортном режиме: протокол ESP аутентифицирует только данные из пакета, не затрагивая IP заголовка; протокол АН защищает и данные и оба заголовка. В туннельном режиме: аутентификация в ESP протоколе применяется к данным пакета и исходному IP заголовку, но не затрагивает новый IP заголовок; протокол АН аутентифицирует данные, АН заголовок и оба IP заголовка. Протокол ESP может применяться отдельно или совместно с протоколом АН. При совместном использовании протоколы АН и ESP могут комбинироваться разными способами. Если используется транспортный режим, то аналогично тому, как в рамках ESP аутентификация идет следом за шифрованием, протокол АН должен применяться после протокола ESP. В туннельном режиме протоколы АН и ESP применяются к разным вложенным пакетам и, кроме того, допускается многократная вложенность туннелей с различными начальными и/или конечными точками. Алгоритмы аутентификации и шифрования в IPSec. Стек протоколов IPSec представляет собой согласованный набор открытых стандартов, имеющий вполне определенное ядро, и в то же время он может быть достаточно просто дополнен новыми протоколами, алгоритмами и функциями. Благодаря модульной структуре протоколы АН и ESP допускают применение пользователями по их согласованному выбору различных криптографических алгоритмов аутентификации и шифрования. Для шифрования данных в IPSec (протокол ESP) может быть применен практически любой симметричный алгоритм шифрования, использующий секретные ключи. Для обеспечения целостности и аутентификации данных (протоколы АН и ESP) используется один из приемов шифрования шифрование с помощью односторонней функции (one way function), называемой также хэш функцией (hash function) или дайджест функцией (digest function). Эта функция, примененная к шифруемым данным, дает в результате значение дайджест, состоящее из фиксированного небольшого числа байт. Дайджест передается в IP пакете вместе с исходным сообщением. Получатель, зная, какая односторонняя функция шифрования была применена для составления дайджеста, заново вычисляет его, используя исходное сообщение. Если значения полученного и вычисленного дайджестов совпадают, это значит, что содержимое пакета во время передачи не было подвергнуто никаким изменениям. Знание дайджеста не дает возможности восстановить исходное сообщение и поэтому не может быть использовано для защиты конфиденциальности, но оно позволяет проверить целостность данных. Дайджест является своего рода контрольной суммой для исходного сообщения. В отличие от традиционной контрольной суммы при вычислении дайджеста используется секретный ключ. Если для получения дайджеста применялась односторонняя функция с параметром (в качестве которого выступает секретный ключ), известным только отправителю и получателю, любая модификация исходного сообщения будет немедленно обнаружена. В целях обеспечения совместимости продуктов разных производителей рабочая группа IETF определила базовый набор поддерживаемых функций и алгоритмов, который должен быть однотипно реализован во всех продуктах, поддерживающих IPSec. На сегодня определены 2 алгоритма аутентификации и 7 алгоритмов шифрования. В настоящий момент для протоколов АН и ESP зарегистрировано 2 алгоритма аутентификации HMACMD5 и НМАСSHA1. Алгоритм НМАС (Keyed Hashing for Message Authentication Code) определяется стандартом RFC 2104. Функции MD5 (Message Digest version 5, стандарт RFC 1321) и SHA1 (Secure Hash Algorithm version 1, стандарт FIPS 1801) являются функциями хеширования. Алгоритмы HMACMD5 и HMACSHA1 являются алгоритмами аутентификации с общим секретным ключом. Секретный ключ имеет длину 128 бит в случае MD5 и 160 бит в случае SHA1. Если секретный ключ известен только передающей и принимающей сторонам, это обеспечит аутентификацию источника данных, а также целостность пакетов, пересылаемых между двумя сторонами. Ключи для НМАС генерируются посредством процедуры ISAKMP/Oakley. Для обеспечения совместимости оборудования и ПО на начальной стадии реализации протокола IPSec один из зарегистрированных алгоритмов аутентификации принято использовать по умолчанию. В качестве такого алгоритма определен алгоритм HMAC-MD5. Структура алгоритма НМАС показана на Рис. 39. Принцип действия алгоритма НМАС заключается в двухкратной обработке пакета функцией хеширования, управляемой ключом аутентификации (например, функцией хеширования MD5). Как видно из рисунка, оба раза в обрабатываемые данные включается секретный ключ, который обеспечивает аутентификацию передаваемой информации. Полученная контрольная сумма помещается в заголовок АН протокола. Проверка аутентификации на другой стороне осуществляется путем повторного вычисления контрольной суммы для пришедшего пакета с использованием такого же ключа и сравнения полученного результата с присланным. Структура алгоритма НМАС показана на Рис. 39. Принцип действия алгоритма НМАС заключается в двухкратной обработке пакета функцией хеширования, управляемой ключом аутентификации (например, функцией хеширования MD5). Как видно из рисунка, оба раза в обрабатываемые данные включается секретный ключ, который обеспечивает аутентификацию передаваемой информации. Полученная контрольная сумма помещается в заголовок АН протокола. Проверка аутентификации на другой стороне осуществляется путем повторного вычисления контрольной суммы для пришедшего пакета с использованием такого же ключа и сравнения полученного результата с присланным.  Рис. 39. Структура HMAC алгоритма Алгоритм НМАС реализует симметричную схему аутентификации, используя параметр проверки целостности пакета ICV (Integrity Check Value). По сути, он представляет собой цифровую подпись, помещаемую в поле аутентификации и позволяющую отправителю подписать результат предварительного хеширования содержательной части пакета ESP. Анализ содержимого этого поля дает возможность получателю идентифицировать источник данных и убедиться в том, что они не были изменены в процессе передачи. Если для протокола ESP функции аутентификации являются факультативными, то для протокола АН процесс аутентификации обязателен. Для протокола ESP зарегистрировано несколько алгоритмов шифрования. Чаще всего в качестве алгоритмов шифрования для ESP применяются DES (Data Encryption Standard), 3DES (тройной DES) и новый стандарт шифрования AES (Advanced Encryption Standard). Для обеспечения IPSec совместимости по умолчанию в качестве алгоритма шифрования стандартом предусмотрен симметричный метод DESCBC (Cipher Block Chaining) с явно заданным вектором инициализации IV и с 56 разрядным ключом. Алгоритм AES повсюду встраивается в стандарт IPSec как альтернатива DES и 3DES. Выбор алгоритма шифрования целиком зависит от разработчика. Возможность выбора алгоритма шифрования предоставляет пользователю дополнительное преимущество: злоумышленник должен не только вскрыть шифр, но и определить, какой именно шифр ему надо вскрывать, а вместе с необходимостью подбора ключей, это еще более уменьшает его шансы своевременно расшифровать данные пользователя. IPSec может работать совместно с протоколами L2TP или L2F, которые выполняют только туннелирование, но не обеспечивают шифрование и аутентификацию данных. Эти протоколы создают через Internet туннель для пакетов любых протоколов, упаковывая их в пакеты IP. Когда трафик с помощью L2F или L2TP оказывается упакованным в пакеты IP, то дальше для его защиты можно использовать IPSec. В результате комбинирование IPSec с протоколами туннелирования типа L2F/L2TP позволяет решить задачу защиты данных для протоколов, отличных от IP. Алгоритмическая независимость протоколов АН и ESP требует предварительного согласования взаимодействующими сторонами набора применяемых алгоритмов и их параметров. Вопрос 3. Протокол управления криптоключами IKE. Протоколы ESP и АН позволяют реализовать важнейшие атрибуты защищенной передачи конфиденциальность связи, аутентификацию сторон и целостность данных. Однако их функции теряют всякую ценность в отсутствие мощной поддерживающей инфраструктуры, которая обеспечивала бы распределение ключей и согласование протоколов между участниками обмена. Роль такой инфраструктуры в IPSec выполняет группа протоколов IKE (Internet Key Exchange). Это название пришло в 1998 г. на смену более раннему ISAKMP/Oakley, которое непосредственно указывало на происхождение средств управления ключами в составе IPSec. Протокол ISAKMP {Internet Security Association and Key Management Protocol), описанный в документе RFC 2408, позволяет согласовывать алгоритмы и математические структуры (так называемые мультипликативные группы, определенные на конечном поле) для процедуры обмена ключами Диффи Хеллмана, а также процессов аутентификации. Протокол Oakley, описанный в RFC 2412, основан на алгоритме Диффи Хеллмана и служит для организации непосредственного обмена ключами. Протоколы IKE решают три задачи: 1. осуществляют аутентификацию взаимодействующих сторон, согласовывают алгоритмы шифрования и характеристики ключей, которые будут использоваться в защищенном сеансе обмена информацией; 2. обеспечивают создание, управление ключевой информации соединения, непосредственный обмен ключами (в том числе возможность их частой смены); 3. управляют параметрами соединения и защитой от некоторых типов атак, контролируют выполнение всех достигнутых соглашений. Разработчики IPSec начали свою деятельность с решения последней из перечисленных задач. В результате на свет появилась концепция защищенных виртуальных соединений или безопасных ассоциаций SA (Security Associations). Установление безопасной ассоциации SA. Основой функционирования IPSec являются защищенные виртуальные соединения или безопасные ассоциации SA (Security Associations). Для того чтобы протоколы АН и ESP могли выполнять свою работу по защите передаваемых данных, между двумя конечными точками должна быть сформирована ассоциация SA соглашение о защите обмена данными между двумя взаимодействующими партнерами. Установление SA должно начинаться со взаимной аутентификации сторон, потому что меры безопасности теряют всякий смысл, если данные передаются или принимаются неавторизованными пользователями. Процедуры установления SA оправданы лишь в том случае, если у каждой из сторон имеется полная уверенность в том, что ее партнер именно тот, за кого он себя выдает. Для выполнения аутентификации сторон в IKE применяются два основных способа. Первый способ основан на использовании разделяемого секрета. Перед инициализацией IPSecустройств, образующих безопасные ассоциации, в их БД помещается предварительно распределенный разделяемый секрет. Цифровая подпись на основе односторонней функции, например, MD5, использующей в качестве аргумента этот предварительно распределенный секрет, доказывает аутентичность противоположной стороны. Второй способ основан на использовании технологии цифровой подписи и цифровых сертификатов стандарта Х.509. Каждая из сторон подписывает свой цифровой сертификат своим закрытым ключом и передает эти данные противоположной стороне. Если подписанный сертификат расшифровывается открытым ключом отправителя, то это удостоверяет тот факт, что отправитель, предоставивший данные, действительно обладает ответной частью данного открытого ключа соответствующим закрытым ключом. Однако следует отметить, что для удостоверения аутентичности стороны нужно еще убедиться в аутентичности самого сертификата, и для этого сертификат должен быть подписан не только его владельцем, но и некоторой третьей стороной, выдавшей сертификат и вызывающей доверие. В архитектуре IPSec эта третья сторона именуется органом сертификации СА (Certification Authority). Этот орган призван засвидетельствовать подлинность обеих сторон и должен пользоваться полным доверием сторон, а его открытый ключ известен всем узлам, использующим его сертификаты для удостоверения личностей друг друга. После проведения взаимной аутентификации взаимодействующие стороны могут непосредственно перейти к согласованию параметров защищенного канала. Выбираемые параметры SA определяют: протокол, используемый для обеспечения безопасности передачи данных; алгоритм аутентификации протокола АН и его ключи; алгоритм шифрования, используемый протоколом ESP, и его ключи; наличие или отсутствие криптографической синхронизации; способы защиты сеанса обмена; частоту смены ключей и ряд других параметров. Важным параметром SA является так называемый криптографический материал, т. е. секретные ключи, используемые в работе протоколов АН и ESP. Сервисы безопасности, предлагаемые IPSec, используют для формирования криптографических ключей разделяемые секреты. Параметры SA должны устраивать обе конечные точки защищенного канала. Поэтому при использовании автоматической процедуры установления SA протоколы IKE, работающие по разные стороны канала, выбирают параметры в ходе переговорного процесса. Для каждой задачи, решаемой протоколами АН и ESP, предлагается несколько схем аутентификации и шифрования это делает IPSec очень гибким средством. Безопасная ассоциация SA представляет собой в IPSec однонаправленное логическое соединение, поэтому при двустороннем обмене данными необходимо установить две ассоциации SA. В рамках одной ассоциации SA может работать только один из протоколов защиты данных либо АН, либо ESP, но не оба вместе. Для идентификации каждой SA предназначен индекс параметров безопасности SPI (Security Parameters Index). Этот индекс включается в заголовки защищенных IPSec-пакетов, чтобы принимающая сторона смогла правильно их расшифровать и аутентифицировать, воспользовавшись указанной безопасной ассоциацией. Система IPSec допускает применение ручного и автоматического способа установления SA. При ручном способе администратор конфигурирует каждый конечный узел таким образом, чтобы они поддерживали согласованные параметры ассоциации, включая и секретные ключи. Для автоматического установления ассоциации необходим соответствующий протокол, в качестве которого в стандартах IPSec определен протокол IKE. Он является комбинацией протоколов ISAKMP, Oakley и SKEME. Протокол согласования параметров виртуального канала и управления ключами ISAKMP (Internet Security Association Key Management Protocol) описывает базовую технологию аутентификации, обмена ключами и согласования остальных параметров IPSec туннеля при создании SA, однако сами протоколы аутентификации сторон и обмена ключами в нем детально не определены. Поэтому при разработке протокола IKE общие правила и процедуры протокола ISAKMP дополнены процедурами аутентификации и обмена ключами, взятыми из протоколов Oakley и SKEME. Поскольку протокол IKE использует для управления ассоциациями алгоритмы и форматы протокола ISAKMP, названия этих протоколов иногда используют как синонимы. На основании протокола ISAKMP согласование параметров защищенного взаимодействия необходимо как при формировании IPSec-туннеля, так и при формировании в его рамках каждого защищенного однонаправленного соединения. Параметры IPSec-туннеля согласуются по протоколу ISAKMP/Oakley. Параметры каждого защищенного однонаправленного соединения согласуются в рамках сформированного IPSec-туннеля и образуют SA. Криптографические ключи для каждого защищенного однонаправленного соединения генерируются на основе ключей, выработанных в рамках IPSec туннеля. При этом учитываются алгоритмы аутентификации и шифрования, используемые в протоколах аутентифицирующего заголовка (АН) и инкапсулирующей защиты (ESP). Стандарты IPSec позволяют шлюзам использовать как одну ассоциацию SA для передачи трафика всех взаимодействующих через Internet хостов, так и создавать для этой цели произвольное число ассоциаций SA, например по одной на каждое соединение TCP. Базы данных SAD и SPD. IPSec предлагает различные методы защиты трафика. В каждом узле, поддерживающем IPSec, используются БД двух типов: база данных безопасных ассоциаций SAD (Security Associations Database); база данных политики безопасности SPD (Security Policy Database). При установлении SA две вступающие в обмен стороны принимают ряд соглашений, регламентирующих процесс передачи потока данных между ними. Соглашения представляются в виде набора параметров. Для SA такими параметрами являются, в частности, тип и режим работы протокола защиты (АН или ESP), методы шифрования, секретные ключи, значение текущего номера пакета в ассоциации и другая информация. Объединение служебной информации в рамках SA предоставляет пользователю возможность сформировать разные классы защиты, предназначенные, например, для электронного общения с разными «собеседниками». Другими словами, применение структур SA открывает путь к построению множества виртуальных частных сетей, различающихся своими параметрами. Наборы текущих параметров, определяющих все активные ассоциации, хранятся на обоих оконечных узлах защищенного канала в виде SAD. Каждый узел IPSec поддерживает две базы SAD одну для исходящих ассоциаций, другую для входящих. SPD задает соответствие между IP пакетами и установленными для них правилами обработки. При обработке пакетов БД SPD используются совместно с БД SAD. SPD представляет собой упорядоченный набор правил, каждое из которых включает совокупность селекторов и допустимых политик безопасности. Селекторы служат для отбора пакетов, а политики безопасности задают требуемую обработку. Такая БД формируется и поддерживается на каждом узле, где установлено ПО IPSec. Вопрос 4. Особенности реализации средств IPSec. Выше было рассмотрено, что протоколы АН или ESP могут защищать передаваемые данные в двух режимах: туннельном, при котором IP пакеты защищаются целиком, включая их заголовки, и транспортном, обеспечивающим защиту только содержимого IP пакетов. Основным режимом является туннельный. В туннельном режиме исходный пакет помещается в новый IP пакет и передача данных по сети выполняется на основании заголовка нового IP пакета. При работе в этом режиме каждый обычный П'пакет помещается целиком в криптозащищенном виде в конверт IPSec, а тот в свою очередь инкапсулируется в другой защищенный IP пакет. Туннельный режим обычно реализуют на специально выделенных шлюзах безопасности, в роли которых могут выступать маршрутизаторы или МЭ. Между такими шлюзами и формируются защищенные туннели IPSec. После приема на другой стороне туннеля защищенные IP пакеты «распаковываются» и полученные исходные IP пакеты передаются компьютерам приемной локальной сети по стандартным правилам. Туннелирование IP пакетов полностью прозрачно для обычных компьютеров в локальных сетях, являющихся держателями туннелей. На оконечных системах туннельный per жим может использоваться для поддержки удаленных и мобильных пользователей. В этом случае на компьютерах этих пользователей должно быть установлено ПО, реализующее туннельный режим IPSec. В транспортном режиме передача IP пакета через сеть выполняется с помощью исходного заголовка этого пакета. В конверт IPSec в криптозащищенном виде помещается только содержимое исходного П'пакета и к полученному конверту добавляется исходный Бэзаголовок. Транспортный режим быстрее туннельного и разработан для применения на оконечных системах. Этот режим может использоваться для поддержки удаленных и мобильных пользователей, а также защиты информационных потоков внутри локальных сетей. Следует отметить, что работа в транспортном режиме отражается на всех входящих в группу защищенного взаимодействия системах, и в большинстве случаев требуется перепрограммирование сетевых приложений. Основные схемы применения IPSec. Применение туннельного или транспортного режима зависит от требований, предъявляемых к защите данных, а также от роли узла, в котором работает IPSec. Узлом, завершающим защищенный канал, может быть хост (конечный узел) или шлюз (промежуточный узел). Соответственно различают три основные схемы применения IPSec: 1) хост-хост; 2) шлюз-шлюз; 3) хост-шлюз. В схеме 1 защищенный канал, или, что в данном контексте одно и то же, SA, устанавливается между двумя конечными узлами сети, т. е. хостами HI и Н2 (Рис. 40.). Протокол IPSec в этом случае работает на конечном узле и защищает данные, поступающие на него. Защищенный канал, SA  Рис. 40. Схема хост-хост Для хостов, поддерживающих IPSec, разрешается использовать как транспортный режим, так и туннельный. В соответствии со схемой 2 защищенный канал устанавливается между двумя промежуточными узлами, называемыми шлюзами безопасности SG1 и SG2 (Security Gateway), на каждом из которых работает протокол IPSec (Рис. 41.).  Рис. 41 Схема шлюз-шлюз Защищенный обмен данными может происходить между любыми двумя конечными узлами, подключенными к сетям, которые расположены позади шлюзов безопасности. От конечных узлов поддержка протокола IPSec не требуется, они передают свой трафик в незащищенном виде через заслуживающие доверие сети Intranet предприятия. Трафик, направляемый в общедоступную сеть, проходит через шлюз безопасности, который и обеспечивает его защиту с помощью IPSec, действуя от своего имени. Шлюзам разрешается использовать только туннельный режим работы, хотя они могли бы поддерживать и транспортный режим, но он в этом случае малоэффективен. При защищенном удаленном доступе часто применяется схема 3 хост-шлюз (Рис. 42.).  Рис. 42. Схема шлюз-шлюз, дополненная каналом хост-хост Здесь защищенный канал организуется между удаленным хостом H1, на котором работает IPSec, и шлюзом SG, защищающим трафик для всех хостов, входящих в сеть Intranet предприятия. Удаленный хост может использовать при отправке пакетов шлюзу как транспортный, так и туннельный режим, шлюз же отправляет пакеты хосту только в туннельном режиме. Эту схему можно модифицировать, создав параллельно еще один защищенный канал между удаленным хостом H1 и каким-либо хостом Н2, принадлежащим внутренней сети, защищаемой шлюзом. Такое комбинированное использование двух SA позволяет надежно защитить трафик и во внутренней сети. Рассмотренные схемы построения защищенных каналов на базе IPSec широко применяются при создании разнообразных виртуальных защищенных сетей VPN. Их спектр варьируется от провайдерских сетей, позволяющих управлять обслуживанием клиентов непосредственно на их площадях, до корпоративных сетей VPN, разворачиваемых и управляемых самими компаниями. На базе IPSec успешно реализуются виртуальные защищенные сети любой архитектуры, включая VPN с удаленным доступом (Remote Access VPN), внутрикорпоративные VPN (Intranet VPN) и межкорпоративные VPN (Extranet VPN). Преимущества средств безопасности IPSec. Система стандартов IPSec вобрала в себя прогрессивные методики и достижения в области сетевой безопасности, завоевала признание специалистов как надежная и легко интегрируемая система безопасности для П'сетей. Система IPSec прочно занимает сегодня лидирующие позиции в наборе стандартов для создания VPN. Этому способствует ее открытое построение, способное включать все новые достижения в области криптографии. IPsec позволяет защитить сеть от большинства сетевых атак,«сбрасывая» чужие пакеты еще до того, как они достигнут уровня IP на принимающем компьютере. В защищаемый компьютер или сеть могут войти только пакеты от зарегистрированных партнеров по взаимодействию. IPsec обеспечивает: аутентификацию доказательство отправки пакетов вашим партнером по взаимодействию, т. е. обладателем разделяемого секрета; целостность невозможность изменения данных в пакете; конфиденциальность невозможность раскрытия передаваемых данных; надежное управление ключами протокол IKE вычисляет разделяемый секрет, известный только получателю и отправителю пакета; туннелирование полную маскировку топологии локальной сети предприятия. Работа в рамках стандартов IPSec обеспечивает полную защиту информационного потока данных от отправителя до получателя, закрывая трафик для наблюдателей на промежуточных узлах сети. VPN решения на основе стека протоколов IPSec обеспечивают построение виртуальных защищенных сетей, их безопасную эксплуатацию и интеграцию с открытыми коммуникационными системами. |