Авторизация пользователей в VPN сетях

Клиент и сервер имеют секретный ключ. От этого секретного ключа, сложенного с идентификатором запроса берется MD5 хэш, который XOR'ится с паролем, введенным пользователем. Если пароль пользователя больше чем два байта, дополнительно вычисляется MD5 хэш, используя уже полученный шифр вместо идентификатора запроса.

Например:

Пусть секретный ключ S, а сгенерированный идентификатор запроса RA. Пароль разбивается на двухбайтные блоки p1, p2 … pn. Зашифрованные блоки c1, c2,..,cn.

c1 = p1 XOR MD5(S + RA)

c2 = p2 XOR MD5(S + c1)

cn = pn XOR MD5(S + cn-1)

Тогда значение атрибута «User-Password» будет c1+c2+...+cn, где + означает конкатенацию.

Процесс авторизации. Сторона сервера. Получив, Access-Request пакет, сервер RADUIS'а проверяет, имеет ли он секретный ключ для клиента, приславшего запрос. Если ключа нет. То сервер игнорирует такой пакет. Так как сервер обладает секретным ключом, он, выполнив действия, аналогичные описанным выше, проверяет, верный ли был прислан пароль. Если пароль верный, сервер создает Access-Accept пакет, иначе Access-Reject пакет. Оба пакета используют тот же идентификатор, что был использован в клиентском Access-Request пакета.

Аутентификатор пакета - это MD5 хэш пакета-ответа, аутентификатора Request пакета, и секретный ключ. То есть ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) где + означает конкатенацию.

Процесс авторизации. Сторона клиента, окончание. Когда клиент получает пакет с ответом сервера, он ищет соответствующий запрос по полю-идентификатору. Если запрос не найден, то пришедший ответ сервера обрабатываться не будет. Далее проверяется аутентификатор ответа, и при его несовпадении, пришедший пакет также не будет обрабатываться. И наконец, в соответствии с типом пришедшего ответа(Access-Accept или Access-Reject), клиент получает доступ к ресурсам.

3.4 Протокол DIAMETER

3.4.1Общая информация о протоколе

Протокол Diameter берет свое начало из протокола RADIUS (значительно улучшая его различные аспекты) и предлагается, в основном, для использования в качестве протокола следующего поколения для аутентификации, авторизации и учета (Authentication, Authorization, Accounting - AAA). Протокол Diameter широко использовался в IMS-архитектуре для обмена AAA-информацией между IMS-объектами. [4]

С появлением новых технологий и приложений, таких как, VPN, беспроводные сети (Wi-fi) и Mobile IP, требования к аутентификации и авторизации значительно повысились, а механизмы контроля доступа стали более сложными, чем когда-либо. Существующего протокола RADIUS (Remote Authentication Dial-In User Service) может быть недостаточно для удовлетворения этих новых требований; необходим новый протокол, обладающий новыми возможностями контроля доступа, сохраняющий в то же время гибкость для последующих расширений. Вот здесь и может понадобиться протокол Diameter. Протокол Diameter не является совершенно новым протоколом для AAA, а, как следует из его имени, является расширенной версией протокола RADIUS. Он включает многочисленные улучшения всех аспектов, например, обработки ошибок и надежности доставки сообщений. Он извлекает суть AAA-протокола из RADIUS и определяет набор сообщений, являющихся достаточно общими, для того чтобы служить ядром базового протокола Diameter. Различные приложения, нуждающиеся в AAA-функциях, могут определять свои собственные расширения на основе базового протокола Diameter. На рисунке 3.4 изображена взаимосвязь между базовым протоколом Diameter и различными Diameter-приложениями.

Рисунок 3.4 - взаимосвязь между базовым протоколом Diameter и различными Diameter-приложениями

3.4.2 Узлы и агенты протокола Diameter

Diameter имеет одноранговую архитектуру (Peer-To-Peer), и каждый хост, реализующий протокол Diameter, может выступать либо клиентом, либо сервером, в зависимости от сетевой инфраструктуры. Поэтому термин «Diameter-узел» используется для ссылки на Diameter-клиент, на Diameter-сервер или на Diameter-агент, с которым мы познакомимся позже. Узел протокола Diameter, принимающий пользовательский запрос на соединение, выступает как Diameter-клиент. В большинстве случаев Diameter-клиентом будет Network Access Server. После сбора информации, удостоверяющей пользователя, такой как имя пользователя и пароль, он передаст сообщение запроса на доступ одному Diameter-узлу, обслуживающему запрос. Для простоты мы предполагаем, что это Diameter-сервер. Diameter-сервер выполняет аутентификацию пользователя на основе предоставленной информации. Если процесс аутентификации выполняется успешно, в ответное сообщение включаются полномочия пользователя (процесс авторизации), и это сообщение передается обратно соответствующему Diameter-клиенту. В противном случае передается сообщение об отказе. [4]

Узел выступающий в роли Diameter-сервера, для некоторых запросов может, на самом деле, в некоторых ситуациях выступать как Diameter-клиент; протокол Diameter является, в действительности, одноранговым протоколом в более широком смысле. Кроме того, в протоколе четко определен специальный Diameter-узел, называемый «Diameter-агентом». Обычно существует три типа Diameter-агентов:

1) Relay Agent (агент-ретранслятор)

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

2) Proxy Agent (прокси-агент)

