DEV Community

Cover image for Protege tu aplicación web On-Premises con AWS WAF: Guía paso a paso
Cristhian Becerra
Cristhian Becerra

Posted on

Protege tu aplicación web On-Premises con AWS WAF: Guía paso a paso

#spanish #aws #networking #cybersecurity

TL;DR: Este artículo te guiará en la implementación de AWS WAF para tus aplicaciones web alojadas en servidores On-Premises. Mostraré paso a paso cómo crear los certificados SSL/TLS, desplegar una distribución de CloudFront protegida por WAF y configurar el enrutamiento DNS necesario para esta implementación, todo ello alineado con el pilar de Seguridad del AWS Well-Architected Framework. 🧱

Tabla de Contenidos:

Introducción

Si has oído hablar de AWS WAF, probablemente sepas que es un servicio de firewall de capa 7 que permite asociar un Web Application Firewall directamente a recursos de AWS como Application Load Balancer, API Gateway, CloudFront Distributions, entre otros. Sin embargo, no puede asociarse directamente a una instancia EC2, a direcciones IP específicas o a una interfaz de red ENI en particular; únicamente puede vincularse a determinados servicios de AWS.

Un día recibí la solicitud de un cliente que deseaba implementar AWS WAF para una aplicación web alojada en un servidor On-Premises expuesto mediante una dirección IP pública. El cliente aclaró que no planeaban migrar el servidor a la nube; el servidor permanecería On-Premises, pero necesitaban contar con la protección de WAF y querían saber si era posible hacerlo desde AWS. 🤔

Con un poco de creatividad, se me ocurrió una solución: desplegar una distribución de CloudFront protegida con AWS WAF, cuyo origen sería el servidor On-Premises. Tras generar algunos certificados SSL/TLS, modificar un par de registros DNS y ajustar ligeramente la configuración de la aplicación local, logré implementar esta solución con excelentes resultados y un cliente completamente satisfecho. 😎

En este artículo te explicaré por qué deberías implementar AWS WAF en tu aplicación web On-Premises, cómo lo hice yo y cómo podrías hacerlo tú.

Por qué implementar AWS WAF en una aplicación web On-Premises

Si tienes una aplicación web On-Premises y necesitas protegerla con un Web Application Firewall (WAF), pero no deseas desplegar y administrar manualmente una solución WAF local, una excelente alternativa es implementar AWS WAF.

AWS WAF es un servicio completamente gestionado por Amazon Web Services, lo que significa que tú solo necesitas definir qué reglas aplicar y a qué recurso proteger. El servicio incluye managed rules que analizan el tráfico en busca de patrones de vulnerabilidades comunes, y AWS se encarga de mantener y actualizar dichas reglas por ti. Además, puedes crear reglas personalizadas, ya sean stateful o stateless, permitir o bloquear conjuntos de direcciones IP, aplicar restricciones geográficas, crear reglas basadas en expresiones regulares (regex), entre muchas otras opciones. 🤩

Con AWS WAF, puedes ofrecer a tu aplicación web On-Premises la protección de un firewall moderno sin necesidad de aprovisionar ni administrar manualmente una infraestructura WAF local. Y si el tiempo es un factor crítico, la configuración de AWS WAF probablemente sea mucho más rápida que cualquier otra alternativa tradicional. 😏

Ya sea que busques fortalecer la seguridad de tus aplicaciones web o cumplir con requisitos de compliance, es importante que sepas cómo implementar AWS WAF en una aplicación web On-Premises.

Qué vas a implementar

Esta guía asume que cuentas con un servidor On-Premises que aloja una aplicación web expuesta en el puerto 443, con una dirección IP pública protegida por HTTPS mediante un certificado SSL/TLS, y accesible desde un dominio (por ejemplo, www) a través de un registro DNS tipo A.

Partiendo de este punto de inicio, realizaremos lo siguiente:

  • Crear dos certificados SSL/TLS: uno para configurar en CloudFront y otro para instalar en el servidor On-Premises.
  • Instalar el certificado SSL/TLS correspondiente en el servidor On-Premises.
  • Crear una distribución CloudFront, configurada con su certificado SSL/TLS correspondiente, cuyo origen será un dominio que apunte al servidor On-Premises.
  • Configurar un registro DNS tipo CNAME para dirigir todo el tráfico del dominio hacia CloudFront.
  • Configurar un registro DNS tipo A para dirigir el tráfico desde CloudFront hacia el servidor On-Premises.
  • Configurar la aplicación On-Premises para aceptar únicamente tráfico proveniente de CloudFront.

