Best Practices for Enabling WAF Protection
Gateways play a crucial role in system architecture as they serve as the entry point connecting different networks, applications, and services. Web Application Firewall (WAF) is an essential security capability in the gateway domain, designed to identify and protect against malicious traffic patterns for websites or applications. By filtering and cleaning traffic, it ensures only normal, secure traffic reaches the server, preventing performance issues and security breaches caused by malicious intrusions, thereby safeguarding business and data security.
Introduction to Relevant Knowledge
ModSecurity
ModSecurity is an open-source, cross-platform Web Application Firewall (WAF) engine and one of the most widely used open-source WAF products. Its primary function is to analyze and filter incoming HTTP requests to detect and block potential attacks, including:
- SQL Injection (SQLi): Prevents SQL injection attacks
- Cross-Site Scripting (XSS): Blocks cross-site scripting attacks
- Local File Inclusion (LFI): Prevents attacks exploiting local file inclusion vulnerabilities
- Remote File Inclusion (RFI): Prevents attacks exploiting remote file inclusion vulnerabilities
- Remote Code Execution (RCE): Prevents attacks exploiting remote command execution vulnerabilities
- PHP Code Injection: Blocks PHP code injection
- HTTP Protocol Violations: Prevents malicious access that violates HTTP protocols
- HTTPoxy: Prevents attacks exploiting remote proxy infection vulnerabilities
- Shellshock: Prevents attacks exploiting Shellshock vulnerabilities
ModSecurity implements these features through a rule-based engine that defines patterns and behaviors to match and process.
Security Rule Language
ModSecurity Rule Language (also known as SecLang) is a domain-specific language based on regular expressions and pattern matching, used to describe and detect security events and attacks in web applications.
SecLang supports the following basic concepts and syntax structures:
- Transactions and Rules: Rules in SecLang are organized in transactions, which contain one or more rules. Rules define patterns to match and actions to take upon a match.
- Actions: Rules can include various actions such as logging, blocking requests, setting variables, and modifying requests.
- Conditions: Rules can use conditional statements to specify actions that should only be executed when certain conditions are met. Conditions can be based on various aspects of the request, such as request method, URI, headers, body, and IP address.
- Variables: SecLang supports built-in and user-defined variables for storing and manipulating request and response data. Variables can be used in rule matching, condition evaluation, and action execution.
- Operators: SecLang provides various operators for pattern matching, comparison, and logical operations, which are used to build rule conditions and actions.
SecLang allows users to write custom rules to specify how potential security issues in HTTP requests and responses should be detected and handled. Rules can define behaviors such as blocking malicious requests, filtering specific data, and intercepting attack types like SQL injection and cross-site scripting (XSS). By using SecLang, users can leverage ModSecurity’s powerful features to protect web applications from various security threats. For more information on SecLang syntax, refer to the SecLang Syntax Reference.
OWASP Core Rule Set
OWASP CRS (OWASP ModSecurity Core Rule Set) is a set of ModSecurity rules developed and maintained by the OWASP (Open Web Application Security Project) community. It provides predefined rules to protect web applications from a wide range of security threats and attacks. These rules can be modified to meet the specific security requirements of different web applications.
WAF Plugin Protection Principle
The WAF plugin is implemented based on the Higress Wasm Go SDK and Coraza, following the Phase specification defined by ModSecurity:
- Phase 1: Request headers
- Phase 2: Request body
- Phase 3: Response headers
- Phase 4: Response body
- Phase 5: Logging
The plugin includes OWASP CRS to provide basic protection features, supports custom protection rules, and offers route/domain-level granular protection.
Usage Example
First, prepare a K8s cluster and install Higress. Refer to the Higress Deployment Guide.
Deploy Services and Create Ingress
Apply the following resources in your K8s cluster to deploy the backend service and ingress:
apiVersion: apps/v1kind: Deploymentmetadata: name: httpbin-deployment labels: app: httpbin-deploymentspec: replicas: 1 selector: matchLabels: app: httpbin-deployment template: metadata: labels: app: httpbin-deployment spec: containers: - image: kennethreitz/httpbin imagePullPolicy: IfNotPresent name: httpbin-backend ports: - name: http containerPort: 80---apiVersion: v1kind: Servicemetadata: name: httpbin-service namespace: default labels: app: httpbin-servicespec: ports: - port: 8080 name: http protocol: TCP targetPort: 80 selector: app: httpbin-deployment type: ClusterIP---kind: PodapiVersion: v1metadata: name: foo-app labels: app: foospec: containers: - name: foo-app image: higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/http-echo:0.2.4-alpine args: - "-text=foo"---kind: ServiceapiVersion: v1metadata: name: foo-servicespec: selector: app: foo ports: # Default port used by the image - port: 5678---apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: httpbin-ingress namespace: defaultspec: ingressClassName: higress rules: - http: paths: - pathType: Prefix path: "/" backend: service: name: httpbin-service port: number: 8080---apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: echo-ingress namespace: defaultspec: ingressClassName: higress rules: - http: paths: - pathType: Prefix path: "/foo" backend: service: name: foo-service port: number: 5678
Access the two routes (/user-agent
routes to httpbin-service
, and /foo
routes to foo-service
):
Install WAF Plugin
Apply the following resources in your K8s cluster to deploy the WAF plugin:
apiVersion: extensions.higress.io/v1alpha1kind: WasmPluginmetadata: name: waf-go namespace: higress-systemspec: defaultConfig: useCRS: true secRules: - "SecRuleEngine On" - "SecDebugLogLevel 3" - "SecRule REQUEST_URI \"@streq /admin\" \"id:101,phase:1,t:lowercase,deny\"" matchRules: - ingress: - default/echo-ingress config: secRules: - "SecRuleEngine On" - "SecDebugLogLevel 3" - "SecAction \"id:102,phase:1,deny\"" url: oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/go-waf:1.0.1
The above configuration has the following meanings:
defaultConfig
contains global protection rules:useCRS=true
indicates that the OWASP CRS security rule set is loadedsecRules
contains three user-defined protection rules.
matchRules
contains route-level protection rules (domain-level is similar), refer to the Higress Plugin Documentation:ingress
specifies the routes to which the protection rules apply. Here, the route is set toecho-ingress
in thedefault
namespace.config
contains route-level protection rules with the same structure asdefaultConfig
. In this example, the OWASP CRS rule set is not loaded, and all requests are blocked.
Request Blocking Example
Custom Rule Protection Test
Test the following custom rule we defined in the global protection rules:
SecRule REQUEST_URI "@streq /admin" "id:101,phase:1,t:lowercase,deny"
This rule blocks all requests to the /admin
path. When you try to access this path, the request will be blocked by the WAF.
Overall Protection Capability Evaluation
GoTestWAF is an API and OWASP attack simulation tool that supports various API protocols including REST, GraphQL, gRPC, WebSockets, SOAP, and XMLRPC. It is designed to evaluate web application security solutions such as API security proxies, Web Application Firewalls (WAF), IPS, API gateways, and more.
The tool helps in assessing the effectiveness of your WAF configuration by simulating various attack vectors and measuring the protection level provided by your security setup.