Cómo se comunican los sistemas, por qué confían entre sí y cómo esa confianza puede romperse

Cuando una persona empieza en ciberseguridad, normalmente aprende herramientas antes que fundamentos. Aprende a lanzar un escaneo con Nmap, a abrir Wireshark, a probar Metasploit o a mirar paquetes sin comprender del todo qué está viendo. Eso produce una ilusión peligrosa: parece que hacer hacking consiste en usar herramientas, cuando en realidad consiste en entender sistemas.

Un sistema aislado tiene poco valor operativo. Un sistema conectado, en cambio, participa en una red, intercambia información, abre servicios, responde solicitudes, consulta servidores, resuelve nombres, mantiene sesiones, negocia estados y confía en múltiples mecanismos para que esa comunicación ocurra correctamente.

Y ahí aparece una verdad fundamental de la ciberseguridad:

"Todo sistema que se comunica expone una superficie de ataque"

La red no es solo un medio de transporte. No es solo el "camino" por el que viajan los datos. La red es un conjunto de reglas, estados, identidades, traducciones y supuestos de confianza. Cada paquete, cada cabecera, cada protocolo y cada resolución representa una decisión del sistema sobre qué aceptar, qué ignorar, qué enrutar y en quién confiar.

Por eso, si quieres dejar de ver la red como una caja negra y empezar a verla como un campo de batalla técnico, este módulo es uno de los más importantes de toda tu formación.

1. La red no es internet: la red es comunicación estructurada

Mucha gente usa "internet" y "red" como si fueran prácticamente lo mismo. Pero desde un punto de vista técnico y ofensivo, esa simplificación es demasiado pobre.

Una red es un sistema de comunicación entre entidades computacionales. Es decir, un entorno donde dispositivos, procesos y servicios intercambian información bajo ciertas reglas comunes. Esas reglas existen porque comunicar no es trivial. Para que dos sistemas se entiendan, deben acordar cosas como:

• cómo se representa la información
• cómo se direcciona
• cómo se divide en unidades transportables
• cómo se detectan errores
• cómo se confirma la recepción
• cómo se resuelven nombres
• cómo se identifica el destino correcto
• cómo se mantiene una sesión activa

Todo esto se resuelve mediante protocolos.

Un protocolo no es otra cosa que un conjunto de reglas que define cómo debe ocurrir una interacción. En redes, eso significa que los sistemas no "hablan" libremente: hablan dentro de una estructura.

Y ese es el primer gran cambio de mentalidad que debe ocurrir en este módulo:

la red no es caos; la red es un sistema formal de intercambio.

Ahora bien, una vez que entiendes eso, aparece una consecuencia inmediata:

si la comunicación sigue reglas, entonces esas reglas pueden estudiarse, observarse, manipularse y explotarse.

Ese es el punto exacto donde nace la seguridad ofensiva en redes.

2. El modelo en capas: una solución de ingeniería… y una fuente de vulnerabilidades

La razón por la que internet y las redes modernas pueden funcionar a gran escala es que la complejidad fue dividida en capas.

En vez de exigir que cada componente entienda todo al mismo tiempo, la ingeniería de redes separó el problema en niveles. Cada capa resuelve una parte específica del problema de la comunicación y delega el resto a otras capas.

De forma pedagógica, esto suele explicarse con el modelo OSI. De forma práctica, suele aterrizarse en el modelo TCP/IP. No importa tanto memorizar los nombres como comprender la idea central:

• hay capas que se encargan del medio físico y la entrega local
• hay capas que se encargan del direccionamiento lógico
• hay capas que se encargan de la comunicación entre procesos
• hay capas que se encargan del significado de la información intercambiada

Cuando un usuario abre una página web, en realidad no está ocurriendo un solo evento. Está ocurriendo una cadena de transformaciones:

1. la aplicación genera datos
2. esos datos se encapsulan en una unidad de transporte
3. esa unidad se encapsula en una unidad de red
4. esa unidad se encapsula en una trama de enlace
5. finalmente se transmite por un medio físico o virtual

Luego, del otro lado, todo se reconstruye en sentido inverso.

