About Web Application Firewalls

WAFs protect your web apps by monitoring, filtering, and blocking potentially harmful HTTP traffic. You write a WAF policy by following a framework and ruleset. Then, you apply the WAF policy to the route for the apps that you want to protect. When Gloo Gateway receives an incoming request for that route (ingress traffic), the WAF intercepts and inspects the network packets and uses the rules that you set in the policy to determine access to the web app. The WAF policy also applies to any outgoing responses (egress traffic) along the route. This setup provides an additional layer of protection between your apps and end users.

In this section, you can learn about the following WAF topics:

ModSecurity rule sets

Gloo Gateway supports the popular Web Application Firewall framework and ruleset ModSecurity version 3.0.4. ModSecurity uses a simple rules language to interpret and process incoming HTTP traffic. Because it is open source, ModSecurity is a flexible, cross-platform solution that incorporates transparent security practices to protect apps against a range web attacks.

You have several options for using ModSecurity to write WAF policies:

  • Use publicly available rule sets that provide a generic set of detection rules to protect against the most common security threats. For example, the OWASP Core Rule Set is an open source project that protects apps against a wide range of attacks, including the “OWASP Top Ten.”
  • Write your own custom rules by following the ModSecurity rules language. For examples, see Configure WAF policies.

For more information, see the WAF API.

Understand the WAF API

The WAF filter supports a list of RuleSet objects which are loaded into the ModSecurity library. The Gloo Gateway API has a few conveniences built on top of that to allow easier access to the OWASP Core Rule Set (via the coreRuleSet field).

You can disable each rule set on a route independently of other rule sets. Rule sets are applied on top of each other in order. This order means that later rule sets overwrite any conflicting rules in previous rule sets. For more fine-grained control, you can add a custom rule_str, which is applied after any files of the rule sets.

Review the following RuleSet API example and explanation. For more information, see the WAF API.

  message ModSecurity {
    // Disable all rules on the current route
    bool disabled = 1;
    // Global rule sets for the current http connection manager
    repeated RuleSet rule_sets = 2;
    // Custom message to display when an intervention occurs
    string custom_intervention_message = 3;
}

message RuleSet {
    // string of rules which are added directly
    string rule_str = 1;
    // array of files to include
    repeated string files = 3;
}

Before you begin

  1. Follow the Get started guide to install Gloo Gateway, set up a gateway resource, and deploy the httpbin sample app.

  2. Get the external address of the gateway and save it in an environment variable.

      export INGRESS_GW_ADDRESS=$(kubectl get svc -n gloo-system gloo-proxy-http -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo $INGRESS_GW_ADDRESS  
  
      export INGRESS_GW_ADDRESS=$(kubectl get svc -n gloo-system gloo-proxy-http -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
echo $INGRESS_GW_ADDRESS
  
      kubectl port-forward deployment/gloo-proxy-http -n gloo-system 8080:8080

Set up a WAF filter

  1. Create a VirtualHostOption resource to define your WAF rules. The following example denies requests that have the User-Agent: scammer request header with a 403 HTTP response code. In addition, a custom message ModSecurity intervention! Custom message details here.. is configured.

      kubectl apply -n gloo-system -f- <<EOF
apiVersion: gateway.solo.io/v1
kind: VirtualHostOption
metadata:
  name: waf
  namespace: gloo-system
spec:
  options:
    waf:
      customInterventionMessage: 'ModSecurity intervention! Custom message details here..'
      ruleSets:
      - ruleStr: |
          # Turn rule engine on
          SecRuleEngine On
          SecRule REQUEST_HEADERS:User-Agent "scammer" "deny,status:403,id:107,phase:1,msg:'blocked scammer'"
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: http
    namespace: gloo-system
EOF

  2. Send a request to the httpbin app without the User-Agent: scammer request header. Verify that you get back a 200 HTTP response code.

      curl -I http://$INGRESS_GW_ADDRESS:8080/status/200 -H "host: www.example.com:8080" 
  
      curl -I localhost:8080/status/200 -H "host: www.example.com"

    Example output:

      HTTP/1.1 200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
date: Wed, 24 Apr 2024 21:04:14 GMT
x-envoy-upstream-service-time: 0
server: envoy
transfer-encoding: chunked

  3. Send another request to the httpbin app. This time, you include the User-Agent: scammer request header. Verify that you get back a 403 HTTP response code because the WAF policy denies requests when the User-Agent: scammer request header is detected. Check that you also see the custom WAF message that you configured in the VirtualHostOption resource.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/status/200 -H "host: www.example.com:8080" -H User-Agent:scammer 
  
      curl -vik localhost:8080/status/200 -H "host: www.example.com" -H User-Agent:scammer

    Example output:

       * Mark bundle as not supporting multiuse
   < HTTP/1.1 403 Forbidden
   HTTP/1.1 403 Forbidden
   < content-length: 55
   content-length: 55
   < content-type: text/plain
   content-type: text/plain
   < date: Wed, 24 Apr 2024 20:45:51 GMT
   date: Wed, 24 Apr 2024 20:45:51 GMT
   < server: envoy
   server: envoy

   ModSecurity intervention! Custom message details here..%

  4. Optional: Clean up the resources that you created.

      kubectl delete virtualhostoption waf -n gloo-system