Análisis de Tráfico de Red y Acceso Remoto Seguro

CompTIABeginner
Practicar Ahora

Introducción

Bienvenido a este laboratorio sobre Análisis de Tráfico de Red y Acceso Remoto Seguro en Linux. Comprender cómo monitorizar la actividad de red y asegurar las comunicaciones es una habilidad crítica para cualquier administrador de sistemas, desarrollador o entusiasta de la seguridad.

En este laboratorio, obtendrá experiencia práctica con un conjunto de potentes herramientas de línea de comandos. Aprenderá a:

  • Inspeccionar conexiones de red activas y servicios en escucha utilizando netstat y su sucesor moderno, ss.
  • Capturar y analizar paquetes de red en vivo con tcpdump.
  • Establecer una conexión remota segura a su propia máquina utilizando ssh.
  • Verificar la integridad de las respuestas DNS utilizando dig y DNSSEC.

Al final de este laboratorio, tendrá una comprensión práctica de estas utilidades de red esenciales y sus roles en la gestión y seguridad de un sistema Linux.

Este es un Guided Lab, que proporciona instrucciones paso a paso para ayudarte a aprender y practicar. Sigue las instrucciones cuidadosamente para completar cada paso y obtener experiencia práctica. Los datos históricos muestran que este es un laboratorio de nivel principiante con una tasa de finalización del 88%. Ha recibido una tasa de reseñas positivas del 100% por parte de los estudiantes.

Inspeccionar Conexiones de Red Activas con Netstat/SS

En este paso, aprenderá a ver las conexiones de red activas y los puertos en escucha en su sistema. Esto es fundamental para comprender qué servicios se están ejecutando y son accesibles a través de la red. Utilizaremos dos herramientas comunes: netstat y ss.

Primero, usemos netstat, una utilidad clásica y ampliamente conocida. El paquete net-tools, que contiene netstat, fue instalado para usted durante la configuración del laboratorio.

Ejecute el siguiente comando para listar todos los puertos TCP (-t) y UDP (-u) en escucha en formato numérico (-n) sin resolver nombres, centrándose solo en los sockets en escucha (-l):

netstat -tuln

Debería ver una salida similar a esta. Observe las entradas para el servidor SSH (puerto 22) y el servidor web de Python (puerto 8000) que se iniciaron para usted, junto con servicios adicionales en los puertos 3001 y 3002:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:3001            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:3002            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.11:37199        0.0.0.0:*               LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
udp        0      0 127.0.0.11:60120        0.0.0.0:*
udp        0      0 0.0.0.0:3001            0.0.0.0:*

Ahora, usemos ss, que es el reemplazo moderno de netstat. Generalmente es más rápido y proporciona información más detallada. El comando y las banderas son muy similares.

ss -tuln

La salida será ligeramente diferente en formato, pero mostrará la misma información esencial: los servicios en escucha en los puertos 22, 3001, 3002 y 8000, junto con algunos servicios internos de Docker:

Netid                        State                         Recv-Q                        Send-Q                                               Local Address:Port                                                 Peer Address:Port                        Process
udp                          UNCONN                        0                             0                                                       127.0.0.11:60120                                                     0.0.0.0:*
udp                          UNCONN                        0                             0                                                          0.0.0.0:3001                                                      0.0.0.0:*
tcp                          LISTEN                        0                             128                                                        0.0.0.0:22                                                        0.0.0.0:*
tcp                          LISTEN                        0                             5                                                          0.0.0.0:3001                                                      0.0.0.0:*
tcp                          LISTEN                        0                             128                                                        0.0.0.0:3002                                                      0.0.0.0:*
tcp                          LISTEN                        0                             5                                                          0.0.0.0:8000                                                      0.0.0.0:*
tcp                          LISTEN                        0                             4096                                                    127.0.0.11:37199                                                     0.0.0.0:*
tcp                          LISTEN                        0                             128                                                           [::]:22                                                           [::]:*

Al utilizar estos comandos, puede obtener rápidamente una instantánea de los servicios de su sistema que están expuestos a la red.

