How to remediate – Web Application Firewall Detection

1. Introduction

The Web Application Firewall Detection vulnerability means that a web server is protected by a firewall designed to filter malicious traffic. This protection can interfere with automated security scans, giving incomplete results. All systems hosting public-facing websites are usually affected. A successful scan bypass could lead to confidential data exposure, service disruption or modification of website content.

2. Technical Explanation

Nessus identifies a web application firewall by observing the responses it receives from web queries. Error codes and messages indicate that a WAF is in place. This doesn’t mean the server *is* vulnerable, but it can affect scan accuracy. There isn’t an exploit path as such; the issue lies with scan reliability when a WAF is present.

• Root cause: The presence of a web application firewall alters standard HTTP responses.
• Exploit mechanism: An attacker would not directly exploit this condition, but could attempt to bypass the WAF to target underlying vulnerabilities.
• Scope: Any web server with an active web application firewall is affected.

3. Detection and Assessment

Confirming a WAF presence involves analysing responses from simple web requests. A thorough method uses automated scanning tools, but results may be incomplete.

• Quick checks: Use `curl -I ` and examine the headers for clues like ‘Server’ or unusual response codes.
• Scanning: Nessus identifies this condition as part of its standard web scan profile.

curl -I https://www.example.com

4. Solution / Remediation Steps

To get more accurate scan results, either whitelist Nessus or scan from an unprotected location. These steps aim to improve scan coverage, not fix a security flaw.

4.1 Preparation

• Backups are generally not needed for this step. No services need stopping.
• Dependencies: Ensure you have the IP address of your Nessus scanner. A roll back plan is to revert any firewall rules made.
• Change window needs may apply if modifying production firewalls; approval from network teams might be required.

4.2 Implementation

1. Step 1: Whitelist the Nessus server’s IP address in the web application firewall configuration.
2. Step 2: If whitelisting isn’t possible, scan the target website from a location *without* WAF protection (e.g., an internal network).

4.3 Config or Code Example

Before

# No specific rule for Nessus scanner IP address

After

# Allow traffic from Nessus Scanner IP Address
allow /32

4.4 Security Practices Relevant to This Vulnerability

Regular security scanning is important, but understanding the limitations of those scans is also key. Input validation and safe defaults help protect against attacks that bypass WAFs.

• Practice 2: Input validation prevents malicious data from reaching the application, even if a WAF is bypassed.

4.5 Automation (Optional)

If your WAF has an API, you could automate rule creation to whitelist Nessus scanners. This requires careful management of IP addresses and access control.

# Example using a hypothetical WAF API
waf_api add_rule --ip  --action allow --description "Allow Nessus Scanner"

5. Verification / Validation

Confirm the fix by re-running the scan and checking for more complete results. A simple service smoke test ensures basic website functionality remains intact.

• Post-fix check: Re-run the Nessus scan. Expect to see a greater number of identified vulnerabilities compared to the previous scan.
• Smoke test: Verify that key website functions (e.g., login, search) still work correctly.

# Example Nessus scan output - compare number of identified hosts/vulnerabilities before and after whitelisting

6. Preventive Measures and Monitoring

For example, update security baselines to include WAF configuration standards. Implement CI/CD pipeline checks for common web application vulnerabilities.

• Baselines: Update your security baseline or policy with recommended WAF settings (e.g., OWASP ModSecurity Core Rule Set).
• Pipelines: Add Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) to your CI/CD pipeline.

7. Risks, Side Effects, and Roll Back

Whitelisting Nessus could potentially allow an attacker using that IP address to bypass the WAF if compromised. Incorrectly configured WAF rules can disrupt website functionality.

• Risk or side effect 1: Whitelisted IP addresses must be carefully managed to prevent abuse.
• Risk or side effect 2: Overly permissive WAF rules could allow malicious traffic through.
• Roll back: Remove the Nessus scanner’s IP address from the WAF whitelist.

8. References and Resources

• Vendor advisory or bulletin: Check your WAF vendor’s documentation for guidance on scan compatibility.
• NVD or CVE entry: This condition is not typically assigned a CVE as it’s not a flaw in the server itself.
• Product or platform documentation relevant to the fix: Refer to your specific web application firewall’s configuration guide.