1. Csatlakoztassa az USB tokent a számítógépéhez.
2. Az USB-token modell nevének meghatározásához nyissa meg Terminálés írja be a parancsot:

Ennek eredményeként az USB-token modell neve megjelenik a Terminál ablakban:

Ügyeljen arra, hogy használja: Aktiv Rutoken ECP

Bevezetés

A Pluggable Authentication Modules (PAM) megosztott könyvtárak halmaza, amelyek lehetővé teszik különböző alacsony szintű hitelesítési módszerek integrálását egyetlen magas szintű API-ba. Ez lehetővé teszi számunkra, hogy egységes mechanizmusokat biztosítsunk a kezeléshez, beágyazáshoz alkalmazási programok a hitelesítési folyamatba.

A PAM beállításának általános eljárása a következő:

1. Létrehozzon egy RSA kulcspárt a tokenen (tesztelték, hogy működik-e 2048 bites kulcshosszon, 1024 bittel voltak problémák)
   
2. Ha tanúsítványra van szükség, akkor az OpenSSL vagy más szoftver segítségével állítson elő egy tanúsítványt, és írja be a tokenbe
3. Írd le nyilvános kulcs vagy tanúsítványt a kívánt címtárba
   

A végén így néz ki:

Előzetes felkészítés

A munka demonstrációja Ubuntu 18.04-en történik. A leírt műveletsor az Ubuntu és Debian alapú rendszerek más verzióira is vonatkozik.

A PAM modul konfigurálásához telepítenie kell a következő csomagokat:

• dbcd
• OpenSC
• OpenSSL
• libpam-p11
• libengine-pkcs11-openssl

Sudo apt-get install pcscd opensc openssl libpam-p11 libengine-pkcs11-openssl

A Rutoken S felhasználóknak a webhelyünkről is telepíteniük kell az illesztőprogramot.

Általános eljárás

A pam_p11 beállítása

Mielőtt elkezdené dolgozni a tokennel, konfigurálja a pam_p11 modult:

Fájl létrehozása /usr/share/pam-configs/p11 a következő tartalommal:

Név: Pam_p11 Alapértelmezés: yes Prioritás: 800 Auth-Type: Elsődleges hitelesítés: elegendő pam_p11_opensc.so /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

Ha nem Ubuntu 18.04-et használ, akkor ellenőriznie kell az opensc-pkcs11.so helyét. Lehet, hogy pl

/usr/lib/opensc-pkcs11.so. Ha nem találja, használja a find parancsot

PAM konfiguráció frissítése:

Sudo pam-auth-update

1. A megjelenő párbeszédpanelen meg kell győződnie arról, hogy a pam_p11 van kiválasztva. Ha szeretné letiltani a jelszavas hitelesítést, letilthatja a Unix hitelesítést.

   Kulcsok létrehozása tokenen

Készítsünk egy tokent.

$ pkcs15-init -E $ pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk "" $ pkcs15-init --store-pin --label "Felhasználói PIN" --auth- id 02 --pin "12345678" --puk "" --so-pin "87654321" --finalize

A pin és so-pin paraméterekben megadhatja a kívánt felhasználói és rendszergazdai PIN kódokat.

Létrehozunk egy 2048 bites RSA kulcspárt „45” azonosítóval (érdemes megjegyezni az azonosítót, szükség lesz rá a tanúsítvány készítésekor). A token hitelesítés a felhasználói entitás alatt történik.

$ pkcs15-init --generate-key rsa/2048 --auth-id 02 --id 45<вводим PIN пользователя>

Ellenőrizzük a generált kulcsot:

$ pkcs15-tool --list-keys Olvasó használata kártyával: Aktiv Rutoken ECP 00 00 Privát RSA Key Object Flags: , private, módosítható Használat: , sign Access Flags: , érzékeny, alwaysSensitive, neverExtract, local ModLength: 2048 Key ref. : 1 (0x1) Natív: igen Elérési út: 3f001000100060020001 Auth ID: 02 ID: 45

Tanúsítvány létrehozása és importálása tokenbe

