ModSecurity Core Rule Set Docker Image

What is the Core Rule Set

The Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls. ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx.

Supported tags and respective Dockerfile links

• 3-nginx-YYYYMMDDHHMM, 3.3-nginx-YYYYMMDDHHMM, 3.3.5-nginx-YYYYMMDDHHMM, nginx (master/nginx/Dockerfile) – last stable ModSecurity v3 on Nginx 1.24 official stable base image, and latest stable Core Rule Set 3.3.5
• 3-apache-YYYYMMDDHHMM, 3.3-apache-YYYYMMDDHHMM, 3.3.5-apache-YYYYMMDDHHMM, apache (master/apache/Dockerfile) –last stable ModSecurity v2 on Apache 2.4.56 official stable base image, and latest stable Core Rule Set 3.3.5

⚠️ We changed tags to support production usage. Now, if you want to use the "rolling version", use the tag owasp/modsecurity-crs:nginx or owasp/modsecurity-crs:apache. If you need a stable long term image, use the one with the full CRS version, in addition to the build date in YYYYMMDDHHMM format, example owasp/modsecurity-crs:3.3.5-nginx-202209141209 or owasp/modsecurity-crs:3.3.5-apache-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 also build alpine linux variants of the base images, using the -alpine suffix. Examples:

• 3-nginx-alpine-YYYYMMDDHHMM, 3.3-nginx-alpine-YYYYMMDDHHMM, 3.3.5-nginx-alpine-YYYYMMDDHHMM, nginx-alpine (master/nginx/Dockerfile-alpine – last stable ModSecurity v3 on Nginx 1.24 official alpine stable base image, and latest stable Core Rule Set 3.3.5
• 3-apache-alpine-YYYYMMDDHHMM, 3.3-apache-alpine-YYYYMMDDHHMM, 3.3.5-apache-alpine-YYYYMMDDHHMM, apache-alpine (master/apache/Dockerfile-alpine) – last stable ModSecurity v2 on Apache 2.4.56 official alpine stable base image, and latest stable Core Rule Set 3.3.5

⚠️ We changed tags to support production usage. Now, if you want to use the "rolling version", use the tag owasp/modsecurity-crs:nginx-alpine or owasp/modsecurity-crs:apache-alpine. If you need a stable long term image, use the one with the full CRS version, in addition to the build date in YYYYMMDDHHMM format, example owasp/modsecurity-crs:3.3.5-nginx-alpine-202209141209 or owasp/modsecurity-crs:3.3.5-apache-alpine-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 create --use --platform linux/amd64,linux/i386,linux/arm64,linux/arm/v7
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 act 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.

To build a specific target for a single platform only (replace target and platform strings in the example with the your choices):

docker buildx bake -f docker-bake.hcl --set target.platforms=linux/amd64 nginx-alpine

CRS Versions

Hey, I used some specific git version with the containers? What happened?

You can achieve the same results just by getting any version you want, and using docker volumes. See this example:

git clone https://github.com/coreruleset/coreruleset.git myrules
cd myrules
git checkout ac2a0d1
docker run -p 80:80 -ti -e PARANOIA=4 -v rules:/opt/owasp-crs/rules:ro --rm owasp/modsecurity-crs

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.

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

TLS is configured by default on port 443. Note: The default configuration generates a self signed certificate on first run. To use your own certificates (recommended) COPY or mount (-v) your server.crt and server.key into /usr/local/apache2/conf/ or /etc/nginx/conf/. Remember to publish the HTTPS port when running the image.

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.

Overridden

CRS specific

Notes regarding reverse proxy

In order to more easily test drive the CRS ruleset, we include support for an technique called Reverse Proxy. Using this technique, you keep your pre-existing web server online at a non-standard host and port, and then configure the CRS container to accept public traffic. The CRS container then proxies the traffic to your pre-existing webserver. This way, you can test out CRS with any web server. Some notes:

• Proxy is not enabled by default. You'll need to pass the -e PROXY=1 environment variable to enable it.
• You'll want to configure your typical webserver to listen on your docker interface only (i.e. 172.17.0.1:81) so that public traffic doesn't reach it.
• Do not use 127.0.0.1 as an UPSTREAM address. The loopback interface inside the docker container is not the same interface as the one on docker host.
• Note that traffic coming through this proxy will look like it's coming from the wrong address. You may want to configure your pre-existing webserver to use the X-Forwarded-For HTTP header to populate the remote address field for traffic from the proxy.

ModSecurity CRS Tuning

There are two possible ways to pass ModSecurity CRS tuning rules to the container:

• To map the ModSecurity tuning file(s) via volumes into the container during the run command
• To copy the ModSecurity tuning file(s) into the created container and then start the container

Map ModSecurity tuning file via volume

docker run -dti --rm \
   -p 80:80 \
   -v /path/to/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf:/etc/modsecurity.d/owasp-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf \
   -v /path/to/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf:/etc/modsecurity.d/owasp-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf \
   owasp/modsecurity-crs:apache

Copy ModSecurity tuning file into created container

This example can be helpful when no volume mounts are possible (some CI pipelines).

docker create -ti --name modseccrs \
   -p 80:80 \
   owasp/modsecurity-crs:apache

docker cp /path/to/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf \
   modseccrs:/etc/modsecurity.d/owasp-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

docker start modseccrs

Full docker run example of possible setup

docker run -dti -p 80:80 --rm \
   -e PARANOIA=1 \
   -e EXECUTING_PARANOIA=2 \
   -e ENFORCE_BODYPROC_URLENCODED=1 \
   -e ANOMALY_INBOUND=10 \
   -e ANOMALY_OUTBOUND=5 \
   -e ALLOWED_METHODS="GET POST PUT" \
   -e ALLOWED_REQUEST_CONTENT_TYPE="text/xml|application/xml|text/plain" \
   -e ALLOWED_REQUEST_CONTENT_TYPE_CHARSET="utf-8|iso-8859-1" \
   -e ALLOWED_HTTP_VERSIONS="HTTP/1.1 HTTP/2 HTTP/2.0" \
   -e RESTRICTED_EXTENSIONS=".cmd/ .com/ .config/ .dll/" \
   -e RESTRICTED_HEADERS="/proxy/ /if/" \
   -e STATIC_EXTENSIONS="/.jpg/ /.jpeg/ /.png/ /.gif/" \
   -e MAX_NUM_ARGS=128 \
   -e ARG_NAME_LENGTH=50 \
   -e ARG_LENGTH=200 \
   -e TOTAL_ARG_LENGTH=6400 \
   -e MAX_FILE_SIZE=100000 \
   -e COMBINED_FILE_SIZES=1000000 \
   -e PROXY=1 \
   -e TIMEOUT=60 \
   -e LOGLEVEL=warn \
   -e ERRORLOG='/proc/self/fd/2' \
   -e USER=daemon \
   -e GROUP=daemon \
   -e SERVER_ADMIN=root@localhost \
   -e SERVER_NAME=localhost \
   -e PORT=80 \
   -e MODSEC_RULE_ENGINE=on \
   -e MODSEC_REQ_BODY_ACCESS=on \
   -e MODSEC_REQ_BODY_LIMIT=13107200 \
   -e MODSEC_REQ_BODY_NOFILES_LIMIT=131072 \
   -e MODSEC_RESP_BODY_ACCESS=on \
   -e MODSEC_RESP_BODY_LIMIT=524288 \
   -e MODSEC_PCRE_MATCH_LIMIT=1000 \
   -e MODSEC_PCRE_MATCH_LIMIT_RECURSION=1000 \
   -e VALIDATE_UTF8_ENCODING=1 \
   -e CRS_ENABLE_TEST_MARKER=1 \
   owasp/modsecurity-crs:apache