Обработка исходящего IP трафика

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

1. Когда пакет поступает от защищенного интерфейса, функция выбора SPD указывает нужную БД, если их несколько. Если БД одна, то этот шаг пропускается.

2. Производит поиск элемента соответствующего заголовкам пакета в кэше SPD (быстрый поиск). Для этого рассматриваются только кэши SPD-O и SPD-S.

3. Если быстрый поиск дал результат, то выполняется действие соответствующее элементу: пакет отбрасывается, пропускается без обработки или защищается с помощью AH или ESP. Если применяется IPsec защита, то в данном элементе кэша содержится ссылка на соответствующий элемент SAD, который определяет туннельный или транспортный режим, AH или ESP, необходимые криптографические алгоритмы, ключи, SPI, PMTU и так далее.

4. Если быстрый поиск в кэше не дал результатов, то производится поиск в самой SPD (используются только части SPD-O и SPD-S (части БД и части кэша называются одинаково и имеют тот же смысл, но в кэше содержатся только элементы, с которыми шла работа последнее время для быстрого поиска, а в БД хранится полный набор элементов)). Для трафика, который должен быть пропущен без обработки или отброшен создаются соответствующие записи в кэше SPD-O. Для трафика, который должен быть пропущен без обработки создается соответствующая запись и в кэше SPD-I. Если трафик должен быть защищен, то вызывается механизм создания SA (например, IKEv2). При успешном создании SA в кэш SPD-S будет добавлена запись для исходящего трафика, а в SAD добавлены две записи - для исходящего и входящего защищенного трафика, так как SA создаются парами. Если процедура создания SA не будет успешна, то пакет необходимо отбросить. Входящий SA содержит значение селекторов полученных из элемента SPD (и из пакета, если указан флаг «взять значение из пакета»), они используются при проверке входящих пакетов принятых через этот SA.

5. Далее пакет проходит через функцию маршрутизации, которая определяет, через какой интерфейс (если их у системы несколько) он будет отправлен. Так же пакет может быть отправлен системой самой себе для дополнительной IPsec обработки, например, для поддержки вложенных SA. Для этого должна быть соответствующая запись в SPD-I разрешающая входящий IPsec трафик от самой системы, иначе пакет будет отброшен.

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

· Элемент SPD, селекторам которого удовлетворяет пакет, прямо говорят отбросить его. В таком случае необходимо послать источнику ICMP сообщение: тип - «местоназначение недостижимо», код - «взаимодействие запрещено администратором»

· Элемент SPD, селекторам которого удовлетворяет пакет, требует создания SA. Но SA не может быть установлен по следующим причинам: администратор запретил удаленной системе взаимодействовать с инициатором; инициатор или удалённая система не смогли аутентифицировать друг друга; SPD удаленной системы не имеет подходящей записи для данного пакета. Источнику пакета должно быть отправлено ICMP сообщение: тип - «местоназначение недостижимо», код - «взаимодействие запрещено администратором»

· Элемент SPD, селекторам которого удовлетворяет пакет, требует создания SA. Но SA не может быть установлен, так как с удаленной системой нет связи (она не отвечает). Источнику пакета должно быть отправлено ICMP сообщение: тип - «местоназначение недостижимо», код - «хост недостижим»

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

Для исходящего пакета в туннельном режиме AH и ESP конструируется новый внешний IP заголовок пакета, учитывая следующие моменты:

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

· Внутренний IP заголовок не меняется, за исключением поля времени жизни TTL и полей DS/ECN. Эти изменения происходят на конечных точках туннеля. В процессе прохождения пакета по туннелю изменений не происходит

· Так же не изменяются поля опций IPv4 пакета или заголовки расширения IPv6 пакета.

Далее подробно рассмотрены поля для внешнего и внутреннего заголовка IPv4 пакета. Внешний заголовок:

· Версия протокола - 4, однако версии протокола внутреннего и внешнего заголовков не обязаны совпадать, то есть можно инкапсулировать IPv4 пакет в IPv6 и наоборот.

· Длина заголовка - вычисляется

· Поле DS (приоритет трафика, качество обслуживания) - копируется из внутреннего заголовка, но может задаваться фиксированным значением

· Поле ECN (перегрузка (затор) сети) - копируется из внутреннего заголовка

· Длина пакета - вычисляется

· Идентификатор пакета - вычисляется

· Флаг DF (запрет фрагментации) - копируется из внутреннего заголовка или задается фиксированным значением

· Смещение фрагмента - вычисляется

· Время жизни пакета - вычисляется

· Протокол следующего уровня - AH или ESP

