Ocultar la IP de origen

«¿Debería poner un CDN delante?» es la primera pregunta que se hace la mayoría de la gente después de comprar un servidor offshore, y no tiene una respuesta única, porque en realidad son dos preguntas con un solo abrigo. Absorber un ataque y seguir siendo inencontrable son problemas distintos con soluciones distintas, y la disposición que resuelve uno puede deshacer el otro sin que te des cuenta.

La confusión sale cara en ambas direcciones. Hay quien pone un gran CDN estadounidense delante de un contenido que eligió alojar precisamente por su hosting ignorado por DMCA, y así devuelve un canal de reclamaciones justo al tipo de intermediario que intentaba evitar. Otros se saltan todo, reciben una inundación de capa de aplicación que el filtrado de red nunca fue diseñado para ver, y concluyen que la protección DDoS era mentira. Esta guía separa los dos problemas, explica qué hace realmente cada capa, y dedica la mayor parte de su extensión a la parte que decide el resultado en cualquier caso: las seis formas en que una dirección de origen se filtra incluso cuando todo lo demás está bien configurado.

Dos problemas que parecen uno solo

Cualquier cosa que pongas delante de un servidor cumple una de dos funciones: mantener un ataque alejado de él, o mantener su dirección desconocida. Se solapan lo suficiente como para confundirse y difieren lo suficiente como para que resolver el problema equivocado sea un desperdicio de dinero.

Lee dos veces la última fila, porque es la que atrapa a la gente. Todo lo demás en esta página es ingeniería. Esa fila no lo es.

Lo que tu proveedor ya hace, y dónde se detiene

El filtrado de capa 3 y capa 4 está incluido en todos los planes que vendemos, sin coste adicional, y se ejecuta en el borde de la red en lugar de en tu servidor — el único lugar donde puede funcionar, ya que un enlace ascendente saturado no lo arregla nada que se ejecute detrás de él. El ancho de banda es ilimitado, así que un ataque no se convierte en una factura. Para la gran mayoría de lo que la gente llama «un DDoS», esa es toda la historia.

Lo que no puede ver es el otro tipo. Quinientas solicitudes por segundo a un endpoint de búsqueda desde cuarenta mil direcciones residenciales no es tráfico malformado; es tráfico. Las conexiones Slowloris que gotean una cabecera cada pocos segundos son, individualmente, educadas. Un formulario de inicio de sesión martilleado con cuerpos POST reales es indistinguible a nivel de paquete de un lunes ajetreado. Ningún filtro de paquetes ayuda, porque no hay nada malo en los paquetes.

Hay una dirección de tráfico ante la que sí actuamos, y merece decirse sin rodeos: los ataques y el spam masivo originados en nuestra red pueden enviarse a una ruta nula (null-routing) para mantener sano el resto de la infraestructura. Es una medida operativa, no de contenido — la distinción que nuestra guía de hosting ignorado por DMCA desarrolla con más detalle.

Lo que oculta un CDN, y el servicio de abuso que heredas

El mecanismo es simple y genuinamente eficaz. Tu dominio resuelve a las direcciones del proveedor, los clientes se conectan ahí, y el proveedor obtiene el contenido de tu origen. La dirección real nunca aparece en la conexión de un cliente, así que nadie que solo conozca el dominio puede atacarla. El mismo truco es la razón por la que el CDN fronting funciona para proxies resistentes a la censura: un censor ve tráfico hacia una dirección que no puede permitirse bloquear.

Con eso llegan tres cosas, y ninguna está escondida en la letra pequeña:

• El borde termina tu TLS. El tráfico es texto plano dentro de la red del proveedor por diseño — así es como funcionan el caché y el filtrado. Lo que sea que escriban tus usuarios llega a un tercero antes de llegar a ti.
• Un canal de abuso que antes no existía. Las reclamaciones pueden presentarse directamente contra el CDN, y un CDN las responde: reenviándotelas, señalando a tu proveedor de hosting, o dándote de baja. Si tu razón para estar offshore es que las reclamaciones no llegan a ninguna parte, poner un intermediario estadounidense delante reconecta la cadena que pagaste por romper.
• Una cuenta. Dirección de correo electrónico, método de pago, a menudo un número de teléfono, vinculados a tu dominio y conservados indefinidamente. Más sobre esto más abajo, porque suele ser el eslabón más débil de toda la disposición.

