Настройка двусторонней RSA и GOST аутентификации в приложении на JBoss EAP 7 / Хабр

Описание системы

VPN будет работать по схеме IPSec L2TP PPP. Протокол Point-to-Point Protocol (PPP) работает на канальном уровне модели OSI и обеспечивает аутентификацию пользователя и шифрование передаваемых данных. Его данные инкапсулируются в данные протокола L2TP, который собственно обеспечивает создание соединения в VPN сети, но не обеспечивает аутентификацию и шифрование.

Данные L2TP инкапсулируются в протокол IPSec, который тоже обеспечивает аутентификацию и шифрование, но в отличие от протокола PPP аутентификация и шифрование происходит на уровне устройств, а не на уровне пользователей.

Данная особенность позволяет обеспечить аутентификацию пользователей только с определённых устройств. Мы же будем использовать протокол IPSec как данное и позволим производить аутентификацию пользователей с любого устройства.

Аутентификация пользователя с помощью смарт-карт будет производиться на уровне протокола PPP с помощью протокола EAP-TLS.

Более подробную информации о работе данной схемы можно найти в этой статье.

Что такое ssl-сертификат?

Многие наверняка слышали про

, но не все чётко представляют, что это такое и для чего они нужны. По сути, SSL-сертификат — цифровая подпись вашего сайта, подтверждающая его подлинность. Использование сертификата позволяет защитить как владельца сайта, так и его клиентов. SSL-сертификат даёт возможность владельцу применить к своему сайту технологию SSL-шифрования.

Настройка FreeRADIUS.

Начнем с установки и настройки FreeRADIUS сервера.

В операционной системе Gentoo это делается довольно просто, достаточно ввести команду
=====================================================
root@s2 ~ # emerge -av freeradius

These are the packages that I would merge, in order:

Calculating dependencies …done!

[ebuild N ] net-dialup/freeradius-1.0.5-r1 -edirectory
-frascend -frnothreads -frxp -kerberos -ldap -mysql pam
-postgres -snmp ssl -udpfromto 2,240 kB

Total size of downloads: 2,240 kB

Do you want me to merge these packages? [Yes/No]
=====================================================

Если планируется хранить базу пользователей во внешних базах (например, ldap, mysql или postgre), то перед сборкой RADIUS сервера надо активировать соответствующие флаги, позволяющие собрать FreeRADIUS с поддержкой mysql/postgre и/или ldap:
=====================================================
# USE=”mysql ldap” emerge -av freeradius
=====================================================

После проверки включенности нужных флагов, достаточно нажать клавишу Y и пакет будет собран и установлен в систему:
=====================================================

<….>

— !targe sym /usr/lib/rlm_digest-1.0.5.la
— !targe sym /usr/lib/rlm_detail.so
— !targe sym /usr/lib/rlm_detail-1.0.5.la
— !targe sym /usr/lib/rlm_counter.so
— !targe sym /usr/lib/rlm_counter-1.0.5.la
— !targe sym /usr/lib/rlm_checkval.so
— !targe sym /usr/lib/rlm_checkval-1.0.5.la
— !targe sym /usr/lib/rlm_chap.so
— !targe sym /usr/lib/rlm_chap-1.0.5.la
— !targe sym /usr/lib/rlm_attr_rewrite.so
— !targe sym /usr/lib/rlm_attr_rewrite-1.0.5.la
— !targe sym /usr/lib/rlm_attr_filter.so
— !targe sym /usr/lib/rlm_attr_filter-1.0.5.la
— !targe sym /usr/lib/rlm_always.so
— !targe sym /usr/lib/rlm_always-1.0.5.la
— !targe sym /usr/lib/rlm_acct_unique.so
— !targe sym /usr/lib/rlm_acct_unique-1.0.5.la
— !targe sym /usr/lib/libradius.so
— !targe sym /usr/lib/libradius-1.0.5.la
— !targe sym /usr/lib/libeap.so
— !targe sym /usr/lib/libeap-1.0.5.la
>>> original instance of package unmerged safely.
>>>

Вышеприведенный лог сборки (его конец) показывает, что FreeRADIUS 1.0.5 успешно установлен в систему (о чем сообщает строка ” net-dialup/freeradius-1.0.5-r1 merged”). Можно приступать к его настройке.