Proxy Agent может также использоваться для перенаправления сообщений, но, в отличие от Relay Agent, Proxy Agent может изменить содержимое сообщения и, следовательно, предоставлять дополнительные службы, применять правила для различных сообщений или выполнять задачи администрирования для различных областей. На рисунке 3.5 показано, как используется Proxy Agent для перенаправления сообщения в другой домен. Если Proxy Agent не изменяет содержимое оригинального запроса, в этом сценарии достаточно было бы использования Relay Agent.

Рисунок 3.5 - Diameter Proxy Agent

3) Redirect Agent (агент перенаправления)

Redirect Agent выступает в роли централизованного репозитория конфигураций для других Diameter-узлов. Принимая сообщение, он проверяет свою таблицу маршрутизации и возвращает ответное сообщение вместе с информацией о перенаправлении оригинальному отправителю сообщения. Это могло бы быть очень полезно для других Diameter-узлов, поскольку им не нужно хранить список записей о маршрутизации локально, и они могли бы, при необходимости, искать Redirect Agent. На рисунке 3.6 изображена работа Redirect Agent. Сценарий, показанный на рисунке 3.6, в основном идентичен сценарию, показанному на рисунке 3.5 , но в этот раз Proxy Agent не знает адреса связанного Diameter-узла в example.com. Следовательно, он ищет информацию в Redirect Agent своей собственной области для получения адреса.

Рисунок 3.6 - Diameter Redirect Agent

Translation Agent (агент преобразования)

Кроме этих агентов существует специальный агент, называемый Translation Agent. Обязанностью этого агента, является преобразование сообщения из одного AAA-протокола в другой. Translation Agent полезен для компании, или провайдера служб для интеграции пользовательской базы данных двух прикладных доменов, сохраняя их оригинальные AAA-протоколы. Другая ситуация: компания хочет выполнить миграцию на протокол Diameter, но этот процесс состоит из нескольких фаз. Translation Agent мог бы обеспечить обратную совместимость для плавной миграции. На рисунке 3.7 показано, как один агент преобразовывает протокол RADIUS в протокол Diameter, но, естественно, возможны также и другие типы преобразования протоколов (например, Diameter в RADIUS, Diameter в TACACS+). [10]



Рисунок 3.7 - Diameter Translation Agent

3.4.3 Diameter-сообщения

Diameter-сообщение - это элементарный модуль для передачи команды или доставки уведомления другим Diameter-узлам. Для различных целей протокол Diameter имеет различные типы Diameter-сообщений, которые определяются их кодом команды. Например, сообщение Accounting-Request распознает, что сообщение содержит информацию об учетной записи, а сообщение Capability-Exchange-Request распознает, что сообщение содержит информацию о возможностях Diameter-узла, передающего сообщение.

Поскольку тип обмена сообщениями в Diameter является синхронным, каждое сообщение имеет своего соответствующего двойника, который использует такой же код команды. Приемник сообщения Accounting-Request подготавливает сообщение Account-Answer и передает его оригинальному отправителю.

Код команды используется для идентификации намерения сообщения, но реальные данные передаются в виде набора пар атрибут-значение (Attribute-Value-Pair - AVP). Протокол Diameter имеет предопределенный набор общих атрибутов и назначает каждому атрибуту соответствующую семантику. Эти AVP передают подробности AAA (такую информацию как маршрутизация, безопасность и возможности) между двумя Diameter-узлами. Кроме того, каждая пара AVP ассоциируется с форматом AVP Data Format, который определен в протоколе Diameter (например, OctetString, Integer32), поэтому значение каждого атрибута должно следовать формату данных.

На рисунке 3.8 изображена взаимосвязь между Diameter-сообщениями и их AVP.



Рисунок 3.8 - Diameter Packet Format

3.4.4 Обнаружение однорангового узла

До появления Diameter системные администраторы должны были вручную настраивать в Network Access Server месторасположение его AAA-сервера, для того чтобы при входе пользователя устройство могло передать запрос по корректному адресу. Однако такая конфигурация могла быть трудоемкой для сложных конфигураций сети. Одним из улучшений в Diameter является его возможность искать одноранговые узлы. Кроме ручной настройки, которая должны поддерживаться всеми Diameter-узлами, для динамического обнаружения однорангового узла могут поддерживаться два параметра - SRVLOC и DNS. В основе этого лежит концепция, что для Diameter-сервер (или Diameter-агент) необходимо сообщать, какие приложения они поддерживают, а также обеспечиваемый уровень безопасности.

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

1) Peer Table. Peer Table - используется, главным образом, вручную для хранения адреса хоста известных Diameter-узлов. В эту таблицу включена и другая информация об этом узле, например, может ли Diameter-узел обнаруживаться динамически, а также информация о защите. [5]

2) Peer Routing Table. В этой таблице существует четыре важных столбца, требующих дополнительного внимания для маршрутизации сообщений. Первыми двумя являются Realm Name и Application Name, которые выступают как критерии выбора для маршрутизации сообщений. Третий столбец - это действие, которое нужно выполнить для целевого сообщения, которым может быть PROXY, RELAY, REDIRECT или LOCAL. LOCAL означает, что сообщение должно быть обработано локально вместо перенаправления к другим узлам. Последний столбец - это ссылка на запись в Peer Table, используемая для определения реального адреса хоста адресата. Peer Routing Table будет всегда содержать запись по умолчанию для сообщений, не отвечающих критерию маршрутизации.

3.4.5 Соединение и сессия

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

