Téves VPN-kísérlet: melyik hitelesítőadat-osztály lépte át a határt?
Egy sikertelen kísérlet lehet, hogy semmit nem küldött, vagy átadta a jelszót annak, aki válaszolt. Osztályozza az artefaktumot, mielőtt eldönti, mit von vissza.
A rossz VPN-hez csatlakozott, és a kliens hibát jelzett. Hogy ennek volt-e jelentősége, attól függ, mi ment át a vonalon a hiba előtt, és maga a szó nem mondja meg. Egyes kézfogások egyáltalán nem hordoznak titkot, mások viszont jelszót adnak át mindenkinek, aki válaszolt a címre. Állapítsa meg, melyik eset történt, mielőtt bármit visszavon.
Álljon meg és őrizze meg a bizonyítékokat
Őrizze meg a kliens naplóját, a kiválasztott profilt, a beírt címet és a hozzávetőleges időpontot. Írja le őket a klienstől külön, mert egy profil szerkesztése vagy egy újratelepítés megsemmisíti a szükséges feljegyzést. Tartóztasson fel minden további kísérletet, amíg a végpontot egy Ön által ellenőrzött útvonalon meg nem erősítik.
Soha ne tegyen közzé szerkesztetlen profilt vagy naplót nyilvános fórumon, miközben azt kérdezi, biztonságos volt-e a kísérlet. Ezek a dokumentumok gyakran tartalmaznak privátkulcs-útvonalat, belső hosztnevet vagy tokent, ezért először szerkessze, és ossza meg a végpont tulajdonosával, a rendszergazdával.
Mi lépheti át a határt
A zavar nagy része abból ered, hogy minden hibát egyfajta eseményként kezelünk. Négy különböző dolog juthat át a másik oldalra: nyilvános tanúsítvány, egy kulcs használatát igazoló aláírás, jelszó vagy egyszeri kód, és egy Ön által kiválasztott fájl. Mindegyiknek megvan a maga következménye és a maga javítása. Az artefaktum osztályozása az a lépés, amely minden továbbit eldönt.
A tanúsítvány esete a legenyhébb, mert ami utazik, az tervezésénél fogva nyilvános, és azonosító mezői már mindenki számára láthatók, aki csatlakozik. Egy kihívásra adott aláírás azt mondja, hogy a kulcsot használták, nem azt, hogy elküldték. A jelszó az ellenkező eset: aki megkapja, máshol is kipróbálhatja, és a jelszavak ellenőrzésére épült szolgáltatás éppen ennek az értéknek a szándékolt címzettje.
A kulcs bizonyítása nem kulcsfeltöltés
A modern TLS szándékosan választja külön ezt a két gondolatot. RFC 8446 írja le a CertificateVerify üzenetet, amelyben a kliens a tanúsítványához tartozó privát kulccsal ír alá egy kihívást. Az aláírás a kulcs hordozása nélkül bizonyítja a birtoklást, ezért a tanúsítvánnyal hitelesített kísérlet nem automatikusan kulcs kompromittálódás.
Ennek a megnyugtatásnak van egy határa, amelyet érdemes kimondani. A bizonyíték azt mutatja, hogy a kulcs részt vett abban a cserében, és semmit sem mond arról, mit olvashatott már egy helyi program a gépen. Arról sem mond semmit, milyen messzire jutott valójában egy ismeretlen kísérlet, ezért a napló továbbra is fontosabb az elméletnél.
A jelszavak teljesen más bizalmi modellt követnek. Egy külső ellenőrzővel beállított koncentrátor továbbadhatja a benyújtott értéket, így annak fogadása a szándékolt funkció, a rossz cél pedig valódi kitettség, nem elméleti.
Építse újra a kísérletet a naplóból
Négy tény építi újra a kísérletet: a ténylegesen felkeresett cím, hogy ellenőrizték-e a szerver identitását, melyik hitelesítési módszert választották, és hol állt meg a folyamat. Mindegyik megjelenik egy kliens naplójában, és mindegyik kizár egy másik történetet. Az útvonalakra vagy egy kiosztott címre vonatkozó hiba semmit sem mond arról, mi volt már a vonalon, mert a hitelesítés befejeződhetett, mielőtt az alagút beállítása meghiúsult.
Ezeket a tényeket a kliens saját naplójából nyerje ki, ne az emlékezetéből. Egy szűk szűrő elég rövidre tartja a kimenetet a szerkesztéshez és a megosztáshoz:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Semmi ne helyettesítse a hosztnevet ezek közül. Egy ismerős név, egy aktuális DNS-válasz és a szoftver által mutatott tanúsítványfigyelmeztetés a jelent írja le, nem a korábbi kapcsolatot. A jelszóra való felszólítás sem bizonyítéka annak, hogy valami elküldésre került, mert a kliens az elküldés előtt is meghiúsulhatott.
Döntsön, aztán cselekedjen
A döntés az artefaktumból következik, nem abból, mennyire ijesztőnek tűnt a hiba. Olvassa el a négy sort az újraépített tények ellenében:
| 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 |
Ha egy jelszó nem kívánt szolgáltatáshoz jutott, változtassa meg a fiókkezelési csatornán, és ellenőrizze, hol használták még újra. Egy lejárt egyszeri kód zárja azt az utat, de a vele létrehozott munkamenet nem, ezért kérje meg az identitás-rendszergazdát a munkamenetek átvizsgálására. Ha egy kulcsfájl ténylegesen felkerült, kövesse a kibocsátó szervezet visszavonási folyamatát, ahelyett hogy a visszaélés bizonyítékára várna.
Ezután írja le a korlátozott eredményt: mi került elküldésre, mi marad ismeretlen, és melyik hitelesítő adat igényel intézkedést. Ez az a feljegyzés, amelyet egy későbbi felülvizsgálat kérni fog, és hasznosabb a két kényelmes következtetés bármelyikénél.