Como comprobar que cobre un interruptor de emerxencia nun host comprometido

Executa a proba de caída, le o resultado de cada capa e mira onde se detén un interruptor de emerxencia: bloquea rutas, non o software que le datos antes do cifrado.

Activa o interruptor de emerxencia, desconecta o servidor do túnel e observa que segue facendo a máquina. A proba paga a pena porque separa o que o devasa impón do que ti supoñías, e os resultados son máis estreitos do que suxiren a maioría das páxinas de produto. Un interruptor de emerxencia goberna rutas de rede; non goberna o software que xa se executa no dispositivo. Executo esta secuencia en calquera máquina cuxo cliente afirme ser fail-closed, e tarda uns dez minutos.

Comeza polo cliente, non polo servidor

O punto de aplicación é o host no que estás sentado: o devasa do sistema operativo, un servizo auxiliar ou o propio controlador do cliente VPN. Iso importa porque todo o que pode facer o interruptor está limitado polo que ve esa capa. Se o cliente implementa o bloqueo cunha regra de encamiñamento máis unha marca, calquera cousa con privilexios suficientes pode engadir a súa propia regra; se usa unha táboa de devasa do núcleo, os mesmos privilexios poden editar a táboa. A forza do cifrado nunca entra nesta cuestión.

Así que o primeiro que hai que establecer é quen posúe a política neste dispositivo e que se lle permite anular. Nunha máquina de traballo xestionada a resposta adoita ser o axente de punto final da organización, e unha VPN persoal non elimina esas capacidades, se configure como se configure o túnel.

Primeiro paso: confirma o bloqueo nas rutas que cres que cobre

Baixa o túnel no extremo remoto, non no cliente, para que o cliente siga crendo que debería estar conectado. Despois proba o que probaría unha persoa:

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

Queres un cliente que falla rápido e limpo, non un que se colga ata o tempo de espera do navegador. Colgarse adoita significar que unha regra descarta paquetes en silencio sen rexeitalos, o cal é aceptable, pero tamén pode significar que o cliente deixou unha ruta por defecto obsoleta apuntando a unha interface morta. Le a táboa de encamiñamento co túnel baixado: unha ruta por defecto que aínda apunta ao dispositivo do túnel e unha regra de devasa que só bloquea conexións saíntes novas son dous estados distintos, e só un é de fallo pechado.

Repite os mesmos comandos coa opción de permitir LAN do cliente activada e desactivada. Ese conmutador é onde viven a maioría das sorpresas, porque reabre unha ruta que o resto da política estaba escrita para pechar.

Segundo paso: comproba DNS e IPv6 como rutas separadas

A resolución de nomes é o oco que sobrevive á maioría das implementacións, porque a consulta pode saír por algo distinto do resolutor do sistema. Pregunta cunha ferramenta que ignore a túa configuración de resolutor e comproba o lado v6 de paso:

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 baleiras para as dúas consultas de nome co túnel baixado son o resultado que queres. Se a segunda consulta responde, un enderezo de resolutor codificado é accesible e o túnel non é a única saída da máquina. Se só ten éxito a petición v6, a política cobre IPv4 e ignora IPv6, que é a mesma fuga noutra familia de enderezos.

Os navegadores fan isto máis difícil de ler desde fóra, porque un configurado para DNS sobre HTTPS resolve a consulta mediante unha petición HTTPS: a consulta só está bloqueada na medida en que o estea o porto 443 cara a ese extremo. Nun host onde a política permite a subrede local, esa petición aínda pode chegar a un resolutor na LAN.

Terceiro paso: separa a exposición de rede da exposición do punto final

Agora a parte que ningunha regra de devasa alcanza. Un interruptor de emerxencia bloquea rutas fóra da máquina; non impide que o software da máquina lea datos antes de cifralos nin que ese software use o túnel de forma lexítima. Un keylogger, unha extensión maliciosa, unha pantalla deixada desbloqueada, un cliente de sincronización con permisos amplos: todos moven información por unha conexión que o interruptor permite de bo grado.

O mesmo vale para o software de monitorización que un empresario instalou a propósito. Bloquear rutas non o elimina, e comprar un servidor VPN novo non é a reparación, porque a exposición está antes do túnel.

Un xestor de portapapeis que sobe a unha conta na nube móstrao con claridade. O tráfico está cifrado, o destino está permitido e o interruptor informa dun estado saudable todo o tempo.

Cuarto paso: escribe a afirmación que respalda a túa proba

Tras a proba de caída podes afirmar feitos concretos: que aplicacións fallaron, que rutas se detiveron, como se comportaron DNS e IPv6 e se o bloqueo aguantou cando caeu o túnel. Non podes afirmar que o sistema operativo estea limpo, nin que un servizo do extremo remoto manteña privado o teu inicio de sesión.

Mantén os dous problemas separados e dálle a cada un o seu propio control:

  • Interruptor de emerxencia: o requisito de fallo definido, verificado cunha proba de caída que repites tras cada actualización do cliente.
  • Confianza do dispositivo: actualizacións compatibles, protección de punto final dunha fonte fiable, revisión de permisos e avisos de autenticación inxustificados.
  • Incidente: segue o proceso da plataforma ou da organización cando se sospeite un compromiso; un servidor novo non é un paso de limpeza.
  • Divulgación: cando pidas axuda, non pegues claves privadas nin arquivos de diagnóstico completos, porque os rexistros e as capturas levan os mesmos segredos que a conexión.

Executa a secuencia de novo tras a próxima actualización, porque un interruptor de emerxencia é configuración que se move coas versións. A proba é a única evidencia de que o comportamento no que confías segue sendo o que obtés.

Artigos relacionados