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). La primera regla, rebrà per defecte totes les connexions HTTP i realitzarà un drop de les connexions amb un codi d'error 403 (Forbidden). La segona regla, rebra per defecte totes les connexions HTTPS, aplicarà la capçalera HSTS i també realitzarà un drop amb codi d'error 403 (Forbidden). D'aquesta manera afegim un nivell addicional de seguretat pel fet que no exposarem subdominis sense configurar o recursos que Apache pot incloure per defecte. Ja que aquests fitxers representen regles genèriques que únicament s'aplicaran en mancar una més especifica, no entorpeix als subdominis funcionals, pel fet que aquests si disposen d'una regla concreta.
<VirtualHost _default_:80>
ServerName grup3ieti.tk
ServerAlias www.grup3ieti.tk
<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>
ServerName grup3ieti.tk
ServerAlias www.grup3ieti.tk
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>