Nada de eso hace que un CDN sea un error. Lo convierte en una decisión con dos caras: excelente para una tienda o una aplicación con usuarios reales y presión real de capa 7, activamente contraproducente para una publicación que atrae retiradas. Nuestra propia respuesta a esta pregunta en la página de hosting ignorado por DMCA siempre ha sido la versión corta de esto: para resistir a las retiradas, usa el filtrado de red que ya tienes y prescinde del CDN.

Las seis formas en que una dirección de origen se filtra igualmente

Esta es la sección que importa, porque la ocultación no es un producto que se compra — es una propiedad que mantienes o pierdes, normalmente en cuestión de días, ante una de seis cosas. Cada día se encuentran orígenes detrás de configuraciones de CDN perfectamente correctas.

• Los registros de Certificate Transparency. Todo certificado de confianza pública emitido para tu dominio se publica en registros públicos, permanentes y consultables en cuestión de minutos. No publican tu dirección; publican tus nombres de host — staging, mail, vpn, el subdominio que configuraste una vez en 2024. Cada uno es candidato a resolverse, y un solo registro que no apunte al frontal termina con el ejercicio.
• El historial de DNS. Los servicios de DNS pasivo archivan cada dirección a la que ha resuelto alguna vez tu dominio. Pasar detrás de un CDN más tarde no despublica lo que ya quedó registrado — la ocultación tiene que empezar antes de que el dominio resuelva por primera vez, o necesitas una dirección nueva, no un frontal nuevo.
• Registros que no se pueden proxear, y los que olvidaste. Los servidores de correo tienen que apuntar a algo alcanzable. Lo mismo ocurre con un registro AAAA olvidado cuando solo proxeaste IPv4, un antiguo nombre de host de FTP o de panel, un comodín, o el host de desarrollo «temporal» que ya tiene tres años.
• Cualquier cosa que envíe el servidor. El correo desde el origen lleva su dirección en las cabeceras Received — un mensaje de restablecimiento de contraseña es una divulgación por cuenta propia. Los webhooks, las descargas de imágenes salientes, las vistas previas de enlaces, los pingbacks, las comprobaciones de actualizaciones y los reportadores de fallos contactan todos desde la dirección real, y cualquiera que consiga que tu aplicación hable con un host que controla la aprende.
• El escaneo de todo internet. Cada dirección IPv4 se escanea y se indexa continuamente mediante servicios públicos, y los resultados son consultables en segundos. Si tu origen responde en el puerto 443 con tu certificado, o sirve tu página de inicio ante cualquier cabecera Host, encontrar la coincidencia es una sola consulta contra un hash del cuerpo, una huella de certificado o un hash de favicon. Así es como se encuentran la mayoría de los orígenes, y no le cuesta nada a quien busca.
• La aplicación hablando de sí misma. URLs absolutas y redirecciones que contienen la dirección en crudo, endpoints de estado o de métricas dejados abiertos, trazas de pila detalladas que nombran hosts internos, cabeceras que revelan el backend, y el host virtual por defecto que sirve alegremente tu sitio a cualquiera que lo pida por dirección.

Cerrar el origen para que solo el frontal pueda alcanzarlo

Una ocultación que depende de que nadie adivine la dirección no es ocultación. La disposición solo se sostiene cuando el origen se niega a hablar con nadie que no sea el frontal, de modo que una dirección filtrada sea una molestia y no un incidente.

