Panorama: la red como una pila de confianzas no ganadas#

Casi todo lo que este manual describió sucede sobre una red. El reconocimiento la barre, la explotación la atraviesa, el movimiento lateral la recorre, la exfiltración la usa como salida y la detección la escucha. Entender la red no es un requisito técnico opcional: es entender el terreno común sobre el que se libra casi toda la disciplina. Y la mejor forma de entenderla es como lo que realmente es —una pila de capas donde cada nivel confía en el de abajo sin poder verificarlo—, porque esa estructura explica de un solo golpe por qué la red funciona y por qué es atacable.

El modelo se enseña con dos vocabularios. El de referencia, OSI, tiene siete capas y sirve para pensar; el que gobierna Internet, TCP/IP, tiene cuatro y sirve para operar. Sus capas —acceso al medio, Internet, transporte y aplicación— se apilan de modo que cada una resuelve un problema y le entrega el resultado a la de arriba como si fuera un servicio confiable. La capa de aplicación asume que el transporte le entrega los bytes en orden y completos; el transporte asume que la capa de Internet sabe llevar el paquete al host correcto; esta asume que la capa de acceso pone el bit en el cable. Ninguna capa verifica las garantías de la de abajo: las da por supuestas. Esa suposición encadenada es lo que permite que un navegador funcione sin saber nada de cables, y también lo que permite que un atacante que quiebra una capa inferior engañe a todas las superiores sin tocarlas.

flowchart TB
  A["aplicación\nHTTP · DNS · SMB — el dato que importa"]
  T["transporte\nTCP/UDP — puertos, orden, entrega"]
  I["Internet\nIP — direcciones, enrutamiento salto a salto"]
  L["acceso al medio\nEthernet/Wi-Fi · MAC/ARP — el bit en el cable"]
  A -->|"confía en que le entregan\nlos bytes completos y en orden"| T
  T -->|"confía en que el paquete\nllega al host correcto"| I
  I -->|"confía en que la trama\nllega al equipo del segmento"| L
  L -.->|"ninguna capa verifica\nla garantía de la de abajo"| A

Este capítulo recorre esa pila desde el punto de vista de la seguridad: qué garantiza cada capa, qué no garantiza, y dónde vive por lo tanto la frontera que hay que defender. No repite los ataques concretos —el envenenamiento de resolución de nombres, el relay de autenticación, el movimiento lateral— que las Partes ofensivas ya trataron; nombra el modelo que todos ellos presuponen, para que se vea que son variaciones de una misma idea: explotar una confianza que una capa depositó en otra sin haberla verificado.

Encapsulación: la cebolla de cabeceras#

El mecanismo que hace funcionar la pila es la encapsulación (encapsulation). Cuando una aplicación envía datos, cada capa envuelve lo que recibe de la de arriba en su propia cabecera —agregando la información que su par en el otro extremo necesitará— y se lo pasa a la de abajo. El dato de la aplicación se convierte en un segmento cuando el transporte le antepone sus puertos, en un paquete cuando la capa de Internet le antepone las direcciones IP, y en una trama cuando la capa de acceso le antepone las direcciones físicas. Del otro lado, cada capa quita su cabecera y entrega el contenido hacia arriba. Es una cebolla que se arma al bajar y se pela al subir.

Para la seguridad, la encapsulación tiene dos consecuencias grandes. La primera es que cada cabecera es un dato que el emisor controla y el receptor procesa —y todo dato controlado por un lado y procesado por el otro es una superficie—. La dirección de origen de un paquete, por ejemplo, la escribe quien lo envía; nada en el protocolo IP obliga a que sea real, y de ahí nace la falsificación de origen (spoofing). La segunda es que la encapsulación permite el túnel: como cada capa trata el contenido de la de arriba como una carga opaca, se puede meter un protocolo dentro de otro —tráfico de control disfrazado de tráfico web, un canal de mando escondido en consultas de nombres—. El túnel es neutral: lo usa la VPN legítima para proteger y lo usa el atacante para que su tráfico de salida parezca inofensivo. La lección de arquitectura es que la capa que transporta no entiende lo que transporta, y esa opacidad, otra vez, sirve para lo bueno y para lo malo.

Direccionamiento y enrutamiento: llevar el paquete al host correcto#

La capa de Internet resuelve el problema de la ubicación: dado un destino en cualquier parte del mundo, cómo llevar el paquete hasta él. Lo hace con dos ideas. La dirección IP identifica de forma lógica a cada interfaz —IPv4 con sus 32 bits ya agotados, IPv6 con sus 128 bits como sucesor—, y la máscara de subred parte esa dirección en una porción de red y una de host, que es lo que permite decidir si un destino es «local» (mismo segmento, se le habla directo) o «remoto» (hay que entregárselo a un router). El enrutamiento es el proceso por el cual los routers, consultando sus tablas, van pasando el paquete de salto en salto hasta la red de destino.