2. Indítsa el az openssl-t

   A pkcs11 támogatási modul betöltése:

   OpenSSL> motor dinamikus -elő 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:/usr/lib/x86_64- linux-gnu/opensc-pkcs11.so (dinamikus) Dinamikus motorbetöltési támogatás : SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so : ID:pkcs11 : LIST_ADD:1 : LOAD : MODULE_PATH /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so Betöltve: (pkcs11) pkcs11 motor OpenSSL>

   Ha nem Ubuntu 18.04-et használ, ellenőriznie kell a pkcs11.so helyét. Megtalálható például a /usr/lib/openssl/engines/ könyvtárban. Ha nem találja, használja a find parancsot

   Hozzon létre egy önaláírt tanúsítványt PEM formátumban:

   OpenSSL> req -engine pkcs11 -új -kulcs 0:45 -keyform engine -x509 -out cert.pem -text

   Ahol 0:45 a slot:id pár (ezt az 5. lépésben jeleztük). Az OpenSSL felkéri a PIN-kód megadására és a tanúsítvány adatainak kitöltésére. Ha hibaüzenetet kap, ellenőrizze, hogy nincs-e más USB-token vagy intelligenskártya-olvasó csatlakoztatva a számítógépéhez.

   Ellenőrizzük a létrehozott tanúsítványt. Az aktuális könyvtárban létre kell hozni egy cert.pem nevű önaláírt tanúsítványfájlt.
   Megjegyzés: ha eltávolítja az -x509 kulcsot, amikor tanúsítványt hoz létre az OpenSSL-ben, akkor a kimenet egy tanúsítvány alkalmazás lesz.

   jegyzet

   A felhasználó kiválasztásának szakaszában előfordulhat, hogy a csatlakoztatott tokennel kapcsolatos információk nem frissülnek dinamikusan. Ha csatlakoztatott egy tokent, és nem látja a PIN-kód beviteli mezőjét, előfordulhat, hogy át kell állítania a fókuszt a „vendég munkamenetre”, majd vissza a felhasználóra.

Ha Ön Linux rendszergazda és szeretné maximalizálni szerverei és asztali számítógépek, valószínűleg gondolt már a kétfaktoros hitelesítés használatára. Általánosságban elmondható, hogy mindenkinek erősen ajánlott a beállítás, mivel a kétfaktoros hitelesítés jelentősen megnehezíti a támadók hozzáférését a gépekhez.

A Linux lehetővé teszi a számítógép konfigurálását úgy, hogy ne tudjon bejelentkezni a konzolba, az asztalra vagy a Secure Shell-en keresztül a géphez társított kétfaktoros hitelesítési kód nélkül. Nézzük meg a teljes beállítási folyamatot a rendszeren Ubuntu szerver 16.04.

Bevezetés

Mielőtt elkezdené, meg kell fontolnia egy tényt – miután beállította a kéttényezős hitelesítést, nem fog tudni hozzáférni számítógépéhez harmadik fél által generált kódok nélkül. Minden alkalommal, amikor be szeretne jelentkezni, szüksége lesz okostelefonjára vagy segélyhívó kódokra, amelyeket a folyamat során konfigurálhat.

Szükségünk lesz egy Linux szerverre vagy asztali számítógépre. Győződjön meg arról, hogy a rendszer naprakész, és előre nem látható körülmények esetén biztonsági másolatot készítenek adatairól. Kéttényezős kódok létrehozásához használjuk harmadik féltől származó alkalmazás, mint például az Authy vagy a Google Authenticator. Hagyományosan a Google Authenticatort használjuk, amelyet először telepíteni kell.

Telepítés

Jelentkezzen be a rendszerbe, és kövesse az alábbi lépéseket:

1. Nyisson meg egy terminál ablakot.
2. Futtassa a parancsot: sudo apt install libpam-google-authenticator.
3. Írja be a sudo jelszavát, és nyomja meg az Enter billentyűt.
4. Ha a rendszer megerősítést kér, írja be az "y"-t, és nyomja meg az Enter billentyűt.
5. Várja meg, amíg a telepítés befejeződik.

Most itt az ideje, hogy beállítsa számítógépét kétfaktoros hitelesítésre.

Konfiguráció

Térjen vissza a terminál ablakba, és írja be a parancsot: sudo nano /etc/pam.d/common-auth. Adja hozzá a következő sort a fájl végéhez:

Mentse és zárja be ezt a fájlt.

Most be kell állítanunk a Google Authenticatort minden olyan felhasználó számára, akinek hozzáféréssel kell rendelkeznie a rendszerhez. Ehhez vissza kell térnie a terminálablakba, és annak a felhasználónak a nevében, akinek hozzáférést kíván adni, futtassa a google-authenticator parancsot. Itt néhány kérdésre kell válaszolnia.

Az első kérdés a következő: „Akarja-e, hogy a hitelesítési tokenek időalapúak legyenek (i/n)”. Válaszoljon "y"-re, és kap egy QR-kódot. Nyissa meg a kéttényezős alkalmazást az okostelefonon, és adja hozzá fiókotés olvassa be ezt a QR-kódot.

1. ábra Fogadott QR-kód

A kód hozzáadása után még mindig van néhány megválaszolandó kérdés:

• Szeretné, hogy frissítsem a "/home/jlwallen/.google_authenticator" fájlt (y/n) - Frissítse a /home/jlwallen/.google_authenticator fájlt;
• Meg akarja tiltani ugyanannak a hitelesítési tokennek a többszöri használatát (i/n)? - Szeretné letiltani egy token többszöri újrafelhasználásának lehetőségét? Ez a beállítás csak egy bejelentkezést tesz lehetővé 30 másodpercenként. Ha ez az opció be van kapcsolva, megnő az esélye annak, hogy észreveszi vagy akár megakadályozza a „man-in-the-middle” támadást.
• Mivel az alapértelmezett érték 30 másodperc, és a szerver és a kliens idői kissé eltérhetnek, lehetséges további token használata. Ezért, ha problémái vannak a szinkronizálással, növelheti az ablak időtartamát körülbelül 4 percre. Szeretnéd ezt megtenni? - Akarja-e ezt (i/n).
• Ha nem biztos abban, hogy megvédi-e számítógépét a brute force támadásoktól, engedélyezheti a sebességkorlátozást a hitelesítési modul számára. Alapértelmezés szerint ez legfeljebb 3 bejelentkezési kísérlet 30 másodpercenként. Szeretné engedélyezni a sebességkorlátozást? - Szeretné engedélyezni a sebességkorlátozást (i/n)

Válaszoljon minden kérdésre igennel az „y” beírásával és az Enter megnyomásával.

SSH beállítása

A következő lépés az SSH beállítása kéttényezős hitelesítés. Ha kihagyja ezt a lépést, nem fog tudni bejelentkezni SSH-n keresztül.

Először engedélyeznie kell a PAM modult. Ehhez írja be a következő parancsot: sudo nano /etc/pam.d/sshd. A fájl megnyitása után adja hozzá a következő sort a fájl végéhez:

hitelesítés szükséges pam_google_authenticator.so nullok

Mentse el ezt a fájlt, majd futtassa a parancsot: sudo nano /etc/ssh/sshd_config. Ebben a fájlban a következőket találjuk:

ChallengeResponseAuthentication sz

És módosítsd a következőre:

ChallengeResponseAuthentication igen

Mentse el ezt a fájlt, és indítsa újra az sshd-t - sudo systemctl indítsa újra az sshd-t.

Belépés

Kijelentkezés előtt erősen javasoljuk, hogy nyisson meg egy új terminálablakot, és próbáljon meg SSH-n keresztül bejelentkezni. Ha ez nem sikerül, ismételje meg a fenti lépéseket, és győződjön meg arról, hogy nem hagyott ki semmit. Miután sikeresen bejelentkezett SSH-n keresztül, kijelentkezhet, majd újra bejelentkezhet.

következtetéseket

Nemrég változtattunk egy felhasználói jelszót Linuxon, amikor hibát észleltünk: Hitelesítési token manipulációs hiba.

A normál passwd parancsot használtuk a jelszó megváltoztatásához, és ez ezt a hibát adta, és a jelszó nem változott.

Sudo passwd my_user_name Felhasználó jelszavának megváltoztatása my_user_name felhasználó jelszavának módosítása tecmint (jelenlegi) UNIX jelszó: passwd: Hitelesítési token manipulációs hiba passwd: jelszó változatlan