· Контрольная сумма пакета - вычисляется

· Адрес источника и назначения - каждый SA определяет адрес назначения, от которого будет зависеть интерфейс отправки, то есть адрес источника.

Внутренний заголовок - для него все поля, кроме следующих, остаются неизменными:

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

· Контрольная сумма пакета - должна быть пересчитана, так как изменилось время жизни.

Обработка входящего IP трафика

Входящим считается трафик, который поступает с незащищенного интерфейса на защищенный. Понятия защищенный и незащищённый интерфейс пояснены в разделе «Обработка исходящего IP трафика». Обработка входящего трафика отличается от обработки исходящего. Для входящего трафика, который защищен с помощью IPsec, выполняется поиск соответствующего SA по индексу параметров безопасности (SPI). Для трафика, который принимается без обработки или отбрасывается, используется кэш SPD-I. Если входящий пакет является фрагментированным IPsec пакетом, то он должен быть собран прежде, чем подвергнется IPsec обработке. Входящий пакет должен быть отброшен, если для него не найден SA, в случае IPsec пакета или не найдена соответствующая запись в SPD-I кэше или в самой SPD, в случае незащищённого пакета. Рекомендуется добавлять в SPD последнюю запись, которая соответствует всем пакетам и предписывает их отбросить.

Обработка входящего пакета включает следующие шаги:

1. Фрагментированные пакеты должны быть собраны в дейтаграмму. За это отвечает IP часть стека протоколов.

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

3. Трафик разделяется на две категории:

a. Защищенный IPsec трафик, адресованный данной системе, чьи пакеты имеют в поле протокола следующего уровня значения AH или ESP, предполагает поиск соответствующего SA в SAD

b. Незащищённый трафик, адресованный данной системе, а так же любой трафик неадресованный данной системе, должен быть обработан в соответствии с найденной записью в SPD-I, то есть, пропущен или отброшен.

4. Если происходит поиск в SAD, то в качестве критерия используется поле SPI пакета (или SPI и номер протокола (AH или ESP)) для юникаст трафика и дополнительно адрес назначения и источника для мультикаст трафика. Если соответствующий элемент SAD не найден, пакет отбрасывается и это событие подлежит аудиту. В журнал аудита попадают дата, время, SPI, адреса источника и назначения, IPsec протокол.

5. Если поиск происходит в кэше SPD-I и элемент не найден, то должна быть просмотрена SPD-I часть БД и создан соответствующий элемент кэша. Далее должно быть выполнено действие определенное найденным элементом - пропустить трафик или отбросить. Если элемент не найден, то трафик должен быть отброшен, а данное событие занесено в журнал аудита.

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

7. Если запись в SAD найдена на шаге 4, то после криптографической обработки пакета, его поля должны быть проверены на соответствие селекторам для входящего трафика, на которые ссылается данный элемент SAD. Если селекторы не соответствуют полям пакета, то пакет должен быть отброшен, а событие подлежит аудиту. В журнал аудита должны попасть дата, время, SPI, IPsec протокол, адрес источника и назначения, другие поля пакета, а так же селекторы из SAD элемента. Так же система должна уведомить через IKE удлинённый узел, что селекторы неверны и поэтому пакет отброшен.

8. После шага 7, пакет передается процедуре маршрутизации, которая должна отправить его на целевой хост в случае туннельного режима. Так же пакет может быть снова отправлен и принят системой (отправлен самой себе), например, если нужна дополнительная IPsec обработка в случае вложенных SA, при этом SPD-O должна разрешать его отправку.

Протоколы AH и ESP

Сами по себе данные протокола просты, так как основную часть по поддержке технологии IPsec берут на себя базы данных IPsec и протокол IKEv2 рассмотренный далее. Оба протокола защищают пакеты с данными, оказывая разный уровень сервиса безопасности. Так AH гарантирует целостность и аутентичность пакета с данными, а так же части внешнего IP заголовка, а ESP, кроме этого может гарантировать конфиденциальность данных, но не обслуживает внешний IP заголовок. Оба протокола функционируют, опираясь на контексты безопасности (SA), которые содержат полный набор параметров, указываемых в полях соответствующего протокола.

Пакет AH содержит следующие служебные поля:

· Тип следующего заголовка - определяет протокол, а, следовательно, и тип пакета, который идет после AH

· Длина содержимого - размер AH заголовка

· Индекс параметров безопасности - позволяет найти SA на противоположной стороне для обработки пакета

· Порядковый номер - монотонно возрастающий номер пакета, позволяет обеспечить защиту от повторов (воспроизведения) пакетов.

