Stunnel е SSL прокси (TCP тунелен мениджър), които се състои от две части - клиент и сървър. Страницата на проекта е на адрес:

https://www.stunnel.org

Най-важните характеристики на stunnel са:

• комуникацията между клиента и сървъра е само и единствено TCP-базирана (UDP не се поддържа все още)

• stunnel използва библиотеките на OpenSSL:

  Следодвателно SSL протокола (като версии, използвани шифри и др) се реализира на базата на тези библиотеки, с всички произтичащи от това предимства и недостатъци.

• един stunnel сървърски процес може да поддържа множество TCP тунели

Всички модерни дистрибуции поддържат пакет с дистрибуцията на проекта Stunnel. Този документ се фокусира върху инсталирането и конфигурирането на Stunnel под CentOS 7 и Scientific Linux 7 и интегрирането му с PKI инфраструктурата на проекта УНИТе.

Процесът на stunnel може да бъде конфигуриран да функционира като сървър или клиент:

• сървър:

  Вашият клиентски софтуер се свързва към порта, на който слуша stunnel процеса, използвайки SSL, а от своя страна stunnel процеса се свързва към отдалечен ресурс, от името на вашия клиентски софтуер, без да установява SSL комуникация, от/до ресурса.

• клиент:

  Вашият клиентски софтуер се свързва към порта, на който слуша stunnel процеса, без да използва SSL, а от своя страна stunnel процеса се свързва към отдалечен ресурс, от името на вашия клиентски софтуер, установявайки SSL комуникация, от/до ресурса.

Целта на използването на Stunnel-базирано реверсивно прокси в инфраструктурата на УНИТе е да се предостави, когато е необходимо, достъп до TCP базирани ресурси (като файлови сървъри, iSCSI инициатори и др), на базата на валиден X.509 сертификат, без да се модифицира протокола на услугата, който е обвит в изградения SSL тунел.

Използвайте актуализирана и поддържана версия на CentOS 7 или Scientific Linux 7!

Пакетът stunnel5 е специално изработен по начин, по който да поддържа systemd и едновременното използване на много различни конфигурации (едновремено стартирани процеси на stunnel) в една състема. Освен това, пакетът не интерферира с никой от пакетите (включително пакета stunnel), който се намират в дистрибутивното хранилище на CentOS 7 или Scientific Linux 7.

Инсталирайте пакета за поддръжка на пакетното хранилище на СУ PKI и след това инсталирайте пакета stunnel5:

$ sudo yum install https://pki.uni-sofia.bg/yum/el7/x86_64/Packages/pkisu-release-1.0.0-1.el7.noarch.rpm
$ sudo yum install stunnel5

Стартовата конфигурация на stunnel, която е дадена по-долу, прави възможно stunnel да бъде стартиран като сървър, който проксира SSL трафика (използвайки транспорт по протокол TLS v1.2), идващ на порт 3260/tcp към друга отдалчена системата (без да се използва SSL транспорт), прозрачно за клиентския софтуер:

options = CIPHER_SERVER_PREFERENCE
sslVersion = TLSv1.2
ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
curve = secp521r1

CApath = /etc/stunnel5/CA
CRLpath = /etc/stunnel5/CRL
verify = 2

cert = /etc/pki/tls/certs/stunnel.crt
key = /etc/pki/tls/private/stunnel.key

syslog = no
output = /var/log/stunnel5/iscsi.log

pid = /var/run/stunnel5/iscsi.pid

setuid = stunnel
setgid = stunnel

[iscsi]
client = no
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
accept = 62.44.109.26:3260
accept = 2001:67c:20d0:aafa::26:3260
local = fc00:67c:20d0:bafa::40:3260
connect = fc00:67c:20d0:bafa::41:3260
sessionCachetimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

Ето и описание на декларациите в тази конфигурация:

• options = CIPHER_SERVER_PREFERENCE

  С тази опция правите така, че при договорянето на SSL алгоритмите и параметрите, тези предлагани от сървъра да са с предимство пред тези, предлагани от клиента. Това е важно за предотвратяване на атаки, при които атакуващия може нарочно да накара сървъра да приеме от клиента предложения за шифри, които са слаби и взломяеми.

