Дифференцированная защита трафика средствами IPSес

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

В предыдущем выпуске рубрики было определено место системы протоколов IPSec в ряду других технологий защищенного канала. Было показано, что IPSec обеспечивает защищенную передачу данных в рамках логического соединения — безопасной ассоциации (Security Association, SA), причем протокол распределения ключей IKE отвечает за установление SA, а протоколы защиты данных AH и ESP выполняют обработку передаваемых пакетов в соответствии с созданной для них безопасной ассоциацией.

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

ПРОТОКОЛ AH

Протокол AH позволяет приемной стороне убедиться в следующем:

• пакет был отправлен стороной, с которой установлена данная ассоциация;
• содержимое пакета не было искажено в процессе передачи его по сети;
• пакет не является дубликатом некоторого пакета, полученного ранее.

Две первые функции обязательны для протокола AH, а последняя — факультативная — выбирается при установлении ассоциации. Для выполнения этих функций протокол AH использует заголовок следующего вида (см. Рисунок 1).

Рисунок 1. Структура заголовка протокола АН.

В поле Next Header указывается код типа протокола более высокого уровня, т. е. протокола, сообщение которого размещено в поле данных пакета IP. Скорее всего, им будет один из протоколов транспортного уровня (TCP или UDP) или протокол ICMP, но может встретиться и протокол ESP, если он используется в комбинации с AH.

В поле Payload Length содержится длина заголовка AH.

Следующее поле — Security Parame-ters Index (SPI) — используется для связи пакета с предусмотренной для него безопасной ассоциацией. Немного позже мы обсудим его более подробно.

Поле Sequence Number (SN) указывает на последовательный номер пакета и применяется для защиты от его ложного воспроизведения, когда третья сторона пытается повторно использовать перехваченные защищенные пакеты, отправленные действительным аутентифицированным отправителем. Отправляющая сторона последовательно увеличивает значение этого поля в каждом новом пакете, передаваемом в рамках данной ассоциации, так что приход дубликата будет замечен принимающей стороной, если только функция защиты от ложного воспроизведения была активирована в рамках ассоциации. Однако в любом случае в функции протокола AH не входит восстановление утерянных и упорядочивание прибывающих пакетов — он просто отбрасывает пакет в том случае, когда обнаруживает, что аналогичный пакет уже был получен. Чтобы сократить требуемую для работы протокола буферную память, используется механизм скользящего окна — на предмет дублирования проверяются только те пакеты, чей номер находится в пределах окна. Окно обычно выбирается шириной в 32 или 64 пакета.

Для аутентификации и проверки целостности пакета используется поле Authentication Data, которое содержит так называемое «значение контроля целостности» (Integrity Check Value, ICV). Это значение, называемое также дайджестом, вычисляется с помощью одной из двух обязательно поддерживаемых протоколом AH односторонних функций шифрования MD5 или SAH-1, но может использоваться и любая другая факультативная функция, о которой стороны договорились во время установления ассоциации. При вычислении дайджеста в качестве аргумента односторонней функции выступает содержимое пакета, а в качестве параметра — симметричный секретный ключ, который был задан для данной ассоциации вручную или автоматически с помощью протокола IKE. Так как длина дайджеста зависит от выбранной функции, то это поле имеет в общем случае переменный размер (наиболее часто используемая функция MD5 всегда порождает 16-байтный дайджест).

Протокол AH старается охватить при вычислении дайджеста как можно большее число полей исходного IP-пакета, но некоторые из них изменяются непредсказуемым образом в процессе передачи пакета по сети и поэтому не могут быть включены в аутентифицируемую часть пакета. Например, целостность значения поля времени жизни (Time To Live, TTL) в приемной точке канала оценить нельзя, так как оно каждым промежуточным маршрутизатором уменьшается на единицу и никак не может совпадать с исходным, поэтому традиционные методы контроля целостности, основанные на повторном вычислении дайджеста, здесь применяться не могут.

Местоположение заголовка AH в пакете зависит от того, в каком режиме — транспортном или туннельном — сконфигурирован защищенный канал. Результирующий пакет в транспортном режиме выглядит так, как показано на Рисунке 2.

Рисунок 2. Результирующий пакет протокола АН в транспортном режиме.

При использовании туннельного режима, когда шлюз IPSec принимает проходящий через него транзитом исходящий пакет и создает для него внешний IP-пакет, протокол AH защищает все поля исходного пакета, а также неизменяемые поля нового заголовка внешнего пакета (см. Рисунок 3).

Рисунок 3. Результирующий пакет протокола АН в туннельном режиме.

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

ПРОТОКОЛ ESP

Протокол ESP решает две группы задач. К первой из них относятся функции, аналогичные функциям протокола AH, — это обеспечение аутентификации и целостности данных на основе дайджеста, а ко второй — защита данных от несанкционированного просмотра путем шифрования передаваемых данных.

Рисунок 4. Структура заголовка протокола ESP.

Для решения своих задач протокол ESP использует заголовок следующего формата (см. Рисунок 4). Некоторые его поля аналогичны полям заголовка AH: Next Header, SPI, SN, Authentication Data. Но имеются и два дополнительных поля — заполнитель (Padding) и длина заполнителя (Pad Length). Заполнитель может понадобиться в трех случаях. Во-первых, для нормальной работы некоторых алгоритмов шифрования необходимо, чтобы шифруемый текст содержал кратное число блоков определенного размера. Во-вторых, формат заголовка ESP требует, чтобы поле данных заканчивалось на границе четырех байтов. И, наконец, заполнитель можно использовать для сокрытия действительного размера пакета в целях обеспечения так называемой частичной конфиденциальности трафика. Правда, протокол ESP ограничивает возможности маскировки 255 байт заполнителя; это сделано для того, чтобы из-за большого объема избыточных данных не слишком снижалась полезная пропускная способность канала связи.