Исходя из того, что Diameter, в основном, имеет одноранговую архитектуру, для конкретного узла можно было бы установить более одного соединения. Протокол Diameter явно определяет, что Diameter-узел как минимум должен устанавливать соединение с двумя одноранговыми узлами в каждой области, которые выступают как первичные (primary) и вторичные контакты (secondary contact). Естественно, что при необходимости могли бы быть установлены дополнительные соединения. По сравнению с соединением сессия представляет собой логическое соединение между двумя Diameter-узлами и может пересекать несколько физических соединений. Сессия - это, на самом деле, концепция последовательности активностей во временном промежутке; она относится к взаимодействиям между Diameter-клиентом и Diameter-сервером в течение определенного периода времени. Каждая сессия в протоколе Diameter ассоциируется с генерируемым клиентом идентификатором Session-Id, который уникален глобально и постоянно. Session-Id используется затем для идентификации конкретной сессии во время дальнейшего обмена информацией. На рисунке 3.9 показаны концепции соединения и сессии:

Рисунок 3.9 - Сессия и соединение в Diameter

Как и в большинстве моделей взаимодействия клиент-сервер, Diameter-сессия начинается с передачи сообщения запроса от клиента серверу. В контексте Diameter Diameter-клиент передаст сообщение auth-request, содержащее уникальный Session-Id, Diameter-серверу (или Diameter-прокси, если необходимо перенаправление сообщения). Используемые для аутентификации и авторизации пары AVP зависят от приложения, они не определены в базовом протоколе. [9]

После приема сообщения auth-request Diameter-сервер может включить Authorization-Lifetime AVP в ответное сообщение. Эта пара AVP используется для указания количества времени в секундах, которое требуется Diameter-клиенту для повторной авторизации. После истечения лимита времени и допустимого Auth-Grace-Period, Diameter-сервер будет удалять сессию из своего списка сессий и освобождать все ресурсы, выделенные для нее.

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

Кроме того, для догадки об исключительном закрытии сессии используется пара AVP Origin-State-Id. Отправитель запроса будет включать эту AVP, и поскольку необходимо, чтобы это значение монотонно увеличивалось, получатель запроса может легко догадаться о том, что предыдущая сессия была закрыта либо по аварийному завершению работы устройства доступа, либо из-за каких-либо других исключительных ситуаций. Получатель запроса может затем удалить сессию из своего списка, освободить ресурсы и, возможно, уведомить свои Diameter-серверы, если он работает как прокси-сервер.

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

Сообщение о завершении сессии может быть инициировано либо Diameter-клиентом, либо Diameter-сервером. Когда Diamete-клиент полагает, что нужно закрыть сессию, он передает сообщение Session-Termination-Request Diameter-серверу. В этот запрос включается AVP Termination-Clause, указывающая Diameter-серверу причину, почему сессия должна быть закрыта. В свою очередь, если Diameter-сервер обнаруживает, что сессия должна быть закрыта Diameter-сервер передает сообщение Abort-Session-Request Diameter-клиенту. Однако, в зависимости от различной политики или сценариев использования, Diameter-клиент может решить не закрывать сессию, даже при получении сообщения от сервера о ее завершении, и позволить пользователю продолжать пользоваться своим сервисом.

3.4.6 AAA в протоколе DIAMETER

Аутентификация и авторизация. Протокол Diameter не привязан к определенному приложению, его использующему. Он концентрируется на общих функциональных возможностях обмена сообщениями. Поскольку механизмы аутентификации и авторизации в приложениях отличаются, базовый протокол Diameter не определяет коды команд и AVP, специфичные для аутентификации и авторизации. Ответственность за определение своих собственных сообщений и соответствующих атрибутов на основе характеристик приложения возлагается на сами Diameter-приложения. Например, сообщение AA-Request используется для передачи информации об аутентификации и авторизации в NAS-приложение, в то время как в SIP-приложении сообщение называется User-Authorization-Request.

Учет. В отличие от аутентификации и авторизации, поведение и сообщение для учета четко определено. Учет в Diameter, по существу, следует модели управления сервером. Это означает, что устройство, генерирующее учетные записи, следует указаниям сервера авторизации.

На основе пользовательского профиля или какого-либо бизнес-условия Diameter-сервер информирует соответствующего Diameter-клиента об ожидаемом поведении, а также о том, как часто учетная запись должна посылаться от клиента на сервер, или о том, должна ли учетная запись генерироваться во время учетной сессии постоянно. [10]

Для предотвращения дублирования учетных записей каждому сообщению назначается AVP Session-Id вместе с AVP Accounting-Record-Number. Поскольку эта комбинация может уникально идентифицировать учетную запись, Diameter-узел, выступающий в роли Diameter-агента, может использовать эту информацию для обнаружения дублирования учетных сообщений, передаваемых Diameter-серверу, устраняя, таким образом, нежелательную обработку Diameter-сервером. Эта ситуация может возникнуть из-за временных сетевых проблем или останова клиента. Кроме того, Diameter-клиент должен хранить локальный кэш исходящих учетных сообщений до получения подтверждающего сообщения.

3.5 Аппаратные маркеры/PKCS #11

Аппаратные маркеры -- это устойчивые к подделке устройства размером с кредитную карту (и типа смарт-карты), которые пользователь имеет в своем распоряжении. LCD на карте состоит из 6-8 цифр, которые обычно изменяются каждые 60 секунд. При авторизации пользователя LCD обычно комбинируется с PIN. Оба известны только пользователю и вместе они служат как пароль. Для удобства вы можете ограничить пароль только изображением LCD. Если вы решите использовать LCD в качестве пароля, он должен применяться вместе с другим механизмом безопасности, таким как схема шифрования, подобная DES. Программный маркер -- это приложение на машине, которое эмулирует устройство аппаратного маркера.

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