· Контрольная сумма - вычисляется с помощью секретного ключа, что позволяет проверить целостность и аутентичность пакета. Объектами вычисления являются данные пакета, служебные поля AH и часть внешнего IP заголовка.

Пакет ESP содержит следующие служебные поля:

· Индекс параметров безопасности - позволяет найти SA на противоположной стороне для обработки пакета

· Порядковый номер - монотонно возрастающий номер пакета, позволяет обеспечить защиту от повторов (воспроизведения) пакетов.

· Данные оригинально пакета (Payload) - в зашифрованном виде

· Добавка (Padding) - пустые данные, которые выравнивают длину пакета или скрывают его истинную длину

· Размер добавки

· Тип следующего заголовка - определяет протокол, а, следовательно, и тип пакета, который идет после ESP

· Контрольная сумма - вычисляется с помощью секретного ключа, что позволяет проверить целостность и аутентичность пакета.



Протокол IKEv2

Технология IPsec обеспечивает конфиденциальность, целостность данных, контроль доступа и аутентичность источника для IP дейтаграмм. Эти сервисы поддерживаются за счет разделяемого состояния между источником и приемником дейтаграммы. Это состояние, помимо прочего, характеризуется криптографическими алгоритмами для предоставления сервисов указанных выше и ключами для этих алгоритмов. Установление разделяемого системами состояния ручным способом является плохомасштабируемым решением. Поэтому требуется технология, которая позволяет системам динамически устанавливать данное состояние - такой технологией является протокол Обмена Ключами через Интернет (версия 2) (Internet Key Exchange version 2 (IKEv2)). Далее по тексту обозначение IKE будет относится к IKEv2, если не оговорено другое. Он пришел на смену IKEv1 и является более простым и безопасным в некоторых моментах. Так же он имеет более четкое описание, что позволяет лучше выполнять предназначение IKE-протоколов - взаимодействие независимо реализованных систем. Для этого он представлен в форме стандарта

IKE выполняет взаимную аутентификацию между системами и устанавливает Контекст Безопасности IKE сессии (IKE Security Association (IKE SA)), который включает разделяемую системами секретную информацию, на основе которой устанавливаются контексты безопасности AH и ESP. Они носят название Дочерние Контексты Безопасности (Child SA), так как создаются на основе IKE SA - их «родителя». Данные клиентов IPsec уже передаются по Child SA. И IKE SA и Child SA определяют набор криптографических алгоритмов (иначе называемый криптографический набор), при этом инициатор предлагает на выбор различные поддерживаемые им алгоритмы, а в результате согласования из них формируется набор, в котором каждой криптографической операции соответствует один алгоритм и который поддерживается обеими сторонами.

Все IKE взаимодействия состоят из парных сообщений типа запрос-ответ. Каждая такая пара называется «обмен». Первые два обмена сообщениями устанавливают IKE SA. Эти обмены носят название «инициализация IKE контекста безопасности» (IKE_SA_INIT) и «IKE аутентификация» (IKE_AUTH). Дальнейшие обмены являются либо «созданием дочерних контекстов безопасности» (CREATE_CHILD_SA), либо «информационными обменами» (INFORMATIONAL). В общем случае происходит один обмен IKE_SA_INIT и одни обмен IKE_AUTH (итого четыре сообщения), результатом которых является установленный IKE SA и первый созданный Child SA. Однако существуют случаи, когда нужно совершить больше обменов. Но всегда действует правило: все IKE_SA_INIT обмены должны быть завершены, перед тем как будет возможен любой другой обмен, далее, все IKE_AUTH обмены должны быть завершены, перед тем как будет возможен любой другой обмен, далее обмены CREATE_CHILD_SA и INFORMATIONAL могут осуществляться в произвольном порядке. В некоторых сценариях достаточно только одного Child SA, так что никаких дополнительных обменов не нужно. Последующие обмены могут создавать дополнительные Child SA между аутентифицированными системами.

IKE предполагает строгий порядок сообщений - сначала запрос, потом ответ, нельзя посылать новый запрос, пока не пришел ответ на старый. За этим следит сторона инициатор запроса. Если в течение определенного таймаута ответ не получен, то инициатор запроса должен повторить его или разорвать соединение. Первый обмен IKE сессии, IKE_SA_INIT, согласует параметры безопасности для IKE SA, случайные номера (nonces) и значения алгоритма Диффи-Хеллмана. Второй обмен, IKE_AUTH, передает идентификаторы сторона, доказательства знания секрета, который подтверждает идентификацию и устанавливает первый, а чаще всего единственный, Child SA для AH или ESP. Если при установлении Child SA произошла ошибка, то IKE SA всё еще установлен, но без дочерних контекстов. Далее идут обмены CREATE_CHILD_SA, которые создают дополнительные дочерние контексты и INFORMATIONAL, которые удаляют контексты, сигнализируют об ошибках и выполняют, проверяют активно ли соединение (keepalive) и выполняют другие функции по его обслуживанию. Далее обмены рассмотрены более подробно.