Создание сертификата компьютера.

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

Наш компьютер называется testcomp1. Создаем сертификат для него:
#—————————————————-
# ./sign_cert.sh client_cert testcomp1
#—————————————————-

Называние поля CN сертификата в общем случае может не совпадать с названием рабочей станции, на которой этот сертификат будет установлен. Но в настройках Radius-сервера можно ввести проверку на идентичность этого поля и имени машины. В случае несовпадения — отказать в соединении.

После ввода всех необходимых параметров и отработки скрипта мы получим на выходе файл testcomp1.p12 — его и установим в дальнейшем на нашу рабочую станцию.

1 Установка корневого сертификата CA напрямую.

Для начала, необходимо установить корневой сертификат CA (сертификационного центра). Просто открываем в Windows Explorer-е директорию, где у нас лежат файлы сертификатов, и два раза щелкаем на созданном ранее файле tmp_org-ca.crt

В ответ получаем окошко, где нам предлагается установить сертификат в систему. Можно сразу щелкнуть по кнопке “Установить сертификат”, а можно предварительно побегать по закладкам:

Закладка “Состав” показывает все параметры сертификата. Особенно интересны пункты “Действителен с” и “Действителен по” — сертификат будет действителен только в этом промежутке времени. Если им воспользоваться раньше или позже указанного времени, он будет отвергнутым (это касается сертификатов любых типов — как серверных, так и клиентских).

“Путь сертификации” показывает, что сертификат является корневым (самоподписанным).

После нажатия кнопки “Установить сертификат” в закладке “Общие”, мы попадем в мастер импорта сертификатов.

Операционная система сама разберется, куда помещать сертификат, поэтому можно оставить галку на “Автоматически выбрать хранилище”.

… осталось нажать кнопку “готово”.

Выскакивает последнее предупреждение об установке нового центра сертификации “tmp_org root CA”.

После нажатия на кнопку “да” в предыдущем меню, система сообщит нам, что импорт выполнен. Тем не менее, даже после нажатия на “ОК”, основное окошко с сертификатом продолжает сообщать, что сертификат неизвестен. Это всего лишь “фича” операционной системы. Достаточно закрыть то окно и открыть его заново (два раза щелкнуть на файл с сертификатом):

В этом случае нам уже сообщают, что сертификат известен и ему доверяют.

1 файл /etc/raddb/clients.conf

Для начала пропишем клиентов (в данном случае — точку доступа) в файле /etc/raddb/clients.conf
#—————————————————-
client 192.168.1.250/32 {
secret = test1234
shortname = test_ap
}
#—————————————————-

Эта запись означает, что клиент с адресом 192.168.1.250 авторизируется на RADIUS-е с паролем test1234. Имя test_ap будет использована при логировании событий, связанных с этой точкой доступа.

Не забываем сменить стандартный пароль для localhost_клиентов:
#—————————————————-
secret = very_strong_secret_password
#—————————————————-

3 файл /etc/raddb/proxy.conf

Теперь открываем файл /etc/raddb/proxy.conf и добавляем в конец этого файла
#—————————————————-
realm DEFAULT {
type = radius
authhost = LOCAL
accthost = LOCAL
}
#—————————————————-

DEFAULT реалм, добавленный нами, позволяет всем аккаунтам, которые не попали ни в один вышезаданный реалм, проверяться на локальном радиусе. В нашем случае это означает, что все windows-аккаунты с отрезанной доменной частью будут проверяться локально.

4 файл /etc/raddb/eap.conf

Переходим к настройке протокола EAP. Его настройки располагаются в отдельном файле, который, в свою очередь, подключается к основному /etc/raddb/radiusd.conf вот такой конструкцией:
#—————————————————-
$INCLUDE ${confdir}/eap.conf
#—————————————————-

Открываем /etc/raddb/eap.conf

В секции eap{ }
#—————————————————-
default_eap_type = peap # по-умолчанию, используем EAP-PEAP
#—————————————————-

Раскомментируем секцию, относящуюся к peap:
#—————————————————-
peap {
default_eap_type = mschapv2
}
#—————————————————-