• Denegar por defecto, y luego permitir al frontal. Acepta los puertos 80 y 443 solo desde los rangos de direcciones publicados por el proveedor, y actualiza esa lista automáticamente — los rangos cambian, y una lista desactualizada falla abierta o falla cerrada en el peor momento. Todo lo demás, incluido SSH, pertenece a un túnel o a una dirección de gestión, como en nuestra lista de refuerzo de la primera hora.
• Autenticar al frontal. Los certificados de cliente entre el CDN y tu origen — normalmente llamados authenticated origin pulls — hacen que incluso una dirección correcta más una cabecera Host correcta no obtengan nada sin el certificado.
• Mejor: ningún puerto de entrada en absoluto. Un túnel solo de salida desde el origen hasta el borde, ya sea el conector propio del CDN o WireGuard hacia un nodo que tú operas, hace que el origen nunca escuche en una interfaz pública. El escaneo no puede encontrar lo que no responde, y esta es, con diferencia, la versión más sólida de la disposición.
• Un solo host virtual, una sola cabecera Host. El servidor por defecto no debería devolver nada útil. Si tu sitio carga por dirección, un escáner lo emparejará en cuestión de una semana.
• Saca el correo del origen web. El correo tiene que ser alcanzable y tiene que identificarse; mantenlo en su propia máquina, como asume nuestra guía de servidor de correo.
• Verifica desde fuera. Cada comprobación de esta lista no significa nada si se ejecuta desde el propio servidor. Pruébalo desde una red que no sea la tuya.

Tu propio nodo frontal en lugar de un CDN

La tercera opción se pasa por alto porque no tiene presupuesto de marketing: un VPS pequeño como cara pública, un túnel cifrado de vuelta a la máquina que guarda los datos, y nginx o HAProxy pasando el tráfico entre ambos. Desde fuera parece cualquier servidor web. El real está en otro sitio, sin ningún puerto de entrada.

Lo que obtienes es ocultación sin nadie más en la disposición — sin cuenta de terceros, sin servicio de abuso externo, sin ningún desconocido terminando tu TLS. También obtienes una división de jurisdicción que de otro modo es difícil de comprar: el frontal donde están los usuarios, los datos donde te conviene la ley, elegidos entre nuestras siete ubicaciones. Y como no se vinculó ninguna identidad al darte de alta, el frontal es desechable — una dirección quemada se sustituye en minutos en lugar de negociarse.

Lo que no obtienes es capacidad anycast. Un nodo tiene la capacidad de un nodo, y aunque nuestro filtrado de red lo protege exactamente igual que a cualquier otro servidor, un ataque volumétrico genuinamente grande es una competición de ancho de banda que gana una red global. Planteado con honestidad: un nodo frontal es la respuesta correcta para ocultar un backend pesado o caro — una cabina de almacenamiento, una máquina con GPU, un servidor de correo, una base de datos — y para dividir jurisdicciones. No sustituye a un CDN bajo presión sostenida de capa 7.

Cómo elegir, en una sola tabla

La cuenta suele ser el eslabón más débil

Piensa en lo que ocurre cuando la infraestructura es perfecta y el papeleo no lo es. El servidor se pagó en Monero, sin documentos de identidad ni dirección de correo electrónico — la disposición que describen nuestras páginas de hosting sin KYC. Luego se abre una cuenta de CDN con una tarjeta, una dirección personal y un número de teléfono, indicando el dominio que protege. Esa cuenta es un registro de identidad más sólido y más duradero que cualquier cosa del servidor, en manos de una empresa que responde a citaciones judiciales, y deshace por completo la privacidad del pago.

La solución no es complicada, solo fácil de olvidar: si el objetivo es el anonimato, o el frontal te pertenece, o la cuenta que hay delante es tan desechable y tan inatribuible como el servidor que hay detrás. OpSec para servidores cubre esta disciplina como es debido, y nuestra respuesta honesta sobre el anonimato offshore es tajante sobre qué eslabones de la cadena suelen romperse primero. Casi nunca son los técnicos.

Auditar tu propia exposición en diez minutos

