ModSecurity Docker Image

Note

⚠️ This repository has been archived.

We used to build owasp/modsecurity-crs via owasp/modsecurity (this repository), but it has become error prone and cumbersome. We have opted to merge the two repositories and will no longer build owasp/modescurity.

Please visit https://github.com/coreruleset/modsecurity-crs-docker.

Supported tags and respective Dockerfile links

• 3-YYYYMMDDHHMM, 3.0-YYYYMMDDHHMM, 3.0.8-YYYYMMDDHHMM, nginx (master/v3-nginx/Dockerfile) – last stable ModSecurity v3 on Nginx 1.22 official stable base image
• 2-YYYYMMDDHHMM, 2.9-YYYYMMDDHHMM, 2.9.6-YYYYMMDDHHMM, apache (master/v2-apache/Dockerfile) – last stable ModSecurity v2 on Apache 2.4 official stable base image

⚠️ We changed tags to support production usage. Now, if you want to use the "rolling version", use the tag owasp/modsecurity:nginx or owasp/modsecurity:apache. If you need a stable long term image, use the one with the build date in YYYYMMDDHHMM format, example owasp/modsecurity:3-202209141209 or owasp/modsecurity:2.9.6-alpine-202209141209 for example. You have been warned.

🆕 We added healthchecks to the images. Containers already return HTTP status code 200 when accessing the /healthz URI. When a container has a healthcheck specified, it has a health status in addition to its normal status. This status is initially starting. Whenever a health check passes, it becomes healthy (whatever state it was previously in). After a certain number of consecutive failures, it becomes unhealthy. See https://docs.docker.com/engine/reference/builder/#healthcheck for more information.

Supported variants

We have support for alpine linux variants of the base images. Just add -alpine and you will get it. Examples:

• 3-alpine-YYYYMMDDHHMM, 3.0-alpine-YYYYMMDDHHMM, 3.0.8-alpine-YYYYMMDDHHMM, nginx-alpine (master/v3-nginx/Dockerfile-alpine – last stable ModSecurity v3 on Nginx 1.22 Alpine official stable base image
• 2-alpine-YYYYMMDDHHMM, 2.9-alpine-YYYYMMDDHHMM, 2.9.6-alpine-YYYYMMDDHHMM, apache-alpine (master/v2-apache/Dockerfile-alpine) – last stable ModSecurity v2 on Apache 2.4 Alpine official stable base image

⚠️ We changed tags to support production usage. Now, if you want to use the "rolling version", use the tag owasp/modsecurity:nginx-alpine or owasp/modsecurity:apache-alpine. If you need a stable long term image, use the one with the build date in YYYYMMDDHHMM format, example owasp/modsecurity:3-202209141209-alpine or owasp/modsecurity:2.9.6-202209141209 for example. You have been warned.

Supported architectures

We added the docker buildx support to our docker builds so additional architectures are supported now. As we create our containers based on the official apache and nginx ones, we can only support the architectures they support.

There is a new file docker-bake.hcl used for this purpose. To build for new platforms, just use this example:

$ docker buildx use $(docker buildx create --platform linux/amd64,linux/arm64,linux/arm/v8)
$ docker buildx bake -f docker-bake.hcl

We require a version of buildx >= v0.9.1. Visit the official documentation for instructions on installing and upgrading buildx. You can check which version you have using:

docker buildx version
github.com/docker/buildx v0.9.1 ed00243a0ce2a0aee75311b06e32d33b44729689

If you want to see the targets of the build, use:

docker buildx bake -f ./docker-bake.hcl --print

We are building now for these architectures:

• linux/amd64
• linux/i386
• linux/arm64
• linux/arm/v7

You can find additional examples on how to use buildx in this repository's GitHub actions.

Quick reference

• Where to get help: the CRS-Support Docker Repo, the Core Rule Set Slack Channel (#coreruleset on owasp.slack.com), or Stack Overflow

• Where to file issues: the Core Rule Set Docker Repo

• Maintained By: The Core Rule Set Project maintainers

What is ModSecurity

ModSecurity is an open source, cross platform Web Application Firewall (WAF) engine for Apache, IIS and Nginx. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.

How to use this image

This image only contains ModSecurity built from the code provided on the ModSecurity Github Repo. THE CORE RULE SET IS NOT PROVIDED IN THIS IMAGE, but it should not be hard to extend. On the other hand, IF YOU WANT MODSECURITY WITH THE CORE RULE SET please visit the OWASP Core Rule Set (CRS) DockerHub Repo.

1. Create a Dockerfile in your project and copy your code into container.

   FROM owasp/modsecurity:apache
   COPY ./public-html/ .
   

2. run the commands to build and run the Docker image.

   $ docker build -t my-modsec .
   $ docker run -p 8080:80 my-modsec
   

3. Visit http://localhost:8080 and your page.

Nginx based images breaking change

If using the Nginx environment variables is not enough for your use case, you can mount your own nginx.conf file as the new template for generating the base config.

An example can be seen in the docker-compose file.

💬 What happens if I want to make changes in a different file, like /etc/nginx/conf.d/default.conf? You mount your local file, e.g. nginx/default.conf as the new template: /etc/nginx/templates/conf.d/default.conf.template. You can do this similarly with other files. Files in the templates directory will be copied and subdirectories will be preserved.

TLS/HTTPS

The TLS is configured by default on port 443. Note: The default configuration uses self signed certificates, to use your own certificates (recommended) COPY or mount (-v) your server.crt and server.key into /usr/local/apache2/conf/. Please remember you'll need to forward the HTTPS port.

$ docker build -t my-modsec .
$ docker run -p 8443:443 my-modsec

We use sane intermediate defaults taken from the Mozilla SSL config tool. Please check it and choose the best that match your needs.

You can use variables on nginx and apache to always redirect from http to https if needed (see APACHE_ALWAYS_TLS_REDIRECT and NGINX_ALWAYS_TLS_REDIRECT below).

Proxying

ModSecurity is often used as a reverse proxy. This allows one to use ModSecurity without modifying the webserver hosting the underlying application (and also protect web servers that modsecurity cannot currently embedd into). The proxy is set by default to true and the location is defined by BACKEND environment variable. The SSL is enabled by default.

$ docker build -t my-modsec . -f
$ docker run -p 8080:80 -e PROXY_SSL=on -e BACKEND=http://example.com my-modsec

ServerName

It is often convenient to set your servername. To do this simply use the SERVER_NAME environment variable passed to docker run. By default the servername provided is localhost.

$ docker build -t modsec .
$ docker run -p 8080:80 -e SERVER_NAME=myhost my-modsec

Apache ENV Variables

Note: Apache access and metric logs can be disabled by exporting the nologging=1 environment variable, or using ACCESSLOG=/dev/null and METRICSLOG=/dev/null.

Nginx ENV Variables

ModSecurity ENV Variables

All these variables impact in configuration directives in the modsecurity engine running inside the container. The reference manual has the extended documentation, and for your reference we list the specific directive we change when you modify the ENV variables for the container.