Ferkearde VPN-poging: hokker type bewiis gie oer de grins?
In mislearre poging hat miskien neat stjoerd, of in wachtwurd jûn oan wa't antwurde. Sortearje it bewiisstik foardat jo beslute wat jo weromlûke.
Jo hawwe oan 'e ferkearde VPN ferbûn, en de klient melde in flater. Oft dat saaklik wie hinget ôf fan wat der foar de flater oer de line gie, en it wurd sels fertelt dat net. Guon hânskowen drage hielendal gjin geheim, wylst oaren in wachtwurd oerlangje oan wa't dan ek dat adres beantwurde. Bepaal hokker fan de twa gefallen barde foardat jo wat dan ek weromlûke.
Stop en bewarje it bewiis
Bewarje de kliïntlog, it keazen profyl, it adres dat jo typten en de likernôch tiid. Skriuw se earne bûten de klient del, want in profylbewurking of in weromynstallaasje ferneatiget it record dat jo nedich hawwe sille. Hâld elke fierdere poging tsjin oant it einpunt befêstige is oer in paad dat jo behearskje.
Plekje noait in ûnbewurke profyl of log op in iepenbier forum wylst jo freegje oft de poging feilich wie. Dizze dokuminten befetsje faak in paad nei in priveekaai, in ynterne hostnamme of in token, dus bewurkje earst en diel mei de administrator dy't it einpunt besit.
Wat oer de grins kin
It measte betizing komt derfan dat elke flater as ien soarte barren behannele wurdt. Fjouwer ferskillende dingen kinne de oare kant berikke: in iepenbier sertifikaat, in hantekening dy't bewiist dat in kaai brûkt is, in wachtwurd of ienmalige koade, en in bestân dat jo sels keazen hawwe. Elk hat syn eigen gefolch en syn eigen reparaasje. It sortearjen fan it bewiisstik is de stap dy't alles dêrnei beslút.
It gefal mei it sertifikaat is it mildst, want wat reizget is fanwege it ûntwerp iepenbier en syn identifisearjende fjilden binne al sichtber foar elkenien dy't ferbynt. In hantekening oer in útdaging seit dat de kaai brûkt is, net dat er stjoerd is. In wachtwurd is it tsjinoerstelde gefal: wa't it ûntfangt kin it earne oars besykje, en in tsjinst dy't boud is om wachtwurden te ferifiearjen is de bedoelde ûntfanger fan krekt dy wearde.
In kaai-bewiis is gjin kaai-oplaad
Moderne TLS hâldt dy twa ideeën mei opsetsin útinoar. RFC 8446 beskriuwt it CertificateVerify-berjocht, wêrby't de klient in útdaging ûndertekenet mei de priveekaai dy't by syn sertifikaat past. De hantekening bewiist besit sûnder de kaai te dragen, en dêrom is in poging mei sertifikaatferifikaasje net automatysk in kaai-kompromis.
Dy gerêststelling hat in grins dy't it neamen wurdich is. It bewiis lit sjen dat de kaai oan dy útwikseling meidie, en it seit neat oer wat in lokaal programma op 'e masine miskien al lêzen hat. It seit ek neat oer hoe fier in ûnbekende poging echt kaam is, en dêrom bliuwt de log noch wichtiger as de teory.
Wachtwurden folgje in hiel oar fertrouwensmodel. In konsintrator dy't mei in eksterne ferifiearjer konfigurearre is, kin de ynstjoerde wearde trochjaan, dus it ûntfangen dêrfan is de bedoelde funksje en in ferkearde bestimming is in echte bleatstelling ynstee fan in teoretyske.
Bou de poging op 'e nij út 'e log
Fjouwer feiten rekonstruearje de poging: it adres dat feitlik kontakt wie, oft de identiteit fan 'e tsjinner falidearre waard, hokker autentikaasjemetoade keazen waard, en wêr't it proses stoppe. Elk ferskynt yn in kliïntlog, en elk slút in oar ferhaal út. In flater oer rûtes of in tawiisd adres seit neat oer wat al op 'e line wie, want autentikaasje kin klear wêze foardat it ynstellen fan 'e tunnel mislearre.
Helje dy feiten út 'e eigen log fan 'e klient en net út it ûnthâld. In smel filter hâldt de útfier koart genôch om te bewurkjen en te dielen:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Ferfange de hostnamme net troch ien fan dizze. In fertroude namme, in aktueel DNS-antwurd en in sertifikaatwarskôging dy't de software toant beskriuwe it hjoed, net de eardere ferbining. In wachtwurdprompt is ek gjin bewiis dat der wat stjoerd is, want de klient kin mislearre wêze foardat it dat ynstjoerde.
Beslis, en hannelje dan
It beslút folget út it bewiisstik, net út hoe alaarmearjend de flater like. Lês de fjouwer rigen tsjin 'e feiten oan dy't jo rekonstruearre hawwe:
| 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 in wachtwurd in ûnbedoelde tsjinst berikt hat, feroarje it dan fia it kanaal foar akkountbehear en kontrolearje wêr't it oars werbrûkt is. In ferrûne ienmalige koade slút dat paad, mar in sesje dy't dermei makke is net, dus freegje de identiteitsadministrator om sesjes te besjen. As in kaai-bestân echt opladen is, folgje dan it weromlûkproses fan 'e útjaande organisaasje ynstee fan te wachtsjen op bewiis fan misbrûk.
Skriuw dan it begrinzge resultaat del: wat stjoerd is, wat ûnbekend bliuwt, en hokker bewiis aksje nedich hat. Dat record is wat in lettere beoardieling freegje sil, en it is nuttiger as ien fan 'e beide noflike konklúzjes.