A hitelesítési token manipulációs hibájának javítása az Ubuntuban

„Authentication Token Manipulation Error” azt jelenti, hogy a jelszómódosítás valamilyen okból meghiúsult.

Ennek több oka is lehet. Egyszerű esetekben magában a kimenetben láthatja a probléma kiváltó okát. Például, ha nem adott meg jelszót, akkor azt látnia kell a hibaüzenetben:

Nincs megadva jelszó passwd: Hitelesítési jogkivonat manipulációs hiba passwd: jelszó változatlan

Hasonlóképpen, ha a jelszó újbóli megadása nem egyezik, akkor ez az információ is megjelenik:

Sajnáljuk, a jelszavak nem egyeznek: passwd: Hitelesítési token manipulációs hiba passwd: jelszó változatlan

Ez egyszerű, mert tudja, mi okozta a problémát, és ennek alapján megteheti a helyesbítő lépéseket. De lehet, hogy nem mindig lesz szerencséje, mert bizonyos esetekben nem fog ilyet látni hasznos információ, csak hiba.

Nézzünk meg néhány ilyen esetet, és javítsuk ki ezt a problémát.

1. módszer

Ha ismeri a Linux könyvtárszerkezetét, tudja, hogy az /etc/shadow könyvtár titkosított formátumban tárolja a jelszót a felhasználókkal és jelszavaikkal kapcsolatos egyéb információkkal együtt.

Emiatt meg kell győződnie arról, hogy rendelkezik a fájl olvasási és írási jogosultságával. Mivel szuperfelhasználóként módosítja a jelszót, ennek a fájlnak rendelkeznie kell a root olvasási és írási jogosultságával.

Ha nem, akkor be kell állítania a megfelelő felbontást:

Sudo chmod 640 /etc/shadow

2. módszer

Az 1. módszer a legtöbb esetben működik. De a mi esetünkben újra kellett csatolnunk a gyökérpartíciót olvasási és írási jogosultsággal. Megpróbáltuk visszaállítani a rendszergazdai jelszót az Ubuntuban.

Mount -rw -o remount /

Egyes ritka esetekben előfordulhat, hogy a lemez annyira megtelt, hogy nem tudja módosítani az /etc/shadow fájlt. De ha ez a helyzet, akkor sok más problémával kell szembenéznie.

Ez bevált neked?

Megosztottuk, mi vált be nekünk, és csak remélni tudjuk, hogy neked is bevált. Megcsináltad? Melyik módszer vált be nálad? Említse meg a megjegyzésekben.

2020-tól tilos a GOST R 34.10-2001 szerinti titkosítás használata, ami azt jelenti, hogy minden kormányzati szervvel együttműködő szervezet kénytelen sürgősen végrehajtani a következő szabványt - 2012. Ha az egyikben dolgozik, akkor ne menjen el: ebben a cikkben arról fogunk beszélni, hogyan lehet megoldani a problémát szerver használatával a CentOS 7 és CryptoPro csomag JCP.

Ha most hall először erről az egészről, akkor itt egy kis történelmi háttér.

1994-ben az FSB számos szabványt és intézkedést dolgozott ki a szervezetek és a folyamat többi résztvevője közötti dokumentumcsere védelmére. Az egyik ilyen biztonsági intézkedés a dokumentumok elektronikus digitális aláírása volt, az egyik szabvány pedig a GOST R 34.10-94, amely leírja az elektronikus létrehozásának és ellenőrzésének algoritmusát. digitális aláírás. Az orosz állami szabvány 1994. május 23-i, 154. számú rendeletével fogadták el és léptették hatályba, és 2001-ig működött.

Felváltotta a jól ismert GOST R 34.10-2001 - egy továbbfejlesztett szabvány, amelyet az algoritmus nagyobb stabilitásának biztosítására terveztek. De az idő nem áll meg, a kriptográfiai védelem algoritmusai és módszerei változnak, és tizenegy évvel később a GOST R 34.10-2001 GOST R 34.10-2012-re változik.

