A kriptográfiai token hálózati megosztása usbip alapú felhasználók között

A bizalmi szolgáltatásokkal kapcsolatos jogszabályi változásokkal kapcsolatban („Az elektronikus bizalmi szolgáltatásokról” Ukrajna) a vállalkozásnak több részlegre van szüksége, hogy tokeneken elhelyezett kulcsokkal dolgozzon (jelenleg a hardverkulcsok számának kérdése még nyitott ).

A legalacsonyabb költségű (ingyenes) eszközként azonnal esett a választás usbip. Az Ubintu 18.04 szervere a kiadványnak köszönhetően elkezdett működni USB/IP megszelídítése és több flash meghajtón is sikeresen tesztelték (akkori token hiánya miatt). A monopóliumtulajdonláson (a felhasználó számára fenntartott foglaláson) kívül semmilyen különleges probléma nem merült fel ekkor. Nyilvánvaló, hogy ahhoz, hogy több felhasználó (kezdetben legalább kettő) hozzáférését megszervezzük, meg kell osztani a hozzáférésüket időben, és felváltva kell őket dolgozni.

A kérdés a következő volt: Hogyan csináljam a legkevesebb tánccal úgy, hogy minden mindenkinek menjen...

A rész ügyetlen

A kriptográfiai token hálózati megosztása usbip alapú felhasználók között
XNUMX.opció. Számos parancsikon a bat fájlokhoz, nevezetesen
a) A hozzáférési kulcs csatlakoztatása.
b) Szándékos lekapcsolás.

Bekezdés "б» ellentmondásos, ezért úgy döntöttek, hogy a kulccsal való munkaidőt 3 percben adják meg.

Az usbip kliens sajátossága, hogy indítása után a konzolban lógva marad, a konzol munkamenet megszakítása nélkül "nagyjából" lezárható a kapcsolat kliens oldalról és szerver oldalról is.

Íme, ami nekünk bevált:

először: kapcsolat on.bat

usbip -a 172.16.12.26 4-1
msg * "Подпись/токен недоступны или заняты "

második: leállítás off.bat

ping 127.0.0.1 -n 180
taskkill /IM usbip.exe /F

A felhasználó tudatára való támaszkodás nélkül a szkripteket egyesítették token.bat

on.bat | off.bat

Mi történik: az összes fájl ugyanabban a mappában van, amelyet a token.bat fájl indított el, a kapcsolat megszakadása esetén a felhasználó azonnal üzenetet kap a kulcs elérhetetlenségéről, más esetben csak 180 ping után. A fenti kódsorok felszerelhetők az „@ECHO OFF” felirattal és a konzolirány „> null”-ra, hogy a felhasználót ne sokkoljuk túlságosan, de nem szükséges tesztelni. Az USB-meghajtón végzett kezdeti „futás” azt mutatta, hogy minden kiszámítható, megbízható és világos. Sőt, nincs szükség semmilyen manipulációra a szerver oldaláról.

A kriptográfiai token hálózati megosztása usbip alapú felhasználók között

Természetesen a tokennel való közvetlen munka során minden nem a várt módon ment: az eszközkezelő fizikai kapcsolata esetén a token 2 eszközként (WUDF és intelligens kártya), hálózati kapcsolat esetén pedig csak WUDF-ként van regisztrálva (bár ez elég a PIN kód kéréséhez).

A kriptográfiai token hálózati megosztása usbip alapú felhasználók között

Az is kiderült, hogy a brutális "taskkill" nem olyan súlyos, és a kapcsolat lezárása a kliensen problémás, és még ha sikerült is, akkor sem garantálja, hogy a szerveren lezárja.

Miután az összes konzolt feláldozta az ügyfélen, a második szkript a következő formát öltötte:

ping 127.0.0.1 -n 180 > nul
taskkill /IM usbip.exe /F /T  > nul
ping 127.0.0.1 -n 10 > nul
taskkill /IM conhost.exe /F /T  > nul

bár hatékonysága 50% alatti, mivel a szerver makacsul továbbra is nyitottnak tekintette a kapcsolatot.

A kapcsolattal kapcsolatos problémák a szerveroldal frissítésével kapcsolatos gondolatokhoz vezettek.

