coreruleset / modsecurity-docker Goto Github PK

We currently use a custom log format named perlogjson for the performance log of Apache. This log format doesn't exist though. It was introduced in cfe220b but without a format definition.

Adding a docker HEALTHCHECK should simplify testing and also running in k8s and other orchestrators.

Hi,

We are using 3.0.4 image and we can not configure format logs in JSON :
SecAuditLogFormat JSON

{"error":"ModSecurity was not compiled with JSON support."}

Are you going to fix that ?

Thanks for the reply

I think that we should enable the module by default on our dockers.

Will create a new PR for this.

Both ssdeep and yajl libraries are now available in for all the versions we are using, so it doesn't make sense to build them.

Also, they haven't changed since quite some time, so we don't need to set some specific version.

So let's:

• remove ssdeep build step
• remove yajl build step
• add libfuzzy and libyajl packages for alpine and debian builds (for both stages)
• remove version argument
• remove the ssdeep binary. ModSecurity should use it as a library, and we save some bytes.

The issue:

I am using ModSecurity as a proxy in front of a file server. Everything works fine in DetectionOnly mode. But as soon as I set MODSEC_RULE_ENGINE=on, the file upload fails.

With the following log message:

2022/01/15 15:45:13 [error] 30#30: *1 Request body limit is marked to reject the request, client: 1.1.1.1, server: domain.com, request: "PUT /public.php/webdav/ZAP_2.11.1.dmg HTTP/1.1", host: "domain.com"
2022/01/15 15:45:13 [error] 30#30: *1 client intended to send too large body: 222978300 bytes, client: 1.1.1.1, server: domain.com, request: "PUT /public.php/webdav/ZAP_2.11.1.dmg HTTP/1.1", host: "domain.com"

The reason for this is, that if DetectionOnly is set, the default for SecRequestBodyLimitAction is ProcessPartial and if MODSEC_RULE_ENGINE=on is set the default is for SecRequestBodyLimitAction is Reject which causes the file upload to fail as seen above.

My request:

Make the SecRequestBodyLimitAction in the modsecurity-override.conf configurable via ENV variable allowing me to set it in the Docker or Docker-Compose file.

This would prevent me from needing to overwrite your override.conf 😇

In nginx official image, entrypoint runs each script in docker-entrypoint.d folder as initialization. For better compatilibity, isn't it better to move the current docker-entrypoint.sh in docker-entrypoint.d as another script?

The status call to TW servers is failing. This takes an unnecesary call, and startup times are longer.

We are switching this to Off by default.

This is coming from the modsecurity.conf recommended config:

# Improve the quality of ModSecurity by sharing information about your
# current ModSecurity version and dependencies versions.
# The following information will be shared: ModSecurity version,
# Web Server version, APR version, PCRE version, Lua version, Libxml2
# version, Anonymous unique id for host.
SecStatusEngine On

Lets add it to our override and turn it Off as default.

This fixes

    *) Security: 1-byte memory overwrite might occur during DNS server
       response processing if the "resolver" directive was used, allowing an
       attacker who is able to forge UDP packets from the DNS server to
       cause worker process crash or, potentially, arbitrary code execution
       (CVE-2021-23017).

In #126 we added support for setting the log format. This format is used for access log, error log and transfer log. It would be nice to have separate variables to control the log format for each of these logs independently.

This one comes from coreruleset/modsecurity-crs-docker#82.

While we are using the provided environment ACCESSLOG in

Additionally, we would like to provide an APACHE_LOGFORMAT variable so the access log format can be tuned.

I have been looking in to switching my Nginx that uss modsecurity and CRS over to this official image.

Using the Trivy docker image scanner we get the following summary for the nginx image used as base:

$ trivy nginx:1.17.9
2020-04-16T08:26:11.391+0200    INFO    Detecting Debian vulnerabilities...

nginx:1.17.9 (debian 10.3)
==========================
Total: 116 (UNKNOWN: 0, LOW: 19, MEDIUM: 82, HIGH: 13, CRITICAL: 2)

If we instead switch over and use the alpine version of the same image, we get the following:

$ trivy nginx:1.17.9-alpine
2020-04-16T08:28:03.984+0200    INFO    Detecting Alpine vulnerabilities...

nginx:1.17.9-alpine (alpine 3.10.4)
===================================
Total: 2 (UNKNOWN: 0, LOW: 0, MEDIUM: 2, HIGH: 0, CRITICAL: 0)

Not perfect, but much better.

As a nice side effect we also get a much smaller image:

nginx:1.17.9         size: 127MB
nginx:1.17.9-alpine  size: 19.7MB

Hi I'm getting an error while building the docker image from the Dockerfile given. Error details are as below.

Step 8/12 : RUN cd /opt/ModSecurity-apache/  &&  ./autogen.sh && ./configure && make && make install
 ---> Running in ba6c92078428
configure.ac:10: installing './compile'
configure.ac:8: installing './install-sh'
configure.ac:8: installing './missing'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
configure: looking for Apache module support via DSO through APXS
configure: found APXS at /usr/bin/apxs2
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
configure: looking for libmodsecurity
checking for msc_init in -lmodsecurity... no
configure: error: ModSecurity libraries not found!
The command '/bin/sh -c cd /opt/ModSecurity-apache/ &&     ./autogen.sh &&     ./configure &&     make &&     make install' returned a non-zero code: 1

Any idea why this error is coming and how to fix this?

Hi All,

when i compile mod_security with lua5.1-dev its failing to link to lua library, at the same time lua5.2-dev working without issues. I have a use-case where in, i need to use lua5.1. I tried few things but not able to figure out why things are breaks, can anyone help me out

mod_security version: 2.9.3
lua version: 5.1

Hello, I can't find a way to run the ModSecurity 3.3 NGINX Docker image

docker run --rm -it owasp/modsecurity-crs:3.3-nginx
2022/03/08 16:52:51 [emerg] 1#1: invalid parameter "${METRICS_ALLOW_FROM}" in /etc/nginx/includes/location_common.conf:10
nginx: [emerg] invalid parameter "${METRICS_ALLOW_FROM}" in /etc/nginx/includes/location_common.conf:10

Any tips?

This container is going to be run as a reverse proxy basically.

It should:

• SSL CERT: generate its own self-signed SSL cert to accept TLS traffic. User can replace with their own SSL cert after it is up and running if they want
• HIGHER VERSION: we should build Apache from source so we get 2.4.38 which has quite a bit more than 2.4.29, the latest version in Ubuntu:18.04 LTS
• DEFAULT SITE FILE: we should add in a default site file that sets up the correct ProxyPass directives. The IP address to pass the requests too will be a variable the user will provide on the command-line during docker run.
• DOCKERFILE SECURITY: we can probably put some limits on the container by dropping certain kernel privileges, restricting resource consumption, etc. There are some easy/quick commands to do this
• RANDOM: random other things I'm forgetting :)

Future Cool Stuff:

• We can make a helm chart for ModSecurity!
• This helm chart could be used to install ModSecurity firewall layer on any K8s cluster...going to be cool stuff

The owasp/modsecurity image, as of PR #38, allows to specify a service to be protected by the WAF via the BACKEND environment variable.

In Apache, this backend is served via mod_proxy's ProxyPass and ProxyPassReverse directives, and sets the X-Forwarded-Proto, X-Real-IP, X-Unique-ID request headers for serving the backend service.

In Nginx, we attempt to make the external behavior identical, i.e. also providing the request headers mentioned above to the backend service, which is done using several proxy_set_header directives in a location block having proxy_pass ${BACKEND}.

Unfortunately, for some reason, those (magic) request headers a removed from the request header before they reach the ${BACKEND} in Nginx, so the request looks slightly different. This should be fixed.

This is a follow-up issue on: #38

I'm working with colleagues on operating ModSecurity+CRS on modern infrastructure for some months, and we've seen a few challenges that make it hard to do sustainable software development.

What's wrong?

The industry needs a set of official images that are both trustworthy and easy to work with. Modern software development requires us to react quickly, hence we need sane defaults and convenient ways to override the default configuration. Container security is a growing concern, hence we must ensure the smallest attack surface possible -- without compromising development and operation convenience.

We need to:

