Лекция. Защита информации на сетевом уровне - протокол IPSec

Лекция 10. Защита информации на сетевом уровне - протокол IPSec

1. Архитектура протокола IPSec
2. Протоколы АН и ESP
3. Механизмы трансляции IPSec и NAT
4. Межсетевые экраны

1. Архитектура протокола IPSec

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

Поэтому сообщество Internet Engineering Task Force (IETF) разработало IPSec - протокол сетевого уровня для проверки подлинности, целостности, конфиденциальности данных и защиту от повторов. Поддержка IPSec встроена в Windows 2000/XP.

Развертывание протокола IPSec в Windows 2000/XP позволяет обеспечить высокий уровень безопасности всей сети, при этом приложения на серверах и клиентах, поддерживающих IPSec, защищаются автоматически.

Для предупреждения нападений в IPSec служат криптографические механизмы. Они защищают информацию путем хеширования и шифрования.

Уровень безопасности для данного сеанса в IPSec определяется политикой. Она назначается в распределенных системах через контроллеры домена с Windows 2000 или создается и хранится локально в реестре компьютера с Windows XP Professional.

IPSec – это набор протоколов, разработан IETF как базовый протокол обеспечения безопасности на уровне IP-соединения. Является дополнением к использующемуся протоколу IP ver.4 и составной частью IP ver.6.

Возможности, предоставляемые IPSec:

‑ контроль доступа;

- контроль целостности данных;

- аутентификация данных;

- защита от повторений;

- обеспечение конфиденциальности.

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

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

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

Протокол работает на сетевом уровне модели OSI и, соответственно, он «прозрачен» для приложений. Иными словами, на работу приложений (таких как web-сервер, браузер, СУБД и т.д.) не влияет, используется ли защита передаваемых данных с помощью IPSec или нет.

Операционные системы семейства Windows 2000 и выше имеют встроенную поддержку протокола IPSec. С точки зрения многоуровневой модели защиты, этот протокол является средством защиты уровня сети.

Рис.1. Туннель безопасности.

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

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

- IP-адрес получателя;

- указание на протоколы безопасности, используемые при передаче данных;

- ключи, необходимые для  шифрования и формирования имитовставки;

- указание на метод форматирования, определяющий, каким образом создаются заголовки;

- индекс параметров защиты (Security Parameter Index, сокр. SPI) – идентификатор, позволяющий найти нужный SA.

Обычно, контекст защиты является однонаправленным, а для передачи данных по туннелю в обе стороны задействуются два SA. Каждый хост имеет свою базу SA, из которой выбирается нужный элемент либо на основании SPI, либо по IP-адресу получателя.

IPSec состоит из 2 протоколов:

1) протокол аутентифицирующего заголовка – AH (от англ. Authentication Header), обеспечивающий проверку целостности и аутентификацию передаваемых данных; последняя версия протокола  описана в RFC 4302 (предыдущие – RFC 1826, 2402);

2) протокол инкапсулирующей защиты данных – ESP (от англ. Encapsulating Security Payload) – обеспечивает конфиденциальность и, дополнительно, может обеспечивать проверку целостности и аутентификацию, описан в RFC 4303 (предыдущие – RFC 1827, 2406).

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

Транспортный режим ориентирован на соединение хост-хост. При использовании ESP в транспортном режиме защищаются только данные IP-пакета, заголовок не затрагивается. При использовании AH защита распространяется на данные и часть полей заголовка. Более подробно режимы работы описаны ниже.

2. Протокол AH

Рис. 2.  а) исходный IP-пакет, b) IP-пакет при использовании AH в транспортном режиме, с) IP-пакет при использовании AH в туннельном режиме.

На рисунке 2 представлен исходный пакет и варианты его изменения при использовании протокола AH в разных режимах. В транспортном режиме заголовок исходного IP-пакета остается на своем месте, но в нем модифицируются некоторые поля. Например, меняется поле Next Header, указывающее на то, заголовок какого протокола следует за IP-заголовком. В туннельном режиме создается новый IP-заголовок, после которого идет заголовок AH, а за ним – полностью исходный IP-пакет.

