Пользователь
20 февраля 2012 в 14:05

Разработка → Защита RDP по ГОСТ с помощью Рутокен ЭЦП. Двухуровневый TLS

image

Протокол RDP является протоколом прикладного уровня и поэтому для его защиты идеально подходит TLS, который работает над транспортным уровнем.

В данном топике с помощью open source приложений OpenSSL и sTunnel мы защитим RDP-соединения по протоколу TLS c поддержкой российских шифрсьютов (GOST2001-GOST89-GOST89), клиентская аутентификация по ГОСТ-вым сертификатам будет проводиться аппаратно на борту USB-токена Рутокен ЭЦП с выработкой ключа согласования по схеме VKO GOST 34-10.2001. При этом ключ аутентификации является неизвлекаемым и его невозможно украсть. Так же Рутокен ЭЦП будет использоваться в качестве аппаратного ДСЧ.

Для случая аутентификации на терминальном сервере об Active Directory по сертификатам RSA мы обернем TLS по RSA в TLS по ГОСТ. Таким образом, мы получим двухуровневый TLS — RSA с клиентской аутентификацией будет идти внутри канала, защищенного ГОСТами.



В OpenSSL имеется реализация шифрсьютов TLS на базе российских алгоритмов в соответствии с draft-chudov-cryptopro-cptls.

sTunnel представляет собой компактный TLS-прокси: принимает незащищенные TCP-соединения на вход, TLS-зирует их и форвардит на удаленный сервер. В качестве «криптографического ядра» stunnel использует OpenSSL.

sTunnel из «коробки» не умеет работать с ГОСТами, поэтому я его пропатчил и пересобрал. Патч размером примерно в 2 строчки.

Рутокен ЭЦП подключается к OpenSSL способом, описанным на форуме вендора forum.rutoken.ru/topic/1639. При этом используется аппаратная реализация российских криптоалгоритмов «на борту» Рутокен ЭЦП.

Защита по ГОСТам



Базовая схема представлена на рисунке.

image

Для начала надо сделать небольшой УЦ, который бы выдавал ГОСТовые сертификаты серверу sTunnel и клиентам sTunnel. Для этого имеет смысл воспользоваться OpenSSL. Генерация клиентских ключей на токене, формирование заявок на сертификаты описаны в статье habrahabr.ru/blogs/infosecurity/134725. Ключ и сертификат сервера имеет смысл делать в виде обычных файлов.

Подробно на этой теме я не буду останавливаться.

Настройка сервера:

Инсталлируем sTunnel как службу на виндовый сервер с поднятым терминальным сервером и конфигурируем его:
  • скачиваем и распаковываем архив ubuntuone.com/4zOP5AR39vKxk0uF6rwxNM
  • говорим stunnel -install (при этом stunnel регистрируется как служба)
  • устанавливаем системную переменную окружения OPENSSL_ENGINES=[путь к папке, в которую распаковали архив]
  • подкладываем sTunnel сертификат УЦ, сертификат и ключ сервера (в соответствии с конфигом)
  • подкладываем конфиг (я его сохранил в файл stunnel.conf и положил рядом c sTunnel.exe)
  • перезагружаем компьютер

Конфиг сервера:
verify = 2

cafile = crypto/ca.crt
cert = crypto/server.crt
key = crypto/server.key

engine=gost

socket = l:TCP_NODELAY=1 
socket = r:TCP_NODELAY=1 

debug = 7 
output = stunnel.log 

client = no 

[RDP-TLS-GOST] 
ciphers = GOST2001-GOST89-GOST89
accept = 1494 
connect = localhost:3389 


Не забудьте на сервере закрыть файрволлом 3389 порт IP-адреса, торчащего наружу!

Настройка клиента (на винде):
  • скачиваем и распаковываем архив ubuntuone.com/5D4sNc9i29MDgdW9KvROZa
  • подкладываем сертификат клиента и сертификат УЦ (ключ клиента на токене)
  • устанавливаем для пользователя переменную окружения OPENSSL_ENGINES=[путь к папке, в которую распаковали архив]
  • подкладываем конфиг


Конфиг клиента:
verify=2
client=yes

CAFile=ca.crt

output=stunnel.log
sslVersion=TLSv1
taskbar=yes
DEBUG=7

