WAF

The following YAML configuration is for a basic WAF policy that denies requests if the User-Agent header is set to the value scammer. You can use this example to learn the basic parts of a WAF policy, as well as get ideas for how you might allow or deny traffic based on request headers.

apiVersion: security.policy.gloo.solo.io/v2
kind: WAFPolicy
metadata:
  name: basic-auth
  namespace: bookinfo
spec:
  applyToRoutes:
  - route:
      labels:
        route: ratings
  config:
    customInterventionMessage: custom-intervention-message
    customRuleSets:
    - ruleStr: |2
        SecRuleEngine On
        SecRule REQUEST_HEADERS:User-Agent "test([1-5])$" "deny,status:403,id:1,phase:1,msg:'blocked scammer'"
    disableCoreRuleSet: true
    priority: 0

Review the following table to understand this configuration. For more information, see the API docs.

You might want to allow access to a specific IP address or subnet range, such as an access control list (ACL) for internal services or to enforce a network boundary between different environments like staging and production. You can use a WAF filter with custom ModSecurity rules to set up an allowlist, such as with the following example to allow access from a local workstation.

1. Enable source IP preservation in the Istio ingress gateway that your Gloo virtual gateway selects. For more information, see the Istio docs. If applicable, make sure that the load balancer in front of your cluster environment permits source IP preservation. In this example, the source IP address of your local workstation must be preserved when the traffic from your workstation is forwarded by the load balancer to the gateway. This way, the gateway can see the original client IP as the remote address, and use this address in the WAF rules to allow the IP address.
2. Create a custom rule set to allow the IP address of your local workstation in the config section of your WAF policy.

   apiVersion: security.policy.gloo.solo.io/v2
   kind: WAFPolicy
   metadata:
     name: basic-auth
     namespace: bookinfo
   spec:
     applyToRoutes:
     - route:
         labels:
           route: ratings
     config:
       customRuleSets:
         - ruleStr: |2
             SecRuleEngine On
             SecRule REMOTE_ADDR "!@ipMatch 173.175.0.0/16" "phase:1,deny,status:403,id:1,msg:'block ip'"
   

Review the following table to understand this configuration. For details on the other settings, see the Header example tab or the API docs.

You can improve the performance of certain services by not sending the body of requests to the ModSecurity WAF ruleset. For example, calls from gRPC services can timeout if the gRPC call is a stream, because the WAF filter requires an end stream to be specified to finish evaluating intervention. To avoid this timeout, add the requestHeadersOnly: true and responseHeadersOnly: true entries to the WAF config, such as in the following example.

apiVersion: security.policy.gloo.solo.io/v2
kind: WAFPolicy
metadata:
  name: basic-auth
  namespace: bookinfo
spec:
  applyToRoutes:
  - route:
      labels:
        route: ratings
  config:
    requestHeadersOnly: true
    responseHeadersOnly: true

Gloo audit logging for WAF works differently than native ModSecurity, because Gloo is optimized for performance in Envoy and Kubernetes cloud environments. Instead of using the ModSecurity audit engine, Gloo exposes the audit logs as part of the Envoy gateway's access logging.

The following ModSecurity directives that configure the audit engine are ignored, even if set:

• SecAuditEngine. Instead, use the action property of the audit logging configuration to choose when to log.
• SecAuditLog
• SecAuditLogStorageDir
• SecAuditLogType

Although the way that audit logging works is different, you still can use the features that ModSecurity audit logging provides:

• SecAuditLogFormat
• SecAuditLogParts
• SecAuditLogRelevantStatus
• noauditlog, when the action is RELEVANT_ONLY

Review the following configuration file and table description to understand audit logging-specific settings. For details on the other settings, see the Header example tab.

apiVersion: security.policy.gloo.solo.io/v2
kind: WAFPolicy
metadata:
  name: basic-auth
  namespace: bookinfo
spec:
  applyToRoutes:
  - route:
      labels:
        route: ratings
  config:
    customInterventionMessage: custom-intervention-message
    customRuleSets:
    - ruleStr: |2
        SecRuleEngine On
        SecAuditLogFormat JSON
        SecRule REQUEST_HEADERS:User-Agent "test" "deny,status:403,id:107,phase:1,msg:'blocked scammer'"
    disableCoreRuleSet: true
    auditLogging:
      action: ALWAYS
      location: FILTER_STATE

Review the following table to understand this configuration. For more information, see the API docs.