Web Application Firewalls in Ambassador Edge Stack

Ambassador Edge Stack comes fully equipped with a Web Application Firewall solution (commonly referred to as WAF) that is easy to set up and can be configured to help protect your web applications by preventing and mitigating many common attacks. To accomplish this, the Coraza Web Application Firewall library is used to check incoming requests against a user-defined configuration file containing rules and settings for the firewall to determine whether to allow or deny incoming requests.

Ambassador Edge Stack also has additional authentication features such as Filters and Rate Limiting. When Filters, Ratelimits, and WebApplicationFirewalls are all used at the same time, the order of operations is as follows and is not currently configurable.

1. WebApplicationFirewalls are always executed first
2. Filters are executed next (so long as any configured WebApplicationFirewalls did not already reject the request)
3. Lastly Ratelimits are executed (so long as any configured WebApplicationFirewalls and Filters did not already reject the request)

The Web Application Firewalls Resource

In Ambassador Edge Stack, the WebApplicationFirewall resource defines the configuration for an instance of the firewall.

• ambassadorSelector Configures how this resource is allowed to be watched/used by instances of Edge Stack
  • ambassadorIds: This optional field allows you to limit which instances of Ambassador Edge Stack can watch and use this resource. This allows for the separation of resources when running multiple instances of Ambassador Edge Stack in the same Kubernetes cluster. Additional documentation on configuring Ambassador IDs can be found here. By default, all instances of Ambassador Edge Stack will be able to watch and use this resource.
• firewallRules: Defines the rules to be used for the Web Application Firewall
  • sourceType: Identifies which method is being used to load the firewall rules. Value must be one of configMapRef;file;http. The value corresponds to the following fields for configuring the selected method.
  • configMapRef: Defines a reference to a ConfigMap in the Kubernetes cluster to load firewall rules from.
    • name: Name of the ConfigMap.
    • namespace: Namespace of the ConfigMap. It must be an RFC 1123 label. Valid values include: "example". Invalid values include: "example.com" - "." is an invalid character. The maximum allowed length is 63 characters and the regex pattern ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ is used for validation.
    • key: The key in the ConfigMap to pull the rules data from.
  • file: Location of a file on disk to load the firewall rules from. Example: "/ambassador/firewall/waf.conf.
  • http: Configuration for downloading firewall rules from the internet. The rules will only be downloaded once when the WebApplicationFirewall is loaded. The rules will then be cached in-memory until a restart of Ambassador Edge Stack occurs or the WebApplicationFirewall is modified.
  • url: URL to fetch firewall rules from. If the rules are unable to be downloaded/parsed from the provided url for whatever reason, the requests matched to this WebApplicationFirewall will be allowed/denied based on the configuration of the onError
• logging: Provides a way to configure additional logging in the Ambassador Edge Stack pods for the WebApplicationFirewall. This is in addition to the logging config that is available via the firewall configuration files. The following logs will always be output to the container logs when enabled.
  • onInterrupt: Controls logging behavior when the WebApplicationFirewall interrupts a request.
    • enabled: Configures whether the container should output logs.

status: This field is automatically set to reflect the status of the WebApplicationFirewall.

• conditions: Conditions describe the current conditions of the WebApplicationFirewall, known conditions are Accepted;Ready;Rejected.

The Web Application Firewalls Policy Resource

The WebApplicationFirewallPolicy resource controls which requests to match on and which WebApplicationFirewall configuration to use. This gives users total control over the firewall configuration and when it is executed on requests. It is possible to set up multiple different firewall configurations for specific requests or a single firewall configuration that is applied to all requests.

spec: Defines which requests to match on and which WebApplicationFirewall to be used against those requests.

• ambassadorSelector Configures how this resource is allowed to be watched/used by instances of Edge Stack
  • ambassadorIds: This optional field allows you to limit which instances of Ambassador Edge Stack can watch and use this resource. This allows for the separation of resources when running multiple instances of Ambassador Edge Stack in the same Kubernetes cluster. Additional documentation on configuring Ambassador IDs can be found here. By default, all instances of Ambassador Edge Stack will be able to watch and use this resource.
