A a vállalati portálok kéttényezős hitelesítésének fontosságáról beszéltünk. Legutóbb bemutattuk, hogyan állíthatjuk be a biztonságos hitelesítést az IIS webkiszolgálón.
A hozzászólások között kérték, hogy készítsünk útmutatót a legelterjedtebb Linux alapú webkiszolgálók — nginx és Apache — számára.
Kértétek — megírtuk.
Mi szükséges a kezdethez?
- Bármely modern Linux disztribúció. Én az MX Linux 18.2_x64 tesztbeállítását végeztem. Ez ugyan nem szerver disztribúció, de a Debian rendszerek között valószínűleg nem lesznek nagy eltérések. Más disztribúcióknál a könyvtárak és konfigurációk elérési útja kissé eltérhet.
- Token. Mi továbbra is azt a modellt használjuk, , amely a sebességi jellemzői miatt ideális vállalati felhasználásra.
- A token használatához Linux alatt a következő csomagokat kell telepíteni:
libccid libpcsclite1 pcscd pcsc-tools opensc
Tanúsítványok kiadása
A korábbi cikkeinkben alapvetően arra támaszkodtunk, hogy a szerverek és kliensek tanúsítványait Microsoft CA segítségével állítjuk ki. De mivel most mindent Linuxban állítunk be, bemutatjuk az alternatív módszert ezen tanúsítványok kiadására — anélkül, hogy elhagynánk a Linuxot.
CA-ként az XCA-t fogjuk használni (), amely bármely modern Linux disztribúcióban elérhető. Minden műveletet, amit az XCA-ban végzünk, parancssori módban is el lehet végezni az OpenSSL és pkcs11-tool segédprogramok segítségével, de az egyszerűség és áttekinthetőség kedvéért ebben a cikkben ezeket nem fogjuk bemutatni.
Munka kezdetek
- Telepítjük:
$ apt-get install xca - És indítsuk el:
$ xca - Létrehozzuk a CA adatbázisunkat — /root/CA.xdb
Javasoljuk, hogy a Certificate Authority adatbázisát olyan mappában tároljuk, amelyhez csak az adminisztrátor férhet hozzá. Ez fontos a gyökér tanúsítványok zárt kulcsainak védelmében, amelyek az összes többi tanúsítvány aláírásához használatosak.
Létrehozzuk a kulcsokat és a root CA tanúsítványt
A nyílt kulcsú infrastruktúra (PKI) alapját egy hierarchikus rendszer képezi. Ebben a rendszerben a fő szereplő a gyökér tanúsítványkibocsátó vagy root CA. A tanúsítványának létrehozása az elsődleges feladat.
- A CA számára létrehozzuk az RSA-2048 zárt kulcsot. Ehhez a Privát kulcsok kattintsunk Új kulcs fülön válasszuk ki a megfelelő típust.
- Adunk nevet az új kulcspárosnak. Én a CA Kulcs nevet adtam neki.
- Magát a CA tanúsítványt az elkészített kulcspárral állítjuk ki. Ehhez átváltunk a Tanúsítványok mellett, majd kattintsunk Új tanúsítvány.
- Kötelezően választjuk SHA-256, mert a SHA-1 használata már nem számít biztonságosnak.
- Kötelezően válasszunk mintaként [default] CA. Ne felejtsük el rákattintani a Minden alkalmazása, különben a minta nem kerül alkalmazásra.
- A Tárgy válasszuk ki a kulcspárunkat. Itt kitölthetjük a tanúsítvány összes alapvető mezőjét.
Létrehozzuk a https-szerverünk kulcsait és tanúsítványát
- Hasonló módon létrehozunk egy zárt RSA-2048 kulcsot a szerverhez, amit Server Key-nek neveztem el.
- A tanúsítvány létrehozásakor válasszuk, hogy a kiszolgáló tanúsítványát alá kell írni a CA tanúsítványával.
- Ne felejtsük el választani SHA-256.
- Mintaként válasszuk [default] HTTPS_server. Kattintsunk a Minden alkalmazása.
- Ezután a Tárgy fülön válasszuk ki a kulcsunkat és töltsük ki a szükséges mezőket.
Létrehozzuk a felhasználó kulcsait és tanúsítványát
- A felhasználó zárt kulcsa a tokenünkön lesz tárolva. A használatához telepítenünk kell a PKCS#11 könyvtárat a weboldalunkról. Népszerű disztribúciókhoz készen álló csomagokat biztosítunk, amelyek itt találhatók — . Arm64, armv7el, armv7hf, e2k, mipso32el csomagok is rendelkezésre állnak a SDK-nkban — . A linux mellett macOS, freebsd és android verziók is elérhetők.
- Új PKCS#11 Szolgáltatót adunk hozzá az XCA-hoz. Ehhez menjünk a menübe Options a PKCS#11 Szolgáltató.
- fülre. Ezután adja meg az Amazon S3-hoz való hozzáféréshez szükséges fiókot — válassza ki a meglévőt a listából, vagy kattintson Kattintsunk
- és válasszuk ki a PKCS#11 könyvtár útvonalát. Az én esetemben ez usrliblibrtpkcs11ecp.so.
- Végezzük el
Szükségünk lesz egy formázott Rútoken ÉCDP PKI tokenre. Töltsük le az rtAdmin eszközt — - $ rtAdmin -f -q -z /usr/lib/librtpkcs11ecp.so -u
- Kulcstípusként válasszuk — RSA-2048 kulcs a Rútoken ÉCDP PKI-n. Ezt a kulcsot Client Key-nek neveztem el.
- Adjuk meg a PIN-kódot. És várjunk a kulcspár hardveres generálásának befejezésére. A felhasználó számára tanúsítványt hasonlóan készítünk, mint a szerver tanúsítvány. Ezúttal válasszuk a [default] HTTPS_client Minden alkalmazása.
- A Tárgy mintát, és ne felejtsük el rákattintani.
töltsük ki a felhasználói információt. A tokenre való tanúsítvány mentésére vonatkozó kérdésre válaszoljunk igennel. Tanúsítványok Ennek eredményeként az XCA fülén nagyjából ilyen képnek kell lennie.
Ez a minimális kulcs- és tanúsítványkészlet elegendő ahhoz, hogy elkezdjük a szerverek közvetlen beállítását.
A beállításhoz ki kell exportálni a tanúsítványt az OÜ, a szerver tanúsítványát és a szerver zárt kulcsát.
Ehhez válasszuk ki a megfelelő bejegyzést a megfelelő fülön az XCA-ban és kattintsunk Export.
Nginx
Nem fogok írni arról, hogyan kell telepíteni és elindítani az nginx szervert — erre elég sok cikk található az interneten, nem is beszélve a hivatalos dokumentációról. Rögtön az HTTPS és a token alapú kétfaktoros hitelesítés beállításához kezdünk.
Adjunk hozzá a server szekcióhoz az nginx.conf fájlban az alábbi sorokat:
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;
}A ssl beállításokkal kapcsolatos összes paraméter részletes leírását itt találhatjuk —
Csak röviden leírom azokat, amelyeket magam állítottam be:
- ssl_verify_client — megadja, hogy a tanúsítványhoz szükséges a bizalmi lánc ellenőrzése.
- ssl_verify_depth — meghatározza a megbízható gyökér tanúsítvány keresésének mélységét a láncban. Mivel nálunk a kliens tanúsítvány közvetlenül a gyökér tanúsítványra van aláírva, ezért a mélység 1. Ha a felhasználó tanúsítványát egy közbenső CA írja alá, akkor ezt a paramétert 2-re kell állítani, és így tovább.
- ssl_client_certificate — jelzi a megbízható gyökér tanúsítványhoz vezető utat, amelyet a felhasználói tanúsítvány megbízhatóságának ellenőrzésénél alkalmaznak.
- ssl_certificate/ssl_certificate_key — a szerver tanúsítványához/zártkulcsához vezető utat adják meg.
Ne feledjük el futtatni az nginx -t, hogy ellenőrizzük, hogy a konfigurációban nincsenek hibák, és hogy minden fájl a megfelelő helyen található.
És valójában ennyi! Mint látható, a beállítás nagyon egyszerű.
Ellenőrizzük a működést Firefoxban
Mivel mindent teljesen Linux alatt csinálunk, feltételezzük, hogy a felhasználóink is Linuxot használnak (ha Windowsuk van, akkor .
- Indítsuk el a Firefoxot.
- Próbáljuk meg először token nélküli belépést. Ekkor ezt a képet kapjuk:
- Lépjünk be a about:preferences#privacy, majd keressük meg a Security Devices…
- fülre. Betöltés, hogy új PKCS#11 Eszközmeghajtót adjunk hozzá, és megadjuk a librtpkcs11ecp.so fájl elérési útját.
- A tanúsítvány ellenőrzésére beléphetünk a Certificate Manager. Megjelenik a PIN-kód megadásának kérése. A helyes megadás után ellenőrizhetjük, hogy a Your Certificates fülön megjelent a tokenünkkel rendelkező tanúsítványunk.
- Most tokennel lépünk be. A Firefox felajánlja a tanúsítvány kiválasztását, amely a szerveren lesz kiválasztva. Kiválasztjuk a tanúsítványunkat.
- NYERESÉG!
A beállítás egyszeri művelet, és ahogy a tanúsítványkérés ablakában is látszik, elmenthetjük a választásunkat. Ezután, amikor belépünk a portálra, csak be kell illesztenünk a tokent és meg kell adnunk a felhasználói PIN-kódot, amelyet a formázás során állítottunk be. Az ilyen hitelesítés után a szerver már tudja, hogy melyik felhasználó lépett be, így nem szükséges további ablakok megnyitása a belépés ellenőrzésére, hanem azonnal beengedhetjük a felhasználót a személyes fiókjába.
Apache
A nginx-hez hasonlóan az apache telepítése sem okozhat problémát senkinek. Ha nem tudja, hogyan telepítse ezt a webkiszolgálót, csak használja a hivatalos dokumentációt.
Most pedig nekilátunk a HTTPS és a kétfaktoros hitelesítés beállításának:
- Először is aktiválni kell a mod_ssl-t:
$ a2enmod ssl - Ezután aktiválni kell az alapértelmezett HTTPS beállításokat:
$ a2ensite default-ssl - Most szerkesztenünk kell a konfigurációs fájlt: /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 10Ahogy látható, a paraméterek nevei gyakorlatilag megegyeznek a nginx paramétereivel, ezért nem szükséges őket külön magyarázni. Ismételten, aki érdeklődik a részletek iránt – szívesen látjuk a dokumentációban.
Most újraindítjuk a szerverünket:$ service apache2 reload $ service apache2 restart
Látható, hogy a kétfaktoros hitelesítést bármely webkiszolgálón beállítani, akár Windows, akár Linux esetén egy órát maximum. A böngészők beállítása körülbelül 5 percet vesz igénybe. Sokan úgy vélik, hogy a kétfaktoros hitelesítés beállítása és használata bonyolult és érthetetlen. Remélem, hogy a cikkünk legalább egy kicsit cáfolja ezt a mítoszt.
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Szükség van-e útmutatóra a TLS tanúsítványokkal való működéshez a GOST 34.10-2012 szerint:
Igen, a TLS-GOST nagyon szükséges
Nem, a GOST-algoritmusokkal való beállítás nem érdekel
44 felhasználó szavazott. 9 felhasználó tartózkodott.
Forrás: habr.com
