Verkeerde VPN-poging: watter tipe geloofsbrief het oorgesteek?
'n Mislukte poging het dalk niks gestuur nie, of 'n wagwoord aan die verkeerde ontvanger gegee. Sorteer die bewysstuk voordat jy besluit wat om te herroep.
Jy het aan die verkeerde VPN gekoppel, en die kliënt het 'n fout gerapporteer. Of dit saak maak, hang daarvan af wat voor die fout oor die draad gegaan het, en die woord self sê dit nie vir jou nie. Sommige handskud dra glad geen geheim nie, terwyl ander 'n wagwoord oorhandig aan wie ook al by daardie adres geantwoord het. Bepaal eers watter van die twee gebeur het voordat jy enigiets herroep.
Stop en bewaar die bewyse
Bewaar die kliëntlog, die gekose profiel, die adres wat jy ingetik het en die benaderde tyd. Skryf dit iewers buite die kliënt neer, want 'n profielwysiging of 'n herinstallasie vernietig die rekord wat jy nodig sal hê. Hou elke verdere poging terug tot die eindpunt bevestig is oor 'n pad wat jy beheer.
Moet nooit 'n ongeredigeerde profiel of log op 'n openbare forum plaas terwyl jy vra of die poging veilig was nie. Daardie dokumente bevat dikwels 'n privaatsleutelpad, 'n interne gasheernaam of 'n token, so redigeer eers en deel dit met die administrateur wat die eindpunt besit.
Wat oor die grens kan gaan
Die meeste verwarring kom daaruit dat elke fout as een soort gebeurtenis behandel word. Vier verskillende dinge kan die ander kant bereik: 'n openbare sertifikaat, 'n handtekening wat bewys dat 'n sleutel gebruik is, 'n wagwoord of eenmalige kode, en 'n lêer wat jy self gekies het. Elkeen het sy eie gevolg en sy eie herstel. Om die bewysstuk te sorteer is die stap wat alles daarna bepaal.
Die sertifikaatgeval is die sagste, want die ding wat reis is per ontwerp openbaar en sy identifiserende velde is reeds sigbaar vir enigiemand wat koppel. 'n Handtekening oor 'n uitdaging sê dat die sleutel gebruik is, nie dat dit gestuur is nie. 'n Wagwoord is die teenoorgestelde geval: wie ook al dit ontvang, kan dit elders probeer, en 'n diens wat gebou is om wagwoorde te verifieer is 'n bedoelde ontvanger van presies daardie waarde.
'n Sleutelbewys is nie 'n sleuteloplaai nie
Moderne TLS hou daardie twee idees doelbewus apart. RFC 8446 beskryf die CertificateVerify-boodskap, waar die kliënt 'n uitdaging met die privaatsleutel onderteken wat by sy sertifikaat pas. Die handtekening bewys besit sonder om die sleutel te dra, en daarom is 'n sertifikaat-geverifieerde poging nie outomaties 'n sleutelkompromie nie.
Daardie gerusstelling het 'n perk wat die moeite werd is om te noem. Die bewys wys die sleutel het aan daardie uitruiling deelgeneem, en dit sê niks oor wat 'n plaaslike program op die masjien dalk al gelees het nie. Dit sê ook niks oor hoe ver 'n onbekende poging werklik gekom het nie, en daarom bly die log steeds belangriker as die teorie.
Wagwoorde volg 'n heeltemal ander vertrouensmodel. 'n Konsentrator wat met 'n eksterne verifieerder opgestel is, kan die ingediende waarde deurstuur, so om dit te ontvang is die bedoelde funksie en 'n verkeerde bestemming is 'n werklike blootstelling eerder as 'n teoretiese een.
Herbou die poging uit die log
Vier feite rekonstrueer die poging: die adres wat werklik gekontak is, of die bedieneridentiteit bekragtig is, watter verifikasiemetode gekies is, en waar die proses gestop het. Elkeen verskyn in 'n kliëntlog, en elkeen sluit 'n ander verhaal uit. 'n Fout oor roetes of 'n toegewysde adres sê niks oor wat al op die draad was nie, want verifikasie kon voltooi het voordat die tonnelopstelling misluk het.
Onttrek daardie feite uit die kliënt se eie log eerder as uit geheue. 'n Nou filter hou die uitset kort genoeg om te redigeer en te deel:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Moenie die gasheernaam vir enigiets hiervan in die plek stel nie. 'n Bekende naam, 'n huidige DNS-antwoord en 'n sertifikaatwaarskuwing wat die sagteware wys, beskryf die hede eerder as die vroeër verbinding. 'n Wagwoordprompt is ook nie bewys dat iets gestuur is nie, want die kliënt kon misluk het voordat dit ingedien is.
Besluit, tree dan op
Die besluit volg uit die bewysstuk, nie uit hoe onrusbarend die fout gelyk het nie. Lees die vier rye teen die feite wat jy herbou het:
| 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 |
As 'n wagwoord 'n onbedoelde diens bereik het, verander dit deur die rekeningbestuurkanaal en kyk waar anders dit hergebruik is. 'n Verstreke eenmalige kode sluit daardie pad, maar 'n sessie wat daarmee geskep is nie, so vra die identiteitsadministrateur om sessies na te gaan. As 'n sleutellêer werklik opgelaai is, volg die uitreikende organisasie se herroepingsproses eerder as om op bewyse van misbruik te wag.
Skryf dan die begrensde resultaat neer: wat gestuur is, wat onbekend bly, en watter geloofsbrief optrede nodig het. Daardie rekord is wat 'n latere hersiening sal vra, en dit is nuttiger as enige van die twee gerusstellende gevolgtrekkings.