Compartilhamento de rede de um token criptográfico entre usuários baseado em usbip

Em conexão com mudanças na legislação relativa a serviços de confiança (“Sobre serviços de confiança eletrônicos” Ucrânia), a empresa precisa que vários departamentos trabalhem com chaves localizadas em tokens (no momento, a questão do número de chaves de hardware ainda está em aberto ).

Por ser uma ferramenta de menor custo (gratuita), a escolha recaiu imediatamente sobre usbip. O servidor no Ubintu 18.04 começou a funcionar graças à publicação Domando USB/IP e testado com sucesso em vários pen drives (devido à falta de um token naquele momento). Não foram identificados nessa altura quaisquer problemas especiais para além da propriedade de monopólio (reserva para o utilizador). É claro que para organizar o acesso de vários usuários (pelo menos dois, para começar), é necessário dividir o acesso no tempo e obrigá-los a trabalhar em turnos.

A questão era: Como posso fazer isso com o mínimo de dança para que tudo funcione para todos...

A parte é desajeitada

Compartilhamento de rede de um token criptográfico entre usuários baseado em usbip
Opção XNUMX. Vários atalhos para arquivos bat, nomeadamente
a) Conectando a chave de acesso.
b) Desconectar deliberadamente.

Parágrafo "б» controverso, por isso decidiu-se dar o tempo de trabalho com a chave em 3 minutos.

A peculiaridade do cliente usbip é que após ser iniciado ele permanece pendurado no console, sem interromper a sessão do console, você pode fechar a conexão “aproximadamente” do lado do cliente e também do lado do servidor.

Aqui está o que funcionou bem para nós:

primeiro: conexão em.bat

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

segundo: desligamento desligado.bat

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

Sem depender da consciência do usuário, os scripts foram combinados em token.bat

on.bat | off.bat

O que acontece: todos os arquivos estão na mesma pasta, iniciada pelo arquivo token.bat, se a conexão for fechada o usuário recebe imediatamente uma mensagem informando que a chave está indisponível, em outro caso, somente após 180 pings. As linhas de código fornecidas podem ser equipadas com “@ECHO OFF” e a direção do console para “> nul” para não chocar muito o usuário, mas não é necessário iniciar o teste. A “execução” inicial em uma unidade USB mostrou que tudo era previsível, confiável e claro. Além disso, nenhuma manipulação é necessária por parte do servidor.

Compartilhamento de rede de um token criptográfico entre usuários baseado em usbip

Naturalmente, ao trabalhar diretamente com o token, nem tudo saiu como esperado: com uma conexão física no gerenciador de dispositivos, o token é registrado como 2 dispositivos (WUDF e um cartão inteligente), e com uma conexão de rede apenas como WUDF (embora isso é suficiente para solicitar um código PIN).

Compartilhamento de rede de um token criptográfico entre usuários baseado em usbip

Acontece também que o brutal "taskkill" não é tão grave, e fechar a conexão no cliente é problemático e mesmo que tenha sido bem-sucedido, não garante o fechamento no servidor para isso.

Tendo sacrificado todos os consoles do cliente, o segundo script assumiu a forma:

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

embora sua eficácia seja inferior a 50%, já que o servidor continuou teimosamente a considerar a conexão aberta.

Problemas com a conexão levaram a pensamentos sobre a atualização do lado do servidor.

Parte do servidor

O que você precisa:

  1. Desconecte usuários inativos do serviço.
  2. Veja quem está usando (ou ainda pegando emprestado) o token.
  3. Veja se o token está conectado ao próprio computador.

Esses problemas foram resolvidos usando os serviços crontab e apache. A natureza discreta da reescrita do estado dos resultados de monitoramento dos pontos 2 e 3 que nos interessam indica que o sistema de arquivos pode estar localizado no ramdrive. Adicionada linha ao /etc/fstab

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

Uma pasta de scripts com scripts foi criada na raiz: desmontando-montando o 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

obtendo uma lista de dispositivos ativos 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

obtenção de uma lista de IPs ativos (com modificação subsequente para exibir IDs de usuário) usbip_client_ip.sh

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

o próprio crontab se parece com isto:

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

Então temos: a cada 5 minutos um novo usuário pode se conectar, independente de quem trabalhou com o token. A pasta /ramdrive é conectada ao servidor http por meio de um link simbólico, no qual são salvos 2 arquivos de texto, mostrando o status do servidor usbip.

Parte a seguir: “Feio em uma embalagem”

Opção II. Para agradar um pouco o usuário com pelo menos uma interface menos intimidante. Intrigado com o fato de os usuários terem versões diferentes do Windows com estruturas diferentes, direitos diferentes, uma abordagem menos problemática do que Lázaro Não encontrei (claro que sou a favor de C#, mas não neste caso). Você pode iniciar arquivos bat da interface em segundo plano, minimizados, mas sem os devidos testes, eu pessoalmente sou da opinião: você precisa visualizá-los para coletar a insatisfação do usuário.

Compartilhamento de rede de um token criptográfico entre usuários baseado em usbip

As seguintes tarefas foram resolvidas pela interface e software:

  1. Exibe se o token está ocupado no momento.
  2. No primeiro lançamento, a configuração inicial envolve a geração dos arquivos bat “corretos” que implementam o lançamento e a interrupção de uma sessão com o servidor de token. Nas partidas subsequentes, implementação do modo “serviço” por meio de senha.
  3. Verifica a presença de uma conexão com o servidor, pelo que verifica se está ocupado ou exibe mensagens sobre problemas. Quando a comunicação é retomada, o programa começa automaticamente a funcionar no modo normal.

O trabalho com o servidor WEB é implementado usando o snap-in fphttpclient adicional.


aqui estará um link para a versão atual do cliente

há também outras considerações sobre o tema do artigo, bem como um entusiasmo inicial parcial pelo produto VirtualHere com suas funcionalidades...

Fonte: habr.com

Adicionar um comentário