• sslVersion = TLSv1.2

  Използвайте (когато това е възможно) само протокол TLS 1.2 или по-висока версия (която се очаква скоро да се появи в библиотеките на OpenSSL).

• ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256

  Тази деклрация задава кой набор шифри сървъра да оферира и договаря с клиента. Посочените шифри са "златното сечение" за TLSv1.2. Най-важната част от тях е избрания алгоритъм за обмен на сесиен ключ, който използва елиптични криви (избран е ECDHE, виж също декларацията curve по-долу). Отбележете, че ако искате да използвате Diffie-Hellman алгоритъм, тогава трябва да замените шифрите в декларацията по-горе с DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256 и допълнително да генерирате дълъг Diffie-Hellman ключ, който да поставите последен във файла, посочен с деклрарацията key. Препоръчително е да използвате елиптични криви, ако клиентския софтуер може да работи с тях.

• curve = secp521r1

  Тази деклрация задава коя елиптична крива да се използва при обмен на сесиен ключ за използване в ECDHE. В случай

• CApath = /etc/stunnel5/CA

  В директория /etc/stunnel5/CA трябва да поставите файловете, които съдържат сертификатите, на база на които ще се валидират сертификатите на клиентите. След това трябва да създадете symlink обекти към тези файлове така, че името на обекта да е хешираната стойност на "Subject" полето в сертификата:

  $ sudo su wget https://pki.uni-sofia.bg/crt/SU_ECC_Root_CA.crt -O /etc/stunnel5/CA/SU_ECC_Root_CA.crt
  $ sudo su wget https://pki.uni-sofia.bg/crt/UNITe_ECC_CA.crt -O /etc/stunnel5/CA/UNITe_ECC_CA.crt
  $ sudo su cd /etc/stunnel5/CA && ln -s SU_ECC_Root_CA.crt `openssl x509 -hash -noout -in SU_ECC_Root_CA.crt`.0
  $ sudo su cd /etc/stunnel5/CA && ln -s UNITe_ECC_CA.crt `openssl x509 -hash -noout -in UNITe_ECC_CA.crt`.0

• CRLpath = /etc/stunnel5/CRL

  В директория /etc/stunnel5/CRL трябва да поставите файловете, които съдържат списъците с отменени сертификати (CRL), на база на които ще се валидира моментната валидност на сертификатите на клиентите. След като ги поставите там, трябва да създадете symlink обекти, на базата на които stunnel процеса да може да търси файл по хешираната стойност на "Subject" полето в сертификата на издадетеля:

  $ sudo su wget https://pki.uni-sofia.bg/crl/SU_ECC_Root_CA.crl -O /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin
  $ sudo su wget https://pki.uni-sofia.bg/crt/UNITe_ECC_CA.crl -O /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin
  $ sudo openssl crl -inform DER -in /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin -outform PEM -out /etc/stunnel5/CRL/SU_ECC_Root_CA.crl
  $ sudo openssl crl -inform DER -in /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin -outform PEM -out /etc/stunnel5/CRL/UNITe_ECC_CA.crl
  $ sudo su cd /etc/stunnel5/CRL && ln -s SU_ECC_Root_CA.crl `openssl crl -hash -noout -in SU_ECC_Root_CA.crl`.r0
  $ sudo su cd /etc/stunnel5/CRL && ln -s UNITe_ECC_CA.crl `openssl crl -hash -noout -in UNITe_ECC_CA.crl`.r0
  $ sudo rm -f /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin
  $ sudo rm -f /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin

• verify = 2

  Ако в деклрацията verify е зададено числото 2, това означава, че сървърския stunnel процес ще провери валидността на клиентския сертификат спрямо сертификатите на издателите в директория /etc/stunnel5/CA.

• cert = /etc/pki/tls/certs/stunnel.crt

  /etc/pki/tls/certs/stunnel.crt е файла, който съдържа сървърския X.509 сертификат и сертификатната верига (ако такава има), като всеки сертификат е представен в този файл като PEM блок.

  ВНИМАНИЕ! В този файл първи е сертификата на сървъра.