Аутентификация производится  путем создания имитовставки (MAC) используется хэш-функция и секретный ключ. Во всех реализациях AH обязательно должно поддерживаться использование хэш-функций с ключом HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96, представляющих собой варианты хэш-функций MD5 и SHA-1, соответственно. Но могут использоваться и другие, «факультативные» алгоритмы хэширования. Полученное значение, называемое в описании протокола ICV (от англ. Integrity Check Value – значение контроля целостности) помещается в поле Authentication Data (рис.3). Это поле переменной длины, т.к. разные алгоритмы хеширования формируют разные по длине дайджесты.

При использовании AH в транспортном режиме, ICV рассчитывается для ULP, данных и неизменяемых полей IP-заголовка. Изменяемые поля, такие как поле TTL, указывающее на время жизни пакета и изменяемое при прохождении маршрутизаторов, при расчете значения хэш-функции принимаются равными 0. В туннельном режиме аутентифицируется весь исходный IP-пакет и неизменяемые поля нового заголовка.

Рассмотрим формат заголовка AH (рис.44). Первые 8 бит заголовка (поле Next Header) содержат номер, соответствующий протоколу следующего уровня. Номер для каждого протокола назначает организация IANA (Internet Assigned Numbers Authority). Например, номер TCP – 6, ESP – 50, AH – 51 и т.д.

Поле Payload Len указывает длину заголовка AH в 32-битных словах. Далее 16 бит зарезервировано.

Поле SPI содержит значение индекса параметров защиты, по которому получатель сможет найти нужный SA. Нулевое значение SPI показывает, что для данного пакета SPI не существует.

Поле  Sequence Number было введено в RFC 2402. Значение счетчика, содержащееся в этом поле, может использоваться для защиты от атак путем повторных посылок перехваченных пакетов. Если функция защиты от повторов активирована (а это указывается в SA), отправитель последовательно наращивает значение поля для каждого пакета, передаваемого в рамках данной ассоциации (соединения, использующего единый SA).

Поле Authentication Data, как уже указывалось ранее, хранит значение ICV.

Протокол ESP

Если AH обеспечивает защиту от угроз целостности передаваемых данных, то ESP также может обеспечивать и конфиденциальность.

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

- для формирования имитовставки HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96;

- для шифрования - DES (в режиме CBC, используется по умолчанию) и NULL (отсутствие шифрования).

Кроме того, зарегистрированы и могут быть реализованы еще ряд алгоритмов шифрования – Triple DES, CAST-128, RC5, IDEA, Blowfish, ARCFour (общедоступная версия RC4) [22].

Рассмотрим формат заголовка ESP (рис. 5). Он начинается с двух 32-разрядных значений – SPI и SN. Роль их такая же, как в протоколе AH – SPI идентифицирует SA, использующийся для создания данного туннеля; SN – позволяет защититься от повторов пакетов. SN и SPI не шифруются.

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

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

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

При совместном использовании протоколов AH и ESP, после IP‑заголовка идет AH, после него – ESP. В этом случае, ESP решает задачи обеспечения конфиденциальности, AH – обеспечения целостности и аутентификации источника соединения.

Рассмотрим ряд дополнительных вопросов, связанных с использованием IPSec. Начнем с того, откуда берется информация о параметрах соединения – SA. Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности вручную, или формироваться с использованием специальных протоколов – SKIP, ISAKMP (Internet Security Association and Key Management Protocol) и IKE (Internet Key Exchange).

3.     Механизмы трансляции IPSec и NAT

