Que proceso de VPN recibe ese achado de vulnerabilidade?

O resultado dun escáner nomea un enderezo, un porto e algo que se negociou alí. Non nomea o proceso detrás dese socket, e nunha máquina VPN varios procesos poden compartir o equipo mentres só un deles é o túnel. Ler unha cadea de versión dunha utilidade auxiliar ou atopar un ficheiro de biblioteca no disco engade probas sobre a máquina, non sobre o oínte. O achado só se volve accionable cando se liga a un compoñente en execución e despois se compara co alcance que un aviso indica realmente.

A orde importa: primeiro o compoñente, segundo o aviso, terceiro a remediación.

O informe nomea un porto, non un programa

Comeza polo extremo que realmente se avaliou. Unha sonda contra o porto de administración HTTPS mediu o servizo web, a súa pila TLS e calquera proxy que teña diante; non aprendeu nada do oínte OpenVPN ou WireGuard noutro porto. Os proxies inversos e os axentes de xestión empeórano, porque o certificado e o banner poden pertencer á parte frontal mentres a biblioteca vulnerable queda detrás nun proceso de fondo.

Rexistra o destino, o transporte, o porto e o nome do servizo xunto co resultado, para que o alcance viaxe co achado.

Que é realmente a compilación en execución

Nunha máquina de propósito xeral, o paquete instalado e a biblioteca cargada son cuestións distintas. Unha base de datos de paquetes pode listar unha versión parcheada mentres un daemon de longa duración aínda mantén o antigo obxecto compartido na memoria, e unha imaxe de dispositivo integrada pode levar as súas propias bibliotecas que ningún xestor de paquetes informa. Pregunta ao xestor de servizos que se executa e despois inspecciona o proceso e as súas ligazóns.

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

A hora de inicio na lista de procesos é o detalle que a xente omite. Un daemon iniciado antes da última actualización de paquetes segue executando a compilación que cargou no arranque, e ese é exactamente o caso no que un inventario di corrixido e o socket di o contrario.

Comparar a compilación co alcance dun aviso

Os avisos describen produtos, versións e ás veces condicións necesarias, e eses tres campos non sempre coinciden coa versión dun paquete. O aviso de Heartbleed de abril de 2014 de OpenVPN é un exemplo histórico útil porque separa as versións afectadas de Access Server dos servizos web e os daemons VPN, que tiñan unha exposición distinta. A lección é ler que compoñente cobre o texto en lugar de facer coincidir por patrón a palabra OpenSSL.

Ese aviso tamén está desactualizado. Os seus números de versión corrixidos xa non son consello de instalación, e un fallo corrixido en 2014 non di nada sobre problemas posteriores na rama que executas hoxe.

Resolver o desacordo e despois pechar a exposición

Cando o inventario e a avaliación non coinciden, comproba se ambos describen o mesmo extremo e o mesmo contorno de execución: outro enderezo, un proxy frontal, un segundo servizo, un proceso antigo aínda ligado ao porto ou unha biblioteca integrada que o xestor de paquetes nunca viu. Resólveo na fronteira antes de reescribir un informe.

Aplica a corrección admitida, reinicia o servizo afectado e confirma que a nova compilación é a que agora se executa. Un ficheiro parcheado no disco co proceso antigo aínda servindo tráfico non é remediación.

Despois ocúpate do que o compoñente puido conter durante a ventá de exposición. Parchear e substituír credenciais responden a preguntas distintas, e un certificado gardado preto da máquina afectada non é por si mesmo unha lista do que se filtrou. Segue o procedemento do responsable do incidente para a revogación, a retirada de sesións e as actualizacións de clientes, e rexistra que compoñente se viu afectado, por que aplicaban as probas e que o pechou. Ese rexistro é o que lerá unha revisión posterior.