Программа установки защищенных сетевых соединений с использованием протокола ISAKMP

Internet в последнее время стал популярной, недорогой базовой инфраструктурой. Универсальный доступ к нему заставил многие компании рассмотреть возможность создания виртуальной защищенной сети (Virtual Private Network VPN) на основе глобальной сети Internet (которая, по сути, представляет собой совокупность сетей). Преимущества VPN заключается в использовании базовой инфраструктуры Internet и для коммуникаций внутри компании (включая ее различные отделения) и для связи между компаниями, причем защищенность данных соединений остается такой же, как и в локальных корпоративных сетях.

Корпоративная сеть характеризуется тем, что все ее управление находится в руках ее владельцев, данные, передаваемые по ней, проходят только через узлы входящие в эту сеть и взаимодействие с внешним миром выражается в небольшом объеме передаваемых данных (иногда и полном отсутствие). При таких самодостаточных условиях сеть можно было сделать защищенной. VPN переводит корпоративную сеть на базис Internet. При этом, однако, возникает ряд существенных трудностей. Ни один из узлов не может управлять Internet-ом. Данные из разных источников передаются посредством общей инфраструктуры. Также, благодаря развитию электронной коммерции и бурному росту сетевых технологий, значительно возрос объем данных передаваемых между компаниями. Исходя из всех вышеперечисленных особенностей, можно сделать вывод, что структура VPN существенно отличается от старой традиционной корпоративной сети.

Координационным советом IETF (Internet Engineering Task Force) был разработан и предложен набор протоколов защиты сетевых соединений. IPSec протоколы обеспечивают целостность и конфиденциальность передаваемых данных, а также управление ключевой информацией и политикой защищенных соединений. Отличительной особенностью IPSec от более ранних подобных протоколов заключается в защите всего пути следования передаваемых данных (а не фрагмента, как это было раньше).

Для защиты трафика было предложено два протокола AH (Authentication Header) и ESP (Encapsulating Security Payload). Протокол AH (Authentication Header) заключается в подсчете и проверке значения хеш-функции с ключом от передаваемых данных. Протокол AH обеспечивает целостность и аутентичность данных и защищает от атак, основанных на переповторах пакетов (replay attack). В основе ESP протокола лежит шифрование и расшифрование данных, и он обеспечивает те же функции, что и AH, и дополнительно конфиденциальность передаваемой информации.

Эти две вышеуказанные особенности привели к возникновению проблемы управления ключевой информации и политик (параметров) соединений. Простейшим решением является ручное конфигурирование соединений, при котором параметры и секретные ключи жестко прописываются при запуске системы. К единственному достоинству можно отнести относительную простоту данного метода. Самым же большим недостатком данного метода можно считать отсутствие «масштабируемости». Это означает, что для установления секретного соединения ручным конфигурированием обе стороны должны договориться о ключе, используемом для защиты трафика и о параметрах его использования (выбор протокола, алгоритма и т. п.). Если речь идет о системе, состоящей из небольшого количества пользователей, то никаких проблем не возникает. Когда же количество пользователей составляет несколько тысяч (десятков, сотен…) процедура конфигурирования становится практически невыполнимой задачей. Другим недостатком ручного конфигурирования можно считать отсутствие простого механизма смены используемого ключевого материала. Т. е. ключ шифрование будет использоваться слишком долго (для слишком большого объема данных), что снижает защищенность передаваемых данных.

Другим способом конфигурирования соединений является использование специальных «key management» протоколов. Одним из таких протоколов явился ISAKMP. Данный протокол был также предложен координационным советом IETF. Протокол работает независимо от модуля осуществляющего защиту передаваемых данных. Результатом работы протокола является договоренные между двумя партнерами параметры защищенного соединения (включает в себя набор используемых протоколов защиты данных, алгоритмы, используемые в этих протоколах, параметры алгоритмов) и ключевая информация, для используемых алгоритмов. Полученная информация является выходными данными для протокола и должна быть передана модулю защиты передаваемых данных.

