Защита сетевых сервисов, шифрованием с помощью stunnel. Часть 3

Установку stunnel и OpenSSL для FreeBSD и Linux мы обсуждали в первой и второй частях этой статьи, поэтому останавливаться на данном вопросе не будем. Теперь нужно поставить VNC. Для FreeBSD устанавливаем tightVNC стандартным способом из портов. К сожалению, в репозитарии пакетов ALT Linux пакет tightVNC отсутствует, поэтому ставим стандартный VNC, они все равно совместимы между собой.

Пришло время создать SSL-сертификаты, с помощью которых мы будем проводить взаимную аутентификацию клиентов и сервера. Это можно сделать на любой из используемых нами платформ. Но все же стоит отметить, что под Windows выполнять подобные действия неудобно из-за бедности функционала, портированного OpenSSL.

Для остальных обсуждаемых в этой статье систем процедура практически одинакова, все отличия обычно состоят в именах директорий, используемых во время работы. FreeBSD хранит исполняемый файл openssl в /usr/local/bin/openssl, а ALT Linux – в /usr/bin/openssl. Плюс к этому вспомогательный скрипт CA.pl, представляющий для нас особую важность, в первом случае лежит в директории /usr/local/openssl/misc, а во втором – внутри /var/lib/ssl/misc. Впрочем, не стоит переживать: я обязательно подробно опишу всю процедуру генерации сертификатов для обеих систем.

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

Для начала исправляем файл openssl.cnf, дабы не набирать нижеприведенные данные каждый раз заново при создании сертификата.

Во FreeBSD openssl.cnf находится в /usr/local/openssl/, а под ALT Linux соответственно в /var/lib/ssl/.

Начнем с FreeBSD. Переходим в любую удобную директорию и выполняем команды:

Большинство полей в сертификате совпадают с нашими значениями по умолчанию, во время генерации сертификатов нам просто нужно нажимать «Enter». Единственное, что нужно менять, – это поле CN (Common name). Заполнять его нужно в соответствии с полным доменным именем компьютера, для которого предназначается сертификат.

Таким образом, мы создали пару сертификат-ключ для всех наших машин. Теперь ключ лежит в файле с суффиксом key, а сертификат соответственно в файле с суффиксом cert. В ALT Linux все вышеприведенные команды будут иметь тот же эффект. Хотя для этой системы есть и другой способ. Чтобы изучить его, переходим в /var/lib/ssl/certs/ и выполняем команды:

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

Для того чтобы системы, соединенные с помощью stunnel, могли провести аутентификацию, они должны доверять публичным сертификатам друг друга. Соответственно клиенты должны доверять сертификату сервера и наоборот. Давайте изготовим файл с доверенными сертификатами для машины win2000. Для этого объединяем сертификаты altlinuxcert.pem и freebsdcert.pem в файл trusted.pem.

# cat altlinuxcert.pem freebsdcert.pem > trusted.pem

Переносим файлы win2000key.pem, win2000cert.pem и trusted.pem на Windows-машину и кладем в директорию C:\Stunnel\certs\.

Таким же образом на FreeBSD копируем файлы freebsd-key.pem и freebsdcert.pem, а на Linux, соответственно, altlinuxkey.pem altlinuxcert.pem. Для клиентов в качестве файла с сертификатом доверия выступает win2000cert.pem, поэтому обязательно отправляем его на обе машины и для единообразия переименовываем в trusted.pem. Также не забываем на клиентских машинах положить файлы ключа и сертификатов в /usr/local/etc/stunnel/certs/.

Стоит обратить внимание на то, что vnc может работать либо самостоятельно, либо как подключаемый модуль веб-браузера. В первом случае нужно проводить аутентификацию и шифровать трафик, а во втором случае будет доступно только шифрование, потому что непонятно, как клиентский браузер сможет предъявить свой сертификат серверу. Отсюда делаем вывод, что на машине с Windows должно работать два независимых демона stunnel. Один с авторизацией, другой – без.