OpenConnect csd-wrapper: audite o script antes do login

Adicionar --csd-wrapper a um perfil entrega um script local a um daemon que o executa durante o login, então a decisão à sua frente é uma revisão de código, não um botão de preferência. A opção existe para que o componente de verificação de host do gateway possa ser substituído, e aceita um caminho para um script que você fornece. Tudo abaixo pressupõe que o responsável pela implantação já disse qual verificação de postura é necessária; se essa parte ainda estiver aberta, resolva-a primeiro. O manual tem quatro passos: localizar o estágio que falhou, ler o script, escolher a identidade com que ele é executado e provar o resultado.

Passo 1: Localize o estágio que falhou

A última mensagem do cliente costuma ser sobre um cookie, que é o fim de uma cadeia e não o começo. Um login HTTPS, uma verificação de certificado do servidor, uma troca de autenticação e um componente de postura ficam todos à frente dessa mensagem.

Capture a versão e o endereço de login em uso, depois repita a tentativa mantendo a saída detalhada no seu próprio terminal. Leia o primeiro erro que não é uma nova tentativa, não a última linha da transcrição. Se o log parar antes de qualquer componente de avaliação ser nomeado, o wrapper ainda não é o seu problema. Adicioná-lo nesse ponto só amplia a superfície que você terá de defender mais tarde.

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

Mantenha a transcrição localmente, porque cookies e respostas de autenticação são material de acesso. Um rastro colado em uma conversa é vazamento de credenciais mesmo quando a etapa de avaliação parece inofensiva. Compartilhe o texto do erro e o ponto do fluxo em que ele apareceu, nunca a carga útil.

Passo 2: Leia o script antes de ele entrar em um perfil

Um wrapper é tão confiável quanto a revisão que você examinou, então fixe essa revisão e guarde o hash dela ao lado da nota de aprovação. Os dois comandos abaixo dão uma impressão digital e uma verificação de sintaxe barata antes de você ler uma única linha. Também dão à próxima pessoa uma referência fixa, o que importa quando o arquivo vive fora do gerenciamento de pacotes. Nenhum dos comandos diz o que o script faz, então execute-os e continue lendo.

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

Leia o arquivo inteiro com quatro perguntas em mente: ele faz chamadas HTTP de saída, lê arquivos de credenciais ou variáveis de ambiente, escreve fora de um diretório temporário, e alguma ramificação relata uma postura aprovada sem medir nada. Esse último padrão é uma burla de política com uma linha de log anexada. Wrappers copiados costumam contrabandeá-lo para trás de uma verificação de aparência plausível. Se o script decide que o dispositivo está bem antes de olhar para o dispositivo, pare aí.

Verifique também cargas empacotadas, porque um cabeçalho legível não prova nada sobre o resto do arquivo. Baixar um script de um tópico de fórum não o torna confiável só porque o nome ecoa um componente real de verificação de host. Registre quem o instalou, de onde veio e como será atualizado.

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

Passo 3: Escolha a identidade com que o wrapper é executado

--csd-user reduz os privilégios enquanto o programa CSD, TNCC ou HIP é executado. Essa conta faz parte do arranjo local de execução, não do nome de usuário enviado ao gateway.

Dê ao wrapper uma conta dedicada sem shell interativo, sem direitos de sudo e sem participação em grupos de que não precise. Conceda acesso de leitura ao script e aos arquivos específicos que ele inspeciona, depois teste a redução antes de tocar no perfil de VPN. Encontrar o problema aqui custa menos do que encontrá-lo dentro do cliente.

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

Reduzir privilégios limita o dano que um script ruim pode causar. Não revisa o código, não torna o relatório verdadeiro e não estabelece que o administrador do gateway aceite esta implementação como cumprimento da política de dispositivos.

Passo 4: Mantenha a alteração reversível

Faça backup do perfil antes de editá-lo e mantenha o wrapper sob controle de versão, para que uma reversão restaure um hash conhecido em vez de procurar uma cópia. Anote o caminho do script, o hash, o usuário de execução e o aprovador em um só lugar.

Para reverter, remova a opção, reinicie o cliente e confirme que o erro original volta. Se o gateway ainda rejeitar o login depois da reversão, algo mais também mudou, e encontrar essa diferença vem antes de tentar o wrapper novamente. Guarde a cópia anterior durante toda a janela de mudança, o que para a maioria das equipes significa até a próxima janela de manutenção passar.

Depois de uma implantação bem-sucedida, verifique duas coisas em vez de uma: o túnel sobe, e um dispositivo que deveria falhar na verificação de postura continua sendo recusado. Uma conexão que funciona para todos não é prova de que a avaliação sobreviveu à sua mudança.

Atalhos que criam um segundo problema

Não deixe o assistente relatar um estado conforme sem executar as verificações exigidas, e não substitua a identidade da plataforma para corresponder a outro sistema operacional. Afirmar uma plataforma diferente não é prova de que o dispositivo real cumpre a política. Isso deixa você com um cliente que mente em cada login futuro.

Desativar a verificação do servidor, reproduzir um cookie antigo e empilhar scripts não revisados trocam todos uma falha visível por uma invisível. Se o cliente instalado não consegue concluir o fluxo suportado, peça uma alternativa aprovada em vez de dobrar o que você tem.

O manual do OpenConnect documenta --csd-wrapper e --csd-user separadamente, e essa é a pista que importa: o script e a identidade são duas decisões. Revise-os separadamente e anote os dois. Então a solicitação de login deixa de ser um mistério que se resolve colando código.