Протокол ISAKMP полностью решает проблему «масштабируемости». Ключевой материал высчитывается на основе данных, передаваемых в процессе аутентификации партнера и договора параметров соединения. При расчете также используется случайные величины, генерящиеся каждой из сторон для данного соединения, что обеспечивает разный ключевой материал при двух попытках установления соединения между одними и теми же партнерами. Данное свойство также позволяет не описывать правило секретного соединения для каждого из абонентов, а объединять их по какому-либо признаку (подсеть, диапазон IP адресов, определенный протокол и т. д.) и описать для них одно правило создания секретного соединения.

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

Анализ методов реализации системы защиты сетевых соединений

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

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

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

Для защиты трафика внутри VPN требовались специальные протоколы передачи данных и протоколы для получения параметров соединения и ключевой информации. На данный момент к протоколам первого типа относятся AH (Authentication Header) и ESP (Encapsulating Security Payload). AH передает данные и некую подпись по этим данным, что обеспечивает их целостность и подлинность. ESP передает зашифрованные данные, что обеспечивает дополнительно конфиденциальность данных.

К протоколам, обеспечивающим AH и ESP необходимыми параметрами и ключевой информацией, относится протокол ISAKMP. Он и будет подробнее рассмотрен далее в этой главе.

Структура протокола ISAKMP

В этом разделе будет рассмотрено, как ISAKMP протокол договаривается о параметрах и обменивается ключами между двумя системами, которые хотят создать секретное соединение.

Для того чтобы рассмотреть все на конкретном примере примем, что метод аутентификации — заранее известный секретный ключ (preshared key).

Все пакеты, которыми обмениваются партнеры в процессе установления соединения, начинаются с ISAKMP заголовка. Он содержит некоторую идентифицирующую информацию (Initiator Cookie, Responder Cookie и Message ID), тип обмена, флаги, номер версии и длину всего пакета.

Основное тело пакета состоит из payload-ов. Payload — объем информации, несущий определенную смысловую нагрузку. В дальнейшем этот элемент будем называть «компонентом».

Фаза 1 (Main Mode)

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

Рис. 1. Структура фазы 1 (Main Mode)

В пакете 1 инициатор посылает SA payload, компонент, который содержит все предлагаемые варианты параметров соединения. Его структура представлена на рисунке 2.

Рис. 2. Структура SA payload

SA payload содержит внутри себя список Proposal payload-ов, каждый из которых представляет собой отдельный протокол. Proposal payload-ы могут объединяться в группы по «И» и по «ИЛИ». Это осуществляется с помощью номеров данных компонент — одинаковые номера означают объединение по «И», а разные по ИЛИ. В свою очередь Proposal payload содержит список Transform payload-ов, которые представляют алгоритмы для данного протокола. Объединены они могут быть только по «ИЛИ». Transform payload содержит список атрибутов, конкретизирующих данный алгоритм (длина ключа) и содержащих другие параметры соединения. Атрибуты не могут выбираться, или принимается весь список атрибутов или все отвергает.

Таким образом, инициатор посылает ответчику на выбор список списков протоколов и для каждого протокола на выбор список алгоритмов. Из всего этого ответчик выбирает список протоколов, причем для каждого протокола может быть выбран только один алгоритм и набор атрибутов для данного алгоритма не может изменяться (ни добавления / удаления, ни изменения), т. е. алгоритм или принимается со всем списком атрибутов, или отвергается. Выбранная информация оформляется также в SA payload, и отправляется инициатору вторым пакетом.

Итогом первых двух пакетов, или первого обмена, становиться договоренность относительно параметров соединения.

В пакетах 3 и 4 передаются KE payload и Nonce payload. В КЕ payload инициатор и ответчик обмениваются своими открытыми ключами для алгоритма Diffie-Hellman. Они потребуются на последующих этапах для расчета общего ключа. Nonce payload содержит случайную последовательность любого размера, которые также будут участвовать при расчете ключевой информации.

После этого обмена можно начать расчет ключевой информации. На основе чужого открытого и своего секретного ключей рассчитывается общий ключ (g^xy) по алгоритму Diffie-Hellman. Затем производится расчет некоторых служебных констант.

SKEYID = PRF (Preshared Key, Ni | Nr)

где Preshared Key — заранее известный секретный ключ.