Стандарты шифрования открытого ключа (PKCS, Public-Key Cryptographs Standards), разработанные RSA с консорциумом других организаций, являются множеством стандартов, установленных для криптографии с открытым ключом. PKCS совместимы со стандартами цифровых сертификатов ITU-T Х.509. Стандарт PKCS включает некоторые определенные стандарты алгоритмов, такие как RSA и Diffic-Hcllman. PKCS также определяет независимые стандарты, которые могут использоваться для цифровых подписей, цифровых конвертов и расширенных цифровых сертификатов.

Далее представлены стандарты PKCS:

- #1 Механизмы для шифрования и подписания данных с помощью RSA

- #3 Протокол согласования ключа Diffie-Hellman

- #5 Метод шифрования строки с помощью секретного ключа, полученного из пароля

- #6 В настоящее время свертывается и заменяется версией 3 Х.509

- #7 Общий синтаксис для сообщений и криптографических усовершенствований, таких как цифровые подписи и шифрование

- #8 Формат для информации закрытого ключа

- #9 Выбранные типы атрибутов для использования в других стандартах PKCS

- #10 Синтаксис для запросов сертификации

- #11 Определяет независимый от технологии интерфейс программирования, называемый Cryptoki для криптографических устройств, таких как смарт-карты

- #12 Определяет переносимый формат для хранения или транспортировки закрытых ключей пользователя, сертификатов и т. д.

- #13 Механизмы для шифрования и подписания данных, использующие эллиптическую кривую

- #14. Стандарт для генерирования псевдослучайных чисел

Именно #11 используется в технологии смарт-карт. RSA Data Security разработал PKSC-11, который определяет стандарт интерфейса криптографического маркера (API, называемый Cryptoki) для устройств, которые содержат криптографическую информацию и выполняют криптографические функции. Cryptoki (произносится "крипто-ки") применяет объектный подход, определяя технологическую независимость (любой вид устройства) и совместное использование ресурса (множество приложений, получающих доступ ко множеству устройств) и представляя приложениям общий, логический вид устройства, которое называется криптографическим маркером.

3.6 Биометрия как способ авторизации пользователя

Биометрия, в частности биометрия для вычислительных приложений, используется как форма идентификации. Технология биометрической идентификации является свойством или действием человека с целью уникальной идентификации другого человека. Системы биометрической идентификации включают отпечатки пальцев, рукописную подпись, отпечатки голоса и снимки сетчатки глаза. Биометрия является третьей категорией классификации (что-то, являющееся единичным). Применяя PIN, маркер и биометрическое исследование, корпорация могла бы достичь трехфакторной аутентификации и авторизации. [6]

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

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

В связи с биометрическими устройствами употребляются следующие термины:

- Степень ошибочного признания (FAR, False acceptance rate)

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

- Степень ошибочного отказа (FRR, False reject rate) Степень, с которой действительный пользователь отвергается из системы.

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

1. Захват. Биометрические устройства фиксируют то, что вы пытаетесь использовать -- отпечатки пальцев, изображение сетчатки глаза и т. д.

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

3. Хранение Данные необходимо где-то сохранить для авторизации, отказа и для будущего анализа. Для этого пока не существует стандартов, поэтому вам придется полностью использовать продукт поставщика.

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

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

4. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ ВИРТУАЛЬНОЙ ЧАСТНОЙ СЕТИ НА ОСНОВЕ OPENVPN

4.1 Постановка задачи

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

4.2. Описание технологии реализации пакета OpenVPN

4.2.1 Общие сведения о технологии OpenVPN

OpenVPN - это инструмент с открытым исходным кодом, используемый для построения клиент/сервер VPN и site-to-site VPN сетей с использованием SSL/TLS протокола или с разделяемыми ключами. Он выполняет роль безопасного туннеля для передачи данных через один TCP/UDP порт в небезопасной сети как Интернет. OpenVPN может быть установлен практически на любую платформу включая: Linux, Windows 2000/XP/Vista/7, OpenBSD, FreeBSD, NetBSD, Mac OS X и Solaris.

Linux системы должны работать на ядре 2.4 или выше. Принципы конфигурирования одинаковы для всех платформ. OpenVPN использует клиент/сервер архитектуру. Он должен быть установлен на все узлы VPN сети, где один узел должен быть сервером, а остальные клиентами. OpenVPN создает TCP или UDP туннель, при этом данные проходящие через этот туннель шифруются. Стандартный порт для OpenVPN - UDP 1194, но можно использовать любой другой TCP или UDP порт. С версии 2.0 один и тот же порт можно использовать для нескольких туннелей на OpenVPN сервере. Начиная с версии 2.0, вы можете использовать любой другой TCP или UDP порт. На OpenVPN сервере один и тот же порт может быть использован для нескольких туннелей. При использовании статических ключей, VPN шлюзы используют один и тот же ключ для шифрования и дешифрования данных. В этом случае настройка будет довольно простой, но при этом возникает проблема передачи и безопастноси ключа. Если кто-то завладеет этим ключом, то он может дешифровать данные.

Для того чтобы избежать этой проблемы необходимо использовать Инфраструктуру Открытых Ключей (PKI). При этом каждый узел владеет двумя ключами: открытый ключ, известный всем и закрытый ключ доступный только его владельцу. Такую структуру использует OpenSSL, интегрированный в OpenVPN, для аутентификации VPN узлов перед тем как начать передавать зашифрованные данные. В таблице 7.1 дано сравнение двух режимов OpenVPN.

