Применяем stunnel для защиты сервисов

Очень часто возникает потребность защитить от различных систем мониторинга работу SSH, VPN, либо других сервисов. С этим отлично справится stunnel, который мы и рассмотрим в данной статье.

Введение

Stunnel — это мощный прокси, который добавляет внешний слой шифрования TLS поверх любого из существующих протоколов без необходимости изменения их конфигурации, либо программного кода.

Мы рассмотрим работу с данным программным продуктом на примере дистрибутива Fedora (и CentOS с подключённым репозиторием EPEL7) и будем защищать OVN сервер.

Установка stunnel

Пакет доступен в главном репозитории Fedora. Установим его:

Настройка сервера stunnel

Все файлы конфигурации сервера должны находиться в каталоге /etc/stunnel, поэтому создадим главный конфиг stunnel.conf и укажем правильные права доступа:

Листинг файла /etc/stunnel/stunnel.conf:

Создадим каталог для индивидуальных конфигов защищаемых сервисов:

Листинг файла /etc/stunnel/conf.d/ovn.conf:

Здесь 127.0.0.1:1194 — это IP-адрес и порт, который слушает OVN сервер (для максимальной безопасности рекомендуется в настройках VPN сервера разрешить ему работать исключительно на 127.0.0.1, чтобы никто не мог подключиться к нему в обход stunnel), а 443 — порт, на котором stunnel будет ожидать входящие подключения.

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

Stunnel будет осуществлять аутентификацию клиентов при помощи сертификатов.

Создадим каталог для их хранения:

Сгенерируем сертификат для нашего сервера:

На выходе мы получим файлы server.crt (открытый ключ) и server.key (секретный ключ). Загрузим их на сервер в каталог /etc/stunnel/certs любым удобным для нас способом и установим chmod 0600:

Сгенерируем сертификаты для клиентов (каждый клиент должен выполнять этот шаг самостоятельно, а затем лишь передать свой открытый ключ (файл client.crt) на сервер):

Объединим все открытые ключи клиентов в единый бандл:

Скопируем полученный clients.pem на сервер любым способом и установим chmod 0644:

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

Запуск сервера

Теперь мы наконец готовы запустить наш сервер:

Настройка клиентов

Создадим каталог для хранения пользовательских сертификатов:

Создадим конфиг клиента client.conf и установим ему корректные права доступа:

Листинг файла /etc/stunnel/client.conf:

Скопируем публичный ключ сервера server.crt, а также клиентский сертификат (открытый (client1.crt) и закрытый (client1.key) ключи) в /etc/stunnel/certs и установим им правильный chmod:

Теперь изменим OVN подключение так, чтобы в качестве IP-адреса сервера использовался 127.0.0.1:1194.

Шифрование SOCKS-трафика с помощью Stunnel

Протокол SOCKS позволяет пересылать пакеты между сервером и клиентом через промежуточный (прокси) узел. Главным минусом SOCKS является отсутствие шифрования. Частично это можно скомпенсировать использованием поверх SOCKS протоколов со встроенным шифрованием. Однако и тут не всё идеально: если используется SOCKS5 с авторизацией по логину и паролю то логин и пароль от прокси передаются по сети без шифрования.

Stunnel это программное обеспечение позволяющее «пробросить» tcp-соединение поверх другого tcp-соединения с использованием шифрования. При использовании Stunnel можно обеспечить безопасное соедиение с сервисами, не поддерживающими шифрование. Платой за безопасность будет некоторое усложнение конфигурации как сервера, так и клиента.

Далее будет показано как добавить шифрование с помощью Stunnel к SOCKS5-прокси, описанному некоторое время назад. Краткое описание схемы: клиент вместо прямого соединения с проски подключается к Stunnel, запущенному на локальной машине в режиме клиента, Stunnel-клиент подключается к Stunnel-серверу, и он уже подключается к прокси.

Настройка сервера

Приступаем к настройке. Для начала установим Stunnel на нашу VPS с прокси-сервером:

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

Сразу создадим копию сертификата в формате PKCS12. На сервере она не нужна, но некоторым типам клиентов может понадобиться:

Закончив с сертификатами нужно создать файл конфигурации туннеля. В нашем случае это будет «/etc/stunnel/socks.conf» следующего содержания:

Здесь «45.67.78.90:8088» это IP и порт нашего SOCKS-прокси, который мы «оборачиваем» в Stunnel

После этого включаем сервис и запускаем его:

На этом настройка сервера заканчивается и можно приступать к настройке клиентов.

Настройка Linux-клиента

На клиентской машине под управлением Linux необходимо как и на сервере установить пакет «stunnel4», затем скопировать с сервера файл сертификата («/etc/stunnel/socks.pem») и сохранить его под именем «/etc/stunnel/socks.pem». Наконец создать файл конфигурации («/etc/stunnel/socks.conf»):

Здесь «45.67.78.90:8088» это IP и порт нашего Stunnel-сервера. Закончив конфигурацию включаем сервис и запускаем его:

На этом настройка клиента заканчивается. Теперь в качестве SOCKS-прокси в приложениях можно указывать адрес «127.0.0.1» и порт «8088».

Настройка Windows-клиента

На Windows первым делом надо скачать стабильную версию stunnel для windows и установить на свой компьютер. В процессе установки будет предложено создать сертификат. Можно создавать с любыми данными, так как нам он не понадобится.

После установки необходимо скопировать файл «socks.pem» с сервера в директорию «C:\Program Files (x86)\Stunnel\config». Затем кликнув правой кнопкой мыши по значку Stunnel в системном лотке в открывшемся меню выбрать «Edit Configuration».

Конфигурация для Windows практически не отличается от таковой для Linux и имеет вид:

После сохранения новой конфигурации нужно в меню stunnel выбрать пункт «Reload Configuration» и можно начинать пользоваться.

Настройка Android-клиента

На смартфонах под управлением ОС Android есть несколько приложений реализующих возможности Stunnel. Автору этих строк больше всего приглянулся SSLDroid: простые настройки, стабильная работа на Android 7.0, поддержка одновременно нескольких туннелей.

Настройка очень проста: необходимо загрузить на устройство сертификат нашего Stunnel-сервера в формате PKCS12, запустить создание нового туннеля, указать имя туннеля, порт на котором будут ожидаться входящие соединения, хост и порт нашего Stunnel-сервера и путь к файлу сертификата. Примерно так:

Дальше надо сохранить настройки, и в меню приложения выбрать запуск сервиса. После этого можно смело подключаться к SOCKS-прокси с адресом «127.0.0.1» и портом, который был указан как локальный.

Настройка iOS-клиента

Очень хотелось написать этот раздел, однако не получилось: stunnel-клиентов для iOS в App Store нет. Есть сборки stunnel от энтузиастов, но они требуют устройства с JailBreak. Потому к сожалению использовать stunnel на iOS в настоящий момент невозможно.

Вместо заключения

Stunnel позволяет добавить шифрование туда, где оно не предусмотрено изначально. Однако не стоит забывать что stunnel можно сконфигурировать небезопасным образом (без верификации сертификатов), допускающим MITM-атаку. Потому настройку stunnel следует доверять только опытным и проверенным администраторам.

Шифрование TLS-трафика по алгоритмам ГОСТ-2012 c Stunnel

В этой статье я хочу показать, как настроить Stunnel на использование российских криптографических алгоритмов в протоколе TLS. В качестве бонуса покажу, как шифровать TLS-канал, используя алгоритмы ГОСТ, реализованные в криптоядре Рутокен ЭЦП 2.0.

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

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

Стоит заметить, что на сервере не обязательно должен стоять именно Stunnel, для работы с криптографическими алгоритмами. Здорово, что есть готовые демонстрационные стенды, которые поддерживают российскую криптографию, список которых есть в презентации с РусКрипто’2019.

Нам нужны стабильно работающие серверы, осуществляющие двухстороннюю аутентификацию.
Мы выбрали серверы КриптоПро как наиболее надёжные с полной реализацией стандарта ГОСТ TLS. Спасибо им за это 🙂

Звучит достаточно просто, давайте попробуем организовать этот процесс.

Подготовительный шаг

1. OpenSSL
2. Stunnel
3. rtengine
4. Доступ к тестовым серверам КриптоПро, для проверки соединения по TLS

OpenSSL для Windows можно взять отсюда, а для пользователей линукса — из репозиториев или собрать самому, скачав свежую версию отсюда. Также его можно взять из Rutoken SDK, из директории openssl\openssl-tool-1.1, этот архив нам будет полезен и дальше, т.к. в нём находится интересующий нас rtengine. Stunnel можно найти здесь. Для работы необходима версия >= 5.56.

