¶ Primeros Pasos
En esta sección vamos a dar los primeros pasos para poner en marcha tu CDN, desde cero hasta tener tu sitio web sirviendo contenido a través de la red de Transparent Edge.
Empezaremos configurando el Backend, el recurso que define dónde está alojado realmente tu contenido (tu servidor de origen) y cómo debe comunicarse el CDN con él. A continuación veremos cómo crear y configurar el Site, que es el recurso que conecta tu dominio público con ese Backend y lo publica a través de la red de Transparent Edge, incluyendo la verificación del dominio y la gestión de certificados.
Una vez ambos recursos estén creados y el DNS apuntando correctamente al CDN, pasaremos a la parte de configuración: cómo usar el Easy Setup para activar de forma sencilla funcionalidades clave como la seguridad de tu sitio (Anti-DDoS, Bot Mitigation y WAF), y cómo, si lo prefieres, escribir tu propia configuración en VCL para un control más avanzado.
¶ Configuración inicial
Para iniciar con el proceso de configuración inicial y aprovisionamiento de recursos, debemos de acceder a la ventana de Provisioning desde el menú lateral del dashboard CDN.
¶ Backend
El recurso Backend es el núcleo de la configuración del CDN. Permite gestionar y coordinar la infraestructura encargada de la distribución del contenido, centralizando la administración de dominios, configuraciones de servicio, políticas de enrutamiento y la supervisión del estado de los nodos que forman la red. Además, actúa como punto de referencia para los recursos asociados a la plataforma.
¶ Añadir Backend
Para añadir un nuevo Backend, seleccionamos Add new backend
Se abrirá un formulario donde se deberán especificar los siguientes campos sobre el backend que se utilizará para servir el contenido.
| Opción | Descripción |
|---|---|
| Name | Nombre descriptivo y único del backend que comienza por el id de la compañía |
| IP Origin / Host | Dirección IP o dominio del servidor origen |
| SSL | Indica si la aplicación utiliza conexión segura HTTPS mediante certificados SSL/TLS. |
| Port | Puerto en el que servidor origen escucha las conexiones, normalmente 80 o 443 si usa HTTPS. |
| Healthcheck - Host | La cabecera Host que se enviará al servidor backend. Por ejemplo, si el servidor utiliza Apache, correspondería al valor configurado en ServerName o ServerAlias, como www.example.com. |
| Healthcheck - URL | La URL a la que el healthcheck enviará la solicitud de comprobación. Debe apuntar a un recurso muy ligero y que no cambie nunca, por ejemplo un archivo .txt vacío alojado en el servidor web. |
| Healthcheck - Status code | El código de estado HTTP esperado. Si el servidor backend responde con un código diferente, el backend se marcará como no disponible (unhealthy) y el contenido no cacheado podría fallar. |
Ejemplo de configuración final:
Una vez completado según los datos necesarios de cada caso, podemos guardar seleccionando en Save changes.
¶ Sites
El recurso Sites define los sitios web o aplicaciones que publicarán contenido a través del CDN. Cada Site se asocia a un Backend previamente configurado, heredando su infraestructura y políticas de distribución. Desde este recurso se gestionan los dominios de entrega y la relación entre el contenido de origen y la red CDN, facilitando una publicación eficiente, segura y escalable.
¶ Crear Site
Una vez se ha configurado y guardado correctamente la configuración del Backend, podremos proceder a generar un Site mediante la selección de la opción Add Site.
En primer lugar, CDN solicita añadir el registro DNS que referencia a la máquina (caso regular como registro de tipo A).
Es importante remarcar que este registro requiere ser generado previamente a este procedimiento y resolutivo a nivel global.
Una vez añadimos nuestro dominio, podremos proseguir con las siguientes configuraciones del Site. En este punto, se requiere verificar la propiedad del dominio que se va a agregar. Tenemos dos opciones:
El proceso requiere que generemos un fichero con nombre "tcdn.txt" en la raíz del site (donde reside index.html en el caso de nginx por ejemplo) con el código de verificación y, una vez realizado, si se lanza solicitud sobre el link 🔗URL, el código de verificación debe aparecer aplicado.
El proceso requiere que generemos un registro DNS adicional en el dominio donde reside el registro asociado a la máquina con tipo TXT. Este registro deberá de generarse con el mismo nombre de registro al añadido, y con el campo que aparece disponible para copiar.
¶
Tras aplicar las configuraciones de verificación con cualquiera de los dos casos, podemos delegar la configuración de Site o configurarlo nosotros mismos.
Si seleccionamos la opción No, I will configure it myself, en la siguiente opción nos aparecerá una regla básica VCL que realiza lo siguiente:
- Detecta las peticiones dirigidas a web.test.es
- Asocia esas peticiones al backend cXXX_pruebas (XXX será el id de vuestro backend)
- Redirige automáticamente las conexiones HTTP a HTTPS
Debemos tener en cuenta que para que esta redirección funcione debemos importar o generar los certificados dentro del transparent.
Para generar o importar los certificados seguiremos los pasos adjuntos en la siguiente imagen:
Una vez creado el site, para que las solicitudes se apliquen en el CDN, es necesario cambiar el tipo de registro de nuestro dominio.
Debemos proceder al borrado de registro tipo A de la configuración DNS y generar un registro tipo CNAME que apunte el dominio del servidor (indicado en el site al inicio de su creación) a caching.cXXX.edge2befaster.net. (donde XXX será el id de company).
Este enlace podrá observarlo desde cualquier ventana de la sección de Provisioning en la parte superior con el siguiente mensaje:
¶ Configuración
Una vez generados los recursos Backend y Site, y tras modificar el registro DNS para establecerlo como tipo CNAME, podremos proceder con la configuración del CDN. Para la parte, existe dos tipos de modalidades:
Este modelo de configuración permite realizar acciones clave en tus sitios web de forma fácil y ágil. Se basa en la lógica condicional «si... entonces». Para utilizarla, debes definir una regla con un conjunto de condiciones y una acción específica para cada una de ellas.
Una vez familiarizado con la lógica del Easy Setup, el siguiente paso recomendado es activar y ajustar la capa de seguridad de tu sitio: Anti-DDoS, Bot Mitigation y WAF. A continuación se explica qué hace cada servicio y cómo activarlos, siguiendo un orden pensado para no generar interrupciones en tu sitio: primero se observa, después se ajusta y por último se bloquea.
¶ ¿Qué es el Anti-DDoS?
Transparent Edge ya tiene activado un servicio Anti-DDoS por defecto, el cual no se puede deshabilitar ya que este actúa tanto en las capas 3 y 4 como en la capa 7 de manera integrada.
Las dos capas
Se aplica en dos niveles:
Capas 3 y 4
El Anti-DDoS de Transparent Edge analiza la dirección IP de origen, la IP destino y el tipo de protocolo. A este nivel, frena ataques masivos de fuerza bruta que intentan colapsar el ancho de banda o agotar las conexiones de red de la infraestructura.
Los ataques que bloquea el Anti-DDoS en las capas 3 y 4 son:
- Inundación de negociación SSL, UDP, GRE-IP UDP, SYN, TCP RST, TCP CONNECT() y TCP ACK
- Amplificación de DNS, NTP, CharGEN, Memcache, SSD, SNMP
- Tsunami SYN
- Ataques de fragmentación y CLDAP
- ARMS (ARD)
- Jenkins
- Cuentagotas DNS
- CoAP
- WS-DD
- NetBIOS
Capa 7
El sistema (gestionado por el motor de Varnish Enterprise) inspecciona el interior del paquete comprobando el contenido de la petición HTTP/S. Esto permite frenar ataques "inteligentes" y selectivos (como inundaciones de peticiones o bots) que intentan agotar los recursos internos de nuestro servidor.
En esta capa tenemos los siguientes ataques que bloquea:
- Inundación de peticiones HTTP/S, de inicio de sesión, de creación de sesión y de contenido
- Amplificación DNS
- Ataques de fuerza bruta
- Slowloris
El Anti-DDoS no requiere ninguna acción de configuración por tu parte: viene activo desde el momento en que tu sitio se publica a través del CDN.
¶ ¿Qué es el Bot Mitigation?
Es un sistema integrado en el CDN que detecta y filtra tráfico automatizado antes de que llegue a tu web. En su núcleo es una base de datos de reputación de IPs, actualizada en tiempo real, que protege los sitios de tráfico sintético malicioso.
Este sistema distingue entre bots buenos (Googlebot, Bingbot, que respetan robots.txt) y bots malos (que buscan vulnerabilidades, hacen scraping abusivo, ataques DDoS, etc.) y los clasifica por sofisticación:
- Simple: una IP, scripts sin disimulo.
- Moderado: navegador headless, ejecuta JS.
- Avanzado: simula ratón y clics, propio de botnets.
- Evasivo: como el avanzado pero además se esconde con VPNs/proxies.
El radar de bots
Cada vez que llega una petición a tu web:
- Mira la IP del visitante en una caché local muy rápida.
- Si no la tiene cacheada, consulta un backend de inteligencia de amenazas que devuelve una puntuación de riesgo y unas flags.
- Compara esa puntuación/flags con los umbrales que tú has configurado para tu sitio.
- Si se supera, ejecuta la acción configurada: bloquear (403), mostrar un captcha, mostrar un reto JavaScript, o simplemente registrar sin actuar (bypass).
A diferencia del Anti-DDoS, el Bot Mitigation no viene activado por defecto: es un servicio que debe habilitarse desde el dashboard.
Activar Bot mitigation
Dentro de la pestaña Easy Setup de tu Site, añade una nueva regla (New rule) y sigue estos pasos:
- Selecciona el tipo de regla Bot Management (categoría Botmitigation).
- Ponle un nombre descriptivo en Rule Name (por ejemplo,
Bot Management #1). - En el bloque WHEN..., elige Custom filter rule y selecciona la condición Client IP con el operador y el valor que corresponda (por ejemplo, una IP o rango concreto que quieras tratar de forma diferenciada).
- En el bloque inferior Bot Management, selecciona el comportamiento que se aplicará cuando una IP sea marcada o bloqueada por el servicio de Bot Mitigation. Las opciones disponibles incluyen
Block, entre otras.
- Guarda la regla. El Easy Setup genera y despliega automáticamente la configuración equivalente, sin que tengas que escribir VCL a mano.
El formulario incluye más campos de configuración avanzada (Score threshold, Flags, etc.) que no se cubren en esta guía; aquí nos centramos en el caso de uso de condición por Client IP.
Recomendación: si vas a usar la acción
Block, hazlo primero sobre una IP o rango concreto y conocido (por ejemplo, una IP de pruebas tuya) para validar que la regla se comporta como esperas, antes de aplicar condiciones más amplias a todo el tráfico del sitio.
¶ ¿Qué es el WAF?
El WAF inspecciona el tráfico HTTP/HTTPS independientemente de si la petición va dirigida a una página web o a un endpoint de API. Escanea el tráfico en tiempo real y analiza peticiones maliciosas y riesgos de seguridad, protegiendo tus sitios y APIs de ataques y exploits, sin que tengas que definir reglas manualmente.
Funciona como un filtro situado entre internet y tu servidor: examina cada petición buscando patrones típicos de ataque (SQL injection, XSS, inclusión de ficheros, etc.) y decide si la deja pasar o no. Puedes aplicar reglas específicas según la ruta, el método HTTP o el tipo de contenido, y crear excepciones por IP, ruta, cabecera o parámetro.
Transparent Edge no cobra por regla: puedes personalizar la configuración sin límite en el número de reglas activas.
Configuración básica del WAF (Easy Setup)
Dentro de Security & Access Control, encontrarás varias reglas relacionadas con el WAF. Para tu primer despliegue solo necesitas tres: Activate WAF, WAF Mode y WAF exception, aplicadas en este orden.
1 Encender
Crea una nueva regla y selecciona Activate WAF. Define las condiciones de WHEN... (por ejemplo, todas las peticiones entrantes, o un host/ruta concreto) y guarda la regla.
Con esto el WAF queda activado para tu sitio, aunque por defecto actuará en modo bloqueo. Por eso el siguiente paso es importante antes de dejarlo así en producción.
2 Solo mirar
Crea una segunda regla y selecciona WAF Mode. Esta regla permite desactivar el WAF (#Off) para una request, o cambiarlo a modo solo detección (#DetectionOnly) para probar amenazas potenciales sin bloquear.
Configura la condición WHEN... igual que en la regla de Activate WAF (por ejemplo, todas las peticiones de tu sitio) y selecciona el valor #DetectionOnly.
Con esto el WAF queda activo pero en modo observación: detecta y registra las peticiones sospechosas, pero no bloquea nada. Déjalo así durante unos días para que el WAF "vea" tu tráfico real (formularios, APIs, plugins, integraciones...) y revisa los logs de auditoría WAF para detectar falsos positivos: peticiones legítimas que el WAF habría bloqueado.
3 Curar falsos positivos
Si durante la fase de detección encuentras falsos positivos, crea una regla WAF exception para esa ruta, IP, cabecera o parámetro concretos. Esta regla permite excluir esa request de las reglas del WAF para evitar bloqueos no deseados, sin tener que desactivar el WAF para todo el sitio.
Configura la condición WHEN... apuntando específicamente al caso con falso positivo (por ejemplo, una ruta o un parámetro determinado) y guarda la regla.
4 Pasar a producción
Cuando ya no detectes falsos positivos relevantes, edita la regla WAF Mode del paso anterior y elimínala (o cambia su valor a #On, que es el comportamiento por defecto de Activate WAF).
A partir de aquí, las peticiones que el WAF identifique como peligrosas se bloquean (normalmente con un 403), salvo las que hayas eximido con las reglas WAF exception creadas en el paso anterior. Si surge un nuevo falso positivo ya en producción, repite ese paso para ese caso concreto, sin necesidad de volver a modo detección global.
Siguiendo este orden (Anti-DDoS verificado → Bot Mitigation activo en modo suave → WAF en detección → ajuste de excepciones → WAF en bloqueo) consigues activar toda la capa de seguridad sin generar interrupciones para los usuarios legítimos de tu sitio.
Este modelo de configuración utiliza una versión modificada del lenguaje de configuración de Varnish (VCL), el cual es un potente lenguaje que permite personalizar en gran detalle el comportamiento del sitio web y comportamiento del CDN.
La configuración actual y activa es la que aparece marcada con una marca verde bajo el encabezado «Estado».
Puede realizar las siguientes acciones:
-
View: abre una vista de solo lectura de la configuración.
-
Duplicate: abre un editor para implementar una nueva configuración prellenada con el código de esta configuración en particular.
-
Back to production: una forma rápida de volver a implementar una configuración anterior; es un botón de revertir.
Además de la posibilidad de escribir manualmente el código Varnish, también se ofrece la posibilidad de utilizar un Ai Assistant para poder crear o mejorar las reglas.
También desde el equipo técnico de Aire Cloud hemos añadido ejemplos de configuración de Varnish, los cuales pueden observarse visitando la siguiente página:
Ejemplos de configuración VCL