engine=pkcs11_gost
engineCtrl=MODULE_PATH:rtPKCS11ECP.dll
engineCtrl=INIT 
engineCtrl=PIN:12345678

[RDP-TLS-GOST]
engineNum=1
key=100
cert=client.crt
accept = 127.0.0.1:8088
connect = x.x.x.x:1494
ciphers = GOST2001-GOST89-GOST89
TIMEOUTclose = 1



Важный момент. sTunnel не требует установки с правами администратора. Вообще говоря его можно использовать совместно с Рутокен ЭЦП Flash.
Рутокен ЭЦП Flash представляет собой CCID-устройство, которое не требует установки драйверов на современных ОС. Нужные файлы кладутся на Flash-память и пишется небольшой
скрипт для винды, который запускает процесс sTunnel с нужным окружением (OPENSSL_ENGINES=) и запускает RDP-клиент Windows на нужный хост: порт (mstsc /v:127.0.0.1:8088)

Двухуровневый TLS



В случае аутентификации пользователей об Active Directory по сертификатам RSA я предлагаю использовать обычный TLS c хранением клиентского ключа аутентификации RSA на Рутокен ЭЦП, но ходить через sTunnel. В этом случае TLS по RSA будет передаваться внутри канала TLS c ГОСТ.

Возможны две схемы. В первой TLS с RSA организует непосредственно клиент RDP. При этом на токене хранятся два ключа — ГОСТовый (аутентификация «свой-чужой», чтобы авторизоваться на сервере sTunnel)
и RSA (если пользователь смог пройти первый барьер, то этот ключ используется для аутентификации об AD, пользователь сразу попадает в свою учетную запись на RDP-сервере).

image

Для доступа к ключу/сертификату RSA, хранящимся на Рутокен ЭЦП, и аппаратной реализации RSA на «борту» Рутокен ЭЦП используется на Windows Рутокен CSP (входит в дистрибутив драйверов Рутокен), на Linux приложение rdesktop работает через PC/SC.

Во второй схеме TLS по RSA и по ГОСТ обеспечивается самим sTunnel. Сразу предупреждаю, что эту вторую схему я не пробовал.

image

Для доступа к ключу RSA и аппаратной реализации RSA «на борту» Рутокен ЭЦП используется engine pkcs11 из проекта OpenSC www.opensc-project.org/engine_pkcs11.

Соответственно, в конфиге клиента sTunnel будут две секции:

[RDP-TLS-GOST]
engineNum=1
key=100
cert=client_gost.crt
accept = 127.0.0.1:8088
connect = x.x.x.x:1494
ciphers = GOST2001-GOST89-GOST89
TIMEOUTclose = 1


[RDP-TLS-RSA]
engineNum=2
key=101
cert=client_rsa.crt
accept = 127.0.0.1:8087
connect = 127.0.0.1:8088
TIMEOUTclose = 1