Но этого недостаточно для функционирования PEAP, нам также необходимо активировать (раскомментировать) секцию, отвечающую за EAP-TLS:
#—————————————————-
tls {
private_key_password = whatever
private_key_file = ${raddbdir}/certs/cert-srv.pem

certificate_file = ${raddbdir}/certs/cert-srv.

В данном случае использованы цифровые сертификаты, сгенерированные автоматически, при установке пакета freeradius. Можно, конечно, создать собственные сертификаты, подписанные своим (или сторонним) сертификационным центром, но для простоты объяснения, этот этап опущен (он будет подробно расписан в следующей части статьи). Для работы RADIUS-сервера для обеспечения работы EAP-PEAP протокола, вышеприведенных настроек будет достаточно.

Настройка точки доступа.

Здесь описывается лишь настройка точки доступа в качестве Radius-клиента. Разумеется, интерфейсы точек доступа разных производителей будут выглядеть по-разному, но общие принципы настроек изменяться не будут.

Надо сделать следующее:

• включить WPA;
• выбрать тип шифрования (AES или TKIP)
• прописать адрес RADIUS-сервера
• прописать пароль доступа (shared secret) к RADIUS-серверу

Вводим SSID беспроводной сети (WPA-PEAP), активируем “Security” и жмем кнопку “Configure Security”.

В появившемся окне выбрать WPA RADIUS в пункте “Security Mode”. Далее алгоритм шифрования — установить AES (или TKIP, если клиентское оборудование AES не поддерживает). Далее вводим адрес машины, где установлен RADIUS сервер и порт, по которому оный принимает запросы (порт 1812 — является стандартным).

Осталось задать “Shared Secret” (пароль на подключение) и все — настройка точки доступа на этом завершена.

25 твитов об ssl-сертификатах

SSL сертификаты. Для чего они нужны, какие бывают, от чего защищают, кто использует, как долго действуют, есть ли гарантия? Разберем основные вопросы – кратко, в режиме твиттера – не более 280 символов на ответ.

1. Что такое SSL?

SSL означает Secure Sockets Layer – это протокол, используемый для шифрования и аутентификации данных, передаваемых между приложениями, например, браузером и веб-сервером.

2. Как появился сертификат SSL?

SSL версии 1.0 был разработан Netscape в начале 1990-х. Но из-за недостатков безопасности так и не был опубликован. Первым общедоступным выпуском был SSL 2.0, вышедший в феврале 1995 года. Это была улучшенная версия, но лишь после полного изменения дизайна утвердилась версии 3.0.

3. В чем суть сертификатов?

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

4. Что такое TLS-сертификат?

TLS (Transport Layer Security) – преемник и улучшенная версия SSL, имеет более надежные алгоритмы шифрования, но несмотря на схожесть считается другим стандартом.

5. Какие же протоколы сейчас используются?

SSL, как ни странно сейчас не используются. Было 3 версии 1.0, 2.0 и 3.0 и на основе версии SSL 3.0 создали протокол TLS 1.0. Затем вышли версии TLS 1.1, 1.2 и 1.3, а применяются только две последние.

6. Какой принцип работы SSL-сертификата?

При подключении браузера к сайту происходит «SSL-рукопожатие» (создаются ключи “рукопожатия”), далее происходит обмен криптографическими данными и в конце формируются сессионные ключи, на основе которых происходит шифрование трафика.

7. Какие существуют сертификаты?

8. И для чего каждый из них?

9. Есть ли другие виды сертификатов?

Да, например, сертификат Multi-Domain SSL на несколько доменов – не требует покупки сертификатов на каждый домен и упрощает администрирование. Code Signing certificates предназначен для защиты вашего кода, контента и других файлов во время их передачи в онлайн режиме.

10. Какие данные в SSL-сертификате?

SSL-сертификат содержит информацию:

11. В чем различия между SSL и HTTPS?

SSL – протокол безопасности, используемый для установления защищенного соединения между веб-браузером и веб-сервером. HTTPS работает как подуровень между приложениями. HTTPS шифрует обычное HTTP-сообщение перед отправкой и расшифровывает его во время доставки.

12. Как узнать, использует ли сайт SSL/HTTPS?

Большинство браузеров помечают безопасные соединения, защищенные сертификатами SSL/TLS замком и/или сообщением.

13. Как браузер может понять, корректен ли сертификат? 

Операционная система компьютера хранит список корневых сертификатов, составляющих цепочку доверия. При открытии сайта браузер проверяет всю цепочку, вплоть до корневого. Если хоть один из сертификатов оказывается недействительным, то и вся цепочка также недействительна.

14. Почему SSL сертификаты такие дорогие?

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

15. Существуют ли бесплатные сертификаты и насколько они безопасны?

Бесплатные сертификаты существуют, выполняют ту же функцию, что и платные, но обычно имеют самый низкий уровень безопасности (DV), на него, вероятно, не будет гарантии, т.е. они безопасны но до некоторой степени. При угрозе посетители вашего сайта не смогут требовать гарантии.

16. Где купить?

Если ваш хост не предлагает бесплатные SSL-сертификаты или вам нужен другой тип сертификата, вы можете приобрести собственный сертификат в центре сертификации или у реселлера, имеющего скидки, что будет дешевле.

17. Что такое центр сертификации?

Центр сертификации (Certificate Authority, CA) – международная организация, которая выпускает и несет ответственность за SSL-сертификаты. CA проверяет домены и источники, подтверждающие подлинность организаций. Центрам сертификации доверяет 99% браузеров.

18. Каков процесс получения сертификата, после того как вы его оплатили?

Сначала вы генерируете CSR и секретный ключ. Затем отсылаете CSR в орган сертификации (CA) и получаете архив с текстовыми / бинарными файлами для разных типов веб-серверов. Затем устанавливаете его на хостинге или своем сервере.

19. Как воспользоваться SSL/TLS сертификатом?

20. Как проверить правильность настройки сертификата?

Один популярных способов: зайдите на сайт Qualys, введите имя сайта и нажмите кнопку “submit. Сервис осуществит проверку и выдаст оценку в баллах. Если сайт получил А или А , то сертификат работает корректно.

21. Связаны ли как-то SSL-сертификат и продвижение в сети (SEO)?

Если ваш сайт не защищен сертификатом SSL, то он получает от Google отметку «небезопасно». Кроме того, если вы хотите, чтобы контент и сайт занимали высокие позиции в результата выдачи, виртуальный замок вам всё же понадобится. Но основная цель всё же безопасность соединения.

22. Какой срок действия сертификата?

Коммерческий сертификат действует 1 год. Срок действия сертификатов неуклонно сокращался с 10 лет в 2021 году, далее до 3 лет в 2021 году, затем до двух лет в 2021 году и до года в настоящее время.  Бесплатные сертификаты действуют на 90 дней.

23. Почему SSL-сертификаты не делают вечными?

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

24. Защищает ли SSL данные сайта?

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

25. И всё-таки, зачем нужен SSL сертификат?

Любая информация, отправляемая через интернет, проходит через сетевое оборудование, серверы, компьютеры и прочие соединения, и если данные не зашифрованы, то это делает их уязвимыми для атак.

В заключение капля юмора. Так выглядит сайт с говорящим названием рубрики: “SSL сертификат купить дешево” – http://www.net.ru/ssl/ssl-sertifikat-kupit-deshevo

---

Материал подготовлен компанией ITSOFT. Размещение и аренда серверов и стоек в двух ЦОДах в Москве; colocation GPU-ферм и ASIC-майнеров, аренда GPU-серверов. Лицензии связи, SSL-сертификаты. Администрирование серверов и поддержка сайтов. UPTIME за последние годы составляет 100%.

Настройка беспроводного клиента.

WiFi карта подключена к компьютеру под управлением Windows XP PRO SP2. Настройка производится в родной Windows Zero Config утилите.

Жмем на “изменить порядок предпочтения сетей”.

В закладке “беспроводные сети” щелкаем на кнопку “Добавить”.

Попадаем в окно свойств беспроводной сети.

Закладка “связи”. Указываем нужное имя сети (в нашем случае WPA-PEAP) и выбираем тип шифрования данных (AES или TKIP). Разумеется, он должен совпадать с тем, что был указан в точке доступа.

Переходим на закладку “Проверка подлинности”. В типе EAP ставим “Protected EAP (PEAP)”. После чего жмем на кнопку “Свойства”.

В следующем окошке снимаем галку с “проверять сертификат сервера”. Так как сертификаты у нас самосгенеренные при установке FreeRadius, Windows не сможет проверить их валидность (это будет показано чуть ниже).

Далее, выбираем “Метод проверки подлинности”, ставим там “Secured password (EAP-MSCHAP v2). Если тут же нажать кнопку “настроить”, то

Установка сертификатов через MMC

Пара способов установки клиентских сертификатов уже была описана в четвертой части:

К сожалению, так можно установить только клиентские сертификаты (и корневые). И те и другие будут храниться в профиле пользователя.

Для установки сертификата компьютера, который будет храниться в системном профиле (куда ОС будет иметь доступ даже без наличия сети), необходимо воспользоваться Microsoft Managment Console (MMC).

Для этого идем в “Пуск” -> “Выполнить”.

В окне запуска программы пишем “mmc” и жмем клавишу “OK”.

В открывшемся окне консоли необходимо добавить оснастку сертификатов.

Для этого идем в меню “Консоль”. И выбираем пункт “Добавить или удалить оснастку”.

На закладке “Изолированная оснастка” жмем кнопку “добавить”.

В появившемся списке выбираем оснастку “Сертификаты” и жмем кнопку “Добавить”.

Появляется меню, в котором необходимо выбрать, какими сертификатами мы будем управлять.

Пункт “моей учетной записи пользователя” позволит добавить оснастку управления пользовательскими сертификатами. Именно ими мы и управляли в предыдущей статье с помощью интерфейса IE.

Добавляем пользовательскую оснастку.

Теперь таким же образом добавляем оснастку для управления сертификатами учетной записи компьютера:

Сертификаты компьютера невозможно добавить напрямую или через IE. Они добавляются только через MMC-консоль.

При добавлении оснастки управления сертификатами компьютера, появляется меню, где можно указать, каким именно компьютером мы хотим в данный момент управлять — выбираем “локальным компьютером” (в принципе, администратор домена может удаленно управлять оснастками и на удаленных машинах).

В результате мы добавили две оснастки — для управления сертификатами пользователя и компьютера.

Теперь подробнее рассмотрим, что эти оснастки из себя представляют.

Раскрываем дерево сертификатов текущего пользователя. Идем вниз по дереву: “Личные” -> “Сертификаты”.

Добавление FreeRadius в автостарт

Осталось лишь остановить FreeRADIUS сервер, запущенный в режиме отладки, добавить его в автостарт…
=====================================================
# rc-update add radiusd default
* radiusd added to runlevel default
=====================================================

…для того, чтобы radiusd сервис запускался при старте системы, и запустить его (однократно) в нормальном режиме:
=====================================================
# /etc/init.d/radiusd start
* Starting radiusd … [ ok ]
=====================================================

Все, настройка системы на этом завершена.

Процесс подключения со стороны RADIUS-сервера

Для детального наблюдения за процессом, запускаем Radius в режиме отладки:
#—————————————————-
# radiusd -X
#—————————————————-

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

После того, как рабочая станция включится и операционная система полностью загрузится (до момента, когда появится ctrl alt del экран) нужно подождать еще секунд 20..40. Это время необходимо ОС для обнаружения беспроводной сети — только после этого произойдет попытка подключения к ней.

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

Где купить ssl-сертификат?

Приобретают сертификаты обычно не напрямую у удостоверяющего центра, а через партнёров. В России продажей сертификатов известных удостоверяющих центров (УЦ), таких как Comodo, Geotrust, GoDaddy, GlobalSign, Symantec и прочих, занимается множество компаний.

Для клиента на linux

Для начала сгенерируем ключевую пару на токене и создадим заявку на сертификат:

#идентификатор ключа (параметр --id) можно заменить на любой другой.
pkcs11-tool --module /usr/lib/librtpkcs11ecp.so --keypairgen --key-type rsa:2048 -l --id 45

openssl
OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:librtpkcs11ecp.so
...
OpenSSL> req -engine pkcs11 -new -key 45 -keyform engine -out client.req -subj "/C=RU/CN=client"

Появившуюся заявку client.req отправьте в УЦ. После того как вы получите сертификат для своей ключевой пары, запишите его на токен с тем же id, что и у ключа:

pkcs11-tool --module /usr/lib/librtpkcs11ecp.so -l -y cert -w ./client.pem --id  45

Добавление нового клиента

Чтобы добавить нового клиента в сеть, необходимо записать его сертификат в список доверенных для данного клиента.

Если пользователь хочет стать участником VPN сети, он создаёт ключевую пару и заявку на сертификат для данного клиента. Если пользователь доверенный, то данную заявку можно подписать, а получившийся сертификат записать в директорию сертификатов:

sudo openssl x509 -req -in client.req -CAkey /etc/ppp/keys/ca.pem -CA /etc/ppp/certs/ca.pem -out /etc/ppp/certs/client.pem -CAcreateserial

Добавим строчку в файл /etc/ppp/eaptls-server для сопоставления имени клиента и его сертификата:

"client" * /etc/ppp/certs/client.pem /etc/ppp/certs/server.pem /etc/ppp/certs/ca.pem /etc/ppp/keys/server.pem *

NOTEЧтобы не запутаться, лучше чтобы: Common Name, имя файла с сертификатом и имя пользователя были уникальными.

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

Защита для бизнеса и клиентов

Каким же сайтам нужна защита SSL? Да практически всем. Особенно тем, которые в наибольшей степени подвержены атакам: ресурсам финансовых учреждений, крупных брендов, сайтам, работающим с персональными данными и платёжной информацией.

Использование беспроводных сетей в доменах windows

Предыдущая статья была посвящена настройке клиентской части WPA шифрования по протоколу EAP-TLS.

В предпоследней статье серии мы рассмотрим вопросы использования EAP-TLS в доменных сетях Windows.

Обращаю внимание, что для понимания нижеследующего материала, читателю необходимо ознакомиться со всеми предыдущими статьями этого цикла.

Как обычно, для дальнейшей работы нам потребуется все то, что упоминалось в предыдущей части. А именно:

Настройка jre

Казалось бы, все настроено, и должно работать. Но нет. Остается еще один важный штрих.

Чтобы из приложения на JBoss аутентифицироваться в КриптоПро УЦ по протоколу Gost TLS, сервер JBoss нужно запускать в JRE с установленным КриптоПро JCP провайдером.

При установке JCP в настройки JRE вносятся изменения. В частности, в jre1.8.0_144libsecurity java.security алгоритмы KeyManagerFactory и TrustManagerFactory меняются на Gost. Если так оставить, то в JBoss при старте будет возникать ошибка:

Настройка vpn соединения

Для настройки VPN соединения перейдите в панель управления и выберите пункт для создания нового соединения.

Во всплывшем окне выберите опцию создания соединения для подключения к рабочему месту:

В следующем окне выберете подключение по VPN:

и введите данные VPN соединения, а также укажите опцию для использования смарт-карты:

На этом настройка не закончена. Осталось указать общий ключ для протокола IPsec, для этого перейдём на вкладку “Настройки сетевых подключений” и затем перейдём на вкладку “Свойства для данного соединения”:

В открывшемся окне перейдём на вкладку “Безопасность”, укажем в качестве типа сети “Сеть L2TP/IPsec” и выберем “Дополнительные параметры”:

В открывшемся окне укажем общий ключ IPsec:

Настройка клиента l2tpipsecvpn

Запускаем установленный клиент:

После запуска у вас должен открыться апплет L2tpIpsecVPN. Нажмём на него правой кнопкой мыши и произведём настройку соединения:

Для работы с токенами, в первую очередь, укажем путь opensc движка OpenSSL и PKCS#11 библиотеки. Для этого откройте вкладку “Preferences” для настройки параметров openssl:

Закроем окно настроек OpenSSL и перейдём к настройке сети. Добавим новую сеть, нажав на клавишу Add… в панели настроек и введите имя сети:

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

После этого переходим на вкладку настройки PPP и укажем там имя пользователя, под которым мы хотим зайти в сеть:

После этого откроем вкладку Properties и укажем путь до ключа, сертификата клиента и УЦ:

Закроем данную вкладку и выполним финальную настройку, для этого откроем вкладку “IP settings” и поставим галочку напротив опции “Obtain DNS server address automatically”:

Данная опция позволит клиенту получать от сервера личный IP-адрес внутри сети.

После всех настроек закроем все вкладки и перезагрузим клиент:

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

Для настройки сервера JBoss EAP 7.0.0 все изменения нужно внести в конфигурационный файл jboss-EAP-7.0.0standaloneconfiguration

standalone.xml

В раздел <system-properties> добавляются настройки, указывающие серверу, каких провайдера и хранилища использовать для двусторонней ГОСТ-аутентификации:

Для настройки RSA TLSv1.2 аутентификации пользователя и сервера JBoss в раздел

нужно добавить область безопасности:

Таким образом, для JBoss указаны все необходимые хранилища ключей и сертификатов.

В раздел

Общая схема аутентификации по сертификатам

Когда пользователь аутентифицируется при помощи сертификата на веб-сайте, происходит примерно следующий процесс:

1. Пользователь запрашивает доступ к некоторой сетевой службе;
2. По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
3. Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
4. Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
5. Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
6. Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).