Начальные обмены

Как было сказано ранее, первый обмен (IKE_SA_INIT) согласует криптографические алгоритмы, так же стороны посылают друг другу случайные числа и значения алгоритма Диффи-Хеллмана. Второй обмен (IKE_AUTH) аутентифицирует предыдущие сообщения, передает идентификаторы и сертификаты сторон и устанавливает первый дочерний кнотекст для передачи данных. Сообщения второго обмена зашифрованы и обеспечены защитой целостности на основе ключей, которые получены в первом обмене, таким образом, идентификаторы сторон скрыты, а сообщения аутентифицированы. Однако атакующий («человек посередине»), выдав себя за противоположенную сторону, может увидеть идентификатор инициатора, но так как атакующий не может корректно завершить аутентификацию (IKE_AUTH), то на этом всё и закончится. Все сообщения, идущие далее, защищены криптографическими алгоритмами и ключами, согласованными в обмене IKE_SA_INIT. Так, обмены CREATE_CHILD_SA, IKE_AUTH и INFORMATIONAL используют сообщения, состоящие из фиксированного заголовка и тела, причем тело зашифровано, а вместе они (заголовок и тело) защищены контролем целостности. Для каждого IKE сообщения заголовок содержит идентификатор самого сообщения (Message ID), который позволяет определять соответствие ответа запросу, а так же идентифицирует повторные посылки сообщения.

Сообщение обмена IKE_SA_INIT, посылаемое инициатором имеет вид (HDR, SAi1, KEi, Ni). IKE SA HDR - это заголовок, который содержит индексы параметров безопасности, по которым идентифицируются IKE SA, номер версии протокола IKE, тип обмена, идентификатор самого сообщения и различные флаги. Поле SAi1 - это перечисление криптографических алгоритмов, которые поддерживает инициатор для IKE SA и которые он предлагает на выбор ответчику. Поле KEi содержит значение Диффи-Хеллмана инициатора, а Ni - случайное значение, участвующее в генерации ключей. Ответчик посылает инициатору сообщение (HDR, SAr1, KEr, Nr). В SAr1 ответчик выбрал конкретные алгоритмы из предложенных инициатором. Поле KEr содержит значение Диффи-Хеллмана ответчика, а Nr - случайное значение, участвующее в генерации ключей. После этого обмена каждая сторона может выработать ключи для IKE SA, которые будут участвовать в защите следующих сообщений. Для каждого направления обмена вырабатываются по два ключа: SK_e - для шифрования и SK_a - для проверки целостности и аутентичности. Так же вырабатывается величина SK_d, из которой потом будут выведены ключи дочерних SA.

Далее следует обмен, который включает взаимную идентификацию и аутентификацию сторон. Инициатор посылает следующую последовательность (HDR, SK {IDi, [CERT,], [CERTREQ,], [IDr,], AUTH, SAi2, TSi, TSr}). В IDi передается идентификатор инициатора, который однозначно представляет его в данной информционной системе и признан всеми остальными участниками. Поле AUTH содержит данные, которые доказывают, что инициатор знает секрет, сопоставленный его идентификатору. Конкретные данные зависят от способа аутентификации. Поле CERT содержит сертификаты, которые позволяют проверить данные AUTH, если выбран соответствующий способ аутентификации. Они передаются только, если ответчик их запросил в предыдущем сообщении. Передаваться может цепочка сертификатов, но именно первый должен содержать ключ для проверки AUTH. Так же инициатор может запросить (CERTREQ), чтобы ответчик передал свои сертификаты в следующем сообщении. В опциональном поле IDr инициатор может указать, кого именно он ожидает услышать в качестве ответчика. Это актуально, если на компьютере (хосте) работают несколько ответчиков, например, когда он поддерживает несколько разных VPN. Ответчик может попытаться использовать идентификатор не из множества IDr, но инициатор в таком случае может разорвать соединение. В TSi и TSr передаются селекторы трафика, который инициатор желает передавать ответчику и принимать от него. В SAi2 содержится список криптографических алгоритмов, которые инициатор предлагает на выбор ответчику и параметры IPsec: протокол, режим. Поля TSi, TSr и SAi2 относятся к созданию дочернего SA (Child SA), то есть SA, через который уже будут передаваться данные под защитой AH или ESP. Обозначение SK{…}, говорит, что его содержимое зашифровано на ключе SK_e, а целостность обеспечена на ключе SK_a, которые выработаны в результате предыдущего обмена. После сообщения инициатора следует аналогичное сообщение от ответчика (HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}). Ответчик так же идентифицирует себя (IDr), проходит аутентификацию, попутно защищая целостность сообщения (AUTH), опционально предоставляет необходимые сертификаты (CERT) и согласует дочерний контекст передачи данных (SAr2, TSi, TSr). После того как стороны проверили аутентичность друг друга, контекст IKE SA считается созданным, при этом, если дочерний контекст не удалось согласовать, то IKE SA всё равно остается активным, просто в нем нет ни одного дочернего контекста, но они могут быть созданы обменами CREATE_CHILD_SA. Любые сообщения об ошибках, присылаемых стороной, чья аутентификация не произведена (не завершена), нужно обрабатывать с осторожностью, ведь даже если она (сторона) располагает ключами SK_e и SK_a, которые позволяют проверить целостность сообщения, не понятно кто их использует.

