Uma VPN não confiável são três fronteiras separadas, não uma
Pares remotos, o operador no caminho e o cliente no seu host são três ameaças distintas. Uma regra de firewall responde apenas à primeira.
«Não confio nesta VPN» costuma ser três afirmações vestidas numa só frase. Os pares remotos nessa rede podem alcançar serviços no seu host, o operador que executa o túnel pode observar o tráfego que o atravessa, e o software cliente que instalou pode alterar a política de rede da sua máquina. A crença que merece correção é que uma regra de firewall, uma máquina virtual ou uma escolha criteriosa de sistema operativo respondem às três. Cada medida responde exatamente a uma delas.
O mito: um único controlo cobre todo o risco
A suposição comum é que entrar numa rede não confiável é uma única decisão com uma única mitigação. As pessoas escolhem o controlo em que já confiam, aplicam-no e consideram o risco resolvido: a firewall está ligada, o espaço de trabalho é descartável, o cliente veio de um fornecedor respeitável.
Esses controlos não se sobrepõem como a suposição implica. Uma firewall de host limita o que um par remoto pode alcançar, e não faz nada contra um operador que termina o seu TLS. Uma máquina virtual separa um espaço de trabalho dos ficheiros do seu host, e não faz nada contra um componente cliente autorizado a reconfigurar a pilha de rede por baixo de ambos. Nomear a fronteira que cada controlo cria realmente é todo o exercício.
Sepá-las também lhe diz que risco escolheu aceitar. A maioria das decisões reais mitiga uma fronteira e tolera outra, o que está bem desde que o registo da alteração diga qual é qual.
A que pode realmente chegar o par remoto
Comece pelos serviços à escuta. A interface de túnel tratada como amplamente confiável porque os seus pacotes chegaram cifrados é o erro habitual, e transforma cada ouvinte local num alvo candidato para quem mais esteja nessa rede. A cifra protege o cabo entre dois extremos; não diz nada sobre a intenção do par do outro lado.
ss -tulpn sudo nft list ruleset ip -br addr
Ligue os serviços ao endereço de que precisam em vez de a cada interface, e permita apenas as operações exigidas pela tarefa aprovada. Mantenha explícitos o encaminhamento, a ponte e o proxy de aplicações, porque duas ligações de rede não criam uma rota de trânsito por si só, mas uma regra de proxy certamente pode.
Um espaço de trabalho descartável aprovado reduz a que pode chegar a rede remota, mas apenas quando a sua configuração de partilha corresponde à afirmação. Pastas partilhadas, integração da área de transferência, agentes de credenciais e canais de gestão atravessam todos a fronteira que o espaço de trabalho devia criar. A etiqueta do espaço de trabalho não prova nada sobre quais deles estão abertos.
A arquitetura de confiança zero da NIST enuncia o princípio por detrás de tudo isto: a localização na rede por si só não concede confiança implícita. A autenticação de recursos ainda tem trabalho depois de o túnel ser admitido, e também a pergunta sobre quem mais partilha essa rede.
O que o operador no caminho pode ver
Uma VPN move o seu tráfego para outro ponto do caminho; não acrescenta cifra de aplicação. Se o fornecedor termina o seu TLS, pode ler o que o seu navegador teria protegido de outra forma, e nenhuma regra de firewall local muda isso.
Mantenha a validação normal de certificados para o destino real e compreenda o caminho do resolutor e dos metadados, porque uma consulta DNS pode revelar mais do que a carga útil que a antecede. Apenas os metadados, isto é, que endereços contactou e quando, respondem frequentemente à pergunta do operador sem qualquer necessidade de ler conteúdo. Por isso «o tráfego está cifrado» e «o tráfego é privado» são afirmações diferentes.
Se essa visibilidade é inaceitável para a tarefa, a resposta é outra arquitetura aprovada em vez de mais filtragem local. A filtragem local não pode remover um observador de um caminho em que ele ainda se encontra.
O que o cliente local pode alterar
Esta é a fronteira que as pessoas perdem, e é a que torna as outras duas irrelevantes. No Linux, CAP_NET_ADMIN abrange a configuração de interfaces, a administração da firewall e as alterações de rotas no seu contexto de rede. Um software que detenha essa capacidade pode reescrever a política que acabou de escrever.
getcap /usr/sbin/openvpn systemd-analyze security vpn-client.service ip netns list
Um espaço de nomes de rede é uma fronteira real para o estado da rede e uma má para todo o resto: não isola o sistema de ficheiros nem o armazém de credenciais. Trate-o como uma camada e não como um contentor para todo o problema.
Obtenha o cliente e a sua configuração de uma fonte mantida, reveja a autoridade que solicita e mantenha os componentes privilegiados sob controlo de administrador. Uma máquina virtual pode fazer parte de uma fronteira de avaliação qualificada sem se tornar permissão para executar um instalador inexplicado ao lado de credenciais valiosas. O instalador corre com a autoridade que lhe der, e essa autoridade é a fronteira.
Escreva que fronteira aceitou
Termine com uma frase que nomeie quatro coisas: o código local de confiança, o acesso remoto permitido, os dados de aplicação protegidos e a relação com o operador que resta. Essa frase vale mais do que uma afirmação genérica de que uma VM, um sistema operativo ou um antivírus tornaram segura uma rede hostil.
Depois confirme que a operação estreita funciona e que a negação exigida ainda se mantém, mesmo depois de o túnel cair. Uma fronteira que só existe enquanto o túnel está de pé não é a fronteira que documentou.
Nenhum teste prova que toda a vulnerabilidade está ausente, e uma revisão que afirme o contrário exagera. O resultado honesto nomeia o risco residual e a pessoa que o aceitou.