Обеспечить доступ из «везде где есть интернет» к некоему ПО. Шифровать траффик между клиентской и серверной частью приложения, которое не умеет работать через SSL. Так же нужно иметь возможность ограничивать доступ некоторым пользователям при необходимости. По различным причинам основные реализации VPN отпали. В процессе поиска решения наткнулся на Stunnel, который идеально подошел.
В данной статье постараюсь детально описать процесс настройки.
Статья по большей части составлена из рабочих заметок в довесок с претензиями на туториал, поэтому прошу спокойно относится к капитанству вида — «Первое, что мы сделаем — обновим систему».
Общее представление схемы работы:
ПО клиент (windows) > Stunnel > Интернет > Stunnel > ПО Сервер (linux)
Система: свежеустановленная ubuntu server 14.04 x64.
Приложение трафик которого нужно шифровать я называть не буду. Вместо него буду указывать ssh. Для теста подходит идеально, на мой взгляд.
stunnel trad
Приступим
Первое, что мы сделаем — обновим систему:
sudo apt-get update sudo apt-get upgrade
Настроим и включим ufw:
sudo ufw allow 22/tcp sudo ufw allow 443/tcp sudo ufw enable
sudo apt-get install stunnel4
- /var/lib/stunnel4 здесь будет chroot окружение
- /etc/stunnel любой файл в этом каталоге оканчивающийся на .conf будет считаться конфигом
- /usr/share/doc/stunnel4/examples с примером конфига внутри
Проведем некоторые подготовительные мероприятия.
Разрешим автозапуск. В файле /etc/default/stunnel4 заменим ENABLED=0 на ENABLED=1:
sudo nano /etc/default/stunnel4
Создадим папки для клиентских сертификатов. certs — разрешенные, crls — запрещенные (отозванные). О самих сертификатах чуть позже.
sudo mkdir /var/lib/stunnel4/certs sudo mkdir /var/lib/stunnel4/crls
Создадим лог-файл и сменим владельца.
Я не считаю размещение логов в месте отличном от /var/log хорошей идеей, но заставить stunnel писать логи за пределы окружения мне не удалось.
sudo touch /var/lib/stunnel4/stunnel.log sudo chown stunnel4:stunnel4 /var/lib/stunnel4/stunnel.log
Я буду использовать свой конфиг, но если он вам не подходит можно взять пример в /usr/share/doc/stunnel4/examples
Создадим конфигурационный файл:
sudo nano /etc/stunnel/stunnel.conf
Со следующим содержимым:
; ************************************************************************** ; * Global options * ; ************************************************************************** ; Каталог chroot окружения. chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 ; Создается в окружении pid = /stunnel4.pid ; Уровень болтливости debug = 7 ; Лог-файл output = /stunnel.log ; Не использовать syslog syslog = no ; ************************************************************************** ; * Service defaults may also be specified in individual service sections * ; ************************************************************************** ; Сертификат/ключ сервера cert = /etc/stunnel/servercert.pem key = /etc/stunnel/serverkey.pem ; Проверка сертификата. 0 — не проверять, 1 — проверять при наличии, 2 — проверять всегда, . verify = 2 ; Каталог для разрешенных сертификатов. ; Находится в окружении.
Для каждого сертификата должна быть хэш-ссылка CApath = /certs ; Каталог для запрещенных (отозванных) сертификатов. ; Находится в окружении. Для каждого сертификата должна быть хэш-ссылка CRLpath = /crls ; Не использвать SSLv2 options = NO_SSLv2 ; ************************************************************************** ; * Service definitions (remove all services for inetd mode) * ; ************************************************************************** [ssh] ; Принимать соединения на интерфейс:порт или просто порт.
stunnel configuration
Например accept = 192.168.0.1:443 accept = 443 ; Отдавать приложению на интерфейс:порт или просто порт. Например connect = 127.0.0.1:22 connect = 22
Ключи и сертификаты
Не большое отступление. В нашем случае stunnel проверяет только корректность пары сертификат/ключ и наличие сертификата в разрешенных или запрещенных.
Самоподписанного сертификата более чем достаточно, и с технической стороны (stunnel) и со стороны поставленной задачи. Нет никакого смысла заморачиваться с собственным CA или с присутствием корневого сертификата в списке доверенных на клиенте или сервере.
Нам нужны пары сертификат/ключ для сервера и каждого клиента.
C помощью openssl создадим пару для сервера:
sudo openssl req -nodes -new -days 365 -newkey rsa:1024 -x509 -keyout serverkey.pem -out servercert.pem
Отвечаем на вопросы:
Generating a 1024 bit RSA private key . ++++++ . ++++++ writing new private key to ‘serverkey.pem’ —— You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank. —— Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:MyProvince Locality Name (eg, city) []:MyCity Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany Organizational Unit Name (eg, section) []:IT dep Common Name (e.g. server FQDN or YOUR name) []:server Email Address []:
И переместим их по назначению:
sudo mv serverkey.pem /etc/stunnel/ sudo mv servercert.pem /etc/stunnel/
Как и где хранить клиентские сертификаты с ключами (за исключением каталогов certs и crls созданных ранее) решать вам. Я просто создам каталог clients в домашней директории своего пользователя и буду хранить их там на первых порах.
Создадим каталог и перейдем в него:
mkdir /home/myuser/clients cd /home/myuser/clients
Создадим пару для клиента:
sudo openssl req -nodes -new -days 365 -newkey rsa:1024 -x509 -keyout clientkey.pem -out clientcert.pem
Как и при создании сертификата для сервера отвечаем на вопросы. Common Name будет другим например client.
Создадим еще одну пару:
sudo openssl req -nodes -new -days 365 -newkey rsa:1024 -x509 -keyout dnclientkey.pem -out dnclientcert.pem
Предположим, что clientcert.pem сертификат клиента которому доступ разрешен, а dnclientcert.pem сертификат клиента которому доступ запрещен. Скопируем сертификаты по нужным директориям.
sudo cp clientcert.pem /var/lib/stunnel4/certs sudo cp dnclientcert.pem /var/lib/stunnel4/crls
Для каждого сертификата нужно создать хэш-ссылки (Возможно «хэш-ссылка» не корректное название, но оно очень точно передает суть). Это можно сделать с помощью утилиты c_rehash из пакета openssl. Мы же создадим небольшой скрипт для этих целей.
nano /home/myuser/certlink.sh
Со следующим содержимым:
Возможно будет более целесообразным разместить certlink.sh где нибудь в /usr/bin. Я пока не стал этого делать. Но выбор за вами.
Дадим права:
chmod +x /home/myuser/certlink.sh
cd /var/lib/stunnel4/certs sudo /home/myuser/certlink.sh clientcert.pem cd /var/lib/stunnel4/crls sudo /home/myuser/certlink.sh dnclientcert.pem
В результате в каталогах у нас должны появится ссылки вида 7469493f.0.
sudo /etc/init.d/stunnel4 start
Stunnel на клиенте
На клиенте будем использовать версию stunnel аналогичную серверной. На сервере у нас 4.53. Забираем с одного из зеркал.
Если прямая ссылка перестанет работать, найти нужную версию можно так:
- Идем на stunnel.org в Downloads;
- В разделе Code Repositories выбираем зеркало и переходим. Например usenix.org.uk;
- Переходим в archive;
- Затем в 4.x;
- Забираем нужную версию.
Редактируем файл stunnel.conf. У меня он имеет следующий вид:
debug = 7 ; Пара сертификат/ключ клиента cert = clientcert.pem key = clientkey.pem verify = 2 ; Сертификат сервера CAfile = servercert.pem options = NO_SSLv2 [ssh] client = yes accept = 127.0.0.1:22 connect = 192.168.0.1:443
Здесь 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, реализовано будет с помощью него. Если материал на эту тему интересен — дайте знать.
- Настройка Linux
- Системное администрирование
- *nix
- Сетевые технологии
Источник: habr.com
Программа stunnel для чего
КЛЮЧЕВОЕ СЛОВО
в защите информации
- О компании
- Контакты
- Схема проезда
- Новости
- Лицензии
- Аккредитация
- Реквизиты
- Вакансии
- КриптоПро CSP
- Использование
- КриптоПро CSP Lite
- КриптоПро TLS c ГОСТ
- КриптоПро Java CSP
- КриптоПро Winlogon
- Считыватели
- История версий
- Сравнение версий
- Совместимость реализаций X.509 и CMS
- Загрузка файлов
- КриптоПро JTLS
- КриптоПро Java CSP
- Загрузка файлов
- Использование
- Информационные материалы
- Мобильные приложения
- Тестовый СЭП
- КриптоПро DSS Lite
- КриптоПро CloudCSP
- Загрузка файлов
- VPN-сервер NGate
- TLS-сервер NGate
- Сервер портального доступа
- IPsec VPN-шлюз NGate
- Общая информация
- Информационные материалы
- Аппаратные платформы
- Загрузка файлов
- КриптоПро УЦ 1.5
- КриптоПро УЦ 2.0
- КриптоПро Службы УЦ
- Задачи
- Развёртывание
- Консалтинг
- Обучение
- Техническая поддержка
- КриптоПро Шлюз УЦ-СМЭВ
- Использование
- Совместимость реализаций IPsec
- Загрузка файлов
- Браузер Chromium-Gost
- КриптоПро ЭЦП Browser plug-in
- Приложение cryptcp
- КриптоПро Office Signature
- КриптоПро PDF
- КриптоПро AirKey
- Защищенная мобильность
- КриптоПро Stunnel
- stunnel-msspi
- КриптоПро SPR 4.0
- Secure Pack Rus (SPR 3.0)
- КриптоПро Шлюз УЦ-СМЭВ
- КриптоПро ЭЦП
- КриптоАРМ ГОСТ
- КриптоПро CRM
- КриптоПро SSF
- КриптоПро HLF
- Электронные замки
- Считыватели смарт-карт
- USB-токены
- Услуги УЦ
- Сервис электронной подписи
- Консалтинг
- CRM решения для УЦ
- Защита информации
- Блокчейн (распределённый реестр)
- Обучение
- Дилеры
- Дистрибьюторы
- Стать дилером
- Вход для дилеров
- Решения партнёров
- Центр загрузки
- Тестовый УЦ
- Портал технической поддержки
- База знаний (FAQ)
- Документация
- Поиск
- Проверка лицензии
- Проверка сведений о лицензии
- Проверка возможности обновления
- Юридические лица
- Форма заказов
- Оплата
- Доставка
- Форма заказов
- Оплата
- Доставка
- Форма заказов
- Доставка
- Оплата
- Условия возврата
- Форма заказов
- Доставка
- Оплата
- Условия возврата
- Order form
- Payment methods
- Delivery
КриптоПро Stunnel
Назначение:
Программа stunnel предназначена для шифрования трафика между произвольным приложением на клиентском компьютере, которое работает с некоторым приложением или службой на удаленном компьютере (сервере).
Возможности:
Шифрование делается между двумя экземплярами программы stunnel (на сервере и на клиенте) без необходимости вносить изменения в работу клиентского или серверного ПО. Кроме шифрования, можно настроить требование аутентификации клиента по сертификату клиента. Входит в состав КриптоПро CSP
Реализуемые алгоритмы:
- ГОСТ 28147-89 (для шифрования),
- ГОСТ Р 34.11-94, ГОСТ Р 34.11-2012, ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012 (для аутентификации).
Источник: crypto-pro.ru
Stunnel — программа для кодирования SSL
Stunnel — это прокси, который позволяет добавлять возможности шифрования TLS к существующим клиентам и серверам без изменения кода программ. Stunnel оптимизирован для переносимости, безопасности и масштабируемости, включая балансировку нагрузки, что делает его подходящим для крупных развертываний.
Помимо прочего, Stunnel также позволяет шифровать электронную почту без функций SSL. После этого пароли больше не отправляются в виде простого текста через Интернет. Однако электронная почта пересылается почтовым сервером в виде обычного текста. Чтобы зашифровать содержимое почты, вам все равно нужно использовать дополнительное программное обеспечение, такое как PGP.
Источник: pcrentgen.ru