Защита сетевых сервисов с помощью stunnel

АНДРЕЙ БЕШКОВ

Защита сетевых сервисов с помощью stunnel

Инциденты с безопасностью были и, видимо, будут всегда. Не последнюю роль в этом играет изначально ошибочный дизайн многих сетевых протоколов. Большинство из них передают и принимают данные либо в открытом виде, либо с минимальным шифрованием. Криптография не стоит на месте, и постепенно некоторые протоколы обзаводятся функциями, реализующими стойкое шифрование, но, к сожалению, процесс этот идет не слишком быстро. Для подавляющего большинства разработчиков программного обеспечения вопросы безопасности создаваемого продукта стоят далеко не на первом месте. Обычно все делается по принципу «лишь бы приложение хоть как-то заработало», а потом мы уже исправим все недочеты. Обычно это «потом» растягивается на годы. И чаще всего для внедрения в уже работающий программный комплекс механизмов безопасности необходимо достаточно сильно менять не только код, но и многие идеи, лежащие в основе всего дизайна. Не каждый производитель программного обеспечения с радостью пойдет на дополнительные трудозатраты.

Благодаря инициативе компании Netscape стандартом де факто для задач шифрования веб-коммуникаций стал SSL (Security Socket Layer). Первоначально он применялся для защиты данных, передаваемых с помощью HTTP. Годы активного использования в сфере веб-коммерции доказали стабильность и надежность этого решения. Таким образом, возникла защищенная версия протокола HTTP, в дальнейшем получившая название HTTPS. Вслед за этим появились протоколы IMAPS, POP3S, SMTPS, NNTPS, LDAPS. Они призваны со временем заменить своих небезопасных предков.

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

Как я говорил ранее, переделка обычной программы в SSL-версию – уже нетривиальный процесс, но на этом трудности не заканчиваются. К сожалению, настройка и установка на сервере программного обеспечения, реализующего защищенные версии протоколов, упомянутых выше, часто тоже довольно непроста. Кроме этого, иногда встречаются ситуации, когда производитель того или иного серверного или клиентского обеспечения, работающего с небезопасными протоколами, канул в Лету, не успев создать защищенных версий своих программ и оборудования. За право пользования этими разработками когда-то были заплачены лицензионные отчисления и, соответственно, отказаться от работы с ними экономически невыгодно. Иногда это сделать вообще невозможно по причине того, что ни одно из решений, предлагаемых сторонними поставщиками, не реализует нужные функции. Но чаще всего складывается ситуация, когда безопасные приложения от нового поставщика не удается встроить в устаревшее оборудование и программные среды, до сих пор используемые во многих производственных процессах и служащие нам верой и правдой.

Таким образом, мы незаметно подошли к предмету нашей сегодняшней беседы. Говорить мы будем о программе Stunnel, которая позволяет защитить небезопасные сервисы. Механика действия довольно проста. Stunnel позволяет шифровать любое TCP-соединение с помощью SSL. При этом ни отправитель, ни получатель не подозревают о том, что трафик в процессе передачи по сети шифруется с помощью внешней программы.

Программа работает на следующих операционных системах:

• FreeBSD
• NetBSD
• OpenBSD
• GNU/Linux
• AmigaOS
• BeOS
• IBM AIX
• Mac OS X
• OpenVMS
• HP NonStop™ Kernel
• HP-UX
• Plan 9
• QNX
• SCO OpenServer
• SGI IRIX
• Solaris
• Tru64, он же Digital Unix, он же DEC OSF/1
• Windows 95/98/ME/NT/2000/XP

Итак, рассмотрим пример превращения небезопасных сервисов pop3, imap, smtp в их безопасные аналоги IMAPS, POP3S, SMTPS. Представим, что у нас есть сервер, функционирующий под управлением FreeBSD 4.10. Он называется freebsd410.unreal.net и доступен нашему клиенту по адресу 10.10.21.134. Кроме всего прочего, на нем работают программы dkimap, postfix, cucipop, которые и реализуют ту самую «святую троицу» протоколов. Все они принимают входящие соединения на любом сетевом интерфейсе. Postfix работает как резидентный демон, а остальные демоны запускаются с помощью inetd, как только кто-нибудь попытается присоединиться к нужным портам. Соответственно, в /etc/inetdd.conf присутствуют следующие строки:

pop3    stream  tcp     nowait  root    /usr/local/libexec/cucipop cucipop -Y

imap    stream  tcp     nowait  root    /usr/local/libexec/dkimap4 dkimap

Таким образом, картина, показываемая командой:

# netstat -na | grep LISTEN

выглядит следующим образом:

Демоны ждут входящих соединений на портах 25, 110, 143. Что означают эти номера, можно узнать, пролистав файл /etc/services. Кстати, стоит убедиться, что в этом же файле есть записи, описывающие наши будущие защищенные сервисы:

imaps      993/tcp             # imap4 protocol over TLS/SSL

imaps      993/udp

pop3s      95/tcp  spop3       # pop3 protocol over TLS/SSL

pop3s      995/udp spop3

smtps      465/tcp             # smtp protocol over TLS/SSL (was ssmtp)

smtps      465/udp   

Объяснить, как все происходит, довольно просто. На схеме изображена типичная картина сетевого взаимодействия клиента и почтового сервера.

При отправке сообщений почтовый клиент, умеющий работать с SSL, шифрует пакеты и передает их демону stunnel. Тот в свою очередь расшифровывает их и отдает демонам imap, pop3, smtp. А почтовые демоны в ответ на запросы отдают данные в открытом виде stunnel, который шифрует их и передает клиенту. При этом ни клиент, ни демоны не догадываются о том, что общаются друг с другом через посредника.

Итак, приступаем к установке stunnel на сервер.

Предварительно в систему должен быть проинсталлирован OpenSSL, так как для правильного функционирования stunnel требуются криптоалгоритмы, реализуемые именно этой библиотекой. Для FreeBSD проводить инсталляцию удобнее всего из портов.

# cd /usr/ports/security/stunnel

# make all install

По окончании сборки будет автоматически создан поль-зователь stunnel, входящий в одноименную группу. Затем произойдет установка, и нам будет доступен stunnel версии 4.04. Сразу же после этого система начнет создавать секретный ключ и сертификат. Вы можете воспользоваться этим способом и начать отвечать на задаваемые вопросы или просто нажимать Enter и впоследствии самостоятельно создать нужные файлы. Я предпочитаю второй способ. Создаем директорию, где у нас будут храниться сертификаты и ключи.

# mkdir /usr/local/etc/stunnel/certs

# cd /usr/local/etc/stunnel/certs

Самостоятельно создаем ключи и сертификаты со сроком действия 1 год. В связи с тем, что stunnel не умеет работать с ключами, защищенными паролями, используем опцию -nodes.

# openssl req -new -x509 -days 365 -nodes -out mailserver.cert -keyout mailserver.key

Обратите внимание, что для заполнения поля Common Name или CN было использовано DNS-имя сервера. Это обязательно нужно делать, иначе почтовый клиент будет постоянно возмущаться несовпадением фактического имени сервера и того, что записано в недрах сертификата. Также необходимо убедиться, что на клиентском компьютере правильно работает разрешение имени freebsd410. unreal.net.

Покончив с предыдущим пунктом, устанавливаем правильные права доступа к файлам.

# chmod 600 ./mailserver.cert ./mailserver.key

Создаем директорию, куда демон перейдет в chroot:

# mkdir /var/tmp/stunnel

# chown stunnel:stunnel /var/tmp/stunnel

# chmod 700 /var/tmp/stunnel

При запуске без параметров stunnel будет использовать файл конфигурации /usr/local/etc/stunnel/stunnel.conf. Записываем в него следующие строки:

# Ключи и сертификаты

cert = /usr/local/etc/stunnel/certs/mailserver.cert

key = /usr/local/etc/stunnel/certs/mailserver.key

# Директория, внутри которой будет работать демон

chroot = /var/tmp/stunnel

# Файл pid. pid = /stunnel.pid

# Имя пользователя и группа, с чьими правами будет работать демон

setuid = stunnel

setgid = stunnel

# Уровень подробности отладочных сообщений

debug = 7

# Имя файла протоколирования

output = /var/log/stunnel.log

# Описание наших сервисов

[pop3s]

accept  = 10.10.21.134:995

connect = 110

[imaps]

accept  = 993

connect = 143

[ssmtp]

accept  = 465

connect = 127.0.0.1:25

В описании сервисов стоит обратить особое внимание на ключевые слова accept и connect. Первое описывает адрес и порт, через который к нам и от нас будут идти зашифрованные данные, а второе, соответственно, адрес и порт для обмена расшифрованными данными с демонами. Описание обоих переменных может быть в нескольких форматах.

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

Запускаем stunnel и смотрим, что демон пишет в /var/log/stunnel.log. Должны увидеть что-то подобное:

Теперь нужно снова посмотреть, что нам скажет команда:

# netstat -na | grep LISTEN

Как видите, список портов, ожидающих входящие соединения, существенно увеличился.

