Web Application Firewall

WARNING: The Web Application Firewall is in its end-of-life process. It is deprecated in GitLab 13.6, and planned for removal in GitLab 14.0.

A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws. It can be used to detect SQL injection, Cross-Site Scripting (XSS), Remote File Inclusion, Security Misconfigurations, and much more.

Overview

GitLab provides a WAF out of the box after Ingress is deployed. All you need to do is deploy your application along with a service and Ingress resource. In the GitLab Ingress deployment, the ModSecurity module is loaded into Ingress-NGINX by default and monitors the traffic to the applications which have an Ingress. The ModSecurity module runs with the OWASP Core Rule Set (CRS) by default. The OWASP CRS detects and logs a wide range of common attacks.

By default, the WAF is deployed in Detection-only mode and only logs attack attempts.

Requirements

The Web Application Firewall requires:

• Kubernetes

  To enable the WAF, you need:

  • Kubernetes 1.12+.
  • A load balancer. You can use NGINX-Ingress by deploying it to your Kubernetes cluster by either:
    • Using the nginx-ingress Helm chart.
    • Installing the Ingress GitLab Managed App with WAF enabled.

• Configured Kubernetes objects

  To use the WAF on an application, you need to deploy the following Kubernetes resources:

  • Deployment
  • Service
  • Ingress Resource

Quick start

If you are using GitLab.com, see the quick start guide for how to use the WAF with GitLab.com and a Kubernetes cluster on Google Kubernetes Engine (GKE).

If you are using a self-managed instance of GitLab, you must configure the Google OAuth2 OmniAuth Provider before you can configure a cluster on GKE. Once this is set up, you can follow the steps on the quick start guide to get started.

NOTE: This guide shows how the WAF can be deployed using Auto DevOps. The WAF is available by default to all applications no matter how they are deployed, as long as they are using Ingress.

Network firewall vs. Web Application Firewall

A network firewall or packet filter looks at traffic at the Network (L3) and Transport (L4) layers of the OSI Model, and denies packets from entry based on a set of rules regarding the network in general.

A Web Application Firewall operates at the Application (L7) layer of the OSI Model and can examine all the packets traveling to and from a specific application. A WAF can set more advanced rules around threat detection.

Features

ModSecurity is enabled with the OWASP Core Rule Set (CRS) by default. The OWASP CRS logs attempts to the following attacks:

• SQL Injection
• Cross-Site Scripting
• Local File Inclusion
• Remote File Inclusion
• Code Injection
• Session Fixation
• Scanner Detection
• Metadata/Error Leakages

It is good to have a basic knowledge of the following:

• Kubernetes
• Ingress
• ModSecurity
• OWASP Core Rule Set

Roadmap

You can find more information on the product direction of the WAF in Category Direction - Web Application Firewall.