SKEYID_d = PRF (SKEYID, g^xy | CKY-I | CKY-R | 0)

SKEYID_a = PRF (SKEYID, SKEYID_d | g^xy | CookieI | CookieR | 1)

SKEYID_e = PRF (SKEYID, SKEYID_a | g^xy | CookieI | CookieR | 2)

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

Из SKEYID_e мы получаем ключевую информацию. Остальные константы будут использованы при дальнейших расчетах.

В пакетах 5 и 6 партнеры обмениваются информацией, которая их идентифицирует (IDii и IDir) и информацией, которая их аутентифицирует (HASH_I, HASH_R). Идентификационная информация передается посредством Identification payload, где указывается тип идентификационной информации (IP адрес, имя пользователя, SubNet и т. п.) и собственно значение.

Аутентификационная информация передается через Hash payload. Его содержимое рассчитывается по следующим формулам (для инициатора и ответчика соответственно):

HASH_I = PRF (SKEYID, g^xi | g^xr | CookieI | CookieR | SAi | IDii)

HASH_R = PRF (SKEYID, g^xr | g^xi | CookieR | CookieI | SAi | IDir)

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

Фаза 1 (Aggressive Mode)

Aggressive Mode выполняет те же функции, что и Main Mode, но укладывается всего в три пакета. Такое упрощение, однако, приводит к тому, что он более подвержен атакам, чем Main Mode. На рисунке 3 представлена структура Aggressive Mode.

В пакете 1 инициатор посылает сразу SA payload с предложением параметров соединения, KE payload со своим открытым ключом, Nonce payload со случайной информацией и идентифицирует себя с помощью Identification payload.

Сразу видны недостатки данного режима. В SA payload-е не может быть предложено более одной группы параметров для алгоритма Diffie-Hellman-а т. к. сразу же посылается открытый ключ, а его размер напрямую зависит от этих параметров. В данном режиме, в отличие от Main Mode, идентификационная информация посылается в открытом виде.

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

Рис. 3. Структура фазы 1 (Aggressive Mode)

Инициатор из пакета 2 берет необходимую информацию. Затем вычисляет рабочие константы, аутентификационную информацию и ключи шифрования. Пакетом 3 инициатор аутентифицирует себя.

Фаза 2 (Quick Mode)

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

Рис. 4. Структура фазы 2 (Quick Mode)

Режим состоит из трех пакетов. Его структура представлена на рисунке 4. В первом пакете инициатор посылает SA payload, содержащий предложения о параметрах будущего соединения, случайную информацию (Nonce payload) для создания ключевой информации. Все остальные компоненты пакета являются опциональными. Если для расчета ключевой информации требуется использовать «свежий» ключевой материал, то осуществляется еще один обмен открытыми ключами, в противном случае для расчета берется информация из первой фазы. Также, если локальная политика требует использование во второй фазе идентификационной информации отличной от информации используемой в первой фазе, добавляются соответствующие Identification payload-ы.

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

Третий пакет посылается инициатором в подтверждение правильности принятой информации и содержит только Hash payload, который вычисляется с помощью буфера случайных данных, посланных ответчиком во втором пакете. Содержимое Hash payload-ов вычисляются по следующим формулам:

HASH (1) = PRF (SKEYID_a, Message ID | SA | Ni [| KE] [| IDic | IDcr])

HASH (2) = PRF (SKEYID_a, Message ID | Ni | SA | Nr | [| KE] [| IDic | IDcr])

HASH (3) = PRF (SKEYID_a, 0 | Message ID | Ni | Nr)

Формула для расчета окончательного ключевого материала зависит от того, был ли обмен открытыми ключами для создания нового общего ключа. Если такого обмена не было, то формула следующая:

KEYMAT = PRF (SKEYID_d, protocol | SPI | Ni | Nr)

где protocol — номер протокола, для алгоритма которого считается ключевой материал.

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

KEYMAT = PRF (SKEYID_d, g^xy | protocol | SPI | Ni | Nr)

Таким образом, после второй фазы мы получаем всю необходимую информацию для создания секретного соединения. Список применяемых протоколов и используемых в них алгоритмы получается после обмена SA payload-ами во второй фазе. Ключевая информация для каждого алгоритма рассчитывается по приведенным выше формулам. Следует заметить, что приведенная выше структура протокола была упрощена для простоты восприятия (отсутствует рассмотрение остальных методов аутентификации и New Group Mode).

