Infolge der Änderung der Gesetzgebung zu vertraulichen Dienstleistungen ("Über elektronische Vertrauensdienste" Ukraine) besteht im Unternehmen die Notwendigkeit, dass mehrere Abteilungen mit Schlüsseln arbeiten, die auf Token liegen (aktuell ist die Anzahl der Hardware-Schlüssel noch offen).

Als kostengünstigstes Instrument (kostenlos) fiel die Wahl sofort auf usbip. Der Server unter Ubuntu 18.04 funktionierte dank der Veröffentlichung USB/IP zähmen und wurde erfolgreich an mehreren USB-Sticks getestet (da zu diesem Zeitpunkt kein Token verfügbar war). Es gab keine nennenswerten Probleme, abgesehen von der monopolartigen Nutzung (Reservierung für einen Benutzer) zu diesem Zeitpunkt. Es ist klar, dass, um den Zugang für mehrere Benutzer (zumindest für zwei, zunächst) zu organisieren, deren Zugang zeitlich aufgeteilt und sie dazu gebracht werden müssen, abwechselnd zu arbeiten.

Es stellte sich die Frage: Wie kann man mit minimalem Aufwand sicherstellen, dass alles für alle funktioniert…

Ein grober Teil

Variante I. Mehrere Verknüpfungen zu bat-Dateien, nämlich
a) Anschluss des Zugangsschlüssels.
b) Gezielte Trennung.

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

Eine Besonderheit des usbip-Clients besteht darin, dass er nach dem Start in der Konsole hängen bleibt; das Beenden der Verbindung kann "grob" seitens des Clients und ebenso seitens des Servers erfolgen, ohne die Konsolensitzung zu unterbrechen.

Das funktioniert bei uns gut:

Erster: Verbindung on.bat

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

Zweiter: Trennung off.bat

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

Da wir nicht auf die Umsicht des Benutzers vertrauen, wurden die Skripte in token.bat

on.bat | off.bat

Was wir erhalten: Alle Dateien befinden sich in einem Ordner, der Start läuft über die Datei token.bat, falls die Verbindung vom Benutzer geschlossen wird, erfolgt sofort die Nachricht über die Nichtverfügbarkeit des Schlüssels; im anderen Fall erst nach 180 Pings. Die aufgeführten Codezeilen können mit "@ECHO OFF" und einer Umleitung der Konsole in "> nul" ausgestattet werden, um den Benutzer nicht zu sehr zu schockieren, aber für den Testlauf ist es nicht notwendig. Der erste "Durchlauf" auf einem USB-Stick zeigte, dass alles vorhersehbar-zuverlässig-genau funktionierte. Zudem sind seitens des Servers keine Manipulationen erforderlich.

Natürlich lief es bei der direkten Arbeit mit dem Token nicht wie erwartet: Bei der physischen Verbindung im Geräte-Manager wird das Token als 2 Geräte (WUDF und Smartcard) registriert, und bei der Netzwerkanbindung nur als WUDF (obwohl dies für die PIN-Code-Anfrage ausreicht).

Es stellte sich auch heraus, dass der brutale „taskkill“ gar nicht so schlimm ist, und das Schließen der Verbindung auf der Client-Seite problematisch ist; selbst wenn dies gelingt, garantiert es nicht, dass die Verbindung auf dem Server geschlossen wird.

Nachdem ich alle Konsolen auf dem Client aufgegeben hatte, 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 unter 50% liegt, da der Server hartnäckig weiterhin die Verbindung als nicht geschlossen betrachtete.

Verbindungsprobleme führten zu Überlegungen zur Modernisierung des Serverteils.

Serverteil

Was benötigt wird:

1. Inaktive Benutzer vom Dienst trennen.
2. Sehen, wer gerade das Token verwendet (oder es noch in Anspruch nimmt).
3. Überprüfen, ob das Token mit dem Computer verbunden ist.

Diese Aufgaben wurden mit Hilfe der Dienste crontab und apache gelöst. Die Diskretion der Überwachungsergebnisse für die Punkte 2 und 3 zeigt, dass das Dateisystem auf einem ramdrive platziert werden kann. In /etc/fstab wurde folgende Zeile hinzugefügt:

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

Im Wurzelverzeichnis wurde ein Ordner script mit den Skripten erstellt: USB-Neuinstallation 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

Abrufen 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

Abrufen der Liste aktiver IP-Adressen (mit nachfolgender Bearbeitung zur Anzeige der Benutzer-IDs) 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 so 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/null)

Somit haben wir: Alle 5 Minuten kann ein neuer Benutzer sich anschließen, unabhängig davon, wer mit dem Token gearbeitet hat. Der Ordner /ramdrive, der mit einem Symlink verbunden ist, speichert 2 Textdateien, die den Zustand des usbip-Servers anzeigen.

Nächster Teil: „Unschön verpackt“

II. Version. Die Benutzer zumindest mit einer weniger bedrohlichen Benutzeroberfläche erfreuen. Angesichts der Tatsache, dass Benutzer unterschiedliche Windows-Versionen mit unterschiedlichen Frameworks und Berechtigungen haben, gab es keinen weniger problematischen Ansatz als Lazarus (ich bevorzuge C#, aber nicht in diesem Fall). Bat-Dateien können aus der Benutzeroberfläche im Hintergrund gestartet werden, minimiert, aber ohne angemessene Tests bin ich der Meinung: Man muss visualisieren, um die Unzufriedenheit der Benutzer zu erfassen.

Folgende Aufgaben wurden mit der Benutzeroberfläche und der Softwarelösung gelöst:

1. Anzeige, ob das Token momentan belegt ist.
2. Bei der ersten Ausführung erfolgt die anfängliche Konfiguration mit der Generierung von "richtigen" Bat-Dateien, die den Start und das Unterbrechen der Sitzung mit dem Token-Server umsetzen. Bei nachfolgenden Ausführungen wird der "Service-Modus" über ein Passwort implementiert.
3. Überprüfung der Verbindung zum Server, deren Ergebnis eine Abfrage über die Belegung oder eine Meldung über Probleme auslöst. Bei Wiederherstellung der Verbindung beginnt das Programm automatisch, im normalen Modus zu arbeiten.

Die Arbeit mit dem WEB-Server wurde mithilfe des zusätzlichen Moduls fphttpclient umgesetzt.

Es gibt auch weitere Überlegungen zu dem Thema des Artikels sowie einen teilweisen anfänglichen Enthusiasmus für das Produkt VirtualHere mit seinen Besonderheiten…

Quelle: habr.com