Intent de VPN equivocat: quina classe de credencial ha creuat?
Un intent fallit potser no ha enviat res, o ha lliurat una contrasenya a qui ha respost. Ordena l'artefacte abans de decidir què revocar.
Vas connectar amb el VPN equivocat i el client va informar d'una fallada. Si allò va tenir importància depèn del que va travessar el fil abans de la fallada, i la paraula no t'ho diu. Alguns intercanvis de salutació no porten cap secret, mentre que d'altres lliuren una contrasenya a qui va respondre a l'adreça. Esbrina quin dels dos casos va passar abans de revocar res.
Atura't i conserva les evidències
Conserva el registre del client, el perfil seleccionat, l'adreça que vas escriure i l'hora aproximada. Anota-ho en un lloc fora del client, perquè editar el perfil o reinstal·lar destrueix el registre que necessitaràs. Atura qualsevol intent posterior fins que l'extrem s'hagi confirmat per un camí que controlis.
No publiquis mai un perfil o un registre sense censurar en un fòrum públic mentre preguntes si l'intent era segur. Aquests documents sovint contenen un camí de clau privada, un nom d'amfitrió intern o un testimoni, així que censura primer i comparteix-ho amb l'administrador que posseeix l'extrem.
Què pot creuar la frontera
La major part de la confusió ve de tractar cada fallada com un sol tipus d'esdeveniment. Quatre coses diferents poden arribar a l'altre costat: un certificat públic, una signatura que demostra que s'ha fet servir una clau, una contrasenya o un codi d'un sol ús, i un fitxer que vas triar tu mateix. Cadascuna té la seva conseqüència i la seva reparació. Ordenar l'artefacte és el pas que decideix tot el que ve després.
El cas del certificat és el més lleu, perquè allò que viatja és públic per disseny i els seus camps identificadors ja són visibles per a qualsevol que es connecti. Una signatura sobre un repte diu que la clau s'ha fet servir, no que s'hagi enviat. Una contrasenya és el cas oposat: qui la rep pot provar-la en un altre lloc, i un servei fet per verificar contrasenyes és el destinatari previst d'exactament aquest valor.
Una prova de clau no és una pujada de clau
El TLS modern manté aquestes dues idees separades a propòsit. RFC 8446 descriu el missatge CertificateVerify, on el client signa un repte amb la clau privada que correspon al seu certificat. La signatura demostra possessió sense portar la clau, i per això un intent autenticat amb certificat no és automàticament una clau compromesa.
Aquest consol té un límit que val la pena dir. La prova mostra que la clau va participar en aquell intercanvi i no diu res sobre què pot haver llegit ja un programa local de la màquina. Tampoc no diu res sobre fins on va arribar realment un intent desconegut, i per això el registre continua sent més important que la teoria.
Les contrasenyes segueixen un model de confiança completament diferent. Un concentrador configurat amb un verificador extern pot fer passar el valor enviat, així que rebre'l és la funció prevista i una destinació equivocada és una exposició real, no teòrica.
Reconstrueix l'intent a partir del registre
Quatre fets reconstrueixen l'intent: l'adreça amb què realment es va contactar, si es va validar la identitat del servidor, quin mètode d'autenticació es va triar i on es va aturar el procés. Cadascun apareix en un registre del client, i cadascun descarta una història diferent. Un error sobre rutes o una adreça assignada no diu res sobre què ja era al fil, perquè l'autenticació pot haver acabat abans que fallés la configuració del túnel.
Extreu aquests fets del registre del propi client i no de la memòria. Un filtre estret manté la sortida prou curta per censurar-la i compartir-la:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30No substitueixis el nom d'amfitrió per res d'això. Un nom conegut, una resposta DNS actual i un avís de certificat que mostra el programari descriuen el present, no la connexió anterior. Una petició de contrasenya tampoc no és prova que s'hagi enviat res, ja que el client pot haver fallat abans d'enviar-la.
Decideix, i després actua
La decisió surt de l'artefacte, no de com d'alarmant semblava la fallada. Llegeix les quatre files contra els fets que has reconstruït:
| Decision | Evidence that puts you here | Evidence that rules it out |
|---|---|---|
| Change the password now | A password was submitted and a server reply arrived | The log stops before any submission |
| Review active sessions | A one-time code was accepted by the wrong endpoint | The code was never sent, or was rejected before use |
| Revoke and reissue | The file you selected contained key material, not just settings | The upload was a profile with no embedded key |
| No further action | The attempt ended before any authentication value was offered | You later find an earlier attempt you had forgotten |
Si una contrasenya ha arribat a un servei no desitjat, canvia-la pel canal de gestió del compte i comprova on més s'ha reutilitzat. Un codi d'un sol ús caducat tanca aquest camí, però una sessió creada amb ell no, així que demana a l'administrador d'identitat que revisi les sessions. Si un fitxer de clau es va pujar realment, segueix el procés de revocació de l'organització emissora en lloc d'esperar proves d'abús.
Després escriu el resultat limitat: què es va enviar, què continua sent desconegut i quina credencial necessita acció. Aquest registre és el que demanarà una revisió posterior, i és més útil que qualsevol de les dues conclusions còmodes.