In verband met veranderingen in de wetgeving met betrekking tot vertrouwensdiensten ("Over elektronische vertrouwensdiensten" Oekraïne), heeft de onderneming behoefte aan verschillende afdelingen om te werken met sleutels op tokens (op dit moment is de kwestie van het aantal hardwaresleutels nog open ).

Als tool met de laagste kosten (gratis) viel de keuze meteen op usbip. Dankzij de publicatie is de server op Ubintu 18.04 gaan werken USB/IP temmen en met succes getest op verschillende flashdrives (vanwege het ontbreken van een token op dat moment). Er zijn op dat moment geen bijzondere problemen geconstateerd, afgezien van het monopolie-eigendom (reservering voor de gebruiker). Het is duidelijk dat om de toegang voor meerdere gebruikers (tenminste twee, om te beginnen) te organiseren, het noodzakelijk is om hun toegang in de tijd te verdelen en hen te dwingen om beurten te werken.

De vraag was: hoe kan ik dat doen met zo weinig mogelijk dans, zodat alles voor iedereen werkt...

Het onderdeel is onhandig

Optie XNUMX. Verschillende snelkoppelingen naar bat-bestanden, namelijk
a) De toegangssleutel aansluiten.
b) Opzettelijk de verbinding verbreken.

Paragraaf "б» controversieel, daarom werd besloten om de tijdsduur voor het werken met de sleutel op 3 minuten te stellen.

Het bijzondere van de usbip-client is dat deze na het opstarten in de console blijft hangen; zonder de consolesessie te onderbreken, kun je de verbinding “grofweg” verbreken vanaf de clientzijde en ook vanaf de serverzijde.

Dit is wat voor ons goed werkte:

Ten eerste: verbinding op.bat

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

tweede: afsluiten uit.bat

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

Zonder afhankelijk te zijn van het bewustzijn van de gebruiker, werden de scripts gecombineerd tot token.bat

on.bat | off.bat

Wat er gebeurt: alle bestanden bevinden zich in dezelfde map, gelanceerd door het bestand token.bat. Als de verbinding wordt verbroken, ontvangt de gebruiker onmiddellijk een bericht dat de sleutel niet beschikbaar is, in een ander geval pas na 180 pings. De gegeven coderegels kunnen worden uitgerust met “@ECHO OFF” en de consolerichting naar “> nul” om de gebruiker niet te veel te shockeren, maar het is niet nodig om te beginnen met testen. De eerste “run” op een USB-stick toonde aan dat alles voorspelbaar, betrouwbaar en duidelijk was. Bovendien zijn er geen manipulaties vanaf de serverzijde vereist.

Bij het rechtstreeks werken met het token verliep uiteraard niet alles zoals verwacht: bij een fysieke verbinding in apparaatbeheer wordt het token geregistreerd als 2 apparaten (WUDF en een smartcard), en bij een netwerkverbinding alleen als WUDF (hoewel dit is voldoende om een ​​pincode aan te vragen).

Het blijkt ook dat de brutale "taskkill" niet zo ernstig is, en dat het sluiten van de verbinding op de client problematisch is en zelfs als het succesvol zou zijn, garandeert dit niet dat het voor hem op de server wordt gesloten.

Nadat alle consoles op de client waren opgeofferd, nam het tweede script de vorm aan:

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 ervan minder dan 50% bedraagt, omdat de server koppig de verbinding als open bleef beschouwen.

Problemen met de verbinding leidden tot gedachten over het upgraden van de serverkant.

Servergedeelte

Wat je nodig hebt:

1. Ontkoppel inactieve gebruikers van de service.
2. Bekijk wie de token momenteel gebruikt (of nog leent).
3. Kijk of het token op de computer zelf is aangesloten.

Deze problemen zijn opgelost met behulp van de crontab- en apache-services. De discrete aard van het herschrijven van de status van de monitoringresultaten van de punten 2 en 3 die ons interesseren, geeft aan dat het bestandssysteem zich op de ramdrive kan bevinden. Regel toegevoegd aan /etc/fstab

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

In de root is een scriptmap met scripts aangemaakt: het token ontkoppelen-aankoppelen 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

een lijst met actieve apparaten ophalen 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

het verkrijgen van een lijst met actieve IP's (met daaropvolgende wijziging om gebruikers-ID's 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 zelf ziet er als volgt 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/hull)

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

Volgende deel: “Lelijk in een verpakking”

Optie II. Om de gebruiker een beetje te plezieren met op zijn minst een minder intimiderende interface. Verbaasd over het feit dat gebruikers verschillende versies van Windows hebben met verschillende frameworks, verschillende rechten, een minder problematische aanpak dan Lazarus Ik heb het niet gevonden (ik ben natuurlijk voor C#, maar in dit geval niet). Je kunt bat-bestanden starten vanuit de interface op de achtergrond, geminimaliseerd, maar zonder de juiste tests ben ik persoonlijk van mening: je moet het visualiseren om de ontevredenheid van de gebruiker te verzamelen.

De volgende taken zijn opgelost door de interface en software:

1. Geeft weer of het token momenteel bezet is.
2. Bij de eerste lancering omvat de initiële installatie het genereren van de “juiste” bat-bestanden die het starten en onderbreken van een sessie met de tokenserver implementeren. Bij daaropvolgende starts wordt de "service" -modus geïmplementeerd met behulp van een wachtwoord.
3. Het controleren van de aanwezigheid van een verbinding met de server, waardoor deze peilt of deze bezet is of meldingen over problemen weergeeft. Wanneer de communicatie wordt hervat, begint het programma automatisch in de normale modus te werken.

Het werken met de WEB-server wordt gerealiseerd met behulp van de extra module fphttpclient.

hier zal een link zijn naar de huidige versie van de client

er zijn ook verdere overwegingen over het onderwerp van het artikel, evenals een gedeeltelijk aanvankelijk enthousiasme voor het VirtualHere-product met zijn functies...

Bron: www.habr.com