Automatización de pruebas del WAF con el simulador de WAF de Fastly

Staff Security Researcher

Equipo de Security Research de Fastly, Fastly

26 de junio de 2024

¿Te gustaría saber si la regla del firewall de aplicaciones web (WAF) que acabas de crear funcionará como es debido? ¿Cómo lo puedes averiguar? Después de crear una regla, ¿la activas y te olvidas? ¿Cómo sabes que seguirá funcionando al cabo de un tiempo? Imagínate que alguien de tu equipo modifica una regla: ¿cómo puedes saber si los cambios afectarán a tu capacidad de detección?

Aquí entra en juego el simulador de WAF de Fastly, una innovadora funcionalidad que te permite validar reglas en un entorno de simulación seguro y controlado. Una vez creada una regla del WAF, puedes usar el simulador para asegurarte de que funciona como debe sin necesidad de pasar de un sistema a otro. Con solo proporcionar un ejemplo de petición con su correspondiente respuesta, el simulador mostrará las señales y la respuesta del WAF esperadas.

En esta entrada, repasaremos cómo podemos probar reglas por medio del simulador del WAF, veremos las ventajas de hacer pruebas continuas, mostraremos cómo integrar el simulador del WAF en una canalización de CI/CD para automatizar las pruebas continuas y presentaremos un ejemplo que ilustra el uso de las pruebas con el fin de identificar cambios realizados en el WAF.

Realización de pruebas

Los clientes de Fastly pueden probar y validar reglas mediante el simulador del WAF, al que se accede desde la consola de gestión. Una vez creada una regla para un sitio, dirígete a Rules -> Simulator, introduce una petición y una respuesta de muestra y haz clic en Simulate. Cuando se haya completado la simulación, se mostrarán las señales y la respuesta del WAF en la salida de la simulación.

A continuación puedes ver cómo probamos en la consola la regla de un sitio que vincula y etiqueta una petición con una ruta dentro de una lista de puntos de conexión de API de cuentas sensibles.

Tras confirmar que la regla funciona correctamente, podemos adaptar la configuración de la prueba para ir probando con regularidad, pero ya llegaremos a eso.

Ventajas de las pruebas continuas

Con el tiempo, las reglas del WAF pueden quedar obsoletas o acumular errores, con el potencial de provocar falsos positivos (y bloquear tráfico legítimo) o falsos negativos (y permitir el paso a tráfico malicioso). Además, cuando alguien que está al corriente de la configuración del WAF abandona la empresa, existe el riesgo de perder conocimiento sobre la misma y las razones que llevaron a crear ciertas reglas. Es más: muchas organizaciones están sujetas a normas de cumplimiento, y la realización de pruebas regulares puede ayudar a satisfacer dichas normas. La realización continua de pruebas no solo sirve para garantizar que las reglas funcionan como es debido; también facilita la transmisión de conocimiento, ayuda a satisfacer normas de cumplimiento y forja una mentalidad proactiva con respecto a la seguridad.

Integración del simulador del WAF en tu canalización de CI/CD

Una forma de establecer la realización continua de pruebas es mediante el uso de una canalización de CI/CD. Para mostrarlo en la práctica, hemos creado un repositorio de ejemplo que aloja código de Terraform para dos aplicaciones web que usan el WAF de última generación de Fastly (NGWAF), app1.example.com y app2.example.com. Hemos incluido las herramientas, escritas en Go, que servirán para facilitar la automatización de las pruebas mediante el simulador del WAF de Fastly. Más concretamente, hemos incorporado una canalización de CI/CD que utiliza flujos de acción de Github para ejecutar pruebas de cada cambio de código en la rama principal.

Configuración de pruebas

Las pruebas están escritas en formato yaml y se ubican en el directorio test/rules**.** Los archivos yaml son una forma estructurada de definir y organizar casos de pruebas. Cada archivo de pruebas contiene una lista de las mismas, y cada prueba contiene los campos siguientes:

name: (obligatorio) nombre identificativo único del caso de pruebas
site: (obligatorio) nombre identificativo del sitio en el NGWAF de Fastly que se someterá a la prueba
rule_id: (opcional) identificador de la regla que se someterá a la prueba
description: (opcional) información sobre las comprobaciones que realiza la prueba
type: (opcional) positivo verdadero, falso negativo, falso positivo o negativo verdadero
request: (obligatorio) petición HTTP que se enviará durante la prueba
response: (obligatorio) respuesta esperada de la prueba
expect: (obligatorio) explicación del resultado esperado de la prueba
- waf_response: código de respuesta esperado del WAF
- signals: lista de datos de señales que deberá arrojar la prueba; cada señal contiene varios valores y debería omitirse si está vacía
  - type: identificador de la señal (es decir, el tipo de señal)
  - location: ubicación del valor de la señal (por ejemplo, QUERYSTRING o USERAGENT)
  - name: nombre asignado a la señal
  - value: valor específico que activó la señal
  - detector: identificador del detector que generó la señal
  - redaction: valor binario (1 o 0) que indica si el valor de la señal se ha ocultado

A continuación tenemos el ejemplo de un archivo de prueba:

tests:
 - name: sensitive account api test 001
   site: app1.example.com
   rule_id: 63d04576d3b2e101d4f1345d
   description: tags request with site.sensitive-account-api
   type: true positive
   request: |
     POST /api/v1/account/update_profile HTTP/1.1
     Host: app1.example.com
     Content-Type: application/x-www-form-urlencoded
     Accept: */*
     User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4)
     Content-Length: 8

     user=foo
   response: |
     HTTP/1.1 200 OK
   expect:
     waf_response: 200
     signals:
     - type: site.sensitive-account-api
       detector: 63e4404084fb8b01d40e3468

Cada archivo de la prueba se analiza y se envía al simulador del WAF. La secuencia de comandos compara la respuesta y las señales simuladas del WAF con las que la prueba define como esperables. Si falla alguna prueba, se muestran los detalles y se añade una unidad al cómputo de errores.

Primeros pasos

Haz lo siguiente:

Clona el repositorio https://github.com/fastly/waf-simulator-automation.
Crea una clave de API del NGWAF.
1. Inicia sesión en la consola de gestión del NGWAF, en https://dashboard.signalsciences.net/login.
2. En la pestaña My Profile, en el apartado API Access Tokens, selecciona Add API access token.
3. Introduce un nombre y selecciona Create API access token.

Configura tus credenciales del NGWAF de Fastly como variables del entorno.

export SIGSCI_EMAIL='your-email'
export SIGSCI_TOKEN='your-token'
export SIGSCI_CORP='your-corp-id'

Si aún no lo has hecho, instala Terraform siguiendo estos pasos.
Desde el directorio del proyecto, pasa al directorio terraform y ejecuta los siguientes comandos.
```
terraform init
terraform plan -out ngwaf.plan
terraform apply ngwaf.plan
```
Después de ejecutar «apply», toma nota de los valores de salida de sensitive_account_api_rule_id e invalid_host_header_rule_id.
Abre tests/rules/app1.example.com/sensitive-account-api.yaml y sustituye todas las veces que aparece 65a190f3e3148001dc71a5ca por el valor de sensitive_account_api_rule_id de la salida de terraform.
Abre el archivo tests/rules/app2.example.com/invalid-host-headers.yaml y sustituye todas las veces que aparece 65a190f40f6eb201dc0fdd81 por el valor de invalid_host_header_rule_id de la salida de terraform.
Una vez actualizados los archivos de la prueba, puedes realizar las pruebas en el simulador del WAF para comprobar si las reglas del mismo funcionan correctamente.
Si aún no lo has hecho, instala Go siguiendo estos pasos.
Vuelve al directorio raíz del proyecto y ejecuta el comando siguiente.

go run tests/main.go

Si no recibes ningún fallo, las pruebas se han saldado favorablemente. Si ves fallos, sírvete de los registros para solucionar los problemas.
Crea un nuevo repositorio en GitHub con los pasos descritos en esta página.
Sustituye la URL remota por tu nuevo repositorio.

git remote set-url origin https://github.com/yourusername/new-repository.git

Añade SIGSCI_EMAIL, SIGSCI_CORP y SIGSCI_TOKEN a los secretos de GitHub.
En el archivo de flujo de trabajo .github/workflows/tests.yaml, cambia el nombre de la rama de main-branch a main.
Añade los cambios y confírmalos.

git add .github/workflows/tests.yaml
git commit -m "update workflow"

A continuación, envía el código a tu nuevo repositorio usando el comando git push.

git push origin main

Después comprueba en tu repositorio de GitHub que el flujo de trabajo de la prueba se esté ejecutando.
En tu propio repositorio, encuentra la pestaña Actions, cerca de la parte superior de la página, que muestra una lista de los flujos de trabajo ejecutados relacionados con tu repositorio. Verás una lista de los flujos de trabajo ejecutados recientemente. Cada ejecución corresponde a una confirmación o a una acción que la inició (como un envío a la rama principal).
Si el flujo de trabajo ha funcionado correctamente, las reglas del WAF actúan como era de esperar.
Si hay fallos, sírvete de los registros para solucionar los problemas. Después de hacer las correcciones oportunas, confirma y envía los cambios de nuevo para iniciar el flujo de trabajo.

A partir de esta idea, también puedes configurar la integración de un webhook que inicie automáticamente el flujo de trabajo de una prueba cuando se modifique cualquier regla, lo cual resulta útil para garantizar que los cambios realizados a las reglas del WAF mediante la consola de gestión no perjudiquen tus detecciones.

Situación de ejemplo

Piensa en la regla del encabezado no válido del host que hemos creado para app2.example.com. Esta regla impide los ataques al encabezado del host HTTP, que se pueden llevar a cabo incluso en configuraciones de servidor web en apariencia seguras. Los valores de la siguiente lista se contrastarán con el encabezado del host y, si no hay ninguna coincidencia exacta, la regla bloqueará la petición y aplicará la señal site.invalid-host-header.

www.app2.example.com
app2.example.com

Creamos una serie de pruebas para garantizar que las peticiones se bloquean y etiquetan correctamente cuando incluyen un encabezado de host no válido.

Ahora, imaginemos una situación en la que alguien del equipo añade un nuevo subdominio, payments.app2.example.com, al WAF. Tras este cambio, los usuarios empezarán a obtener respuestas «406 Not Acceptable» cuando intenten acceder a payments.app2.example.com. Para resolver este problema rápidamente, alguien tiene que iniciar sesión en la consola de gestión del WAF y modificar la regla para que, en vez de bloquear las peticiones, las admita.

Este cambio inicia un flujo de trabajo de pruebas que termina en fallo porque las pruebas esperaban que la regla bloqueara las peticiones, pero resulta que las admite. En lugar de admitir todas las peticiones, esa persona tendría que haber añadido payments.app2.example.com a la lista de hosts permitidos. No obstante, debido a las pruebas, se envía una notificación de fallo a los miembros del equipo correspondientes, quienes pueden realizar los ajustes oportunos a la regla. Sin este círculo de comunicación, ese cambio podría haber pasado desapercibido y habría dado pie a la creencia incorrecta de que el WAF seguía bloqueando peticiones con encabezados de host no válidos.

Este ejemplo pone de relieve la importancia de utilizar pruebas para identificar cambios efectuados en las reglas del WAF, sobre todo en contextos de responsabilidad compartida. Así pues, realizar pruebas continuas es de gran importancia a la hora de detectar cambios que, de otro modo, podrían pasar desapercibidos.

Conclusión

En resumidas cuentas, hemos tratado los siguientes temas:

Las pruebas del WAF mediante el simulador del WAF
Las ventajas de las pruebas continuas
La integración del simulador del WAF en una canalización de CI/CD
Un ejemplo del uso de pruebas para identificar cambios realizados en el NGWAF

Las pruebas y la validación del comportamiento de las reglas son elementos clave para poder mantener cualquier WAF. La estrategia, teórica y práctica, de realizar pruebas continuas garantiza la eficacia sostenida de las reglas del WAF, ayuda a preservar el fundamento de las reglas, contribuye a cumplir con los requisitos de cumplimiento y forja una mentalidad proactiva con respecto a la seguridad.