<<
>>

IPsec

Проблемная группа IETF в течение многих лет мирилась с отсутствием безопасности в Интернете. Обеспечить ее было действительно непросто, и прежде всего потому, что разгорелись жаркие споры вокруг того, какую часть Интернета следует, собственно, защищать.
Большинство экспертов по вопросам безопасности уверены в том, что по-настоящему надежная система должна выполнять сквозную шифрацию и сквозное обеспечение целостности данных (то есть все это должно быть сделано на прикладном уровне). Это означает, что процесс-источник шифрует и/или ставит защиту целостности данных и отправляет их процессу- приемнику, который, соответственно, дешифрует данные и проверяет их целостность. Тогда можно будет заметить любые попытки взлома (даже на уровне операционной системы на любой из сторон). Беда такого подхода в том, что для обеспечения безопасности требуется вносить изменения во все приложения. Это означает, что необходимо «спустить» шифрацию на транспортный уровень или организовать новый специализированный подуровень между прикладным и транспортным уровнями.
Он должен быть сквозным, но в то же время не требующим внесения изменений в приложения.

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

Результатом всех этих дискуссий было создание стандарта IPsec (IP security — IP-безопасность), описанного в RFC 2401, 2402, 2406 и др. Не всем пользователям требуется шифрация соединений (выполнение соответствующих процедур может занимать существенную часть вычислительных ресурсов). Однако вместо того чтобы делать шифрацию необязательной, пользователю предлагается в случае необходимости выбирать пустой алгоритм. В RFC 2410 расписываются такие достоинства пустого алгоритма, как простота, легкость реализации и высокая скорость.

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

Для чего нужен целый набор алгоритмов? Дело в том, что считающийся сегодня надежным алгоритм завтра может быть сломан. Если сделать IPsec независимым от конкретного алгоритма, стандарт выживет даже в случае взлома одного из алгоритмов.

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

Несколько удивительно, что IPsec ориентирован на соединение, несмотря на его присутствие на уровне IP. На самом деле, это не так странно, как кажется. Ведь безопасность можно обеспечить только созданием ключа и использованием его в течение какого-то времени. А это, по сути дела, разновидность соединения. К тому же все соединения погашают расходы на их установление за счет передачи большого количества пакетов. «Соединение» в контексте IPsec называется защищающей связью (security connection). Защищающая связь — это симплексное соединение между двумя конечными точками, с которым связан специальный идентификатор защиты.

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

Технически IPsec состоит из двух основных частей. Первая описывает два новых заголовка, которые можно добавлять к пакету для передачи идентификатора защиты, данных контроля целостности и другой информации. Вторая часть, ISAKMP (Internet Security and Key Management Protocol — интернет-безопасность и протокол управления ключами), предназначена для создания ключей. Мы не станем вдаваться в подробности устройства ISAKMP, потому что, во-первых, это очень сложная тема и, во-вторых, основной протокол IKE (Internet Key Exchange — обмен ключами в Интернете) работает очень некорректно и требует замены (Perlman и Kaufman, 2000).

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

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

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

А ведь иногда даже объем трафика, передаваемого одним лицом другому, является ценной информацией. Например, если во время военного кризиса трафик между Пентагоном и Белым домом резко снижается и при этом так же резко растет трафик между Пентагоном и какой-нибудь военной базой в Колорадо, перехватчик может сделать из этого далеко идущие выводы.

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

Первый из новых заголовков называется заголовком идентификации (АН — Authentication Header). С его помощью проверяется целостность данных и выполняется защита от взлома путем повторной передачи. Однако он не имеет никакого отношения к секретности (то есть шифрации данных). Применение АН в транспортном режиме показано на рис. 8.23. В стандарте IPv4 он располагается

между заголовком 1Р (вместе со всеми необязательными полями) и заголовком ТСР. В 1Ру6 это просто еще один дополнительный заголовок. Так он и воспринимается. Формат АН действительно очень близок к формату дополнительного заголовка 1Ру6. К полезной нагрузке иногда добавляют заполнение, чтобы достичь определенной длины, необходимой алгоритму идентификации. Это показано на рисунке.

Рис. 8.23. Заголовок идентификации IPsec в транспортном режиме для IPv4

Рассмотрим заголовок АН. Поле Следующий заголовок хранит предыдущее значение, которое в поле Протокол заголовка IP ранее было заменено на 51, чтобы показать, что далее следует заголовок АН. Обычно здесь встречается код для TCP (6). Поле Длина полезной нагрузки хранит количество 32-разрядных слов заголовка АН минус 2.