Я посчитал нужным немного развернуть последний пункт, чтобы вы понимали общее устройство этого канала (поскольку, у людей есть некоторые заблуждения на этот счёт):

1. Клиент запрашивает установку безопасного канала;
2. Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
3. Клиент посылает на сервер свой список протоколов симметричного шифрования;
4. Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
5. Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
6. После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).

Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.

Подготовка rsa-ключей аутентификации

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

Удостоверяющие центры для сервера и клиента могут быть разные.

Пользователь должен доверять удостоверяющему центру, выпустившему сертификат для сервера.

Сервер должен доверять удостоверяющему центру, выпустившему сертификат для клиента.

Существует много утилит и инструментов с хорошим описанием и примерами, которые позволяют работать с хранилищами и выполнять генерацию ключей и запросов на сертификат (keytool, openSSL, Portecle, XCA). Поэтому процесс подготовки хранилищ и выпуск сертификатов здесь пропустим.

Вот, например, хорошая статья и пошаговая инструкция по настройке Two-way SSL with TLS1.2 для Oracle SOA Suite с использованием openSSL и keytool. Но, правда, она частично потеряла актуальность и перестала отражать всю картину. Выпущенные по ней сертификаты не будут корректно восприниматься в веб-браузерах.

Error: «Subject Alternative Name Missing» or NET::ERR_CERT_COMMON_NAME_INVALID or «Your connection is not private»