Обмены по созданию дочерних контекстов

Обмен CREATE_CHILD_SA служит для создания дочерних контекстов (Child SAs) и для обновления ключей (rekey) любых контекстов: IKE SA или дочерних. Обмен состоит из одной пары сообщений запрос-ответ. Обновление ключей для SA включает создание нового SA, переключение на него трафика и удаление старого. Обмен CREATE_CHILD_SA может инициировать любая сторона. Поэтому инициатором может быть не обязательно тот узел, который запросил создание IKE SA. Создание нового контекста может опционально включать обмен новыми значениями Диффи-Хеллмана, чтобы повысить уровень безопасности. Ключевой материал для дочернего SA включает значение SK_d, которое было получено во время начальных обменов IKE SA, случайные величины, обмен которыми производится во время создания дочернего SA и значения Диффи-Хеллмана, если сторонами принято решение обмениваться им. Отвечающая сторона может отвергнуть создания нового SA или процедуру обновления ключей для существующего SA, например, если она имеет простую реализацию и предполагает наличие лишь одного дочернего SA в контексте IKE.

Для создания нового дочернего SA инициатор посылает (HDR, SK {SA, Ni, [KEi,], TSi, TSr}). Как и ранее, поле SA содержит предложение по криптографическим алгоритмам, протоколу IPsec, режиму, поле Ni предоставляет случайную величину для генерации ключей, поля TSi, TSr согласуют селекторы трафика, который будет передаваться между узлами, опциональное поле KEi предоставляет значения Диффи-Хеллмана, которые участвуют в генерации ключей для дочернего SA (чем чаще меняются эти значения, тем меньше вероятность, что злоумышленник подберет ключи, накопив достаточное количество зашифрованного материала). Сообщение зашифровано и его целостность обеспечина с помощью ключей согласованных на этапе создания IKE SA. Ответчик отправляет (HDR, SK {SA, Nr, [KEr,], TSi, TSr}). Тем самым он производит согласование алгоритмов в SA, согласование трафика, отправляет свое случайное число и, если необходимо, значение Диффи-Хеллмана. Если в процессе создания дочерних контекстов произошла ошибка и создание завершилось неудачно, то стороны не должны разрывать сам IKE SA.

В случае обновления ключей (rekeying) для IKE SA, инициатор посылает (HDR, SK {SA, Ni, KEi}). В данном случае значение Диффи-Хеллмана обязательно, так как оно является основным для выработки новых ключей. Поле SA содержит новый SPI инициатора. Во время процедуры обновления ключей ни одна из сторон не должна инициировать создание дочерних SA. Ответчик отправляет (HDR, SK {SA, Nr, KEr}). Это сообщение завершает согласование, а поле SA содержит новый SPI ответчика. В результате, обменявшись значениями Диффи-Хеллмана и случайными величинами, стороны могут выработать новые ключи для шифрования и проверки целостности последующих сообщений IKE.



Глава 3. Построение современной корпоративной VPN на базе протокола IPsec

IPsec еще не VPN

сетевой виртуальный информация безопасность

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

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

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

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

