Feil VPN-forsøk: hvilken klasse påloggingsopplysninger krysset grensen?
Et mislykket forsøk kan ha sendt ingenting, eller gitt et passord til den som svarte. Sorter artefakten før du bestemmer hva som skal tilbakekalles.
Du koblet til feil VPN, og klienten rapporterte en feil. Om det betydde noe avhenger av hva som gikk over linjen før feilen, og ordet selv forteller deg det ikke. Noen håndtrykk bærer ikke noen hemmelighet i det hele tatt, mens andre gir et passord til enhver som svarte på adressen. Finn ut hvilken av de to hendelsene som skjedde før du tilbakekaller noe.
Stopp og ta vare på bevisene
Ta vare på klientloggen, den valgte profilen, adressen du skrev inn og omtrentlig tidspunkt. Skriv dem ned utenfor klienten, fordi en profilendring eller en nyinstallering ødelegger opptegnelsen du vil trenge. Stans ethvert videre forsøk til endepunktet er bekreftet over en vei du kontrollerer.
Publiser aldri en uredigert profil eller logg på et offentlig forum mens du spør om forsøket var trygt. Disse dokumentene inneholder ofte en sti til en privat nøkkel, et internt vertsnavn eller et token, så rediger først og del med administratoren som eier endepunktet.
Hva som kan krysse grensen
Mesteparten av forvirringen kommer av å behandle hver feil som én type hendelse. Fire forskjellige ting kan nå den andre siden: et offentlig sertifikat, en signatur som beviser at en nøkkel ble brukt, et passord eller engangskode, og en fil du valgte selv. Hver har sin egen konsekvens og sin egen reparasjon. Å sortere artefakten er trinnet som avgjør alt etterpå.
Sertifikattilfellet er det mildeste, fordi det som reiser er offentlig av design og identitetsfeltene allerede er synlige for alle som kobler til. En signatur over en utfordring sier at nøkkelen ble brukt, ikke at den ble sendt. Et passord er det motsatte tilfellet: den som mottar det kan prøve det andre steder, og en tjeneste bygget for å verifisere passord er den tiltenkte mottakeren av nettopp den verdien.
Et nøkkelbevis er ikke en nøkkelopplasting
Moderne TLS holder de to ideene bevisst fra hverandre. RFC 8446 beskriver CertificateVerify-meldingen, der klienten signerer en utfordring med den private nøkkelen som passer til sertifikatet. Signaturen viser besittelse uten å bære nøkkelen, og derfor er et sertifikatautentisert forsøk ikke automatisk en nøkkelkompromittering.
Den beroligelsen har en grense det er verdt å nevne. Beviset viser at nøkkelen deltok i den utvekslingen, og det sier ingenting om hva et lokalt program på maskinen kan ha lest allerede. Det sier heller ingenting om hvor langt et ukjent forsøk faktisk kom, og derfor betyr loggen fortsatt mer enn teorien.
Passord følger en helt annen tillitsmodell. En konsentrator konfigurert med en ekstern verifiserer kan videresende den innsendte verdien, så å motta den er den tiltenkte funksjonen, og en feil destinasjon er en reell eksponering snarere enn en teoretisk.
Gjenoppbygg forsøket fra loggen
Fire fakta gjenoppbygger forsøket: adressen som faktisk ble kontaktet, om serverens identitet ble validert, hvilken autentiseringsmetode som ble valgt, og hvor prosessen stoppet. Hvert av dem vises i en klientlogg, og hvert av dem utelukker en annen historie. En feil om ruter eller en tildelt adresse sier ingenting om hva som allerede var på linjen, fordi autentiseringen kan ha fullført før tunneloppsettet mislyktes.
Trekk disse fakta ut av klientens egen logg i stedet for fra hukommelsen. Et smalt filter holder utdata kort nok til å redigeres og deles:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Ikke bytt ut vertsnavnet med noe av dette. Et kjent navn, et gjeldende DNS-svar og en sertifikatadvarsel som programvaren viser beskriver nåtiden og ikke den tidligere forbindelsen. En passordforespørsel er heller ikke bevis for at noe ble sendt, siden klienten kan ha feilet før den ble sendt inn.
Bestem, og handle så
Beslutningen følger av artefakten, ikke av hvor alarmerende feilen så ut. Les de fire radene mot faktaene du gjenoppbygde:
| 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 et passord nådde en utilsiktet tjeneste, endre det via kontoadministrasjonskanalen og sjekk hvor ellers det ble gjenbrukt. En utløpt engangskode lukker den veien, men en økt opprettet med den gjør det ikke, så be identitetsadministratoren gjennomgå økter. Hvis en nøkkelfil faktisk ble lastet opp, følg tilbakekallingsprosessen til organisasjonen som utstedte den, i stedet for å vente på bevis på misbruk.
Skriv så ned det avgrensede resultatet: hva som ble sendt, hva som forblir ukjent, og hvilke påloggingsopplysninger som krever handling. Det er den opptegnelsen en senere gjennomgang vil be om, og den er nyttigere enn noen av de to behagelige konklusjonene.