Description
Description
Requests that are blocked in Phase 1 (Request Headers) do not appear in the audit log. The rules are evaluated correctly, and block calls as expected. However, because they do not appear in the audit log, I am blind to a significant portion of possible disruptive actions in the ModSecurity CRS.
The issue is not present in the ModSecurity image based on Apache HTTPD. That is why I am reporting the issue here.
Steps to reproduce
Start the ModSecurity CRS container based on NGINX.
$ docker run --rm -ti -p 8080:80 --name modsecurity-nginx \
docker.io/owasp/modsecurity-crs:v3.2-modsec3-nginx
In another terminal, tail the audit log.
$ docker exec -ti modsecurity-nginx tail -f /var/log/modsec_audit.log
In yet another terminal, first confirm that the audit log works by triggering a warning. Then, confirm that the audit log does not work when the request is blocked by a rule in phase:1.
# Empty Accept header triggers a warning; returns status code 200.
$ curl http://localhost:8080/ -v -H "Accept;"
# Content-Length with invalid content is blocked; returns status code 400.
$ curl http://localhost:8080/ -v -H "Content-Length: not a digit"
You can repeat the steps above with the Apache-based image, and see that the Apache-based image does not have this problem.
Environment
I tried to track down what software versions were used in the Docker image, which turned out to be quite difficult.
The exact Docker image that I tested is docker.io/owasp/modsecurity-crs:v3.2-modsec3-nginx. Its Dockerfile is located here, in the SpiderLabs/owasp-modsecurity-crs repository.
There, I can see that the image is based on docker.io/owasp/modsecurity:3.0-nginx. The Dockerfile of that image appears to be located here, in the CRS-support/modsecurity-docker repository.
This is where it gets hairy, because both ModSecurity and ModSecurity-nginx are checked out directly from the tip of the master branch. Additionally, the base image used for this Dockerfile is docker.io/library/nginx:1, which is a floating tag that gets updated whenever a new mainline NGINX version is pushed.
Using docker inspect, I was able to determine that the image was built on the 29th of May, 2019.
$ docker inspect docker.io/owasp/modsecurity-crs:v3.2-modsec3-nginx -f "{{ .Created }}"
2019-05-29T23:15:40.7504558Z
From there, I could check the commit logs of both projects to guess what version of the software is actually in the images.
ModSecurity-nginx has not had any development since January of this year, so I can quite confidently say that the actual version in the container image is d7101e13685e, the current tip of the master branch. That is itself a bit funny, because ModSecurity-nginx has not been officially released since the 20th of December, 2017, nearly two years ago.
ModSecurity itself is more actively developed, but based on the container image's timestamp, the actual version seems to be 6d266fae8549, which was the tip of the v3/master branch at the time.
Besides the versions being difficult to track down, this also means that the official ModSecurity image contains software versions that have not seen actual releases.
Finally, the NGINX version was fairy easily tracked down by looking at the embedded version info.
$ docker run --rm docker.io/owasp/modsecurity:3.0-nginx nginx -V
nginx version: nginx/1.15.12
...