Melyik VPN-folyamatot érinti ez a sebezhetőségi lelet?

Egy szkánereredmény nevet ad egy címnek, egy portnak és valaminek, amiről ott megegyeztek. Nem nevezi meg az adott socket mögötti folyamatot, és egy VPN-gazdagépen több folyamat is osztozhat a gépen, miközben csak az egyikük az alagút. Egy verziószöveg beolvasása egy mellékeszközből vagy egy könyvtárfájl megtalálása a lemezen a gazdagépről, nem a figyelőről ad bizonyítékot. A lelet csak akkor válik kezelhetővé, ha egy futó komponenshez kapcsolják, majd összevetik azzal a hatókörrel, amelyet egy tanácsadás ténylegesen megad.

A sorrend számít: először a komponens, másodszor a tanácsadás, harmadszor a helyreállítás.

A jelentés portot nevez meg, nem programot

A ténylegesen értékelt végpontnál kezdje. Az HTTPS-adminisztrációs port elleni vizsgálat a webes szolgáltatást, annak TLS-veremét és az előtte álló proxyt mérte; semmit sem tudott meg a másik porton figyelő OpenVPN vagy WireGuard szolgáltatásról. A fordított proxyk és a felügyeleti ügynökök tovább rontják a helyzetet, mert a tanúsítvány és a banner a frontendhez tartozhat, miközben a sebezhető könyvtár mögötte, egy háttérfolyamatban van.

Rögzítse az úti célt, a szállítást, a portot és a szolgáltatás nevét az eredménnyel együtt, hogy a hatókör a lelettel együtt utazzon.

Mi is valójában a futó build

Egy általános célú gazdagépen a telepített csomag és a betöltött könyvtár külön kérdések. Egy csomagadatbázis javított verziót listázhat, miközben egy hosszú ideje futó démon még a régi megosztott objektumot tartja a memóriában, és egy beépített készülékkép saját könyvtárakat hordozhat, amelyekről egyetlen csomagkezelő sem számol be. Kérdezze meg a szolgáltatáskezelőt, mi fut, majd vizsgálja meg a folyamatot és annak kapcsolódásait.

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

A folyamatlistában szereplő indítási idő az a részlet, amelyet az emberek kihagynak. Az utolsó csomagfrissítés előtt indított démon még mindig a bootkor betöltött buildet futtatja, és pontosan ez az az eset, amikor a leltár azt mondja, javítva, a socket pedig mást.

A build összevetése egy tanácsadás hatókörével

A tanácsadások termékeket, verziókat és néha szükséges feltételeket írnak le, és ez a három mező nem mindig igazodik egy csomagverzióhoz. Az OpenVPN 2014 áprilisi Heartbleed-tanácsadása hasznos történelmi példa, mert elválasztja az érintett Access Server kiadásokat a webes szolgáltatásoktól és a VPN-démonoktól, amelyek kitettsége eltérő volt. A tanulság az, hogy olvassa el, melyik komponenst fedi a szöveg, ahelyett hogy az OpenSSL szót mintázat alapján egyeztetné.

Ez a tanácsadás is elavult. A javított kiadási számai ma már nem telepítési tanácsok, és egy 2014-ben javított hiba semmit sem mond a mai ág későbbi problémáiról.

Az ellentmondás feloldása, majd a kitettség lezárása

Amikor a leltár és az értékelés ellentmond, ellenőrizze, hogy mindkettő ugyanazt a végpontot és futtatókörnyezetet írja-e le: másik cím, frontend proxy, második szolgáltatás, a porthoz még kötött régi folyamat, vagy egy beépített könyvtár, amelyet a csomagkezelő soha nem látott. Oldja fel ezt a határon, mielőtt átír egy jelentést.

Alkalmazza a támogatott javítást, indítsa újra az érintett szolgáltatást, és erősítse meg, hogy most az új build fut. Egy lemezen javított fájl, miközben a régi folyamat még forgalmat szolgál ki, nem helyreállítás.

Ezután foglalkozzon azzal, amit a komponens a kitettségi ablak alatt tarthatott. A javítás és a hitelesítő adatok cseréje különböző kérdésekre válaszol, és az érintett gazdagép közelében tárolt tanúsítvány önmagában nem lista arról, mi szivárgott ki. Kövesse az incidens tulajdonosának eljárását a visszavonásra, a munkamenetek eltávolítására és az ügyfélfrissítésekre, és rögzítse, melyik komponenst érintette, miért voltak alkalmazhatók a bizonyítékok, és mi zárta le. Ezt a feljegyzést fogja olvasni egy későbbi felülvizsgálat.