Виды сетевых атак

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

Отказ в обслуживании (Denial of Service)

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

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

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

Человек посередине (Man-in-the-Middle)

Целью атаки являются конфиденциальность и целостность данных. Атака заключается в том, что злоумышленник, вклиниваясь в процесс установления секретного соединения, представляется для каждой из сторон ее партнером и проводит установление соединения от ее имени. В результате вместо одного защищенного канала между двумя партнерами получается два канала между каждой из сторон и злоумышленником. Для каждого из партнеров все выглядит обычным образом, но злоумышленник получает возможность не только просматривать данные, передаваемые по «защищенному» каналу, но даже модифицировать их. Структура описанной атаки представлена на рисунке 5.

Sx — секретный ключ, Px — открытый ключ Защита от данного вида атаки в протоколе ISAKMP заключается в процессе аутентификации. Обязательное выполнение этого процесса во время первой фазы гарантирует обеим сторонам отсутствие «человека посередине», который смог бы прослушивать и модифицировать передаваемые данные не только во второй фазе, но и при передаче основной информации. В данном случае стойкость протокола к данному типу атаки определяется надежностью метода аутентификации. Для метода заранее известного секретного ключа это определяется уникальностью данного ключа, для методов, использующих сертификаты — достоверностью полученного сертификата.

Повтор посылки (Replay attack)

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

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

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

Во второй части были представлены основные типы сетевых атак, объяснен принцип их действия и, на основе структуры протокола ISAKMP, показано как он противостоит этим атакам.

Разработка программы

Определение места программы в системе защиты сетевого трафика

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

На рисунке 6 представлена структура системы защиты сетевого трафика. Рассмотрим отдельно каждый модуль.

Модуль управления

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

Модуль хранения основной ключевой информации

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

Модуль обработки сетевого трафика

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

Модуль ISAKMP

По запросу со стороны модуля управления и используя информацию из конфигурации, создает правила обработки трафика. Взаимодействует с модулем управления и модулем хранения ключевой информации ISAKMP. В модуль хранения ключевой информации сохраняются внутренние соединения, созданные во время первой фазы и использующиеся для защиты последующих фаз. От модуля управления получает запрос на создание соединения, информацию из конфигурации для формирования / выбора параметров соединения и формирования / проверки идентифицирующей информации и информацию для аутентификации себя. Обратно в модуль управления отдается созданное соединение или сигнал о неудачной попытке его создания.

Модуль хранения ключевой информации ISAKMP

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

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

Разработка общей структуры программы

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

Что такое нить (thread)?

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

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

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

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

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

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

Однако использование нитей несет в себе несколько опасностей, и главная из них это работа с общей памятью. Рассмотрим конкретный пример. Оператор увеличения переменной на единицу для программы выливается в 3 действия:

Загрузить значение переменной в регистр Увеличить регистр Записать значение регистра в переменную Если две нити начнут выполнять этот оператор одновременно, то может произойти следующая последовательность действий:

Нить 1 Нить 2

1 Загрузить значение переменной в регистр

1 Загрузить значение переменной в регистр

2 Увеличить регистр

3 Записать значение регистра в переменную

2 Увеличить регистр

3 Записать значение регистра в переменную В этом случае нить 1 перезапишет значение записанной нитью 2, и переменная увеличится лишь на единицу вместо двух. Такие места в коде называют критическими секциями и организуют работу так, что они гарантировано выполняются только одной нитью.

Использование многонитевого принципа построения моей программы вызвано двумя причинами:

Необходимость постоянно прослушивать требуемый порт на наличие пришедшего пакета.

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

Механизм обмена информации между нитями

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

#include

int pipe (int filedes[2]);

Функция возвращает 0 в случае успеха и -1 при ошибке. Параметрами в функцию предается массив из двух дескрипторов, которые заполняются внутри функции. В первый дескриптор (filedes[0]) предназначен для чтения из pipe, а второй (filedes[1]) для записи в pipe. Чтение из pipe и запись в него производятся с помощью стандартных функций read и write. Для этих функций дескриптор pipe ничем не отличается от дескриптора файла.

