Двухфакторна автентикация на сайта с използване на USB токен. Сега и за Linux

В в една от нашите предишни статии разказахме за важността на двуфакторната автентикация на корпоративните портали на компаниите. Показахме как да настроите сигурна автентикация в web сървъра IIS.

В коментарите ни помолиха да напишем инструкция за най-разпространените уеб сървъри под Linux — nginx и Apache.

Вие питахте — ние написахме.

Какво е необходимо, за да започнем?

• Всеки съвременен дистрибутив на Linux. Правих тестова настройка в MX Linux 18.2_x64. Това разбира се не е сървърен дистрибутив, но за Debian едва ли ще има някакви различия. Пътищата до библиотеките в другите дистрибутиви може да се различават малко.
• Токен. Продължаваме да използваме модела Рутокен ЕЦП PKI, който е идеален по скоростни характеристики за корпоративно приложение.
• За работа с токена в Linux е необходимо да инсталирате следните пакети:
  libccid libpcsclite1 pcscd pcsc-tools opensc

Издаване на сертификати

В предишните статии разчитахме на това, че сертификатите за сървъри и клиенти ще се издават с помощта на Microsoft CA. Но тъй като настройваме всичко в Linux, ще споделим и алтернативен метод за издаване на тези сертификати — без да напускаме Linux.
Като CA ще използваме XCA (https://hohnstaedt.de/xca/), който е наличен в всеки съвременен дистрибутив на Linux. Всички действия, които ще извършим в XCA, могат да се направят и в режим на команден ред с помощта на утилитите OpenSSL и pkcs11-tool, но за по-голяма простота и нагледност в тази статия няма да ги представяме.

Започване

1. Инсталираме:

   $ apt-get install xca

2. И стартираме:

   $ xca

3. Създаваме нашата база данни за CA — /root/CA.xdb
   Препоръчваме да се съхранява базата данни на Certificate Authority в папка, до която има достъп само администраторът. Това е важно за защитата на частните ключове на кореновите сертификати, които се използват за подписване на всички останали сертификати.

Създаваме ключове и сертификат за root CA

В основата на инфраструктурата с открити ключове (PKI) лежи йерархична система. Най-важният в тази система е кореновият централен орган за сертификация или root CA. Неговият сертификат трябва да бъде създаден първо.

1. Създаваме RSA-2048 частен ключ за CA. За целта на таба Private Keys кликнете New Key и избираме съответния тип.
2. Задаваме име за новата ключова двойка. Аз я нарекох — CA Key.
3. Издаване на самия CA сертификат, с използване на създадената ключова двойка. За целта преминаваме на раздела Сертификати и натискаме Нов сертификат.
4. Задължително избираме SHA-256, защото използването на SHA-1 вече не може да се счита за безопасно.
5. Като шаблон задължително избираме [default] CA. Не забравяйте да натиснете на Прилагане на всички, иначе шаблонът няма да бъде приложен.
6. На таба Субект избираме нашата ключова двойка. Там можете да попълните всички основни полета на сертификата.

Създаваме ключове и сертификат за https-сървър

1. По подобен начин създаваме затворен ключ RSA-2048 за сървъра, който нарекох — Server Key.
2. При създаването на сертификата избираме, че сертификатът на сървъра трябва да бъде подписан с CA сертификата.
3. Не забравяйте да изберете SHA-256.
4. Като шаблон избираме [default] HTTPS_server. Щракваме на Прилагане на всички.
5. След което на раздела Субект избираме нашия ключ и попълваме нужните полета.

Създаваме ключове и сертификат за потребителя

1. Затвореният ключ на потребителя ще се съхранява на нашия токен. За работа с него е необходимо да инсталирате PKCS#11 библиотека от нашия сайт. За популярни дистрибуции предлагаме готови пакети, които го има тук — https://www.rutoken.ru/support/download/pkcs/. Имаме и сборки за arm64, armv7el, armv7hf, e2k, mipso32el, които могат да бъдат намерени в нашия SDK — https://www.rutoken.ru/developers/sdk/. Освен сборките за linux, съществуват и сборки за macOS, freebsd и android.
2. Добавяме нов PKCS#11 Provider в XCA. За целта отиваме в менюто Опции на раздела PKCS#11 Provider.
3. Натискаме Добави и избираме пътя до PKCS#11 библиотеката. В моя случай това е usrliblibrtpkcs11ecp.so.
4. Нуждаем се от форматиран токен Рутокен ЕЦП PKI. Изтеглете утилитата rtAdmin — https://dev.rutoken.ru/pages/viewpage.action?pageId=7995615
5. Изпълняваме

   $ rtAdmin -f -q -z /usr/lib/librtpkcs11ecp.so -u

6. Като тип ключ избираме — ключ RSA-2048 на Рутокен ЕЦП PKI. Нарекох този ключ Client Key.

   

7. Въвеждаме PIN-кода. И изчакваме завършването на хардуерната генерация на ключовата двойка.

   

8. Сертификатът за потребителя създаваме по аналогия с сертификата на сървъра. Този път избираме шаблон [default] HTTPS_client и не забравяме да натиснем Прилагане на всички.
9. На таба Субект въвеждаме информация за потребителя. На запитването за запазване на сертификата на токена отговаряме утвърдително.

В резултат на това на раздела Сертификатите в XCA трябва да се получи приблизително такава картина.

Този минимален комплект от ключове и сертификати е достатъчен, за да започнем да настройваме сървърите.

За настройка е необходимо да извършим експортиране на сертификата на УЦ, сертификата на сървъра и затворения ключ на сървъра.

За целта е необходимо да изберете подходящия запис на съответната вкладка в XCA и да натиснете Експорт.

Nginx

Няма да описвам как да инсталирате и стартирате nginx-сървър — в интернет има достатъчно статии по темата, а камо ли официалната документация. Нека да преминем направо към настройките на HTTPS и двуфакторна автентикация по токен.

Добавяме следните редове в секцията server в nginx.conf:

server {
	listen 443 ssl;
	ssl_verify_depth 1;
	ssl_certificate /etc/nginx/Server.crt;
	ssl_certificate_key /etc/nginx/ServerKey.pem;
	ssl_client_certificate /etc/nginx/CA.crt;
	ssl_verify_client on;
}

Подробно описание на всички параметри, свързани с настройката на ssl в nginx, можете да намерите тук — https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

Аз само накратко ще опиша тези, които сам зададох:

• ssl_verify_client — указва, че трябва да се провери веригата на доверие към сертификата.
• ssl_verify_depth — определя дълбочината на търсене на доверения коренов сертификат в веригата. Тъй като нашият клиентски сертификат е подписан веднага на кореновия сертификат, дълбочината е зададена на 1. Ако потребителският сертификат е подписан от междинен CA, то в този параметър трябва да се зададе 2 и така нататък.
• ssl_client_certificate — указва пътя до доверения коренов сертификат, който се използва при проверката на доверието към сертификата на потребителя.
• ssl_certificate/ssl_certificate_key — указват пътя до сертификата/частния ключ на сървъра.

Не забравяйте да изпълните nginx -t, за да проверите дали в конфигурацията няма печатни грешки и дали файловете са на правилното място и т.н.

И собствено всичко! Както виждате, настройката е много лесна.

Проверяваме работата в Firefox

След като всичко правим изцяло в Linux, да приемем, че и нашите потребители също работят в Linux (ако имат Windows, то вж. инструкциите за настройка на браузерите в предишната статия.

1. Стартираме Firefox.
2. Нека да опитаме първо да влезем без токен. Получаваме такава картина:

   

3. Посещаваме about:preferences#privacy, и отиваме в Security Devices…
4. Натискаме Load, за да добавим нов PKCS#11 Драйвера и указваме пътя до нашата librtpkcs11ecp.so.
5. За проверка дали сертификатът се вижда, можете да влезете в Certificate Manager. Ще се появи искане за въвеждане на PIN-код. След правилното въвеждане можете да проверите, че на страницата Your Certificates се е появил нашият сертификат с токена.
6. Сега влизаме с токен. Firefox предлага да изберем сертификата, който ще бъде избран на сървъра. Избираме нашия сертификат.

   

7. ПЕЧАЛБА!

   

Настройката се извършва само веднъж, и както е видно в прозореца за заявка на сертификат, можем да запазим своя избор. След това, при всяко влизане в портала, ще трябва само да въведем токена и PIN кода на потребителя, който беше зададен при форматирането. След такава аутентикация сървърът вече знае кой потребител е влязъл и не е нужно да се правят допълнителни прозорци за проверка, а веднага да се пусне потребителя в личния му кабинет.

Apache

Също така, както и с nginx, проблеми с инсталирането на apache не би трябвало да възникнат. Ако не знаете как да инсталирате този уеб сървър, просто се възползвайте от официалната документация.

А ние преминаваме към настройката на нашия HTTPS и двуфакторна аутентикация:

1. Първо е необходимо да активирате mod_ssl:

   $ a2enmod ssl

2. След това включете настройките за HTTPS на сайта по подразбиране:

   $ a2ensite default-ssl

3. Сега редактираме конфигурационния файл: /etc/apache2/sites-enabled/default-ssl.conf:

       SSLEngine on
       SSLProtocol all -SSLv2
   
       SSLCertificateFile	/etc/apache2/sites-enabled/Server.crt
       SSLCertificateKeyFile /etc/apache2/sites-enabled/ServerKey.pem
   
       SSLCACertificateFile /etc/apache2/sites-enabled/CA.crt
   
       SSLVerifyClient require
       SSLVerifyDepth  10

   Както виждате, имената на параметрите почти съвпадат с имената на параметрите в nginx, затова няма да ги обяснявам. Отново, ако на някого му интересуват подробности — заповядайте в документацията.
   Сега рестартираме нашия сървър:

   $ service apache2 reload
   $ service apache2 restart

Както виждате, настройването на двуфакторна аутентикация на всеки уеб сървър, било то Windows или Linux, е работа на максимум един час. А настройката на браузерите отнема около 5 минути. Мнозина смятат, че настройването и работата с двуфакторна аутентикация е сложно и неразбираемо. Надявам се, нашата статия поне малко да развенчае този мит.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.

Нужна ли е инструкция за настройка на работа с TLS с сертификати по ГОСТ 34.10-2012:

• Да, TLS-ГОСТ е много необходим

• Не, настройката с ГОСТ алгоритми не е интересна

Гласували са 44 потребители. Въздържали са се 9 потребители.

Източник: habr.com