Cortafuegos para aplicaciones web

Los cortafuegos de aplicación web (WAF) son un tipo de tecnología de proxy inverso que opera en la capa 7 de la pila de interconexión de sistemas abiertos (OSI). Por lo general, se implementan para proteger las aplicaciones y los servicios web del tráfico o los usuarios malintencionados. Un WAF se suele implementar como un componente de hardware o software o como un servicio en la nube nativo administrado y funciona principalmente como un proxy inverso, a veces en una configuración 1:1 para los sistemas backend y a veces admite varios sistemas backend y varias IP frontend o nombres de host.

Los WAF son diferentes de los proxies inversos normales, ya que se diseñan para proteger la aplicación backend. No se limitan a trasladar las solicitudes de forma transparente, sino que generalmente disponen de una lógica para inspeccionar las solicitudes, incluida la URL de la solicitud, los encabezados, la ubicación de origen y el cuerpo, en busca de contenidos maliciosos o potencialmente maliciosos. La mayoría de los WAF implementan un conjunto de reglas comunes, definido por el fabricante o una comunidad, para identificar los intentos maliciosos habituales, como los intentos de inyección SQL, la falsificación de peticiones del lado del servidor (SSRF) u otros tipos de comportamiento. Los WAF también pueden implementar la medición, para limitar un número de solicitudes en un periodo determinado, proteger contra ataques de denegación de servicio (DoS) distribuidos y filtrar el acceso para bloquear las IP de determinadas áreas geográficas u orígenes. Cada una de estas reglas puede activarse o desactivarse individualmente, y el WAF puede implementar y aplicar cientos o miles de estas reglas a la aplicación protegida.

Los WAF tienen con frecuencia dos modos que pueden configurarse, a saber:

• Modo de detección: por lo general, el modo de detección permite que el tráfico pase a través del WAF de forma transparente, pero registra cualquier solicitud que desencadene la detección de una regla, de forma que el administrador pueda consultar esta lista, identificar cuál podría representar tráfico válido y, potencialmente, deshabilitar o ajustar esa regla para garantizar que no se bloqueen las solicitudes válidas.
• Modo de protección: el modo de protección bloquea activamente (devolviendo un error HTTP o un tiempo de espera) cualquier solicitud que desencadene estas reglas.

Monitorización del tráfico entrante

La monitorización del tráfico entrante se refiere a la inspección y filtrado de las solicitudes entrantes a un sistema, ya sean de origen interno o público. Aunque la monitorización del tráfico entrante puede referirse a otros métodos o planteamientos más allá de los WAF, estos conceptos suelen estar estrechamente vinculados.

Trabajar con WAF para acceder a los sistemas ArcGIS

El software ArcGIS depende de una gran variedad de tipos de solicitudes y respuestas HTTP, desde solicitudes GET, POST y OPTIONS hasta grandes cuerpos de contenido, encabezados únicos y diversos métodos para la autenticación basada en tokens. Es probable que un WAF demasiado conservador presente problemas para las aplicaciones cliente de una implementación de ArcGIS Enterprise.

Cuando implemente o utilice un WAF con una implementación de ArcGIS, tenga en cuenta algunas de las siguientes orientaciones:

• Comience con el Modo de detección con tráfico de usuario real: así ayudará a identificar las peticiones que son válidas (que representan una actividad real y útil del usuario) pero que serían bloqueadas por el WAF si estuviera configurado para el modo de protección.
• Consulte la orientación existente de Esri: Esri ha preparado un conjunto de sugerencias de configuración de reglas para el producto Azure WAF, que puede utilizarse para identificar otras reglas potencialmente problemáticas en otros productos WAF.
• Probar, probar, probar: cuando habilite el modo de protección, pruebe un amplio conjunto de flujos de trabajo, desde la publicación hasta la interacción con los datos y su descarga, para identificar qué reglas podrían estar mal configuradas. Por ejemplo, pruebe una solicitud de geoprocesamiento síncrono de larga duración para asegurarse de que el tiempo de espera predeterminado del sistema no sea demasiado corto.
• Solución de problemas mediante pruebas 1:1: si una solicitud se bloquea o devuelve un error a través del WAF, primero pruebe la solicitud utilizando un cliente HTTP contra la URL del backend (detrás del WAF) para verificar que no se trate de un problema del sistema y, a continuación, estudie la posibilidad de ajustar la configuración del WAF para permitir la solicitud, si es necesario.

Esri proporciona un ejemplo detallado de la compatibilidad de las reglas WAF, basado en la oferta de Azure WAF, en el que se identifican las reglas o configuraciones que pueden causar problemas para las implementaciones de ArcGIS y que deberían deshabilitarse. Este documento está disponible en el ArcGIS Trust Center: Reglas de filtrado de aplicaciones web de ArcGIS Enterprise (se requiere un inicio de sesión en ArcGIS).

Este ejemplo contiene reglas específicas de un proveedor de WAF concreto, pero puede proporcionar una ruta más fácil hacia la configuración de los conjuntos de reglas WAF específicos de una organización en el futuro. Tenga en cuenta también que ciertas funcionalidades de las aplicaciones pueden ser bloqueadas por un WAF y esto puede ser aceptable, si nunca se planea utilizar esa aplicación o servicio con un sistema, el hecho de que el tráfico esté bloqueado podría considerarse un problema sin importancia. A medida que se completen más pruebas o validaciones del WAF, se hará referencia a más recursos en esta página; en este momento, el conjunto de reglas de Azure WAF es el único ejemplo detallado disponible, aunque puede informar sobre la configuración adecuada de otros productos u propuestas de WAF.