если получит с сервера SSL-сертификат без домена в альтернативном имени субъекта сертификации.

Вот что говорит об этом Support Google Chrome Answer

Как с помощью openSSL добавить в сертификат subjectAlternativeName — можно посмотреть здесь и здесь

Разумеется, такой способ получения TLS-сертификатов годится только для внутрикорпоративных приложений.

Подключение к сети

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

В процессе установки соединения клиент попросит ввести нас PIN-код Рутокен:

Если в статус-баре появится оповещение о том, что соединение успешно установлено, значит, настройка была произведена успешно:

В противном случае стоит разобраться, почему соединение не было установлено. Для этого стоит посмотреть лог программы, выбрав в апплете команду “Connection information”:

Постановка задачи

Для корпоративного приложения с тонким клиентом в веб-браузере, middle или backend servlet-а, которые запускаются на JBoss EAP, необходимо настроить двустороннюю аутентификацию по протоколу TLSv1.2 с применением зарубежных криптографических алгоритмов.

Задача усложняется тем, что приложение на сервере JBoss в свою очередь взаимодействует, например, с Программно-аппаратным комплексом «ПАК Удостоверяющий центр КриптоПро», где требуется процедура двусторонней аутентификации по протоколу Transport Layer Security (TLSv1.0) c использованием российских криптографических алгоритмов.

