Очень часто возникает потребность защитить от различных систем мониторинга работу SSH, VPN, либо других сервисов. С этим отлично справится stunnel, который мы и рассмотрим в данной статье.
Введение
Stunnel — это мощный прокси, который добавляет внешний слой шифрования TLS поверх любого из существующих протоколов без необходимости изменения их конфигурации, либо программного кода.
Мы рассмотрим работу с данным программным продуктом на примере дистрибутива Fedora (и CentOS с подключённым репозиторием EPEL7) и будем защищать OVN сервер.
Установка stunnel
Пакет доступен в главном репозитории Fedora. Установим его:
sudo dnf install stunnel
Настройка сервера stunnel
Все файлы конфигурации сервера должны находиться в каталоге /etc/stunnel, поэтому создадим главный конфиг stunnel.conf и укажем правильные права доступа:
sudo touch /etc/stunnel/stunnel.conf sudo chmod 0644 /etc/stunnel/stunnel.conf
Листинг файла /etc/stunnel/stunnel.conf:
; Указываем имя и группу, от имени которых будет запущен сервис. setuid = nobody setgid = nobody ; Указываем PID файл работающего сервиса. pid = /var/run/stunnel.pid ; Отключим отладочные режимы. debug = 0 output = /var/log/stunnel.log ; Для удобства отделим основной файл конфигурации от настроек сервисов. include = /etc/stunnel/conf.d ; Зададим настройки шифрования и версию TLS. curves = prime256v1 sslVersion = TLSv1.2:TLSv1.3 ; Полностью отключим уязвимые протоколы SSL версии 2 и 3. options = NO_SSLv2 options = NO_SSLv3
Создадим каталог для индивидуальных конфигов защищаемых сервисов:
sudo mkdir -p /etc/stunnel/conf.d sudo chmod 0755 /etc/stunnel/conf.d
Листинг файла /etc/stunnel/conf.d/ovn.conf:
[ovn] accept = 443 connect = 127.0.0.1:1194 renegotiation = no verifyPeer = yes ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-SHA cert = /etc/stunnel/certs/server.crt key = /etc/stunnel/certs/server.key CAfile = /etc/stunnel/certs/clients.pem
Здесь 127.0.0.1:1194 — это IP-адрес и порт, который слушает OVN сервер (для максимальной безопасности рекомендуется в настройках VPN сервера разрешить ему работать исключительно на 127.0.0.1, чтобы никто не мог подключиться к нему в обход stunnel), а 443 — порт, на котором stunnel будет ожидать входящие подключения.
Создание сертификатов
Stunnel будет осуществлять аутентификацию клиентов при помощи сертификатов.
Создадим каталог для их хранения:
sudo mkdir -p /etc/stunnel/certs sudo chmod 0755 /etc/stunnel/certs
Сгенерируем сертификат для нашего сервера:
openssl req -newkey rsa:2048 -nodes -keyout server.key -x509 -days 3650 -subj "/CN=stunnel" -out server.crt
На выходе мы получим файлы server.crt (открытый ключ) и server.key (секретный ключ). Загрузим их на сервер в каталог /etc/stunnel/certs любым удобным для нас способом и установим chmod 0600:
sudo chmod 0600 /etc/stunnel/certs/server.{crt,key}
Сгенерируем сертификаты для клиентов (каждый клиент должен выполнять этот шаг самостоятельно, а затем лишь передать свой открытый ключ (файл client.crt) на сервер):
openssl req -newkey rsa:2048 -nodes -keyout client1.key -x509 -days 720 -subj "/CN=client1" -out client1.crt openssl req -newkey rsa:2048 -nodes -keyout client2.key -x509 -days 720 -subj "/CN=client2" -out client2.crt
Объединим все открытые ключи клиентов в единый бандл:
cat client*.crt > clients.pem
Скопируем полученный clients.pem на сервер любым способом и установим chmod 0644:
sudo chmod 0644 /etc/stunnel/certs/clients.pem
При появлении нового клиента его публичный ключ должен быть добавлен в бандл, а сервис stunnel перезапущен.
Запуск сервера
Теперь мы наконец готовы запустить наш сервер:
sudo systemctl enable --now [email protected]
Настройка клиентов
Создадим каталог для хранения пользовательских сертификатов:
sudo mkdir -p /etc/stunnel/certs sudo chmod 0755 /etc/stunnel/certs
Создадим конфиг клиента client.conf и установим ему корректные права доступа:
sudo touch /etc/stunnel/client.conf sudo chmod 0644 /etc/stunnel/client.conf
Листинг файла /etc/stunnel/client.conf:
; Общие настройки клиента. setuid = nobody setgid = nobody pid = /var/run/stunnel.pid debug = 0 curves = prime256v1 sslVersion = TLSv1.2 ; Настройки подключения к сервису. [ovn] client = yes accept = 127.0.0.1:1194 connect = IP_СЕРВЕРА:443 verifyPeer = yes cert = /etc/stunnel/certs/client1.crt key = /etc/stunnel/certs/client1.key CAfile = /etc/stunnel/certs/server.crt
Скопируем публичный ключ сервера server.crt, а также клиентский сертификат (открытый (client1.crt) и закрытый (client1.key) ключи) в /etc/stunnel/certs и установим им правильный chmod:
sudo chmod 0644 /etc/stunnel/certs/server.crt sudo chmod 0600 /etc/stunnel/certs/client*.{crt,key}
Запустим клиент:
sudo systemctl enable --now [email protected]
Теперь изменим OVN подключение так, чтобы в качестве IP-адреса сервера использовался 127.0.0.1:1194.
Есть смысл использовать stunnel на WireGuard?
Нет ибо это перечеркнёт все основные преимущества протокола WireGuard: работа в режиме ядра и скорость.
В самом WireGuard можно включить шифрование рукопожатия при помощи статического ключа.
Смысл может быть, чтобы сокрыть от систем DPI и прочих доброжелателей факт использования ВПН, как будто вы работаете по HTTPS, что может помочь от блокировки или замедления трафика.
Доброго дня. Нужна помощь.
Centos.
Stunnel 5.59 Compiled/running with OpenSSL 1.1.1d 10 Sep 2019.
Apache 2.4.6
После обновления Apache до версии 2.4.48 или 2.4.49 Stunnel работает до перезагрузки.
После перезапуск Stunnel «ругается» на отсутствие OpenSSL 1.1.0. Т.е. произошла какая-то подмена в конфигурационных файлах.
На машине нет OpenSSL 1.1.0, а есть OpenSSL 1.1.1d с ним и должен работать Stunnel.
Т.к., с Linux ранее не работал, то ОЧЕНЬ нужна помощь. Где копать?
Stunnel и openssl у вас, я так понимаю, не из репозиториев CentOS? В таком случае необходимо пересобрать пакет stunnel с соответствующей версией openssl ибо ABI совместимость между версиями из разных веток не гарантируется.
После пересборки и установки этой версии всё должно снова работать корректно.