Hvilken VPN-proces rammer den pågældende sårbarhedsfinding?

Et scannerresultat angiver en adresse, en port og noget, der blev forhandlet der. Det angiver ikke processen bag den socket, og på en VPN-vært kan flere processer dele maskinen, mens kun én af dem er tunnelen. At læse en versionsstreng fra et hjælpeværktøj eller finde en biblioteksfil på disken tilføjer bevis om værten, ikke om lytteren. Fundet bliver først handlingsdygtigt, når det knyttes til én kørende komponent og derefter matches med det omfang, en sikkerhedsmeddelelse faktisk angiver.

Rækkefølgen betyder noget: komponent først, meddelelse derefter, udbedring sidst.

Rapporten angiver en port, ikke et program

Begynd ved det endepunkt, der faktisk blev vurderet. En sondering mod HTTPS-administrationsporten målte webtjenesten, dens TLS-stak og den proxy, der ligger foran den; den lærte intet om OpenVPN- eller WireGuard-lytteren på en anden port. Omvendte proxyer og administrationsagenter gør det værre, fordi certifikatet og banneret kan tilhøre frontenden, mens det sårbare bibliotek ligger bagved i en baggrundsproces.

Registrér destination, transport, port og tjenestenavn sammen med resultatet, så omfanget følger med fundet.

Hvad den kørende build egentlig er

På en alsidig vært er den installerede pakke og det indlæste bibliotek to forskellige spørgsmål. En pakkedatabase kan liste en patchet version, mens en langvarig daemon stadig holder det gamle delte objekt kortlagt i hukommelsen, og et indbygget appliance-image kan bære sine egne biblioteker, som ingen pakkeadministrator rapporterer. Spørg servicemanageren, hvad der kører, og undersøg derefter processen og dens linkning.

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

Starttiden i proceslisten er den detalje, folk springer over. En daemon, der blev startet før den seneste pakkeopgradering, kører stadig den build, den indlæste ved opstart, og det er præcis tilfældet, hvor en oversigt siger rettet, og socketen siger noget andet.

At matche builden med omfanget i en meddelelse

Sikkerhedsmeddelelser beskriver produkter, versioner og nogle gange påkrævede betingelser, og de tre felter stemmer ikke altid overens med en pakkeversion. OpenVPN’s Heartbleed-meddelelse fra april 2014 er et nyttigt historisk eksempel, fordi den skelner berørte Access Server-udgivelser fra webtjenesterne og VPN-daemonerne, som havde forskellig eksponering. Læren er at læse, hvilken komponent teksten dækker, i stedet for at mønstermatch ordet OpenSSL.

Den meddelelse er også forældet. Dens rettede udgivelsesnumre er ikke installationsråd nu, og en fejl rettet i 2014 siger intet om senere problemer i den gren, du kører i dag.

At løse uenighed og derefter lukke eksponeringen

Når oversigt og vurdering er uenige, skal du kontrollere, om begge beskriver samme endepunkt og kørselsmiljø: en anden adresse, en frontend-proxy, en anden tjeneste, en gammel proces, der stadig er bundet til porten, eller et indbygget bibliotek, som pakkeadministratoren aldrig har set. Løs det ved grænsen, før du omskriver en rapport.

Anvend den understøttede rettelse, genstart den berørte tjeneste, og bekræft, at den nye build er den, der kører nu. En patchet fil på disken, mens den gamle proces stadig betjener trafik, er ikke udbedring.

Håndtér derefter det, komponenten kan have indeholdt i eksponeringsvinduet. Patching og udskiftning af legitimationsoplysninger besvarer forskellige spørgsmål, og et certifikat, der ligger nær den berørte vært, er ikke i sig selv en liste over, hvad der lækkede. Følg hændelsesejerens procedure for tilbagekaldelse, fjernelse af sessioner og klientopdateringer, og registrér, hvilken komponent der blev berørt, hvorfor beviserne var relevante, og hvad der lukkede det. Den registrering er det, en senere gennemgang vil læse.