Az új szabványban a paraméterkövetelmények első változata változatlan marad. A titkos kulcs hossza körülbelül 256 bit, és 256 vagy 512 bites hash kóddal lehet hash függvényt használni. A fő különbség az új szabvány között az opciókban rejlik további paraméterekés sémák, beleértve a kivonatolást a GOST R 34.11-2012 „Stribog” szabvány szerint.

INFO

Stribog az ősi szlávok istene, aki pártfogolja a szeleket, az időjárást és mindent, ami a légtérrel kapcsolatos. Talán felhő technológiák Azonos. További információ erről a titkosításról a „” és „” cikkekben található.

2014 februárjában az FSB bejelentette az új nemzeti szabvány GOST R 34.10-2012 használatára való áttérés megkezdését. Elektronikus aláírásállamtitkot nem tartalmazó információkra. Megjelent a 2014. január 31-i 149/7/1/3-58 számú „Az új digitális aláírási szabványok és kivonatolási funkciók használatára való áttérés rendjéről” című dokumentum, amely az alábbi követelményeket állapította meg.

1. 2013. december 31. után hagyja abba az elektronikus aláírási eszközökre vonatkozó, az oroszországi FSB 2011. december 27-i 796. számú rendeletében jóváhagyott elektronikus aláírási eszközökre vonatkozó követelményeknek való megfelelés tanúsítását, ha ezek az eszközök nem biztosítják a funkciók megfelelő végrehajtását. a GOST R 34.10-2012.
2. 2018. december 31. után tiltsa meg a GOST R 34.10-2001 használatát elektronikus aláírás generálására.

A Hírközlési Minisztérium még tervet is készített a szabványra való átállásról (PDF). A gyakorlatban azonban kiderült, hogy nem minden olyan egyszerű, és az átállást 2019. december 31-ig kellett elhalasztani. Az okok a következők.

1. Sok állami és önkormányzati hatóság nem áll készen az új GOST-2012 elektronikus aláírási szabványra való átállásra a szoftverszintű támogatás hiánya miatt.
2. Új tanúsítványok kiállításához olyan berendezésekre van szükség, amelyek támogatják új GOST, valamint a vezető tanúsító hatóság tanúsítványa, amelyet a GOST-2012 használatával hoztak létre. A tanúsító központok csak 2018 nyarán kapták meg. További időre van szükség a tanúsítványok minden felhasználó számára történő kiadásához.

Jelenleg két kriptográfiai védelmi szabvány van használatban: EDS munka, de a GOST-2001-et használóknak sürgősen tenniük kell valamit. A tél, ahogy mondják, jön, és ez azt jelenti, hogy tesztsorozat vár ránk a GOST-2012 támogatásának megvalósítása során.

Elmondom, hogyan telepíthetsz egy FSB-tanúsítvánnyal rendelkező CIPF-eszközt (CryptoPro JCP) egy Java JDK-t futtató Linux-kiszolgálón. Egyébként, ha még mindig GOST-2001-et használ, van egy csodálatos a CryptoPro honlapján, azt tanácsolom, olvassa el, nem lesz felesleges.

Minden dokumentumáramlás a csere résztvevői között az SMEV elv (osztályközi elektronikus interakció rendszere) szerint történik. Egy alkalmazás lehet résztvevője egy ilyen rendszernek, de lehet, hogy egyáltalán nem, ez nem változtat az iratcsere elvén. A könnyebb érthetőség kedvéért rajzoltam egy kis diagramot.

Árak

Mint mindig, most is felmerül egy szoftvermegoldás engedélyezésének kérdése. A CryptoPro JCP nem olcsó, és ha egy munkaállomás 1200 rubelbe kerül, akkor a szerverlicencek sokkal drágábbak - körülbelül 30 000 magonként (vagy két magonként) Intel processzor a Hyper Threading letiltásával).

Titkosító szolgáltató telepítése és konfigurálása

A példákban fogom használni Virtuális gép CentOS 7 rendszerrel, de a választása nem korlátozott hardverÉs Linux disztribúció. Minden művelet és parancs ugyanaz lesz.

Először is hozzunk létre egy helyi felhasználót, amely alatt a dokumentum-aláírást használó szoftver futni fog.

$ sudo useradd -d /opt/user -p<Тут указываем пароль>-s /bin/bash felhasználó; sudo grep felhasználó /etc/passwd

