Por qué filtrar en el edge cambia el juego
Cuando tu servidor de aplicación hace sus propias verificaciones de seguridad, cada solicitud maliciosa igual llega hasta el, consume CPU, abre una conexion a la base de datos y compite con usuarios reales por recursos. cdn.com.tr traslada esa inspección al edge, de modo que los intentos de inyección, las sondas de escáneres y el tráfico basura se rechazan lejos de tu origin y nunca tocan tu código ni tu base de datos. Esa es la diferencia entre un servidor que se dobla bajo un ataque y uno que apenas lo nota, porque la carga abusiva la absorbe una red distribuida construida para soportarla.
El conjunto de reglas WAF administrado
El web application firewall inspecciona el método de la solicitud, la ruta, los headers y el body contra reglas que reconocen las clases de ataque más conocidas: inyección SQL, cross-site scripting, remote file inclusión, path traversal y command injection entre otras. Estas reglas se mantienen de forma centralizada, así que te beneficias de las actualizaciones sin editar tu propia configuración, lo cual importa más para plataformas como WordPress y PHP legacy donde la propia aplicación puede tardar en parchearse. Puedes activar la protección por dominio y añadir tus propias reglas de permitir y denegar encima para rutas específicas de la aplicación.
Absorbiendo inundaciones DDoS
Un ataque de denegación de servicio distribuido intenta agotar tu capacidad enviando mucho más tráfico del que un solo origin puede responder. Como cdn.com.tr pone un edge distribuido delante de tu dominio, las inundaciones volumétricas se reparten por la red y se filtran antes de concentrarse en tu servidor, y las respuestas cacheadas se siguen sirviendo desde el edge incluso mientras el ataque está en curso. El resultado práctico es que tu origin permanece accesible para los visitantes legítimos exactamente en los momentos en que un sitio sin protección quedaría fuera de línea.
Rate limiting y mitigación de bots
No toda amenaza es una firma; algunas son simplemente demasiadas solicitudes de un mismo cliente. El rate limiting te permite limitar cuántas veces una IP puede golpear endpoints sensibles como formularios de login, restablecimientos de contraseña o rutas costosas de la API, lo que corta el credential stuffing por fuerza bruta y el scraping agresivo sin bloquear a los usuarios normales. Combinado con reglas de acceso por país e IP, esto te da una forma de detener automatización abusiva que un firewall basado en firmas por sí solo pasaría por alto, todo configurado por dominio desde el panel.
Ocultar el origin elimina el bypass
Un firewall en el edge solo funciona si los atacantes no pueden rodearlo, y el error clásico es dejar el servidor origin accesible en su IP real. cdn.com.tr te anima a bloquear el origin para que solo acepte conexiones desde el edge y a mantener su dirección fuera del DNS público, lo que significa que el único camino hacia tu aplicación pasa por la capa de seguridad. Este origin shielding convierte al WAF de un obstáculo opcional en un punto de control obligatorio, y además reduce la superficie de ataque expuesta a los escáneres de todo internet.
Una sola política de seguridad para cada app que ejecutas
Ya sea que publiques un sitio WordPress, un portal PHP legacy o una API basada en contenedores, el mismo modelo de seguridad edge aplica una vez que el dominio se enruta a través de cdn.com.tr. Eso significa que no mantienes un stack de firewall separado por aplicación; conectas el dominio, activas el WAF, defines rate limits, y la política lo protege de manera uniforme. Para equipos que administran varios sitios o servicios, esta consistencia es lo que hace que la seguridad sea manejable en lugar de un lio por proyecto.
Cómo configurarlo, paso a paso
Enruta el dominio a través del edge
Agrega el hostname a tu cuenta del CDN y apunta su DNS al edge de cdn.com.tr. A partir de ese momento cada solicitud del dominio entra primero por un nodo edge, lo cual es el prerequisito para que aplique cualquier política de seguridad, porque un firewall solo ayuda si todo el tráfico realmente pasa por el.
Activa el WAF para el dominio
Activa el web application firewall en el panel para ese dominio. El conjunto de reglas administrado empieza de inmediato a inspeccionar las solicitudes en busca de firmas de ataque comunes como inyección SQL, cross-site scripting y path traversal, sin cambios en tu aplicación.
Oculta y blinda tu origin
Una vez que el tráfico fluye a través del edge, restringe tu origin para que solo acepte conexiones desde cdn.com.tr y deja de publicar su IP real en el DNS público. Esto cierra el bypass donde un atacante golpea el origin directamente y se salta por completo el WAF.
Agrega rate limits y reglas de acceso
Configura rate limiting en endpoints sensibles como /wp-login.php, /xmlrpc.php, o la ruta de autenticación de tu API, y agrega reglas de permitir/denegar por país o IP donde sea necesario. Esto detiene el abuso de fuerza bruta y scraping antes de que consuma recursos de la aplicación.
Confirma TLS y fuerza HTTPS
Con Auto SSL en su lugar, activa la redirección a HTTPS para que cada solicitud se actualice a TLS en el edge. Esto asegura que el tráfico inspeccionado y reenviado a tu origin este cifrado de extremo a extremo para los visitantes.
Observa, luego ajusta
Revisa que está bloqueando el WAF, confirma que el tráfico legítimo no queda atrapado, y ajusta reglas o excepciones para el raro falso positivo. La seguridad es una política que refinas con el tiempo, no un interruptor que activas una sola vez, y el panel te da la visibilidad para hacerlo con seguridad.
Escenarios de ejemplo
Un sitio WordPress activa el WAF y aplica rate limit a /wp-login.php y /xmlrpc.php, cortando los bots de fuerza bruta en el edge para que el proceso PHP y la base de datos nunca sean tocados por el tráfico del ataque.
Una API JSON basada en contenedores se publica con el WAF activado y rate limits por ruta, de modo que los intentos de scraping e inyección se filtran antes de llegar al servicio, mientras el origin se bloquea para aceptar solo conexiones del edge.
Antes de un lanzamiento de alta visibilidad, un sitio se apoya en la absorción de DDoS del edge y la entrega cacheada para que un aumento repentino, ya sean visitantes reales o un ataque, se reparta por la red en lugar de colapsar el origin.
Preguntas frecuentes
Tengo que cambiar el código de mi aplicación para usar el WAF?
No. El firewall opera en el edge sobre el camino de la solicitud, así que inspecciona y bloquea el tráfico antes de que llegue a tu aplicación. Lo activas por dominio en el panel; tu código, framework y configuración de servidor se mantienen exactamente igual.
Qué tipos de ataques detiene realmente el WAF?
El conjunto de reglas administrado apunta a las clases de ataque web comunes, incluyendo inyección SQL, cross-site scripting, path traversal, remote file inclusión y command injection, además del volumen abusivo mediante rate limiting. Está diseñado para atrapar el sondeo automatizado y los intentos de explotación que conforman la mayor parte del tráfico web hostil.
Los atacantes pueden saltarse el WAF golpeando mi origin directamente?
Solo si dejas el origin expuesto. La configuración recomendada bloquea tu origin para aceptar conexiones solo desde el edge de cdn.com.tr y mantiene su IP real fuera del DNS público, de modo que el único camino hacia tu aplicación pasa por la capa de seguridad y los ataques directos al origin quedan cortados.
El WAF bloqueará visitantes legítimos por error?
Los falsos positivos son posibles con cualquier firewall, por eso el panel te permite ver que se está bloqueando y agregar excepciones para rutas o clientes específicos. El enfoque práctico es activar la protección, observar los resultados y ajustar las reglas para que el tráfico genuino fluya mientras los ataques se mantienen bloqueados.
En qué se diferencia la protección DDoS del WAF?
Resuelven problemas diferentes. El WAF inspecciona el contenido de solicitudes individuales en busca de patrones maliciosos, mientras que la protección DDoS se ocupa del volumen puro repartiendo y absorbiendo inundaciones a través del edge distribuido. Un ataque serio suele involucrar ambos, así que las dos capas trabajan juntas delante de tu origin.
Activar la seguridad ralentiza mi sitio?
El edge ya está en el camino de la solicitud para el caché, así que agregar la inspección del WAF allí no introduce un salto separado, y las respuestas cacheadas se siguen sirviendo rápido. En la práctica la misma capa que te protege también te acelera, ya que el tráfico bloqueado y cacheado nunca carga tu origin.