Al finalizar esta implementación, contaremos con una cadena de resolución y redirección similar al siguiente flujo:

  1. Dominio: www.midominio.com
  2. DNS de la distribución de CloudFront
  3. Distribución CloudFront protegida por AWS WAF
  4. Dominio: origen.midominio.com
  5. Dirección IP pública del servidor On-Premises

Architecture

Prerrequisitos

Para esta implementación de AWS WAF, se requiere contar con los siguientes prerrequisitos:

  • Acceso a una cuenta de AWS.
  • Permisos IAM en la cuenta de AWS para utilizar los servicios Amazon CloudFront, AWS WAF, Amazon Route 53 y AWS ACM.
  • Acceso administrativo al Authoritative DNS Provider (Cloudflare o Amazon Route 53).
  • Acceso a un servidor On-Premises que aloje una aplicación web expuesta en el puerto 443, con una dirección IP pública.
    • Acceso para la creación de certificados SSL/TLS emitidos por una Certificate Authority (CA) pública, por ejemplo, la misma CA que emitió el certificado actualmente instalado en el servidor On-Premises.
    • Permisos para instalar el certificado en el servidor On-Premises.
    • Permisos para editar la configuración de la aplicación On-Premises.

Pasos de Implementación

Las siguientes secciones ofrecen una guía paso a paso para la implementación de AWS WAF en un servidor On-Premises, mostrando cómo se integran cada uno de los componentes, tales como los certificados SSL/TLS de ACM y de una CA pública, los registros DNS de Amazon Route 53, la distribución de CloudFront y la ACL web de AWS WAF, con el fin de implementar WAF en nuestra aplicación web On-Premises y garantizar que todo el tráfico sea enrutado de forma segura a través de AWS.

Crea los certificados SSL/TLS

Crea e instala el certificado para el servidor On-Premises

Para iniciar con esta implementación, necesitamos crear un nuevo certificado para el servidor On-Premises. Como se mencionó anteriormente, se asume que la comunicación hacia tu servidor ya estaba protegida mediante HTTPS, utilizando un certificado SSL/TLS instalado previamente para el hostname principal, por ejemplo, www.midominio.com.

1. Siguiendo el mismo método que utilizaste originalmente para generar el certificado previo con una CA pública, adquiere ahora un certificado válido para origen.midominio.com, ya sea con la misma CA pública o con otra de tu preferencia.

2. Luego, realiza la instalación del nuevo certificado SSL/TLS en la misma ruta donde se encontraba el certificado previo. Asegúrate de que la instalación se haya completado correctamente.

3. Para validar que la instalación del certificado sea correcta, puedes utilizar herramientas en línea como sslshopper.com o sslchecker.com para verificar el hostname origen.midominio.com. El certificado debe ser válido para dicho hostname y no estar expirado.

Crea el certificado para CloudFront

1. En la consola de AWS, navega al servicio AWS Certificate Manager y haz clic en el botón Request a Certificate.

AWS Certificate Manager

2. En la sección Certificate Type, asegúrate de que Request a public certificate esté seleccionado y haz clic en Next.

Certificate type

3. En la sección Domain names, ingresa tu dominio principal, por ejemplo, www.midominio.com. En la sección Validation method, asegúrate de que DNS validation esté seleccionado y haz clic en Request.

Domain names

Nota: ¿viste la sección Allow export? Es una funcionalidad relativamente nueva en AWS, y permite exportar certificados públicos emitidos por Amazon, incluyendo su llave privada, para que puedas instalarlos donde desees, por ejemplo, en un servidor On-Premises. Es decir, en el paso anterior, en lugar de usar otra CA pública, también podríamos haber utilizado AWS Certificate Manager para obtener el certificado destinado a nuestro servidor On-Premises. 😮

4. El certificado ha sido creado, pero se encuentra en un estado de validación pendiente. Para que ACM pueda verificar que realmente somos los propietarios del dominio especificado en el certificado, debemos crear un registro CNAME en el Authoritative DNS Provider.

  • En mi caso, estoy utilizando Amazon Route 53 para gestionar mi dominio, por lo que simplemente puedo hacer clic en el botón Create records in Route 53.

  • Si gestionas tu dominio en otro Authoritative DNS Provider, entonces deberás crear manualmente el registro CNAME utilizando el CNAME name y el CNAME value que se detallan en la sección Domains.

Create records

5. Finalmente, el certificado de AWS Certificate Manager debería pasar del estado Pending validation al estado Issued. Con esto confirmamos que el certificado se ha emitido correctamente en ACM.

