theonemule / docker-waf

An NGINX and ModSecurity based Web Application Firewall for Docker

Securing Docker Containers with a Web Application Firewall (WAF) built on ModSecurity and NGINX

One can never be too paranoid about online security for a number of reasons. Containers are generally considered to be more secure by default that virtual machines because they substantially reduce the attack surface for a given application and its supporting infrastructure. This does not imply, however, that one should not be vigilant about secure containers. In addition to following secure practices for mitigating security risks with containers, those that use them should also use edge security to protect containers as well. Most applications that are being deployed into containers are in some way connected to the internet with ports exposed and so on. Traditionally, applications are secured with edge devices such as Unified Threat Management (UTM) that provides a suite of protection services including application protection. The nature of containers though makes using a UTM harder, because container loads are portable and elastic. Likewise, container loads are also being shifted to the cloud.

A Web Application Firewall (WAF) is a purpose-built firewall designed to protect against attacks common to web apps. One of the most widely used WAF’s is ModSecurity. Originally, it was written as a module for the Apache webserver, but it has since been ported to NGINX and IIS. ModSecurity protects against attacks by looking for:

• SQL Injection
• Insuring the content type matches the body data.
• Protection against malformed POST requests.
• HTTP Protocol Protection
• Real-time Blacklist Lookups
• HTTP Denial of Service Protections
• Generic Web Attack Protection
• Error Detection and Hiding

NGINX, though, is more than merely a web server. It can also act as a load balancer, reverse proxy, and do SSL offloading. Combine with ModSecurity, it has all the features to be a full-blown WAF. The NGINX/ModSecurity WAF has traditionally be deployed on VM’s and bare-metal servers, however it too can also be containerized. Using NGINX/ModSecurity in a container means that a container itself can be a WAF and carry with it all the advantages of containers. Likewise, it can scale and deploy with containers loads with on premise and cloud based solutions while VM’s and physical firewalls cannot. The Dockerfile and script herein builds NGINX and ModSecurity from their sources inside a container, then uploads three config files. These files are configured with the defaults settings on.

• nginx.conf – This is the NGINX configuration file that contains the directives for load balancing and reverse proxying.
  • Line 44 starts the section about enabling and disabling ModSecurity
  • Line 52 starts the section to configure the reverse proxy. For docker, this will usually be the name of the container that is being fronted by the app.
  • Line 53 contains the internal URL that nginx is proxying.
• modsecurity.conf – this contains the configuration for modsecurity and some configuration for the defaults and exclusion of the rules used by mod security. Most everything in the modsecurity.conf file can be left as is.
  • Line 230 starts the configuration of the rules.
  • The rules are downloaded and installed (/usr/local/nginx/conf/rules) when the container is built. Individual rules can be disabled or enabled, or they can all be enabled.
• crs-setup.conf – this configures the rules used by ModSecurity. The file has integrated documentation. Reading through this file explains what the settings are for. For more information about crs-setup.conf, visit OWASP's website.

Using the Dockerfile is simple. Change directories to the dockerfile, and build the image.

UPDATE: 6/8/2020

A new folder was added for ModSecurity 3.0

waf-2 is for ModSecurity 2 waf-3 is for ModSecurity 3

Everything else remails the same.

---

Multi-Stage Build:

docker build --tag mywaf .

Then run it.

docker run --name my-container-name -p 80:80 mywaf

This creates container.

Also, the image can be used with Docker Compose. The docker-compose.yml isa simple example that will deploy a simple node application along with the WAF. Change directories to the docker compose file, then run.

docker-compose up

Use with Kubernetes

It is possible to use the WAF with Kubernetes too. In short, you create a deployment and load balancer service with the WAF, then use the WAF to connect to your applicaiton running on a deployment with a a cluster IP service. Reference the kube.yml file in the code for specifics.

Then use kubectl to deploy the kube.yml file to your Kubernetes environment.

kubectl create -f kube.yml

docker-waf's Issues

can I pull it in docker?

just like pull cloudflared/cloudflared

WAF exited with code 127 - nginx not found

Hi, I'm trying to run demo environment with Your solution, but I got stuck because of the error:

waf_1  | /bin/sh: 1: nginx: not found
docker-waf_waf_1 exited with code 127

All I did to run was to rename WAF Dokerfile.single to Dockerfile and next to simply to up docker-compose.yml file.
It seems like nginx inside of WAF docker doesn't work properly.

Why not libModSec with the ModSecurity-nginx connector.

I notice that it is not using the ModSecurity-nginx connector yet. Is that any specific reason for that?

ModSecurity-nginx:
https://github.com/SpiderLabs/ModSecurity-nginx

Error build waf

When i try to build waf: docker-compose build waf the proccess ending:
configuring additional modules
adding module in /usr/src/modsecurity/nginx/modsecurity
./configure: error: no /usr/src/modsecurity/nginx/modsecurity/config was found
make: *** No rule to make target 'build', needed by 'default'. Stop.
make: *** No rule to make target 'install'. Stop.
ERROR: Service 'waf' failed to build: The command '/bin/sh -c chmod +x /build.multi.sh && /bin/bash -c "source /build.multi.sh"' returned a non-zero code: 2

ModSecurityEnabled on Left An Error

nginx: [emerg] unknown directive "ModSecurityEnabled" in /etc/nginx/nginx.conf:44

Anomaly detection does not triggered

I'm new to ModSecurity and just playing with it.

