Welk VPN-proces raakt die kwetsbaarheidsbevinding?

Een scannerresultaat noemt een adres, een poort en iets wat daar is onderhandeld. Het noemt niet het proces achter die socket, en op een VPN-host kunnen meerdere processen de machine delen terwijl slechts één ervan de tunnel is. Het lezen van een versiestring uit een hulpprogramma of het vinden van een bibliotheekbestand op schijf voegt bewijs toe over de host, niet over de listener. De bevinding wordt pas uitvoerbaar wanneer zij aan één lopende component wordt gekoppeld en vervolgens wordt vergeleken met de reikwijdte die een advies werkelijk noemt.

De volgorde is belangrijk: eerst de component, dan het advies, dan de herstelmaatregel.

Het rapport noemt een poort, geen programma

Begin bij het eindpunt dat werkelijk is beoordeeld. Een probe tegen de HTTPS-beheerpoort mat de webservice, de TLS-stack en elke proxy die ervoor staat; over de OpenVPN- of WireGuard-listener op een andere poort leerde zij niets. Reverse proxies en beheeragenten maken dit erger, omdat het certificaat en de banner bij de frontend kunnen horen terwijl de kwetsbare bibliotheek erachter in een backendproces zit.

Leg de bestemming, het transport, de poort en de dienstnaam samen met het resultaat vast, zodat de reikwijdte met de bevinding meereist.

Wat de lopende build werkelijk is

Op een host voor algemeen gebruik zijn het geïnstalleerde pakket en de geladen bibliotheek twee verschillende vragen. Een pakketdatabase kan een gepatchte versie vermelden terwijl een langlopende daemon nog het oude gedeelde object in het geheugen houdt, en een ingebouwde appliance-image kan eigen bibliotheken meedragen die geen pakketbeheerder meldt. Vraag de servicemanager wat er draait en onderzoek dan het proces en zijn koppelingen.

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

De starttijd in de proceslijst is het detail dat mensen overslaan. Een daemon die vóór de laatste pakketupdate is gestart, draait nog de build die hij bij het opstarten heeft geladen, en dat is precies het geval waarin een inventaris zegt gepatcht en de socket iets anders.

De build afstemmen op de reikwijdte van een advies

Adviezen beschrijven producten, versies en soms vereiste voorwaarden, en die drie velden komen niet altijd overeen met een pakketversie. OpenVPN's Heartbleed-advies van april 2014 is een nuttig historisch voorbeeld, omdat het getroffen Access Server-releases onderscheidt van de webservices en de VPN-daemons, die een andere blootstelling hadden. De les is te lezen welke component de tekst dekt in plaats van het woord OpenSSL op patroon te matchen.

Dat advies is ook gedateerd. De gepatchte releasenummers zijn nu geen installatieadvies, en een in 2014 verholpen fout zegt niets over latere problemen in de branch die je vandaag draait.

Het meningsverschil oplossen en dan de blootstelling sluiten

Wanneer inventaris en beoordeling van mening verschillen, controleer of beide hetzelfde eindpunt en dezelfde runtime beschrijven: een ander adres, een frontend-proxy, een tweede dienst, een oud proces dat nog aan de poort gebonden is, of een ingebouwde bibliotheek die de pakketbeheerder nooit heeft gezien. Los dat aan de grens op voordat je een rapport herschrijft.

Pas de ondersteunde correctie toe, herstart de betrokken dienst en bevestig dat de nieuwe build nu draait. Een gepatcht bestand op schijf terwijl het oude proces nog verkeer bedient, is geen herstel.

Behandel daarna wat de component tijdens het blootstellingsvenster kan hebben bevat. Patchen en het vervangen van inloggegevens beantwoorden verschillende vragen, en een certificaat dat dicht bij de getroffen host is opgeslagen, is op zichzelf geen lijst van wat er is gelekt. Volg de procedure van de incidenteigenaar voor intrekking, sessieverwijdering en clientupdates, en leg vast welke component getroffen was, waarom het bewijs van toepassing was en wat het heeft gesloten. Dat verslag is wat een latere beoordeling zal lezen.