Dwustopniowa weryfikacja na stronie z użyciem tokena USB. Teraz także dla systemu Linux

W w jednym z naszych wcześniejszych artykułów opowiadaliśmy o ważności uwierzytelniania dwuskładnikowego na korporacyjnych portalach firmowych. Ostatnim razem pokazaliśmy, jak skonfigurować bezpieczną autoryzację na serwerze webowym IIS.

W komentarzach prosiliście, abyśmy napisali instrukcję dla najpopularniejszych serwerów webowych w systemie Linux — nginx i Apache.

Proszono nas — napisaliśmy.

Co trzeba, żeby zacząć?

• Każda nowoczesna dystrybucja Linuxa. Wykonywałem testową konfigurację w MX Linux 18.2_x64. To oczywiście nie jest dystrybucja serwerowa, ale w Debianie raczej nie będzie dużych różnic. W innych dystrybucjach drogi do bibliotek mogą się nieco różnić.
• Token. Nadal korzystamy z modelu Routoken ECP PKI, który idealnie nadaje się pod względem wydajności do zastosowań korporacyjnych.
• Aby pracować z tokenem w Linuxie, należy zainstalować następujące pakiety:
  libccid libpcsclite1 pcscd pcsc-tools opensc

Wydawanie certyfikatów

W poprzednich artykułach opieraliśmy się na tym, że certyfikaty serwera i klientów będą wydawane za pomocą Microsoft CA. Ale skoro konfigurujemy wszystko w Linux, to przy okazji opowiemy o alternatywnym sposobie wydawania tych certyfikatów — nie opuszczając Linux.
Jako CA będziemy używać XCA (https://hohnstaedt.de/xca/), który jest dostępny w każdej nowoczesnej dystrybucji Linux. Wszystkie czynności, które będziemy wykonywać w XCA, można także zrealizować w trybie wiersza poleceń za pomocą narzędzi OpenSSL i pkcs11-tool, ale dla większej prostoty i przejrzystości w tym artykule nie będziemy ich podawać.

Rozpoczęcie pracy

1. Instalujemy:

   $ apt-get install xca

2. I uruchamiamy:

   $ xca

3. Tworzymy naszą bazę danych dla CA — /root/CA.xdb
   Zalecamy przechowywanie bazy danych Certyfikatu Władzy w folderze, do którego ma dostęp tylko administrator. Jest to ważne dla ochrony prywatnych kluczy głównych certyfikatów, które są używane do podpisywania wszystkich innych certyfikatów.

Tworzymy klucze i certyfikat root CA

Na bazie infrastruktury kluczy publicznych (PKI) opiera się hierarchiczny system. Głównym w tym systemie jest główny urząd certyfikacji lub root CA. Jego certyfikat trzeba stworzyć jako pierwszy.

1. Tworzymy dla CA prywatny klucz RSA-2048. W tym celu przechodzimy do zakładki Klucze prywatne kliknij Nowy klucz i wybieramy odpowiedni typ.
2. Podajemy nazwę dla nowej pary kluczy. Nazwałem ją — CA Key.
3. Wydajemy certyfikat CA, korzystając z utworzonej pary kluczy. W tym celu przechodzimy do zakładki Certyfikaty i klikamy Nowy certyfikat.
4. Z obowiązkowym wyborem SHA-256, ponieważ używanie SHA-1 nie może być już uważane za bezpieczne.
5. Obowiązkowo wybieramy jako szablon [default] CA. Nie zapomnij kliknąć na Zastosuj wszystkie, w przeciwnym razie szablon nie zostanie zastosowany.
6. Na karcie Temat wybieramy naszą parę kluczy. Tam także możesz wypełnić wszystkie podstawowe pola certyfikatu.

Tworzymy klucze i certyfikat serwera https

1. Analogicznie tworzymy dla serwera prywatny klucz RSA-2048, nazwałem go — Klucz Serwera.
2. Podczas tworzenia certyfikatu wybieramy, że certyfikat serwera musi być podpisany certyfikatem CA.
3. Nie zapominamy wybrać SHA-256.
4. Obowiązkowo wybieramy jako szablon [default] HTTPS_server. Klikamy na Zastosuj wszystkie.
5. Następnie na zakładce Temat wybieramy nasz klucz i wypełniamy potrzebne pola.

Tworzymy klucze i certyfikat dla użytkownika

1. Prywatny klucz użytkownika będzie przechowywany na naszym tokenie. Aby z nim pracować, należy zainstalować bibliotekę PKCS#11 z naszej strony. Dla popularnych dystrybucji oferujemy gotowe pakiety, które znajdują się tutaj — https://www.rutoken.ru/support/download/pkcs/. Mamy również wersje dla arm64, armv7el, armv7hf, e2k, mipso32el, które można znaleźć w naszym SDK — https://www.rutoken.ru/developers/sdk/. Oprócz wersji dla linuxa, mamy też wersje dla macOS, freebsd i androida.
2. Dodajemy nowego dostawcę PKCS#11 do XCA. W tym celu przechodzimy do menu Options na zakładkę Dostawca PKCS#11.
3. Klikamy Dodaj i wybieramy ścieżkę do biblioteki PKCS#11. W moim przypadku to usrlibrtpkcs11ecp.so.
4. Będziemy potrzebować sformatowanego tokena RUToken ECDSA PKI. Pobieramy narzędzie rtAdmin — https://dev.rutoken.ru/pages/viewpage.action?pageId=7995615
5. Wykonujemy

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

6. Wybieramy typ klucza — klucz RSA-2048 na RUToken ECDSA PKI. Nazwałem ten klucz Klucz Klienta.

   

7. Wprowadzamy kod PIN. I czekamy na zakończenie sprzętowej generacji pary kluczy.

   

8. Certyfikat dla użytkownika tworzymy analogicznie do certyfikatu serwera. Tym razem wybieramy szablon [default] HTTPS_client i nie zapominamy kliknąć Zastosuj wszystkie.
9. Na karcie Temat wprowadzamy informacje o użytkowniku. Na pytanie o zapisz certyfikat na tokenie odpowiadamy twierdząco.

W rezultacie na zakładce Certyfikaty w XCA powinno powstać mniej więcej takie zdjęcie.

Ten minimalny zestaw kluczy i certyfikatów wystarczy, aby przejść do konfiguracji serwerów.

Aby skonfigurować, musimy wyeksportować certyfikat CA, certyfikat serwera oraz prywatny klucz serwera.

W tym celu należy wybrać odpowiedni wpis na odpowiedniej zakładce w XCA i nacisnąć Eksport.

Nginx

Nie będę opisywał, jak zainstalować i uruchomić serwer nginx — w internecie jest wystarczająco dużo artykułów na ten temat, nie wspominając o oficjalnej dokumentacji. Przejdźmy od razu do konfiguracji HTTPS i dwuetapowej autoryzacji za pomocą tokenu.

Dodajemy następujące linie do sekcji server w 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;
}

