Информация. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ. В. Ф. Шаньгининформационная безопасность компьютерных систем
 Скачать 5.69 Mb.
|
|
и туннельном режимах ким образом пакет, включая заголовок IP и собственно сам заго ловок АН. Таким образом, любое изменение данных в пакете или заголовков будет обнаружено. Следует также заметить, что в этом режиме данные пакета отсылаются открытыми, т. е. данные пакета защищены от изменений, но не защищены от просмотра. В частности, не удается скрыть IP-адреса источника и назначе ния от возможного просмотра посторонними лицами, поскольку эти поля всегда присутствуют в незашифрованном виде и соот ветствуют действительным адресам хостов. В туннельном режиме в качестве заголовка внешнего IP-па кета создается новый заголовок IP. IP-адреса посылающей и принимающей сторон могут отличаться от адресов в заголовке исходного IP-пакета. В защищенном IP-пакете внутренний (пер воначальный) IP-заголовок содержит целевой адрес пакета, а внешний IP-заголовок содержит адрес конца туннеля. За новым заголовком внешнего IP-пакета следует заголовок АН, а затем весь исходный пакет (заголовок IP и сами данные). Как и в слу чае транспортного режима, протокол АН защищает весь создан ный пакет (два заголовка IP, заголовок АН и данные), что также позволяет обнаружить любые изменения в пакете. Как и в транспортном режиме, сам пакет не защищен от просмотра. Независимо от режима работы, протокол АН предоставляет меры защиты от атак, направленных на нарушение целостности и подлинности пакетов сообщений. С помощью этого протокола аутентифицируется каждый пакет, что делает программы, пы тающиеся перехватить управление сеансом, неэффективными. Протокол АН обеспечивает аутентификацию не только содержи мого, но и заголовков IP-пакетов. Однако следует иметь в виду, что аутентификация по протоколу АН не допускает манипулиро вания основными полями IP-заголовка во время прохождения пакета. По этой причине данный протокол нельзя применять в среде, где используется механизм трансляции сетевых адресов NAT (Network Address Translation), поскольку для его работы не обходимо манипулирование ІР-заголовками. Протокол АН может применяться как отдельно, так и в ком бинации с протоколом ESP или даже с пакетом, который уже содержит AH-заголовок (вложенное применение). 1 2 .2 .2 . Прот окол инкапсулирую щ ей защиты ESP Протокол инкапсулирующей защиты содержимого ESP (En capsulating Security Payload) обеспечивает конфиденциальность, аутентичность, целостность и защиту от повторов для пакетов данных. Следует отметить, что конфиденциальность данных про токол ESP обеспечивает всегда, а целостность и аутентичность яв ляются для него опциональными требованиями. Конфиденциаль ность данных обеспечивается путем шифрования содержимого отдельных пакетов. Целостность и аутентичность данных обеспе чиваются на основе вычисления дайджеста. Из приведенного перечня функций по защите информаци онного обмена видно, что функциональность протокола ESP шире, чем у протокола АН. Протокол ESP поддерживает все функции протокола АН по защите зашифрованных потоков дан ных от подлога, воспроизведения и случайного искажения, а также обеспечивает конфиденциальность данных. В протоколе ESP функции аутентификации и криптографи ческого закрытия могут быть задействованы либо вместе, либо отдельно друг от друга. При выполнении шифрования без аутен тификации появляется возможность использования механизма трансляции сетевых адресов NAT (Network Address Translation), поскольку в этом случае адреса в заголовках IP-пакетов можно модифицировать [9]. Для решения своих задач протокол ESP использует заголо вок формата, приведенного на рис. 12.5. О 16 31 Индекс параметров защиты SPI Порядковый номер SN Данные (переменная длина) Заполнитель PAD Заполнитель PAD Длина заполнителя Следующий заголовок Аутентификационные данные (переменная длина) Рис. 12.5. Формат заголовка 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) и код аутентичности сообщения, используемые для проверки подлинности отправителя и целостности сообщения. Зна чение ІСѴ вычисляется для заголовка ESP, передаваемых данных и концевой метки ESP. Поле Authentication Data помещается в заголовок ESP только при включенной ау тентификации. Нетрудно заметить, что некоторые поля заголовка ESP анало гичны полям заголовка АН: Next Header, SPI, SN, Authentication Data. Но есть и два дополнительных поля — заполнитель (Padding) и длина заполнителя (Pad Length). Заполнитель может понадо биться в трех случаях. Во-первых, для нормальной работы неко торых алгоритмов шифрования необходимо, чтобы шифруемый текст содержал кратное число блоков определенного размера. Во-вторых, формат заголовка ESP требует, чтобы поле данных за канчивалось на границе четырех байтов. В-третьих, заполнитель можно использовать для сокрытия действительного размера паке та в целях обеспечения так называемой частичной конфиденци альности трафика, хотя протокол ESP ограничивает возможности маскировки 255 байтами заполнителя; это сделано для того, что бы не слишком снижалась полезная пропускная способность ка нала связи из-за большого объема избыточных данных. Как видно из рис. 12.5, заголовок делится на две части, разде ляемые полем данных (полезная нагрузка — Payload Data). Первая часть, которая далее будет обозначаться как заголовок ESP, обра зуется двумя полями — SPI и SN — и размещается перед полем данных. Остальные служебные поля протокола ESP расположены в конце пакета. Непосредственно за полем данных следует так называемый трейлер, в который входят заполнитель (Padding), длина заполнителя (Pad Length), а также указатель на протокол следующего уровня (Next Header). Завершает пакет поле контроля целостности (Authentication Data). В том случае, когда при уста новлении безопасной ассоциации принято решение не использо вать возможности ESP по обеспечению целостности, это поле от сутствует. ПО перечисленных протоколов (утилиты шифрования, циф ровой подписи и пр.) может функционировать на серверах или компьютерах конечных пользователей. Однако чаше его устанав ливают на маршрутизаторах или специальных устройствах, кото рые в архитектуре IPSec именуются шлюзами безопасности (security gateway). Протокол ESP также используют в двух режимах — транс портном и туннельном. На рис. 12.6 показано расположение ESP заголовка в туннельном и транспортном режимах [62]. В транспортном режиме зашифрованные данные транспор тируются непосредственно между хостами. В транспортном ре жиме протокола ESP заголовок исходного IP-пакета остается внешним. ІР-пакета_Заголовок_ESP_Заголовок_TCP_(или_UDP)_Данные_Трейлер_ESP'>Заголовок ESP помещается в передаваемый пакет ме жду заголовками протоколов третьего (IP) и четвертого (напри мер, TCP) уровней. Следует заметить, что поля протокола ESP следуют после стандартного IP-заголовка, а это означает, что та кой пакет может маршрутизироваться в сети с помощью обыч ного оборудования, поддерживающего IP. IP-пакет после применения протокола ESP в транспортном режиме Заголовок исходного ІР-пакета Заголовок ESP Заголовок TCP (или UDP) Данные Трейлер ESP Данные аутентификации Зашифровано Аутентифицировано IP-пакет после применения протокола ESP в туннельном режиме Заголовок внешнего ІР-пакета Заголовок ESP Заголовок исходного ІР-пакета Заголовок TCP (или UDP) Данные Трейлер ESP Данные аутентификации Зашифровано Аутентифицировано Рис. 12.6. IP-пакет после применения протокола ESP в транспортном и туннельном режимах Шифрованию подвергаются только данные исходного IP-па кета (пакет верхнего уровня) и заключительная часть ESP заго ловка (ESP trailer). В этом режиме ESP не шифрует заголовок IP-пакета, иначе маршрутизатор не сможет прочитать поля заго ловка и корректно осуществить продвижение пакета между сетя ми. В число шифруемых полей не попали также поля SPI и SN, которые должны передаваться в открытом виде, для того чтобы прибывший пакет можно было отнести к определенной ассоциа ции SA и защититься от ложного воспроизведения пакета. В отличие от протокола АН, контроль целостности и аутен тичности данных в протоколе ESP не распространяется на заго ловок исходного пакета, и по этой причине имеет смысл приме нять оба протокола совместно — ESP для шифрования, а АН для контроля целостности. Таким образом, адресная информация (IP-адреса отсылаю щей и принимающей сторон) видна при пересылке пакета по сети, и несанкционированное изменение этих IP-адресов не бу дет замечено. В туннельном режиме основная роль отводится шлюзам безо пасности, поскольку предполагается, что клиентские станции (или серверы) могут не поддерживать IPSec и отправляют в сеть обычный IP-трафик. Перед тем как достичь каналов глобальной сети, каждый исходный IP-пакет сначала попадает в шлюз, ко торый помещает этот пакет целиком в «оболочку» IPSec, зашиф ровывая его содержимое вместе с исходным IP-заголовком. Что бы обеспечить возможность маршрутизации получившегося па кета, шлюз снабжает его новым IP-заголовком и только после этого отправляет в сеть. Шлюз, находящийся на противополож ном конце соединения, расшифровывает этот пакет и передает его на оконечное устройство в первоначальном виде. Описанная процедура называется туннелированием. Из рис. 12.6 видно, что в туннельном режиме в качестве внешнего заголовка создается новый заголовок IP. Весь исход ный IP-пакет (и данные и заголовок IP) и заключительная часть заголовка ESP (трейлер ESP) шифруются. Поэтому адресная ин формация исходного IP-пакета не доступна для просмотра. Заго ловок внешнего IP-пакета протоколом ESP не защищается. Туннелирование позволяет распространить действие средств защиты на сетевой уровень модели OSI и, в частности, скрыть истинные адреса источника и получателя. При этом уменьшает ся риск атак, основанных на детальном анализе трафика. Сравнивая протоколы ESP и АН можно заметить, что они дублируют функциональность друг друга в области обеспечения аутентификации данных. Главным отличием протокола АН от ESP в данном вопросе является то, что протокол АН обеспечи вает аутентификацию всего пакета (и IP заголовка и самих дан ных), в то время как протокол ESP аутентифицирует только данные из пакета (см. рис. 12.6). При шифровании в протоколе ESP используется симметричный секретный ключ, т. е. переда ваемые данные зашифровываются и расшифровываются с помо щью одного и того же ключа. Для протокола ESP также опреде лен перечень обязательных алгоритмов шифрования — DES, MD5 и SHA-1. При аутентификации данных протокол ESP использует те же алгоритмы НМАС, что и протокол АН (использующие MD5 или SHA-1 в качестве функции хеширования). Однако способы при менения различаются (см. рис. 12.6). В транспортном режиме: • протокол ESP аутентифицирует только данные из пакета, не затрагивая ІР-заголовка; • протокол АН защищает и данные и оба заголовка. В туннельном режиме: • аутентификация в ESP протоколе применяется к данным пакета и исходному IP-заголовку, но не затрагивает новый I Р-заголовок; • протокол АН аутентифицирует данные, АН-заголовок и оба ІР-заголовка. Протокол ESP может применяться отдельно или совместно с протоколом АН. При совместном использовании протоколы АН и ESP могут комбинироваться разными способами. Если ис пользуется транспортный режим, то аналогично тому, как в рам ках ESP аутентификация идет следом за шифрованием, прото кол АН должен применяться после протокола ESP. В туннель ном режиме протоколы АН и ESP применяются к разным вложенным пакетам и, кроме того, допускается многократная вложенность туннелей с различными начальными и/или конеч ными точками. 1 2 .2 .3 . Алгоритмы аутентификации и ш иф рования в IPSec Стек протоколов IPSec представляет собой согласованный набор открытых стандартов, имеющий вполне определенное ядро, и в то же время он может быть достаточно просто допол нен новыми протоколами, алгоритмами и функциями. Благода ря модульной структуре протоколы АН и ESP допускают приме нение пользователями по их согласованному выбору различных криптографических алгоритмов аутентификации и шифрования. Для шифрования данных в IPSec (протокол ESP) может быть применен практически любой симметричный алгоритм шифро вания, использующий секретные ключи. Для обеспечения целостности и аутентификации данных (протоколы АН и ESP) используется один из приемов шифрова ния — шифрование с помощью односторонней функции (one-way function), называемой также хэш-функцией (hash function) или дайджест-функцией (digest function) [45, 72]. Эта функция, при мененная к шифруемым данным, дает в результате значение-дай джест, состоящее из фиксированного небольшого числа байт. Дайджест передается в IP-пакете вместе с исходным сообщени ем. Получатель, зная, какая односторонняя функция шифрова ния была применена для составления дайджеста, заново вычис ляет его, используя исходное сообщение. Если значения полу ченного и вычисленного дайджестов совпадают, это значит, что содержимое пакета во время передачи не было подвергнуто ника ким изменениям. Знание дайджеста не дает возможности восста новить исходное сообщение и поэтому не может быть использо вано для защиты конфиденциальности, но оно позволяет прове рить целостность данных. Дайджест является своего рода контрольной суммой для ис ходного сообщения. В отличие от традиционной контрольной суммы при вычислении дайджеста используется секретный ключ. Если для получения дайджеста применялась односторон няя функция с параметром (в качестве которого выступает сек ретный ключ), известным только отправителю и получателю, любая модификация исходного сообщения будет немедленно об наружена. В целях обеспечения совместимости продуктов разных произ водителей рабочая группа IETF определила базовый набор под держиваемых функций и алгоритмов, который должен быть одно типно реализован во всех продуктах, поддерживающих IPSec. На сегодня определены 2 алгоритма аутентификации и 7 алгоритмов шифрования. В настоящий момент для протоколов АН и ESP зарегистри ровано 2 алгоритма аутентификации — HMAC-MD5 и НМАС- SHA1. Алгоритм НМАС (Keyed-Hashing for Message Authenti cation Code) определяется стандартом RFC 2104. Функции MD5 (Message Digest version 5, стандарт RFC 1321) и SHA1 (Secure Hash Algorithm version 1, стандарт FIPS 180-1) являются функ циями хеширования. Алгоритмы HMAC-MD5 и HMAC-SHA1 являются алгоритмами аутентификации с общим секретным ключом. Секретный ключ имеет длину 128 бит в случае MD5 и 160 бит в случае SHA1 [9]. Если секретный ключ известен только передающей и прини мающей сторонам, это обеспечит аутентификацию источника данных, а также целостность пакетов, пересылаемых между дву мя сторонами. Ключи для НМАС генерируются посредством процедуры ISAKMP/Oakley. Для обеспечения совместимости оборудования и ПО на начальной стадии реализации протокола IPSec один из зарегистрированных алгоритмов аутентификации принято использовать по умолчанию. В качестве такого алгорит ма определен алгоритм HMAC-MD5. Структура алгоритма НМАС показана на рис. 12.7. Принцип действия алгоритма НМАС заключается в двухкратной обработке пакета функцией хеширования, управляемой ключом аутентифи кации (например, функцией хеширования MD5). Как видно из рисунка, оба раза в обрабатываемые данные включается секрет ный ключ, который обеспечивает аутентификацию передаваемой информации. Полученная контрольная сумма помещается в за головок АН протокола. Проверка аутентификации на другой сто роне осуществляется путем повторного вычисления контрольной суммы для пришедшего пакета с использованием такого же клю ча и сравнения полученного результата с присланным. Рис. 12.7. Структура НМАС алгоритма Алгоритм НМАС реализует симметричную схему аутентифи кации, используя параметр проверки целостности пакета ІСѴ (Integrity Check Value). По сути, он представляет собой цифро вую подпись, помещаемую в поле аутентификации и позволяю щую отправителю подписать результат предварительного хеши рования содержательной части пакета ESP. Анализ содержимого этого поля дает возможность получате лю идентифицировать источник данных и убедиться в том, что они не были изменены в процессе передачи. Если для протокола ESP функции аутентификации являются факультативными, то для протокола АН процесс аутентификации обязателен. Для протокола ESP зарегистрировано несколько алгоритмов шифрования. Чаще всего в качестве алгоритмов шифрования для ESP применяются DES (Data Encryption Standard), 3DES (тройной DES) и новый стандарт шифрования AES (Advanced Encryption Standard). Для обеспечения IPSec-coвместимости по умолчанию в качестве алгоритма шифрования стандартом преду смотрен симметричный метод DES-CBC (Cipher Block Chaining) с явно заданным вектором инициализации IV и с 56-разрядным ключом. Алгоритм AES повсюду встраивается в стандарт IPSec как альтернатива DES и 3DES. Выбор алгоритма шифрования целиком зависит от разработ чика. Возможность выбора алгоритма шифрования предоставля ет пользователю дополнительное преимущество: злоумышлен ник должен не только вскрыть шифр, но и определить, какой именно шифр ему надо вскрывать, а вместе с необходимостью подбора ключей, это еще более уменьшает его шансы своевре менно расшифровать данные пользователя. IPSec может работать совместно с протоколами L2TP или L2F, которые выполняют только туннелирование, но не обеспе чивают шифрование и аутентификацию данных. Эти протоколы создают через Internet туннель для пакетов любых протоколов, упаковывая их в пакеты IP. Когда трафик с помощью L2F или L2TP оказывается упакованным в пакеты IP, то дальше для его за щиты можно использовать IPSec. В результате комбинирование IPSec с протоколами туннелирования типа L2F/L2TP позволяет решить задачу защиты данных для протоколов, отличных от IP. Алгоритмическая независимость протоколов АН и ESP тре бует предварительного согласования взаимодействующими сто ронами набора применяемых алгоритмов и их параметров. 12.3. Протокол управления криптоключами ІКЕ Протоколы ESP и АН позволяют реализовать важнейшие ат рибуты защищенной передачи — конфиденциальность связи, ау тентификацию сторон и целостность данных. Однако их функ ции теряют всякую ценность в отсутствие мощной поддерживаю щей инфраструктуры, которая обеспечивала бы распределение ключей и согласование протоколов между участниками обмена. Роль такой инфраструктуры в IPSec выполняет группа про токолов IKE (Internet Key Exchange). Это название пришло в 1998 г. на смену более раннему — ISAKMP/Oakley, которое не посредственно указывало на происхождение средств управления ключами в составе IPSec. Протокол ISAKMP (Internet Security Association and Key Management Protocol), описанный в документе RFC 2408, позво ляет согласовывать алгоритмы и математические структуры (так называемые мультипликативные группы, определенные на ко нечном поле) для процедуры обмена ключами Диффи — Хелл- мана, а также процессов аутентификации [98, 102]. Протокол Oakley, описанный в RFC 2412, основан на алгоритме Диффи — Хеллмана и служит для организации непосредственного обмена ключами. Протоколы ІКЕ решают три задачи: • осуществляют аутентификацию взаимодействующих сто рон, согласовывают алгоритмы шифрования и характери стики ключей, которые будут использоваться в защищенном сеансе обмена информацией; • обеспечивают создание, управление ключевой информации соединения, непосредственный обмен ключами (в том чис ле возможность их частой смены); • управляют параметрами соединения и защитой от некото рых типов атак, контролируют выполнение всех достигну тых соглашений. Разработчики IPSec начали свою деятельность с решения по следней из перечисленных задач. В результате на свет появилась концепция защищенных виртуальных соединений или безопасных ассоциаций (Security Associations). 1 2 .3 .1 . Установление б езо п асн о й ассоциации SA Основой функционирования IPSec являются защищенные виртуальные соединения или безопасные ассоциации SA (Security Associations). Для того чтобы протоколы АН и ESP могли выпол нять свою работу по защите передаваемых данных, между двумя конечными точками должна быть сформирована ассоциация SA — соглашение о защите обмена данными между двумя взаи модействующими партнерами. Установление SA должно начинаться со взаимной аутенти фикации сторон, потому что меры безопасности теряют всякий смысл, если данные передаются или принимаются неавторизо ванными пользователями. Процедуры установления SA оправда ны лишь в том случае, если у каждой из сторон имеется полная уверенность в том, что ее партнер — именно тот, за кого он себя выдает. Для выполнения аутентификации сторон в ІКЕ применяют ся два основных способа. Первый способ основан на использовании разделяемого сек рета. Перед инициализацией IPSee-устройств, образующих безо пасные ассоциации, в их БД помещается предварительно рас пределенный разделяемый секрет. Цифровая подпись на основе односторонней функции, например, MD5, использующей в ка честве аргумента этот предварительно распределенный секрет, доказывает аутентичность противоположной стороны. Второй способ основан на использовании технологии цифро вой подписи и цифровых сертификатов стандарта Х.509. Каждая из сторон подписывает свой цифровой сертификат своим закры тым ключом и передает эти данные противоположной стороне. Если подписанный сертификат расшифровывается открытым ключом отправителя, то это удостоверяет тот факт, что отправи тель, предоставивший данные, действительно обладает ответной частью данного открытого ключа — соответствующим закрытым ключом. Однако следует отметить, что для удостоверения аутентично сти стороны нужно еще убедиться в аутентичности самого сер тификата, и для этого сертификат должен быть подписан не только его владельцем, но и некоторой третьей стороной, выдав шей сертификат и вызывающей доверие. В архитектуре IPSec эта третья сторона именуется органом сертификации СА (Certification Authority). Этот орган призван засвидетельствовать подлинность обеих сторон и должен пользоваться полным доверием сторон, а его открытый ключ — известен всем узлам, использующим его сертификаты для удостоверения личностей друг друга. После проведения взаимной аутентификации взаимодейст вующие стороны могут непосредственно перейти к согласованию параметров защищенного канала. Выбираемые параметры SA оп ределяют: протокол, используемый для обеспечения безопасно сти передачи данных; алгоритм аутентификации протокола АН и его ключи; алгоритм шифрования, используемый протоколом ESP, и его ключи; наличие или отсутствие криптографической синхронизации; способы защиты сеанса обмена; частоту смены ключей и ряд других параметров. Важным параметром SA являет ся так называемый криптографический материал, т. е. секретные ключи, используемые в работе протоколов АН и ESP. Сервисы безопасности, предлагаемые IPSec, используют для формирова ния криптографических ключей разделяемые секреты. Параметры SA должны устраивать обе конечные точки защи щенного канала. Поэтому при использовании автоматической процедуры установления SA протоколы ІКЕ, работающие по разные стороны канала, выбирают параметры в ходе переговор ного процесса. Для каждой задачи, решаемой протоколами АН и ESP, предлагается несколько схем аутентификации и шифрова ния — это делает IPSec очень гибким средством. Безопасная ас социация SA представляет собой в IPSec однонаправленное ло гическое соединение, поэтому при двустороннем обмене данны ми необходимо установить две ассоциации SA. В рамках одной ассоциации SA может работать только один из протоколов защи ты данных — либо АН, либо ESP, но не оба вместе. Для идентификации каждой SA предназначен индекс пара метров безопасности SPI (Security Parameters Index). Этот индекс включается в заголовки защищенных IPSec-пакетов, чтобы при нимающая сторона смогла правильно их расшифровать и аутен тифицировать, воспользовавшись указанной безопасной ассо циацией. Система IPSec допускает применение ручного и автоматиче ского способа установления SA. При ручном способе админист ратор конфигурирует каждый конечный узел таким образом, чтобы они поддерживали согласованные параметры ассоциации, включая и секретные ключи. Для автоматического установления ассоциации необходим соответствующий протокол, в качестве которого в стандартах IPSec определен протокол ІКЕ. Он является комбинацией про токолов ISAKMP, Oakley и SKEME. Протокол согласования па раметров виртуального канала и управления ключами ISAKMP (Internet Security Association Key Management Protocol) описывает базовую технологию аутентификации, обмена ключами и согла сования остальных параметров IPSec-туннеля при создании SA, однако сами протоколы аутентификации сторон и обмена клю чами в нем детально не определены. Поэтому при разработке протокола ІКЕ общие правила и процедуры протокола ISAKMP дополнены процедурами аутентификации и обмена ключами, взятыми из протоколов Oakley и SKEME. Поскольку протокол ІКЕ использует для управления ассоциациями алгоритмы и фор маты протокола ISAKMP, названия этих протоколов иногда ис пользуют как синонимы. На основании протокола ISAKMP согласование параметров защищенного взаимодействия необходимо как при формирова нии IPSec-туннеля, так и при формировании в его рамках каж дого защищенного однонаправленного соединения. Параметры IPSec-туннеля согласуются по протоколу ISAKMP/Oakley. Па раметры каждого защищенного однонаправленного соединения согласуются в рамках сформированного ІРБес-туннеля и образу ют SA. Криптографические ключи для каждого защищенного одно направленного соединения генерируются на основе ключей, вы работанных в рамках IPSec-туннеля. При этом учитываются ал горитмы аутентификации и шифрования, используемые в прото колах аутентифицирующего заголовка (АН) и инкапсулирующей защиты (ESP). Стандарты IPSec позволяют шлюзам использовать как одну ассоциацию SA для передачи трафика всех взаимодействующих через Internet хостов, так и создавать для этой цели произволь ное число ассоциаций SA, например по одной на каждое соеди нение TCP. 1 2 .3 .2 . Базы данны х SAD и SPD IPSec предлагает различные методы защиты трафика. В каждом узле, поддерживающем IPSec, используются БД двух типов: • база данных безопасных ассоциаций SAD (Security Asso ciations Database); • база данных политики безопасности SPD (Security Policy Database). При установлении SA две вступающие в обмен стороны при нимают ряд соглашений, регламентирующих процесс передачи потока данных между ними. Соглашения представляются в виде набора параметров. Для SA такими параметрами являются, в ча стности, тип и режим работы протокола защиты (АН или ESP), методы шифрования, секретные ключи, значение текущего но мера пакета в ассоциации и другая информация. Объединение служебной информации в рамках SA предос тавляет пользователю возможность сформировать разные классы защиты, предназначенные, например, для электронного обще ния с разными «собеседниками». Другими словами, применение структур SA открывает путь к построению множества виртуаль ных частных сетей, различающихся своими параметрами. Наборы текущих параметров, определяющих все активные ассоциации, хранятся на обоих оконечных узлах защищенного канала в виде SAD. Каждый узел IPSec поддерживает две базы SAD — одну для исходящих ассоциаций, другую — для входящих. SPD задает соответствие между IP-пакетами и установлен ными для них правилами обработки. При обработке пакетов БД SPD используются совместно с БД SAD. SPD представляет со бой упорядоченный набор правил, каждое из которых включает совокупность селекторов и допустимых политик безопасности. Селекторы служат для отбора пакетов, а политики безопасности задают требуемую обработку. Такая БД формируется и поддер живается на каждом узле, где установлено ПО IPSec. 12.4. Особенности реализации средств IPSec Выше было рассмортрено, что протоколы АН или ESP могут защищать передаваемые данные в двух режимах: туннельном, при котором IP-пакеты защищаются целиком, включая их заго ловки, и транспортном, обеспечивающим защиту только содер жимого ІР-пакетов. Основным режимом является туннельный. В туннельном ре жиме исходный пакет помещается в новый IP-пакет и передача данных по сети выполняется на основании заголовка нового IP-пакета. При работе в этом режиме каждый обычный ІР-пакет помещается целиком в криптозащищенном виде в конверт IPSec, а тот в свою очередь инкапсулируется в другой защищенный IP-пакет. Туннельный режим обычно реализуют на специально выделенных шлюзах безопасности, в роли которых могут высту пать маршрутизаторы или МЭ. Между такими шлюзами и фор мируются защищенные туннели IPSec. После приема на другой стороне туннеля защищенные ІР-па- кеты «распаковываются» и полученные исходные IP-пакеты пе редаются компьютерам приемной локальной сети по стандарт ным правилам. Туннелирование IP-пакетов полностью прозрач но для обычных компьютеров в локальных сетях, являющихся держателями туннелей. На оконечных системах туннельный ре жим может использоваться для поддержки удаленных и мобиль ных пользователей. В этом случае на компьютерах этих пользова телей должно быть установлено ПО, реализующее туннельный режим IPSec. В транспортном режиме передача IP-пакета через сеть вы полняется с помощью исходного заголовка этого пакета. В кон верт IPSec в криптозащищенном виде помещается только содер жимое исходного IP-пакета и к полученному конверту добавля ется исходный IP-заголовок. Транспортный режим быстрее туннельного и разработан для применения на оконечных систе мах. Этот режим может использоваться для поддержки удален ных и мобильных пользователей, а также защиты информацион ных потоков внутри локальных сетей. Следует отметить, что ра бота в транспортном режиме отражается на всех входящих в группу защищенного взаимодействия системах, и в большинстве случаев требуется перепрограммирование сетевых приложений. 1 2 .4 .1 . Основны е схем ы п р им енения IPSec Применение туннельного или транспортного режима зависит от требований, предъявляемых к защите данных, а также от роли узла, в котором работает IPSec. Узлом, завершающим защищен ный канал, может быть хост (конечный узел) или шлюз (проме жуточный узел) [48]. Соответственно различают три основные схемы применения IPSec: 1) хост—хост; 2) шлюз—шлюз; 3) хост—шлюз. В схеме 1 защищенный канал, или, что в данном контексте одно и то же, SA, устанавливается между двумя конечными уз лами сети, т. е. хостами Н1 и Н2 (рис. 12.8). Протокол IPSec в этом случае работает на конечном узле и защищает данные, Рис. 12.8. Схема хост—хост поступающие на него. Для хостов, поддерживающих IPSec, раз решается использовать как транспортный режим, так и туннель ный. В соответствии со схемой 2 защищенный канал устанавлива ется между двумя промежуточными узлами, называемыми шлю зами безопасности SG1 и SG2 (Security Gateway), на каждом из которых работает протокол IPSec (рис. 12.9). Intranet Intranet Защищенный обмен данными может происходить между лю быми двумя конечными узлами, подключенными к сетям, кото рые расположены позади шлюзов безопасности. От конечных узлов поддержка протокола IPSec не требуется, они передают свой трафик в незащищенном виде через заслуживающие дове рие сети Intranet предприятия. Трафик, направляемый в обще доступную сеть, проходит через шлюз безопасности, который и обеспечивает его защиту с помощью IPSec, действуя от своего имени. Шлюзам разрешается использовать только туннельный режим работы, хотя они могли бы поддерживать и транспортный режим, но он в этом случае малоэффективен. При защищенном удаленном доступе часто применяется схе ма 3 хост—шлюз (рис. 12.10). Здесь защищенный канал организуется между удаленным хостом Н 1, на котором работает IPSec, и шлюзом SG, защищаю щим трафик для всех хостов, входящих в сеть Intranet предпри ятия. Удаленный хост может использовать при отправке пакетов шлюзу как транспортный, так и туннельный режим, шлюз же отправляет пакеты хосту только в туннельном режиме. Эту схему можно модифицировать, создав параллельно еще один защищенный канал — между удаленным хостом Н1 и ка- Рис. 12.10. Схема хост—шлюз, дополненная каналом хост—хост ким-либо хостом Н2, принадлежащим внутренней сети, защи щаемой шлюзом. Такое комбинированное использование двух SA позволяет надежно защитить трафик и во внутренней сети. Рассмотренные схемы построения защищенных каналов на базе IPSec широко применяются при создании разнообразных виртуальных защищенных сетей VPN. Их спектр варьируется от провайдерских сетей, позволяющих управлять обслуживанием клиентов непосредственно на их площадях, до корпоративных сетей VPN, разворачиваемых и управляемых самими компания ми. На базе IPSec успешно реализуются виртуальные защищен ные сети любой архитектуры, включая VPN с удаленным досту пом (Remote Access VPN), внутрикорпоративные VPN (Intranet VPN) и межкорпоративные VPN (Extranet VPN). 1 2 .4 .2 . Преимущества средств безопасности IPSec Система стандартов IPSec вобрала в себя прогрессивные ме тодики и достижения в области сетевой безопасности, завоевала признание специалистов как надежная и легко интегрируемая система безопасности для IP-сетей. Система IPSec прочно зани мает сегодня лидирующие позиции в наборе стандартов для соз дания VPN. Этому способствует ее открытое построение, спо собное включать все новые достижения в области криптографии. IPsec позволяет защитить сеть от большинства сетевых атак, «сбрасывая» чужие пакеты еще до того, как они достигнут уров ня IP на принимающем компьютере. В защищаемый компьютер или сеть могут войти только пакеты от зарегистрированных партнеров по взаимодействию. IPsec обеспечивает: • аутентификацию — доказательство отправки пакетов ва шим партнером по взаимодействию, т. е. обладателем раз деляемого секрета; • целостность — невозможность изменения данных в пакете; • конфиденциальность -- невозможность раскрытия переда ваемых данных; • надежное управление ключами — протокол ІКЕ вычисляет разделяемый секрет, известный только получателю и от правителю пакета; • туннелирование — полную маскировку топологии локаль ной сети предприятия. Работа в рамках стандартов IPSec обеспечивает полную за щиту информационного потока данных от отправителя до полу чателя, закрывая трафик для наблюдателей на промежуточных узлах сети. VPN-решения на основе стека протоколов IPSec обеспечивают построение виртуальных защищенных сетей, их безопасную эксплуатацию и интеграцию с открытыми коммуни кационными системами. |