Скачать rtengine можно из Rutoken SDK, он лежит в директории openssl\rtengine\bin. Закинуть его нужно туда, где хранятся все движки openssl. Узнать путь до них можно с помощью

Но просто переместить движок в нужную папку — мало, нужно ещё сконфигурировать сам openssl для работы с ним. Узнаём где лежит файл с конфигурацией openssl.cnf с помощью той же команды, что указана выше (под виндой stunnel идёт с собственной версией openssl, поэтому файл с конфигурацией лежит в path\to\stunnel\config\openssl.cnf

Давайте проверим, что rtengine подключился, для этого подключим токен и выведем список всех алгоритмов шифрования:

Напомню, что в Windows нужно проверять на openssl, который лежит рядом с stunnel
Если среди них будут присутствовать наши ГОСТы, значит всё настроено верно.

Настало время самого интересного: проверка установки соединения по ГОСТу с тестовыми серверами КриптоПро. Список данных серверов описан здесь (https://www.cryptopro.ru/products/csp/tc26tls). Каждый из этих серверов работает со своими алгоритмами для аутентификации и шифрования. Более того на портах 443, 1443, 2443,… запущены сервисы, которые воспринимают только определённые парамсеты. Так, например, по адресу http://tlsgost-256auth.cryptopro.ru происходит шифрование с аутентификацией с использованием алгоритмов GOST2012-GOST8912-GOST8912 и 256-битным ключом. Так же на порту 443 используется XchA-ParamSet, на порту 1443 — XchB-ParamSet, на порту 2443 — A-ParamSet и т.д.

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

Простой способ (работает под Windows и Linux)

Через командную строку

Для того, чтобы получить корневой сертификат, зайдём на сайт тестового УЦ ООО «КРИПТО-ПРО». И нажмём на кнопку для получения сертификата. Отобразится новая вкладка, в которой нужно будет выбрать метод шифрования Base64 и нажать на кнопку «Загрузка сертификата ЦС». Полученный файл certnew.cer сохраняем.

Теперь генерируем ключи.

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

Создадим запрос на сертификат:

Опять открываем сайт тестового УЦ, но на этот раз нажимаем на кнопку «Отправить готовый запрос PKCS#10 или PKCS#7 в кодировке Base64». Вставляем в поле содержимое нашего запроса, нажимаем на кнопку Выдать и загружаем сертификат user.crt в формате Base64. Полученный файл сохраняем

Остался последний вопрос: Для чего всё это. Зачем мы получали все эти сертификаты, ключи и запросы?

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

У нас есть сертификат сервера, и мы считаем его доверенным.

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

Мы отправили этот запрос и сервер подписал её своей ЭЦП. Теперь мы можем каждый раз предъявлять этот сертификат, подписанный корневым УЦ, тем самым подтверждая, что мы — это мы.

Конфигурирование Stunnel

Осталось только правильно настроить наш туннель. Для этого создадим файл stunnel.conf с настройками Stunnel по умолчанию и напишем туда следующее:

Теперь, если всё сделано правильно, можно запустить Stunnel с нашей конфигурацией и подключиться к серверу:

Откроем браузер и зайдём по адресу localhost:8080. Если всё верно, то отобразится следующее:

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

Если у вас остались какие-то вопросы, то милости просим в комментарии 🙂

Stunnel на сервере и клиенте

Задача

Обеспечить доступ из «везде где есть интернет» к некоему ПО. Шифровать траффик между клиентской и серверной частью приложения, которое не умеет работать через SSL. Так же нужно иметь возможность ограничивать доступ некоторым пользователям при необходимости. По различным причинам основные реализации VPN отпали. В процессе поиска решения наткнулся на Stunnel, который идеально подошел. В данной статье постараюсь детально описать процесс настройки.

Статья по большей части составлена из рабочих заметок в довесок с претензиями на туториал, поэтому прошу спокойно относится к капитанству вида — «Первое, что мы сделаем — обновим систему».

Общее представление схемы работы:

ПО клиент (windows) > Stunnel > Интернет > Stunnel > ПО Сервер (linux)

Система: свежеустановленная ubuntu server 14.04 x64.

Приложение трафик которого нужно шифровать я называть не буду. Вместо него буду указывать ssh. Для теста подходит идеально, на мой взгляд.

Приступим

Первое, что мы сделаем — обновим систему:

Настроим и включим ufw:

При установке создаются:
— пользователь и группа stunnel4;
— интересные нам каталоги:

• /var/lib/stunnel4 здесь будет chroot окружение
• /etc/stunnel любой файл в этом каталоге оканчивающийся на .conf будет считаться конфигом
• /usr/share/doc/stunnel4/examples с примером конфига внутри

Проведем некоторые подготовительные мероприятия.

Разрешим автозапуск. В файле /etc/default/stunnel4 заменим ENABLED=0 на ENABLED=1:

Создадим папки для клиентских сертификатов. certs — разрешенные, crls — запрещенные (отозванные). О самих сертификатах чуть позже.

Создадим лог-файл и сменим владельца.

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

Я буду использовать свой конфиг, но если он вам не подходит можно взять пример в /usr/share/doc/stunnel4/examples

Создадим конфигурационный файл:

Со следующим содержимым:

Ключи и сертификаты

Не большое отступление. В нашем случае stunnel проверяет только корректность пары сертификат/ключ и наличие сертификата в разрешенных или запрещенных. Самоподписанного сертификата более чем достаточно, и с технической стороны (stunnel) и со стороны поставленной задачи. Нет никакого смысла заморачиваться с собственным CA или с присутствием корневого сертификата в списке доверенных на клиенте или сервере.

Нам нужны пары сертификат/ключ для сервера и каждого клиента.

C помощью openssl создадим пару для сервера:

Отвечаем на вопросы:

И переместим их по назначению:

Как и где хранить клиентские сертификаты с ключами (за исключением каталогов certs и crls созданных ранее) решать вам. Я просто создам каталог clients в домашней директории своего пользователя и буду хранить их там на первых порах.

Создадим каталог и перейдем в него:

Создадим пару для клиента:

Как и при создании сертификата для сервера отвечаем на вопросы. Common Name будет другим например client.

Создадим еще одну пару:

Предположим, что clientcert.pem сертификат клиента которому доступ разрешен, а dnclientcert.pem сертификат клиента которому доступ запрещен. Скопируем сертификаты по нужным директориям.

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

Со следующим содержимым:

Возможно будет более целесообразным разместить certlink.sh где нибудь в /usr/bin. Я пока не стал этого делать. Но выбор за вами.
Дадим права:

В результате в каталогах у нас должны появится ссылки вида 7469493f.0.

Stunnel на клиенте

На клиенте будем использовать версию stunnel аналогичную серверной. На сервере у нас 4.53. Забираем с одного из зеркал.

Если прямая ссылка перестанет работать, найти нужную версию можно так:

• Идем на stunnel.org в Downloads;
• В разделе Code Repositories выбираем зеркало и переходим. Например usenix.org.uk;
• Переходим в archive;
• Затем в 4.x;
• Забираем нужную версию.

Скачанный файл stunnel-4.53-installer.exe устанавливать не будем, просто распакуем содержимое в каталог stunnel4. В этот же каталог скопируем сертификат и ключ клиента, и сертификат сервера.

Редактируем файл stunnel.conf. У меня он имеет следующий вид:

Здесь debug = 7 только на момент отладки, потом можно понизить до 3 или 4. Также есть опции для «тихого режима» и сокрытия значка в трее все есть в man’e.

Запускаем stunnel.exe, и пробуем с помощью putty подключится к 127.0.0.1. Тестируем. Можно попробовать подключится с запрещенным сертификатом.

Полезные материалы

• stunnel(8) manual. Без комментариев;
• Защита сетевых сервисов с помощью stunnel на opennet.ru. Большая, полезная статья. Автор подробно разбирает несколько сценариев применения stunnel. Must read;
• OpenSSL xgu.ru. Много полезной информации об openssl. Скрипт certlink.sh взят из этого источника.

Приведенные здесь инструкции полностью работоспособны. Проверено 26.12.2014 ubuntu 14.04.01, stunnel 4.53.

В данный момент работаю над парсингом логов stunnel с выводом отчетов и автоматизацией создания/управления сертификатами. Так как в последнее время мне интересен golang, реализовано будет с помощью него. Если материал на эту тему интересен — дайте знать.