Hokker VPN-proses rekket dy kwetsberheidsbefining?

In skannerresultaat neamt in adres, in poarte en eat dat dêr ûnderhannele is. It neamt net it proses efter dy socket, en op in VPN-host kinne ferskate prosessen de masine diele wylst mar ien fan harren de tunnel is. It lêzen fan in ferzje-string út in sydhelp en it finen fan in biblioteektriem op skiif foeget bewiis oer de host ta, net oer de listener. De befining wurdt pas útfierber as it oan ien rinnend komponint ferbûn wurdt en dan ferlike wurdt mei de omfang dy’t in advys feitlik neamt.

De oarder is wichtich: komponint earst, advys twadde, remediearring tredde.

It rapport neamt in poarte, net in programma

Begjin by it einpunt dat feitlik beoardiele is. In probe tsjin de HTTPS-administraasjepoarte mjitten de websjinst, syn TLS-stapel en hokker proxy dan ek derfoar sit; it learde neat oer de OpenVPN- of WireGuard-listener op in oare poarte. Omkearde proxys en behearagenten meitsje dit slimmer, om’t it sertifikaat en de banner by de foarkant hearre kinne wylst de kwetsbere biblioteek der efter sit yn in eftergrûnproses.

Registrearje it bestimming, it ferfier, de poarte en de tsjinstnamm by it resultaat, sadat de omfang mei de befining reizget.

Wat de rinnende build feitlik is

Op in host foar algemien gebrûk binne it ynstallearre pakket en de laden biblioteek aparte fragen. In pakketdatabez stiet miskien in patchte ferzje, wylst in langrinnende daemon noch it âlde mienskiplike objekt yn it ûnthâld hâldt, en in ynsletten apparaatbyld kin syn eigen biblioteken drage dy’t gjin pakketbehearder rapportearret. Freegje de tsjinstbehearder wat rint en ûndersykje dan it proses en syn keppelingen.

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 starttime yn de proseslist is it detail dat minsken oerslaan. In daemon dy’t foar de lêste pakketfernijing start is, rint noch de build dy’t er by it opstarten laden hat, en dat is krekt it gefal wêryn in ynventaris seit reparearre en de socket seit oars.

De build oanpasse oan de omfang fan in advys

Advysen beskriuwe produkten, ferzjes en soms ferplichte betingsten, en dy trije fjilden komme net altyd oerien mei in pakketferzje. OpenVPN syn Heartbleed-advys fan april 2014 is in nuttich histoarysk foarbyld, om’t it de troffen Access Server-útjeften skiede fan de websjinsten en de VPN-daemons, dy’t oare bleatstelling hiene. De les is te lêzen hokker komponint de tekst beslacht, ynstee fan it wurd OpenSSL patroanmjittich te ferlykjen.

Dat advys is ek ferâldere. Syn reparearre útjefte-nûmers binne no gjin ynstallaasjeadvys, en in flater dy’t yn 2014 reparearre is, seit neat oer lettere problemen yn de tûke dy’t jo hjoed rinne.

Unienigens oplosse en dan de bleatstelling slute

As ynventaris en beoardieling faninoar ferskille, kontrolearje dan oft beide itselde einpunt en deselde rinomjouwing beskriuwe: in oar adres, in front-end-proxy, in twadde tsjinst, in âld proses dat noch oan de poarte bûn is, of in ynsletten biblioteek dy’t de pakketbehearder nea seach. Los dat op by de grins foar’t jo in rapport werom skriuwe.

Pas de stipe korreksje ta, start de troffen tsjinst opnij en befêstigje dat de nije build no rint. In patcht triem op skiif wylst it âlde proses noch ferkear betsjinnet, is gjin remediearring.

Behannel dan wat it komponint yn it bleatstellingsfinster hâlde kinnen hie. Patchen en it ferfangen fan bewiisstikken beäntwurdzje ferskate fragen, en in sertifikaat dat tichtby de troffen host bewarre is, is op himsels gjin list fan wat lekte. Folgje de proseduere fan de ynsidint-eigner foar ynlûken, sesjes fuortsmite en klantfernijingen, en registrearje hokker komponint troffen wie, wêrom’t it bewiis jilde en wat it sletten hat. Dat register is wat in lettere resinsje lêze sil.