#include

ssize_t read (int fildes, void *buf, size_t nbyte);

ssize_t read (int fildes, void *buf, size_t nbyte);

Вторым параметром в функции передается указатель на буфер, куда записывать данные (для read) или откуда считывать их (для write). Третьим параметром для read передается максимальное число читаемых данных, я для write число записываемых байт.

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

Рис. 8. Структура передаваемых запросов Первым байтом в сообщении идет тип данного сообщения, который говорит, какие именно данные содержаться. Если тип сообщения не предусмотрен в месте, куда это сообщение пришло, сообщается об ошибке и из pipe считывается буфер максимальной длины. Следующие за типом сообщения 4 байта содержат длину передаваемых данных. Если тип сообщения налагает какие-либо ограничения на длину данных (например, если передается IP адрес, то его длина должна быть 4 байта) и считанная длина этим ограничениям не удовлетворяет, то также сообщается об ошибке, и стараемся все вычитать из pipe. После этого из pipe достаются данные указанной длины. После обработки считанного запроса процедура повторяется заново, начиная с получения типа сообщения. Такой формат сообщения и приведенный порядок его обработки гарантирует, что никакое сообщение не будет потеряно.

Нитевая структура программы

В этом разделе будет рассмотрено, из каких нитей состоит программа, их назначение и как они взаимодействуют друг с другом. На рисунке 9 представлена нитевая структура программа.

Рис. 9. Нитевая структура программы На рисунке окружностями условно показаны нити, одинарными стрелками передача данными между нитями, а двойными взаимодействие с таблицей (добавление, поиск и удаление). Программа содержит 4 вида нитей:

Нить работы с сетью Нить распределения пакетов Нить выполнения первой фазы Нить выполнения второй фазы

Нить работы с сетью. Задачей данной нити является непрерывная проверка порта на наличие пакета и прием запросов от других модулей на отсылку пакетов. Работа данной нити начинается с открытия порта (функция socket) и указания адреса и порта, с которым мы будем работать[9].

struct sockaddr_in serveraddr;

if ((sockdscr = socket (AF_INET, SOCK_DGRAM, 0)) == -1) {

printf («Server error: cannot open socketn»);

return NULL;

}

memset (&serveraddr, 0, sizeof (serveraddr));

serveraddr.sin_family = AF_INET;

serveraddr.sin_port = htons (Conf. LocalPort);

serveraddr.sin_addr.s_addr = inet_addr (Conf. LocalAddress); if (bind (sockdscr, (struct sockaddr *)&serveraddr, sizeof (serveraddr))==-1) {

printf («Server error: cannot bindn»);

return NULL;

}

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

#include

int select (int nfds, fd_set *readfds, fd_set *writefds,

fd_set *errorfds, struct timeval *timeout);

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

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

FD_SET (sockdscr, &rfds); /* Добавление в массив дескриптора порта*/

FD_SET (pipefd[0],&rfds); /* Добавление в массив дескриптора pipe*/

retval=select (1024,&rfds, NULL, NULL, NULL);

if (SOCKET_ERROR == retval) {

/* Обработка ошибки*/

}

if (FD_ISSET (sockdscr, &rfds)) {

/* Действия, выполняемые при приходе пакета */

}

if (FD_ISSET (pipefd[0], &rfds)) {

/* Действия, выполняемые при получении запроса */

}

В случае прихода пакета он целиком передается нити распределения пакетов (вместе с ним передаются также IP адрес и номер порта отправителя). При получении запроса на посылку пакета пакет отсылается, причем адрес и номер порта получателя должен находиться в запросе.

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

Первые 8 байт занимает Initiator Cookie — иидентификатор попытки установления соединения со стороны инициатора. Значение данного поля выбирается на стороне инициатора (случайным или предопределенным образом) и служит при дальнейшем распределении пакетов. Responder Cookie играет такое же значение, но для ответчика.

