Vilken VPN-process träffar den där sårbarhetsupptäckten?

Ett skannerresultat namnger en adress, en port och något som förhandlades där. Det namnger inte processen bakom den socketen, och på en VPN-värd kan flera processer dela maskinen medan bara en av dem är tunneln. Att läsa en versionssträng från ett hjälpverktyg eller hitta en biblioteksfil på disken tillför bevis om värden, inte om lyssnaren. Upptäckten blir bara åtgärdbar när den kopplas till en körande komponent och sedan jämförs med den omfattning som en bulletin faktiskt anger.

Ordningen spelar roll: komponenten först, bulletinen sedan, åtgärden sist.

Rapporten namnger en port, inte ett program

Börja vid den slutpunkt som faktiskt utvärderades. En sond mot HTTPS-administrationsporten mätte webbtjänsten, dess TLS-stack och vilken proxy som helst framför den; den lärde sig inget om OpenVPN- eller WireGuard-lyssnaren på en annan port. Omvända proxyservrar och hanteringsagenter gör det värre, eftersom certifikatet och bannern kan tillhöra fronten medan det sårbara biblioteket ligger bakom i en backend-process.

Registrera destination, transport, port och tjänstenamn tillsammans med resultatet så att omfattningen följer med upptäckten.

Vad den körande byggen egentligen är

På en allmän värd är det installerade paketet och det inlästa biblioteket två skilda frågor. En paketdatabas kan lista en patchad version medan en långvarig daemon fortfarande håller det gamla delade objektet i minnet, och en inbäddad apparatavbildning kan bära egna bibliotek som ingen pakethanterare rapporterar. Fråga tjänstehanteraren vad som körs och undersök sedan processen och dess länkningar.

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 processlistan är detaljen folk hoppar över. En daemon som startades före den senaste paketuppdateringen kör fortfarande bygget den laddade vid uppstart, och det är precis det fall där en inventering säger patchad och socketen säger något annat.

Matcha bygget mot omfattningen i en bulletin

Bulletiner beskriver produkter, versioner och ibland nödvändiga villkor, och dessa tre fält stämmer inte alltid med en paketversion. OpenVPN:s Heartbleed-bulletin från april 2014 är ett användbart historiskt exempel eftersom den skiljer berörda Access Server-utgåvor från webbtjänsterna och VPN-demonerna, som hade olika exponering. Lärdomen är att läsa vilken komponent texten täcker i stället för att mönstermatcha ordet OpenSSL.

Den bulletinen är också daterad. Dess patchade utgivningsnummer är inte installationsråd nu, och en brist som åtgärdades 2014 säger ingenting om senare problem i den gren du kör i dag.

Lösa meningsskiljaktigheten och sedan stänga exponeringen

När inventering och bedömning inte stämmer, kontrollera om båda beskriver samma slutpunkt och samma körmiljö: en annan adress, en frontend-proxy, en andra tjänst, en gammal process som fortfarande är bunden till porten, eller ett inbäddat bibliotek som pakethanteraren aldrig har sett. Lös det vid gränsen innan du skriver om en rapport.

Tillämpa den stödda rättelsen, starta om den berörda tjänsten och bekräfta att det nya bygget är det som körs nu. En patchad fil på disken medan den gamla processen fortfarande betjänar trafik är ingen åtgärd.

Hantera sedan vad komponenten kan ha hållit under exponeringsfönstret. Patchning och byte av autentiseringsuppgifter svarar på olika frågor, och ett certifikat som lagras nära den berörda värden är inte i sig en lista över vad som läckte. Följ incidentägarens rutin för återkallelse, borttagning av sessioner och klientuppdateringar, och registrera vilken komponent som berördes, varför bevisen gällde och vad som stängde det. Den posten är vad en senare granskning kommer att läsa.