Forkert VPN-forsøg: hvilken type legitimationsoplysning gik over grænsen?
Et mislykket forsøg kan have sendt intet som helst eller givet en adgangskode til den, der svarede. Sorter artefakten, før du beslutter, hvad der skal tilbagekaldes.
Du oprettede forbindelse til den forkerte VPN, og klienten rapporterede en fejl. Om det betød noget, afhænger af, hvad der gik over forbindelsen før fejlen, og ordet selv fortæller dig det ikke. Nogle håndtryk bærer slet ingen hemmelighed, mens andre udleverer en adgangskode til enhver, der svarede på adressen. Find ud af, hvilken af de to ting der skete, før du tilbagekalder noget.
Stop og gem beviserne
Bevar klientloggen, den valgte profil, den adresse du skrev, og det omtrentlige tidspunkt. Skriv dem ned uden for klienten, fordi en profilredigering eller en geninstallation ødelægger den registrering, du får brug for. Stands ethvert videre forsøg, indtil endepunktet er bekræftet ad en vej, du kontrollerer.
Læg aldrig en urelateret profil eller log ud på et offentligt forum, mens du spørger, om forsøget var sikkert. Disse dokumenter indeholder ofte en sti til en privat nøgle, et internt værtsnavn eller et token, så rediger først og del med den administrator, der ejer endepunktet.
Hvad kan krydse grænsen
Det meste af forvirringen kommer af at behandle hver fejl som én slags hændelse. Fire forskellige ting kan nå den anden side: et offentligt certifikat, en signatur der beviser, at en nøgle blev brugt, en adgangskode eller engangskode og en fil, du selv valgte. Hver har sin egen konsekvens og sin egen reparation. At sortere artefakten er det skridt, der afgør alt efter det.
Certifikattilfældet er det mildeste, fordi det, der rejser, er offentligt af design, og dets identificerende felter allerede er synlige for enhver, der forbinder. En signatur over en udfordring siger, at nøglen blev brugt, ikke at den blev sendt. En adgangskode er det modsatte tilfælde: den, der modtager den, kan prøve den andre steder, og en tjeneste bygget til at verificere adgangskoder er den tilsigtede modtager af netop den værdi.
Et nøglebevis er ikke en nøgleoverførsel
Moderne TLS holder de to idéer adskilt med vilje. RFC 8446 beskriver CertificateVerify-meddelelsen, hvor klienten signerer en udfordring med den private nøgle, der passer til dens certifikat. Signaturen demonstrerer besiddelse uden at bære nøglen, og derfor er et certifikatgodkendt forsøg ikke automatisk en kompromitteret nøgle.
Den beroligelse har en grænse, der er værd at nævne. Beviset viser, at nøglen deltog i den udveksling, og det siger intet om, hvad et lokalt program på maskinen måske allerede har læst. Det siger heller intet om, hvor langt et ukendt forsøg faktisk nåede, og derfor betyder loggen stadig mere end teorien.
Adgangskoder følger en helt anden tillidsmodel. En koncentrator konfigureret med en ekstern verifikator kan sende den indsendte værdi videre, så at modtage den er den tilsigtede funktion, og en forkert destination er en reel eksponering snarere end en teoretisk.
Genopbyg forsøget ud fra loggen
Fire kendsgerninger genopbygger forsøget: den adresse, der faktisk blev kontaktet, om serverens identitet blev valideret, hvilken godkendelsesmetode der blev valgt, og hvor processen stoppede. Hver af dem optræder i en klientlog, og hver udelukker en forskellig historie. En fejl om ruter eller en tildelt adresse siger intet om, hvad der allerede var på forbindelsen, fordi godkendelsen kan være fuldført, før tunnelopsætningen mislykkedes.
Træk de kendsgerninger ud af klientens egen log i stedet for af hukommelsen. Et snævert filter holder outputtet kort nok til at redigere og dele:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Erstat ikke værtsnavnet med noget af dette. Et velkendt navn, et aktuelt DNS-svar og en certifikatadvarsel vist af softwaren beskriver nutiden snarere end den tidligere forbindelse. En adgangskodeopfordring er heller ikke bevis for, at noget blev sendt, da klienten kan være fejlet, før den blev indsendt.
Beslut, og handl så
Beslutningen følger af artefakten, ikke af hvor alarmerende fejlen så ud. Læs de fire rækker op mod de kendsgerninger, du genopbyggede:
| 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 |
Hvis en adgangskode nåede en utilsigtet tjeneste, skal du ændre den via kontoadministrationskanalen og kontrollere, hvor ellers den blev genbrugt. En udløbet engangskode lukker den vej, men en session oprettet med den gør ikke, så bed identitetsadministratoren om at gennemgå sessioner. Hvis en nøglefil faktisk blev uploadet, skal du følge den udstedende organisations tilbagekaldelsesproces i stedet for at vente på bevis for misbrug.
Skriv derefter det afgrænsede resultat ned: hvad der blev sendt, hvad der forbliver ukendt, og hvilken legitimationsoplysning der kræver handling. Den registrering er det, en senere gennemgang vil spørge efter, og den er mere nyttig end nogen af de to behagelige konklusioner.