Таблица 4.1 - сравнение режимов OpenVPN: разделяемые ключи и SSL.

Режим OpenVPN	Разделяемые ключи	SSL
Шифрование:	Симметричное	Aсимметричный/Симметричное
Реализация:	Проще	Сложнее
Скорость:	Быстро	Медленно
Загрузка процессора:	Меньше	Больше
Обмен ключами:	Да	Нет
Обновление ключей:	Нет	Да
Аутентификации узлов:	Нет	Да

4.2.2 Secure Sockets Layers

Secure Sockets Layer (SSL) - криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Было выпущено две версии v2 (1994) и v3 (1995). В 2001 IETF купила и обновила патент. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC 2246, получивший имя TLS.

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

SSL состоит из двух уровней. На нижнем уровне многоуровневого транспортного протокола (например, TCP) он является протоколом записи и используется для инкапсуляции (то есть формирования пакета) различных протоколов (SSL работает совместно с таким протоколами как POP3, IMAP, XMPP, SMTP и HTTP). Для каждого инкапсулированного протокола он обеспечивает условия, при которых сервер и клиент могут подтверждать друг другу свою подлинность, выполнять алгоритмы шифрования и производить обмен криптографическими ключами, прежде чем протокол прикладной программы начнёт передавать и получать данные.

Для доступа к веб-страницам, защищённым протоколом SSL, в URL вместо обычного префикса http, применяется префикс https, указывающий на то, что будет использоваться SSL-соединение. Стандартный TCP-порт для соединения по протоколу https -- 443.

SSL выполняет две основные задачи:

- Аутентификация сервера и клиента по средством Инфраструктуры Открытых Ключей (PKI).

- Создает шифрованное соединение между клиентом и сервером для обмена сообщениями.

Этап работы SSL/TLS:

- SSL Handshake - определяется метод шифрования для передачи данных.

- SSL Change Cipher Spec - создание и передача ключа между клиентом и сервером на эту сессию.

- SSL Alert - доставка сообщений SSL об ошибках между клиентом и сервером.

- SSL Record - передача данных.

4.2.3 Сравнение IPSEC и SSL/TLS

Цель у SSL и IPSec одинакова: шифрование данных между двумя устройствами одним и тем же алгоритмом. Но методы какими решаются эти задачи разные. IPSec и SSL не совместимы. В таблице 7.2 приведено сравнение IPSEC и SSL/TLS.

Таблица 4.2 - сравнение IPSEC и SSL/TLS.

Протокол IPSec - это протокол 3 уровня, а это означает, что для его реализации необходимо изменить IP стек, который расположен в пространстве ядра, для всех IPSec устройств. А это приводит к тому, что каждая операционная система (Cisco, Windows, Nortel, Linux и т.д.) будет иметь свою реализацию IPSec.

OpenVPN ведет себя как стандартное приложение, так как оно реализовано в пространстве пользователя. И это дает ему приимущество в лучшей безопасности и переносимости:

- Безопасность - в связи с тем, что IPSec тесно связанно с ядром, сбой в приложении может привести к сбою в ядре. Такой проблемы с OpenVPN не возникает, так как он полностью реализован в пространстве пользователя. Еще одна проблема с безопасностью может возникнуть в случает программного взлома, с помощью IPSec взломщик может получить доступа к ядру, или другими словами получить права администратора. OpenVPN не имеет такой уязвимости так как запускается под специальным пользователем с ограниченными правами.

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

Наиболее серьезная проблема с которой приходиться сталкивать при использовании IPSec - это необходимость изменения правил фильтрации (firewall), чтобы разрешить протокол и преобразование адресов (NAT). Эта проблеме частично решена использованием протокола NAT-T.

При использовании OpenVPN необходимо открыть TCP или UDP порт в firewall, если он еще не открыт. OpenVPN может также работать через прокси сервера, что позволяет не менять правила фильтрации (firewall). Так так SSL не меняет IP уровень, то преобразование адресов (NAT) работает.

Создание site-to-site SSL туннеля намного проще чем IPSec. Сложность конфигурации IPSec часто приводит к проблемам с безопасностью или к пропуску настроек, даже если сеть строит администратор. К тому же настройки IPSec могут отличаться от производителя к производителю, в то время как настройки SSL и OpenVPN очень похожи на всех системах.

Большим преимуществом IPSec остается то, что он работает на любом производителе поддерживающем IPSec RFC. Например, практически возможно установить VPN соединение между Cisco и Nortel маршрутизаторами. Практически, потому что как показало время, даже если различные производители поддерживают IPSec стандарты, иногда остаются проблемы совместимости. OpenVPN не возможно установить на маршрутизаторы таких основных производителей как Cisco, Checkpoint, Juniper и Nortel.

SSL очень быстро развивается в сегменте клиент-сервер VPN по сравнению с IPSec и постепенно заменит его. В site-to-site сегменте преимущество остается за IPSec, это связано с тем что не существует стандарта (RFC) на создание site-to-site SSL VPN сетей. Среди большого количества VPN сетей созданных на базе устройств с закрытым исходным кодом, IPSec остается лидеров в этом секторе.

4.3 Исходные данные

Имеется сервер с FreeBSD, через который подсеть центрального офиса подключена к Интернет. На нем будет развернут сервер OpenVPN. Имеется два удаленных филиала, подсети которых также подключены к Интернет через серверы с FreeBSD (они будут клиентами OpenVPN) и компьютер системного администратора с Windows XP (он также будет клиентом OpenVPN). Локальная подсеть центрального офиса имеет адрес 192.168.0.0/24; локальная подсеть филиала № 1 - 192.168.1.0/24; локальная подсеть филиала № 2 - 192.168.2.0/24.