А ходить клиентом RDP надо на 127.0.0.1:8087.
Виктор Ткаченко @VicTun
карма
26,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (19)

  • +4
    Отличная статья. Даже не смотря на то, что вы работаете в компании, которая делает USB токены.
    • 0
      Спасибо. Грешен:)
  • 0
    >> Tunnel из «коробки» не умеет работать с ГОСТами, поэтому я его пропатчил и пересобрал. Патч размером примерно в 2 строчки.

    Как под виндой не знаю, а под *nix надо сказать скрипту configure ключ --disable-rsa. Что примечательно, алгоритмы RSA от этого не пропадут, напротив, отсутствие этой опции отрубает все, кроме RSA. Вероятно, патч прибивает это гвоздями? Может под винду тоже есть штатный способ?

    Самому как-то надо было ГОСТовый stunnel для http, собирал. Удобно :) Действительно радует то, что под nix-ы патч не нужен. Правда, я юзал сертифицированную крипту на основе того же openssl, но сути это не меняет.
    • 0
      Дело в том, что sTunnel сначала инициализирует OpenSSL, а потом подгружает engine, которая релизует ГОСТы, поэтому ГОСТы не попадают в список шифрсьютов.

      Поэтому так не работало. Когда я поменял последовательность вызовов (сначал подгружаем engine, потом инициализируем OpenSSL) все заработало.

      Какую версию sTunnel вы собирали?
      • 0
        stunnel 4.36 on i686-redhat-linux-gnu with OpenSSL 0.9.8e
        Брал актуальную на тот момент. Никаких проблем, ГОСТы есть.

        Собственно, способ взял тут cryptocom.ru/opensource/stunnel.html.
        А способ придумал, видимо, Витус Вагнер vitus-wagner.livejournal.com/104283.html?thread=19701339#t19701339
        Говорит, и под виндой оно работает.
        • 0
          Я собирал с OpenSSL 1.0.

          А откуда вы в OpenSSL 0.9.8e получили ГОСТы?

          Предполагаю, что вы использовали патченный OpenSSL 0.9.8e, в котором механизм подгрузки engine работает по другому. Вы случайно не МагПро КриптоПакет использовали?
          • 0
            >> Вы случайно не МагПро КриптоПакет использовали?
            Ага, именно его.

            Мне казалось, что я с OpenSSL 1.0.0 пробовал тоже, сам собирал из исходников. Хотя могу ошибаться.
  • 0
    Понравилось: «В случае TLS-аутентификации пользователей об Active Directory»
    • 0
      Речь идет о том, что по результатам TLS-аутентификации на конкретном сервисе (например, RDP) у AD запрашивается учетная информация пользователя.
    • 0
      Например, в случае доступа через ISA (TMG), которая работает в режиме «делегирование аутентификации»
      пользователь аутентифицируется в рамках TLS по сертификату на ISA. А она уже, конвертирует эту аутентификацию в билет kerberos об AD.
  • 0
    Что мешает просто использовать криптопровайдер ГОСТ?

    http://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%BF%D1%80%D0%BE%D0%B2%D0%B0%D0%B9%D0%B4%D0%B5%D1%80
    • 0
      1. Как криптопровайдер будет работать на Linux, Mac, Android? (openssl и stunnel работают на всех этих платформах)

      2. Все ли провайдеры поддерживают аппаратную аутентификацию с неизвлекаемыми ключами?

      3. Не все версии RDP-клиента под виндой умеют TLS.

      4. Удобнее. Как я уже писал, можно сделать конструкцию, которая не требует установки с правами сисадмина (для современных систем). Можно войти на RDP из интернет-кафе.

      А так ничего не машает:)
  • 0
    1. Я думаю, что связка когда с одной стороны сервер с криптопровайдером, а с другой стороны OpenSSL с ГОСТ вполне будет работать. Хотя сам не пробовал.
    2. КриптоПро ?
    3. Что мешает обновить? + в вашей схеме TLS+RSA over TLS+GOST
    4. Спорный момент. Как быть если нужно конектится к нескольким серверам? Несколько sTunnel'ей?

    • 0
      Вы просто о разном говорите.
      Моё имхо: статья о том, как получить быстрое, дешевое, защищенное и вполне себе удобное решение для админа/программера/фрилансера с берега Красного моря :)

      Ничего не мешает на этой базе сделать промышленное решение, либо выбрать для промышленного решения другую базу по своим потребностям.

      Годная, зачётная статья.
      • 0
        Никто не спорит, что это годная, зачетная статья. У меня был вопрос, а не критика :)

        А что касается «себе удобное решение для админа/программера/фрилансера с берега Красного моря» — в таких случаях и TLS + RSA подойдет. ГОСТ, имхо, нужен только если предъявляются специфические требования.
      • 0
        Уже имеется промышленное решение МагПро Защита RDP
    • 0
      1. На сервере — да. Я про кроссплатформенный клиент.
      4. Несколько секций в конфиге sTunnel. При доступе на 127.0.0.1:8088 будет проброс на сервер А, при доступе на 127.0.0.1:8089 будет проброс на сервер В.
    • 0
      Использую сейчас с отечественным криптопровайдером полностью ГОСТовые, не обернутые RSA ключи на виндовом сервере с AD, Winlogon, и подключаюсь через TSG по RDP, то есть практически все решения готовые и без настраивания sTunnel. Почему бы и нет.
  • –1
    заранее извините за занудство, но слово Suite по-английски произносится «свит», а не «сьют» (suit). Эта новоязовская ошибка уже далеко проникла, но все еще есть шанс ее исправить. Либо целиком перевести на русский термин Cipher suite, либо произносить его правильно.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.