· IPsec описывает концепции и намеренно не касается реализации концепции. Конкретный производитель может сделать минимум из требований IPsec, а может сделать максимум, что позволит сделать сеть более масштабируемой и удобной. Кроме того производитель может привнести дополнительные функции, например, горячее резервирование шлюзов безопасности, что может оказаться крайне важным для практической VPN и неважным для концепции IPsec.

· Так же IPsec ничего не говорит об управлении сетью, а большая сеть должна иметь удобные механизмы администрирования, иначе её поддержка окажется очень трудоемкой задачей. Данный вопрос так же отдан на откуп производителей, реализующих IPsec.

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

Этапы

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

· Создание структуры VPN сети - определения кто и с кем должен быть связан

· Выбор поставщика VPN продукта

· Создание физической топологии сети

· Распределение секретов для аутентификации пользователей

· Администрирование VPN сети



Политика безопасности

Самым первым этапом внедрения любого средства защиты информации, будь то VPN или какое-либо еще, является определение политики безопасности предприятия. Именно она дает ответ на главный вопрос: «что нужно защищать?». Этот вопрос связывает информационную безопасность и реальные потребности организации. Так как то, что подлежит защите (объекты защиты) имеет материальную или иную ценность. Определить, что нужно защищать, то есть выделить те самые объекты защиты можно основываясь на законодательстве той или иной страны, например, «Закон о персональных данных» в России или специальном статусе информации, например «Государственная тайна» или на основе проведенной оценки рисков, которая покажет, какие будут потери, например, финансовые или репутационные, в случае несанкционированного доступа к объекту защиты. Вторым важным аспектом политики безопасности является определение легитимных пользователей, которые могут взаимодействовать с объектом защиты. Таким образом, определяется круг субъектов, которые имеют право доступа к объекту защиты. Причем у каждого субъекта может быть свой ограниченный набор прав доступа. Логично, что пользователям, не относящимся к группе легитимных, любой доступ к объекту защиты должен быть закрыт. Так же легитимные пользователи не должны превышать свои права при взаимодействии с объектом защиты. Политика безопасности предполагает ответственность субъектов за нарушение правил доступа.

Когда зафиксированы объекты защиты и взаимодействующие с ними субъекты, можно приступать формированию плана реализации политики безопасности. В нем нужно определить модель угроз, то есть описать, от чего конкретно нужно защищать объект: какие виды угроз возможны, насколько серьезна каждая из них (к каким последствиям приведёт реализация угрозы), насколько легко реализуема, что (или кто) является источником угрозы. Для определения источников угрозы полезно составить модель нарушителя, где все субъекты разделены на группы согласно их правам доступа. Для начала можно выделить две простейшие группы, легитимные пользователи - имеют доступ, нелегитимные пользователи - не должны иметь никакого доступа. Модель угроз определяет, какие средства защиты должны быть использованы. Каждое из них направлено на уменьшение вероятности реализации угрозы и/или на снижение последствий удачной реализации. Чем более качественно составлена модель угроз и чем более качественные средства защиты выбраны, тем, как правило, лучше реализуется политика безопасности. Средствами защиты могут быть аппаратными, программными, административными или управленческими решениями, а так же их объединением.

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

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

· Нарушение целостности: возможность исказить информацию при передаче от узла к узлу (от клиента к серверу, между серверами или между узлами), или послать информацию от лица другого узла.

· Нарушение конфиденциальности: возможность прочитать перехваченную информацию при передаче её от узла к узлу.

· Нарушение доступности: возможность получить доступ к ресурсу, расположенному на узле сети, не обладая соответствующими правами.

Технология IPsec предполагает защиту от всех перечисленных нарушений, поэтому VPN на её основе можно рассматривать в качестве средства защиты согласно модели угроз. А так как политика безопасности определят, какие серверы содержащие ресурсы какие клиентские устройства должны быть защищены, то из этого можно сделать вывод:

· На какие узлы установить VPN модули

· Как физически организовать сеть - где разместить шлюзы безопасности

· Как настроить VPN на узлах - какой узел с каким должен соединяться и какой уровень IPsec защиты требуется соединению.

Все это вместе, как раз и определяет структуру VPN сети предприятия.

Выбор поставщика VPN

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