Esta idea se conoce como encapsulación.

Y aquí hay algo importante que muchas veces no se enseña con suficiente profundidad:

cada capa añade funcionalidad, pero también añade una frontera de confianza.

Por ejemplo:

• una aplicación confía en que el destino resuelto por DNS es correcto
• TCP confía en que las direcciones IP involucradas representan al interlocutor esperado
• IP confía en que el siguiente salto y la entrega local se realizarán correctamente
• el host confía en que la resolución ARP no fue manipulada

Eso significa que la seguridad extremo a extremo depende de una cadena acumulativa de supuestos.

Y si una de esas capas es alterada, la superior hereda el problema.

Por eso, en ciberseguridad, las capas no deben verse solo como organización técnica. Deben verse como lo que realmente son desde la perspectiva ofensiva:

múltiples niveles donde un atacante puede intervenir.

3. Encapsulación: cómo viajan realmente los datos

Vamos a aterrizarlo con una idea sencilla. Supón que escribes en tu navegador una URL y presionas Enter. Desde el punto de vista del usuario, "abriste una página". Pero desde el punto de vista de redes, lo que ocurre es mucho más interesante.

La aplicación construye una solicitud. Esa solicitud se convierte en datos que deben viajar. Luego:

• la capa de transporte los segmenta
• la capa de red les pone direcciones IP
• la capa de enlace los mete en una trama con direcciones MAC
• la interfaz los transmite

Cuando llegan al destino:

• la capa de enlace verifica y entrega la carga
• la capa de red procesa el paquete IP
• la capa de transporte reconstruye la sesión
• la aplicación interpreta el mensaje

Este proceso es elegantísimo desde la ingeniería. Pero también es una fuente natural de oportunidades para un atacante. Porque cada capa ve solo una parte del problema.

• La capa de enlace no entiende HTTP.
• La capa de transporte no entiende el significado del contenido de aplicación.
• La aplicación no necesariamente sabe si la ruta de red fue manipulada.
• El usuario no tiene visibilidad de lo que pasó debajo.

Entonces aparece una consecuencia técnica muy poderosa:

Puedes atacar una capa para afectar otra.

Ese principio explica muchísimas cosas en ciberseguridad. Por ejemplo:

• manipulas ARP para redirigir tráfico
• al redirigir tráfico puedes observar paquetes TCP
• al observar paquetes TCP puedes estudiar la sesión
• al estudiar la sesión puedes analizar protocolos de aplicación

Es decir, la explotación de red rara vez ocurre de forma aislada. Lo que ocurre es una cascada de control sobre la comunicación.

4. La red local: donde empieza la confianza ingenua

Antes de hablar de internet, servicios remotos o web, hay que hablar de algo mucho más básico y, al mismo tiempo, muy importante:

La red local.

Cuando dos equipos están en la misma red local, no necesitan todavía resolver todo el problema global del enrutamiento. Primero necesitan saber cómo entregarse tramas localmente. Aquí aparecen dos conceptos fundamentales:

• IP: identidad lógica para direccionamiento
• MAC: identidad de interfaz en la red local

Un host puede saber que quiere enviar tráfico a cierta IP, pero para hacerlo dentro de la red local necesita una dirección MAC asociada.

¿Y cómo obtiene esa asociación?

Mediante ARP.

5. ARP: el pequeño protocolo que revela una gran debilidad

ARP, Address Resolution Protocol, resuelve una pregunta muy concreta:

"¿Qué dirección MAC corresponde a esta dirección IP?"

En una red local, cuando un host quiere enviar tráfico al gateway o a otro host del mismo segmento, emite una solicitud ARP. Básicamente pregunta quién tiene determinada IP. El equipo correspondiente responde indicando su MAC. El emisor guarda esa relación en su caché ARP y luego ya puede enviar tráfico.

Hasta aquí, parece totalmente razonable.

El problema es que ARP fue diseñado en un contexto donde la red local se asumía más confiable de lo que realmente es en muchos escenarios modernos.