Поле Указатель параметров безопасности — это идентификатор соединения. Он вставляется отправителем и ссылается на конкретную запись в базе данных у получателя. В этой записи содержится общий ключ и другая информация данного соединения. Если бы этот протокол был придуман ITU, а не IETF, это поле, скорее всего, называлось бы Номером виртуального канала.

Поле Порядковый номер применяется для нумерации всех пакетов, посылаемых по защищенной связи. Все пакеты получают уникальные номера, даже если они посылаются повторно. Имеется в виду, что повторно передаваемый пакет имеет номер, отличный от номера оригинального пакета (даже если порядковый номер TCP тот же самый). Это поле служит для предотвращения взлома путем повторной передачи. Порядковые номера никогда не повторяются. Если же окажутся использоваными все 232 номера, для продолжения общения устанавливается новая защищающая связь.

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

новкой защищающей связи отправитель и получатель должны договориться о значении общего ключа, применяемого при вычислении подписи. Один из простейших способов заключается в вычислении хэш-функции для пакета и общего ключа. Отдельно общий ключ, конечно, не передается. Подобная схема называется НМАС (Hashed Message Authentication Code — код идентификации хэшированного сообщения). Вычисление этого кода выполняется гораздо быстрее, чем последовательный запуск SHA-1 и RSA.

Заголовок АН не позволяет шифровать данные. Его основная польза выявляется, когда важна проверка целостности, но не нужна секретность.

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

Альтернативой заголовку IPsec служит заголовок ESP (Encapsulating Security Payload — инкапсулированная защищенная полезная нагрузка). Как показано на рис. 8.24, этот заголовок может применяться как в транспортном режиме, так и в режиме туннелирования.

Заголовок ЕБР состоит из двух 32-разрядных слов: Указателя параметров безопасности и Порядкового номера. Мы их уже встречали в заголовке АН. Третье слово, которое обычно следует за ними, однако технически не является частью заголовка, — это Вектор инициализации (если только не применяется пустой алгоритм шифрования, тогда это поле опускается).

ЕБР, как и АН, обеспечивает проверку целостности при помощи НМАС, однако вместо того, чтобы включать хэш в заголовок, его вставляют после поля полезной нагрузки. Это видно на рис. 8.24. Такое расположение полей дает преимущество при аппаратной реализации метода. Оно заключается в том, что НМАС может подсчитываться во время передачи битов полезной нагрузки по сети и добавляться к ним в конец. Именно поэтому в ЕШегпеТ и других стандартах локальных сетей циклический контроль избыточности вставляется в концевик, а не в заголовок. При применении заголовка АН пакет приходится буферизировать и вычислять подпись, только после его можно отправлять. Это потенциалы

но приводит к уменьшению числа пакетов, которые можно передать за единицу времени.

Казалось бы, если ЕБР умеет делать все то же самое, что и АН, и даже больше, причем он еще и гораздо эффективнее, тогда зачем мучиться с АН? Причины этого в основном исторические. Изначально заголовок АН обеспечивал только проверку целостности, а ЕБР — только секретность. Позднее ЕБР научили использовать для проверки целостности, но разработчики АН не хотели, чтобы он канул в Лету после всей той работы, которую они проделали. Единственный аргумент в пользу АН заключается в том, что с его помощью можно частично проверять заголовок 1Р, чего не умеет ЕБР. И все же это аргумент довольно слабый. Еще один сомнительный аргумент состоит в том, что система, поддерживающая АН, но не поддерживающая ЕБР, возможно, будет иметь меньше проблем при получении лицензии на экспорт, поскольку этот заголовок не имеет отношения к секретности и шифрованию. Похоже, что АН со временем все-таки исчезнет с горизонта.

<< | >>
Источник: Э. ТАНЕНБАУМ. КОМПЬЮТЕРНЫЕ СЕТИ 4-Е ИЗДАНИЕ. 2003

Еще по теме IPsec:

  1. Л.О. Доліненко, В.О. Доліненко, С.О. Сарновська. Цивільне право України, 2006
  2. ЦИВІЛЬНЕ ПРАВО УКРАЇНИ
  3. ПЕРЕДМОВА
  4. Частина І ПРОГРАМА КУРСУ «ЦИВІЛЬНЕ ПРАВО УКРАЇНИ»
  5. Розділ І. Загальні положення цивільного права
  6. Тема 1. Поняття цивільного права. Предмет та метод, система цивільного права. Функції та принципи цивільного права
  7. Тема 2. Цивільне законодавство України
  8. Тема 3. Поняття, елементи та види цивільних правовідносин
  9. Тема 4. Здійснення цивільних прав і виконання обов’язків
  10. Тема 5. Захист цивільних прав та інтересів