Unha VPN non fiable son tres fronteiras separadas, non unha

«Non confío nesta VPN» adoitan ser tres afirmacións vestidas cunha soa frase. Os pares remotos desa rede poderían alcanzar servizos no seu host, o operador que executa o túnel podería observar o tráfico que o atravesa, e o software cliente que instalou podería cambiar a política de rede da súa máquina. A crenza que merece corrección é que unha regra de devasas, unha máquina virtual ou unha elección coidadosa do sistema operativo responden ás tres. Cada medida responde exactamente a unha delas.

O mito: un só control cobre todo o risco

A suposición común é que unirse a unha rede non fiable é unha soa decisión cunha soa mitigación. A xente escolle o control no que xa confía, aplícao e considera o risco resolto: a devasa está activa, o espazo de traballo é dun só uso, o cliente procede dun provedor respectable.

Eses controis non se solapan como a suposición implica. Unha devasa de host limita a que pode chegar un par remoto, e non fai nada contra un operador que remata o seu TLS. Unha máquina virtual separa un espazo de traballo dos ficheiros do seu host, e non fai nada contra un compoñente cliente ao que se permite reconfigurar a pila de rede debaixo de ambos. Nomear a fronteira que cada control crea realmente é todo o exercicio.

Separaas tamén lle di que risco elixiu aceptar. A maioría das decisións reais mitigan unha fronteira e toleran outra, o cal está ben sempre que o rexistro do cambio diga cal é cal.

A que pode chegar realmente o par remoto

Comece polos servizos que escoitan. A interface de túnel tratada como amplamente fiable porque os seus paquetes chegaron cifrados é o erro habitual, e converte cada escoita local nun obxectivo candidato para calquera que estea nesa rede. A cifraxe protexe o cable entre dous extremos; non di nada sobre a intención do par na outra beira.

ss -tulpn
sudo nft list ruleset
ip -br addr

Ate os servizos ao enderezo que necesitan en lugar de a cada interface, e permita só as operacións que a tarefa aprobada require. Manteña explícitos o reenvío, a ponte e o proxy de aplicacións, porque dúas conexións de rede non crean unha ruta de tránsito por si soas, pero unha regra de proxy si pode.

Un espazo de traballo dun só uso aprobado reduce a que pode chegar a rede remota, pero só cando a súa configuración de compartición coincide coa afirmación. Os cartafoles compartidos, a integración do portapapeis, os axentes de credenciais e as canles de xestión atravesan todos a fronteira que o espazo de traballo debía crear. A etiqueta do espazo de traballo non proba nada sobre cales deles están abertos.

A arquitectura de confianza cero de NIST enuncia o principio que hai detrás de todo isto: a localización de rede por si soa non outorga confianza implícita. A autenticación de recursos aínda ten traballo despois de que se admita o túnel, e tamén o ten a pregunta de quen máis comparte esa rede.

Que pode ver o operador na ruta

Unha VPN move o seu tráfico a outro lugar da ruta; non engade cifraxe de aplicacións. Se o provedor remata o seu TLS, o provedor pode ler o que o seu navegador tería protexido doutro xeito, e ningunha regra de devasas local o cambia.

Manteña a validación normal de certificados para o destino real e comprenda a ruta do resolvedor e dos metadatos, porque unha consulta DNS pode revelar máis que a carga útil que a precede. Só os metadatos, é dicir, a que enderezos contactou e cando, a miúdo responden a pregunta que o operador facía sen necesidade algunha de ler contido. Por iso «o tráfico está cifrado» e «o tráfico é privado» son afirmacións distintas.

Se esa visibilidade é inaceptable para a tarefa, a resposta é outra arquitectura aprobada en lugar de máis filtrado local. O filtrado local non pode quitar un observador dunha ruta na que aínda se senta.

Que pode cambiar o cliente local

Esta é a fronteira que a xente pasa por alto, e é a que deixa sen sentido as outras dúas. En Linux, CAP_NET_ADMIN cobre a configuración de interfaces, a administración da devasa e os cambios de rutas dentro do seu contexto de rede. O software que posúe esa capacidade pode reescribir a política que acaba de escribir.

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

Un espazo de nomes de rede é unha fronteira real para o estado de rede e unha mala para todo o demais: non illa o sistema de ficheiros nin o almacén de credenciais. Tráteo como unha capa e non como un contedor de todo o problema.

Obteña o cliente e a súa configuración dunha fonte mantida, revise a autoridade que solicita e manteña os compoñentes privilexiados baixo control de administrador. Unha máquina virtual pode formar parte dunha fronteira de avaliación cualificada sen converterse en permiso para executar un instalador inexplicado xunto a credenciais valiosas. O instalador execútase coa autoridade que lle dea, e esa autoridade é a fronteira.

Escriba que fronteira aceptou

Remate cunha frase que nomee catro cousas: o código local fiable, o acceso remoto permitido, os datos de aplicación protexidos e a relación co operador que queda. Esa frase vale máis que unha afirmación xeral de que unha VM, un sistema operativo ou un produto antivirus fixeron segura unha rede hostil.

Logo confirme que a operación estreita funciona e que a denegación requirida segue vixente, mesmo despois de que caia o túnel. Unha fronteira que só existe mentres o túnel está activo non é a fronteira que documentou.

Ningunha proba demostra que toda vulnerabilidade estea ausente, e unha revisión que afirme o contrario esaxera. A saída honesta nomea o risco residual e a persoa que o aceptou.