Szczegółowy opis wszystkich parametrów związanych z konfiguracją SSL w nginx można znaleźć tutaj — https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

Krótko opiszę tylko te, które sam ustawiłem:

• ssl_verify_client — wskazuje, że należy sprawdzić łańcuch zaufania dla certyfikatu.
• ssl_verify_depth — określa głębokość poszukiwania zaufanego certyfikatu głównego w łańcuchu. Ponieważ nasz certyfikat klienta jest od razu podpisany certyfikatem głównym, głębokość wynosi 1. Jeśli certyfikat użytkownika jest podpisywany przez pośrednie CA, to w tym parametrze należy ustawić 2, i tak dalej.
• ssl_client_certificate — wskazuje ścieżkę do zaufanego certyfikatu głównego, który jest używany podczas weryfikacji zaufania do certyfikatu użytkownika.
• ssl_certificate/ssl_certificate_key — wskazują ścieżkę do certyfikatu/klucza prywatnego serwera.

Nie zapominamy wykonać nginx -t, aby sprawdzić, czy w konfiguracji nie ma literówek, a wszystkie pliki znajdują się tam, gdzie powinny itd.

I w zasadzie to wszystko! Jak widać, konfiguracja jest bardzo prosta.

Sprawdzamy działanie w Firefoxie.