Получается, что в одном приложении на сервере JBoss нужно подружить отечественную и зарубежную криптографию.

Аутентификация должна выполняться комбинированным методом инструментами Инфраструктуры открытых ключей (PKI), т.е. с помощью сертификатов клиента и сервера.

Проблематика

Ещё совсем недавно многие не знали, как это — работать из дома. Пандемия резко изменила ситуацию в мире, все начали адаптироваться к сложившимся обстоятельствам, а именно к тому, что выходить из дома стало просто небезопасно. И многим пришлось быстро организовывать работу из дома для своих сотрудников.

Однако отсутствие грамотного подхода в выборе решений для удалённой работы может привести к необратимым потерям. Пароли пользователей могут быть украдены, а это даст возможность злоумышленнику бесконтрольно подключаться к сети и ИТ-ресурсам предприятия.

Именно поэтому сейчас выросла потребность в создании надёжных корпоративных VPN сетей. Я расскажу вам о надёжной, безопасной и простой в использовании VPN сети.

Она работает по схеме IPsec/L2TP, использующей для аутентификации клиентов неизвлекаемые ключи и сертификаты, хранящиеся на токенах, а также передает данные по сети в зашифрованном виде.

Установка strongswan (ipsec)

В первую очередь, настроим firewall для работы ipsec