Certificates Issued Status

Crea la distribución de CloudFront

1. En la consola de AWS, navega al servicio Amazon CloudFront y haz clic en el botón Create a CloudFront distribution.

Amazon CloudFront

2. En la sección Distribution options, completa el campo Distribution name y, para este caso de uso, asegúrate de que el Distribution type seleccionado sea Single website or app.

3. En la sección Custom domain:

  • Si el dominio en cuestión está siendo gestionado por Amazon Route 53 dentro de la misma cuenta de AWS donde estás creando la distribución de CloudFront, añade el dominio y haz clic en Check Domain.
  • Si gestionas ese dominio en otro Authoritative DNS Provider o en Route 53 de otra cuenta AWS, no te preocupes, podrás añadir el custom domain en un paso posterior.

Distribution options

4. Haz clic en Next.

5. En la sección Origin type, dado que nuestro origen es un servidor On-Premises, selecciona Other.

6. En la sección Origin, especifica origen.midominio.com como Custom origin y deja vacío el campo Origin path.

Origin type

7. En la sección Settings:

  • En Origin settings, personaliza los parámetros si lo deseas o utiliza la configuración recomendada.
  • En Cache settings, selecciona Customize cache settings y, para Origin request policy, elige AllViewer. Si lo deseas, personaliza otros parámetros.

Settings

8. Haz clic en Next.

9. En la sección Enable Security, selecciona Enable security protections. Si aplica a tu caso de uso, activa SQL protection y Rate limiting. Esto creará una ACL web de AWS WAF con protección básica y la asociará a la distribución de CloudFront.

Web Application Firewall

10. Haz clic en Next.

11. Como se mencionó en el paso 3, si el dominio está gestionado por Route 53 en la misma cuenta de AWS y lo especificaste previamente, en la sección Get TLS certificate se intentará encontrar automáticamente un certificado de ACM válido para dicho dominio. En mi caso, se encontró exitosamente el certificado que creé anteriormente.

  • Si el dominio está siendo gestionado en otro Authoritative DNS Provider o en Route 53 de otra cuenta AWS, no te preocupes, podrás añadir el certificado TLS en un paso posterior.

TLS Certificate

12. Haz clic en Next.

13. Revisa los detalles de la distribución y haz clic en Create distribution.

14. La distribución de CloudFront comenzará a desplegarse. En la columna Last modified, podrás ver que se encuentra en estado Deploying.

Deploying distribution

15. Como se mencionó en los pasos 3 y 11, si gestionas tu dominio en otro Authoritative DNS Provider o en Route 53 de otra cuenta AWS, dirígete a la sección Settings y haz clic en Edit.

16. En la sección General, especifica tu dominio en Alternate domain name (CNAME) y selecciona el certificado de ACM creado previamente en Custom SSL certificate. Luego, haz clic en Save changes.

Edit settings

17. Una vez la distribución haya terminado de desplegarse, en Last modified podrás ver el timestamp completo de la última modificación. Si el Alternate domain name y el Custom SSL certificate están configurados correctamente, habrás completado exitosamente la creación y configuración de la distribución de CloudFront.

Deployed distribution

18. Copia el Distribution domain name.

Configura el enrutamiento DNS

En mi caso, estoy gestionando mi dominio con Amazon Route 53, pero tú puedes crear estos registros DNS en el Authoritative DNS Provider que estés utilizando.

Crea el registro CNAME

1. Si el dominio en cuestión está siendo gestionado por Amazon Route 53 dentro de la misma cuenta de AWS donde estás creando la distribución de CloudFront, aprovecha y crea un registro DNS de tipo Alias, apuntando tu dominio principal www.midominio.com hacia la distribución de CloudFront.

Alias record

2. Si el dominio está siendo gestionado en otro Authoritative DNS Provider o en Route 53 de otra cuenta AWS, crea un registro DNS de tipo CNAME, apuntando tu dominio principal www.midominio.com al Distribution domain name de CloudFront.

CNAME record

Crea el registro A

3. Crea un registro DNS de tipo A apuntando tu nuevo subdominio origen.midominio.com a la dirección IP pública de tu servidor On-Premises.

A record

Con esto, habrás completado la configuración DNS necesaria. Sin embargo, aún no hemos terminado: si intentas acceder ahora a tu servidor mediante www.midominio.com y origen.midominio.com, ambos intentos serán exitosos, pero hay un detalle importante — origen.midominio.com no está protegido por WAF y, por ende, sigue siendo vulnerable. Mitigaremos este riesgo en el siguiente paso.