• ARP no autentica las respuestas.
• ARP no verifica criptográficamente que quien responde sea quien dice ser.
• ARP confía.

Y esa palabra es clave:

ARP funciona porque la red local opera sobre confianza implícita.

Eso significa que si un atacante dentro de la misma red local responde falsamente diciendo:

"la IP del gateway soy yo"

muchos sistemas aceptarán esa afirmación y actualizarán su caché.

Eso es ARP spoofing.

Y conceptualmente es brutal, porque no ataca una aplicación, no ataca un servicio expuesto ni necesita explotar un binario complejo. Lo que hace es reescribir el mapa de confianza de la red local.

• La víctima sigue creyendo que se comunica con el gateway.
• El sistema sigue funcionando aparentemente normal.
• Pero ahora el tráfico pasa primero por el atacante.

Eso es un ataque Man-in-the-Middle en esencia.

6. MITM: cuando un tercero entra en la conversación

Un ataque Man-in-the-Middle ocurre cuando un actor se interpone entre dos extremos que creen estar comunicándose directamente.

Hay distintas maneras de lograrlo, pero en redes locales ARP spoofing es uno de los ejemplos más didácticos y reveladores.

Imagina tres nodos:

• una víctima
• un gateway
• un atacante

En condiciones normales:

• la víctima envía tráfico al gateway
• el gateway responde a la víctima

Pero si el atacante envenena la caché ARP de ambos lados, entonces:

• la víctima cree que la MAC del gateway es la del atacante
• el gateway cree que la MAC de la víctima es la del atacante

Resultado:

• la víctima envía tráfico al atacante
• el atacante lo reenvía al gateway
• el gateway responde al atacante
• el atacante reenvía a la víctima

Desde la perspectiva de la víctima, todo sigue funcionando. Desde la perspectiva del atacante, ahora tiene visibilidad privilegiada sobre el flujo.

Y aquí aparece una idea central de este módulo:

la seguridad de la comunicación puede romperse sin tocar directamente la aplicación.

Esta es una lección que separa al principiante del analista serio.

El principiante piensa en vulnerabilidades como "fallos en páginas web" o "errores en programas". El analista serio entiende que muchas veces el problema está en cómo el sistema descubre, enruta y confía en la comunicación.

7. Laboratorio — Observando la red con Wireshark (desde Kali Linux)

Hasta ahora hemos hablado de modelos, capas y protocolos. Pero hay un punto donde todo esto deja de ser teoría y se vuelve real:

cuando puedes ver la red funcionando.

• Este laboratorio no es ofensivo.
• No vas a explotar nada, no vas a interceptar nada, no vas a atacar nada.

Vas a hacer algo más importante:

vas a observar la red como realmente es.

Porque antes de romper un sistema, primero debes entender cómo se comporta.

Objetivo

Capturar y analizar tráfico generado desde tu propia máquina (Kali Linux) para comprender cómo se manifiestan en la práctica protocolos como:

• ARP
• DNS
• TCP
• HTTP

Qué vas a demostrar

Este laboratorio demuestra una idea clave:

La red no es abstracta.

Todo lo que ocurre:

• puede capturarse
• puede analizarse
• puede interpretarse

Y lo más importante:

cada paquete refleja una decisión del sistema.

Entorno utilizado

En este caso, el laboratorio se realiza con:

• Kali Linux
• Wireshark
• conexión a red (wifi o cable)

No necesitas otra máquina.

Y eso es importante, porque demuestra que:

incluso un solo host genera suficiente tráfico para analizar todo el modelo de red.

I. Identificando la interfaz de red

Antes de capturar tráfico, necesitas saber por dónde viaja.

ip a

Aquí debes identificar tu interfaz activa. Generalmente será algo como:

• eth0 (cable)
• wlan0 (wifi)

Esa interfaz es la que usarás en Wireshark.

II. Iniciando Wireshark

Ahora abre Wireshark con privilegios:

sudo wireshark

Cuando se abra:

• verás varias interfaces
• cada una mostrará actividad en tiempo real

Selecciona la interfaz donde veas tráfico (línea verde activa).

III. Observación inicial (baseline)

