In Anbetracht der Änderung der Gesetzgebung zu vertrauenswürdigen Diensten ("Über elektronische vertrauenswürdige Dienste" Ukraine) besteht in dem Unternehmen die Notwendigkeit, dass mehrere Abteilungen mit Schlüsseln arbeiten, die auf Token gespeichert sind (derzeit ist die Anzahl der Hardware-Schlüssel noch offen).

Als kostengünstigstes Tool (kostenlos) fiel die Wahl sofort auf usbip. Der Server unter Ubuntu 18.04 lief erfolgreich dank der Veröffentlichung USB/IP im Griff und wurde erfolgreich mit mehreren USB-Sticks getestet (da zu diesem Zeitpunkt kein Token vorhanden war). Es traten keine besonderen Probleme auf, abgesehen von dem monopolartigen Besitz (Reservierung für den Benutzer) zu diesem Zeitpunkt. Um mehreren Benutzern (wenigstens zwei, für den Anfang) Zugang zu gewähren, ist es offensichtlich erforderlich, ihren Zugang zeitlich zu trennen und sie in Schichten arbeiten zu lassen.

Die Frage stellte sich: Wie kann man mit den geringsten Aufwand sicherstellen, dass alle problemlos arbeiten…

Grober Ansatz

Variante I. Mehrere Verknüpfungen zu bat-Dateien, nämlich
a) Anschluss des Zugriffsschlüssels.
b) Bewusste Abschaltung.

Der Punkt "b" ist umstritten, daher wurde beschlossen, die Zeit für die Arbeit mit dem Schlüssel auf 3 Minuten festzulegen.

Die Besonderheit des USBIP-Clients besteht darin, dass er nach dem Start in der Konsole verweilt, ohne die Konsolensitzung zu unterbrechen. Die Verbindung kann "grob" vom Client und ebenso vom Server aus geschlossen werden.

Das hat bei uns gut funktioniert:

Erstens: Verbindung on.bat

usbip -a 172.16.12.26 4-1
msg * "Signatur/Token nicht verfügbar oder belegt"

Zweitens: Trennung off.bat

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

Ohne auf das Gewissen des Benutzers zu hoffen, wurden die Skripte in token.bat

on.bat | off.bat

Folgendes ergibt sich: Alle Dateien befinden sich im selben Ordner, der Start erfolgt mit der Datei token.bat. Wenn die Verbindung beim Benutzer geschlossen wird, erscheint sofort eine Meldung über die Nichterreichbarkeit des Schlüssels; andernfalls erst nach 180 Pings. Die angegebenen Codezeilen können mit „@ECHO OFF“ versehen werden und die Konsolenrichtung in „> nul“ lenken, um den Benutzer nicht zu schockieren, ist aber für den Teststart nicht erforderlich. Der erste „Durchlauf“ auf dem USB-Stick zeigte, dass alles vorhersehbar, zuverlässig und klar ist. Zudem sind vom Server aus keine Manipulationen notwendig.

Natürlich verlief die Arbeit mit dem Token nicht wie erwartet: Bei physischer Verbindung im Geräte-Manager wird der Token als 2 Geräte registriert (WUDF und Smartcard), während er bei Netzwerkverbindung nur als WUDF erscheint (obwohl dies für die PIN-Abfrage ausreicht).

Es stellte sich auch heraus, dass der brutale "taskkill" nicht so hart ist, und das Trennen der Verbindung auf der Client-Seite problematisch ist, und selbst wenn das gelingt, garantiert das nicht, dass es auch auf dem Server geschlossen wird.

Nachdem alle Konsolen auf der Client-Seite geopfert wurden, nahm das zweite Skript folgende Form an:

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

obwohl seine Effektivität weniger als 50 % beträgt, da der Server hartnäckig weiterhin die Verbindung als offen betrachtete.

Verbindungsprobleme führten zu Gedanken über eine Aufrüstung im Server-Bereich.

Server-seitig

Was benötigt wird:

1. Inaktive Benutzer vom Dienst trennen.
2. Sehen, wer derzeit den Token verwendet (oder noch belegt).
3. Überprüfen, ob der Token mit dem Computer verbunden ist.

Diese Aufgaben wurden mit den Diensten crontab und apache gelöst. Die Diskretion der Zustandsaktualisierung der Überwachungsergebnisse der Punkte 2 und 3 deutet darauf hin, dass das Dateisystem auf einem ramdrive angeordnet werden kann. In /etc/fstab wurde eine Zeile hinzugefügt.

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

Im Root-Verzeichnis wurde der Ordner script mit den Skripten erstellt: USB-Token demontieren-montieren 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

Erhalt der Liste aktiver Geräte 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.

Erhalt der Liste aktiver IPs (mit späterer Anpassung zur Anzeige der Benutzeridentifikatoren) usbip_client_ip.sh.

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

Der crontab sieht folgendermaßen aus:

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

Wir haben also: Alle 5 Minuten kann sich ein neuer Benutzer verbinden, unabhängig davon, wer mit dem Token gearbeitet hat. Der http-Server ist über einen Symlink mit dem Ordner /ramdrive verbunden, in dem 2 Textdateien gespeichert werden, die den Zustand des Servers usbip anzeigen.

Nächster Teil: „Das Unschöne in der Hülle“

II. Variante. Dem Benutzer zumindest mit einer weniger abschreckenden Benutzeroberfläche eine Freude bereiten. Angesichts der Tatsache, dass die Benutzer unterschiedliche Windows-Versionen mit verschiedenen Frameworks und Rechten haben, habe ich keinen weniger problematischen Ansatz gefunden als Lazarus (ich bin natürlich für C#, aber nicht in diesem Fall). Es ist möglich, bat-Dateien aus der Benutzeroberfläche auszuführen, auch im Hintergrund und minimiert, aber ohne ausreichende Tests halte ich es persönlich für wichtig, dies zu visualisieren, um Benutzerunzufriedenheit zu sammeln.

Die Benutzeroberfläche und der Softwareteil haben folgende Aufgaben gelöst:

1. Anzeigen, ob das Token derzeit belegt ist.
2. Beim ersten Start wird die anfängliche Konfiguration mit der Generierung von „korrekten“ bat-Dateien implementiert, die den Start und die Unterbrechung einer Sitzung mit dem Token-Server realisieren. Bei nachfolgenden Starts erfolgt die Implementierung des „Servicemodus“ durch ein Passwort.
3. Überprüfung der Verbindung zum Server, nach deren Ergebnis eine Abfrage zur Belegung durchgeführt oder eine Fehlermeldung ausgegeben wird. Bei Wiederherstellung der Verbindung beginnt das Programm automatisch im Normalmodus zu arbeiten.

Die Arbeit mit dem WEB-Server erfolgt über das zusätzliche Toolkit fphttpclient.

es gibt auch eine Fortsetzung der Überlegungen zum Thema des Artikels sowie eine teilweise ursprüngliche Begeisterung für das Produkt VirtualHere und seine Besonderheiten…

Quelle: habr.com