Feil VPN-forsøk: kva klasse påloggingsinformasjon kryssa grensa?
Eit mislukka forsøk kan ha sendt ingenting, eller gjeve eit passord til den som svara. Sorter artefakten før du avgjer kva som skal trekkjast tilbake.
Du kopla til feil VPN, og klienten rapporterte ein feil. Om det hadde noko å seie, kjem an på kva som gjekk over linja før feilen, og ordet sjølv fortel deg det ikkje. Nokre handtrykk ber ingen løyndom i det heile, medan andre gjev eit passord til kven som helst som svara på adressa. Finn ut kva av dei to hendingane som skjedde før du trekkjer noko tilbake.
Stopp og ta vare på prova
Ta vare på klientloggen, den valde profilen, adressa du skreiv inn og omtrentleg tidspunkt. Skriv dei ned utanfor klienten, fordi ei profilendring eller ein nyinstallering øydelegg oppteikninga du vil trengje. Stans kvart vidare forsøk til endepunktet er stadfesta over ein veg du kontrollerer.
Publiser aldri ein uredigert profil eller logg på eit offentleg forum medan du spør om forsøket var trygt. Desse dokumenta inneheld ofte ein sti til ein privat nøkkel, eit internt vertsnamn eller eit token, så rediger først og del med administratoren som eig endepunktet.
Kva som kan krysse grensa
Det meste av forvirringa kjem av å handsame kvar feil som éin type hending. Fire ulike ting kan nå den andre sida: eit offentleg sertifikat, ein signatur som provar at ein nøkkel vart brukt, eit passord eller eingongskode, og ei fil du valde sjølv. Kvar har si eiga følgje og si eiga reparasjon. Å sortere artefakten er steget som avgjer alt etterpå.
Sertifikattilfellet er det mildaste, fordi det som reiser er offentleg av design og identitetsfelta allereie er synlege for alle som koplar til. Ein signatur over ei utfordring seier at nøkkelen vart brukt, ikkje at han vart send. Eit passord er det motsette tilfellet: den som tek imot det kan prøve det andre stader, og ein teneste bygd for å stadfeste passord er den tiltenkte mottakaren av nettopp den verdien.
Eit nøkkelprov er ikkje ein nøkkelopplasting
Moderne TLS held dei to ideane med vilje frå kvarandre. RFC 8446 skildrar CertificateVerify-meldinga, der klienten signerer ei utfordring med den private nøkkelen som passar til sertifikatet. Signaturen viser eigarskap utan å bere nøkkelen, og difor er eit sertifikatautentisert forsøk ikkje automatisk ein nøkkelkompromiss.
Den beroliginga har ei grense det er verdt å nemne. Provet viser at nøkkelen deltok i den utvekslinga, og det seier ingenting om kva eit lokalt program på maskina kan ha lese allereie. Det seier heller ingenting om kor langt eit ukjent forsøk faktisk kom, og difor tyder loggen framleis meir enn teorien.
Passord følgjer ein heilt annan tillitsmodell. Ein konsentrator konfigurert med ein ekstern stadfestar kan sende den innsende verdien vidare, så å ta imot han er den tiltenkte funksjonen, og ein feil destinasjon er ei reell eksponering snarare enn ei teoretisk.
Bygg opp att forsøket frå loggen
Fire fakta byggjer opp att forsøket: adressa som faktisk vart kontakta, om identiteten til tenaren vart validert, kva autentiseringsmetode som vart vald, og kvar prosessen stoppa. Kvart av dei viser seg i ein klientlogg, og kvart av dei utelukkar ei anna historie. Ein feil om ruter eller ei tildelt adresse seier ingenting om kva som allereie var på linja, fordi autentiseringa kan ha fullført før tunneloppsettet mislukkast.
Trekk desse fakta ut av klienten sin eigen logg i staden for frå minnet. Eit smalt filter held utdata kort nok til å redigerast og delast:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Ikkje byt ut vertsnamnet med noko av dette. Eit kjent namn, eit gjeldande DNS-svar og ei sertifikatåtvaring som programvara viser skildrar notida og ikkje den tidlegare tilkoplinga. Ei passordførespurnad er heller ikkje prov for at noko vart sendt, sidan klienten kan ha mislukkast før han vart send inn.
Avgjer, og handle så
Avgjerda følgjer av artefakten, ikkje av kor alarmerande feilen såg ut. Les dei fire radene mot fakta du bygde opp att:
| 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 |
Viss eit passord nådde ei utilsikta teneste, endre det via kontoadministrasjonskanalen og sjekk kvar elles det vart brukt på nytt. Ein utlopen eingongskode stengjer den vegen, men ei økt oppretta med han gjer det ikkje, så be identitetsadministratoren gå gjennom økter. Viss ei nøkkelfil faktisk vart lasta opp, følg tilbaketrekkingsprosessen til organisasjonen som gav henne ut, i staden for å vente på prov for misbruk.
Skriv så ned det avgrensa resultatet: kva som vart sendt, kva som vert ukjent, og kva påloggingsinformasjon som krev handling. Det er den oppteikninga ein seinare gjennomgang vil be om, og ho er nyttigare enn nokon av dei to behagelege konklusjonane.