Grup 3 - Implementar WAF (Azure)
Tornar a Projecte IETI Cloud - Grup 3.
Tasca
28. Implementar un Web Application Firewall sobre cloud extern (Azure).
Informe
Modificarem la nostra configuració desplegada sobre la màquina d'Azure per tal d'afegir un WAF i protegir els nostres serveis amb algunes regles.
Modificació del servei Reverse Proxy afegint ModSecurity
En primer lloc, per afegir ModSecurity al nostre servei de reverse proxy haurem de modificar la Dockerfile que ens construeix la imatge.
4 #Update, then install Apache2 and other useful tools
5 RUN set -eux; \
6 apt update; \
7 apt install -y \
8 apache2 \
9 libapache2-mod-security2 \
10 nano
A continuació haurem d'activar les regles recomanades de ModSecurity per tal que estiguen disponibles i habilitades. També canviarem al mode de ModSecurity de DetectionOnly a On per tal d'activar la política de bloqueig en tots els potencials atacs.
16 #Enable ModSecurity recommended configuration
17 RUN set -eux; \
18 mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf; \
19 sed -i '/SecRuleEngine DetectionOnly/ s//SecRuleEngine On/g' /etc/modsecurity/modsecurity.conf;
Un cop reconstruïm la imatge amb docker-compose up --build, el nostre servei de reverse proxy amb Apache ja tindrà disponible les opcions de ModSecurity.
Seguretat amb OWASP ModSecurity Core Rule Set
L'OWASP ModSecurity Core Rule Set (CRS) és un conjunt de regles genèriques de detecció d'atacs per utilitzar-les amb ModSecurity. El CRS pretén protegir les aplicacions web d'una àmplia gamma d'atacs, inclòs el Top Ten OWASP, amb un mínim d'alertes falses. El CRS proporciona protecció contra moltes categories d'atac habituals, com ara injecció SQL, Cross Site Scripting, inclusió de fitxers locals, etc.
Afegirem les instruccions necessàries dins el nostre Dockerfile per tal que la imatge emprada pel servei de reverse proxy ja inclogui aquest paquet de regles addicionals recomanades per OWASP. Descarreguem la versió 3.3.2 (la més nova) directament des de la pàgina de releases del Github, la descomprimim i reanomenem l'arxiu de configuració d'exemple perquè sigui un arxiu .conf, a continuació afegim totes les noves regles al directori de ModSecurity.
16 #Enable ModSecurity recommended configuration and add OWASP's CRS
17 ENV CRSDIR=/etc/owasp-modsecurity-crs
18 ENV CRSVER=3.3.2
19 RUN set -eux; \
20 mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf; \
21 sed -i '/SecRuleEngine DetectionOnly/ s//SecRuleEngine On/g' /etc/modsecurity/modsecurity.conf; \
22 wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v${CRSVER}.tar.gz -P ${CRSDIR}/; \
23 tar -xvpzf ${CRSDIR}/v${CRSVER}.tar.gz -C ${CRSDIR}/ --strip-components=1; \
24 ls -la ${CRSDIR}; \
25 rm -f ${CRSDIR}/v${CRSVER}.tar.gz; \
26 mv -f ${CRSDIR}/crs-setup.conf.example ${CRSDIR}/crs-setup.conf; \
27 mv -f ${CRSDIR}/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example ${CRSDIR}/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf; \
28 mv -f ${CRSDIR}/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example ${CRSDIR}/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf; \
29 mv -f ${CRSDIR}/crs-setup.conf /etc/modsecurity/crs/; \
30 mv -f ${CRSDIR}/rules/*.conf /etc/modsecurity/crs/; \
31 mv -f ${CRSDIR}/rules/*.data /etc/modsecurity/crs/; \
32 rm -fr ${CRSDIR};
Un com despleguem els nostres serveis amb docker-compose up --build -d podem comprovar que CRS esta en funcionament mitjançant un fals intent d'injecció XSS.
https://wordpress.grup3ieti.tk/?param="><script>alert(1);</script>
Dins els logs d'Apache podrem trobar els bloquejos entre els fitxers d'error si les regles de CRS s'han activat correctament.
... ModSecurity: Warning. Pattern match "(?i)<script[^>]*>[\\\\s\\\\S]*?" at REQUEST_FILENAME. [file "/usr/share/modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "82"] [id "941110"] [msg "XSS Filter - Category 1: Script Tag Vector"] [data "Matched Data: <script> found within REQUEST_FILENAME: /param=\\x22><script>alert(1);</script>"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/242"] [hostname "wordpress.grup3ieti.tk"] [uri "/param=\\"><script>alert(1);</script>"] [unique_id "Yj0of2A3XjTow2hZjP3K_wAAAEc"]
Regles personalitzades pels subdominis
A l'hora de protegir millor el nostre domini i intentar exposar la mínima informació possible, hem creat dos sets de regles per defecte (HTTP i HTTPS).
<VirtualHost *:80>
<Location />
<RequireAny>
Require all denied
</RequireAny>
</Location>
SecRuleEngine On
SecRule RESPONSE_STATUS "403" "phase:4,id:1,nolog,drop"
ErrorLog ${APACHE_LOG_DIR}/default-error.log
CustomLog ${APACHE_LOG_DIR}/default-access.log combined
</VirtualHost>
<VirtualHost _default_:443>
Header always set Strict-Transport-Security "max-age=15780000; includeSubDomains"
<Location />
<RequireAny>
Require all denied
</RequireAny>
</Location>
SSLEngine On
SSLCertificateFile /opt/ssl/live/grup3ieti.tk/fullchain.pem
SSLCertificateKeyFile /opt/ssl/live/grup3ieti.tk/privkey.pem
Include /opt/ssl/options-ssl-apache.conf
SecRuleEngine On
SecRule RESPONSE_STATUS "403" "phase:1,id:1,nolog,drop"
ErrorLog ${APACHE_LOG_DIR}/default.ssl-error.log
CustomLog ${APACHE_LOG_DIR}/default.ssl-access.log combined
</VirtualHost>