При подключении сетей организаций к Интернет, часто используется механизм трансляции сетевых адресов – NAT (Network Address Translation). Это позволяет уменьшить число зарегистрированных IP-адресов, используемых в данной сети. Внутри сети используются незарегистрированные адреса (как правило, из  диапазонов, специально выделенных для этой цели, например, адреса вида 192.168.x.x для сетей класса C). Если пакет из такой сети передается в Интернет, то маршрутизатор, внешнему интерфейсу которого назначен по крайней мере один зарегистрированный ip-адрес, модифицирует ip-заголовки сетевых пакетов, подставляя вместо частных адресов зарегистрированный адрес. То, как производится подстановка, фиксируется в специальной таблице. При получении ответа, в соответствии с таблицей делается обратная замена и пакет переправляется во внутреннюю сеть.

Рассмотрим пример использования NAT рис. 7. В данном случае, во внутренней сети используются частные адреса 192.168.0.x. С компьютера, с адресом 192.168.0.2 обращаются во внешнюю сеть к компьютеру с адресом 195.242.2.2. Пусть это будет подключение к web-серверу (протокол HTTP, который использует TCP порт 80).

Таблица 4.

Таблица NAT

При прохождении пакета через маршрутизатор, выполняющий трансляцию адресов, ip-адрес отправителя (192.168.0.2) будет заменен на адрес внешнего интерфейса маршрутизатора (195.201.82.146), а в таблицу трансляции адресов будет добавлена запись, аналогичная приведенной в таблице 4.

Получив представление о механизме работы NAT, разберемся, какие сложности могут возникнуть, в случае использования IPSec. Предположим, с хоста с адресом 192.168.0.2 пытаются установить защищенное соединение  с внешним хостом 195.242.2.2, используя протокол аутентифицирующего заголовка (AH). При прохождении маршрутизатора, ip-адрес отправителя меняется, как было описано выше. Протокол AH определяет, что значение имитовставки рассчитывается, включая неизменяемые поля IP-заголовка, в частности – адрес отправителя. Сторона-получатель, обнаружит неверное (из-за трансляции адресов) значение имитовставки и отбросит пакет.

Таким образом, NAT и AH несовместимы. В то же время, протокол ESP, который не контролирует целостность ip-заголовка, может использоваться совместно с NAT.

Кроме того, RFC 2709 определяет расширение NAT - IPC-NAT (IPSec policy Controlled  NAT – NAT управляемый правилами IPSec), которое позволяет решить указанную проблему путем создания IP-IP туннеля, одной из конечных точек которого является узел NAT. В этом случае, вместо модификации IP-адреса отправителя в заголовке исходного пакета, NAT-устройство помещает без изменений весь исходный пакет (который аутентифицирован AH), в новый IP-пакет, в заголовке которого в качестве адреса отправителя ставится адрес NAT-устройства. На стороне получателя из полученного пакета изымают исходный пакет и далее обрабатывают его как обычно.

Отдельно необходимо решать вопрос с распределением ключей. Если для этой цели используется протокол IKE (а он использует UDP, порт 500), потребуется специально организовать пересылку соответствующих данных во внутреннюю сеть. В том, случае, если задействовать UDP-порт 500 не представляется возможным, можно использовать описываемый в RFC 3947, 3948 механизм NAT-T (от англ. NAT traversal), определяющий инкапсуляцию IKE и IPSec трафика в пакеты UDP. При этом задействуется порт 4500.

Вопросы, связанные настройкой и использованием реализации IPSec в ОС семейства Windows, рассматриваются в лабораторной работе №12. В ней, в частности,  подробно рассматривается создание «политики» IPSec, определяющей для каких узлов и с какими параметрами будет создаваться туннель.

4. Межсетевые экраны

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

Английский термин, используемый для обозначения МЭ – firewall. Поэтому в литературе межсетевые экраны иногда также называют файервол или брандмауэр (немецкий термин, аналог firewall).

