ALB WAF features

Work in progress: This page and the STACKIT Application Load Balancer Web Application Firewall (ALB WAF) features are currently under active development. Significant changes and improvements are planned. Configurations and feature availability may change.

This document details the core features and configurations available within the STACKIT Application Load Balancer Web Application Firewall (ALB WAF).

Feature overview & availability

The following table outlines which ALB WAF features are available and which are still being developed:

Feature	API	SDK	Terraform	Portal
ALB WAF base configuration	Available	Available	WIP	WIP
Managed rule sets	Available	WIP	WIP	WIP
Custom rule groups	Available	WIP	WIP	WIP

Base configuration

To use the ALB WAF, you must have an active STACKIT Application Load Balancer (ALB) configured. The ALB WAF protects your backend applications directly at the load balancer level. It inspects incoming Layer 7 traffic before the traffic reaches your target pools.

An ALB WAF configuration (waf_config) must be created with the API or SDK. Once created, you can attach it to your ALB listeners using our API, SDK, or Terraform. To do so, reference the configuration name within your listener setup block.

Managed rule sets

Managed rule sets are pre-configured collections of rules. They help safeguard your infrastructure. You do not need to create any rules manually.

Core ruleset

The OWASP Core Rule Set (CRS) is the first managed rule collection supported by the ALB WAF. It protects against vulnerable vectors highlighted in the OWASP Top 10. These vectors include SQL injection, cross-site scripting (XSS), and running malicious code remotely.

The ALB WAF offers control over individual rules inside this managed set. You can adjust the state of specific rules through the API:

• Enable: Actively inspect and apply the rule action against traffic.
• Disable: Bypasses the rule without logging it.
• Log only: Bypasses the rule while also logging it.

Custom rule groups

You can establish specialized rule groups using custom rule groups. Each group contains multiple custom rules. In the JSON config, these rules are structured as follows:

• Rule ID (auto-assigned): Each custom rule inside a group is automatically assigned an identifier. This identifier ranges from 1 to 99999.
• Behaviors: Dictates the action taken when a match happens:
  • Disruptive actions: Actions like deny halt the request processing path. They issue a strict 403 Forbidden status code response back to the client.
  • Logging: When log is set to true, a mandatory log_msg must be provided. This message is used to enrich downstream logs. This makes debugging easier for security teams.
• Severity levels: Traffic can be tagged with specific impact indicators (for example, severity: "CRITICAL"), based on rules.
• Conditions: A single criterion or multiple criteria evaluated sequentially:
  • Variables: Target specific request scopes (for example, REQUEST_HEADERS) and keys (for example, Host).
  • Transformations: Normalize input data prior to analysis (for example, lowercase or none).
  • Operators: Compare the transformed variable data against a string or pattern (for example, checking whether it @beginsWith an allowed value).

Execution priority: Evaluation order is important. The WAF checks conditions one by one. The first condition that matches an incoming request executes immediately.