With the default settings on, I tried to send an attack request and expected to see it blocked.
So I sent the request below to the demo application
GET http://172.17.0.1/?param="><script>alert(1);</script>,
and it responded with 200 OK (which is okay since it's in detection only mode),
but I expected to see the error "Inbound Anomaly Score Exceeded (Total Score: 5)" in the audit log.

Does anyone have an idea why is that?

Here is the full log of the transaction:

--b147b831-A--
[11/Jan/2017:23:19:13 +0000] AcAcAcIcAcAcAoOcAcAcAcpc 172.21.0.1 43258 127.0.0.1 80
--b147b831-B--
GET /?param=%22%3E%3Cscript%3Ealert(1);%3C/script%3E HTTP/1.1
Host: 172.17.0.1
Connection: keep-alive
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Postman-Token: 4e00b310-ebdf-0331-c48e-9639c0eb4375
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: hu,en-GB;q=0.8,en;q=0.6,en-US;q=0.4

--b147b831-F--
HTTP/1.1 200 OK
X-Powered-By: Express
Cache-Control: public, max-age=0
Last-Modified: Wed, 11 Jan 2017 21:22:18 GMT
ETag: W/"b1-1598f68f710"
Content-Type: text/html; charset=UTF-8
Content-Length: 177
Connection: keep-alive

--b147b831-E--
<!DOCTYPE html>
<html>
  <head>
    <title>Demo App</title>
    <meta name="viewport" content="initial-scale=1.0">
 
  </head>
  <body>
  <h1>Hello World!</h1>
  </body>
</html>
--b147b831-H--
Message: Warning. detected XSS using libinjection. [file "/usr/local/nginx/conf/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "56"] [id "941100"] [rev "2"] [msg "XSS Attack Detected via libinjection"] [data "Matched Data:  found within ARGS:param: \x22><script>alert(1);</script>"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag "OWASP_AppSensor/IE1"] [tag "CAPEC-242"]
Message: Warning. Pattern match "(?i)([<\xef\xbc\x9c]script[^>\xef\xbc\x9e]*[>\xef\xbc\x9e][\\s\\S]*?)" at ARGS:param. [file "/usr/local/nginx/conf/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "91"] [id "941110"] [rev "2"] [msg "XSS Filter - Category 1: Script Tag Vector"] [data "Matched Data: <script> found within ARGS:param: \x22><script>alert(1);</script>"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "4"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag "OWASP_AppSensor/IE1"] [tag "CAPEC-242"]
Message: Warning. Pattern match "(?i)<[^\\w<>]*(?:[^<>\"'\\s]*:)?[^\\w<>]*(?:\\W*?s\\W*?c\\W*?r\\W*?i\\W*?p\\W*?t|\\W*?f\\W*?o\\W*?r\\W*?m|\\W*?s\\W*?t\\W*?y\\W*?l\\W*?e|\\W*?s\\W*?v\\W*?g|\\W*?m\\W*?a\\W*?r\\W*?q\\W*?u\\W*?e\\W*?e|(?:\\W*?l\\W*?i\\W*?n\\W*?k|\\W*?o\\W*?b\\W*?j\\W*?e\ ..." at ARGS:param. [file "/usr/local/nginx/conf/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "267"] [id "941160"] [rev "2"] [msg "NoScript XSS InjectionChecker: HTML Injection"] [data "Matched Data: <script found within ARGS:param: \x22><script>alert(1);</script>"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag "OWASP_AppSensor/IE1"] [tag "CAPEC-242"]
Message: Warning. Pattern match "^[\\d.:]+$" at REQUEST_HEADERS:Host. [file "/usr/local/nginx/conf/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "793"] [id "920350"] [rev "2"] [msg "Host header is a numeric IP address"] [data "172.17.0.1"] [severity "WARNING"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"]
Apache-Handler: IIS
Stopwatch: 1484176753000141 145505 (- - -)
Stopwatch2: 1484176753000141 145505; combined=1723, p1=277, p2=1187, p3=51, p4=165, p5=43, sr=19, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for nginx (STABLE)/2.9.1 (http://www.modsecurity.org/); OWASP_CRS/3.0.0.
Server: ModSecurity Standalone
Engine-Mode: "DETECTION_ONLY"

--b147b831-Z--

How can I test my setup is working?

I deployed, but it seems modsecurity logs but doesnt stop the malicious requets.

The example app in express only returns 404, but it doesnt reach the index.html. Did I do anything wrong?

Regards

Changes over waf-3 so that it runs nginx without problems and without errors and other suggestions

I installed this image yesterday and it gave me errors when starting, I just uploaded the changes with the errors I found and you can build the docker file with docker build --tag waf3.
And then start the container with nginx running, with docker run -d -p 80:80 waf3

Another thing that would be good to do is uncomment the following lines from modsecurity.conf:

#SecDebugLog
#SecDebugLogLevel

This to make it easier for the user to see that their modsecurity is already logging in, it would be good if it is activated by default and commented on the levels 1-9 of login. On the other hand, indicate in the documentation where the debug log file is.

You could also map the directories in docker-compose.yaml, to be able to modify the configuration files and see logs without entering the container. Let me know if these last changes that I mention are in agreement and I do them.

Regards :)

"Nginx not found" when compiling waf-3

I've tried setting up the waf-3 a couple of times now, and each time i get a "nginx not found"

waf-2 works flawlessly.

how to use env in nginx.conf

[root@94 waf]# docker exec -it dockerwaf_waf_1 env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=36e4fa0ae9b9
TERM=xterm
MY_PROXY_SITE=94.191.72.242:9000
HOME=/root

this is my nginx.conf
proxy_pass http://${MY_PROXY_SITE}/;

root@36e4fa0ae9b9:/usr/local/nginx/conf# nginx -t
nginx: [emerg] unknown "my_proxy_site" variable
nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed

Use official NGINX container image as base

See: https://hub.docker.com/_/nginx