• key = /etc/pki/tls/private/stunnel.key

  /etc/pki/tls/private/stunnel.key е файла, който съдържа частния ключ към сървърския X.509 сертификат, в PEM формат. Направете така, че да не бъде читаем от всички потребители на системата, но да бъде читаем от потребителя, с чиито права се изпълнява stunnel сървърския процес (ако е инсталиран пакета от хранилището, посочено по-горе, този потребител ще е stunnel):

  $ sudo chmod 600 /etc/pki/tls/private/stunnel.key
  $ sudo chown stunnel:stunnel /etc/pki/tls/private/stunnel.key

• syslog = no

  Тази деклрация прави така, че сървърския процес на stunnel да не описва събитията в syslog (т.е. да не се използват дефинициите в /etc/rsyslog.conf).

• output = /var/log/stunnel5/iscsi.log

  /var/log/stunnel5/iscsi.log е файла, в който се описват събитията, свързани с комуникацията от и до сървърския процес на stunnel.

• pid = /var/run/stunnel5/iscsi.pid

  С тази декларация се задава файла, в който се поставя PID номера (Process ID) на сървърския процес на stunnel, след успешното стартиране на този процес.

• setuid = stunnel

  Тази деклрация задава името на потребителя, с чиито права ще се изпълнява сървърския процес на stunnel.

• setgid = stunnel

  Тази деклрация задава името на групата, с чиито права ще се изпълнява сървърския процес на stunnel.

• деклрация на ресурс

  Декларацията на ресурс, дадена в примера по-горе:

  [iscsi]
  client = no
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  accept = 62.44.109.26:3260
  accept = 2001:67c:20d0:aafa::26:3260
  local = fc00:67c:20d0:bafa::40:3260
  connect = fc00:67c:20d0:bafa::41:3260
  sessionCachetimeout = 600
  sessionCacheSize = 200
  TIMEOUTidle = 600

  прави така, че процеса на stunnel да работи като сървър (client = no) приемайки заявките, идващи до порт 3260/tcp на 62.44.109.26 и 2001:67c:20d0:aafa::26 (тези два IP адреса, указани с декларацията accept трябва да са конфигурирани локално в системата, на някой от мрежовите интерфейси), установявайки SSL сесия с вашия клиентски софтуер и след като тя бъде установена, проксирайки комуникацията между вашия клиент и ресурса, който е достъпен на порт 3260/tcp на адрес fc00:67c:20d0:bafa::41. Т.е. свързвайки се с приложението, което слуша на порт 3260/tcp на 62.44.109.26 и/или 2001:67c:20d0:aafa::26, вие реално се свързвате с приложението, което слуша на порт 3260/tcp на 2001:67c:20d0:bafa::41. Това, което трябва да имате предвид е, че приложението, което слуша на порт 3260/tcp на fc00:67c:20d0:bafa::41 ще вижда вашите заявки идващи не от вашия IP адрес, а от този, който е посочен чрез декларацията local (това е fc00:67c:20d0:bafa::40, той също трябва да е конфигуран локално в системата, в която работи stunnel). Допълнително са добавени декларации за регулиране на ресурсите за всяка сесия sessionCachetimeout, sessionCacheSize, TIMEOUTidle. Стойностите в тези деклрациите трябва да бъдат настроени спрямо потреблението на ресурси и резерва им в системата.

Тази конфигурация трябва да запазите във файл, който да се намира в директория /etc/stunnel5/conf.d. Разширението на файла трябва да е *.conf.

Стартовата конфигурация на stunnel, която е дадена по-долу, прави възможно stunnel да бъде стартиран като локален не-SSL клиент, който проксира трафика, идващ на порт 3260/tcp към друга отдалчена системата, използвайки за този транспорт протокол TLS v1.2, прозрачно за клиентския софтуер (клиентския софтуер не е нужно да има SSL функционалност):

sslVersion = TLSv1.2
ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256

CApath = /etc/stunnel5/CA
CRLpath = /etc/stunnel5/CRL
verify = 2