Capturar Tráfico de Red Local con Tcpdump

En este paso, utilizará tcpdump, un potente analizador de paquetes de línea de comandos, para capturar e inspeccionar el tráfico de red en tiempo real. Esto es invaluable para depurar problemas de red o comprender cómo funcionan los protocolos.

Primero, veamos qué interfaces de red están disponibles para capturar tráfico.

sudo tcpdump -D

La salida listará las interfaces disponibles. lo es la interfaz "loopback" (de retorno), que se utiliza para la comunicación de red dentro de la misma máquina (por ejemplo, conectarse a localhost). Verá varias interfaces, incluida la interfaz de red principal eth1:

1.eth1 [Up, Running, Connected]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
7.dbus-system (D-Bus system bus) [none]
8.dbus-session (D-Bus session bus) [none]

Capturaremos tráfico en la interfaz de loopback (lo) para ver las solicitudes a nuestro servidor web local. Para hacer esto, necesitará dos terminales.

En su terminal actual, ejecute el siguiente comando tcpdump. Escuchará en la interfaz lo (-i lo) y se detendrá después de capturar 5 paquetes (-c 5).

sudo tcpdump -i lo -c 5

Ahora, haga clic en el icono + en la barra de pestañas de la terminal para abrir una nueva terminal. En esta nueva terminal, genere algo de tráfico de red realizando una solicitud al servidor web local usando curl.

curl http://localhost:8000

Vuelva a su primera terminal. Verá que tcpdump ha capturado los paquetes relacionados con su solicitud curl. La salida se verá algo así, mostrando el handshake TCP y la transferencia de datos:

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:57:14.158058 IP localhost.57272 > localhost.8000: Flags [S], seq 2025143228, win 65495, options [mss 65495,sackOK,TS val 1006286113 ecr 0,nop,wscale 7], length 0
14:57:14.158072 IP localhost.8000 > localhost.57272: Flags [S.], seq 403368374, ack 2025143229, win 65483, options [mss 65495,sackOK,TS val 1006286113 ecr 1006286113,nop,wscale 7], length 0
14:57:14.158083 IP localhost.57272 > localhost.8000: Flags [.], ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
14:57:14.158129 IP localhost.57272 > localhost.8000: Flags [P.], seq 1:79, ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 78
14:57:14.158133 IP localhost.8000 > localhost.57272: Flags [.], ack 79, win 511, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
5 packets captured
24 packets received by filter
0 packets dropped by kernel

Tenga en cuenta que si ejecuta tcpdump sin generar tráfico específico, es posible que vea consultas DNS en segundo plano y otras comunicaciones del sistema, como se muestra en sus registros. Este es un comportamiento normal del sistema y demuestra que, incluso cuando no está navegando activamente, su sistema mantiene diversas comunicaciones de red.

Ha capturado y visto con éxito tráfico de red en vivo.

Demostrar Acceso Remoto Seguro Usando SSH

En este paso, aprenderá a usar SSH (Secure Shell) para acceso remoto seguro. Configuraremos la autenticación basada en claves, que es más segura que usar contraseñas, para iniciar sesión en su propia máquina (localhost). El openssh-server ya se inició para usted.

Primero, necesita generar un par de claves SSH (una clave privada y una clave pública). Crearemos una clave RSA con una longitud de bits de 2048. La bandera -f especifica el archivo donde guardar la clave, y -N "" establece una frase de contraseña vacía por conveniencia en este laboratorio.

ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""

Este comando crea id_rsa (su clave privada) y id_rsa.pub (su clave pública) dentro del directorio ~/.ssh.

A continuación, para permitir que su propio usuario inicie sesión usando esta clave, debe agregar la clave pública al archivo authorized_keys. Este archivo lista todas las claves públicas que tienen permiso para iniciar sesión.

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Por seguridad, SSH requiere permisos estrictos en el directorio .ssh y sus archivos. Asegurémonos de que estén configurados correctamente. El script de configuración ya creó estos archivos con los permisos correctos, pero es una buena práctica conocer estos comandos.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Ahora todo está configurado. Puede probar la conexión segura a localhost. El comando ejecutará echo "Hello from SSH" en el extremo remoto (que es su propia máquina) e imprimirá el resultado.