Dos puntos importan para la seguridad. Primero, dentro de un mismo segmento local la entrega física no usa la IP sino la dirección de hardware (MAC), y la traducción entre ambas la hace un protocolo —ARP en IPv4— que no autentica sus respuestas: cualquiera en el segmento puede afirmar «yo tengo esa IP» y desviar el tráfico hacia sí. Ese es el sustrato de toda una familia de ataques de intermediario en la red local. Segundo, la frontera entre «local» y «remoto» que define la máscara de subred es, en el fondo, una frontera de confianza: históricamente se trató lo que estaba en el mismo segmento como más confiable que lo que venía de afuera, y esa suposición —cómoda pero infundada— es la que la segmentación, más adelante, viene a corregir.

DNS: la guía telefónica que hay que creer#

Nadie recuerda direcciones IP; se recuerdan nombres. El sistema de nombres de dominio (Domain Name System, DNS) es la infraestructura distribuida que traduce un nombre legible —ejemplo.org— a la dirección numérica que la red necesita. Es, sin exageración, uno de los servicios más críticos de Internet: si el DNS miente, no importa cuán segura sea la conexión posterior, porque se estableció con el host equivocado.

Y el DNS, en su forma original, es un sistema construido sobre confianza sin verificación. Las respuestas viajan sin cifrar y, salvo que se despliegue una extensión que las firme (DNSSEC, de adopción todavía parcial), sin garantía de autenticidad. Un cliente que pregunta «¿cuál es la dirección de este nombre?» cree la primera respuesta plausible que llega. De esa credulidad nacen dos clases de problema. Una es la suplantación de la resolución: si un atacante logra que su respuesta llegue antes que la legítima —o envenenar la caché de un resolutor—, dirige a la víctima a donde quiera. La otra, ya del lado del atacante interno, es el uso del DNS como canal encubierto: como las consultas de nombres salen de casi cualquier red sin ser inspeccionadas, se las puede usar para exfiltrar datos o mandar órdenes codificándolos en los nombres consultados. En redes de identidad corporativa, además, los protocolos de resolución de respaldo que se activan cuando el DNS falla —los que la Parte 4 mostró siendo envenenados para capturar autenticación— son la misma falla de fondo: un servicio de nombres que cree lo primero que le contestan.

Fronteras dentro de la red: NAT, cortafuegos y segmentación#

Si toda la red fuera un único espacio plano donde cualquier host habla con cualquier otro, comprometer un solo equipo equivaldría a comprometer la red entera. La arquitectura de red segura consiste, en buena medida, en dibujar fronteras dentro de ese espacio, y hay tres mecanismos que las dibujan.

La traducción de direcciones (Network Address Translation, NAT) nació para conservar direcciones —muchos hosts internos compartiendo unas pocas públicas— y, como efecto lateral, oculta la estructura interna y evita que se inicien conexiones desde afuera hacia adentro sin una regla explícita. No es un control de seguridad diseñado como tal, pero contribuye. El cortafuegos (firewall) sí lo es: filtra el tráfico según reglas —qué puertos, qué direcciones, qué estado de conexión— y es el guardián clásico del perímetro. Su límite es que un cortafuegos perimetral solo ve lo que cruza el borde; una vez dentro, no dice nada.

Y ahí entra el mecanismo decisivo: la segmentación. Consiste en partir la red interna en zonas —por función, por sensibilidad, por nivel de confianza— y controlar el tráfico entre ellas, no solo en el borde. Su opuesto, la red plana donde todo host alcanza a todos los demás, es uno de los pecados originales de la seguridad de red, porque convierte cualquier punto de apoyo en acceso total. No es casual que el movimiento lateral que la Parte 4 recorrió —saltar de una máquina a la siguiente reutilizando credenciales— dependa por completo de que las máquinas puedan hablarse; en una red bien segmentada, la mitad de esos saltos simplemente no tiene ruta. Y no es casual que el caso de la brecha asistida por IA que la Parte 9 analizó señale, entre las causas raíz, precisamente una red plana: la inteligencia artificial aceleró el recorrido, pero fue la ausencia de fronteras internas lo que le dio a dónde recorrer. La segmentación es la aplicación directa de la defensa en profundidad a la topología: que romper una barrera no entregue el resto.

Norte-sur y este-oeste#