· Наличие сертификатов регуляторов. Данный критерий иногда является безапелляционным и требуется политикой безопасности предприятия. Регуляторами в России являются ФСБ и ФСТЭК, при этом ФСБ больше рассматривает криптографическую составляющую, а ФСТЭК продукт в целом. Каждый из этих органов предъявляет набор требований, которым должен удовлетворять конечный продукт. Этот набор требований является показателем качества продукта в области защиты информации. Поэтому на него можно ориентироваться при выборе. Обычно VPN сертифицируется по классу СКЗИ (средства криптографической защиты информации), который требует применение национальных стандартов криптографии (шифрования, ЭЦП и так далее), в России, это стандарты семейства ГОСТ. Так как IPsec не зависит от конкретных криптографических алгоритмов, то производитель сам решает, какие из них будут использованы в его продукте. Как указано выше, для прохождения сертификации, он должен реализовать набор алгоритмов ГОСТ и, так как инициатор IPsec согласует алгоритмы с удаленным узлом, тот тоже должен поддерживать алгоритмы ГОСТ. Кроме того VPN на основе IPsec может быть сертифицирован по классу МЭ (межсетевые экраны), так как технология IPsec предполагает, что на узле будет работать пакетный фильтр который может пропустить трафик (без обработки IPsec или с обработкой IPsec) или заблокировать его. Однако регламент ФСТЭ вышедший в этом году вносит новые требования к МЭ, поэтому функционала пакетной фильтрации IPsec может оказаться недостаточно.

· Полнота реализации стандарта IPsec. Хотя даже при минимальной (то, что в стандарте отмечено, как «необходимо») реализации стандарта взаимодействие систем возможно, однако много его аспектов приводятся в виде рекомендаций и решений, отданных на откуп производителю. Некоторые из них влияют на конечную защищённость системы, некоторые на удобство управления, производительность, масштабируемость, так что им должно быть уделено внимание в продукте. Кроме того, нужно ориентироваться на реализации последних версий стандартов, например на IKEv2, а не на IKEv1.

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

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

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

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

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

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



Физическая организация сети

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

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

· Соединение офиса и одиночного узла через Интернет. Рассмотрим два варианта для этого случая:

o Соединение офиса с удаленным дата-центром или виртуальным выделенным сервером (VPS). Нужно учитывать, что последние будут установлены в сети соответствующего сервис-провайдера. И эта сеть не является доверенной. Одиночный узел можно защитить шлюзом безопасности, включенным в сеть провайдера, если последний разрешает выполнение такой операции. При этом шлюз безопасности будет защищать всего один узел, что может показаться расточительным, однако, в этом варианте данный узел является высоконагруженным по трафику и передача функций защиты отдельному устройству - шлюзу безопасности поможет избежать проблем с ограничением скорости доступа. Далее на пограничном шлюзе безопасности офиса и на шлюзе безопасности, установленном в сети провайдера, создается IPsec туннель, аналогично случаю рассмотренному выше и организуется защита трафика от узлов офиса к удаленному узлу и обратно. Если сервис-провайдер не позволяет устанавливать дополнительные устройства, то IPsec туннель должен поддерживаться путем установки программного обеспечения на удаленный узел.

o Соединения офиса и мобильного пользователя. Здесь предполагается организация доступа к корпоративным ресурсам через Интернет из дома, гостиницы, аэропорта и так далее с помощью мобильных устройств, смартфонов, планшетов, ноутбуков. Обычно сначала эти устройства включаются в сети местных провайдеров услуг связи. Эти сети, так же как и Интернет не являются доверенными и требуют защиты трафика. В данном варианте установка защищенного шлюза для мобильного пользователя не является удачным решением, так как он должен будет возить его с собой и кроме того производительность шлюза будет излишней для защиты одного клиентского узла. Нужно отметить, однако, что существуют компактные носимые шлюзы безопасности с невысокой производительностью специально для таких случаев. Более удобным решением будет установка программного обеспечения на мобильное устройство, которое дает возможность создавать IPsec туннель со шлюзом безопасности офиса и передавать через него защищенный трафик. Еще одним сценарием, который используется организациям, является перенаправление (отправка) всего трафика, мобильного устройства на сервер внутри офиса. Сервер может фильтровать, сканировать трафик антивирусом или выполнять с ним другие действия и выступать посредником между мобильным устройством и ресурсами, к которым оно обращается. Это связано с тем, что нет доверия к сети местного провайдера, поэтому даже при условии, что он предоставляет доступ в Интернет, доступ к Web-сайтам лучше осуществлять через сервер компании.

Нужно учитывать, что в данном случае шлюз безопасности или мобильное устройство расположены не на границе сети провайдера, а непосредственно в ней. Поэтому на выходе в Интернет скорее всего будет расположено натирующее устройство, которое производит подмену адресов и портов для отображения всей локальной сети провайдера на один или группу Интернет адресов. Так как протоколы безопасности IPsec, а именно, AH и ESP не являются натируемыми, потому что не содержат такого понятия как порт и в случае AH могут запрещать подмену адресов, то нужно использовать технологию NAT Traversal, которая упаковывает IPsec пакет в пакет протокола UDP, который уже может проходить через натирующие устройства.

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