• rules: This object configures matching requests and executes WebApplicationFirewalls on them.
  • host: Host is a "glob-string" that matches on the :authority header of the incoming request. If not set, it will match on all incoming requests.
  • path: Path is a "glob-string" that matches on the request path. If not provided, then it will match on all incoming requests.
  • ifRequestHeader: Checks if exact or regular expression matches a value in a request header to determine if the WebApplicationFirewall is executed or not.
    • type: Specifies how to match against the value of the header. Allowed values are Exact;RegularExpression
    • name: Name of the HTTP Header to be matched. Name matching MUST be case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2)
    • value: Value of HTTP Header to be matched. If type is RegularExpression, then this must be a valid regex with a length of at least 1.
    • negate: Allows the match criteria to be negated or flipped.
  • wafRef: A reference to a WebApplicationFirewall to be applied against the request.
    • name: Identifies the WebApplicationFirewall
    • namespace: Namespace of the WebApplicationFirewall. This field is required. It must be a RFC 1123 label. Valid values include: "example". Invalid values include: "example.com" - "." is an invalid character. The maximum allowed length is 63 characters, and the regex pattern ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ is used for validation.
  • onError: provides a way to configure how requests are handled when a request matches the rule but there is a configuration or runtime error. By default, requests are allowed on error if this field is not configured. This covers runtime errors such as those caused by networking/request parsing as well as configuration errors such as if the WebApplicationFirewall that is referenced is misconfigured, cannot be found, or when its configuration cannot be loaded properly. Details about the errors can be found either in the WebApplicationFirewall status or container logs.
    • statusCode: The status code to return to downstream clients when an error occurs.
  • precedence: Allows forcing a precedence ordering on the rules. By default the rules are evaluated in the order they are in the WebApplicationFirewallPolicy.spec.rules field. However, multiple WebApplicationFirewallPolicys can be applied to a cluster. precedence can optionally be used to ensure that a specific ordering is enforced.

status: This field is automatically set to reflect the status of the WebApplicationFirewallPolicy.

• conditions: Conditions describe the current conditions of the WebApplicationFirewallPolicy, known conditions are Accepted;Ready;Rejected. If any rules have an error then the whole WebApplicationFirewallPolicyPolicy will be rejected.
• ruleStatuses:
  • index: Provides the zero-based index in the list of Rules to help identify the rule with an error.
  • host: host of the rule with the error
  • path: path of the rule with the error
  • conditions: Describe the current condition of this Rule. Known values are Accepted;Ready;Rejected. If any rules have an error then the whole WebApplicationFirewallPolicy will be rejected.

Quickstart

1. First, start by creating your firewall configuration. The example will download the firewall rules published by Ambassador Labs, but you are free to write your own or use the published rules as a reference.

2. Next create a WebApplicationFirewallPolicy to control which requests the firewall should run on. The example will run the firewall on all requests, but you can customize the policy to only run for specific requests.

3. Finally, send a request that will be blocked by the Web Application Firewall

Congratulations, you've successfully set up a Web Application Firewall to secure all requests coming into Ambassador Edge Stack.

Rules for Web Application Firewalls

Since the Coraza Web Application Firewall library Ambassador Edge Stack's Web Application Firewall implementation, the firewall rules configuration uses Coraza's Seclang syntax which is compatible with the OWASP Core Rule Set.

Ambassador Labs publishes and maintains a list of rules to be used with the Web Application Firewall that should be a good solution for most users and Coraza also provides their own ruleset based on the OWASP core rule set. It also satisifies PCI 6.6 compliance requirements.

Ambassador Labs rules differ from the OWASP Core ruleset in the following areas:

• WAF engine is enabled by default.
• A more comprehensive set of rules is enabled, including rules related to compliance with PCI DSS 6.5 and 12.1 requirements.

See Configuring Ambassador Edge Stack's Web Application Firewall rules for more information about installing Ambassador Labs rules.

For specific information about rule configuration, please refer to Coraza's Seclang documentation

Observability

To make using Ambassador Edge Stack's Web Application Firewall system easier and to enable automated workflows and alerts, there are three main methods of observability for Web Application Firewall behavior.

Logging

Ambassador Edge Stack will log information about requests approved and denied by any WebApplicationFirewalls along with the reason why the request was denied. You can configure the logging policies in the coraza rules configuration where logs are sent to and how much information is logged. Ambassador Labs' default ruleset sends the WAF logs to stdout so they show up in the container logs.

Metrics

Ambassador Edge Stack also outputs metrics about the Web Application Firewall, including the number of requests approved and denied, and performance information.

Grafana Dashboard

Ambassador Edge Stack provides a Grafana dashboard that can be imported to Grafana. In addition, the dashboard has pre-built panels that help visualize the metrics that are collected about Web Application Firewall activity. For more information about getting Prometheus and Grafana set up for gathering and visualizing metrics from Ambassador Edge Stack please refer to the Prometheus and Grafana documentation.