Señales (III): señales en el edge

En la primera parte de esta serie, presentamos las posibilidades de las señales personalizadas del WAF de última generación, poniendo como ejemplo dos casos de uso de bloqueos de comportamientos sospechosos o no deseados. En la segunda parte repasamos las señales del sistema, con las que los equipos de seguridad y DevOps pueden tener protegidas las API y aplicaciones web sin necesidad de configurar nada.

En la primera parte</u> de esta serie, presentamos las posibilidades de las señales personalizadas del WAF de última generación, poniendo como ejemplo dos casos de uso de bloqueos de comportamientos sospechosos o no deseados. En la segunda parte</u> repasamos las señales del sistema, con las que los equipos de seguridad y DevOps pueden tener protegidas las API y aplicaciones web sin necesidad de configurar nada.

En la tercera parte de esta serie de artículos sobre señales, analizaremos otros dos casos de uso (la detección de usuarios conocidos y el seguimiento de respuestas) y repasaremos cómo las señales pueden contribuir, desde esas dos áreas, a mejorar tu seguridad. También veremos cómo, al trasladar parte de la toma de decisiones sobre seguridad al edge de Fastly, estarás protegiendo más si cabe los sistemas inferiores mediante el uso de códigos de respuesta personalizados.

Identificación de usuarios conocidos

Se insiste mucho en la prevención de amenazas web, y tiene lógica: los ataques por inyección de código, la filtración de datos de clientes y el uso abusivo de API son amenazas constantes a la distribución de servicios en la web. 

La otra cara de la moneda, sin embargo, no recibe tanta atención cuando se modelan amenazas: hablamos de la reducción del ruido y la fatiga por alertas. Y es que, si el personal de seguridad tiene que analizar falsos positivos en vez de amenazas reales, será menos efectivo. 

De acuerdo con un informe de ESG</u>, el 23 % de los responsables de seguridad opina que la principal dificultad de su organización es seguir el ritmo del número de alertas. Una forma de prevenir el desgaste derivado de ello es el uso de un WAF para identificar automáticamente a usuarios conocidos. Si etiquetamos tráfico o peticiones con metadatos que los identifiquen como inofensivos, el personal tendrá más espacio para centrar sus esfuerzos en la mitigación de amenazas. Con el WAF de última generación de Fastly, puedes añadir una señal concreta a ese tipo de tráfico, aprovechando una dirección IP o cualquier otro rasgo identificativo de la petición HTTP. 

A continuación, te enseñamos cómo puedes configurar las reglas de tu sitio para que añadan una señal personalizada que identifique a un explorador a partir de una lista de direcciones IP. Una vez creada la lista, la regla del sitio es de lo más simple. Repasemos los pasos básicos en la IU: primero, creemos una lista que usaremos en la regla. En este ejemplo, conocemos la lista de direcciones IP que hay que identificar:

En la captura de pantalla anterior, hemos añadido tres direcciones IP ficticias que representan exploradores de vulnerabilidades conocidos. Una vez creada la lista, podemos adjuntar una señal a este tipo de tráfico creando una nueva regla de petición:

Mediante esta regla, dejamos pasar el tráfico de las direcciones IP que aparecen en la lista y etiquetamos la petición con la señal known-scanner cara al futuro. Sin esta regla, el WAF de última generación de Fastly analizaría el tráfico e impediría al explorador hacer su trabajo, lo cual crearía alertas innecesarias para el personal de seguridad. Que la señal known-scanner undefinedesté adjuntada a la petición también te permite confirmar y ver la actividad prevista del explorador. 

A continuación, repasaremos un procedimiento más complejo para realizar el seguimiento de ataques: observar tanto la carga útil entrante como el efecto que la petición tuvo (o no) en alguna aplicación inferior.

Seguimiento de respuestas

Los planteamientos básicos sobre la creación de modelos de amenazas a la seguridad web suelen seguir un guion simplista del posible atacante. En primer lugar, lleva una sudadera oscura con capucha (claro que sí) y, en segundo lugar, tiene una sola carga útil tan bien hecha que si se envía a la parte correcta de la aplicación (la URL) hará estragos en el sistema, seguramente mediante la filtración de datos, la denegación de servicio u otra forma de uso abusivo.

El guion sigue así: si hubiéramos tenido la forma perfecta de detectar este ataque (realizado mediante una petición HTTP maliciosa) y ponerle freno a tiempo, ahora estaríamos en un paraíso de seguridad. 

