Introducción
Antes de utilizar un escáner, necesitas distinguir una dirección, un nombre, una ruta de red y un puerto de servicio. Son observaciones diferentes y el éxito en una capa no demuestra el éxito en otra.
Esta práctica proporciona un servidor DNS local y un servicio web dentro de tu entorno Kali. Inspeccionarás la red, resolverás el nombre de entrenamiento y comprobarás su socket TCP en escucha sin escanear una puerta de enlace ni depender de objetivos públicos.
Inspecciona direcciones, rutas y accesibilidad de loopback
En este paso inspeccionarás la red del contenedor Kali y probarás una ruta limitada de conexión local.
Entra en el shell preparado y elige el espacio de trabajo:
kali
cd /home/labex/project
Una dirección IP identifica un endpoint de red. Una interfaz es la conexión del sistema con una red; una ruta describe adónde debe ir el tráfico para una dirección. Los contenedores tienen su propia vista de red, así que inspecciona este entorno en lugar de suponer la configuración del host.
ip inspecciona las redes de Linux. La opción -brief solicita una vista compacta de las direcciones de las interfaces:
ip -brief address
Busca lo, la interfaz de loopback, y 127.0.0.1. El tráfico de loopback permanece en este entorno de red. Las demás interfaces y direcciones pueden variar. Un prefijo como /8 o /16 describe el rango de red de la dirección; no es un puerto de servicio.
Inspecciona las rutas:
ip route
Una entrada default, si existe, se utiliza cuando no coincide una ruta más específica. No necesitas escanear la puerta de enlace ni cambiar ninguna ruta.
ping envía sondas de accesibilidad. -c 3 limita la prueba a tres sondas para que termine automáticamente:
ping -c 3 127.0.0.1
Debes recibir respuestas y un resumen final de paquetes. Los tiempos exactos varían. Una respuesta de ping demuestra que estas sondas recibieron respuesta; no establece que un servicio TCP concreto esté escuchando.
Guarda la observación de interfaces mediante la redirección de salida que ya conoces:
ip -brief address > interfaces.txt
cat interfaces.txt
La vista guardada debe incluir la interfaz de loopback y su dirección.
Resuelve un nombre con el servidor DNS de entrenamiento
En este paso distinguirás la resolución de nombres de la conectividad con un servicio mediante un servidor DNS local.
DNS traduce nombres en registros. Un registro A contiene una dirección IPv4. Esta práctica proporciona un servidor DNS en 127.0.0.1, puerto 5353, y un nombre local training-web.test; no se necesita ningún servicio DNS público.
dig consulta DNS. @127.0.0.1 elige el servidor, -p 5353 elige su puerto DNS no predeterminado, el siguiente argumento es el nombre y A solicita un registro de dirección IPv4:
dig @127.0.0.1 -p 5353 training-web.test A
La sección de respuestas debe mostrar el nombre y la dirección 127.0.0.1. DNS también utiliza puertos: aquí el puerto 5353 pertenece al servidor DNS de entrenamiento, no al servicio web nombrado por su respuesta.
La opción de visualización +short muestra solo los datos de respuesta. Guarda ese resultado más pequeño:
dig @127.0.0.1 -p 5353 +short training-web.test A > dns-answer.txt
cat dns-answer.txt
Salida esperada:
127.0.0.1
La búsqueda de nombres del sistema también puede utilizar archivos locales en lugar de consultar DNS directamente. getent hosts solicita un nombre al mecanismo de búsqueda de hosts configurado en el sistema:
getent hosts localhost
La salida asocia localhost con una dirección de loopback, que puede ser la IPv6 ::1. Esto difiere de consultar explícitamente el servidor DNS proporcionado con dig. Resolver correctamente un nombre da una dirección; todavía debes examinar si el servicio requerido está disponible allí.
Inspecciona un socket en escucha y prueba su puerto TCP
En este paso relacionarás una dirección con un protocolo de transporte y un puerto de servicio concretos.
Un puerto identifica un endpoint de transporte en una dirección. TCP establece conexiones; UDP envía datagramas sin el mismo intercambio de establecimiento de conexión. El número de puerto de un servicio por sí solo no demuestra qué aplicación o vulnerabilidad está presente.
ss muestra información de sockets. -l selecciona sockets en escucha, -t selecciona TCP y -n conserva direcciones y números de puerto numéricos:
ss -ltn
Localiza el endpoint local 127.0.0.1:8080. Pertenece al servicio web de entrenamiento proporcionado. La dirección lo restringe al loopback del contenedor. Inspecciona por separado los sockets UDP con -u en lugar de -t:
ss -lun
El endpoint DNS de entrenamiento utiliza el puerto 5353. TCP y UDP tienen espacios de puertos separados; ambos protocolos pueden utilizar el mismo número.
Guarda solo la fila del socket TCP en escucha del servicio de práctica. El patrón incluye los dos puntos antes del puerto y un espacio final para distinguirlo de un número más largo:
ss -ltn | grep ':8080 ' > service-listener.txt
cat service-listener.txt
La fila debe identificar LISTEN y 127.0.0.1:8080; el espaciado y los valores de cola pueden variar.
Ncat puede probar una conexión TCP sin enviar datos de aplicación. -v muestra el estado y -z solicita una comprobación de conexión en lugar de una sesión de datos interactiva:
ncat -vz 127.0.0.1 8080
El estado debe indicar una conexión correcta. Esto demuestra que el puerto TCP seleccionado acepta una conexión ahora; todavía no valida una respuesta HTTP. Inspeccionarás HTTP en una práctica posterior.
Resumen
Inspeccionaste interfaces y rutas, enviaste una prueba finita de accesibilidad, consultaste DNS local, inspeccionaste sockets TCP y UDP en escucha y probaste una conexión TCP. Distinguiste la resolución correcta y la accesibilidad de red del comportamiento de la aplicación.