Как уже было отмечено, фильтрация производится на основании правил. Наиболее безопасным при формировании правил для МЭ считается подход «запрещено все, что явно не разрешено». В этом случае, сетевой пакет проверяется на соответствие разрешающим правилам, а если таковых не найдется – отбрасывается. Но в некоторых случаях применяется и обратный принцип: «разрешено все, что явно не запрещено». Тогда проверка производится на соответствие запрещающим правилам и, если таких не будет найдено, пакет будет пропущен.

Фильтрацию можно производить на разных уровнях эталонной модели сетевого взаимодействия OSI. По этому признаку МЭ делятся на следующие классы:

- экранирующий маршрутизатор;

- экранирующий транспорт (шлюз сеансового уровня);

- экранирующий шлюз (шлюз прикладного уровня).

Экранирующий маршрутизатор (или пакетный фильтр) функционирует на сетевом уровне модели OSI, но для выполнения проверок может использовать информацию и из заголовков протоколов транспортного уровня. Соответственно, фильтрация может производиться по ip-адресам отправителя и получателя и по ТСР и UDP портам. Такие МЭ отличает высокая производительность и относительная простота – функциональностью пакетных фильтров обладают сейчас даже наиболее простые и недорогие аппаратные маршрутизаторы. В то же время, они не защищают от многих атак, например, связанных с подменой участников соединений.

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

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

Рассмотрим теперь вопросы, связанные с установкой МЭ. На рис. 8(а,b,c,d) представлены типовые схемы подключения МЭ.  В первом случае (рис.8a), МЭ устанавливается после маршрутизатора и защищает всю внутреннюю сеть.

Рис. 8a.подключение межсетевого экрана с двумя сетевыми интерфейсами для «единообразной» защиты локальной сети

Такая схема применяется, если требования в области защиты от несанкционированного межсетевого доступа примерно одинаковы для всех узлов внутренней сети. Например, «разрешать соединения, устанавливаемые из внутренней сети во внешнюю, и пресекать попытки подключения из внешней сети во внутреннюю». В том случае, если требования для разных узлов различны (например, нужно разместить почтовый сервер, к которому могут подключаться «извне»), подобная схема установки межсетевого экрана не является достаточно безопасной. Если в нашем примере нарушитель, в результате реализации сетевой атаки, получит контроль над указанным почтовым сервером, через него он может получить доступ и к другим узлам внутренней сети.

В подобных случаях иногда перед МЭ создается открытый сегмент сети предприятия (рис. 8b), а МЭ защищает остальную внутреннюю сеть.

Рис. 8b.подключение межсетевого экрана с двумя сетевыми интерфейсами при выделении открытого сегмента внутренней сети

Недостаток данной схемы заключается в том, что подключения к узлам открытого сегмента МЭ не контролирует.

Более предпочтительным в данном случае является использование МЭ с тремя сетевыми интерфейсами (рис.8c).

Рис. 8c. подключение межсетевого экрана с тремя сетевыми интерфейсами для защиты внутренней сети  и ее открытого сегмента

В этом случае, МЭ конфигурируется таким образом, чтобы правила доступа во внутреннюю сеть были более строгими, чем в открытый сегмент. В то же время, и те, и другие соединения могут контролироваться МЭ. Открытый сегмент в этом случае иногда называется «демилитаризованной зоной» – DMZ.

Еще более надежной считается схема, в которой для защиты сети с DMZ задействуются два независимо конфигурируемых МЭ (рис.8d).

Рис. 8d. подключение двух межсетевых экранов для защиты внутренней сети  и ее открытого

В этом случае, MЭ 2 реализует более жесткий набор правил фильтрации по сравнению с МЭ1. И даже успешная атака на первый МЭ не сделает внутреннюю сеть беззащитной.

В последнее время стал широко использоваться вариант установки программного МЭ непосредственно на защищаемый компьютер. Иногда такой МЭ называют «персональным». Подобная схема позволяет защититься от угроз исходящих не только из внешней сети, но из внутренней.

сегмента