Cada punto de la lista siguiente es algo que una parte interesada comprobaría en los primeros minutos. Hazlo tú mismo, desde una máquina que no sea el servidor, antes de necesitar las respuestas.

• Lista todos los nombres de host que hayas certificado alguna vez. Busca tu dominio raíz en un motor de búsqueda de Certificate Transparency y resuelve cada resultado. Cualquiera que no apunte al frontal es una fuga, incluidos los hosts que ya no usas.
• Lee tu propio historial de DNS. Una consulta de DNS pasivo muestra las direcciones a las que resolvió tu dominio antes del CDN. Si el origen de ayer sigue siendo el de hoy, la ocultación nunca fue real.
• Pregunta al origen directamente. curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — si el sitio responde, tu firewall no está restringiendo el frontal y cualquiera con una dirección candidata puede confirmarlo con una sola solicitud.
• Pregunta sin rodeos. curl -skI https://198.51.100.10/ no debería devolver nada reconocible. Un host virtual por defecto que sirve tu página de inicio es el error único más común de esta página.
• Comprueba cada tipo de registro, no solo A. dig +short AAAA example.com, dig +short MX example.com, y lo mismo para cada subdominio que revelaron los registros de transparencia. Un IPv6 dejado sin proxear es un clásico.
• Envíate un correo desde la aplicación. Dispara un restablecimiento de contraseña y lee la cadena completa de Received. Si la dirección de origen está ahí, también lo está en todos los mensajes que hayas enviado nunca.
• Confirma que los puertos están cerrados. Desde una red que no tenga relación, nmap -Pn -p80,443 198.51.100.10 debería mostrarlos como filtered, no como open.
• Busca en los escáneres. Consulta la huella de tu certificado y el hash del favicon de tu página de inicio en un índice público de escaneo de internet. Si tu origen está indexado, así es como se encontrará.

Cuando la dirección ya está quemada

Da por hecho que seguirá quemada. Una dirección que ha aparecido en DNS pasivo y en índices de escaneo queda en el registro público de forma permanente, y ningún cambio de configuración la retira. La respuesta es mecánica, no ingeniosa.

• Arregla primero la fuga. Rotar a una dirección nueva sin cerrar el agujero reproduce la situación en cuestión de días, y habrás gastado una migración para no aprender nada.
• Luego rota. Despliega un reemplazo — en una jurisdicción distinta si el motivo era legal y no técnico — restaura, y haz el cambio. Como no se vinculó ninguna identidad al primer servidor, esto es un comienzo desde cero en lugar de una negociación, que es la ventaja práctica y poco glamurosa de comprar servidores sin historial de cuenta.
• Prepara el cambio antes de la emergencia. Un TTL de DNS corto, una configuración que puedas volver a desplegar desde un repositorio y una restauración probada convierten una mala tarde en veinte minutos. Nadie organiza esto durante un ataque.
• Retira bien la dirección antigua. No dejes el servidor antiguo aparcado en la dirección antigua sirviendo el mismo contenido; eso es una confirmación en vivo para quien esté observando, y mantiene fresco el registro.

La versión corta

El filtrado a nivel de red se ocupa de los ataques volumétricos, viene con el servidor y no cuesta nada extra. Un CDN se ocupa de la capa de aplicación y oculta el origen, al precio de un intermediario que termina tu TLS, responde a las reclamaciones y sabe quién eres. Tu propio nodo frontal compra ocultación sin el intermediario, pero no capacidad global. La jurisdicción decide la cuestión legal y ninguna de las tres opciones la toca. Y a todas las deshace un solo registro sin proxear, un solo correo desde el origen, o un solo host virtual por defecto.

Decide según el objetivo y no por costumbre, y dedica luego los diez minutos a la auditoría — encuentra más exposición real que cualquier mejora de plan. Si quieres la arquitectura sin el tercero, un pequeño VPS como frontal y el trabajo real en hardware dedicado detrás es la disposición que vemos con más frecuencia entre quienes ya han sido encontrados una vez.