Met de wijziging van de wetgeving met betrekking tot vertrouwensdiensten ("Over elektronische vertrouwensdiensten" Oekraïne), is er binnen het bedrijf de noodzaak ontstaan voor verschillende afdelingen om te werken met sleutels die zich op tokens bevinden (momenteel is de kwestie van het aantal hardware-sleutels nog open).

Als een instrument met de minste kosten (gratis) viel de keuze direct op usbip. De server op Ubuntu 18.04 werkte dankzij de publicatie USB/IP temmen en werd succesvol getest op verschillende USB-sticks (omdat er op dat moment geen token beschikbaar was). Er zijn geen bijzondere problemen geconstateerd, behalve het monopolistisch bezit (reservering voor een gebruiker) op dat moment. Het is duidelijk dat om toegang te organiseren voor meerdere gebruikers (ten minste twee, om te beginnen) hun toegang in de tijd moet worden verdeeld en ze om beurten moeten laten werken.

De vraag werd gesteld: Hoe kan iedereen met de minste moeite laten werken ...

Een ruwe oplossing

Optie één. Enkele snelkoppelingen naar bat-bestanden, namelijk
a) Verbinden van de toegangssleutel.
b) Bewust ontkoppelen.

Het punt "b" is omstreden, daarom werd besloten om een ​​looptijd van 3 minuten voor het werken met de sleutel toe te kennen.

Een kenmerk van de usbip-client is dat na de start deze blijft hangen in de console, zonder de console-sessie te onderbreken. De verbinding kan "ruw" worden verbroken vanaf de client-kant en ook aan de server-kant.

Dit is wat voor ons goed werkte:

eerste: verbinding on.bat

usbip -a 172.16.12.26 4-1
msg * "De handtekening/token is niet beschikbaar of bezet "

tweede: ontkoppelen off.bat

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

zonder op de bewustheid van de gebruiker te vertrouwen, zijn de scripts samengevoegd in token.bat

on.bat | off.bat

Wat het resultaat is: alle bestanden bevinden zich in dezelfde map, het starten met het bestand token.bat, als de verbinding door de gebruiker wordt verbroken, verschijnt meteen een bericht over de onbeschikbaarheid van de sleutel; in het andere geval, pas na 180 pings. De gegeven code-regels kunnen worden uitgerust met "@ECHO OFF" en het console-uitvoer naar "> nul" om de gebruiker niet al te veel te schokken, maar voor testdoeleinden is dit niet noodzakelijk. De eerste "run" op de USB-stick toonde aan dat alles voorspelbaar, betrouwbaar en nauwkeurig werkte. Bovendien zijn er aan de serverkant geen manipulaties vereist.

Natuurlijk, bij het werken met de token liep alles niet zoals verwacht: bij fysieke aansluiting in de apparaatbeheerder wordt de token geregistreerd als 2 apparaten (WUDF en smartcard) en bij netwerkaansluiting alleen als WUDF (hoewel dit voor de PIN-verzoek al voldoende is).

Het bleek ook dat de brute 'taskkill' helemaal niet zo streng is, en het afsluiten van de verbinding aan de clientzijde problematisch is en zelfs als dit lukt, garandeert het niet dat deze ook aan de serverzijde wordt afgesloten.

Door alle consoles aan de clientzijde op te geven, kreeg het tweede script de vorm:

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

Hoewel de effectiviteit minder dan 50% is, omdat de server hardnekkig blijft denken dat de verbinding nog niet is gesloten.

Verbindingsproblemen leidde tot gedachten over een upgrade aan de serverzijde.

Serverzijde

Wat nodig is:

1. Deactiveren van inactieve gebruikers van de dienst.
2. Kunnen zien wie de token momenteel gebruikt (of nog steeds in gebruik heeft).
3. Kunnen zien of de token op de computer is aangesloten.

Deze taken werden opgelost met behulp van de diensten crontab en apache. De discretie van het opnieuw schrijven van de status van de monitoringresultaten van punten 2 en 3 geeft aan dat het bestandssysteem op een ramdrive kan worden geplaatst. In /etc/fstab werd de regel toegevoegd

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

In de root is een map script aangemaakt met scripts: ontkoppelen-koppelen van de token 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

lijst van actieve apparaten ontvangen 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

lijst van actieve IP-adressen ontvangen (met een vervolgontwikkeling om gebruikersidentificaties weer te geven) usbip_client_ip.sh

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

de crontab ziet er zo uit:

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

Dus hebben we: elke 5 minuten kan er een nieuwe gebruiker aansluiten, ongeacht wie de token heeft gebruikt. De map /ramdrive is via een symlink verbonden met de http-server, waarin 2 tekstbestanden worden opgeslagen die de status van de usbip-server weergeven.

Volgende deel: "Lelijk in verpakking"

Variant II. Een beetje de gebruiker verblijden met een minder intimiderende interface. Gezien het feit dat gebruikers verschillende versies van Windows hebben met verschillende frameworks en rechten, is er geen minder problematische aanpak dan Lazarus heb ik niet gevonden (ik ben natuurlijk voor C#, maar niet in dit geval). Het uitvoeren van bat-bestanden vanuit de interface kan ook op de achtergrond, geminimaliseerd, maar zonder voldoende testing geloof ik persoonlijk dat het belangrijk is om te visualiseren om gebruikersklachten te verzamelen.

Met de interface en de software zijn de volgende taken opgelost:

1. Weergeven of de token momenteel bezet is.
2. Bij de eerste opstart wordt een initiële configuratie uitgevoerd met het genereren van de 'juiste' bat-bestanden die de uitvoering en onderbreking van de sessie met de server van de token mogelijk maken. Bij volgende opstarts wordt de 'service'-modus met een wachtwoord geïmplementeerd.
3. Controle van de verbinding met de server, op basis van de resultaten worden vragen gesteld over de bezetting of worden er berichten over problemen weergegeven. Bij het herstellen van de verbinding begint het programma automatisch in de normale modus te werken.

Werken met de WEB-server is geïmplementeerd met behulp van de aanvullende tool fphttpclient.

er zijn ook aanvullende overwegingen over het onderwerp van het artikel, evenals een gedeeltelijke initiële opwinding over het product VirtualHere met zijn bijzonderheden...

Bron: habr.com