sudo firewall-cmd --permanent --add-port=1701/{tcp,udp}
sudo firewall-cmd --permanent --add-service=ipsec
sudo firewall-cmd --reload

Затем приступим к установке

sudo yum install epel-release ipsec-tools dnf
sudo dnf install strongswan

После установки необходимо задать конфигурацию для strongswan (одну из реализаций IPSec). Для этого отредактируем файл /etc/strongswan/ipsec.conf :

config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    oe=off
    protostack=netkey 

conn L2TP-PSK-NAT
    rightsubnet=vhost:%priv
    also=L2TP-PSK-noNAT

conn L2TP-PSK-noNAT
    authby=secret
    pfs=no
    auto=add
    keyingtries=3
    rekey=no
    ikelifetime=8h
    keylife=1h
    type=transport
    left=%any
    leftprotoport=udp/1701
    right=%any
    rightprotoport=udp/%any
    ike=aes128-sha1-modp1536,aes128-sha1-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha1-modp1536,3des-sha1-modp1024,3des-md5-modp1536,3des-md5-modp1024
    esp=aes128-sha1-modp1536,aes128-sha1-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha1-modp1536,3des-sha1-modp1024,3des-md5-modp1536,3des-md5-modp1024

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

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

Так же в strongswan имеется возможность обеспечить аутентификацию с помощью смарт-карт, но пока поддерживается ограниченный круг устройств и поэтому аутентификация с помощью токенов и смарт-карт Рутокен пока затруднительна. Зададим общий пароль через файл /etc/strongswan/ipsec.secrets:

# ipsec.secrets - strongSwan IPsec secrets file
%any %any : PSK "SECRET_PASSPHRASE"

Перезапустим strongswan:

sudo systemctl enable strongswan
sudo systemctl restart strongswan

Заключение.

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

В последней части речь пойдет о проблеме “первичности курицы и яйца”- использовании беспроводных клиентов в доменах Windows.

Разберем вкратце эту ситуацию. Клиентский сертификат хранится в профиле пользователя. Профиль может лежать как на сервере (перемещаемые профили), так и на самой рабочей станции (локальные профили).

Для процесса аутентификации (подключения к беспроводной сети), нам необходим клиентский сертификат, лежащий в профиле. Для доступа к профилю, нам как минимум надо аутентифицироваться и на домен-контроллере. То есть, с одной стороны, для подключения к беспроводной сети нам нужно аутентифицироваться на домен-контроллере. А с другой — для аутентификации на домен-контроллере мы уже должны быть подключены к беспроводной сети. Замкнутый круг? 🙂

Второй момент. Выдали сотруднику клиентский сертификат на его ноутбук. Работает он в беспроводной сети, горя не знает. Потом сотрудник уволился. Как запретить ему доступ в сеть компании?

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

Логон смарт-картой или pkinit

Интерактивная аутентификация в Active Directory по сертификату не является самостоятельным механизмом. Как и всегда, основной протокол аутентификации в домене — Kerberos. Чтобы обеспечить взаимодействие между аутентификацией по смарт-карте и Керберосом, применяется нехитрый протокол PKINIT.

Примечание: если у пользователя уже есть соответствующий сервисный тикет (TGS), выполняются только шаги 5 и 6.