Väärä VPN-yritys: mikä tunnistetietoluokka ylitti rajan?
Epäonnistunut yritys ei ehkä lähettänyt mitään tai luovutti salasanan sille, joka vastasi. Lajittele artefakti ennen kuin päätät, mitä peruuttaa.
Yhdistit väärään VPN:ään ja asiakasohjelma ilmoitti virheestä. Sillä, oliko sillä merkitystä, on väliä sen suhteen, mitä linjaa pitkin kulki ennen virhettä, eikä sana itse kerro sitä. Jotkin kättelyt eivät kanna lainkaan salaisuutta, kun taas toiset luovuttavat salasanan jokaiselle, joka vastasi osoitteeseen. Selvitä, kumpi kahdesta tapahtui, ennen kuin peruutat mitään.
Pysähdy ja säilytä todisteet
Säilytä asiakasohjelman loki, valittu profiili, kirjoittamasi osoite ja likimääräinen aika. Kirjoita ne jonnekin asiakasohjelman ulkopuolelle, sillä profiilin muokkaus tai uudelleenasennus tuhoaa tarvitsemasi tallenteen. Keskeytä kaikki jatkoyritykset, kunnes päätepiste on vahvistettu reittiä pitkin, jota hallitset.
Älä koskaan julkaise redigeeraamatonta profiilia tai lokia julkisella foorumilla kysyessäsi, oliko yritys turvallinen. Nämä asiakirjat sisältävät usein yksityisen avaimen polun, sisäisen isäntänimen tai tokenin, joten redigeeraa ensin ja jaa päätepisteen omistavalle ylläpitäjälle.
Mikä voi ylittää rajan
Suurin osa sekaannuksesta syntyy siitä, että jokaista epäonnistumista pidetään yhtenä tapahtumatyyppinä. Toiselle puolelle voi päätyä neljä eri asiaa: julkinen varmenne, allekirjoitus joka todistaa avainta käytetyn, salasana tai kertakäyttökoodi sekä tiedosto, jonka valitsit itse. Jokaisella on oma seurauksensa ja oma korjauksensa. Artefaktin lajittelu on vaihe, joka ratkaisee kaiken sen jälkeen.
Varmennetapaus on lievin, koska kulkeva asia on suunnittelultaan julkinen ja sen tunnistekentät ovat jo nähtävissä kaikille, jotka yhdistävät. Haasteeseen tehty allekirjoitus kertoo, että avainta käytettiin, ei että se lähetettiin. Salasana on päinvastainen tapaus: sen vastaanottaja voi kokeilla sitä muualla, ja salasanojen vahvistamiseen rakennettu palvelu on juuri tuon arvon aiottu vastaanottaja.
Avaintodiste ei ole avaimen lataus
Nykyaikainen TLS pitää nuo kaksi ajatusta tarkoituksella erillään. RFC 8446 kuvaa CertificateVerify-viestin, jossa asiakasohjelma allekirjoittaa haasteen varmennettaan vastaavalla yksityisellä avaimella. Allekirjoitus osoittaa hallussapitoa kantaen avainta mukanaan, minkä vuoksi varmenteella todennettu yritys ei automaattisesti ole avaimen vaarantuminen.
Tällä rauhoittelulla on raja, joka kannattaa mainita. Todiste näyttää, että avain osallistui tuohon vaihtoon, eikä se kerro mitään siitä, mitä koneen paikallinen ohjelma on ehkä jo lukenut. Se ei kerro myöskään siitä, kuinka pitkälle tuntematon yritys todella eteni, joten loki on edelleen teoriaa tärkeämpi.
Salasanat noudattavat täysin erilaista luottamusmallia. Ulkoisella vahvistimella määritetty keskitin voi välittää lähetetyn arvon eteenpäin, joten sen vastaanottaminen on aiottu toiminto ja väärä kohde on todellinen paljastuminen eikä teoreettinen.
Rakenna yritys uudelleen lokista
Neljä tosiseikkaa rakentavat yrityksen uudelleen: osoite, johon todella otettiin yhteyttä, vahvistettiinko palvelimen identiteetti, mikä todennusmenetelmä valittiin ja mihin prosessi pysähtyi. Jokainen näkyy asiakasohjelman lokissa, ja jokainen sulkee pois erilaisen tarinan. Virhe reiteistä tai osoitetusta osoitteesta ei kerro mitään siitä, mitä linjalla jo oli, koska todennus on voinut valmistua ennen kuin tunnelin määritys epäonnistui.
Ota nämä tosiseikat asiakasohjelman omasta lokista, älä muistista. Kapea suodatin pitää tulosteen riittävän lyhyenä redigeerattavaksi ja jaettavaksi:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Älä korvaa isäntänimeä millään näistä. Tuttu nimi, nykyinen DNS-vastaus ja ohjelmiston näyttämä varmennevaroitus kuvaavat nykyhetkeä eivätkä aiempaa yhteyttä. Salasanakehote ei sekään ole todiste siitä, että jotain lähetettiin, sillä asiakasohjelma on voinut epäonnistua ennen sen lähettämistä.
Päätä ja toimi sitten
Päätös seuraa artefaktista, ei siitä, kuinka hälyttävältä epäonnistuminen näytti. Lue neljä riviä uudelleenrakennettujen tosiseikkojen valossa:
| 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 |
Jos salasana päätyi ei-toivottuun palveluun, vaihda se tilin hallintakanavan kautta ja tarkista, missä muualla sitä on käytetty uudelleen. Vanhentunut kertakäyttökoodi sulkee tuon reitin, mutta sillä luotu istunto ei, joten pyydä identiteettiylläpitäjää tarkistamaan istunnot. Jos avaintiedosto todella ladattiin, noudata myöntävän organisaation peruutusprosessia sen sijaan, että odottaisit todisteita väärinkäytöstä.
Kirjoita sitten rajattu tulos muistiin: mitä lähetettiin, mikä jää tuntemattomaksi ja mikä tunnistetieto vaatii toimenpiteitä. Juuri sitä tallennetta myöhempi tarkastelu pyytää, ja se on hyödyllisempi kuin kumpikaan kahdesta mukavasta johtopäätöksestä.