Cómo demostramos que la puerta está cerrada antes de la puesta en producción.
Antes de la puesta en producción, demostramos que la puerta está cerrada: atacamos su origen real desde una máquina fuera de la red en la que el firewall nunca confió, y vemos lo que ve un desconocido. Una puerta cerrada responde connection refused, no una página de login.
En este artículo 7 secciones
- Antes de cualquier puesta en producción, y después de cualquier cambio en el edge, hacemos una pregunta: ¿qué ve realmente un desconocido en internet? La respondemos desde una máquina en otro de nuestros centros de datos, en una salida en la que nunca se dijo a nuestro propio firewall que confiara.
- Encontramos el origen real como lo haría un atacante (suele filtrarse en el propio DNS de correo del dominio), fijamos cada herramienta al origen desnudo en lugar de a la CDN y volvemos a ejecutar la batería completa.
- Escaneamos los 65.535 puertos desde ese punto de vista fuera de la red, para poder afirmar qué está cerrado. El arreglo duradero bloquea el origen a los rangos publicados de la CDN, respaldado por un WAF real de capa 7 y listas de bloqueo compartidas.
- Después, no nos creemos el arreglo por fe. Volvemos a atacar el origen desnudo desde fuera, y una puerta cerrada responde connection refused, no una página de login. Eso es una prueba, no una promesa.
La forma más común en que termina un trabajo de bastionado es que alguien cambia un ajuste, recarga la página, ve lo que esperaba y sigue adelante. Eso es parchear y esperar. Demuestra el síntoma que miró; no demuestra nada sobre la puerta. Lo que sigue es el método que ejecutan nuestros ingenieros en su lugar, antes de cualquier puesta en producción y después de cualquier cambio en el edge. Tiene una regla rectora: cada comprobación se ejecuta desde fuera, desde un punto de vista que no recibe ninguna confianza especial, porque la única pregunta que importa es qué puede alcanzar realmente un desconocido en internet. La primera mitad de esto podría ejecutarla usted contra su propio sitio esta noche. La razón para encargárnosla es quién ejecuta la batería completa, y desde dónde.
La única pregunta que importa: ¿qué ve realmente un desconocido?
Ejecutamos el escaneo desde una máquina dedicada en otro de nuestros centros de datos, en una IP de salida en la que nunca se dijo a nuestro propio firewall que confiara. No tiene entrada en la lista de permitidos, ninguna excepción, ninguna cortesía. Ve exactamente lo que ve internet.
Esto solo funciona si el punto de vista es real y está fuera de su perímetro de confianza, y por eso es una máquina en otro de nuestros propios centros de datos, en nuestro propio AS, no un escáner alquilado. Es la misma razón por la que ser dueño de la red importa en absoluto. Más sobre eso en usted no es dueño de su red.
Desde ese punto de vista, tres cosas dejan de ser afirmaciones y se convierten en mediciones. Si su CDN está realmente delante de su origen. Si los puertos que cree cerrados están cerrados. Y, después de un arreglo, si la puerta que acaba de cerrar está realmente cerrada. El resto de esto es cómo leemos cada una.
Encuentre el origen real como lo haría un atacante
El origen suele filtrarse en el propio DNS de correo del dominio, porque el registro SPF que autoriza su correo nombra al mismo host que lo envía. Una vez conocido el origen real, se fija el nombre de host directamente a él, para que cada herramienta golpee el origen desnudo en lugar de la CDN, y se vuelve a ejecutar la batería completa contra él.
# the origin usually leaks in the domain's own mail DNS
scanner$ dig +short TXT origin.example # the SPF record often names the sending host
scanner$ dig +short MX origin.example
# pin the hostname straight to the origin so nothing touches the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/
# now re-run the full battery against the naked origin, not the edge
scanner$ <scan battery> --target <origin-ip>Lo que esto demuestra es sencillo. Si el origen responde al escaneo fijado igual que el nombre de host público, sirviendo las mismas páginas, el mismo formulario de login, entonces la CDN y el WAF que tiene delante están siendo rodeados. Cada petición que un atacante quiera enviar puede pasar de largo.
Escanee cada puerto, después diga qué está cerrado
Desde el punto de vista fuera de la red escaneamos los 65.535 puertos.
# from the box on an egress the firewall doesn't trust: every port, not a shortlist
scanner$ <port-scanner> -p 1-65535 <origin-ip>Un escaneo de toda la superficie no es solo un sí o no por puerto. Qué responde, y cómo, deja la huella de la máquina. Tres señales se repiten.
a mismatched TLS cert on a production subnet -> a forgotten host, fingerprinted
an absurdly low firewall hit-count -> traffic isn't flowing the way you think
a DNS server answering REFUSED -> good: you are not an open resolverUn firewall no es un WAF
La fuerza bruta contra el login es invisible en la capa 3/4, así que la defensa vive en el edge, en la capa 7.
Limite la tasa en el edge, donde están los logins
Cuente los fallos de login por origen en la capa HTTP, el único sitio donde son visibles, y expulse al origen que cruce la línea. El firewall nunca vio el ataque; el edge no ve otra cosa.
Escale a la subred tras dos avisos
Una sola dirección expulsada se rota trivialmente. Tras un segundo aviso desde el mismo vecindario, la expulsión se amplía a la subred infractora, para que el atacante no pueda simplemente moverse una IP más allá.
Decimos la parte incómoda en voz alta: una expulsión de subred puede atrapar a un usuario legítimo que escribió mal su contraseña dos veces desde una dirección compartida, un NAT corporativo, un campus, una cafetería. Es un coste real, no un error de redondeo. Por eso la regla sale con una válvula de escape documentada para IP compartidas, no como un muro permanente.
El arreglo duradero: bloquee el origen a la CDN, después vuelva a atacarlo
El arreglo es poner el origen tras un firewall que solo acepte los rangos publicados de la CDN. Después, la misma sonda fijada, desde la misma máquina no confiable:
# BEFORE: pin the naked origin, it serves the login page around the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
HTTP/1.1 200 OK # the origin answered. the CDN was bypassed.
# AFTER: origin firewalled to accept only the CDN's published ranges
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
curl: (7) Failed to connect to <origin-ip> port 443: Connection refusedDetrás del bloqueo del origen está el WAF real de capa 7, lo que inspecciona las peticiones que la CDN sí reenvía, y una lista de bloqueo compartida: un atacante sorprendido sondeando a un cliente queda expulsado de todos ellos, de modo que el reconocimiento que cartografía un sitio paga peaje en todos los demás.
Lo que arreglamos nosotros, y lo que le devolvemos a usted
Cuando la auditoría encuentra algo, el trabajo se divide en dos columnas. Una es nuestra, y la hacemos en la misma sesión: bastionar en el edge de la infraestructura, de inmediato. La otra está en su aplicación, y no tocamos su código. Le entregamos el hallazgo exacto, y mientras tanto lo protegemos para que no esté expuesto mientras lo arregla.
| Lo que arreglamos en la misma sesión | Lo que le entregamos para arreglar (protegido mientras tanto) |
|---|---|
| Bloquear el origen a los rangos publicados de la CDN | Actualizar o eliminar el plugin, CMS o aplicación vulnerable |
| Levantar la defensa contra fuerza bruta de capa 7 en el edge | Rotar las credenciales compartidas o por defecto |
| Poner los almacenes de datos expuestos tras el firewall, en la red privada | Activar MFA en las cuentas que importan |
| Eliminar las fugas de información en el servidor web | Arreglar la exposición a nivel de aplicación en su propio código |
Después volvemos a atacar, y demostramos que está cerrada
Cada arreglo de arriba termina de la misma manera: volvemos a la máquina en la que nunca se dijo al firewall que confiara, volvemos a ejecutar la batería que encontró el problema y confirmamos que la misma medición ahora vuelve cerrada. La sonda fijada al origen devuelve connection refused (conexión rechazada). El puerto que respondía está a oscuras. El hallazgo que le entregamos, una vez que usted lo cierra, también nos rechaza a nosotros.
La misma postura, apuntada a si siquiera controlamos la red por la que viaja su tráfico, está en usted no es dueño de su red.
Respuestas directas
¿Cómo demuestran que un arreglo de seguridad ha funcionado de verdad?+
No nos fiamos del parche. Volvemos a atacar el origen real desde una máquina en una salida en la que nunca se dijo a nuestro firewall que confiara, para que vea lo que ve internet. Si la puerta está cerrada, un escaneo fijado al origen desnudo responde connection refused, no una página de login. En ese caso, es una prueba, no una promesa.
¿Cómo puede un atacante saltarse una CDN o un WAF y golpear el origen directamente?+
El origen suele filtrarse en el propio DNS de correo del dominio, porque el registro SPF que autoriza su correo nombra al host que lo envía. Con la dirección real del origen, se fija el nombre de host directamente a él para que cada herramienta golpee el origen desnudo en lugar de la CDN. Si el origen responde igual que el nombre de host público, la CDN y el WAF están siendo rodeados: solo son eficaces si el origen está bloqueado a ellos. El arreglo duradero es poner el origen tras un firewall que acepte tráfico solo de los rangos publicados de la CDN, tras lo cual la misma sonda obtiene connection refused.
¿Cómo comprueban que un puerto está realmente cerrado desde fuera?+
Se escanean los 65.535 puertos desde un punto de vista fuera de la red, no los pocos habituales, para poder afirmar que todo lo que no pretendía exponer está cerrado. Un escaneo completo también saca señales a la luz: un certificado TLS que no coincide deja la huella de un host olvidado, un recuento de impactos del firewall absurdamente bajo significa que el tráfico no fluye como usted cree, y un servidor DNS que responde REFUSED confirma que no es un resolutor abierto.
¿Qué arreglan ustedes, y qué tenemos que arreglar nosotros?+
En la misma sesión bastionamos en el edge de la infraestructura: bloqueamos el origen a los rangos de la CDN, levantamos la defensa contra fuerza bruta en el edge, ponemos los almacenes de datos expuestos tras el firewall en la red privada y eliminamos las fugas de información en el servidor web. Después le entregamos el hallazgo exacto y lo protegemos mientras tanto: actualizar o eliminar el plugin, CMS o aplicación vulnerable, rotar las credenciales compartidas o por defecto, activar MFA y arreglar la exposición a nivel de aplicación en su propio código.
No nos limitaremos a cerrar el ticket. Demostraremos que la puerta está cerrada.
Hable con un ingeniero que vuelve a atacar su origen desde una máquina que nunca pusimos en la lista de permitidos, y le muestra el connection refused que demuestra que la puerta está cerrada.
Hable con un ingenieroSi quiere la postura que hay debajo de todo esto, empieza por ser dueño de la red desde la que se le defiende: usted no es dueño de su red.
Ha llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero