VPN-telepítő tükörből? Először ellenőrizze a kiadót

A letöltési csatorna dönti el, milyen kód fut és ki frissítheti. Először ellenőrizze az aláírást, az ellenőrzőösszeg forrását és a profil kiállítóját.

Az alagút működött, a felület megjelent, és a munkamenet egy hétig stabil maradt. Ebből semmi sem mondja meg, ki építette a telepítőt. A VPN-kliens elegendő jogosultsággal fut ahhoz, hogy átírja az útvonalakat és olvassa a hitelesítő adatokat, ezért a kiadó a fenyegetésmodell része, nem lábjegyzet.

Végezze el az ellenőrzéseket sorrendben, és álljon meg az elsőnél, amelyik elbukik. Olcsók, és mindegyik más rést zár be.

Első lépés: Onnan töltse le, ahonnan a projekt mondja

Minden projekt dokumentálja, hol találhatók a kiadásai, és az az oldal a referencia. A közösségi buildok, az áruházi listázások és a beszállítói portálok mind legitim csatornák. Mindegyik csak akkor legitim, ha maga a projekt mutat rá. Ez a teszt, és nem ugyanaz, mint hivatalosnak látszani.

Egy projektről elnevezett fájl semmit sem bizonyít. A telepítő átnevezése egy másodperces művelet, és a név az, amit a keresési találat először mutat.

Második lépés: Ellenőrizze az aláírást egy ismert identitással szemben

Az aláírás-ellenőrzés jól válaszol egy szűk kérdésre. Megmondja, hogy egy adott identitás aláírta ezt a bináris fájlt, és hogy a fájl azóta nem változott. Válaszol az egyik kérdésre, és elutasít egy másikat. Nem tudja megmondani, hogy ez az identitás-e az, amelyben meg akart bízni.

# macOS: who signed this app, and is the signature intact?
codesign -dv --verbose=4 /Applications/Tunnel.app
spctl -a -vvv -t install /Applications/Tunnel.app

# Windows: signature and publisher of the installer
Get-AuthenticodeSignature .\tunnel-setup.exe | Format-List Status, SignerCertificate

# Linux: detached signature from the project's release page
gpg --verify tunnel-1.4.2.tar.gz.asc tunnel-1.4.2.tar.gz

Az identitást olvassa, ne a státuszszót. Egy nem kapcsolódó fejlesztő érvényes tanúsítvánnyal érvényes aláírást állít elő. Egy operációs rendszer, amely elismert kiadót jelent, csak azt mondta meg, hogy valaki fizetett egy tanúsítványért.

Harmadik lépés: Hasonlítsa össze a hash-t független forrással

Az ellenőrzőösszeg bizonyítja az egyezést egy referênciaértékkel. Ha a referencia a letöltés mellé érkezett, mindkettő lehet egyszerre hibás, és az összehasonlítás mégis átmegy. Ez a hiba módja a legtöbb útmutatóban. A hash ugyanazon az oldalon van, mint az a fájl, amelyet leír.

# Linux and macOS
shasum -a 256 tunnel-1.4.2.dmg

# compare against the value published on the project's own release page
# not against a value copied from the same mirror

Amikor egy projekt aláírt ellenőrzőösszegeket vagy aláírt kiadási jegyzéket tesz közzé, az aláírást a lista fölött ellenőrizze, ne külön minden fájl fölött. Így egy megbízható referencia lefedi a teljes kiadást.

Telepítés után: Tartsa meg a frissítési útvonalat

Egy támogatott csatorna a telepítés befejezése után is számít. Az újracsomagolt buildok saját frissítőt hozhatnak, és az a frissítő dönti el, mi fut jövő hónapban. Egy build, amely soha nem frissül, nem biztonságosabb. Egyszerűen régebbi.

Jegyezze fel, hogyan kellene a kliensnek frissülnie, és hogy egy kezelőrendszer birtokolja-e ezt a lépést. Ha a válasz egy fórumról történő kézi letöltés, az ellátási lánc kérdése soha nem zárult be igazán.

Két eredet, nem egy

A kliens fejlesztője és a profil kiadója külön felek. Egy hivatalos kliens, amely nem kapcsolódó szolgáltatótól importál profilt, normális elrendezés, és a profil saját vizsgálatot érdemel: ki adta ki, hogyan jutott el, és megfelel-e a szerver tanúsítványa a várt névnek.

Tartsa mindkét eredetet felismerhetően a jegyzeteiben. Abban a pillanatban, amikor egy klienst lecserélnek vagy egy eszközt biztonsági másolatból állítanak helyre, ez a két sor az, ami megakadályozza, hogy egy ismeretlen build vagy egy ismeretlen profil visszatérjen a többi adattal.

Kapcsolódó cikkek