Hvilken VPN-prosess rammer det sårbarhetsfunnet?

Et skannerresultat navngir en adresse, en port og noe som ble forhandlet der. Det navngir ikke prosessen bak den socketen, og på en VPN-vert kan flere prosesser dele maskinen mens bare én av dem er tunnelen. Å lese en versjonsstreng fra et hjelpeverktøy eller finne en bibliotekfil på disken tilfører bevis om verten, ikke om lytteren. Funnet blir først handlingsdyktig når det knyttes til én kjørende komponent og deretter sammenlignes med omfanget en melding faktisk angir.

Rekkefølgen betyr noe: komponent først, melding neste, utbedring sist.

Rapporten navngir en port, ikke et program

Start ved endepunktet som faktisk ble vurdert. En sondering mot HTTPS-administrasjonsporten målte webtjenesten, TLS-stakken og enhver proxy foran den; den lærte ingenting om OpenVPN- eller WireGuard-lytteren på en annen port. Omvendte proxyer og administrasjonsagenter gjør det verre, fordi sertifikatet og banneret kan tilhøre frontenden mens det sårbare biblioteket ligger bak i en backend-prosess.

Registrer destinasjon, transport, port og tjenestenavn sammen med resultatet, slik at omfanget følger funnet.

Hva den kjørende byggingen egentlig er

På en allmenn vert er den installerte pakken og det innleste biblioteket to forskjellige spørsmål. En pakkedatabase kan liste en patchet versjon mens en langvarig daemon fortsatt holder det gamle delte objektet i minnet, og et innebygd apparatbilde kan bære egne biblioteker som ingen pakkebehandler rapporterer. Spør tjenestebehandleren hva som kjører, og undersøk deretter prosessen og dens koblinger.

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 prosesslisten er detaljen folk hopper over. En daemon som ble startet før den siste pakkeoppdateringen, kjører fortsatt byggingen den lastet ved oppstart, og det er nettopp tilfellet der en oversikt sier rettet og socketen sier noe annet.

Å matche byggingen mot omfanget i en melding

Meldinger beskriver produkter, versjoner og noen ganger nødvendige betingelser, og disse tre feltene samsvarer ikke alltid med en pakkeversjon. OpenVPNs Heartbleed-melding fra april 2014 er et nyttig historisk eksempel fordi den skiller berørte Access Server-utgivelser fra webtjenestene og VPN-daemonene, som hadde ulik eksponering. Lærdommen er å lese hvilken komponent teksten dekker, i stedet for å mønstermatche ordet OpenSSL.

Den meldingen er også utdatert. Dens rettede utgivelsesnumre er ikke installasjonsråd nå, og en feil rettet i 2014 sier ingenting om senere problemer i grenen du kjører i dag.

Å løse uenighet, og deretter lukke eksponeringen

Når oversikt og vurdering er uenige, sjekk om begge beskriver samme endepunkt og samme kjøretidsmiljø: en annen adresse, en frontend-proxy, en annen tjeneste, en gammel prosess som fortsatt er bundet til porten, eller et innebygd bibliotek pakkebehandleren aldri har sett. Løs det ved grensen før du skriver om en rapport.

Bruk den støttede rettelsen, start den berørte tjenesten på nytt og bekreft at den nye byggingen er den som kjører nå. En patchet fil på disken mens den gamle prosessen fortsatt betjener trafikk, er ikke utbedring.

Håndter deretter det komponenten kan ha holdt i eksponeringsvinduet. Patcheing og utskifting av legitimasjon svarer på forskjellige spørsmål, og et sertifikat som ligger nær den berørte verten er ikke i seg selv en liste over hva som lekket. Følg hendelseseierens prosedyre for tilbakekalling, fjerning av økter og klientoppdateringer, og registrer hvilken komponent som ble berørt, hvorfor bevisene gjaldt og hva som lukket det. Den registreringen er det en senere gjennomgang vil lese.