Unos meses atrás hicimos una pequeña introducción al servicio de WAF donde, además de hablar superficialmente de que trata este servicio y algunas configuraciones básicas, también comentamos muy brevemente que uno de sus atractivos eran las reglas administradas por AWS.

Pues bien, hoy hablaremos de estas reglas administradas y cómo podemos activarlas en nuestras WAF ACL. Algunas nociones y configuraciones básicas no las explicaremos en esta ocasión para no alargarnos mucho, pero las puedes consultar en este otro post que publicamos. 

Bien, comenzamos …

Dentro de las reglas administradas por AWS nos encontramos con dos grupos principales:

• Paid rule groups: son reglas que además de los gastos normales del servicio, se cobrará una tarifa adicional por cada solicitud que evalúa utilizando un grupo de reglas de pago. AWS WAF también cobra una tarifa mensual por cada uso de un grupo de reglas de pago en una lista de control de acceso (ACL) web.
• Free rule groups: como su nombre indica, son grupos de reglas de uso libre que no tienen un coste adicional por ser usadas.

En esta ocasión nos vamos a centrar en Free rule groups, donde podemos encontrar los siguientes grupos de reglas:

• Admin protection: este grupo contiene reglas que permiten bloquear el acceso externo a las páginas administrativas expuestas. Esto puede resultar útil si ejecuta software de terceros o si quiere reducir el riesgo de que un actor malintencionado obtenga acceso administrativo a la aplicación.
• Amazon IP reputation list: son reglas basadas en la inteligencia de amenazas interna de Amazon. Es útil si quiere bloquear direcciones IP normalmente asociadas a bots u otras amenazas. El bloqueo de estas direcciones IP puede ayudar a mitigar los bots y a reducir el riesgo de que un actor malintencionado descubra una aplicación vulnerable.
• Anonymous IP list: comprende reglas para bloquear las solicitudes de los servicios que permiten ofuscar la identidad del espectador. Entre éstas se incluyen solicitudes de la VPN, proxies, nodos Tor y proveedores de alojamiento. Este grupo resulta útil si desea filtrar los lectores que podrían intentar ocultar su identidad en la aplicación. El bloqueo de las direcciones IP de estos servicios puede ayudar a mitigar los bots y la evasión de restricciones geográficas.
• Core rule set: este grupo contiene reglas que son generalmente aplicables a las aplicaciones web. Esto brinda protección contra la explotación de una amplia gama de vulnerabilidades, incluidas algunas de ellas de alto riesgo y frecuentes que se describen en las publicaciones de OWASP, como OWASP Top 10.
• Known bad inputs: este grupo abarca reglas para bloquear los patrones de solicitud que se conocen por no ser válidos y que están asociados a la explotación o el descubrimiento de vulnerabilidades. Esto puede ayudar a reducir el riesgo de que un actor malintencionado descubra una aplicación vulnerable.
• Linux operating system: son reglas que bloquean los patrones de solicitud asociados a la explotación de vulnerabilidades específicas de Linux, como los ataques de inclusión de archivos locales (LFI) específicos de Linux. Esto puede ayudar a prevenir ataques que exponen el contenido del archivo o ejecuten código al que el atacante no debería haber tenido acceso. Tienes que valorar este grupo de reglas si alguna parte de su aplicación se ejecuta en Linux. Se recomienda usar estas reglas en conjunto con POSIX operating system. 
• POSIX operating system: reglas que bloquean los patrones de solicitud asociados a la explotación de vulnerabilidades específicas de POSIX y de sistemas operativos similares a éste, como los ataques de inclusión de archivos locales (LFI). Esto puede ayudar a prevenir ataques que exponen el contenido del archivo o que ejecuten código al que el atacante no debería haber tenido acceso. Tienes que valorar este grupo de reglas si alguna parte de su aplicación se ejecuta en un sistema operativo POSIX o similar, entre los que se incluyen Linux, AIX, HP-UX, macOS, Solaris, FreeBSD y OpenBSD.
• PHP application: este grupo contiene reglas que bloquean los patrones de solicitud asociados a la explotación de vulnerabilidades específicas para el uso del lenguaje de programación PHP, como la inyección de funciones PHP poco seguras. Esto puede ayudar a evitar que se exploten las vulnerabilidades que permiten a un atacante ejecutar de forma remota código o comandos para los que no está autorizado.
• SQL database: abarca reglas para bloquear los patrones de solicitud asociados a la explotación de bases de datos SQL, como los ataques de inyección de código SQL. Este puede ayudar a evitar la inyección remota de consultas no autorizadas.
• Windows operating system: comprende reglas que bloquean los patrones de solicitud asociados a la explotación de vulnerabilidades específicas de Windows, como la ejecución remota de PowerShell comandos. Esto puede ayudar a evitar que se exploten las vulnerabilidades que permiten a un atacante ejecutar comandos no autorizados o ejecutar código malintencionado.
• WordPress application: contiene reglas que bloquean los patrones de solicitud asociados a la explotación de vulnerabilidades específicas de WordPress. Se recomienda usar estas reglas en conjunto con SQL database y PHP application.

