Un WAF y rate limiting sin un proveedor de edge aparte

Buena parte de lo que vende un proveedor dedicado de edge/WAF es, en el fondo, simplemente un reverse proxy haciendo bien su trabajo: revisar el request antes de que llegue a la app, no después. Railyard ya corre un proxy web frente a las apps de cada servidor — estas son las reglas que corren ahí, la mayoría configurables desde la propia pestaña Settings → Networking de la app, sin necesidad de una relación con un proveedor aparte.

Qué está en vivo hoy, sin condiciones

• Reglas de contraseña e IP. Pon una contraseña en un entorno de staging o una herramienta de admin en un solo campo; permite o niega direcciones específicas o rangos CIDR, con un 403 limpio para todos los demás.
• Redirecciones y rewrites — hasta 100 reglas, revisadas en orden, gana la primera coincidencia. 301/302/307/308 o un rewrite dentro de la misma app que conserva el query string. Desactivadas durante el modo de mantenimiento, para que una regla de redirección nunca enmascare una caída real.
• Headers de respuesta y CORS, hasta 50 reglas. Define un header, o elimina uno que tu app envió con -Name. Los preflights de CORS los responde el propio proxy y nunca llegan a la app — lo cual también significa que una app protegida con contraseña responde correctamente los preflights con 401 en vez de filtrar primero una respuesta CORS.
• Tu propio certificado SSL. Pega un cert y una key en formato PEM; Railyard verifica que la key coincida con el cert, que el cert sea válido ahora mismo, y que de verdad cubra una de las direcciones de la app — antes de guardar, no después de que algo se rompa. Se guarda cifrado, nunca se devuelve por la API, y deliberadamente se mantiene fuera de railyard.yml para que una clave privada nunca termine en git.
• Páginas de error y mantenimiento, servidas con el código de estado real (502/503/504) en vez de una falla genérica en blanco.

Qué es real pero todavía se está desplegando — dicho con honestidad

Tres funciones existen y son completamente configurables hoy, pero necesitan la propia imagen de proxy de edge de Railyard en un servidor, que todavía se está desplegando en toda la flota. Hasta que un servidor dado la tenga, la regla queda guardada pero no aplicada, y tanto la tarjeta de configuración como el log de despliegue lo dicen claramente — nada finge estar activo cuando no lo está:

• Web Application Firewall — cada request se verifica contra el OWASP Core Rule Set (inyección SQL, XSS, el resto de las categorías estándar del CRS) antes de llegar a la app. Tres modos: desactivado, detectar (se registra, nunca bloquea — el primer paso correcto para ver qué habría bloqueado antes de activar la aplicación real), y bloquear (aplicado de verdad, devuelve 403).
• Rate limiting — requests por minuto por IP de cliente, configurable para toda la app y por ruta (/login 10, /api/* 120). Superar el límite devuelve 429 con Retry-After. Un límite real que vale la pena conocer: los contadores viven en la memoria propia de cada servidor, así que una app repartida entre varios servidores recibe el límite por servidor, no un total global — y detrás de Cloudflare o de otro proxy, cada visitante se ve actualmente como la IP de ese proxy.
• Bloqueo por país — listas de permitir/bloquear por país de dos letras, UNK para direcciones sin país conocido, verificadas antes de los límites de tasa, las redirecciones o la propia app. Las direcciones privadas e internas siempre pasan sin importar la regla.

Por qué la honestidad importa aquí específicamente

Un WAF que en silencio no está aplicando nada es peor que no tener WAF, porque genera una confianza falsa — justo lo que esta categoría de función no se puede permitir hacer mal. Decir claramente “guardado pero aún no aplicado” en el propio producto, no solo en un changelog, es la salvaguarda real contra eso, y vale la pena decirlo también aquí en vez de dar la impresión de que todo lo anterior está en vivo por igual.

Referencia completa: Edge rules.