Telepítsük helyesen a Java JDK-t. Töltse le a szükséges disztribúciót.

$ wget --header "Cookie: oraclelicense=a" --content-disposition http://download.oracle.com/otn-pub/java/jdk/8u191-b12/2787e4a523244c269598db4e85c51e0-191-4taruxu191-4-8uxu .gz -O jdk-8u191-linux-x64.tar.gz

Csomagolja ki az archívumot, és ellenőrizze, hogy a Java mappa készen áll-e a másolásra.

$tar zxvf jdk-8u191-linux-x64.tar.gz; ls -al;

Másolja a mappát az alkalmazásszoftver részbe. Általában az /opt-ot használom.

$ sudo cp -rf jdk1.8.0_191 /opt/

Ellenőrizzük, hogy megfelelően másolták-e le. Ha szükséges, módosítsa a mappa tulajdonosát root-ra.

$ ls -al /opt/jdk1.8.0_191/ $ sudo chown -R root:root /opt/jdk1.8.0_191/; cd /opt/jdk1.8.0_191/; ls -al;

Regisztrálunk Környezeti változók Java JDK-hoz alapértelmezés szerint minden felhasználó számára.

$ sudo vi /etc/profile.d/oracle.sh

A fájlba a következőket írjuk:

JAVA_HOME=/opt/jdk1.8.0_191 exportálás export JRE_HOME=/opt/jdk1.8.0_191/jre export PATH=$PATH:/opt/jdk1.8.0_191/bin:/opt/jdk1.8.0_191/jre/

Ha a szerveren a Java JDK több verziója is található, akkor ehhez alternatívákat kell regisztrálni új verzió.

$ sudo alternatívák --install /usr/bin/java java /opt/jdk1.8.0_191/bin/java 2 $ sudo alternatívák --install /usr/bin/jar jar /opt/jdk1.8.0_191/bin/jar 2 $ sudo alternatívák --install /usr/bin/javac javac /opt/jdk1.8.0_191/bin/javac 2 $ sudo alternatívák --set jar /opt/jdk1.8.0_181/bin/jar $ sudo alternatívák --set jar /opt/jdk1.8.0_191/bin/jar $ sudo alternatívák --set javac /opt/jdk1.8.0_191/bin/javac $ sudo alternatívák --config java

A menüben válassza ki a 2. opciót (vagy azt, amelyik újabb használatához vezet Java verziók). Ne felejtse el kijavítani a JRE systemPrefs jogait.

$ sudo chmod 777 -R /opt/jdk1.8.0_191/jre/.systemPrefs

Ellenőrzés telepített verzió Jáva.

$ java -verzió
Java verzió "1.8.0_191"
Java(TM) SE futási környezet (build 1.8.0_191-b12)
Java HotSpot(TM) 64 bites szerver virtuális gép (25.191-b12 build, vegyes mód)

Másolja a mappát a CryptoPro JCP terjesztési készlettel az alkalmazásszoftver részbe.

$ sudo cp -rf jcp-2.0.40035 /opt/

Ellenőrizzük, hogy minden helyesen lett-e másolva.

$ ls -al /opt/jcp-2.0.40035/

Jogot adunk a szkriptek futtatásához.

$ sudo chmod +x /opt/jcp-2.0.40035/*.sh

Ellenőrizzük a mappa tulajdonosát és jogait, rootnak kell lennie. Menjünk bele.

$ ls -al /opt/jcp-2.0.40035/; cd /opt/jcp-2.0.40035/;

A telepítési problémák elkerülése érdekében ellenőrizze a processzor magjainak számát és a licencet. A magok számát az nproc paranccsal tudod megtudni.

Térjünk át a JCP titkosítási szolgáltató telepítésére. A telepítés során számos kérdésre kell válaszolnia.

A folytatás csak a tagok számára elérhető

1. lehetőség: Csatlakozzon a „webhely” közösséghez, hogy elolvassa az oldalon található összes anyagot

A meghatározott időszakon belüli közösségi tagság hozzáférést biztosít az ÖSSZES Hacker anyaghoz, növeli a személyes kumulatív kedvezményt, és lehetővé teszi, hogy professzionális Xakep Score értékelést gyűjtsön!