De la segmentación surge una distinción que ordena todo el pensamiento defensivo sobre tráfico. El tráfico norte-sur (north-south) es el que cruza el perímetro: entra desde Internet o sale hacia él. El tráfico este-oeste (east-west) es el que se mueve lateralmente dentro del entorno, de servidor a servidor, de segmento a segmento.

Durante años la defensa se concentró en el norte-sur —el firewall del borde, el proxy de salida— y dejó el este-oeste casi sin vigilar, bajo la suposición de que «lo de adentro es confiable». El adversario aprendió a explotar exactamente ese punto ciego: entrar por una grieta norte-sur cualquiera y después moverse a sus anchas por el este-oeste desatendido. La respuesta moderna —la microsegmentación, y en su forma más ambiciosa el zero trust que la arquitectura de seguridad desarrollará— consiste en dejar de tratar el interior como confiable y aplicar control y observación también al tráfico este-oeste. Dicho en los términos del capítulo anterior, es mediación completa aplicada a la red: verificar en cada paso, no solo en la puerta de entrada.

TLS: un canal seguro sobre un transporte que no lo es#

El transporte de Internet —TCP— entrega los bytes en orden y completos, pero en claro y sin autenticar al otro extremo. Sobre esa base insegura, el protocolo TLS (Transport Layer Security, el sucesor de SSL) levanta lo que hoy se da por descontado: un canal confidencial (cifrado, nadie en el medio lo lee), íntegro (nadie lo altera sin que se note) y autenticado (al menos el servidor prueba ser quien dice). Es el ejemplo canónico de cómo se construye seguridad componiendo: no se reemplaza el transporte inseguro, se le pone una capa encima que provee las garantías que le faltan.

A alto nivel, el establecimiento (handshake) hace tres cosas. Primero, las partes acuerdan qué algoritmos usarán. Segundo, el servidor presenta un certificado —una afirmación de identidad firmada por una autoridad en la que el cliente confía— y el cliente lo valida contra su lista de autoridades raíz; ese paso es donde la criptografía de clave pública y la infraestructura de certificados que la criptografía tratará se vuelven concretas. Tercero, con la identidad establecida, ambas partes derivan una clave de sesión con la que cifran el resto de la conversación. El punto de arquitectura es que toda la seguridad del canal descansa en la validación del certificado: si el cliente acepta un certificado que no debería —porque una autoridad fue comprometida, porque el usuario ignoró una advertencia, porque un intermediario lo suplanta—, el cifrado sigue funcionando perfectamente… hacia el atacante. La confidencialidad sin autenticación no protege: cifra el diálogo con quien no es.

Egress filtering: quitarle al atacante la vía de retorno#

La última pieza es de las más subestimadas. Casi toda la energía defensiva se pone en controlar lo que entra, pero buena parte de una intrusión depende de lo que sale: el canal de mando y control por el que el atacante dirige el equipo comprometido, y la exfiltración por la que se lleva los datos. El filtrado de salida (egress filtering) consiste en controlar y restringir el tráfico saliente con el mismo rigor que el entrante —permitir solo los destinos y protocolos que el negocio necesita, y observar el resto—.

Su valor es que ataca la cadena del adversario en un eslabón tardío y necesario. Un implante que no puede establecer su canal de retorno es un implante mudo; una exfiltración que no encuentra salida se acumula sin poder irse. Por eso el egress filtering, junto con la inspección del tráfico este-oeste, es lo que convierte una red de «cáscara dura, interior blando» en una donde cada movimiento del atacante encuentra una frontera. Es, de nuevo, el mismo principio que atraviesa todo el capítulo: no confiar por defecto —ni en lo que entra, ni en lo que ya está adentro, ni siquiera en lo que sale—, y poner la verificación en cada frontera que el tráfico intenta cruzar.

Referencias#

  • Los modelos de referencia OSI y TCP/IP, la encapsulación, el direccionamiento IP y el enrutamiento son material fundacional de redes; su lectura desde la seguridad —cada capa como una confianza no verificada, cada cabecera como superficie— es enriquecimiento propio.
  • La fragilidad del DNS y de los protocolos de resolución sin autenticación conecta con el envenenamiento y la captura de autenticación que trató la Parte 4; el DNS como canal encubierto conecta con la exfiltración.
  • La segmentación frente a la red plana, y su relación con el movimiento lateral y con la red plana señalada en la brecha de la Parte 9, son la aplicación de la defensa en profundidad de 0.1 a la topología.
  • El uso de la red como frontera de confianza y de la salida (SSRF, exfiltración) como cruce de esa frontera conecta con la inyección de la Parte 3. El zero trust que corrige la suposición del interior confiable se desarrolla en la arquitectura de seguridad, y la validación del certificado TLS se apoya en la criptografía.