Ez az OpenVPN biztonsági javítás egyáltalán a te telepítésedről szól?

A tanács, hogy javítsd a klienst, hogy ellenőrizze a tanúsítványokat, túl homályos ahhoz, hogy cselekedni lehessen rá. Leírhat egy javított szoftverhibát, egy szolgáltató régi buildjét, vagy egy profilt, amely soha nem kérte az ellenőrzést. Ez három különböző változás három különböző tulajdonossal. E mondat alapján cselekedni anélkül, hogy tudnád, melyikkel állsz szemben, az az út, ahogyan egy működő klienst ok nélkül módosítanak.

Válaszd szét a három állítást

A szoftverhibának van biztonsági közleménye, érintett verziói és javított kiadása. A szolgáltatói buildnek saját terjesztési csatornája és saját frissítési ritmusa van. A profil kihagyásának egyik sincs meg, mert a futtatható fájl rendben van, és a konfiguráció kevesebbet kér, mint amit feltételeztél. Amíg az állítás nem nevezi meg a három közül egyet, nincs mit tesztelni.

Írd le az állítást egyetlen mondatban, mielőtt keresnéd. Ha a mondat nem tudja megnevezni, mi tört el, a keresésnek nincs célpontja, és minden találat relevánsnak tűnik.

Találd meg a futtatható fájlt, amely valóban fut

Azonosítsd, mi indítja a kapcsolatot, mielőtt bármilyen verzióra pillantanál. Egy terjesztési szolgáltatás, egy asztali beépülő modul és egy szállítói alkalmazás különböző futtatható fájlt vagy motort használhat. Az a verzió, amelyet bármely bináris kiír, amely épp a shell keresési útvonalán van, nem a gép leltára. Olvasd el azt az unitot vagy folyamatot, amely valóban létrehozta a kapcsolatot.

systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpn

A csomaglekérdezés azt jelenti, hogy a helyi metaadatok mit tartanak telepítettnek és elérhetőnek, és ez a gyorsítótár elavult lehet, ezért először frissítsd. Arról sem mond semmit, hogy a futó szolgáltatás betöltött-e öt perccel ezelőtt telepített binárist. Hasonlítsd össze a csomagnyilvántartást a ténylegesen kapcsolódó folyamattal.

Csomagbizonyítékok verzióbenyomások helyett

A disztribúciók biztonsági karbantartása gyakran visszaportol javításokat, ezért egy régebbnek látszó upstream verzió még tartalmazhatja a foltot. Fordítva is igaz: egy ismeretlen tárolóból származó csomag nem hordoz automatikus igényt a jelenlegi karbantartásra. A kiadás támogatási állapotát olvasd, ne a verziószámot.

Ez a megkülönböztetés a különbség egy valódi rés és egy csupán réginek látszó szám között. Jegyezd fel a tárolót, ahonnan a csomag jött, mert ugyanaz a verziókarakterlánc nagyon különböző csatornákon, nagyon különböző támogatással érkezhet.

A konfiguráció a másik fele

Egy karbantartott futtatható fájlnak még mindig szüksége van egy profilra, amely kéri azokat az ellenőrzéseket, amelyeket úgy gondolsz, hogy megvannak. A bizalmi horgonyok, a másik fél szándékolt szerepe és az elvárt kiszolgálónév összefüggő, de külön döntések. A szerepellenőrzés nem névellenőrzés, és egyik sem helyettesíti a másikat. Ha a figyelmeztetés a konfigurációról szól, a javítás a profil tulajdonosáé.

Ne telepíts önkényes foltot egy nem ellenőrzött profil kompenzálására, és ne adj hozzá direktívát egy valódi megvalósítási hiba javítására. Mindkét hiba előrelépésnek tűnik, ezért mindkettő továbbra is megtörténik.

Dönts a nyilvántartás bizonyítékai alapján

A döntés abból következik, amit megállapítottál. Egy dokumentált érintett csomag a támogatott frissítését kívánja, egy nem támogatott platformnak migrációs útra van szüksége, és egy szolgáltatói kliensnek az adott szolgáltató útmutatására. Egy kétértelmű utasításnak közleményre és érintett komponensre van szüksége, mielőtt bármelyik alkalmazható lenne.

Tartsd együtt a változásnyilvántartásban az aktív klienst, a teljes verziót, a közleményt és a profil tulajdonosát. Ez erősebb egy útmutatóra való hivatkozásnál, és erre lesz valóban szüksége a következő embernek.