Maling pagtatangkang VPN: aling uri ng kredensyal ang tumawid sa hangganan?
Ang nabigong pagtatangka ay maaaring walang ipinadala, o nag-abot ng password sa sinumang sumagot. Uriin ang artefakto bago magpasya kung ano ang babawiin.
Kumonekta ka sa maling VPN, at nag-ulat ng pagpalya ang kliyente. Kung may halaga iyon ay depende sa kung ano ang tumawid sa linya bago ang pagpalya, at hindi iyon sinasabi ng salita mismo. May mga handshake na wala talagang dinadalang lihim, habang ang iba ay nag-aabot ng password sa sinumang sumagot sa address. Alamin kung alin sa dalawa ang nangyari bago ka magbawi ng anuman.
Huminto at itago ang ebidensya
Itago ang log ng kliyente, ang napiling profile, ang address na itinaipa mo at ang tinatayang oras. Isulat ang mga ito sa labas ng kliyente, dahil ang pag-edit ng profile o muling pag-install ay sumisira sa rekord na kakailanganin mo. Itigil ang bawat susunod na pagtatangka hanggang makumpirma ang endpoint sa isang daang kontrolado mo.
Huwag kailanman mag-post ng hindi na-edit na profile o log sa pampublikong forum habang nagtatanong kung ligtas ang pagtatangka. Madalas naglalaman ang mga dokumentong iyon ng landas ng pribadong susi, panloob na hostname o token, kaya i-edit muna at ibahagi sa administrador na may-ari ng endpoint.
Ano ang maaaring tumawid sa hangganan
Karamihan ng kalituhan ay nagmumula sa pagtrato sa bawat pagpalya bilang isang uri ng pangyayari. Apat na magkaibang bagay ang maaaring makarating sa kabilang panig: isang pampublikong sertipiko, isang lagda na nagpapatunay na ginamit ang susi, isang password o one-time code, at isang file na ikaw mismo ang pumili. Bawat isa ay may sariling bunga at sariling pag-aayos. Ang pag-uuri ng artefakto ang hakbang na nagpapasya sa lahat ng sumusunod.
Ang kaso ng sertipiko ang pinakamagaan, dahil ang bumabiyahe ay pampubliko sa disenyo at ang mga field ng pagkakakilanlan nito ay nakikita na ng sinumang kumonekta. Ang lagda sa isang hamon ay nagsasabing ginamit ang susi, hindi na ipinadala ito. Ang password ang kabaligtaran: sinumang tumanggap nito ay maaaring subukan ito sa ibang lugar, at ang serbisyong itinayo upang beripikahin ang mga password ang sinadyang tatanggap ng halagang iyon.
Ang patunay ng susi ay hindi pag-upload ng susi
Ang makabagong TLS ay sadyang naghihiwalay sa dalawang ideyang iyon. Inilalarawan ng RFC 8446 ang mensaheng CertificateVerify, kung saan nilalagdaan ng kliyente ang hamon gamit ang pribadong susi na tumutugma sa sertipiko nito. Ipinapakita ng lagda ang pagmamay-ari nang hindi dinadala ang susi, kaya ang pagtatangkang pinatunayan ng sertipiko ay hindi awtomatikong pagkasira ng susi.
May hangganan ang kapanatagang iyon na dapat banggitin. Ipinapakita ng patunay na lumahok ang susi sa palitang iyon, at wala itong sinasabi tungkol sa maaaring nabasa na ng lokal na programa sa makina. Wala rin itong sinasabi tungkol sa kung gaano kalayo talaga ang narating ng isang hindi kilalang pagtatangka, kaya mas mahalaga pa rin ang log kaysa sa teorya.
Ang mga password ay sumusunod sa ganap na ibang modelo ng pagtitiwala. Ang isang concentrator na naka-configure sa panlabas na verifier ay maaaring ipasa ang isinumiteng halaga, kaya ang pagtanggap dito ang sinadyang tungkulin at ang maling destinasyon ay tunay na paglantad at hindi teoretikal.
Buuin muli ang pagtatangka mula sa log
Apat na katotohanan ang nagbubuo muli ng pagtatangka: ang address na talagang kinontak, kung na-validate ang pagkakakilanlan ng server, kung aling paraan ng pagpapatotoo ang pinili, at kung saan huminto ang proseso. Bawat isa ay lumilitaw sa log ng kliyente, at bawat isa ay nagbubukod ng ibang kuwento. Ang error tungkol sa mga ruta o itinalagang address ay walang sinasabi tungkol sa nasa linya na, dahil maaaring natapos na ang pagpapatotoo bago nabigo ang pag-set up ng tunnel.
Kunin ang mga katotohanang iyon mula sa sariling log ng kliyente at hindi mula sa memorya. Ang makitid na filter ay nagpapanatiling sapat na maikli ang output upang ma-edit at maibahagi:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Huwag palitan ng hostname ang alinman sa mga ito. Ang pamilyar na pangalan, kasalukuyang sagot ng DNS at babalang sertipiko na ipinapakita ng software ay naglalarawan ng kasalukuyan at hindi ng dating koneksyon. Ang hiling ng password ay hindi rin ebidensyang may ipinadala, dahil maaaring nabigo ang kliyente bago ito isumite.
Magpasya, pagkatapos kumilos
Ang desisyon ay nagmumula sa artefakto, hindi sa kung gaano kaalarma ang hitsura ng pagpalya. Basahin ang apat na hilera laban sa mga katotohanang binuo mong muli:
| 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 |
Kung ang isang password ay nakarating sa hindi sinasadyang serbisyo, palitan ito sa pamamagitan ng channel ng pamamahala ng account at tingnan kung saan pa ito ginamit muli. Ang nag-expire na one-time code ay nagsasara ng landas na iyon, ngunit ang session na nilikha gamit ito ay hindi, kaya hilingin sa administrador ng pagkakakilanlan na repasuhin ang mga session. Kung ang isang file ng susi ay talagang na-upload, sundin ang proseso ng pagbawi ng organisasyong naglabas sa halip na maghintay ng ebidensya ng pang-aabuso.
Pagkatapos, isulat ang limitadong resulta: ano ang ipinadala, ano ang nananatiling hindi alam, at aling kredensyal ang nangangailangan ng aksyon. Ang rekord na iyon ang hihilingin ng susunod na pagsusuri, at mas kapaki-pakinabang ito kaysa sa alinman sa dalawang maginhawang konklusyon.