• simplify and standardize the current development efforts (e.g. #24 et al.)
• separate Docker image development from CRS development (see owasp-modsecurity-crs)
• provide fully functional convenience configurations (e.g. vshn/modsecurity-docker)
• ensure we have automated builds to remove development burden from maintainers (related to #15, #22)
• ensure that we can react in a timely fashion on issues and PRs (e.g. SpiderLabs/owasp-modsecurity-crs#1345 (comment))

How can we help?

We have some capacity (and need) to work on consolidating the existing container image efforts. You can see our efforts in the related images on Docker Hub (e.g. vshn/modsecurity, vshn/modsecurity-crs).

My colleagues and I have extensive experience with crafting and running container images. If we could help maintain the Docker images in https://github.com/CRS-support (e.g. modsecurity-docker and modsecurity-crs-docker) that may free some of your resources for maintaining the CRS rules.

Can we help maintaining? Would that be possible?

Hi,

im trying to use this container to be a reverse proxy for multiple domains (Ex. x.com goes to 10.10.10.10 and y.com goes to 10.10.10.11)

From what i've seen there is only one value and no conditions applicable to the BACKEND variable.

I was wondering what i could to overcome this, i've created custom vhosts and modified the httpd.conf to use them, but im getting an HSTS error whereas with the BACKEND variable it was working fine but with only one domain.

Regards,
Daniel D.

Unfortunately since we use the apachectl -D FOREGROUND command to start Apache, the SIGTERM will only stop the apachectl process which won't relay it to the actual Apache process. This means that in a typical container environment, the SIGTERM is sent, apachectl is terminated but apache remains running in the background. Once the timeout (i.e. ca. 30s) is over, the apache process will be forcefully killed (by SIGKILL) which prevents any graceful shutdown.

We could solve this in an entrypoint script which traps the SIGTERM signal and then calls apachectl graceful-stop.

That's what the doc says.
The parser seems to agree:
https://github.com/SpiderLabs/ModSecurity/blob/4127c1bf52d2b30a5c2c3e641b8085fd9a720f43/src/parser/seclang-parser.yy#L1674

So does it make sense to set it in the config?

Per owasp-modsecurity/ModSecurity#2719, we might want to add a new version based on pcre2 only.

As compilation flags change, we need to see if this breaks something or not.

While building from this, I get the following error: Perhaps someone can help?

https://github.com/coreruleset/modsecurity-docker/blob/master/v3-nginx/Dockerfile

Step 25/33 : COPY --from=build /etc/modsecurity.d/unicode.mapping /etc/modsecurity.d/unicode.mapping
---> 2a4e88899044
Step 26/33 : COPY --from=build /etc/modsecurity.d/modsecurity.conf /etc/modsecurity.d/modsecurity.conf
---> 1d0cbff3141c
Step 27/33 : COPY src/etc/modsecurity.d/*.conf /etc/modsecurity.d/
COPY failed: no source files were specified

In the README.md only the default env values are mentioned. This is not very useful, as there is no mention of what values are accepted.

A list of all possible env values should be given.

See https://downloads.apache.org//httpd/CHANGES_2.4.48.

" owasp/modsecurity:3-nginx" when used with the caching directive, the whole thing stops to work.
Tried the default one:
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=edge-cache:10m inactive=60m max_size=1g use_temp_path=off;

Thought it was a root privilege problem so tried following folder which is owned by nginx:
proxy_cache_path /var/log/nginx levels=1:2 keys_zone=edge-cache:10m inactive=60m max_size=1g use_temp_path=off;
Still to no vail.

I suggest changing the owner-ship of /var/cache/nginx to the user->nginx.

Even tried to change the user from nginx to root in the configuration file but still didn't work.
#user nginx;
user root;
worker_processes auto;

The same problem occurs when using rate-limiting:
limit_req_zone $remote_addr zone=rate_limit1:12m rate=5r/m;

I think its is permission related issue.

nginx template has a wrong config in proxy_backend.conf.template, you need to change "proxy_set_header Upgrade $connection_upgrade;" to "proxy_set_header Upgrade $http_upgrade;".Otherwise the websockets can not be used.

Hi,

after pulling the most recent image starting the container is no longer possible due to an error with sed:

sed: cannot rename /etc/nginx/nginx.conf: Device or resource busy

This seems to have been introduced with #105.
In my setup I mount the nginx.conf from my host into the container - which is incompatible with the sed renaming (cf. https://github.com/coreruleset/modsecurity-docker/blob/master/v3-nginx/docker-entrypoint.d/91-update-resolver.sh @ line 12)

Minimal compose:

version: "3"
services:
  nginx:
    image: owasp/modsecurity:nginx
    restart: always
    volumes:
      - /host/nginx/nginx.conf:/etc/nginx/nginx.conf
    ports:
      - 80:80

I am actually unsure on whether this should be used differently - yet at least on the nginx dockerhub there are many references wrt. mounting the nginx.conf from the host (see https://hub.docker.com/_/nginx) into the container.

In https://github.com/nginxinc/docker-nginx/blob/master/entrypoint/30-tune-worker-processes.sh I found the following line

touch /etc/nginx/nginx.conf 2>/dev/null || { echo >&2 "$ME: error: can not modify /etc/nginx/nginx.conf (read-only file system?)"; exit 0; }

which they seem to have for this very reason.

Hi,

Our Nginx.conf is externalized from our Docker images.

This file is sometimes empty after multiple POD start simultaneously.

The issue seems to come from the following lines in the entrypoint.sh :
for FILE in ${FILES[*]}; do if [ -f $FILE ]; then envsubst "$ENV_VARIABLES" <$FILE | sponge $FILE fi done

An empty Stdout seems to be send to the sponge command that produce an empty nginx file.

Do you have already saw this behaviour on your environnements ?

There should be a single branch for all these Docker images. Usually this is the pattern most orgs do. See what Nginx does: https://github.com/nginxinc/docker-nginx

Because we don't have this right now, this repo looks very unmaintained, even though in reality it's not, it's just the latest commits are on a different branch than the one users land one when they first click.

Let me think of a folder structure and then submit to you all for approval / a first glance

@franbuehler @csanders-git

We were using tag owasp/modsecurity-crs:3.3.2-nginx to build our application image on top of it. It worked fine until image under that tag was updated in DockerHub and our SSL certificates suddenly stopped working. No changes were done on our side, we just rebuilt our image with the same source code and the same FROM tag. If we build from original image of the same underlying Nginx version - it works ok.

The issue is reproducible with current owasp/modsecurity-crs:3.3.2-nginx and also with latest owasp/modsecurity-crs:3.3.4-nginx-202209221209

There is no issue with image owasp/modsecurity-crs@sha256:4ab21fb9a6cab32fc04b15017b4dce68c6080ca6293726321f31077a7cf76468 which was under the owasp/modsecurity-crs:3.3.2-nginx tag at the time of our successful build 19.11.2021.

We attach SSL certificate from disk using ssl_certificate and ssl_certificate_key settings in server section of Nginx config. Actually those cert files are mapped to container as secrets in docker-compose.yml file.

Issue manifests itself as an SSL error when trying to open application page in Chrome browser, and missing SSL certificate, substituted somehow with self-signed one. See screenshots below:

Hi,

according to https://github.com/coreruleset/modsecurity-docker/blob/master/v3-nginx/Dockerfile#L1 the nginx-based modsecurity Docker image rests on nginx 1.20.2. According to https://nginx.org/en/download.html the latest stable version of nginx is 1.22.0.

Intially I came across this via openssl and a CVE that should be fixed in 1.1.1p. The openssl version in the latest modsecurity docker image is 1.1.1n. Should I bump the nginx version to 1.22.0 by myself (during the docker build)?

Best regards
Jörg Liebig

Hi, the Host header seems incorrect in reverse proxy mode, it always points to localhost independently from BACKEND value, so most website refuse this type of connection

I ran this command:
docker run -p 80:80 -e PROXY_SSL=on -e BACKEND=http://sitename imagename

Whenever I attempt to run the owasp/modsecurity:3.0.4 image, the only output I get from it is error opening output file: Read-only file system. All other containers I attempt to run work fine, including owasp/modsecurity:3.0.3.

Thank you for creating this docker image! I use it for many of my projects.

Beware that the used nginx version (1.20.2) is end of life. See: https://endoflife.date/nginx

New images published to DockerHub (3.0.5 / 3.0 / 3) are only published as arm images, breaking any dependent containers using amd64. Any chance of including the other architectures?

Looking at debug error logs, found:

Apache-Error: [file "apache2_util.c"] [line 273] [level 3] [client 172.25.0.1] ModSecurity: Multipart parsing error: Multipart: Failed to create file: /tmp/modsecurity/tmp/20210905-110250-YTSj2euvr-37s-pgdt6MeAAAAME-file-J0nssC [hostname "localhost"] [uri "/post"] [unique_id "YTSj2euvr-37s-pgdt6MeAAAAME"]

We need to add permissions to the www-data user, and we can just allow o+rwx on the /tmp/modsecurity/tmp directory, just in case.

Hi everyone, after switching from owasp/modsecurity:3-nginx to owasp/modsecurity:nginx modsecurity seems to be unable to log anything to audit log (configuration didn't change at all).

nginx.conf:

modsecurity on;
modsecurity_rules_file /etc/modsecurity.d/include.conf;

include.conf:

Include /etc/modsecurity.d/modsecurity.conf
Include /etc/modsecurity.d/crs-setup.conf
Include /etc/modsecurity.d/rules.d/*.conf

modsecurity.conf:

SecRuleEngine DetectionOnly
...
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogFormat JSON
SecAuditLogType Serial
SecAuditLog /var/log/modsecurity/modsec_audit.log
..

crs-setup.conf

SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"

I noticed that compared to owasp/modsecurity:3-nginx a lot of envs are set in owasp/modsecurity:nginx, e.g.

MODSEC_AUDIT_LOG=/dev/stdout
MODSEC_AUDIT_LOG_FORMAT=JSON
MODSEC_AUDIT_LOG_TYPE=Serial
MODSEC_AUDIT_STORAGE=/var/log/modsecurity/audit/
..

Would those be preferred over the defined values in the modsecurity.conf? Didn't find any information on this anywhere.
Yet even after unsetting all of those and making the environment the same as in owasp/modsecurity:3-nginx doesn't help.
Any input is much appreciated!

Please add Letsencrypt to Docker

Hi All,

not sure if this the right place to ask, apologies in advance

I am having trouble understanding where the below big list of env variable are being used inside container, I am aware what is the pupose of each of these env's but what i don't understand is that where is this being used in inside the image/container. Can someone help me out on this.

Branch: master

Our Docker images should also be posted Google Container Registry:

1. GCR does automated vuln analysis. For instance the current container image has 329 vulns, with 5 of them being pretty serious: https://gcr.io/crs-support/modsecurity-docker/v3/apache-apache

2. GCR can be secured with 2FA by the admins, which for some reason Docker Hub does not have

3. For the base image, we can you GCP Managed Based Images, which are pretty hardened / secured: https://cloud.google.com/container-registry/docs/managed-base-images

4. We can link GCR to Github in a variety of ways, such that when new code is pushed to Github, if it has a tag on it it can kick off a build of the image in GCR. If we want can also send to Cloud Build for testing...

Do you consider moving the base docker images for docker and apache to 'unprivileged' images, i.e. images not running with root user by default ?
This could be achieved for nginx using a different base image or by changing the default permissions of some folders/files.

We should add a manual triggered workflow that runs against all architectures. As this build in particular takes a really long time to run, we should only do it selectively.

👉 Another option is to try and run it in parallel because we don't need to have the manifest generated in the run.

There is no variable to change that behavior right now.

There is a related issue in coreruleset/modsecurity-crs-docker#19 for building additional architectures. While we don't have the time to build from scratch a new architecture, we can leverage the fact that both nginx and apache base containers have already builds for different architectures.

We should build for:

• linux/amd64
• linux/arm/v8
• linux/arm/v7
• linux/i386

Others might come afterwards.

We should use https://dependabot.com/docker/ to update dependencies on base images, so we can speed up the process.

Hi, when running the nginx image on arm64 arch, I have to disable (delete) the CRS REQUEST-910-IP-REPUTATION rule to be able to start nginx, otherwise it fails with

nginx: [emerg] "modsecurity_rules_file" directive Rules error. File: /etc/modsecurity.d/owasp-crs/rules/REQUEST-910-IP-REPUTATION.conf. Line: 76. Column: 22. This version of ModSecurity was not compiled with GeoIP or MaxMind support.  in /etc/nginx/conf.d/modsecurity.conf:2

The amd64 arch doesn't have this problem.

I can see that libgeoip-dev is installed in the owasp/modsecurity:nginx image before building ModSecurity, so I don't understand why it fails. I have tried installing various packages (libgeoip1 libgeoip-dev geoip-database geoip-database-extra geoip-bin) into the container, but it doesn't help. Am I missing something? Could you please verify that ModSecurity gets built with GeoIP or MaxMind support on arm64?

Thanks so much for providing this image.

The nginx container does not properly reflect the REAL_IP_HEADER in the ERRORLOG file within property client_ip.

docker-compose.yml

environment:
   SET_REAL_IP_FROM: "0.0.0.0/0"
   REAL_IP_HEADER: "X-Forwarded-For"
   REAL_IP_RECURSIVE: "on"

waf.log (ERRORLOG)

[...] clientip: 192.168.44.2 

This is the internal IP of the public facing traefik container for SSL termination. The docker compose logs output formats the client ip properly in front of the error message.

With modsecurity-crs-apache and the following docker-compose it is working properly though.

docker-compose.yml

environment:
   REMOTEIP_INT_PROXY: "192.0.0.0/8"

nginx base is around 130MB in my docker builds, but modsecurity-docker jumps to > 500MB. Is this something that can be optimized? This also results in the CRS image to be > 500MB.