Antes de generar tráfico, deja Wireshark capturando durante unos segundos sin hacer nada.

Esto es importante.

¿Por qué?

Porque demuestra que:

tu sistema ya está comunicándose constantemente.

Qué verás

Incluso sin interacción, aparecerán paquetes como:

• ARP
• DNS
• tráfico del sistema
• broadcast

"Incluso sin hacer ninguna acción, el sistema ya está interactuando con la red. La comunicación es constante y automática."

Esto introduce muy bien el concepto de red como sistema vivo.

IV. Observando ARP — Resolución de identidad local

Ahora vamos a forzar tráfico ARP.

Paso 1: limpiar la caché ARP

ip neigh flush all

Paso 2: identificar tu gateway

ip route | grep default

Ejemplo:

default via 192.168.0.1 dev wlan0

Paso 3: hacer ping al gateway

ping -c 3 192.168.0.1

En Wireshark aplica el filtro:

arp

Qué debes observar

Verás dos paquetes clave:

1. ARP Request

Tu máquina pregunta:

"¿Quién tiene la IP 192.168.0.1?"

2. ARP Reply

El router responde con su MAC.

V. Observando DNS — Resolviendo nombres

Ahora vamos a generar tráfico DNS.

Acción

En terminal:

curl http://example.com

En Wireshark filtra:

dns

Qué debes observar

DNS Query

Tu máquina pregunta:

"¿Cuál es la IP de example.com?"

DNS Response

El servidor responde con una IP.

Los sistemas no trabajan con nombres, trabajan con direcciones IP.

DNS es el puente entre:

• lo humano (dominios)
• lo técnico (IP)

VI. Observando TCP — El handshake

Ahora vamos a ver cómo se establece una conexión.

Filtro en Wireshark:

tcp.flags.syn == 1

Qué debes encontrar

Tres paquetes:

1. SYN
2. SYN-ACK
3. ACK

Qué significa cada uno

• SYN: Tu máquina inicia la conexión.
• SYN-ACK: El servidor acepta y responde.
• ACK: Confirmas y la conexión queda establecida.

"Una conexión TCP no es instantánea. Es una negociación."

VII. Observando HTTP — La comunicación real

Ahora viene lo más interesante.

Filtro:

http

(Si no aparece, usa tcp.stream)

Qué debes observar

Una solicitud real como:

GET / HTTP/1.1
Host: example.com

Y la respuesta del servidor.

HTTP no es magia. Es texto estructurado viajando sobre TCP.

VIII. Observando el cierre de la conexión

Filtro:

tcp.flags.fin == 1

Qué verás

• FIN
• ACK

Qué significa

La conexión no solo se abre. También se cierra de forma controlada.

"Antes de este laboratorio, la red era invisible. Después de este laboratorio, cada paquete tiene significado."

"No estoy viendo tráfico… estoy viendo cómo el sistema toma decisiones."

Conclusión del laboratorio

Este laboratorio demuestra que:

• la red es observable
• los protocolos son visibles
• la comunicación es estructurada
• todo puede analizarse

8. TCP: la comunicación no es libre, es una máquina de estados

Muchos usuarios piensan que TCP "simplemente conecta". Pero técnicamente TCP hace algo mucho más sofisticado: crea una relación lógica mantenida por estados, secuencias y confirmaciones.

Eso significa que TCP no es solo transporte. Es un sistema regulado.

Para entenderlo, piensa en una conexión TCP como una conversación donde ambos lados necesitan coordinar:

• quién empieza
• en qué orden llegan los datos
• qué se recibió
• qué falta por recibir
• cuándo termina la sesión

Por eso existe el famoso three-way handshake:

1. SYN
2. SYN-ACK
3. ACK

Pero el valor real del handshake no está en memorizar sus tres pasos. Está en entender qué representa:

• creación de estado
• sincronización de secuencias
• inicio formal de una sesión entre extremos

Y una vez que entiendes eso, entiendes también por qué TCP puede ser atacado.

Si un protocolo mantiene estado, entonces ese estado puede:

• agotarse
• desincronizarse
• cerrarse abruptamente
• manipularse si el atacante logra inyectar tráfico válido o aparentemente válido

Ahí nacen conceptos como:

• SYN flood
• RST injection
• session hijacking
• desincronización de sesiones

No necesitas entrar todavía en explotación avanzada para sacar una conclusión poderosa:

TCP convierte la comunicación en una estructura de estados, y toda estructura de estados es una superficie manipulable.

9. UDP: cuando la velocidad reemplaza al control

Aunque este módulo estará más centrado en TCP porque ofrece más riqueza para análisis y laboratorios, también vale la pena explicar UDP para contrastar modelos de comunicación.

UDP no establece conexión, no mantiene estado complejo como TCP y no garantiza entrega, orden ni confirmación. Eso lo hace más simple y más rápido, pero también cambia el tipo de análisis ofensivo y defensivo.

UDP es útil para protocolos donde la latencia importa más que la confiabilidad estricta, como:

• DNS
• streaming
• VoIP
• ciertos mecanismos de descubrimiento

No todos los protocolos priorizan las mismas propiedades ycuando cambian las prioridades, cambian también las superficies de ataque.

• Con TCP atacas mucho el estado.
• Con UDP observas más la exposición, el abuso de consultas, la ausencia de negociación o la facilidad de falsificación.

10. DNS: cuando controlar el nombre equivale a controlar el destino

Ahora pasamos a una capa que a los usuarios les parece casi invisible, pero que es absolutamente central:

Los humanos pensamos en nombres. Las máquinas enrutan por direcciones. DNS existe para traducir entre ambos mundos.

Cuando escribes un dominio, tu sistema necesita resolverlo a una IP. Esa resolución parece simple, pero en realidad implica una infraestructura distribuida, cachés, delegaciones, tiempos de vida y confianza en las respuestas.

Y aquí aparece otra idea crítica para la seguridad:

si controlas la resolución, puedes influir en el destino de la comunicación.

Eso vuelve a DNS una capa extremadamente sensible.

11. HTTP: donde la red se vuelve semántica

HTTP es una capa particularmente fascinante porque aquí la comunicación empieza a tener significado directo para la aplicación y para el usuario.

Una solicitud HTTP no es solo un paquete. Es una intención:

• pedir un recurso
• enviar datos
• autenticar un usuario
• mantener una sesión
• interactuar con una aplicación

Por eso HTTP es tan central para la seguridad web. Pero incluso si tu próximo módulo será web security, aquí ya debes dejar sembrada una idea fuerte:

HTTP no vive solo; vive montado sobre toda la infraestructura de red que lo sostiene.

Eso significa que la seguridad de una aplicación web no depende únicamente del código del backend o del frontend. También depende de:

• cómo se resolvió el destino
• cómo se estableció la conexión
• si hubo intermediarios
• si el tráfico fue visible
• si la sesión fue alterada o interceptada

12. Herramientas: no son magia, son extensiones del modelo mental

Uno de los errores más comunes en formación ofensiva es enseñar herramientas como recetas desconectadas de teoría.

Eso produce usuarios que "saben usar" Nmap, Wireshark o hping3, pero no comprenden bien qué están observando o provocando.

En este módulo, la postura correcta es otra:

• Wireshark: no es solo un capturador; es una ventana a la semántica del tráfico
• tcpdump: no es solo consola; es observación cruda de la red
• hping3: no es solo generar paquetes; es interactuar con la lógica de transporte
• arpspoof: no es solo ejecutar MITM; es manipular la resolución de identidad local

Laboratorio práctico — MITM por ARP Spoofing en red controlada

Introducción

En este laboratorio se demuestra cómo una red local puede ser alterada lógicamente mediante la manipulación del protocolo ARP, permitiendo que un tercero se interponga entre dos nodos que creen comunicarse directamente.

A diferencia de ataques tradicionales que explotan vulnerabilidades en aplicaciones o sistemas, este experimento se centra en la alteración de la confianza protocolaria que sostiene la comunicación en la red.

Es importante enfatizar que este laboratorio debe realizarse exclusivamente en un entorno controlado, aislado y autorizado.

