Web application firewalls

Web application firewalls (WAF) are a type of reverse proxy technology that operate at Layer 7 of the open systems interconnection (OSI) stack. They are generally implemented to protect web applications and web services from malicious traffic or users. A WAF is usually deployed as a hardware or software component or as a cloud-native managed service and operates primarily as a reverse proxy, sometimes in a 1:1 configuration to backend systems and sometimes support multiple backend systems and multiple frontend IPs or host names.

WAFs are different from regular reverse proxies as they are designed to protect the backend application. They do not simply pass requests transparently, they generally have logic to inspect the requests, including the request URL, headers, source location, and body, for malicious or potentially malicious contents. Most WAFs implement a common ruleset, that is either defined by the manufacturer or a community, to identify common malicious attempts, such as SQL injection attempts, server-side request forgery (SSRF) or other types of behavior. WAFs can also implement metering, to limit a number of requests in a certain period, protect against distributed denial-of-service (DoS) attacks, and filter access to block IPs from certain geographic areas or sources. Each of these rules can be individually configured on or off, and the WAF can implement and apply hundreds or thousands of these rules to the protected application.

WAFs often have two modes that can be configured, including:

• Detect mode – Detect mode generally allows traffic to pass through the WAF transparently, but logs any requests that trigger a rule detection, so that the administrator can refer to this list, identify which might represent valid traffic, and potentially disable or adjust that rule to ensure valid requests are not blocked.
• Protect mode – Protect mode will actively block (returning an HTTP error or timeout) any request that triggers these rules.

Inbound traffic monitoring

Inbound traffic monitoring refers to the inspection and filtering of incoming requests to a system, whether from internal or public sources. While inbound traffic monitoring can refer to other methods or approaches beyond WAFs, these concepts are often closely linked.

Working with WAFs with ArcGIS systems

ArcGIS software relies on a wide variety of HTTP request types and responses, ranging from GET, POST and OPTIONS requests to large content bodies, unique headers, and various methods for token-based authentication. An overly conservative WAF is likely to present problems for client applications of an ArcGIS Enterprise deployment.

When implementing or using a WAF with an ArcGIS deployment, consider some of the following guidance:

• Start with Detect Mode with actual user traffic: This will help identify requests that are valid (representing real, useful user activity) but would be blocked by the WAF if it was configured for Protect mode.
• Check existing Esri guidance: Esri has prepared a set of suggested rule settings for the Azure WAF product, which can be used to identify other potentially problematic rules in other WAF products.
• Test, test, test: When enabling Protect mode, test a comprehensive set of workflows, from publishing to interacting with and downloading data, to identify which rules might be incorrectly configured. For example, test a long-running synchronous geoprocessing request to be sure that the default timeout of the system is not too short.
• Troubleshoot through 1:1 testing: when a request is blocked or returns an error through the WAF, first test the request using an HTTP client against the backend URL (behind the WAF) to verify that it is not a system issue, then look at tuning the WAF configuration to allow the request, if needed.

Esri provides a detailed example of WAF rules that may cause issues for ArcGIS deployments and should be disabled, which is available in the ArcGIS Trust Center: ArcGIS Enterprise Web Application Filter Rules (ArcGIS login required). This example includes specific rules from one specific WAF provider, but may provide an easier path towards configuring an organization’s specific WAF rule sets in the future. Also keep in mind that certain application functionality may be blocked by a WAF and this may be acceptable, if that application or service is never planned for use with a system, the fact that the traffic is blocked might be considered a non-issue.