Ce proces VPN este vizat de această constatare de vulnerabilitate?

Rezultatul unui scaner numește o adresă, un port și ceva negociat acolo. Nu numește procesul din spatele acelui socket, iar pe un host VPN mai multe procese pot împărți mașina în timp ce doar unul dintre ele este tunelul. Citirea unui șir de versiune dintr-un utilitar lateral sau găsirea unui fișier de bibliotecă pe disc adaugă dovezi despre host, nu despre ascultător. Constatarea devine acționabilă doar când este atașată unui component în execuție și apoi comparată cu domeniul de aplicare pe care un aviz îl declară efectiv.

Ordinea contează: mai întâi componentul, apoi avizul, în final remedierea.

Raportul numește un port, nu un program

Începeți de la punctul final care a fost efectiv evaluat. O sondă împotriva portului de administrare HTTPS a măsurat serviciul web, stiva sa TLS și orice proxy din fața lui; nu a aflat nimic despre ascultătorul OpenVPN sau WireGuard de pe alt port. Proxy-urile inverse și agenții de management agravează situația, deoarece certificatul și bannerul pot aparține frontendului, în timp ce biblioteca vulnerabilă se află în spate, într-un proces backend.

Înregistrați destinația, transportul, portul și numele serviciului împreună cu rezultatul, astfel încât domeniul să călătorească cu constatarea.

Ce este de fapt build-ul în execuție

Pe un host de uz general, pachetul instalat și biblioteca încărcată sunt două întrebări separate. O bază de date de pachete poate lista o versiune corectată în timp ce un demon de lungă durată păstrează încă obiectul partajat vechi în memorie, iar o imagine de aparat inclusă poate purta propriile biblioteci pe care niciun manager de pachete nu le raportează. Întrebați managerul de servicii ce rulează, apoi inspectați procesul și legăturile lui.

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

Ora de pornire din lista de procese este detaliul pe care oamenii îl sar. Un demon pornit înainte de ultima actualizare de pachete rulează încă build-ul încărcat la boot, și exact acesta este cazul în care un inventar spune corectat, iar socketul spune altceva.

Potrivirea build-ului cu domeniul unui aviz

Avizele descriu produse, versiuni și uneori condiții necesare, iar aceste trei câmpuri nu se aliniază întotdeauna cu versiunea unui pachet. Avizul Heartbleed al OpenVPN din aprilie 2014 este un exemplu istoric util pentru că separă versiunile Access Server afectate de serviciile web și demonii VPN, care au avut expunere diferită. Lecția este să citiți ce component acoperă textul, în loc să potriviți cuvântul OpenSSL după tipar.

Acest aviz este și el vechi. Numerele sale de versiune corectate nu mai sunt sfaturi de instalare, iar o deficiență corectată în 2014 nu spune nimic despre probleme ulterioare din ramura pe care o rulați astăzi.

Rezolvarea neconcordanței, apoi închiderea expunerii

Când inventarul și evaluarea nu concordă, verificați dacă ambele descriu același punct final și același mediu de execuție: altă adresă, un proxy frontal, un al doilea serviciu, un proces vechi încă legat de port sau o bibliotecă inclusă pe care managerul de pachete nu a văzut-o niciodată. Rezolvați asta la graniță înainte de a rescrie un raport.

Aplicați corecția acceptată, reporniți serviciul afectat și confirmați că noul build este cel care rulează acum. Un fișier corectat pe disc în timp ce procesul vechi servește încă trafic nu este remediere.

Apoi ocupați-vă de ce a putut reține componentul în fereastra de expunere. Corectarea și înlocuirea acreditărilor răspund la întrebări diferite, iar un certificat păstrat lângă hostul afectat nu este în sine o listă a ceea ce a scăpat. Urmați procedura proprietarului incidentului pentru revocare, eliminarea sesiunilor și actualizări ale clienților, și consemnați ce component a fost afectat, de ce probele se aplicau și ce l-a închis. Acea consemnare este ce va citi o revizuire ulterioară.