Objetivo

Demostrar que es posible introducir un intermediario en la comunicación entre una víctima y su gateway mediante ARP spoofing, modificando la tabla ARP de ambos nodos y redirigiendo el tráfico a través del atacante.

Entorno del laboratorio

El laboratorio requiere tres máquinas dentro de la misma red:

• Máquina atacante: Kali Linux
• Máquina víctima: sistema Linux o Windows
• Gateway: router o máquina virtual configurada como punto de salida

Todas las máquinas deben estar conectadas a una red privada o interna donde exista conectividad directa entre ellas.

Fase 1 — Establecimiento del estado base

Paso 1 — Verificación de conectividad

Desde la máquina víctima, verificar conectividad con el gateway:

ping -c 4 <IP_GATEWAY>

Desde la máquina atacante, verificar conectividad con la víctima:

ping -c 4 <IP_VICTIMA>

Este paso garantiza que la red funciona correctamente antes de cualquier intervención.

Paso 2 — Inspección de la tabla ARP de la víctima

En la máquina víctima, consultar la tabla ARP:

ip neigh

o en sistemas Windows:

arp -a

Se debe identificar la entrada correspondiente al gateway, donde la dirección IP está asociada a su dirección MAC real.

Paso 3 — Captura de tráfico en estado normal

En la máquina atacante, iniciar captura de tráfico:

sudo tcpdump -i wlan0

o utilizando Wireshark.

Este paso permite observar el flujo de tráfico sin intervención, que servirá como referencia para comparación posterior.

Interpretación de la fase base

En este punto, la comunicación sigue su ruta directa:

• la víctima envía tráfico al gateway
• el gateway responde directamente a la víctima

No existe intermediación ni alteración del flujo.

Fase 2 — Envenenamiento ARP

Paso 4 — Habilitar reenvío de paquetes en el atacante

En la máquina atacante (Kali), habilitar el reenvío de paquetes:

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

Este paso es esencial para que el atacante pueda reenviar el tráfico entre la víctima y el gateway.

Paso 5 — Enviar respuestas ARP falsas a la víctima

En una terminal del atacante:

sudo arpspoof -i wlan0 -t <IP_VICTIMA> <IP_GATEWAY>

Esto induce a la víctima a asociar la IP del gateway con la MAC del atacante.

Paso 6 — Enviar respuestas ARP falsas al gateway

En otra terminal del atacante:

sudo arpspoof -i wlan0 -t <IP_GATEWAY> <IP_VICTIMA>

Esto induce al gateway a asociar la IP de la víctima con la MAC del atacante.

Interpretación del envenenamiento

En este punto, ambos extremos han sido engañados:

• la víctima cree que el atacante es el gateway
• el gateway cree que el atacante es la víctima

Como resultado, todo el tráfico entre ambos pasa a través del atacante.

Fase 3 — Verificación del ataque

Paso 7 — Verificar tabla ARP en la víctima

En la máquina víctima:

ip neigh

Se debe observar que la IP del gateway ahora apunta a la dirección MAC del atacante.

Paso 8 — Verificar continuidad de conectividad

Desde la víctima:

ping -c 4 8.8.8.8

El tráfico debe continuar funcionando normalmente.

Interpretación

Aunque la víctima mantiene conectividad, la ruta de comunicación ha sido modificada sin su conocimiento.

Fase 4 — Captura del tráfico interceptado

Paso 9 — Capturar tráfico en el atacante

En la máquina atacante:

sudo tcpdump -i wlan0

o mediante Wireshark.

Paso 10 — Generar tráfico desde la víctima

Desde la máquina víctima:

curl http://example.com

o mediante un navegador web.

Paso 11 — Analizar tráfico capturado

En el atacante, se debe observar tráfico que antes no era visible, incluyendo:

• paquetes TCP
• consultas DNS
• solicitudes HTTP (si no están cifradas)

Interpretación

El atacante ahora tiene visibilidad directa del tráfico de la víctima, lo que confirma que la posición de intermediario ha sido establecida correctamente.