En noviembre de 2020, AWS anunció el "AWS Network Firewall". Con tantos firewalls disponibles, es fácil perderse, así que escribí este post para poner orden.
Arrancamos comparando los firewalls de AWS con otros sistemas de defensa de red similares, los casos de uso de cada uno, los ataques de los que protegen y las reglas que usan para detectar amenazas.
Después cerramos con una historia que ilustra los casos de uso con los que probablemente te vas a encontrar a medida que tu aplicación escala y gana peso financiero.
Cuándo usar cada servicio de firewall de AWS
Empezamos desde abajo, por la infraestructura de menor nivel, y vamos subiendo, ya que en general así también conviene construir tus defensas.
Security Groups
Los Security Groups protegen las Elastic Network Interfaces, normalmente asociadas a instancias EC2, pero también a otros servicios como RDS o Lambda dentro de una VPC. Sirven, por ejemplo, para protegerse de conexiones SSH no autorizadas. Bloquean el acceso según puertos de origen y destino y rangos de IP. Conviene definir Security Groups, permitiendo el acceso mínimo necesario, cada vez que crees instancias.
Network ACLs
Las Network ACL protegen subredes; por ejemplo, frente a conexiones no autorizadas a una base de datos por parte del servidor backend desde cualquier ubicación. Al igual que los Security Groups, bloquean el acceso según puertos de origen y destino y rangos de IP. Conviene definir NACLs cuando dividas tus sistemas en subredes por función, algo que se recomienda hacer al definir tus capas. Con las NACLs, los subsistemas pueden acceder a otros según su función en la arquitectura, siempre y cuando las subredes se hayan definido en consecuencia.
Kubernetes Network Policies
Las Kubernetes Network Policies protegen aplicaciones en Elastic Kubernetes Service. Al igual que los Security Groups y las NACLs, bloquean el acceso según puertos de origen y destino y rangos de IP. Pero además pueden usar etiquetas de Kubernetes, lo que habilita un control de acceso funcional con un nivel de granularidad muy fino. Conviene definir estas Network Policies al crear cualquier conjunto de servicios de Kubernetes que vaya más allá de lo más básico.
Network Firewalls
Los Network Firewalls protegen todas las redes de una organización, por ejemplo frente a bots troyanos que extraen datos. Bloquean el acceso a partir de conjuntos de reglas estándar descargables. Al igual que los Security Groups y las NACLs, esos rulesets incluyen firmas definidas por puertos de origen y destino y rangos de IP. Además, pueden usar inspección profunda de paquetes y bloquear según dominios, URLs y protocolos (siempre que TLS se termine antes del Network Firewall). Conviene sumar Network Firewalls cuando necesites políticas consistentes de Detección y Prevención de Intrusiones en toda la organización.
AWS Shield Standard
AWS Shield Standard protege aplicaciones web y APIs frente a DDOS. Bloquea el acceso según patrones de tráfico HTTP(S), incluidas la frecuencia y el origen de las invocaciones. Conviene activar AWS Shield Standard en cualquier aplicación web pública con relevancia para el negocio. (Es gratis y viene activado por defecto en algunos recursos).
AWS Shield Advanced
AWS Shield Advanced hace lo mismo que Standard, pero con más monitoreo, reembolso de los costos del ataque y, lo más importante, un equipo humano de operaciones especializado. Vale la pena considerar AWS Shield Advanced en cualquier aplicación web crítica para el negocio, evaluando el costo de Advanced frente a Standard.
Web Application Firewall
El Web Application Firewall (WAF) protege las aplicaciones web frente a Cross-Site Scripting, SQL Injection, Insecure Direct Object References y otros ataques de la lista OWASP. Detecta y bloquea el acceso a partir de firmas definidas por patrones en los headers o el cuerpo de una solicitud HTTP(s). Vale la pena considerar WAF como protección mientras corriges vulnerabilidades conocidas en la aplicación, o si usas aplicaciones vulnerables cuyo código está fuera de tu control, o si crees que tu código tiene vulnerabilidades mínimas pero quieres una capa extra de protección por las dudas.
Instancias con Security Groups, subredes con NACLs, una organización multi-red con Network Firewall. AWS Shield contra DDOS y WAF protegen los puntos de entrada
Una historia de firewalls
Para mostrar cómo se van adoptando los distintos firewalls a medida que la aplicación crece, va una historia con casos de uso.
Pat acaba de empezar a desarrollar una aplicación web para su startup. Es un poco old-school, así que decide usar una sola instancia EC2 para una prueba de concepto sencilla. Configura un security group como firewall a nivel de instancia y permite el acceso solo por los puertos 80 y 443, para que lleguen las solicitudes HTTP/S; y por el puerto 22 desde el rango de IPs de su oficina, para administrarla por SSH. Con eso ya protege la instancia frente al acceso de atacantes por puertos distintos al 80 o 443, y bloquea cualquier acceso SSH desde direcciones IP no autorizadas.
Su prueba de concepto ya está protegida en esta etapa temprana contra muchos tipos de ataques, pero a medida que sume complejidad a la red y a la aplicación, y a medida que esta gane peso financiero, va a necesitar más defensas.
Para ir más allá de esa prueba de concepto simple y armar una aplicación n-tier robusta, monta una base de datos y separa los servidores de front-end y back-end. Cada capa queda en una subred distinta. Configura Network Access Control Lists (NACLs) como firewall de entrada a la subred, permitiendo que las solicitudes HTTP/S lleguen a la subred del frontend, que el frontend acceda al backend, que el backend acceda a la base de datos, y nada más.
La escalabilidad tiene sus límites; y aunque la aplicación aguante la carga, un ataque DDOS dispararía los costos. Por eso suma AWS Shield Standard, que es gratis. Es una protección DDOS adecuada. Mucho más adelante, cuando la aplicación haya escalado muchísimo y sea una fuente importante de ingresos, el costo de AWS Shield Advanced podría justificarse. El producto Advanced ofrece, sobre todo, un equipo de operaciones especializado de AWS: un recordatorio para el ámbito de la seguridad en general de que la amenaza son personas inteligentes que encuentran nuevas formas de atacarte, y por eso necesitas personas inteligentes que encuentren la forma correcta de defenderte en todo momento.
Pat migra la aplicación a Elastic Kubernetes Service para simplificar la orquestación y la gestión. Allí, la Kubernetes Network Policy define qué servicios de Kubernetes pueden comunicarse con otros, lo que habilita un control de acceso funcional más granular que el que se podría lograr con subredes.
Las pruebas de penetración de la aplicación revelan diversas vulnerabilidades de la lista OWASP, entre ellas Insecure Direct Object References, Cross Site Scripting y SQL Injection. Entonces, Pat y el equipo de desarrollo suman AWS Web Application Firewall, a la vez que priorizan los arreglos necesarios y el trabajo de seguridad a largo plazo dentro del equipo de desarrollo.
Finalmente llega el gran día: ¡Exit!, y una gran corporación adquiere la startup. Ahora la aplicación pasa a formar parte de un portfolio de aplicaciones más grande, y la red, de una infraestructura compleja, con múltiples VPCs y redes on-premises gestionadas por distintas unidades organizativas. Para mantener todo esto protegido, la corporación definió políticas de red consistentes en toda la organización. Se incorpora AWS Network Firewall para restringir el acceso mediante rulesets defensivos estándar definidos por puertos, direcciones IP, dominios, URLs y protocolos. Esto no solo protege contra los mismos ataques que los Security Groups y las Network ACLs, sino que además detecta y previene la intrusión de bots troyanos o hackers humanos que ejecutan código en la red y corrompen o extraen datos.
Las grandes organizaciones necesitan un enfoque centralizado para gestionar sus recursos y políticas: un sistema es tan fuerte como su eslabón más débil. Se incorpora AWS Firewall Manager para gestionar Network Firewalls, WAFs y otros sistemas, y mantener una protección consistente en toda la organización.
Espero que esto haya aclarado el panorama de los muchos firewalls de AWS. Si tienes preguntas, déjalas en los comentarios.
— —
Gracias a mi colega, el Dr. Artem Shchodro, por sus valiosos comentarios.