Рис. 10. Структура ISAKMP заголовка Следующим полем идет Next Payload, которое показывает тип компонента (payload) следующего за заголовком. Version показывает версию используемого протокола. Exchange type говорит о режиме, при котором используется данный пакет (Main Mode, Aggressive Mode, Quick Mode и т. п.). Флаги содержат информацию о состоянии пакета, например, зашифрован он или нет. Еще одним идентификатором пакета является Message ID. Последние 4 байта содержат длину всего пакета, включая сам заголовок.

Идентификация пакета проводится по следующим принципам. В первом пакете инициатор проставляет Initiator Cookie, а Responder Cookie оставляет нулевым, давая возможность ответчику при ответе заполнить его. Message ID служит для идентификации разных попыток установления соединения во второй фазе, идущих под защитой одной и той же первой фазы, а, следовательно, имеющих одинаковые CookieI и CookieR.

Порядок обработки пакета следующий Проверка длины пакета. Производится простым сравнением длины полученного пакета, которую мы узнаем при чтении пакета из порта и значением соответствующего поля в ISAKMP заголовке. Данная проверка является очень простой, но в то же время весьма эффективной, т. к. позволяет быстро (фактически на самом первом этапе), без затрачивания больших ресурсов отсечь случайные пакеты. Здесь мы впервые встречаемся с проблемой разного способа хранения чисел на разных архитектурах. Если рассмотреть конкретный пример, то число 0×1 020 304 в системе с процессором Sun Sparc будет представлено в виде т. е. сначала идут старшие цифры (так называемое big-endian представление), а для процессора Intel

сначала идут младшие цифры (little-endian). Из-за требования поддерживать обе платформы использовать простое проведение памяти к типу unsigned int нельзя, т. к. значение длины пакета, например, 100 для Sun Sparc будет 100, а для Intel 1 677 721 600. Для решения этой проблемы были написаны макросы для перевода чисел из одного состояния в другое для обеих платформ.

#define GET_32BIT (cp)

(((unsigned long) (unsigned char) (cp) [3]) |

((unsigned long) (unsigned char) (cp) << 8) |

((unsigned long) (unsigned char) (cp) << 16) |

((unsigned long) (unsigned char) (cp) << 24))

#define GET_16BIT (cp)

(((unsigned long) (unsigned char) (cp) [1]) |

((unsigned long) (unsigned char) (cp) << 8))

#define PUT_32BIT (cp, value)

(cp) = (value);

(cp) = (value) >> 8;

(cp) = (value) >> 16;

(cp) = (value) >> 24;

#define PUT_16BIT (cp, value)

(cp) = (value);

(cp) = (value) >> 8;

Если проверка не прошла, то дальнейшее рассмотрение пакета заканчивается и пакет удаляется.

Проверяем допустимость значений некоторых других полей заголовка — Next Payload, Version, Exchange Type и Flags. Эти поля проверяются не на точное совпадение, как длина пакета, а на вхождение значения в диапазон допустимых значений. Проверка корректности данных значений будет произведена позже, при детальном рассмотрении структуры пакета Поиск в таблице нитей первой фазы возможного получателя пакета. Поиск ведется на основе значений CookieI и CookieR. Т.к. некоторые пакеты могут представлять собой запросы на создание соединений с другой стороны (т.е. нить для их обработки еще не создана), переповторы этих запросов (нить уже создана и уже проставлено значение CookieR, т. е. в данную нить пакет не попадет), а также ответы на наши запросы (CookieR в таблице стоят нулевые), то порядок поиска подходящей записи в таблице следующий: «если значение CookieR в пакете или таблице нулевое, то запись считается сработавшей, если совпало только значение CookieI, иначе должны совпасть значение и CookieR, и CookieI». Если мы нашли сработавшую запись, то мы получим дескриптор записи для pipe, связывающей с нужной нитью, по которому и передадим пакет. Если запись не найдена и значение CookieR равно нулю это означает, что это первый пакет новой попытки установления соединения. Для данного пакета мы создаем новую нить, pipe для связи с этой нитью, делаем добавление записи в таблицу нитей первой фазы, после чего передаем пакет только что созданной нити. Если не выполнилось ни одного из вышеперечисленных условий, то пакет считается неверным и удаляется.

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