Графическая схема организации сети изображена на рисунке 7.1 Необходимо создать виртуальную частную сеть routed-типа (т.е. не пропускающую широковещательный трафик), с топологией Point-To-Multi-Point (один сервер и несколько клиентов), использующую для шифрования трафика TLS/SSL и обеспечивающую следующую политику маршрутизации:

- из локальной подсети центрального офиса доступны компьютеры локальных подсетей обоих филиалов;

- из локальных подсетей филиалов доступны компьютеры локальной подсети центрального офиса;



Рисунок 4.1 - схема построения виртуальной частной сети между несколькими офисами компании, подключенными к Интернет

При реализации данной задачи использовался пакет OpenSSL, и последняя версию порта OpenVPN.

4.4 Установка сервера OpenVPN

Перед установкой сервера OpenVPN необходимо добавить в файл конфигурации ядра строку pseudo-device tun, если таковая отсутствует, пересобрать ядро и перезагрузить систему. Затем нужно установить OpenVPN из портов:

cd /usr/ports/security/openvpn

make install

Файлы конфигурация сервера OpenVPN хранятся в папке /usr/local/etc/openvpn. Для создания этой папки, а также всех необходимых вложенных папок и файлов необходимо выполнить следующую последовательность команд:

mkdir /usr/local/etc/openvpn

cd /usr/local/etc/openvpn

mkdir ccd

mkdir certs

mkdir crl

mkdir keys

mkdir private

mkdir req

chmod 700 keys private

echo "01" > serial

touch index.txt