cert = /etc/pki/tls/certs/client.crt
key = /etc/pki/tls/private/client.key

syslog = no
output = /var/log/stunnel5/iscsi-client.log

pid = /var/run/stunnel5/iscsi-client.pid

setuid = stunnel
setgid = stunnel

[iscsi-client]
client = yes
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
accept = 127.0.0.1:3260
accept = ::1:3260
retry = yes
checkHost = iscsi.services.unite.uni-sofia.bg
connect = iscsi.services.unite.uni-sofia.bg:3260

Повечето от конфигурационните декларации са описани в секцията, в която е описана конфигурацията на сървъра (виж по-горе). По-долу са коментирани само тези от тях, който са специфични за клиента:

• cert = /etc/pki/tls/certs/client.crt

  /etc/pki/tls/certs/client.crt е файла, който съдържа клиентския X.509 сертификат (ако такъв се налага да бъде използван) и сертификатната верига (ако такава има), като всеки сертификат е представен в този файл като PEM блок.

  ВНИМАНИЕ! В този файл първи е сертификата на клиента.

• key = /etc/pki/tls/private/client.key

  /etc/pki/tls/private/client.key е файла, който съдържа частния ключ към клиентския X.509 сертификат, в PEM формат (ако използването на такъв сертификат се налага). Направете така, че да не бъде читаем от всички потребители на системата, но да бъде чутаем от потребителя, с чиито права се изпълнява stunnel сървърския процес (ако е инсталиран пакета от хранилището, посочено по-горе, този потребител ще е stunnel):

  $ sudo chmod 600 /etc/pki/tls/private/client.key
  $ sudo chown stunnel:stunnel /etc/pki/tls/private/client.key

• output = /var/log/stunnel5/iscsi-client.log

  /var/log/stunnel5/iscsi.log е файла, в който се описват събитията, свързани с комуникацията от и до клиентския процес на stunnel.

• pid = /var/run/stunnel5/iscsi-client.pid

  С тази декларация се задава файла, в който се поставя PID номера (Process ID) на клиентския процес на stunnel, след успешното стартиране на този процес.

• деклрация на ресурс

  Декларацията на ресурс, дадена в примера по-горе:

  [iscsi-client]
  client = yes
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  socket = l:TCP_KEEPIDLE=15
  socket = l:TCP_KEEPINTVL=5
  socket = l:TCP_KEEPCNT=5
  accept = 127.0.0.1:3260
  accept = ::1:3260
  retry = yes
  checkHost = iscsi.services.unite.uni-sofia.bg
  connect = iscsi.services.unite.uni-sofia.bg:3260

  прави така, че процеса на stunnel да приема заявките, идващи до порт 3260/tcp на локалния хост (127.0.0.1 и ::1 са съответно IPv4 и IPv6 адресите на локалния хост, указани с декларацията accept, които са конфигурирани на мрежовия интерфейс lo) и да проксира комуникацията към ресурса, който е достъпен на порт 3260/tcp на iscsi.services.unite.uni-sofia.bg. Т.е. свързвайки се с приложението, което слуша на порт 3260/tcp на локалния хост (без да използвате SSL за тази връзка), вие реално се свързвате в SSL тунел (протокол TLS v1.2) към приложението, което слуша на iscsi.services.unite.uni-sofia.bg. Допълнително е добвена деклрация retry, чиято цел е да възстановява SSL тунела, ако поради липса на комуникация TCP сесията, на която той е базиран, се разпадне. Установяването на това дали сесията се е разпаднал, става на база на деклрациите за socket. Също така, stunnel в ролята си на SSL клиент, проверява и валидността на X.509 сертификата на iscsi.services.unite.uni-sofia.bg, относно това дали сървърския X.509 сертификата, който iscsi.services.unite.uni-sofia.bg връща, е наистина издаден за да валидира името на хост "iscsi.services.unite.uni-sofia.bg".

Тази конфигурация трябва да запазите във файл, който да се намира в директория /etc/stunnel5/conf.d. Разширението на файла трябва да е *.conf.

