 |
|
|
|
Защита сетевых сервисов с помощью stunnel. Часть 3
Защита сетевых сервисов с помощью stunnel Часть 3 Сегодня мы займемся изучением тонкостей работы механизма аутентификации stunnel с помощью SSL-сертификатов. Плюс заодно разберемся, для чего может пригодиться Windows-версия этой программы. Представим, что у нас есть сервер, на котором работает Windows 2000 Advanced Server. Хотелось бы уметь удаленно управлять сервером с двух UNIX-машин. В качестве таковых выступают рабочая станция на основе FreeBSD 5.3 и ноутбук c ALT Linux Master 2.4. Соответственно, машины имеют имена win2000.unreal.net, altlinux.unreal.net, freebsd53. unreal.net и адреса 10.10.21.46, 10.10.21.29, 10.10.21.30. Для решения поставленной задачи можно использовать несколько программ. К примеру, Citrix ICA Client, Radmin, Rdesktop, VNC. Устанавливать и настраивать на сервере Citrix или Terminal Server ради одного человека смысла нет. Radmin для UNIX в природе не существует, значит, опять пришлось бы возиться с каким-либо эмулятором. Решив не плодить сущностей без надобности, я воспользовался последним вариантом в виде VNC, так как бесплатен и существует для всех указанных платформ. Реализаций протокола VNC на свете довольно много. Наиболее известны из них RealVNC, TightVNC, t-VNC и еще несколько клонов. Некоторые, как TightVNC и t-VNC, направлены на минимизацию сетевого трафика, другие же, такие как RealVNC, – на использование шифрования. К сожалению, под Windows RealVNC не бесплатна, поэтому пришлось использовать стандартную свободную реализацию TightVNC без шифрования. Для защиты передаваемых данных, как вы уже, наверно, догадались, будет использоваться stunnel. Займемся установкой нужных пакетов на Windows-сервер. Скачиваем с сайта TightVNC: http://tightvnc.com свежий релиз программы. На момент написания статьи была актуальна версия 1.2.9. Инсталляция достаточно тривиальна: большую часть времени можно просто нажимать кнопку «Далее». Затем нужно убедиться, что был выбран следующий набор компонентов.
Разрешаем стартовать серверу VNC автоматически как системному сервису. После этого получаем предупреждение об отсутствии пароля и на следующем экране вводим его.
По умолчанию VNC ждет соединений на порту 5800 для стандартных клиентов и 5900 для тех, кто использует в качестве клиента браузер. Нажав кнопку «Advanced», получаем следующий диалог, с помощью которого разрешаем входящие соединения только с интерфейса локальной петли.
Таким образом, получается, что на внешнем интерфейсе входящие соединения на порты 5800 и 5900 будет получать stunnel и после расшифровки передавать их на соответствующий порт локальной петли. Теперь уже можно проверить работу VNC c помощью клиента, установленного на локальной машине. Не забываем, что присоединяться надо по адресу 127.0.0.1. Если все работает, переходим к установке stunnel. Сделать это можно двумя путями: либо компилировать пакет из исходных текстов, либо взять уже готовый по адресу: http://stunnel.org/download/binaries.html. Там же не забываем взять реализацию OpenSSL для Windows. Полный пакет OpenSSL нам не нужен, необходимы лишь библиотеки libeay32.dll и libssl32.dll, скачать их можно на той же странице. Нормальным инсталлятором stunnel так до сих пор и не обзавелся, поэтому приходится делать все вручную. Кладем stunnel-4.05.exe в C:Stunnel и добавляем туда же весь OpenSSL или скачанные dll. Затем создаем директорию C:Stunnelcerts. На этом процедуру установки для Windows можно считать законченной. Осталось лишь настроить stunnel, но об этом позже. Установку 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, дабы не набирать нижеприведенные данные каждый раз заново при создании сертификата. countryName_default = RU stateOrProvinceName_default = Rostov region localityName = Rostov-on-Don 0.organizationName_default = Tigrisha Home emailAddress = tigrisha@unreal.net Во FreeBSD openssl.cnf находится в /usr/local/openssl/, а под ALT Linux соответственно в /var/lib/ssl/. Начнем с FreeBSD. Переходим в любую удобную директорию и выполняем команды: # openssl req -nodes -new -days 365 -newkey rsa:1024 -x509 -keyout win2000key.pem -out win2000cert.pem # openssl req -nodes -new -days 365 -newkey rsa:1024 -x509 -keyout altlinuxkey.pem -out altlinuxcert.pem # openssl req -nodes -new -days 365 -newkey rsa:1024 -x509 -keyout freebsdkey.pem -out freebsdcert.pem Большинство полей в сертификате совпадают с нашими значениями по умолчанию, во время генерации сертификатов нам просто нужно нажимать «Enter». Единственное, что нужно менять, – это поле CN (Common name). Заполнять его нужно в соответствии с полным доменным именем компьютера, для которого предназначается сертификат. Таким образом, мы создали пару сертификат-ключ для всех наших машин. Теперь ключ лежит в файле с суффиксом key, а сертификат соответственно в файле с суффиксом cert. В ALT Linux все вышеприведенные команды будут иметь тот же эффект. Хотя для этой системы есть и другой способ. Чтобы изучить его, переходим в /var/lib/ssl/certs/ и выполняем команды: # make win2000.pem # make altlinux.pem # make freebsd.pem Это способ не столь удобен, как предыдущий, и требует больше ручного труда. Дело в том, что теперь ключ и сертификат каждой машины лежат вместе в одном файле. Следовательно, придется вручную разносить их по отдельным файлам. Для того чтобы системы, соединенные с помощью stunnel, могли провести аутентификацию, они должны доверять публичным сертификатам друг друга. Соответственно клиенты должны доверять сертификату сервера и наоборот. Давайте изготовим файл с доверенными сертификатами для машины win2000. Для этого объединяем сертификаты altlinuxcert.pem и freebsdcert.pem в файл trusted.pem. # cat altlinuxcert.pem freebsdcert.pem > trusted.pem Переносим файлы win2000key.pem, win2000cert.pem и trusted.pem на Windows-машину и кладем в директорию C:Stunnelcerts. Таким же образом на FreeBSD копируем файлы freebsd-key.pem и freebsdcert.pem, а на Linux, соответственно, altlinuxkey.pem altlinuxcert.pem. Для клиентов в качестве файла с сертификатом доверия выступает win2000cert.pem, поэтому обязательно отправляем его на обе машины и для единообразия переименовываем в trusted.pem. Также не забываем на клиентских машинах положить файлы ключа и сертификатов в /usr/local/etc/stunnel/certs/. Стоит обратить внимание на то, что vnc может работать либо самостоятельно, либо как подключаемый модуль веб-браузера. В первом случае нужно проводить аутентификацию и шифровать трафик, а во втором случае будет доступно только шифрование, потому что непонятно, как клиентский браузер сможет предъявить свой сертификат серверу. Отсюда делаем вывод, что на машине с Windows должно работать два независимых демона stunnel. Один с авторизацией, другой – без. Теперь пришло время создать конфигурационные файлы. Для Windows содержимое vnc_server.cnf выглядит так: cert = C:\stunnel\certs\win2000cert.pem key = C:\stunnel\certs\win2000key.pem CAFile = C:\stunnel\certs\trusted.pem CRLfile = C:\stunnel\certs\crl.pem debug = 7 output = C:\stunnel\stunnel.log verify = 3 [vnc] accept = 10.10.21.46:5800 connect = 127.0.0.1:5800 Конфигурация второго экземпляра stunnel, хранящаяся в vnc_server1.cnf, соответственно такова: [vnc-https] cert = C:\stunnel\certs\win2000cert.pem key = C:\stunnel\certs\win2000key.pem debug = 7 output = C:\stunnel\stunnel.log accept = 10.10.21.46:5900 connect = 127.0.0.1:5900 Теперь посмотрим, на что похожа конфигурация для FreeBSD. cert = /usr/local/etc/stunnel/certs/freebsdcert.pem key = /usr/local/etc/stunnel/certs/freebsdkey.pem CAFile = /usr/local/etc/stunnel/certs/trusted.pem CRLfile = /usr/local/etc/stunnel/certs/crl.pem chroot = /var/tmp/stunnel/ pid = /stunnel.pid setuid = stunnel setgid = stunnel debug = 7 output = /var/log/stunnel.log client = yes verify = 3 [vnc] accept = 127.0.0.1:5800 connect = 10.10.21.46:5800 Конфигурационный файл для ALT Linux выглядит так: cert = /usr/local/etc/stunnel/certs/altlinuxcert.pem key = /usr/local/etc/stunnel/certs/altlinuxkey.pem CAFile = /usr/local/etc/stunnel/certs/trusted.pem CRLfile = /usr/local/etc/stunnel/certs/crl.pem chroot = /var/tmp/stunnel/ pid = /stunnel.pid setuid = stunnel setgid = stunnel debug = 7 output = /var/log/stunnel.log client = yes verify = 3 [vnc] accept = 127.0.0.1:5800 connect = 10.10.21.46:5800 На этом можно остановиться. Перед запуском стоит обсудить особенности конфигурационных файлов, с которыми мы еще не сталкивались. CAFile – указывает, в каком файле хранятся доверенные сертификаты. CRLfile – описывает имя файла, где должны находиться отозванные сертификаты. Такая возможность полезна, к примеру, если сертификат клиента каким-либо образом попал к злоумышленнику, и теперь нам нужно заблокировать его. И, наконец, самая важная опция – verify. Она определяет, каким образом при начале соединения будут проверяться сертификаты клиента и сервера. Значением переменной должно быть число от 0 до 3. Давайте посмотрим, что значит каждое из них.
Итак, разобравшись с опциями, запускаем stunnel на всех машинах и смотрим, что появляется в файлах stunnel.log под Windows.
Ну а для Linux записи в файле протокола должны выглядеть примерно так:
Думаю, всем понятно, что в протоколах системы FreeBSD будет написано примерно то же, что хранится в протоколах системы Linux. Особое внимание стоит обратить на сообщения о считывании файлов сертификатов. Теперь нужно попробовать присоединиться к серверу Windows с любой из клиентских машин с помощью программы vncviewer. Все должно пройти как по маслу. А в файлах протоколов соответственно появится что-то вроде:
Особое внимание стоит обратить на строчку со следующими символами:
Четко видно, как сертификат сервера был опознан клиентом. Соответственно, в протоколах сервера можно увидеть:
Стоит отметить, что в случае, если файл crl.pem не будет содержать сертификатов, stunnel не запустится. Все, что мы получим, – это вот такое сообщение об ошибке:
Поэтому включайте возможность отзыва сертификатов только в том случае, если она действительно необходима. Разобравшись с авторизацией, давайте посмотрим на еще один способ создания сертификатов клиента и сервера. В составе пакета OpenSSL версий выше 0.9.6 поставляется утилита CA.pl, с помощью которой генерирование сертификатов превращается из нелегкого труда по запоминанию длинных команд в забаву. На этот раз мы поступим в соответствии со всеми правилами. Сначала создадим корневой сертификат для unreal.net, а потом с помощью него заверим все клиентские сертификаты. # /var/lib/ssl/misc/CA.pl –newca
В результате этих действий в файле cakey.pem появится секретный ключ, а в cacert.pem наш корневой сертификат. Затем создаем запрос на новый клиентский сертификат для машины altlinux.unreal.net. # /var/lib/ssl/misc/CA.pl –newreq
После этого во вновь созданном файле newreq.pem будет находиться секретный ключ клиента и запрос на создание сертификата. Осталось только заверить его с помощью корневого сертификата, сгенерировав таким образом новый клиентский сертификат. # /var/lib/ssl/misc/CA.pl –sign
После всех этих мытарств сертификат клиента находится в файле newcert.pem. Повторяем эти шаги для остальных клиентов. При этом не стоит забывать, что в файлы newcert.pem и newreq.pem перезаписываются при каждом запуске CA.pl c ключами -sign и -newreq, отсюда следует, что после завершения цикла генерации ключа и сертификата лучше переименовывать эти файлы так, чтобы своим именем они отражали принадлежность тому или иному клиенту. К примеру, для клиента altlinux.unreal.net файлы должны называться altlinuxcert.pem и altlinuxkey.pem. Еще одно обстоятельство, о котором стоит помнить, – из файла newreq.pem после заверения сертификата лучше всего удалять запрос на сертификацию. Он начинается строкой -------BEGIN CERTIFICATE REQUEST--------- и заканчивается, соответственно ----END CERTIFICATE REQUEST----- Если этого не сделать, то некоторые версии stunnel завершаются с ошибкой при попытке работы с таким файлом. Итак, мы создали все необходимые сертификаты и поместили их в trusted.pem. Конечно, не стоит забывать, что файл trusted.pem должен быть разным для клиентов и сервера. В остальном этот способ полностью совпадает с тем, что мы протестировали выше. Вручную добавлять сертификаты в trusted.pem довольно просто, а вот удалять их потом оттуда в случае, если хочется отказать какому-либо клиенту в доступе, несколько неудобно. В системах с малым количеством клиентов это еще терпимо, а в большом вычислительном комплексе с несколькими сотнями сертификатов это может превратиться в головную боль. Поэтому давайте рассмотрим другой способ управления сертификатами. В этом случае мы будем помещать каждый сертификат в отдельный файл. Затем доверенные сертификаты кладем в директорию trusted, а отозванные – в папку crl. На клиентах и сервере создаем обе папки внутри директории certs. Затем вносим следующие изменения в конфигурационные файлы. Вместо строк CAFile и CRLfile вписываем следующее: Для ALT Linux: CRLpath = /usr/local/etc/stunnel/certs/trusted/ CApath = /usr/local/etc/stunnel/certs/crl/ Для FreeBSD вносим те же изменения, что и для ALT Linux. Для Windows: CRLpath = C:stunnelcertscrl CApath = C:stunnelcerts rusted Если опираться в своих действиях на официальную документацию к stunnel, то, сложив все доверенные сертификаты в папку trusted, можно было бы попытаться запустить демонов на сервере и клиентах и радоваться полученному результату. Но не тут то было – запуск пройдет гладко, а вот аутентификация функционировать не будет. По крайней мере, у меня таким способом вообще ничего не заработало. Все дело в том, что для совместимости со специфическими особенностями stunnel имена файлов доверенных сертификатов должны быть в особом формате. А точнее имя файла должно соответствовать хэшу, вычисленному по содержимому сертификата. Чтобы узнать хэш того или иного файла под ALT Linux, нужно выполнить следующую команду: # /var/lib/ssl/misc/c_hash / /usr/local/etc/stunnel/certs/trusted/*.pem
Таким образом, становится понятно, что файл сертификата win2000cert.pem нужно переименовать в b71698b3.0. После того как вы проведете подобные действия на остальных машинах, можно запускать stunnel. Стоит отметить, что во FreeBSD утилита c_hash будет находиться в директории /usr/local/openssl/misc. Также необходимо обратить внимание на тот факт, что для Windows в стандартной поставке openssl программа c_hash отсутствует. Поэтому хэши ключей нужно будет вычислять на Linux или FreeBSD. Единственное различие будет в том, что в файл протокола при старте записываются следующие сообщения, касающиеся доверенных сертификатов.
В остальном работа системы будет выглядеть точно так же, как если бы доверенные сертификаты хранились в одном файле. Думаю, на этом можно считать тему аутентификации клиентов stunnel с помощью сертификатов исчерпанной. А значит, подошла к концу и эта серия статей. |
АНДРЕЙ БЕШКОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