Указанные команды создают папку /usr/local/etc/openvpn; вложенные в нее папки: ccd (конфигурации удаленных клиентов), certs (сертификаты клиентов и сервера), crl (списки отзыва сертификатов), keys (закрытые ключи сертификатов клиентов и сервера), private (закрытый ключ самоподписного доверенного сертификата (CA), req (запросы на сертификаты); ограничивают права доступа к папкам keys и private; создают базу данных сертификатов (файлы serial и index.txt).

4.5 Файл конфигурации OpenSSL

По умолчанию OpenSSL использует файл конфигурации /etc/ssl/openssl.cnf. Но рекомендуется создать отдельный файл конфигурации OpenSSL в папке /usr/local/etc/openvpn. Данный файл должен называться openssl.cnf и иметь следующее содержимое:

[ ca ]

default_ca = CA_default

[ CA_default ]

dir = /usr/local/etc/openvpn

crl_dir = $dir/crl

database = $dir/index.txt

new_certs_dir = $dir/certs

certificate = $dir/CA_cert.pem

serial = $dir/serial

crl = $dir/crl/crl.pem

private_key = $dir/private/CA_key.pem

RANDFILE = $dir/private/.rand

default_days = 3650

default_crl_days = 365

default_md = md5

unique_subject = yes

policy = policy_any

x509_extensions = user_extensions

[ policy_any ]

organizationName = match

organizationalUnitName = optional

commonName = supplied

[ req ]

default_bits = 2048

default_keyfile = privkey.pem

distinguished_name = req_distinguished_name

x509_extensions = CA_extensions

[ req_distinguished_name ]

organizationName = Organization Name (must match CA)

organizationName_default = Company

organizationalUnitName = Location Name

commonName = Common User or Org Name

commonName_max = 64

[ user_extensions ]

basicConstraints = CA:FALSE

[ CA_extensions ]

basicConstraints = CA:TRUE

default_days = 3650

[ server ]

basicConstraints = CA:FALSE

nsCertType = server

4.6 Создание самоподписного доверенного сертификата (СА)

Для создания самоподписного доверенного сертификата (Certification Authority, CA) и закрытого ключа для него необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl req -new -nodes -x509 -keyout private/CA_key.pem -out CA_cert.pem -days 3650

Команда req заставляет OpenSSL создать сертификат, ключи: -new - cоздать запрос на сертификат, -nodes - не шифровать закрытый ключ, -x509 (совместно с -new) - создать самоподписной сертификат (CA), -keyout - задает местонахождение закрытого ключа, -out - задает местонахождение самоподписного сертификата, -days - задает время действия сертификата (365Ч10 дней, что приблизительно равно десяти годам). В процессе выполнения команды на экран будут выданы запросы о вводе таких параметров как: Country Name, State or Province Name; Locality Name; Organization Name; Organizational Unit Name; Common Name; Email Address. Самым важным параметром является значение Common Name. В данном случае оно должно совпадать с FQDN-именем сервера. Для просмотра результата генерации самоподписного сертификата и закрытого ключа необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl x509 -noout -text -in CA_cert.pem (для сертификата)

openssl rsa -noout -text -in private/CA_key.pem (для закрытого ключа)

4.7 Создание сертификата сервера

Перед созданием сертификата сервера необходимо создать запрос на сертификат сервера и закрытый ключ сервера. Для этого необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl req -new -nodes -keyout keys/server.pem -out req/server.pem

В процессе выполнения комнды необходимо ещё раз ответить на вопросы. Ответы должны соответствовать ответам из предыдущего пункта. В ответ на дополнительные запросы "A challenge password []:” и "An optional company name []:” оставить без изменений (нажать «Enter» ). Для просмотра результата генерации запроса на сертификат и закрытого ключа сервера необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl req -noout -text -in req/server.pem (для запроса на сертификат)

openssl rsa -noout -text -in keys/server.pem (для закрытого ключа)

Для создания сертификата сервера необходимо подписать запрос на сертификат сервера самоподписным доверенным сертификатом (CA). Для этого необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl ca -batch -config openssl.cnf -extensions server -out certs/server.pem -infiles req/server.pem

Команда ca заставляет OpenSSL подписать запрос на сертификат, ключи: -config задает местонахождение файла конфигурации OpenSSL, -extensions - задает секцию файла конфигурации OpenSSL, содержащую дополнительные параметры генерируемого сертификата, -out - задает местонахождение генерируемого сертификата, -infiles - задает местонахождение запроса на сертификат, -batch - избавляет от ответов на дополнительные вопросы. В процессе выполнения команды будет задан вопрос "Sign the certificate? [y/n]:”, на который нужно ответить утвердительно, после чего произойдет генерация сертификата и обновление базы данных сертификатов (файлов index.txt и serial). Для просмотра результата генерации сертификата необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl x509 -noout -text -in certs/server.pem

4.8 Создание файла параметров Диффи-Хэлмана

Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl dhparam -out dh2048.pem 2048

Команда dhparam приказывает OpenSSL создать файл параметров Диффи-Хэлмана, число 2048 определяет разрядность в битах. Данная команда выполняется достаточно медленно даже на очень мощных компьютерах.

4.9 Создание клиентских сертификатов

Процедура создания клиентских запросов на сертификаты и закрытых ключей, подписания запросов на сертификаты и генерации сертификатов, а также просмотра запросов на сертификаты, сертификатов и закрытых ключей полностью аналогична соответствующей процедуре для сервера. Запросы на сертификаты, закрытые ключи и сертификаты должны иметь шаблонные имена, например, вида: req/RClient для запросов на сертификаты, keys/KClient для закрытых ключей и certs/CClient для сертификатов, соответственно. Слово Client должно быть заменено именем клиента, которое обязательно должно соответствовать значению параметра Common Name, вводимого при генерации запроса на сертификат для соответствующего клиента. Возможность дублирования Common Name у нескольких клиентов определяется конфигурацией сервера. Для генерации запроса на сертификат и закрытого ключа, а также подписания запроса на сертификат и генерации сертификата для клиента Client необходимо выполнить следующие команды, находясь в папке /usr/local/etc/openvpn:

openssl req -new -nodes -keyout keys/KClient.pem -out req/RClient.pem

openssl ca -batch -config openssl.cnf -out certs/CClient.pem -infiles req/RClient.pem

Для просмотра сгенерированных запроса на сертификат, закрытого ключа и сертификата клиента Client необходимо выполнить следующие команды, находясь в папке /usr/local/etc/openvpn:

openssl req -noout -text -in req/RClient.pem (для запроса на сертификат)

openssl rsa -noout -text -in keys/KClient.pem (для закрытого ключа)

openssl x509 -noout -text -in certs/CClient.pem (для сертификата)

На данном этапе для рассматриваемого случая необходимо создать три групы, состоящих из запроса на сертификат / закрытого ключа / сертификата, с именами Rclient1 / Kclient1 / Cclient1, Rclient2 / Kclient2 / Cclient2 и Rclient3 / Kclient3 / Cclient3 для филиала № 1 (Common Name - client1), для филиала № 2 (Common Name - client2) и для системного администратора (Common Name - client3), соответственно.

4.10 Создание списка отзыва сертификатов

Для создания списка отзыва сертификатов необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl ca -config openssl.cnf -gencrl -out crl/crl.pem

Команда ca с ключем -gencrl заставляет OpenSSL создать список отзыва сертификатов, ключи: -config задает местонахождение файла конфигурации OpenSSL, -out - задает местонахождение списка отзыва сертификатов. Данная команда создает пустой список отзыва сертификатов. Для того, чтобы отозвать сертификат клиента Client необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl ca -config openssl.cnf -revoke certs/CClient.pem

Команда ca с ключем -revoke заставляет OpenSSL отозвать заданный сертификат, ключ -config задает местонахождение файла конфигурации OpenSSL. Для просмотра списка отозванных сертификатов необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl crl -noout -text -in crl/crl.pem

4.11 Создание статического ключа HMAC

Для создания статического ключа HMAC, обеспечивающего дополнительную защиту от DoS-атак и флудинга UDP-портов, необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openvpn --genkey --secret ta.key

4.12 Файл конфигурации сервера

По умолчанию конфигурация сервера OpenVPN хранится в файле openvpn.conf, который должен находится в папке /usr/local/etc/openvpn. В рассматриваемом случае файл конфигурации имеет следующий вид:

dev tun

local <Внешний IP-адрес сервера>

port 1194

proto udp

server 10.0.0.0 255.255.255.0

push "route 10.0.0.0 255.255.255.0"

route 192.168.1.0 255.255.255.0

route 192.168.2.0 255.255.255.0

client-config-dir ccd

client-to-client

tls-server

dh /usr/local/etc/openvpn/dh2048.pem

ca /usr/local/etc/openvpn/CA_cert.pem

cert /usr/local/etc/openvpn/certs/server.pem

key /usr/local/etc/openvpn/keys/server.pem

crl-verify /usr/local/etc/openvpn/crl/crl.pem

tls-auth /usr/local/etc/openvpn/ta.key 0

comp-lzo

keepalive 10 120

tun-mtu 1500

mssfix 1450

persist-key

persist-tun

user openvpn

group openvpn

verb 3

В данном файле заданы следующие значения параметров сервера OpenVPN: dev - интерфейс OpenVPN, local и port - IP-адрес и порт, на которых OpenVPN принимает входящие соединения, proto - протокол (в данном случае UDP), server - пул IP-адресов, выделенный для виртуальной частной сети и автоматически распределяемый между клиентами, push - команда OpenVPN, передаваемая клиенту и выполняемая клиентом (в данном случае "route 10.0.0.0 255.255.255.0" добавляет на стороне клиента маршрут к виртуальной частной сети), route - добавляет на стороне сервера маршруты к локальным подсетям, находящимся за клиентами, client-config-dir - папка с файлами конфигурации клиентов, client-to-client - разрешение клиентам “видеть” друг друга (естественно, при наличии соответствующих правил маршрутизации), tls-server - включение поддержки TLS; dh - местонахождение файла параметров Диффи-Хэлмана, ca - местонахождение самоподписного доверенного сертификата (CA), cert - местонахождение сертификата сервера, key - местонахождение закрытого ключа сервера, crl-verify - местонахождение списка отзыва сертификатов, tls-auth - местонахождение статического ключа HMAC, comp-lzo - использование LZO-компрессии трафика, keeplive - поддержание соединения (в данном случае отправка пингов каждые 10 секунд, и закрытие соединения через две минуты после отсутствия ответных пакетов, как сервером, так и клиентами), tun-mtu и mssfix - параметры передачи данных по тоннелю, persist-tun - не закрывать / открывать по-новой tun-устройство при получении сигнала SIGUSR1 (перезапуск без привилегий root) или при выполнении ping-restarts, user и group - пользователь и группа, от имени которых работает OpenVPN после запуска (запуск выполняется под root'ом), verb - уровень детализации сообщений, выдаваемых OpenVPN в /var/log/messages.

4.13 Файлы конфигурации клиентов

Файлы конфигурации клиентов являются текстовыми файлами и содержат команды, выполняемые сервером при подключении клиентов. Имена файлов конфигурации клиентов должны соответствовать Common Name клиентов, т.е. при подключении клиента с Common Name client1 сервер выполнит команды, заданные в файле client1 и т.д. Файлы конфигурации клиентов должны находиться в папке /usr/local/etc/openvpn/ccd. Для рассматриваемого для реализации нашего проэкта необходимо создать три файла конфигурации клиентов client1-client3:

cd /usr/local/etc/openvpn/ccd

touch client1 client2 client3

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

push "route 192.168.0.0 255.255.255.0"

iroute 192.168.1.0 255.255.255.0

Файл client2 аналогичен файлу client1 за исключением адреса локальной подсети, находящейся за клиентом:

push "route 192.168.0.0 255.255.255.0"

iroute 192.168.2.0 255.255.255.0

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

push "route 192.168.0.0 255.255.255.0"

push "route 192.168.1.0 255.255.255.0"

push "route 192.168.2.0 255.255.255.0"

4.14 Автоматический запуск сервера

Для автоматического запуска сервера OpenVPN при загрузке операционной системы необходимо добавить строку openvpn_enable="YES" в файл /etc/rc.conf.

4.15 Настройка брэндмауэров

Для корректной работы сервера OpenVPN необходимо внести следующие изменения в настройки брандмауэра:

- разрешить прохождение любого трафика через интерфейс OpenVPN;

- разрешить прохождение UDP-трафика на внешний адрес сервера порт 1194;

- разрешить прохождение любого трафика из виртуальной частной сети в локальную подсеть;

- разрешить прохождение любого трафика из локальной подсети в виртуальную частную сеть;

- разрешить прохождение любого трафика из локальной подсети филиала № 1 в локальную подсеть;

- разрешить прохождение любого трафика из локальной подсети в локальную подсеть филиала № 1;

- разрешить прохождение любого трафика из локальной подсети филиала № 2 в локальную подсеть;

- разрешить прохождение любого трафика из локальной подсети в локальную подсеть филиала № 2.

Для ipfw нужно добавить следующие правила:

/sbin/ipfw -q add pass ip from any to any via ${vif}

/sbin/ipfw -q add pass udp from any to ${oip} 1194 in via ${oif}

/sbin/ipfw -q add pass ip from ${vnet} to ${inet} out via ${iif}

/sbin/ipfw -q add pass ip from ${inet} to ${vnet} in via ${iif}

/sbin/ipfw -q add pass ip from 192.168.1.0/24 to ${inet} out via ${iif}

/sbin/ipfw -q add pass ip from ${inet} to 192.168.1.0/24 in via ${iif}

/sbin/ipfw -q add pass ip from 192.168.2.0/24 to ${inet} out via ${iif}

/sbin/ipfw -q add pass ip from ${inet} to 192.168.2.0/24 in via ${iif}

Переменные shell имеют следующие значения: oip - внешний IP-адрес сервера, inet - адрес локальной подсети (в нашем случае - 192.168.0.0/24), vnet - адрес виртуальной частной сети (в нашем случае 10.0.0.0/24), iif - имя внутреннего интерфейса сервера (например, rl1), oif - имя внешнего интерфейса сервера (например, rl0), vif - имя интерфейса OpenVPN (например, tun0).

Настройка брандмауэров клиентов выполняется аналогично. Правила, начиная с пятого, зависят от реализованной политики маршрутизации. Для нашего случая правила ipfw для клиента client1 будут иметь вид (так как теперь переменная shell inet определяет адрес локальной подсети клиента client1 - 192.168.1.0/24):