· Демилитаризованные зоны (DMZ). К ним, как правило, осуществляется доступ извне компании, причем часто лицами, не являющимися сотрудниками компании. Поэтому содержать защищенные и общедоступные ресурсы на одних DMZ серверах крайне не рекомендуется. Если такое всё-таки происходит, то тут уже необходима поддержка безопасности со стороны самих ресурсов.

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

Распределение секретов для доступа к VPN сети

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

После того как узлы VPN установлены и настроены, необходимо распределить секреты между узлами (или пользователями, далее не будет выделяться различие), чтобы могла происходить их аутентификация. Взаимная идентификация и аутентификация сторон напрямую выполняются IPsec (протоколом IKE) при установлении безопасного соединения. При этом в качестве метода аутентификации используется либо предварительно распределенный секретный ключ, либо сертификаты. В первом варианте - предварительно распределенный секретный ключ, он и является секретом, на основе знания которого проверяется принадлежность идентификатора пользователю. Ключ должен быть одинаковый на обеих сторонах взаимодействия. Первичное распространение наборов таких ключей при инициализации сети обычно вызывает проблемы, особенно в крупных организациях. Сам набор ключей представляет из себя список ключей для связи между двумя узлами, таким образом, если у узла есть связь с десятью другими узлами, то для достижения безопасности при компрометации одного из ключей, у него должно быть десять разных ключей для связи с каждым из узлов. Набор, как правило, шифруется на ключе, получаемом из пароля пользователя. Передача пользователю данного пароля должна производиться с соблюдением правил безопасности, например, может выдаваться под роспись специальный конверт, который нельзя незаметно вскрыть или просветить. В общем случае администратор безопасности или любое другое лицо, кроме пользователя не должны знать этот пароль. Далее необходимо проследить, чтобы ключевой набор попал на нужный узел и пользователь успешно получил доступ к нему с помощью своего пароля. Последующее добавление ключей для связи с новыми узлами уже можно будет производить дистанционно из точки управления VPN сетью, так как они уже будут переданы по безопасному каналу, который как раз и обеспечивается VPN. Данный процесс первичной инициализации трудно автоматизировать, так как в отсутствии защищённой сети, часто нет надежного канала для передачи пароля и набора ключей. Вторым вариантом аутентификации является использование технологии открытых ключей (PKI). Она предполагает наличие у пользователя закрытого ключа, который как раз и является секретом аутентификации и сертификата с открытым кличем соответствующим закрытому. Закрытый ключ пользователь хранит втайне, чаще всего он записывается в неизвлекаемом виде на устройство: токен или смарт-карту и доступ к нему дополнительно ПИН-кодом устройства. Сертификат с открытым ключом передается пользователям, с которыми идет взаимодействие для возможности проверки принадлежности закрытого ключа. Важным моментом является то, что сертификат должен быть заверен удостоверяющим центром, которому доверяют все участники взаимодействия. Удостоверяющий центр гарантирует явно, что открытый ключ принадлежит именно владельцу данного сертификата (имени, которое указано в сертификате) и неявно, что владельцу так же принадлежит закрытый ключ, криптографически связанный с открытым. При использовании сертификатов для аутентификации IPsec позволяет указывать в качестве идентификатора пользователя его имя в сертификате, а так же при создании контекстов безопасности (в протоколе IKE) дает возможность передать или запросить необходимые сертификаты. Кроме того IPsec рекомендует ограничивать время жизни безопасного соединения сроком действия сертификата, использованного для его установления или сроком обновления списка отозванных сертификатов. Технология PKI может применяться в организации для идентификации и аутентификации пользователей в любых информационных системах, а не только в VPN. Она позволяет аннулировать права пользователя через список отозванных сертификатов или через сервис онлайн проверки статуса сертификата. Так же она привносит концепцию единой точки доверия - удостоверяющий центр, что положительно сказывается на уровне безопасности. Кроме того она основана на ассиметричной криптографии, что позволяет пользователю никому не передавать свой закрытый (секретный ключ), а лишь доказывать с помощью сертификата заверенного удостоверяющим центром, что этот ключ принадлежит ему и есть у него в наличии. Важным требованием технологии PKI является передача на устройство пользователя корневого (самоподписанного) сертификата удостоверяющего центра доверенным способом. В этом вопросе можно положиться на сеть VPN, но к этому моменту она должна уже быть инициализирована каким-либо секретом.

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