Szerver rész

Mire van szüksége:

  1. Válassza le az inaktív felhasználókat a szolgáltatásról.
  2. Nézze meg, ki használja jelenleg (vagy még mindig kölcsönzi) a tokent.
  3. Ellenőrizze, hogy a token magához a számítógéphez csatlakozik-e.

Ezeket a problémákat a crontab és az apache szolgáltatások segítségével sikerült megoldani. A minket érdeklő 2. és 3. pont megfigyelési eredményeinek újraírásának diszkrét jellege azt jelzi, hogy a fájlrendszer a ramdrive-on található. Sor hozzáadva az /etc/fstab fájlhoz

tmpfs   /ram_drive      tmpfs   defaults,nodev,size=64K         0       0

Létrejött egy szkriptmappa a szkriptekkel a gyökérben: az usb_restart.sh token leválasztása-csatolása

usbip unbind -b 1-2
sleep 2
usbip bind -b 1-2
sleep 2
usbip attach --remote=localhost --busid=1-2
sleep 2
usbip detach --port=00

az aktív eszközök listájának lekérése usblist_id.sh

usbip list -r 127.0.0.1 | grep ':' |awk -F ":" '{print $1}'| sed s/' '//g | grep -v "^$" > /ram_drive/usb_id.txt

az aktív IP-címek listájának beszerzése (a felhasználói azonosítók megjelenítéséhez szükséges utólagos módosításokkal) usbip_client_ip.sh

netstat -an | grep :3240 | grep ESTABLISHED|awk '{print $5}'|cut -f1 -d":" > /ram_drive/usb_ip_cli.txt

maga a crontab így néz ki:

*/5 * * * * /!script/usb_restart.sh > /dev/null 2>&1
* * * * * ( sleep 30 ; /!script/usblist_id.sh > /dev/null)
* * * * * (sleep 10 ; /!script/usbip_client_ip.sh > /dev/hull)

Így van: 5 percenként új felhasználó csatlakozhat, függetlenül attól, hogy ki dolgozott a tokennel. A /ramdrive mappa egy symlink segítségével kapcsolódik a http szerverhez, amelyben 2 szöveges fájl van elmentve, amelyek az usbip szerver állapotát mutatják.

Következő rész: „Csúnya a csomagolásban”

lehetőség II. Egy kicsit a felhasználó kedvében járni legalább valami kevésbé félelmetes felülettel. Zavarba ejti az a tény, hogy a felhasználók különböző Windows-verziókkal rendelkeznek, eltérő keretrendszerrel, más jogokkal, kevésbé problémás megközelítéssel, mint Lázár Nem találtam (természetesen C#-ra vagyok, de ebben az esetben nem). A denevérfájlokat a háttérben a felületről indíthatjuk, minimálisra csökkentve, de megfelelő tesztelés nélkül, én személy szerint azon a véleményen vagyok: vizualizálni kell, hogy összegyűjtse a felhasználói elégedetlenséget.

A kriptográfiai token hálózati megosztása usbip alapú felhasználók között

Az alábbi feladatokat oldotta meg a felület és a szoftver:

  1. Megjeleníti, hogy a token éppen foglalt-e.
  2. Az első indításkor a kezdeti beállítás magában foglalja a „helyes” bat fájlok létrehozását, amelyek megvalósítják a munkamenet elindítását és megszakítását a tokenkiszolgálóval. A későbbi indításoknál a „szerviz” mód megvalósítása jelszó használatával.
  3. A szerverrel való kapcsolat meglétének ellenőrzése, melynek eredményeként lekérdezi, hogy foglalt-e, vagy üzeneteket jelenít meg a problémákról. Amikor a kommunikáció újraindul, a program automatikusan normál üzemmódban kezd működni.

A WEB-szerverrel való munkavégzés a további fphttpclient beépülő modul segítségével valósul meg.


itt lesz egy link a kliens aktuális verziójához

további megfontolások is vannak a cikk témájával kapcsolatban, valamint a kezdeti részleges lelkesedés a VirtualHere termék iránt a szolgáltatásaival...

Forrás: will.com

Hozzászólás