ssh labex@localhost 'echo "Hello from SSH"'

La primera vez que se conecte, es posible que se le pida que verifique la huella digital del host. Escriba yes y presione Enter. Luego debería ver la salida del comando echo.

The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Hello from SSH

Ha configurado y utilizado con éxito SSH para una autenticación segura basada en claves.

Verificar Resolución DNSSEC con Dig

En este paso, utilizará dig (Domain Information Groper) para realizar consultas DNS y aprender sobre DNSSEC (DNS Security Extensions). DNSSEC ayuda a proteger contra la suplantación de DNS al agregar firmas criptográficas a los datos DNS.

Primero, realicemos una consulta DNS estándar para labex.io para ver su dirección IP.

dig labex.io

La salida le mostrará los detalles de la consulta y, lo más importante, la ANSWER SECTION con los registros A (direcciones IP). Tenga en cuenta que labex.io tiene varias direcciones IP para balanceo de carga:

; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9789
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;labex.io.                      IN      A

;; ANSWER SECTION:
labex.io.               10      IN      A       104.26.10.219
labex.io.               10      IN      A       104.26.11.219
labex.io.               10      IN      A       172.67.72.162

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:16 CST 2025
;; MSG SIZE  rcvd: 85

Ahora, realicemos la misma consulta pero pidamos al resolvedor DNS que proporcione datos relacionados con DNSSEC agregando la opción +dnssec.

dig labex.io +dnssec

La salida incluye información adicional relacionada con DNSSEC en la OPT PSEUDOSECTION, mostrando que se solicitaron datos DNSSEC (la bandera do significa "DNSSEC OK"). Sin embargo, tenga en cuenta que la sección flags no contiene una bandera ad (Authenticated Data):

; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1042
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;labex.io.                      IN      A

;; ANSWER SECTION:
labex.io.               5       IN      A       172.67.72.162
labex.io.               5       IN      A       104.26.11.219
labex.io.               5       IN      A       104.26.10.219

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:21 CST 2025
;; MSG SIZE  rcvd: 108

La ausencia de la bandera ad indica que, si bien se solicitó información DNSSEC, el resolvedor no pudo validar las firmas o el dominio no tiene DNSSEC habilitado.

Intentemos con otro dominio conocido que utiliza DNSSEC, icann.org, para verlo de nuevo.

dig icann.org +dnssec

Nuevamente, inspeccione la cabecera en la salida:

; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> icann.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54437
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;icann.org.                     IN      A

;; ANSWER SECTION:
icann.org.              10      IN      A       192.0.43.7

;; Query time: 72 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:26 CST 2025
;; MSG SIZE  rcvd: 77

De manera similar a la consulta anterior, no hay una bandera ad en la respuesta. Esto indica que el resolvedor DNS en este entorno no está realizando la validación DNSSEC, lo cual es común en entornos contenerizados o virtualizados donde el resolvedor DNS puede estar configurado de manera diferente a un resolvedor de sistema estándar.

Resumen

¡Felicitaciones por completar el laboratorio! Ha adquirido experiencia práctica con varias herramientas esenciales de redes y seguridad de Linux.

En este laboratorio, ha aprendido a:

  • Utilizar netstat y ss para inspeccionar qué servicios de red se están ejecutando y escuchando conexiones.
  • Capturar paquetes de red en vivo en una interfaz específica usando tcpdump para analizar el tráfico.
  • Configurar y usar ssh con autenticación basada en claves para acceso remoto seguro.
  • Utilizar dig para consultar el Sistema de Nombres de Dominio y comprender los conceptos de DNSSEC, incluido cómo solicitar información DNSSEC e interpretar los resultados.

Estas son habilidades fundamentales que son cruciales para administrar, solucionar problemas y asegurar cualquier entorno Linux. Le animamos a seguir explorando las muchas opciones que ofrecen estas potentes herramientas.