Нить выполнения первой фазы. Данная нить предназначена для проведения первой фазы установления соединения.

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

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

#define INITIATOR 0x0

#define RESPONDER 0×80

#define MAIN 0x0

#define AGGRESSIVE 0×40

#define ABSENT 0×0 /* Метод аутентификации еще не определен*/

#define PRESHARED 0x8

#define DSA_SIGN 0×10

#define RSA_SIGN 0×18

#define RSA_ENC 0×20

#define RSA_REV_ENC 0×28

#define RENCRYPT 0×30

#define GET_ROLE (State) (State&0×80)

#define GET_EXCH (State) (State&0×40)

#define GET_MODE (State) (State&0×38)

#define GET_STEP (State) (State&0×03)

#define SET_ROLE (State, Role) {State &= 0×80; State+=Role;}

#define SET_MODE (State, Meth) {State &= 0xC7; State+=Meth;}

#define SET_EXCH (State, Meth) {State &= 0xBF; State+=Meth;}

#define STATE (role, exch_type, mode, step) (role+exch_type+mode+step)

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

/*Получение о предварительная обработка пакета*/

switch (state. State) /* Выбор набора требуемых функций */

{

case STATE (RESPONDER, AGGRESSIVE, ABSENT, 0):

/* Набор функций для данного состояния */

break;

case STATE (RESPONDER, MAIN, ABSENT, 0):

/* Набор функций для данного состояния */

break;

…

case STATE (INITIATOR, MAIN, DSA_SIGN, 2):

/* Набор функций для данного состояния */

break;

}

Переменная текущего состояния также активно используется при расчетах, где формулы отличаются в зависимости от метода аутентификации или исполняемой роли (инициатор или ответчик). Отсылка созданного пакета осуществляется через доступный каждой нити дескриптор записи pipe нити работы с сетью После окончания первой фазы нить переходит в режим управления нитями второй фазы. Пакеты для этих нитей по значению CookieI и CookieR приходят в данную нить, а затем согласно значению Message ID отправляются в нити второй фазы или инициируют их создание. Для проведения правильной идентификации пакетов каждая нить первой фазы содержит свою таблицу нитей второй фазы, по которой и проводит поиск.

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

Таблицы поиска нитей

Таблица нитей выполняющих первую фазу представляет собой список CookieTable_t структур

struct CookieTable_t;

typedef struct CookieTable_t {

uchar CookieI[8]; /*Initiator Cookie */

uchar CookieR[8]; /* Responder Cookie */

int pd; /* Pipe Descriptor */

uchar Ready; /* Ready Flag */

struct in_addr AlienAddr; /* Peer IP Address */

struct CookieTable_t *next; /* Next Member (NULL if last) */

};

Необъясненными в данной структуре остались два поля: флаг Ready и структура IP адреса. В структуре IP адреса находится адрес партнера, с которым мы ведем процесс установления соединения. Флаг Ready показывает, закончилось или нет проведение первой фазы. Он используется, если со стороны модуля управления пришло 2 запроса на инициацию попытки установления соединения. В этом случае просматривается таблица нитей первой фазы в поисках записи с указанным IP адресом. Если флаг Ready в данной записи говорит о том, что первая фаза уже завершена, то запрос формируется на проведение сразу второй фазы. IP адрес может также использоваться при поиске нити для пришедшего пакета.

Ниже приведен пример функции поиска записи в таблице по совпадению и CookieI и CookieR.

CookieTable_t *FindCookieRecord (uchar *CI, uchar *CR) {

uchar Test[8] = {0, 0, 0, 0, 0, 0, 0, 0};

struct CookieTable_t *ptr = CookieTable;

while (ptr)

(MEMCMP (Test, ptr->CookieR, 8)&&MEMCMP (CR, ptr->CookieR, 8)))

ptr = ptr->next;

else

return ptr;

return NULL;

}

Таблица нитей второй фазы тоже представляет собой список структур.

struct Phase2Table_t;

typedef struct Phase2Table_t {

uchar MessageID[4]; /* Message ID */

int pd; /* Pipe Descriptor */

struct SPIlist_t SPIlist; /* List of SPIs */

struct Phase2Table_t next; /* Next Member (NULL if last) */