Nessus a través de VPN: dónde colocar el escáner antes del primer escaneo

Un icono de VPN junto al navegador no dice nada sobre el proceso que envía los paquetes de escaneo. Si la consola y el escáner se ejecutan en hosts distintos, el túnel del navegador es una ruta y el origen del escaneo es otra. Empieza por el punto de ejecución y avanza hacia fuera: la ruta, la autorización y las credenciales. Esa distinción ocupa el primer lugar de la lista por una razón.

Esta es una lista de comprobación previa al lanzamiento, no un tutorial de escaneo. Cada paso produce un hecho que puedes registrar en el expediente del encargo antes de que ningún paquete salga del escáner.

Punto uno: localiza el proceso que envía las sondas

Dibuja los tres roles de forma explícita: el navegador en el portátil A, la consola de escaneo en el host B y el objetivo privado C. Si B también ejecuta el motor de escaneo, el navegador solo necesita una ruta hacia B. Si el trabajo lo hace un dispositivo de escaneo aparte, ese dispositivo necesita la ruta hacia C.

Browser on laptop A -> console on host B
Scanner process on B (or another appliance) -> private target C

Un navegador conectado a la VPN puede alcanzar la consola mientras el escáner que hay detrás sigue sin ruta hacia C. También es posible lo contrario: el escáner está dentro de la red privada y la consola es remota. Averigua qué disposición ejecutas realmente antes de cambiar cualquier control de red. Nombra el dispositivo en la configuración del escaneo antes de culpar a la red.

Si el escáner se ejecuta en A, el host del navegador y el escáner comparten un contexto, pero solo mientras ese proceso mantenga el mismo espacio de nombres y la misma tabla de rutas. Un contenedor o una cuenta de servicio pueden no heredar lo que ve el navegador interactivo. La consola es una superficie de administración, no el motor de escaneo.

Punto dos: demuestra la ruta y el DNS del escáner

Ejecuta la comprobación de ruta en el host del escáner, no en el portátil. Pregunta al núcleo qué interfaz y qué puerta de enlace usaría para la dirección del objetivo y repite la consulta para el nombre de host del objetivo. Una ruta que existe para la IP y un nombre que resuelve a otra dirección son dos fallos distintos.

Confirma la dirección de origen que aparecerá en el objetivo. Un cliente VPN puede asignar una dirección distinta de la que espera el cortafuegos del objetivo, y un dispositivo NAT puede reescribirla de nuevo. El propietario del objetivo necesita el origen observado, no la dirección impresa en el perfil de la VPN.

Comprueba también el camino de vuelta. Un escáner que alcanza el objetivo pero no recibe respuestas tiene un problema de enrutamiento o de cortafuegos en el retorno, y eso se ve idéntico a un objetivo caído.

Punto tres: consigue autorización del alcance y del punto de vista

Pide al propietario del objetivo que nombre por escrito los sistemas, servicios, entorno, origen y ventana de tiempo. Decide qué punto de vista representa la evaluación: un usuario de VPN externo, un cliente interno admitido o un segmento de escáner concreto.

Una ruta privada no es permiso para probar redes adyacentes. Mantén la lista de objetivos estrecha, enumera los sistemas excluidos y acuerda condiciones de parada y un contacto que pueda detener la ejecución. El escáner sondeará con gusto todo lo que pueda alcanzar, y por eso mismo el alcance debe ser explícito.

Registra el origen aprobado en el mismo documento. Si el origen observado del escáner difiere del aprobado, la ejecución no representa el punto de vista acordado aunque la lista de objetivos sea correcta.

Punto cuatro: ajusta las credenciales a la profundidad de la evaluación

Una comprobación de accesibilidad y una evaluación autenticada son pruebas distintas. Una respuesta de puerto demuestra que algo respondió; no demuestra que se ejecutaran comprobaciones con credenciales ni que la aplicación autorizara la cuenta.

Usa credenciales dedicadas solo cuando el alcance acordado exija comprobaciones autenticadas. Confirma los permisos y la política de bloqueo de la cuenta, y decide cómo se almacenarán y compartirán los hallazgos antes de que el escaneo los produzca.

Si las credenciales fallan, no recurras en silencio a una ejecución sin autenticación ni etiquetes el informe como la evaluación planificada. El resultado es una prueba distinta con un significado distinto, y esa diferencia debe constar en el informe.

Punto cinco: guarda el plan y lanza de forma deliberada

En el flujo de trabajo de escaneo de Nessus, elegir una plantilla, configurar los ajustes y guardar o lanzar el escaneo son pasos separados. Aprovecha esa separación para revisar la lista de objetivos, el origen y la programación antes de que empiece cualquier tráfico.

Antes de autorizar el lanzamiento, comprueba qué origen permite la VPN, qué tráfico transporta y cómo se recupera de un túnel caído. No amplíes el acceso del cortafuegos solo porque falló una conexión preliminar; encuentra la capa que la rechazó y corrige esa capa.

Tras la ejecución, registra el host del escáner, su origen observado, la lista de objetivos y cualquier comprobación que no pudiera completarse. Un informe producido desde otro origen o sin las credenciales previstas no representa el plan original, y decirlo forma parte del entregable.

Retira los accesos del encargo y trata los resultados conservados según el proceso acordado. La lista solo está terminada cuando las pruebas coinciden con la ruta que aprobaste, no cuando el escaneo simplemente devolvió resultados.