Autentificare în doi pași pe site cu utilizarea unui token USB. Acum și pentru Linux

În una dintre articolele noastre anterioare am discutat despre importanța autentificării cu doi factori pe portalurile corporative ale companiilor. Data trecută, am demonstrat cum să configurăm o autentificare sigură în serverul web IIS.

În comentarii, ne-ați cerut să scriem un ghid pentru cele mai comune servere web sub Linux — nginx și Apache.

Ați cerut — am scris.

Ce este necesar pentru a începe?

• Orice distribuție modernă de Linux. Am efectuat configurarea de test în MX Linux 18.2_x64. Acesta nu este, desigur, o distribuție server, dar pentru Debian nu ar trebui să existe diferențe semnificative. Pentru alte distribuții, căile către biblioteci și configurări pot varia ușor.
• Token. Continuăm să folosim modelul Rutoken ECP PKI, care se potrivește perfect din punct de vedere al performanței pentru utilizarea în mediul corporate.
• Pentru a lucra cu tokenul în Linux, trebuie să instalăm pachetele următoare:
  libccid libpcsclite1 pcscd pcsc-tools opensc

Emiterea certificatelor

În articolele anterioare, ne-am bazat pe faptul că certificatul serverelor și al clienților va fi emis prin Microsoft CA. Dar acum că configurăm totul în Linux, vom discuta și despre o metodă alternativă de emitere a acestor certificate — fără a părăsi Linux.
Ca CA, vom folosi XCA (https://hohnstaedt.de/xca/), care este disponibil în orice distribuție modernă de Linux. Toate acțiunile pe care le vom desfășura în XCA pot fi făcute și în linia de comandă cu ajutorul utilitarelor OpenSSL și pkcs11-tool, dar pentru o mai mare simplitate și claritate, nu le vom incluzi în acest articol.

Începerea utilizării

1. Instalăm:

   $ apt-get install xca

2. Și lansăm:

   $ xca

3. Creăm baza noastră de date pentru CA — /root/CA.xdb
   Recomandăm să păstrați baza de date a Autorității de Certificare într-un folder la care are acces doar administratorul. Acest lucru este important pentru protejarea cheilor private ale certificatelor root, care sunt utilizate pentru semnarea tuturor celorlalte certificate.

Creăm cheile și certificatul root CA

La baza infrastructurii de chei publice (PKI) stă un sistem ierarhic. Principalul element din acest sistem este centrul de certificare root sau root CA. Certificatul său trebuie creat mai întâi.

1. Creăm o cheie privată RSA-2048 pentru CA. Pentru aceasta, pe tab-ul Chei private apăsăm Cheie nouă și alegem tipul corespunzător.
2. Atribuim un nume pentru noua pereche de chei. Eu l-am numit — Cheia CA.
3. Emiterea certificatului CA, folosind perechea de chei creată. Pentru aceasta, trecem la tab-ul Certificatul și apăsăm Certificat nou.
4. Trebuie să alegem SHA-256, deoarece utilizarea SHA-1 nu mai poate fi considerată sigură.
5. Ca șablon, trebuie să alegem [default] CA. Nu uitați să apăsați pe Aplică tot, altfel șablonul nu se aplică.
6. Pe tab-ul Subiect alegem perechea noastră de chei. Acolo puteți completa toate câmpurile de bază ale certificatului.

Creăm chei și certificat pentru serverul https

1. În mod similar, creăm pentru server cheia privată RSA-2048, pe care am numit-o - Cheia serverului.
2. La crearea certificatului, alegem că certificatul serverului trebuie să fie semnat cu certificatul CA.
3. Nu uitați să alegeți SHA-256.
4. Ca șablon, alegem [default] HTTPS_server. Facem clic pe Aplică tot.
5. Apoi, pe fila Subiect alegem cheia noastră și completăm câmpurile necesare.

Creăm chei și certificat pentru utilizator

1. Cheia privată a utilizatorului va fi stocată pe tokenul nostru. Pentru a lucra cu aceasta, trebuie să instalăm biblioteca PKCS#11 de pe site-ul nostru. Pentru distribuțiile populare, distribuiam pachete gata făcute, care se află aici - https://www.rutoken.ru/support/download/pkcs/. Avem, de asemenea, versiuni pentru arm64, armv7el, armv7hf, e2k, mipso32el, care pot fi luate din SDK-ul nostru - https://www.rutoken.ru/developers/sdk/. Pe lângă versiunile pentru linux, avem și versiuni pentru macOS, freebsd și android.
2. Adăugăm un nou Provider PKCS#11 în XCA. Pentru aceasta, mergem în meniul Opțiuni pe fila Provider PKCS#11.
3. Facem clic pe Adaugă și alegem calea către biblioteca PKCS#11. În cazul meu, este usrliblibrtpkcs11ecp.so.
4. Ne va trebui un token formatat RUTOKEN ECDSA PKI. Descărcăm utilitarul rtAdmin - https://dev.rutoken.ru/pages/viewpage.action?pageId=7995615
5. Executăm

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

6. Ca tip de cheie, alegem - cheie RSA-2048 pe RUTOKEN ECDSA PKI. Am numit această cheie Cheia Clientului.

   

7. Introducem PIN-codul. Și așteptăm finalizarea generării hardware a perechii de chei.

   

8. Certificatul pentru utilizator se creează în mod similar cu certificatul serverului. De această dată, alegem șablonul [default] HTTPS_client și nu uitați să apăsați Aplică tot.
9. Pe tab-ul Subiect introducem informațiile despre utilizator. La întrebarea privind salvarea certificatului pe token, răspundem afirmativ.

Ca urmare, pe fila Certificate în XCA ar trebui să obținem aproximativ această imagine.

Această setare minimă de chei și certificate este suficientă pentru a începe configurarea serverelor propriu-zise.

Pentru configurare, trebuie să exportăm certificatul CA, certificatul serverului și cheia privată a serverului.

Pentru aceasta, trebuie să selectați înregistrarea dorită pe fila corespunzătoare din XCA și să apăsați Export.

Nginx

Cum să instalăm și să configurăm un server nginx, nu voi detalia — pe această temă există suficiente articole pe internet, dar și documentația oficială. Să trecem direct la configurarea HTTPS și a autentificării cu doi factori pe bază de token.

Adăugăm în secțiunea server din nginx.conf următoarele linii:

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;
}