Самое время настроить почтовый клиент. В качестве подопытного кролика будет использоваться Microsoft Outlook Express 6. Первым делом будут не самолеты, о которых подумали поклонники советской эстрады, а копирование сертификата с почтового сервера и импортирование его в почтовый клиент. С первым заданием, я думаю, вы и сами справитесь. Подойдет любой способ, лишь бы файл mailserver.cert оказался на Windows-машине. В Outlook Express задействуем меню «Сервис –> Параметры», затем выбираем вкладку «Безопасность», незамедлительно жмем на кнопки «Сертификаты» и «Импортировать» и делаем все, как на следующих снимках.

После этого в списке доверенных центров сертификации должно появиться имя нашего сервера.

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

После этого вся принимаемая и отправляемая почта будет шифроваться с помощью SSL, а в файле /var/log/stunnel.log будут появляться подобные надписи:

Для того чтобы забирать письма с сервера, в данном примере использовался POP3S, но смею вас уверить, что IMAPS будет также надежно выполнять эту задачу. Вдоволь наигравшись с Outlook Express, я принялся тестировать все почтовые клиенты, что были под рукой. Поэтому могу смело заявить: как и ожидалось, Mozilla Thunderbird 0.6 и Ximian Evolution 2.0.2 работают с SSL вполне стабильно и быстро. Единственное нарекание стоит адресовать Kmail 1.7.1, который при использовании защищенных протоколов стал шевелиться в несколько раз медленнее, чем обычно. В частности, на получение тестового письма из 500 байт у него в среднем уходило примерно 45 секунд.

The Bat, любимый многими на постсоветских просторах, тоже отлично работает в наших условиях. Тесты, описанные ниже, проводились на версии 3.0.1.33. Впрочем, думаю, что с большинством версий The Bat это тоже будет работать. Итак, для того чтобы включить ночного вампира в нашу связку, нужно установить все так же, как изображено на следующем снимке. Удивляться тому, что вместо SSL приходится выбирать TLS, не стоит. Главное, что такой подход работает.

При первой попытке соединения с сервером получаем следующее предупреждение. За исключением опечаток все в нем выглядит неплохо.

Первым делом жмем «Просмотреть сертификат». И убеждаемся в том, что он действительно принадлежит нам.

С помощью кнопки «Добавить к доверенным» завершаем процедуру.

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

Итак, мы добились того, что данные нормально передаются по сети в защищенном виде. Теперь осталось сделать так, чтобы никто, кроме stunnel, не смог воспользоваться старыми версиями наших сервисов. Для этого нужно, чтобы стандартные демоны SMTP, POP3, IMAP принимали соединения только от 127.0.0.1. Соответственно, клиенты смогут работать с сервером только через stunnel. В случае c postfix все довольно просто: необходимо всего лишь установить переменную inet_interfaces = localhost в файле main.cf и перезапустить его. А вот с cucipop и dkimap4 есть два варианта решения проблемы. Первый – запретить входящие соединения с помощью межсетевого экрана. Второй – использовать tcp wrapper. О первом способе написано достаточно много статей, поэтому давайте посмотрим, как работать с tcp wrapper. При обнаружении нового входящего соединения inetd вызывает демона tcpd. Тот в свою очередь просматривает файл /etc/host.allow и в зависимости от адреса вызывающей стороны принимает решение о том, что делать с соединением. Если соединение проходит через этот контроль, то его передают демону, который будет в дальнейшем его обслуживать. В отличие от межсетевого экрана, который для принятия решений оперирует адресами и номерами портов, tcpd работает с адресами клиентов и именами вызываемых демонов. По умолчанию в /etc/hosts.allow описано разрешение принимать данные от любых хостов. Это нам не подходит, а значит, надо удалить или закомментировать строку ALL : ALL : allow и добавить в файл вот это:

cucipop : localhost 127.0.0.1 : allow

dkimap : localhost 127.0.0.1 : allow

После внесения изменений все должно работать как часы. Впрочем, для достижения наилучшего эффекта никто не мешает комбинировать настройки tcpd и запреты пакетов на межсетевом экране. После всех действий данные, выдаваемые netstat, должны выглядеть так:

После некоторого количества тестов можно понижать уровень подробности отладочных сообщений, описываемый переменной debug в файле /usr/local/etc/stunnel/stunnel.conf. Приемлемым значением будет цифра 3.

Кстати, если нужно, чтобы stunnel автоматически запускался после перезагрузки машины, не забудьте переименовать /usr/local/etc/rc.d/stunnel.sh.sample в /usr/local/etc/rc.d/stunnel.sh. В случае, когда у нас есть клиент, способный самостоятельно работать с SSL, все выглядит довольно просто. А вот что делать, если такового нет? Этот и многие другие вопросы мы обсудим в следующей статье.