Watter VPN-proses raak daardie kwesbaarheidsbevinding?

’n Skandeerderuitslag noem ’n adres, ’n poort en iets wat daar onderhandel is. Dit noem nie die proses agter daardie sok nie, en op ’n VPN-gasheer kan verskeie prosesse die masjien deel terwyl net een van hulle die tonnel is. Om ’n weergawestring by ’n syprogram te lees of ’n biblioteeklêer op skyf te vind, voeg bewyse oor die gasheer by, nie oor die luisteraar nie. Die bevinding word eers uitvoerbaar wanneer dit aan een lopende komponent gekoppel word en dan met die omvang wat ’n advies werklik noem, vergelyk word.

Die volgorde maak saak: komponent eerste, advies tweede, regstelling derde.

Die verslag noem ’n poort, nie ’n program nie

Begin by die eindpunt wat werklik getoets is. ’n Toets teen die HTTPS-administrasiepoort het die webdiens, sy TLS-stapel en watter instaanbediener ook al daarvoor staan, gemeet; dit het niks oor die OpenVPN- of WireGuard-luisteraar op ’n ander poort geleer nie. Omgekeerde instaanbedieners en bestuursagente maak dit erger, want die sertifikaat en banier kan aan die voorkant behoort terwyl die kwesbare biblioteek daaragter in ’n backend-proses sit.

Teken die bestemming, transport, poort en diensnaam saam met die resultaat op, sodat die omvang saam met die bevinding reis.

Wat die lopende bou werklik is

Op ’n algemene gasheer is die geïnstalleerde pakket en die gelaai biblioteek aparte vrae. ’n Pakketdatabasis kan ’n gepakte weergawe lys terwyl ’n langdurige daemon steeds die ou gedeelde objek in die geheue vas het, en ’n saamgeboude toestelbeeld kan sy eie biblioteke dra wat geen pakketbestuurder rapporteer nie. Vra die diensbestuurder wat loop en ondersoek dan die proses en sy skakeling.

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

Die begintyd in die proseslys is die detail wat mense oorslaan. ’n Daemon wat voor die laaste pakketopgradering begin het, loop steeds die bou wat dit by die opstart gelaai het, en dit is presies die geval waar ’n inventaris sê reggemaak en die sok sê anders.

Om die bou by die omvang van ’n advies te pas

Adviese beskryf produkte, weergawes en soms vereiste voorwaardes, en daardie drie velde stem nie altyd met ’n pakketweergawe ooreen nie. OpenVPN se Heartbleed-advies van April 2014 is ’n nuttige historiese voorbeeld, want dit skei geaffekteerde Access Server-vrystellings van die webdienste en die VPN-daemons, wat verskillende blootstelling gehad het. Die les is om te lees watter komponent die teks dek eerder as om die woord OpenSSL patroon te pas.

Daardie advies is ook gedateer. Sy reggemaakte vrystellingsnommers is nou nie installasieadvies nie, en ’n fout wat in 2014 reggemaak is, sê niks oor latere probleme in die tak wat jy vandag loop nie.

Om meningsverskil op te los en dan blootstelling te sluit

Wanneer inventaris en beoordeling van mekaar verskil, kyk of albei dieselfde eindpunt en looptyd beskryf: ’n ander adres, ’n voorkant-instaanbediener, ’n tweede diens, ’n ou proses wat nog aan die poort gebind is, of ’n saamgeboude biblioteek wat die pakketbestuurder nooit gesien het nie. Los dit by die grens op voordat ’n verslag herskryf word.

Pas die ondersteunde regstelling toe, herbegin die betrokke diens en bevestig dat die nuwe bou die een is wat nou loop. ’n Gepakte lêer op skyf terwyl die ou proses nog verkeer bedien, is nie regstelling nie.

Hanteer dan wat die komponent tydens die blootstellingsvenster kon bevat het. Regmaak en die vervang van geloofsbriewe antwoord verskillende vrae, en ’n sertifikaat wat naby die geaffekteerde gasheer gestoor is, is nie op sigself ’n lys van wat gelek het nie. Volg die insident-eienaar se prosedure vir herroeping, sessieverwydering en kliëntopdaterings, en teken op watter komponent geaffekteer was, waarom die bewyse van toepassing was en wat dit gesluit het. Daardie rekord is wat ’n latere hersiening sal lees.