Como testar o que um interruptor de emergência cobre num host comprometido

Ative o interruptor de emergência, desligue o servidor do túnel e observe o que a máquina ainda faz. O teste vale a pena porque separa o que a firewall realmente impõe daquilo que pressupunha, e os resultados são mais estreitos do que a maioria das páginas de produto sugere. Um interruptor de emergência governa caminhos de rede; não governa software que já está em execução no dispositivo. Executo esta sequência em qualquer máquina cujo cliente alegue ser fail-closed, e demora cerca de dez minutos.

Comece pelo cliente, não pelo servidor

O ponto de aplicação é o host onde está sentado: a firewall do sistema operativo, um serviço auxiliar ou o próprio controlador do cliente VPN. Isso importa porque tudo o que o interruptor pode fazer é limitado pelo que essa camada vê. Se o cliente implementa o bloqueio com uma regra de encaminhamento e uma marca, qualquer coisa com privilégios suficientes pode acrescentar a sua própria regra; se usa uma tabela de firewall do kernel, os mesmos privilégios podem editar a tabela. A força da cifra nunca entra nesta questão.

Assim, a primeira coisa a estabelecer é quem detém a política neste dispositivo e o que lhe é permitido sobrepor. Numa máquina de trabalho gerida, a resposta é normalmente o agente de ponto final da organização, e uma VPN pessoal não remove essas capacidades, seja como for configurado o túnel.

Primeiro passo: confirme o bloqueio nos caminhos que pensa que cobre

Derrube o túnel na extremidade remota, não no cliente, para que o cliente continue a acreditar que devia estar ligado. Depois experimente o que uma pessoa experimentaria de facto:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Quer um cliente que falhe depressa e de forma limpa, não um que fique pendurado até ao limite do navegador. Ficar pendurado significa normalmente que os pacotes são descartados em silêncio por uma regra sem rejeição, o que é aceitável, mas também pode significar que o cliente deixou uma rota predefinida obsoleta apontada a uma interface morta. Leia a tabela de encaminhamento com o túnel em baixo: uma rota predefinida que ainda aponta ao dispositivo do túnel e uma regra de firewall que só bloqueia novas ligações de saída são dois estados diferentes, e apenas um deles é fail-closed.

Repita os mesmos comandos com a opção de permitir LAN do cliente ligada e desligada. Esse comutador é onde vivem a maioria das surpresas, porque reabre um caminho que o resto da política foi escrito para fechar.

Segundo passo: verifique DNS e IPv6 como caminhos separados

A resolução de nomes é a falha que sobrevive à maioria das implementações, porque a consulta pode sair por algo diferente do resolvedor do sistema. Pergunte com uma ferramenta que ignore a sua configuração de resolvedor, e verifique o lado v6 ao mesmo tempo:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Respostas vazias para ambas as consultas de nome com o túnel em baixo são o resultado que quer. Se a segunda consulta responder, um endereço de resolvedor codificado é alcançável e o túnel não é a única saída da máquina. Se apenas o pedido v6 tiver êxito, a política cobre IPv4 e ignora IPv6, que é a mesma fuga noutra família de endereços.

Os navegadores tornam isto mais difícil de ler de fora, porque um navegador configurado para DNS sobre HTTPS resolve a consulta através de um pedido HTTPS: a consulta só está bloqueada na medida em que a porta 443 para esse ponto final estiver. Num host onde a política permite a sub-rede local, esse pedido ainda pode chegar a um resolvedor na LAN.

Terceiro passo: separe a exposição de rede da exposição do ponto final

Agora a parte que nenhuma regra de firewall alcança. Um interruptor de emergência bloqueia caminhos fora da máquina; não impede o software da máquina de ler dados antes de serem cifrados, nem impede esse software de usar o túnel de forma legítima. Um keylogger, uma extensão maliciosa, um ecrã deixado desbloqueado, um cliente de sincronização com permissões amplas: todos movem informação por uma ligação que o interruptor permite de bom grado.

O mesmo vale para software de monitorização que um empregador instalou de propósito. Bloquear rotas não o remove, e comprar um novo servidor VPN não é a reparação, porque a exposição está antes do túnel.

Um gestor de área de transferência que carrega para uma conta na nuvem mostra-o com nitidez. O tráfego está cifrado, o destino é permitido, e o interruptor de emergência relata um estado saudável o tempo todo.

Quarto passo: escreva a afirmação que o seu teste sustenta

Depois do teste de corte pode afirmar factos concretos: que aplicações falharam, que caminhos pararam, como se comportaram DNS e IPv6 e se o bloqueio aguentou quando o túnel caiu. Não pode afirmar que o sistema operativo está limpo, nem que um serviço na extremidade remota manterá o seu início de sessão privado.

Mantenha os dois problemas separados e dê a cada um o seu próprio controlo:

• Interruptor de emergência: o requisito de falha definido, verificado com um teste de corte que repete após cada atualização do cliente.
• Confiança do dispositivo: atualizações suportadas, proteção de ponto final de uma fonte fiável, revisão de permissões e pedidos de autenticação inexplicados.
• Incidente: siga o processo da plataforma ou da organização quando se suspeitar de compromisso; um servidor novo não é um passo de limpeza.
• Divulgação: ao pedir ajuda, não cole chaves privadas nem arquivos de diagnóstico completos, porque os registos e as capturas transportam os mesmos segredos que a ligação.

Execute a sequência de novo após a próxima atualização, porque um interruptor de emergência é configuração que se move com as versões. O teste é a única prova de que o comportamento em que confia continua a ser o que obtém.