O descriere detaliată a tuturor parametrilor referitori la configurarea ssl în nginx o puteți găsi aici — https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

Voi descrie în scurt cei pe care i-am setat eu:

• ssl_verify_client — indică faptul că trebuie verificată lanțul de încredere pentru certificat.
• ssl_verify_depth — determină adâncimea căutării certificatului root de încredere în lanț. Deoarece certificatul clientului nostru este semnat direct pe certificatul root, adâncimea este setată la 1. Dacă certificatul utilizatorului este semnat pe un CA intermediar, atunci în această parametră trebuie să se specifice 2, și așa mai departe.
• ssl_client_certificate — indică calea către certificatul root de încredere, care este utilizat la verificarea încrederii în certificatul utilizatorului.
• ssl_certificate/ssl_certificate_key — indică calea către certificat/cheia privată a serverului.

Nu uitați să executați nginx -t pentru a verifica că nu există erori de tipar în configurație și că toate fișierele sunt acolo unde trebuie și așa mai departe.

Și, de fapt, asta este tot! Așa cum puteți observa, configurarea este foarte simplă.

Verificăm funcționarea în Firefox

Deoarece totul este realizat în totalitate în Linux, să presupunem că și utilizatorii noștri lucrează în Linux (dacă au Windows, atunci consultați instrucțiunile privind configurarea browserelor în articolul anterior.

1. Lansăm Firefox.
2. Vom încerca mai întâi să accesăm fără token. Primim această imagine:

   

3. Accesăm about:preferences#privacy, și mergem la Dispozitive de securitate…
4. Facem clic pe Load, pentru a adăuga un nou driver de dispozitiv PKCS#11 și indicăm calea către librtpkcs11ecp.so.
5. Pentru a verifica dacă certificatul este vizibil, putem accesa Manager de certificate. Se va afișa o solicitare de introducere a PIN-ului. După introducerea corectă, putem verifica că pe fila Certificatul dumneavoastră apare certificatul nostru de pe token.
6. Acum accesăm cu tokenul. Firefox oferă opțiunea de a selecta certificatul care va fi utilizat pe server. Selectăm certificatul nostru.

   

7. PROFIT!

   

Configurarea se efectuează o singură dată, iar așa cum se vede în fereastra de cerere a certificatului, putem salva alegerea noastră. După aceea, la fiecare accesare a portalului, va trebui doar să introducem tokenul și PIN-ul utilizatorului, care a fost setat în timpul formatarii. După o astfel de autenticare, serverul știe deja ce utilizator s-a conectat și nu mai este necesară nicio fereastră suplimentară pentru verificare, permițând utilizatorului să acceseze direct panelul său personal.

Apache

La fel ca și cu nginx, nu ar trebui să apară probleme la instalarea apache pentru nimeni. Dacă nu știți cum să instalați acest server web, folosiți pur și simplu documentația oficială.

Acum trecem la configurarea HTTPS și a autentificării cu două factorii:

1. Pentru început, este necesar să activăm mod_ssl:

   $ a2enmod ssl

2. Apoi, activăm setările HTTPS pentru site-ul implicit:

   $ a2ensite default-ssl

3. Acum edităm fișierul de configurație: /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

   După cum vedeți, numele parametrilor coincid aproape complet cu cele din nginx, așa că nu le voi explica. Din nou, pentru cei care sunt interesați de detalii - bun venit în documentație.
   Acum repornim serverul nostru:

   $ service apache2 reload
   $ service apache2 restart

După cum vedeți, configurarea autentificării cu două factorii pe orice server web, fie că este vorba de Windows sau Linux, durează maximum o oră. Configurarea browserelor durează aproximativ 5 minute. Mulți consideră că setarea și utilizarea autentificării cu două factorii sunt complicate și neclare. Sper că articolul nostru demontează puțin acest mit.

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.

Este necesară o instrucțiune pentru configurarea TLS cu certificate conform GOST 34.10-2012:

• Da, TLS-GOST este foarte necesar.

• Nu, configurarea cu algoritmii GOST nu este interesantă.

Au votat 44 de utilizatori. S-au abținut 9 utilizatori.

Sursa: habr.com