¿Cómo puedes darte cuenta fácilmente de si www.midominio.com y origen.midominio.com están protegidos por WAF o no? Yo utilizo una extensión de Google Chrome llamada Wappalyzer, que permite identificar las tecnologías empleadas en cualquier sitio web. Por ejemplo, al probar mis dominios, Wappalyzer detectó que el dominio www utiliza Amazon CloudFront como CDN y Amazon Web Services como PaaS, mientras que el dominio origen no utiliza ninguno de estos servicios. Esto confirma que el tráfico hacia el dominio origen no pasa por CloudFront y, por lo tanto, no es inspeccionado por AWS WAF. ⚠️

Wappalyzer comparison

Restringe el acceso al servidor On-Premises

Ahora debemos restringir el acceso al servidor On-Premises de tal manera que solo el tráfico que pase por CloudFront —y que haya sido inspeccionado por AWS WAF— sea aceptado por el servidor.

Para ello, tenemos dos opciones:

  • Hacer que CloudFront envíe un encabezado HTTP personalizado adicional con un valor secreto al origen, y que este último solo acepte el tráfico que contenga dicho encabezado con el valor secreto correcto.
  • Configurar el firewall del servidor On-Premises para que únicamente acepte tráfico proveniente de las direcciones IP de CloudFront especificadas en el archivo ip-ranges.json.

Dado que la segunda opción potencialmente implicaría actualizar las reglas del firewall On-Premises cada vez que Amazon modifique el archivo ip-ranges.json, me inclino más por la primera alternativa, que de hecho es la opción recomendada por Amazon cuando se requiere restringir el acceso a un Application Load Balancer.

1. En la consola de AWS, selecciona la distribución de CloudFront. En la pestaña Origins, selecciona el origen configurado y haz clic en Edit.

Origins

2. En la sección Settings, dentro de Add custom header, haz clic en Add header y añade un encabezado HTTP personalizado. El valor de este encabezado debe ser secreto y no debe exponerse públicamente. Guarda los cambios.

Add custom header

Ahora CloudFront añadirá este encabezado HTTP en todas las solicitudes que envíe al origen.

3. Finalmente, configura el servidor web On-Premises para que acepte solicitudes únicamente si contienen el encabezado HTTP personalizado de CloudFront con el valor secreto correcto.

Con esto hemos completado la implementación de AWS WAF para una aplicación web On-Premises mediante CloudFront, restringiendo el acceso por otros medios y garantizando que todo el tráfico hacia el servidor On-Premises sea inspeccionado de forma segura. 🔍

Estructura de costos

Los costos que deben considerarse en esta implementación son los siguientes:

  • Amazon CloudFront (distribución, Price Class “Use all edge locations (best performance)”)
    • Costo por salida de datos hacia Internet (primera capa): ~ USD 0,085 por GB para Estados Unidos/México/Canadá/Europa.
    • Costo por solicitudes HTTP/HTTPS: para USA se cita ~ USD 0,01 por cada 10 000 solicitudes (~ USD 0,000001 por solicitud) según guía reciente.
    • Nota: Hay un nivel gratuito de 1 TB de salida + 10 millones de solicitudes/mes para CloudFront.
  • AWS WAF (Web ACL asociada a CloudFront)
    • Costo de Web ACL: USD 5/mes por Web ACL.
    • Costo por regla dentro de la Web ACL: USD 1/mes por regla.
    • Costo por solicitudes inspeccionadas: USD 0,60 por cada millón de solicitudes.
  • Amazon Route 53 (Zona alojada + registros)
    • Costo por hosted zone pública: USD 0,50/mes para las primeras 25 hosted zones.
    • Costo adicional por registros (si se tienen más de 10 000 por zona): USD 0,0015/mes por registro adicional.
    • Costo de consultas DNS estándar: ~ USD 0,40 por millón de consultas (primer 1 B de consultas).
  • AWS Certificate Manager (ACM Certificate para FQDN)
    • Si es un certificado público gestionado por ACM, el uso con servicios integrados (como CloudFront) no tiene costo adicional.
    • Si fuese un certificado exportable o wildcard habría tarifas, pero en este caso un FQDN usando CloudFront → costo estimado = USD 0/mes.

Cabe mencionar que los precios indicados corresponden a octubre de 2025.💲

Estimación de costos mensual

