Chaim and I discussed about opening a PR for the Docker Image. And then discussing the changes in that PR.
But now I thought it would be easier to think first about what we want to have in the official Docker Image and then open a PR.
I am sure you have already looked at it, but here again what I have done:
docker-entrypoint.sh:
Reverse Proxy Config:
Pretty 403.html:
Dockerfile:
Which parts would you see in the official image?
docker-compose
I have also added a sample or prepared docker-compose.yaml file:
With prepared exclusion files:
https://github.com/franbuehler/modsecurity-crs-rp/blob/v3.1/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf and
https://github.com/franbuehler/modsecurity-crs-rp/blob/v3.1/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
Let's discuss about that...
Are you considering only a single flavor of a docker image? Then which is the purpose of CRS on maintaining a docker image?
Personally, I am more familiar with docker and testing than with anything related to security (modsecurity, crs, etc) so I prefer images that are for production use and maintained. That way, I don't need crontabs, I just use the following to pick the new image whenever it is pushed:
https://github.com/v2tec/watchtower
@franbuehler you have done a nice job for CI. If a docker-compose.yml can be provided for production use in a simple set-it-and-forget-it way of installation (letting me as an extra step to do just the SSL), it will help.
this will generate a self-signed cert on this server if placed in the Dockerfile: RUN openssl req -x509 -newkey rsa:4096 -keyout /etc/ssl/private/selfsigned.key.pem -out /etc/ssl/certs/selfsigned.cert.pem -days 1065 -nodes -subj "/C=xx/ST=x/L=x/O=x/OU=x/CN=localhost"
Then configure httpd.conf to listen for SSL. Something like the following will work and just needs to be slightly adjusted to however you want:
# Rewrites all HTTP requests to HTTPS
<VirtualHost *:80>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L]
</VirtualHost>
<VirtualHost _default_:443>
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
SSLProtocol -ALL +TLSv1.2
SSLCertificateFile /etc/ssl/certs/selfsigned.cert.pem
SSLCertificateKeyFile /etc/ssl/private/selfsigned.key.pem
</VirtualHost>
Hi @franbuehler , I think TLS support is a must have (with A+ from ssllabs) but use ACME or mod_md to get a valid cert from let's encrypt or provide it with the conf, and let self-signed certs as bad non-default option.
Also proxyprotocol support would be nice so that it can be behind an HAproxy and keep original client ip on the logs or at least remoteip support :)
As a demo of my previous comment you can look at the following which is work in progress.
https://github.com/nicosmaris/auro-update-crs
My question is whether it makes sense to pull updates of this repository (for example once every month). If yes, then an official image that stays up to date would help.
Reasonable thoughts, @nicosmaris.
@csanders-git and I are working on these Docker images for modsecurity and modsecurity-crs.
The work is "in progress"...
Franziska, do you need help on anything?
I’m an expert on Docker and Kubernetes, much more so than ModSecurity sadly, so maybe this is something I can actually help with.
On Feb 20, 2019, at 7:32 AM, Franziska Bühler notifications@github.com wrote:
@csanders-git and I are working on these Docker images for modsecurity and modsecurity-crs.
The work is "in progress"...—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Many thanks, @danehrlich1! I will contact you on Slack.
Worked on this today. See https://github.com/danehrlich1/modsecurity-docker
and this issue where I basically just echo what @franbuehler says above.
Configuration files for loading the security2_module are missing, IIUC. This should go after the INSTALL instructions and into files placed in /etc/apache2/mods-available/:
# FILE: /etc/apache2/mods-available/security2.conf
<IfModule security2_module>
Include modsecurity.d/owasp-crs/crs-setup.conf
Include modsecurity.d/owasp-crs/rules/*.conf
</IfModule>
# FILE: /etc/apache2/mods-available/security2.load
LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so
... and enabled via a2enmod security2 in the Dockerfile, probably.
@bittner: which Docker image are you talking about?
@franbuehler: The official CRS Docker image v3.1 from Docker Hub.
In the meantime we've noticed that the configuration I mentioned above is already included:
modsecurity.d/include.conf -> contains the Include directivesmods-available/modsecurity.load -> contains the LoadModule directivemods-available/modsecurity.conf -> loads the modsecurity.d/include.conf file... and modsecurity is already symlinked in mods-enabled/.
Sorry for the noise! :expressionless:
Great! No problem 😊
This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days
This may be addressed in the long run by #1600.
Most helpful comment
Franziska, do you need help on anything?
I’m an expert on Docker and Kubernetes, much more so than ModSecurity sadly, so maybe this is something I can actually help with.