Skoro wszystko robimy w systemie Linux, to załóżmy, że nasi użytkownicy również pracują w Linuxie (jeśli mają Windows, to zobacz instrukcję konfiguracji przeglądarek w poprzednim artykule..

1. Uruchamiamy Firefoxa.
2. Spróbujmy najpierw zalogować się bez tokenu. Otrzymujemy taki obrazek:

   

3. Wchodzimy na about:preferences#privacy, a następnie przechodzimy do Security Devices…
4. Klikamy Ładowanie, aby dodać nowy PKCS#11 Device Driver i podajemy ścieżkę do naszej librtpkcs11ecp.so.
5. Aby sprawdzić, czy certyfikat jest widoczny, można wejść do Certificate Manager. Pojawi się prośba o wprowadzenie kodu PIN. Po poprawnym wprowadzeniu można sprawdzić, czy na karcie Your Certificates pojawił się nasz certyfikat z tokena.
6. Teraz wchodzimy z tokenem. Firefox proponuje wybór certyfikatu, który zostanie wybrany na serwerze. Wybieramy nasz certyfikat.

   

7. ZYSK!

   

Konfiguracja jest wykonywana tylko raz, a jak można zobaczyć w oknie żądania certyfikatu, możemy zachować nasz wybór. Po tym, przy każdym logowaniu do portalu, wystarczy wprowadzić token i podać kod PIN użytkownika, który został ustawiony podczas formatowania. Po takiej uwierzytelnieniu serwer już wie, który użytkownik się zalogował i nie trzeba już wykonywać dodatkowych okienek weryfikacyjnych, a od razu wpuszczać użytkownika do jego panelu użytkownika.

Apache

Podobnie jak w przypadku nginx, nikt nie powinien mieć problemów z instalacją apache. Jeśli nie wiesz, jak zainstalować ten serwer webowy, po prostu skorzystaj z oficjalnej dokumentacji.

Przystępujemy do konfiguracji naszego HTTPS i uwierzytelnienia dwuetapowego:

1. Na początek należy aktywować mod_ssl:

   $ a2enmod ssl

2. A następnie włączyć domyślne ustawienia HTTPS witryny:

   $ a2ensite default-ssl

3. Teraz edytujemy plik konfiguracyjny: /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

   Jak widać, nazwy parametrów prawie pokrywają się z nazwami parametrów w nginx, więc nie będę ich tłumaczyć. Znowu, kto jest zainteresowany szczegółami – zapraszam do dokumentacji.
   Teraz restartujemy nasz serwer:

   $ service apache2 reload
   $ service apache2 restart

Jak widać, skonfigurowanie uwierzytelnienia dwuetapowego na dowolnym serwerze webowym, czy to w Windows, czy w Linux, trwa maksymalnie godzinę. A konfiguracja przeglądarek zajmuje około 5 minut. Wiele osób uważa, że konfiguracja i praca z uwierzytelnieniem dwuetapowym jest skomplikowana i niezrozumiała. Mam nadzieję, że nasz artykuł przynajmniej częściowo obala ten mit.

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.

Czy potrzebna jest instrukcja dotycząca konfiguracji pracy TLS z certyfikatami na GOST 34.10-2012:

• Tak, TLS-GOST jest bardzo potrzebny

• Nie, konfiguracja z algorytmami GOST mnie nie interesuje

Głosowało 44 użytkowników. 9 użytkowników wstrzymało się od głosu.

Źródło: habr.com