Tomando como referencia mi implementación con los siguientes supuestos:

  • Región us-east-1
  • Datos salientes (egress) desde CloudFront: 1 000 GB/mes
  • Solicitudes al CloudFront: 10 millones de solicitudes/mes
  • Una Web ACL en AWS WAF, asociada a la distribución
  • Una hosted zone en Route 53 con un registro A + un registro CNAME
  • Un certificado ACM para un FQDN
  • No otras reglas avanzadas, no certificado wildcard, no consultas DNS masivas.

Cálculos:

  • CloudFront — datos de salida
    • 1 000 GB × USD 0,085/GB = USD 85,00/mes
  • CloudFront — solicitudes
    • 10 millones de solicitudes → (10 000 000 / 10 000) × USD 0,01 = 1 000 × USD 0,01 = USD 10,00/mes
  • WAF — Web ACL
    • USD 5,00/mes (una Web ACL)
  • WAF — reglas
    • Suponiendo solo 1 regla para simplificar → USD 1,00/mes
  • WAF — solicitudes inspeccionadas
    • 10 millones de solicitudes × (USD 0,60 por millón) = 10 × USD 0,60 = USD 6,00/mes
  • Route 53 — hosted zone
    • USD 0,50/mes (una zona pública)
  • Route 53 — registros
    • Solo 2 registros (A + CNAME) → ninguno adicional sobre el umbral → USD 0,00 extra
  • Route 53 — consultas DNS
    • Suponiendo un uso modesto (por ejemplo, ~100 000 consultas) → 0,1 millones × USD 0,40 = USD 0,04 (aproximadamente). Para simplicidad redondeamos a ≈ USD 0,05/mes
  • ACM — certificado público integrado
    • USD 0,00/mes

Total estimado:

Componente Costo estimado mensual (USD)
CloudFront — datos de salida 85,00
CloudFront — solicitudes 10,00
WAF — Web ACL 5,00
WAF — reglas 1,00
WAF — solicitudes inspeccionadas 6,00
Route 53 — hosted zone 0,50
Route 53 — registros 0,00
Route 53 — consultas DNS 0,05
ACM — certificado 0,00
Total estimado ~ USD 107,55

Lecciones aprendidas

En mi experiencia, al crear los certificados, especifica el FQDN exacto que utilizarás. No emplees wildcard a menos que realmente lo necesites, ya que los certificados wildcard suelen tener un costo significativamente mayor y, en la mayoría de los casos, no se aprovechan al 100%. 💰

La protección de WAF que implementé para CloudFront en esta guía incluye defensa frente a vulnerabilidades comunes como las del OWASP Top 10, inyecciones SQL (SQL Injection), limitación de tasa (Rate Limiting), y bloqueo de tráfico proveniente de direcciones IP maliciosas basadas en la inteligencia de amenazas de Amazon. Sin embargo, si lo consideras necesario —y de hecho es lo recomendado—, personaliza tu ACL web según tus requerimientos y añade las reglas adicionales que estimes convenientes para proteger tu servidor On-Premises.

Por favor, asegúrate de restringir el acceso al servidor On-Premises únicamente a través de CloudFront, ya que, de lo contrario, el servidor permanecerá expuesto, sin inspección ni protección por parte de WAF, y por tanto vulnerable a ataques por otras rutas de acceso. 🥲

Te recomiendo renovar el valor secreto del encabezado HTTP personalizado de CloudFront al menos una vez al año, como medida preventiva ante posibles filtraciones de seguridad. ⏱️

Conclusión

En conclusión, aunque tengamos una aplicación web alojada en un servidor On-Premises que no podamos migrar a la nube, de forma sencilla el servicio gestionado AWS WAF nos permite implementar el firewall que necesitamos en forma de una ACL web con las reglas adecuadas, ya sea utilizando reglas administradas por Amazon o creando reglas personalizadas según nuestro caso de uso.

De esta manera, podemos inspeccionar y filtrar todo el tráfico entrante hacia nuestro servidor On-Premises, garantizando que únicamente el tráfico analizado por AWS WAF sea procesado, fortaleciendo así la postura de seguridad de la aplicación. 🥳

Qué sigue

En la siguiente sección encontrarás los recursos y documentos oficiales de los servicios mencionados, junto con algunos puntos de interés relacionados con los temas tratados, por si deseas seguir aprendiendo o profundizar para evaluar si realmente aplican a tu caso de uso.

Te invito también a realizar esta implementación en tu propia cuenta de AWS. Cuéntame en los comentarios qué te pareció esta guía o si descubriste algo interesante durante tu implementación. ✍🏻

Recursos oficiales

Top comments (0)