Com provar què cobreix un interruptor de seguretat en un amfitrió compromès

Activeu l'interruptor de seguretat, desconnecteu el servidor del túnel i observeu què fa encara la màquina. Aquesta prova val la pena perquè separa el que el tallafoc imposa del que vós suposàveu que imposava, i els resultats són més estrets del que suggereixen la majoria de pàgines de producte. L'interruptor de seguretat governa camins de xarxa; no governa el programari que ja s'executa al dispositiu. Faig aquesta seqüència a qualsevol màquina on el client afirmi que falla tancat, i triga uns deu minuts.

Comenceu pel client, no pel servidor

El punt d'aplicació és l'amfitrió on sou asseguts: el tallafoc del sistema operatiu, un servei auxiliar o el controlador del mateix client VPN. Això importa perquè tot el que pot fer l'interruptor està limitat pel que veu aquesta capa. Si el client implementa el bloqueig amb una regla d'encaminament més una marca, qualsevol cosa amb prou privilegis pot afegir una regla pròpia; si fa servir una taula de tallafoc del nucli, els mateixos privilegis poden editar la taula. La força del xifratge no entra mai en aquesta qüestió.

Per tant, el primer que cal establir és qui posseeix la política en aquest dispositiu i què se li permet anul·lar. En una màquina de treball gestionada la resposta sol ser l'agent d'extrem de l'organització, i una VPN personal no elimina aquestes capacitats, sigui com sigui configurat el túnel.

Pas u: confirmeu el bloqueig als camins que creieu que cobreix

Baixeu el túnel a l'extrem llunyà, no al client, perquè el client continuï creient que hauria d'estar connectat. A continuació proveu el que provaria una persona:

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

Voleu un client que falli ràpid i net, no un que pengi fins que el navegador esgoti el temps. Penjar-se sol voler dir que les regles descarten paquets en silenci sense rebutjar-los, cosa acceptable, però també pot voler dir que el client ha deixat una ruta per defecte obsoleta apuntant a una interfície morta. Llegiu la taula d'encaminament amb el túnel baixat: una ruta per defecte que encara apunta al dispositiu del túnel i una regla de tallafoc que només bloqueja connexions sortints noves són dos estats diferents, i només un és de fallada tancada.

Repetiu les mateixes ordres amb l'opció de permetre LAN del client activada i desactivada. Aquest commutador és on viuen la majoria de sorpreses, perquè reobre un camí que la resta de la política estava escrita per tancar.

Pas dos: comproveu DNS i IPv6 com a camins separats

La resolució de noms és el buit que sobreviu a la majoria d'implementacions, perquè la consulta pot sortir per una altra cosa que el resolutor del sistema. Pregunteu amb una eina que ignori la configuració del resolutor i comproveu el costat v6 mentre hi sou:

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

Respostes buides per a les dues consultes de nom amb el túnel baixat són el resultat que voleu. Si la segona consulta respon, una adreça de resolutor codificada és accessible i el túnel no és l'únic camí fora de la màquina. Si només té èxit la petició v6, la política cobreix IPv4 i ignora IPv6, que és la mateixa fuita en una altra família d'adreces.

Els navegadors ho fan més difícil de llegir des de fora, perquè un navegador configurat per a DNS sobre HTTPS resol la consulta amb una petició HTTPS: la consulta només està bloquejada tant com el port 443 cap a aquell extrem. En un amfitrió on la política permet la subxarxa local, aquesta petició encara pot arribar a un resolutor de la LAN.

Pas tres: separeu l'exposició de xarxa de l'exposició d'extrem

Ara la part on no arriba cap regla de tallafoc. L'interruptor bloqueja camins fora de la màquina; no impedeix que el programari de la màquina llegeixi dades abans de xifrar-les ni que aquell programari faci servir el túnel legítimament. Un keylogger, una extensió maliciosa, una pantalla deixada oberta, un client de sincronització amb permisos amplis: tots mouen informació per una connexió que l'interruptor permet de bon grat.

El mateix val per al programari de monitoratge que un empresari va instal·lar expressament. Bloquejar rutes no el treu, i comprar un servidor VPN nou no és la reparació, perquè l'exposició se situa abans del túnel.

Un gestor del porta-retalls que puja a un compte al núvol ho mostra amb claredat. El trànsit està xifrat, la destinació és permesa i l'interruptor informa d'un estat saludable tot el temps.

Pas quatre: escriviu l'afirmació que la prova permet

Després de la prova de caiguda podeu afirmar fets concrets: quines aplicacions van fallar, quins camins es van aturar, com es van comportar DNS i IPv6 i si el bloqueig va aguantar quan va caure el túnel. No podeu afirmar que el sistema operatiu estigui net, ni que un servei de l'extrem llunyà mantindrà privat el vostre inici de sessió.

Manteniu els dos problemes separats i doneu a cadascun el seu control:

• Interruptor de seguretat: el requisit de fallada definit, verificat amb una prova de caiguda que repetiu després de cada actualització del client.
• Confiança del dispositiu: actualitzacions suportades, protecció d'extrem d'una font fiable, revisió de permisos i avisos d'autenticació inexplicats.
• Incident: seguiu el procés de la plataforma o de l'organització quan se sospiti un compromís; un servidor nou no és un pas de neteja.
• Divulgació: quan demaneu ajuda, no enganxeu claus privades ni arxius de diagnòstic sencers, perquè els registres i les captures porten els mateixos secrets que la connexió.

Torneu a executar la seqüència després de la propera actualització, perquè un interruptor de seguretat és configuració que es mou amb les versions. La prova és l'única evidència que el comportament en què confieu és encara el que obteniu.