Проект коммерческого open-source VPN-сервиса
Invite pending
Необходимость защиты информационных процессов и процедуры их электронной автоматизации является одной из приоритетных задач современных IT-технологий. Другим немаловажным аспектом выступает концепция свободы слова, защитить которую призваны инструменты обеспечения анонимности и конфиденциальности в глобальной сети Интернет. К сожалению, во многих странах с каждым днем усиливается политическая цензура. Яркими тому примерами служат преследования журналистов в США, КНДР и Турции. В связи с чем, возрастает актуальность использования технологий защищенных виртуальных каналов, и в частности — VPN (англ. Virtual Private Network — виртуальная частная сеть).
Многие компании разрабатывают коммерческие сервисы, ставя перед собой задачу скорейшего извлечения прибыли. Однако, проведя сравнительный анализ существующих решений с использованием инструментов активного и пассивного анализа трафика и информационных систем (сканеров, зондеров и т.д.), были выявлены уязвимости практически в каждом из сервисов. В одном случае не были установлены критические обновления ПО (например, OpenVPN), в другом же были интегрированы бэкдоры (инструменты скрытного анализа трафика и управления клиентом).
Соответственно, добросовестность подобных ресурсов остается под вопросом. Исходя из данного вывода, мы решили разработать коммерческий open-source VPN-сервис с целью популяризировать технологии защищенных каналов связи.
Текущая версия проекта — это набор скриптов для автоматизированного развертывания удостоверяющего центра и OpenVPN серверов.
Модель взаимодействия пользователя с системой выглядит следующим образом:
Исходя из модели взаимодействия, становятся понятны основные элементы системы:
Схема взаимодействия выглядит следующим образом:
Рис.1. Схема взаимодействия элементов системы.
Это сторонние хосты, которые с помощью стандартного OpenVPN клиента будут подключаться к серверам. Для того чтобы подключиться, пользователь должен сначала зайти в биллинговую систему, зарегистрироваться в ней и оплатить подписку. После регистрации, пользователь из своего личного кабинета может скачать архив с настройками.
Точка входа в систему. Задачами WEB–сервера являются:
Вкратце поясним их:
Работа с профилями включает в себя регистрацию новых пользователей, реализацию возможности редактирования своего профиля пользователем, удаление профилей.
Биллинговая система должна реализовывать систему принятия платежей от пользователей.
Система авторизации должна отвечать на вопрос: какому пользователю, к какому из серверов, и в какое время/месте, можно подключиться, а когда нельзя.
Реализация WEB части может быть выполнена на любом языке с применением любых технологией. В связи с этим, пример реализации WEB-сервера не приводится.
Основной задачей удостоверяющего центра является выдача подписанных им сертификатов для клиентов и серверов VPN-сервиса.
Установка
После запуска скрипта «CA/start.sh», на ПК будет создана инфраструктура публичных ключей (PKI).
Потребуется ввести имя удостоверяющего центра.
Рис.2. Экранная форма выбора имени удостоверяющего центра.
Этим именем будет назван сертификат удостоверяющего центра, а в дальнейшем и все подписанный им сертификаты.
Рис.3. Самоподписанный сертификат удостоверяющего центра.
После запуска и выполнения скрипта, будет создан пользовать «user-ca» с паролем, который скрипт запросит во время установки. После развертывания, в домашнем каталоге пользователя будут расположены два исполняемых файла: «gen-client.sh» – для генерирования сертификатов пользователя, и «gen-server.sh» – для генерирования сертификатов серверов.
Работа
Для генерации сертификата пользователя нужно выполнить скрипт «gen-client.sh», где единственным аргументом является имя пользователя:
Рис.4. Пример работы скрипта генерирования сертификата пользователя.
В итоге получим приватный ключ и подписанный сертификат.
Рис.5. Подписанный удостоверяющим центром сертификат пользователя.
Почти аналогично происходит генерация сертификата и для сервера – единственное отличие заключается в том, что скрипт запрашивает кодовое слово для шифрования первичного ключа.
Рис.6. Пример работы скрипта генерирования сертификата OpenVPN сервера.
В итоге получаем:
Рис.7. Подписанный удостоверяющим центром сертификат OpenVPN сервера.
Для удобства использования, инфраструктура PKIбыла немного изменена. В домашнем каталоге пользователя «user-ca» находится папка «share», в которой находятся каталоги«clients»,«servers» и «base». «clients» — содержит подкаталоги имени пользователей. В них хранятся сертификаты и ключи для каждого пользователя. Содержимое папки «servers» аналогично. В папку «base» копируются файлы ca.crt и crl.pem после создания каждого сертификата.
В дальнейшем этот каталог можно будет вынести из домашней папки пользователя, например для SFTP доступа через ProFTPd.
Рис.8. Структура папок измененного PKI
Существует несколько способов создания этого набора:
Все четыре варианта можно проиллюстрировать следующим образом:
Рис.9. Способы создания сертификата пользователя.
Здесь стоит отметить, что если применяется вариант генерации приватного ключа с применением шифрования кодовым словом, то его придется вводить при каждом подключении клиента.
Рис.10. Экранная форма ввода кодового слова при подключении к OpenVPN серверу.
В данном варианте предлагается использовать первый вариант, поскольку он отличается наибольшим удобством для пользователя. Не нужно скачивать отдельную утилиту, генерировать секретный ключ с кодовым словом и отправлять запрос на подписание сертификата, а так же вводить это кодовое слово при каждом подключении. Для большей части пользователей это является слишком сложным и избыточным. Хотя, конечно, данные возможности можно легко реализовать. Разрабатываемый сервис сам генерирует приватный ключ пользователя и подписывает его после этого, по защищенному каналу набор передается пользователю.
Варианты создания сертификата сервера аналогичны вариантам создания сертификатов для пользователя, которые были рассмотрены ранее.
В разрабатываемом решении для получения сертификата сервера используется вариант с генерацией ключа на стороне удостоверяющего центра с применением шифрования приватного ключа кодовым словом. Это кодовое слово нужно ввести при запуске скрипта «./gen-server.shServerName».
При использовании кодового слова для шифрования приватного ключа, это слово нужно будет вводить каждый раз при старте OpenVPN демона. Если OpenVPN сервера должны стартовать автоматически при их неплановом перезапуске (например, в связи с профилактическими работами дата центра), то в конфигурационном файле сервера «/etc/openvpn/server.config» можно добавить строку, которая будет указывать на файл, в котором в открытом виде будет храниться кодовое слово. Это, конечно, снижает общий уровень защиты OpenVPN сервера, но с другой стороны избавляет от необходимости ручного перезапуска. В предлагаемом решении выбран именно такой вариант. Кодовое слово должно быть записано в файле «/etc/openvpn/pass» в открытом виде в одну строчку без пробелов. Причем предлагается для передачи из удостоверяющего центра ключа и сертификата использовать один защищенный канал связи, а для передачи кодового слова использовать другой канал связи.
Когда пользователь пытается подключиться к серверу, то их взаимодействие можно описать следующим образом:
В разрабатываемом решении проверка удостоверяющего центра на принадлежность к отозванным сертификатам (файл crl.pem;) выполняется формально. Это связано с тем, что его использование в рамках решаемой задачи по построению VPN сервиса крайне неудобно. При регистрации мы выдаем пользователю сертификат для того, чтобы успешно авторизоваться на серверах. Если срок подписки заканчивается, то сертификат необходимо отозвать, что делается достаточно легко с помощью команды «./easyrsarevokeClientName». Однако, когда пользователь вновь продлит подписку, перевести сертификат из ряда запрещенных в разрешенные уже нельзя, поскольку действие это не предусмотрено механизмом crl. Выдать одноименный разрешённый сертификат тоже нельзя: имена клиентов всегда должны быть уникальными. Выдача же нового сертификата с новым именем сопряжена со сложностями его дальнейшего отслеживания в биллинговой системе. По факту это потребовало бы создание еще одной таблицы, где каждому пользователю будут сопоставлены все его сертификаты.
Существует еще одна проблема, связанная со следующим аспектом: после того как мы запретим пользователям сертификат, нужно распространить новый «crl.pem» файл по всем OpenVPN серверам моментально. Это нельзя делать автоматически с помощью планировщика из сервера, так как если мы установим интервал опроса слишком большой, то пользователи, у которых истекла подписка, будут продолжать еще какое то время пользоваться сервисом. Установление же слишком маленького интервала приведет к увеличению нагрузки на сервер.
Самым весомым недостатком использования файла отзыва сертификата «crl.pem» является необходимость не только обновления, но и перезапуска демона OpenVPN после обновления файла, что плохо сказывается на подключенных клиентах (им так же нужно будет возобновить подключение к серверу).
Теперь, когда подробно описаны все элементысистемы, опишем их взаимодействие между собой.
WEB-сервер является центральным и связующим звеном системы. Он выступает внешней системой авторизации для OpenVPN серверов. Это представляется удобным, поскольку логику системы авторизации можно реализовать любую.
Рис.11. Схема взаимодействия элементов системы коммерческого open-source OpenVPN сервиса.
Так же WEB-сервер используется для передачи подписанных сертификатов от удостоверяющего центра к пользователям. Это позволяет сделать IP-адрес CA-сервера скрытым, его знает только WEB-сервер.
Стартом работы системы можно считать регистрацию нового пользователя в WEB-портале. После этого WEB-сервер по протоколу «ssh» обращается к CA-серверу от имени «user-ca» для запуска скрипта «gen-client.sh», который сгенерирует сертификат и ключ клиента. Далее WEB-сервер забирает эти файлы по «sftp» и отдает их клиенту по «https» протоколу. Для повышения безопасности можно использовать запароленные архивы или «trueCrypt»тома генерируемые на стороне WEB-сервера или CA-сервера. Ключи для расшифровки можно передавать по другому каналу связи, например, по почте, которую указывает пользователь при регистрации. Естественно, для обеспечения надлежащего уровня информационной безопасности рекомендуется использовать профилирование и списки фильтрации доступа, технологию простукивания портов, системы обнаружения и предотвращения вторжений, SIEM и другие системы. Это будет дорабатываться в последующих версиях проекта.
Надеемся, что наш бесплатный проект коммерческого VPN-сервиса с открытым исходным кодом будет вам полезен.
С уважением, Научно-исследовательский институт информационно-коммуникационных технологий.
Многие компании разрабатывают коммерческие сервисы, ставя перед собой задачу скорейшего извлечения прибыли. Однако, проведя сравнительный анализ существующих решений с использованием инструментов активного и пассивного анализа трафика и информационных систем (сканеров, зондеров и т.д.), были выявлены уязвимости практически в каждом из сервисов. В одном случае не были установлены критические обновления ПО (например, OpenVPN), в другом же были интегрированы бэкдоры (инструменты скрытного анализа трафика и управления клиентом).
Соответственно, добросовестность подобных ресурсов остается под вопросом. Исходя из данного вывода, мы решили разработать коммерческий open-source VPN-сервис с целью популяризировать технологии защищенных каналов связи.
Текущая версия проекта — это набор скриптов для автоматизированного развертывания удостоверяющего центра и OpenVPN серверов.
Модель взаимодействия пользователя с системой выглядит следующим образом:
- пользователь заходит на сайт VPN сервиса;
- регистрируется на этом сайте;
- скачивает файлы настроек, ключа и сертификатов;
- оплачивает подписку;
- используя стандартный OpenVPN клиент, подключается к одному из серверов;
- использует сервис.
Исходя из модели взаимодействия, становятся понятны основные элементы системы:
- пользователь;
- WEB-сервер;
- OpenVPN сервер;
- удостоверяющий центр.
Схема взаимодействия выглядит следующим образом:
Рис.1. Схема взаимодействия элементов системы.
Пользователи
Это сторонние хосты, которые с помощью стандартного OpenVPN клиента будут подключаться к серверам. Для того чтобы подключиться, пользователь должен сначала зайти в биллинговую систему, зарегистрироваться в ней и оплатить подписку. После регистрации, пользователь из своего личного кабинета может скачать архив с настройками.
WEB–сервер
Точка входа в систему. Задачами WEB–сервера являются:
- предоставление информации о системе;
- работа с профилями пользователей;
- биллинговая система;
- система авторизации.
Вкратце поясним их:
Работа с профилями включает в себя регистрацию новых пользователей, реализацию возможности редактирования своего профиля пользователем, удаление профилей.
Биллинговая система должна реализовывать систему принятия платежей от пользователей.
Система авторизации должна отвечать на вопрос: какому пользователю, к какому из серверов, и в какое время/месте, можно подключиться, а когда нельзя.
Реализация WEB части может быть выполнена на любом языке с применением любых технологией. В связи с этим, пример реализации WEB-сервера не приводится.
CA-сервер. Удостоверяющий центр.
Основной задачей удостоверяющего центра является выдача подписанных им сертификатов для клиентов и серверов VPN-сервиса.
Установка
После запуска скрипта «CA/start.sh», на ПК будет создана инфраструктура публичных ключей (PKI).
Потребуется ввести имя удостоверяющего центра.
Рис.2. Экранная форма выбора имени удостоверяющего центра.
Этим именем будет назван сертификат удостоверяющего центра, а в дальнейшем и все подписанный им сертификаты.
Рис.3. Самоподписанный сертификат удостоверяющего центра.
После запуска и выполнения скрипта, будет создан пользовать «user-ca» с паролем, который скрипт запросит во время установки. После развертывания, в домашнем каталоге пользователя будут расположены два исполняемых файла: «gen-client.sh» – для генерирования сертификатов пользователя, и «gen-server.sh» – для генерирования сертификатов серверов.
Работа
Для генерации сертификата пользователя нужно выполнить скрипт «gen-client.sh», где единственным аргументом является имя пользователя:
Рис.4. Пример работы скрипта генерирования сертификата пользователя.
В итоге получим приватный ключ и подписанный сертификат.
Рис.5. Подписанный удостоверяющим центром сертификат пользователя.
Почти аналогично происходит генерация сертификата и для сервера – единственное отличие заключается в том, что скрипт запрашивает кодовое слово для шифрования первичного ключа.
Рис.6. Пример работы скрипта генерирования сертификата OpenVPN сервера.
В итоге получаем:
Рис.7. Подписанный удостоверяющим центром сертификат OpenVPN сервера.
Для удобства использования, инфраструктура PKIбыла немного изменена. В домашнем каталоге пользователя «user-ca» находится папка «share», в которой находятся каталоги«clients»,«servers» и «base». «clients» — содержит подкаталоги имени пользователей. В них хранятся сертификаты и ключи для каждого пользователя. Содержимое папки «servers» аналогично. В папку «base» копируются файлы ca.crt и crl.pem после создания каждого сертификата.
В дальнейшем этот каталог можно будет вынести из домашней папки пользователя, например для SFTP доступа через ProFTPd.
Рис.8. Структура папок измененного PKI
Создание сертификата для OpenVPN клиента
Существует несколько способов создания этого набора:
- удостоверяющий центр сам генерирует для пользователя приватный и публичный ключи. При генерации приватного ключа шифрование в виде кодового слова не используется. После этого центр подписывает публичный ключ клиента, в результате чего появляется открытый сертификат пользователя. После этого сертификат и приватный ключ по защищенному каналу передается пользователю для использования;
- удостоверяющий центр сам генерирует для пользователя приватный и публичный ключи. Но здесь, в отличие от первого варианта, происходит шифрование приватного ключа с помощью кодового слова. В этом случаебезопасность повышается, поскольку ключ от приватного ключа мы можем сообщить по другому шифрованному каналу, и даже в случае перехвата ключа и сертификата злоумышленником – он не сможет воспользоваться ими, не зная секретного слова;
Секретное слово для генерации ключа здесь может быть случайно сформировано на стороне удостоверяющего центра, либо запрошено от пользователя. В случае если кодовое слово запрашивается у пользователя, который должен нам его сообщить, и в момент генерации ключа мы это слово видим – таким образом, пользователь не может сообщить нам секретное слово так, чтобы мы его не прочили. Соответственно, пользователю, у которого нет к сервису доверия, нет разницы, сгенерировано ли кодовое слово нами или запрошено у него, поскольку в обоих случаях мы можем прочесть это слово; - пользователь создает у себя приватный ключ и на основании этого приватного ключа генерирует запрос на подписание сертификата от удостоверяющего центра. В этом случае пользователь должен передать в удостоверяющий центр только файл запроса – приватный ключ остается у пользователя, и мы его не видим. Таким образом, существенно повышается безопасность;
- пользователь создает у себя приватный ключ с применением шифрования кодовым словом. Этот вариант является самым надежным.
Все четыре варианта можно проиллюстрировать следующим образом:
Рис.9. Способы создания сертификата пользователя.
Здесь стоит отметить, что если применяется вариант генерации приватного ключа с применением шифрования кодовым словом, то его придется вводить при каждом подключении клиента.
Рис.10. Экранная форма ввода кодового слова при подключении к OpenVPN серверу.
В данном варианте предлагается использовать первый вариант, поскольку он отличается наибольшим удобством для пользователя. Не нужно скачивать отдельную утилиту, генерировать секретный ключ с кодовым словом и отправлять запрос на подписание сертификата, а так же вводить это кодовое слово при каждом подключении. Для большей части пользователей это является слишком сложным и избыточным. Хотя, конечно, данные возможности можно легко реализовать. Разрабатываемый сервис сам генерирует приватный ключ пользователя и подписывает его после этого, по защищенному каналу набор передается пользователю.
Создание сертификата для OpenVPN сервера
Варианты создания сертификата сервера аналогичны вариантам создания сертификатов для пользователя, которые были рассмотрены ранее.
В разрабатываемом решении для получения сертификата сервера используется вариант с генерацией ключа на стороне удостоверяющего центра с применением шифрования приватного ключа кодовым словом. Это кодовое слово нужно ввести при запуске скрипта «./gen-server.shServerName».
При использовании кодового слова для шифрования приватного ключа, это слово нужно будет вводить каждый раз при старте OpenVPN демона. Если OpenVPN сервера должны стартовать автоматически при их неплановом перезапуске (например, в связи с профилактическими работами дата центра), то в конфигурационном файле сервера «/etc/openvpn/server.config» можно добавить строку, которая будет указывать на файл, в котором в открытом виде будет храниться кодовое слово. Это, конечно, снижает общий уровень защиты OpenVPN сервера, но с другой стороны избавляет от необходимости ручного перезапуска. В предлагаемом решении выбран именно такой вариант. Кодовое слово должно быть записано в файле «/etc/openvpn/pass» в открытом виде в одну строчку без пробелов. Причем предлагается для передачи из удостоверяющего центра ключа и сертификата использовать один защищенный канал связи, а для передачи кодового слова использовать другой канал связи.
Работа OpenVPN сервера
Когда пользователь пытается подключиться к серверу, то их взаимодействие можно описать следующим образом:
- клиент и сервер обмениваются своими сертификатами. При обмене сертификатами используется алгоритм Диффи-Хеллмана, который необходим для обмена ключами по небезопасному каналу связи;
- получив сертификат, сервер удостоверяется, что он подписан тем же удостоверяющим центром, что и его сертификат. Именно поэтому нужен файл ca.crt. (Клиент, к слову, делает тоже самое);
- после проверки сервер удостоверяется, что сертификат пользователя не отозван, для этого на сервере необходим файл crl.pam (по сути, использование механизма отзыва сертификатов в рамках решаемой задачи нерационально, это будет показано ниже);
- сервер из сертификата пользователя узнает username клиента, запрашивающего соединение;
- сервер совершает https-запрос на WEB-сервер, где передает username для подтверждения прав пользователя на подключение. На WEB-сервере располагается биллинговая подсистема, которая, руководствуясь инкапсулированной логикой, разрешает либо отклоняет запрос пользователя на подключение и уведомляет об этом сервер;
- сервер принимает либо отвергает подключение пользователя. В случае успешного установления соединения происходит успешная работа пользователя через OpenVPN сервер сервиса.
В разрабатываемом решении проверка удостоверяющего центра на принадлежность к отозванным сертификатам (файл crl.pem;) выполняется формально. Это связано с тем, что его использование в рамках решаемой задачи по построению VPN сервиса крайне неудобно. При регистрации мы выдаем пользователю сертификат для того, чтобы успешно авторизоваться на серверах. Если срок подписки заканчивается, то сертификат необходимо отозвать, что делается достаточно легко с помощью команды «./easyrsarevokeClientName». Однако, когда пользователь вновь продлит подписку, перевести сертификат из ряда запрещенных в разрешенные уже нельзя, поскольку действие это не предусмотрено механизмом crl. Выдать одноименный разрешённый сертификат тоже нельзя: имена клиентов всегда должны быть уникальными. Выдача же нового сертификата с новым именем сопряжена со сложностями его дальнейшего отслеживания в биллинговой системе. По факту это потребовало бы создание еще одной таблицы, где каждому пользователю будут сопоставлены все его сертификаты.
Существует еще одна проблема, связанная со следующим аспектом: после того как мы запретим пользователям сертификат, нужно распространить новый «crl.pem» файл по всем OpenVPN серверам моментально. Это нельзя делать автоматически с помощью планировщика из сервера, так как если мы установим интервал опроса слишком большой, то пользователи, у которых истекла подписка, будут продолжать еще какое то время пользоваться сервисом. Установление же слишком маленького интервала приведет к увеличению нагрузки на сервер.
Самым весомым недостатком использования файла отзыва сертификата «crl.pem» является необходимость не только обновления, но и перезапуска демона OpenVPN после обновления файла, что плохо сказывается на подключенных клиентах (им так же нужно будет возобновить подключение к серверу).
Описание работы системы
Теперь, когда подробно описаны все элементысистемы, опишем их взаимодействие между собой.
WEB-сервер является центральным и связующим звеном системы. Он выступает внешней системой авторизации для OpenVPN серверов. Это представляется удобным, поскольку логику системы авторизации можно реализовать любую.
Рис.11. Схема взаимодействия элементов системы коммерческого open-source OpenVPN сервиса.
Так же WEB-сервер используется для передачи подписанных сертификатов от удостоверяющего центра к пользователям. Это позволяет сделать IP-адрес CA-сервера скрытым, его знает только WEB-сервер.
Стартом работы системы можно считать регистрацию нового пользователя в WEB-портале. После этого WEB-сервер по протоколу «ssh» обращается к CA-серверу от имени «user-ca» для запуска скрипта «gen-client.sh», который сгенерирует сертификат и ключ клиента. Далее WEB-сервер забирает эти файлы по «sftp» и отдает их клиенту по «https» протоколу. Для повышения безопасности можно использовать запароленные архивы или «trueCrypt»тома генерируемые на стороне WEB-сервера или CA-сервера. Ключи для расшифровки можно передавать по другому каналу связи, например, по почте, которую указывает пользователь при регистрации. Естественно, для обеспечения надлежащего уровня информационной безопасности рекомендуется использовать профилирование и списки фильтрации доступа, технологию простукивания портов, системы обнаружения и предотвращения вторжений, SIEM и другие системы. Это будет дорабатываться в последующих версиях проекта.
Надеемся, что наш бесплатный проект коммерческого VPN-сервиса с открытым исходным кодом будет вам полезен.
С уважением, Научно-исследовательский институт информационно-коммуникационных технологий.