Este enfoque suele ser la primera capa de defensa de aplicaciones web, lo cual conduce a un modelo basado en firmas o amenazas conocidas. Así, no es de extrañar que las empresas terminen teniendo cientos (o incluso miles) de reglas en sus WAF antiguos. ¿Qué podemos hacer para mejorar la situación? 

Con las señales personalizadas, podemos extrapolar esta lógica y llevarla aún más lejos. En el WAF de última generación de Fastly, tanto la petición como la respuesta se usan para determinar si una señal de ataque o anomalía se deben añadir a un par de petición/respuesta. Por ejemplo, un buen número de nuestras señales de sistema (como la navegación forzada) se sirven de la información de la petición y la respuesta antes de etiquetar una petición con la señal.

Así, la protección no se limita solamente a ataques del tipo «fire and forget», sino que aporta más visibilidad e información sobre ataques más sofisticados. ¿Y si pudiéramos saber cómo se buscan puntos débiles en un punto de conexión de autenticación? Las API de autenticación suelen ser blanco de ataques dado que, por su naturaleza, tienen que estar muy expuestas para funcionar con eficacia. Una señal personalizada que realice un seguimiento de los fallos de autenticación (en este caso, HTTP 302) puede informarte de un número inusitado de fallos de inicio de sesión, que podría indicar un intento de ataque por relleno de credenciales. A continuación, te mostramos una plantilla básica para crear una regla con este objetivo:

En el ejemplo anterior, etiquetamos fallos de autenticación con una señal AuthFailure. No está claro que haya ocurrido algo de origen malicioso, pero si se producen muchos fallos cuando no se esperan, podemos estar ante un ataque. Este indicio nos puede conducir a añadir más controles de seguridad en otras partes de la aplicación que gestionan la autenticación y, así, detectar un posible ataque coordinado. La señal se puede plasmar en el siguiente gráfico con un panel personalizado:

En este ejemplo, hemos creado un panel de prueba para realizar el seguimiento de incidencias de esta señal durante la última hora. Vemos una mayor concentración de actividad entre las 10:30 y las 10:45, lo cual puede indicar un intento de ataque, sobre todo si tu nivel de referencia habitual es mucho más bajo.

Ampliar la protección al edge

Está muy bien realizar un seguimiento de las respuestas, ¿pero qué hay de las acciones coercitivas, como el bloqueo o la limitación de volumen? ¿Y si queremos realizar estas acciones antes? Ahora parece que hemos perdido la oportunidad, porque el agente ya ha completado el proceso y la respuesta vuelve al cliente. 

Es aquí donde puede ser de gran ayuda ampliar el perímetro de seguridad al edge. Las señales de la respuesta se pueden pasar al edge utilizando códigos de respuesta personalizados, lo que permite que la información adicional generada por el WAF de última generación se convierta en acciones coercitivas adicionales en Deliver (Varnish) de Fastly o entornos Compute. En el caso de los clientes de Varnish, es tan fácil como añadir lógica en torno a la variable beresp.status. Por otro lado, los clientes de Compute podrían hacer algo similar según las variables correspondientes de la respuesta, que dependen del lenguaje utilizado.

La variable beresp.status contiene el código de estado HTTP de la respuesta enviado por el origen. Si, por ejemplo, la regla de tu sitio devolviera 550 en vez de 401, tus decisiones de seguridad en el edge podrían ir desde el bloqueo hasta la limitación de volumen o el retraso del tráfico de red para el cliente, lo que ralentizaría al atacante y mantendría el tráfico y la carga lejos de tu origen durante un ataque. Puedes habilitar esta protección adicional haciendo que la regla bloquee y altere el código de respuesta así:

Una vez cambiada la regla en el WAF de última generación, se puede añadir más lógica de seguridad a Varnish para desencadenar acciones cuando el valor de beresp.status llegue a 550. Cuanto mayor sea la sofisticación y la envergadura de la amenaza, mayores serán las ventajas de imponer seguridad en el edge. 

El WAF de última generación de Fastly puede repartir las decisiones de seguridad (y la protección) en múltiples puntos de tu entorno, ya sea en el edge, dentro de las propias aplicaciones (despliegue en el núcleo) o como proxy inverso independiente (WAF en la nube). 

No te pierdas ninguna novedad

Ahora que hemos repasado más casos de uso de las señales personalizadas, esperamos que puedas aplicar estas ideas en tu organización. Si necesitas más ideas o ejemplos, ponte en contacto con tu Technical Account Manager, y no te pierdas las próximas novedades del blog. ¡Hasta pronto!

Si aún no cuentas con el WAF de última generación de Fastly, escríbenos</u> y nos pondremos en contacto contigo lo antes posible.