Kva VPN-prosess råkar det sårbarheitsfunnet?

Eit skannarresultat namngir ei adresse, ein port og noko som vart forhandla der. Det namngir ikkje prosessen bak den socketen, og på ein VPN-vert kan fleire prosessar dele maskina medan berre éin av dei er tunnelen. Å lese ein versjonsstreng frå eit hjelpeverktøy eller finne ei bibliotekfil på disken legg til prov om verten, ikkje om lyttaren. Funnet blir først handlingsdyktig når det blir knytt til éin køyrande komponent og deretter samanlikna med omfanget ei melding faktisk angir.

Rekkjefølgja er viktig: komponent først, melding neste, utbetring sist.

Rapporten namngir ein port, ikkje eit program

Start ved endepunktet som faktisk vart vurdert. Ein sondering mot HTTPS-administrasjonsporten målte nettenesta, TLS-stakken og kvar proxy som står framfor; ho lærte ingenting om OpenVPN- eller WireGuard-lyttaren på ein annan port. Omvende proxyar og administrasjonsagentar gjer det verre, fordi sertifikatet og banneret kan høyre til frontenden medan det sårbare biblioteket ligg bak i ein backend-prosess.

Registrer destinasjon, transport, port og tenestenamn saman med resultatet, slik at omfanget følgjer funnet.

Kva den køyrande bygginga eigentleg er

På ein allmenn vert er den installerte pakken og det innlesne biblioteket to ulike spørsmål. Ein pakkedatabase kan liste ein patcha versjon medan ein langvarig daemon framleis held det gamle delte objektet i minnet, og eit innebygd apparatbilete kan bere eigne bibliotek som ingen pakkehandsamar rapporterer. Spør tenestehandsamaren kva som køyrer, og undersøk deretter prosessen og koplingane hans.

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

Starttida i prosesslista er detaljen folk hoppar over. Ein daemon som vart starta før den siste pakkeoppdateringa, køyrer framleis bygginga han lasta ved oppstart, og det er nettopp tilfellet der ein oversikt seier retta og socketen seier noko anna.

Å matche bygginga mot omfanget i ei melding

Meldingar skildrar produkt, versjonar og stundom nødvendige vilkår, og desse tre felta samsvarar ikkje alltid med ein pakkeversjon. OpenVPNs Heartbleed-melding frå april 2014 er eit nyttig historisk døme fordi ho skil råka Access Server-utgåver frå nettenestene og VPN-daemonane, som hadde ulik eksponering. Lærdomen er å lese kva komponent teksten dekkjer, i staden for å mønstermatche ordet OpenSSL.

Den meldinga er også utdatert. Dei retta utgåvenumra hennar er ikkje installasjonsråd no, og ein feil som vart retta i 2014, seier ingenting om seinare problem i greina du køyrer i dag.

Å løyse usemja, og deretter lukke eksponeringa

Når oversikt og vurdering er usamde, sjekk om begge skildrar same endepunkt og same køyretidsmiljø: ei anna adresse, ein frontend-proxy, ei anna teneste, ein gammal prosess som framleis er bunden til porten, eller eit innebygd bibliotek pakkehandsamaren aldri har sett. Løys det ved grensa før du skriv om ein rapport.

Bruk den støtta rettinga, start den råka tenesta på nytt og stadfest at den nye bygginga er den som køyrer no. Ei patcha fil på disken medan den gamle prosessen framleis tenestegjer trafikk, er ikkje utbetring.

Handter deretter det komponenten kan ha halde i eksponeringsvindauget. Patcheing og utskifting av legitimasjon svarar på ulike spørsmål, og eit sertifikat som ligg nær den råka verten er ikkje i seg sjølv ei liste over kva som lak. Følg prosedyren til hendingseigaren for tilbakekalling, fjerning av økter og klientoppdateringar, og registrer kva komponent som vart råka, kvifor prova gjaldt og kva som lukka det. Den registreringa er det ei seinare gjennomgang vil lese.