Стартовата конфигурация на stunnel, която е дадена по-долу, прави възможно stunnel да бъде стартиран като локален не-SSL клиент, който проксира трафика, идващ на порт 3260/tcp към друга отдалчена системата, използвайки за този транспорт протокол TLS v1.2, прозрачно за клиентския софтуер (клиентския софтуер не е нужно да има SSL функционалност), без да се налага използването на systemd и без да се налага потребителя, с чиито права се изпълняват процесите на stunnel, да бъде stunnel. Stunnel с тази конфигурация може да бъде стартиран от всеки локален потребител:

sslVersion = TLSv1.2
ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256

CApath = /home/usersname/stunnel5/tls/CA
CRLpath = /home/usersname/stunnel5/tls/CRL
verify = 2

cert = /home/usersname/stunnel5/tls/certs/client.crt
key = /home/usersname/stunnel5/tls/private/client.key

syslog = no
output = /home/usersname/stunnel5/log/iscsi-client.log

pid = /home/usersname/stunnel5/run/iscsi-client.pid

[iscsi-client]
client = yes
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
accept = 127.0.0.1:3260
accept = ::1:3260
retry = yes
checkHost = iscsi.services.unite.uni-sofia.bg
connect = iscsi.services.unite.uni-sofia.bg:3260

Конфигурационните декларации, дадени по-горе описани в секция 3 и секция 4 на този документ.

Тази конфигурация трябва да запазите във файл, който да се намира някъде в домашната директория на потребителя, например /home/username/stunnel5/conf.d. Разширението на файла трябва да е *.conf.

Пакетът stunnel5 включа systemd интеграция. Това означава, че всеки отделен конфигурационен файл в /etc/stunnel5/conf.d може да бъде използван за създаването на отделна сървърска или клиентска услуга, базирана на stunnel. По-долу е описано как става това:

• регистриране на нова услуга:

  Ако конфигурацията за услугата се намира във файла /etc/stunnel5/conf.d/service1.conf, то декларирането на услугата става по следния начин:

  $ sudo systemctl enable stunnel5@service1

  (името на услугата е името на префикса на конфигурационния файл).

• стартиране на услуга:

  Ако услугата service1 е дефинирана на база на конфигурацията, която се намира във файла /etc/stunnel5/conf.d/service1.conf, то стартирането на stunnel процеса, предоставящ услугата, става по следния начин:

  $ sudo systemctl start stunnel5@service1

• сприране на услуга:

  Ако услугата service1 е дефинирана на база на конфигурацията, която се намира във файла /etc/stunnel5/conf.d/service1.conf, то спирането на stunnel процеса, предоставящ услугата, става по следния начин:

  $ sudo systemctl start stunnel5@service1

• препрочитане на стартовата конфигурация на услуга:

  Ако услугата service1 е дефинирана на база на конфигурацията, която се намира във файла /etc/stunnel5/conf.d/service1.conf, за да може stunnel процеса, който вече е стартиран на нейна основа, да прочете евентуалните промени в стартовата конфигурация, направени след последното стартиране/рестартиране на услугата, трябва да изпълните следното:

  $ sudo systemctl reload stunnel5@service1

• проверка на текущия статус на услуга:

  Ако услугата service1 е дефинирана на база на конфигурацията, която се намира във файла /etc/stunnel5/conf.d/service1.conf, то проверката на текущия статус на услугата (например, дали процеса на stunnel работи), става по следния начин:

  $ sudo systemctl status stunnel5@service1

7. Управление на процесите на Stunnel без използване на systemd

8. Актуализация на CRL

$ sudo su wget https://pki.uni-sofia.bg/crl/SU_ECC_Root_CA.crl -O /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin
$ sudo su wget https://pki.uni-sofia.bg/crt/UNITe_ECC_CA.crl -O /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin

$ sudo openssl crl -inform DER -in /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin -outform PEM -out /etc/stunnel5/CRL/SU_ECC_Root_CA.crl
$ sudo openssl crl -inform DER -in /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin -outform PEM -out /etc/stunnel5/CRL/UNITe_ECC_CA.crl

9. Управление на журналните ("log") файлове