Как видно из рисунка, заголовок делится на две части, разделяемые полем данных (Payload Data). Первая часть, которая далее будет обозначаться как заголовок ESP, образуется двумя полями SPI и SN и размещается перед полем данных. Остальные служебные поля протокола ESP расположены в конце пакета. Непосредственно за полем данных следует так называемый трейлер, или хвост, в который входят заполнитель (Padding), длина заполнителя (Pad Length), а также указатель на протокол следующего уровня (Next Header). Завершает пакет поле контроля целостности (Authentication Data). В том случае, когда при установлении безопасной ассоциации принято решение не использовать возможностей ESP по обеспечению целостности, это поле отсутствует.

На Рисунке 5 показано размещение полей заголовка ESP в транспортном режиме, а также его области защиты по двум группам функций.

В этом режиме ESP не шифрует заголовок IP-пакета, иначе маршрутизатор не сможет прочитать поля заголовка и корректно осуществить продвижение пакета между сетями. В число шифруемых полей не попали также поля SPI и SN, которые должны передаваться в открытом виде для того, чтобы прибывший пакет можно было отнести к определенной ассоциации и защититься от ложного воспроизведения пакета.

В отличие от протокола AH, контроль целостности и аутентичности данных в протоколе ESP не распространяется на заголовок исходного пакета, и по этой причине имеет смысл применять оба протокола совместно — ESP для шифрования, а AH для контроля целостности.

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

БАЗЫ ДАННЫХ SAD И SPD

Итак, IPSec предлагает различные методы защиты трафика. Каким же образом реализация IPSec, работающая на хосте или шлюзе, определяет способ защиты, который она должна применить к трафику? Решение основано на использовании в каждом узле, поддерживающем IPSec, двух типов баз данных: базы данных безопасных ассоциаций (Security Associations Database, SAD) и базы данных политики безопасности (Security Policy Database, SPD).

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

Другой тип базы данных — база данных политики безопасности SPD — задает соответствие между IP-пакетами и установленными для них правилами обработки. Записи SPD состоят из полей двух типов — поля селектора пакета и поля политики защиты для пакета с данным значением селектора (см. Рисунок 7).

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

• IP-адресов источника и назначения. Эти адреса могут быть представлены как отдельным адресом (любого типа — индивидуальным, групповым или широковещательным), так и диапазоном адресов, заданным с помощью верхней и нижней границы, либо с помощью адреса и маски;
• портов источника и назначения (т. е. портов TCP или UDP);
• типов протокола транспортного уровня (TCP, UDP);
• имени пользователя в формате DNS или X.500;
• имени системы (хоста, шлюза безопасности и т. п.) в формате DNS или X.500.

Для каждого нового пакета, поступающего в защищенный канал, IPSec просматривает все записи в базе SPD и сравнивает значение селекторов этих записей с соответствующими полями IP-пакета. Если значение полей совпадает с каким-либо селектором, то над пакетом выполняются действия, определенные в поле политики безопасности данной записи. Политика предусматривает одну из следующих возможностей: передача пакета без изменения, отбрасывание, обработка средствами IPSec.

В последнем случае поле политики защиты должно содержать ссылку на запись в базе данных SAD, в которую помещен набор параметров безопасной ассоциации для данного пакета. (В примере на Рисунке 7 для исходящего пакета определена ассоциация SA3.) На основании заданных параметров к пакету применяется соответствующий протокол (на рисунке — ESP), функции шифрования и секретные ключи. В том случае, когда пакет нужно обработать с помощью обоих протоколов AH и ESP, администратор должен создать в базе SPD две записи, соответствующие двум ассоциациям. Если к исходящему пакету нужно применить некоторую политику защиты, но указатель записи SPD показывает, что в настоящее время нет активной SA с такой политикой, то IPSec создает новую ассоциацию с помощью протокола IKE, помещая новые записи в базы данных SAD и SPD.

Каждый узел IPSec должен поддерживать две базы SPD: одну — для исходящего трафика, а другую — для входящего, так как защита в разных направлениях может требоваться разная. Базы данных политики безопасности создаются и управляются либо пользователем (этот вариант больше подходит для хоста), либо системным администратором (вариант для шлюза), либо приложением.

Выше мы рассмотрели, как происходит установление связи между входящим пакетом IP и заданной для него безопасной ассоциацией. Но остается другой вопрос: как принимающий узел IPSec определяет, к какой ассоциации относится прибывший пакет, ведь при использовании шифрования многие ключевые параметры, составляющие селектор, будут недоступны. Для решения этой проблемы в заголовках AH и ESP предусмотрено особое поле SPI, куда помещается указатель на строку базы данных SAD, в которой записаны параметры соответствующей SA. Данное поле заполняется протоколами AH или ESP во время обработки пакета в отправной точке защищенного канала. Когда пакет приходит в оконечный узел защищенного канала, из его заголовка ESP или AH (на рисунке из заголовка ESP) извлекается указатель SPI, и дальнейшая обработка пакета выполняется с учетом всех параметров заданной этим указателем ассоциации.

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

Использование баз SPD и SAD для управления процессом защиты трафика позволяет достаточно гибко сочетать механизм безопасных ассоциаций, который предусматривает установление логического соединения, с дейтаграммным характером трафика протокола IP. Соответствующая настройка базы SDP позволяет выбирать нужную степень детализации защиты — от применения одной общей ассоциации для трафика большого количества конечных узлов до защиты каждого отдельного приложения с помощью индивидуально настроенной ассоциации.