NOTA: Puedes encontrar información más detallada sobre estas reglas en este enlace.

Bien, ya que conocemos las reglas que disponemos, vamos a activar alguna de ellas (las que utilizamos en nuestros clientes) dentro de nuestra WEB ACL.

Lo primero que tenemos que hacer es dirigirnos al servicio de WAF & Shield, y más concretamente, a la sección de Web ACLs, en la cual seleccionaremos donde queramos activar las reglas administradas.

Ahora nos vamos a la pestaña de Rules y añadiremos las reglas administradas en la opción que podemos observar en la siguiente imagen.

Esto nos llevará a una nueva pantalla donde aparecen varias opciones, pero a nosotros nos interesa AWS managed rule groups. Abrimos el desplegable y dentro del apartado de Free rule groups activaremos las reglas que necesitemos. En nuestro caso vamos a activar las siguientes:

• Amazon IP reputation list
• Anonymous IP list
• Core rule set

Aceptaremos las configuraciones en el botón naranja de la parte inferior.

En esta ventana nos permite elegir el orden de prioridad de las reglas. Esto se puede modificar más adelante, incluso cuando se añaden reglas nuevas, pero lo que deben tener en cuenta es que la prioridad es en orden descendente, es decir, se analizarán las reglas por orden de arriba hacia abajo. En nuestro caso como es un ejemplo, lo dejaremos en el orden que nos asigna automáticamente. Cuando tengamos el orden correctamente establecido guardamos.

Con esto ya tendríamos nuestras reglas activadas con las configuraciones por defecto que ofrece AWS.

Es cierto que muchas veces estas reglas pueden afectar al comportamiento, o bien en algún momento, nosotros cambiar el de alguna de las reglas de los grupos. Para ello, seleccionaremos la regla que queremos modificar y la editaremos, en este caso, lo haremos sobre las reglas de AWS-AWSManagedRulesCommonRuleSet.

En la ventana que se abre podemos modificar el comportamiento tanto global de todas las reglas como individual. Las opciones de las que disponemos son las siguientes:

• Override Allow: permite que la solicitud se reenvíe al recurso protegido de AWS para su procesamiento y respuesta. Esta es una acción de terminación.
• Override Block: bloquea la solicitud. Esta es una acción de terminación. De forma predeterminada, su recurso de AWS protegido responde con un 403 (Forbidden) código de estado HTTP.
• Override Count: cuenta la solicitud, pero no determina si permitirla o bloquearla. Esta es una acción que no termina.
• Override CAPTCHA y Override Challenge: usa rompecabezas de CAPTCHA y desafíos silenciosos para verificar que la solicitud no provenga de un bot, y AWS WAF usa tokens para rastrear las respuestas exitosas recientes de los clientes.

En este caso vamos a cambiar de forma global todas las acciones para que sea un CAPTCHA, y guardamos la regla en el botón naranja Save rule de la parte inferior.

Con esto ya tendríamos nuestra regla configurada para que muestre un desafío CAPTCHA para aquellas peticiones que sean detectadas por nuestras reglas.

Otra de las configuraciones que podemos realizar es que las reglas administradas no afecten a todas las peticiones web que analiza, si no, a los casos concretos que nosotros queramos. Para ello editaremos el grupo de reglas como en el caso anterior, pero nos centraremos en el apartado Scope of inspection. Seleccionamos la opción “Only inspect requests that match a scope-down statement”, permitiéndonos ésta añadir condiciones para poder delimitar qué peticiones queremos analizar y cuáles no.

Estos son unos ejemplos de las configuraciones personalizadas que se pueden realizar, pero si necesitas alguna configuración específica puedes ponerte en contacto con nosotros para que estudiemos tu caso y podamos ofrecerte una solución personalizada.