Udostępnianie sieciowe tokena kryptograficznego pomiędzy użytkownikami korzystającymi z usbip

W związku ze zmianami przepisów dotyczących usług zaufania („O elektronicznych usługach zaufania” Ukraina) przedsiębiorstwo potrzebuje kilku działów do pracy z kluczami umieszczonymi na tokenach (w tej chwili kwestia liczby kluczy sprzętowych jest nadal otwarta ).

Jako narzędzie o najniższych kosztach (bezpłatne) wybór padł od razu usbip. Dzięki publikacji serwer na Ubintu 18.04 zaczął działać Oswajanie USB/IP i pomyślnie przetestowane na kilku pendrive'ach (ze względu na brak wówczas tokena). Nie zidentyfikowano w tym czasie żadnych szczególnych problemów poza własnością monopolistyczną (zastrzeżeniem dla użytkownika). Oczywiste jest, że aby zorganizować dostęp dla kilku użytkowników (na początek przynajmniej dwóch), należy rozłożyć ich dostęp w czasie i zmusić ich do pracy na zmianę.

Pytanie brzmiało: Jak mogę to zrobić przy jak najmniejszej ilości tańca, aby wszystko działało dla wszystkich…

Część jest niezdarna

Udostępnianie sieciowe tokena kryptograficznego pomiędzy użytkownikami korzystającymi z usbip
opcja XNUMX. Kilka skrótów do plików bat, a mianowicie
a) Podłączenie klucza dostępu.
b) Celowe odłączenie.

Akapit „б» kontrowersyjne, dlatego zdecydowano się podać czas pracy z kluczem na 3 minuty.

Osobliwością klienta usbip jest to, że po uruchomieniu pozostaje on zawieszony w konsoli, bez przerywania sesji konsoli można „w przybliżeniu” zamknąć połączenie po stronie klienta, a także po stronie serwera.

Oto, co zadziałało dla nas dobrze:

po pierwsze: połączenie na.nietoperzu

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

po drugie: zamknięcie wyłączony.bat

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

Bez polegania na świadomości użytkownika, skrypty zostały połączone token.bat

on.bat | off.bat

Co się dzieje: wszystkie pliki znajdują się w tym samym folderze, uruchamianym przez plik token.bat, w przypadku zamknięcia połączenia użytkownik od razu otrzymuje komunikat o braku klucza, w innym przypadku dopiero po 180 pingach. Podane linie kodu można wyposażyć w „@ECHO OFF” i skierować konsolę na „> nul”, aby nie szokować użytkownika zbytnio, ale nie jest konieczne rozpoczynanie testów. Początkowe „uruchomienie” na dysku USB pokazało, że wszystko było przewidywalne, niezawodne i przejrzyste. Co więcej, po stronie serwera nie są wymagane żadne manipulacje.

Udostępnianie sieciowe tokena kryptograficznego pomiędzy użytkownikami korzystającymi z usbip

Oczywiście podczas bezpośredniej pracy z tokenem nie wszystko poszło zgodnie z oczekiwaniami: przy fizycznym połączeniu w menedżerze urządzeń token jest rejestrowany jako 2 urządzenia (WUDF i karta inteligentna), a przy połączeniu sieciowym tylko jako WUDF (chociaż wystarczy poprosić o kod PIN).

Udostępnianie sieciowe tokena kryptograficznego pomiędzy użytkownikami korzystającymi z usbip

Okazuje się też, że brutalne „zadanie” nie jest aż tak dotkliwe, a zamknięcie połączenia na kliencie jest problematyczne i nawet gdyby się udało, nie gwarantuje to zamknięcia mu go na serwerze.

Po poświęceniu wszystkich konsol na kliencie, drugi skrypt przyjął postać:

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

chociaż jego skuteczność jest mniejsza niż 50%, ponieważ serwer uparcie nadal uważa połączenie za otwarte.

Problemy z połączeniem zrodziły myśli o modernizacji strony serwerowej.

Część serwerowa

Czego potrzebujesz:

  1. Odłącz nieaktywnych użytkowników od usługi.
  2. Zobacz, kto obecnie używa (lub nadal pożycza) tokena.
  3. Sprawdź, czy token jest podłączony do samego komputera.

Problemy te zostały rozwiązane przy użyciu usług crontab i Apache. Dyskretny charakter przepisywania stanu wyników monitorowania punktów 2 i 3, który nas interesuje, wskazuje, że system plików może znajdować się na ramdrive. Dodano linię do /etc/fstab

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

W katalogu głównym utworzono folder skryptów ze skryptami: odmontowanie-montowanie tokena usb_restart.sh

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

uzyskanie listy aktywnych urządzeń 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

uzyskanie listy aktywnych adresów IP (z późniejszą modyfikacją w celu wyświetlania identyfikatorów użytkowników) usbip_client_ip.sh

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

Sam crontab wygląda tak:

*/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)

Mamy więc: co 5 minut może połączyć się nowy użytkownik, niezależnie od tego, kto pracował z tokenem. Folder /ramdrive jest połączony z serwerem http za pomocą dowiązania symbolicznego, w którym zapisywane są 2 pliki tekstowe pokazujące stan serwera usbip.

Część następna: „Brzydka w opakowaniu”

Opcja II. Aby choć trochę zadowolić użytkownika, za pomocą przynajmniej mniej zastraszającego interfejsu. Zaskoczony faktem, że użytkownicy mają różne wersje systemu Windows z różnymi frameworkami, różnymi uprawnieniami, mniej problematycznym podejściem niż Łazarz Nie znalazłem (oczywiście jestem za C#, ale nie w tym przypadku). Można uruchamiać pliki bat z interfejsu w tle, zminimalizowane, ale bez odpowiednich testów osobiście jestem tego zdania: trzeba to zwizualizować, żeby zebrać niezadowolenie użytkowników.

Udostępnianie sieciowe tokena kryptograficznego pomiędzy użytkownikami korzystającymi z usbip

Interfejs i oprogramowanie rozwiązały następujące zadania:

  1. Wyświetla, czy token jest aktualnie zajęty.
  2. Przy pierwszym uruchomieniu wstępna konfiguracja obejmuje wygenerowanie „poprawnych” plików bat, które realizują uruchomienie i przerwanie sesji z serwerem tokenów. Przy kolejnych uruchomieniach realizacja trybu „serwisowego” z wykorzystaniem hasła.
  3. Sprawdzanie obecności połączenia z serwerem, w wyniku czego odpytuje czy jest zajęty lub wyświetla komunikaty o problemach. Po wznowieniu komunikacji program automatycznie rozpoczyna pracę w trybie normalnym.

Współpraca z serwerem WWW realizowana jest za pomocą dodatkowej przystawki fphttpclient.


tutaj będzie link do aktualnej wersji klienta

są też dalsze rozważania na temat artykułu, a także częściowy początkowy entuzjazm dla produktu VirtualHere z jego funkcjami...

Źródło: www.habr.com

Dodaj komentarz