Diferència entre revisions de la pàgina «Grup 3 - Implementar WAF (Azure)»

De Wiket
Salta a la navegació Salta a la cerca
 
(44 revisions intermèdies per 2 usuaris que no es mostren)
Línia 7: Línia 7:
 
Modificarem la nostra configuració [[Grup 3 - Implementar HTTPS i HSTS (HTTPS only) (Azure)|desplegada sobre la màquina d'Azure]] per tal d'afegir un WAF i protegir els nostres serveis amb algunes regles.  
 
Modificarem la nostra configuració [[Grup 3 - Implementar HTTPS i HSTS (HTTPS only) (Azure)|desplegada sobre la màquina d'Azure]] per tal d'afegir un WAF i protegir els nostres serveis amb algunes regles.  
  
=== Modificació del servei de ''Reverse Proxy'' per afegir ModSecurity ===
+
=== 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.
+
En primer lloc, per afegir ModSecurity al nostre servei de ''reverse proxy'' haurem de modificar la [[Grup 3 - Implementar HTTPS i HSTS (HTTPS only) (Azure)#anchor-dockerfile|Dockerfile]] que ens construeix la imatge.
<pre>
+
<syntaxhighlight lang="docker" line start="4" highlight="6">
#Update, then install Apache2, ModSecurity and other useful tools
+
#Update, then install Apache2 and other useful tools
 
RUN set -eux; \
 
RUN set -eux; \
 
         apt update; \
 
         apt update; \
 
         apt install -y \
 
         apt install -y \
 
                 apache2 \
 
                 apache2 \
                 <span style="color:green;">libapache2-mod-security2 \</span>
+
                 libapache2-mod-security2 \
 
                 nano
 
                 nano
 +
</syntaxhighlight>
 +
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.
 +
<syntaxhighlight lang="docker" line start="16">
 +
#Enable ModSecurity recommended configuration
 +
RUN set -eux; \
 +
        mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf; \
 +
        sed -i '/SecRuleEngine DetectionOnly/ s//SecRuleEngine On/g' /etc/modsecurity/modsecurity.conf;
 +
</syntaxhighlight>
 +
Un cop reconstruïm la imatge amb <code>docker-compose up --build</code>, 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 [[Grup 3 - Implementar HTTPS i HSTS (HTTPS only) (Azure)#anchor-dockerfile|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 <code>.conf</code>, a continuació afegim totes les noves regles al directori de ModSecurity.
 +
<syntaxhighlight lang="docker" line start="16" highlight="2-3,7-17">
 +
#Enable ModSecurity recommended configuration and add OWASP's CRS
 +
ENV CRSDIR=/etc/owasp-modsecurity-crs
 +
ENV CRSVER=3.3.2
 +
RUN set -eux; \
 +
        mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf; \
 +
        sed -i '/SecRuleEngine DetectionOnly/ s//SecRuleEngine On/g' /etc/modsecurity/modsecurity.conf; \
 +
        wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v${CRSVER}.tar.gz -P ${CRSDIR}/; \
 +
        tar -xvpzf ${CRSDIR}/v${CRSVER}.tar.gz -C ${CRSDIR}/ --strip-components=1; \
 +
        ls -la ${CRSDIR}; \
 +
        rm -f ${CRSDIR}/v${CRSVER}.tar.gz; \
 +
        mv -f ${CRSDIR}/crs-setup.conf.example ${CRSDIR}/crs-setup.conf; \
 +
        mv -f ${CRSDIR}/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example ${CRSDIR}/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf; \
 +
        mv -f ${CRSDIR}/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example ${CRSDIR}/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf; \
 +
        mv -f ${CRSDIR}/crs-setup.conf /etc/modsecurity/crs/; \
 +
        mv -f ${CRSDIR}/rules/*.conf /etc/modsecurity/crs/; \
 +
        mv -f ${CRSDIR}/rules/*.data /etc/modsecurity/crs/; \
 +
        rm -fr ${CRSDIR};
 +
</syntaxhighlight>
 +
Un com despleguem els nostres serveis amb <code>docker-compose up --build -d</code> podem comprovar que CRS esta en funcionament mitjançant un fals intent d'injecció XSS.
 +
<syntaxhighlight lang="http">https://wordpress.grup3ieti.tk/?param="><script>alert(1);</script></syntaxhighlight>
 +
Dins els ''logs'' d'Apache podrem trobar els bloquejos entre els fitxers d'error si les regles de CRS s'han activat correctament.
 +
<pre>
 +
[...] 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"]
 
</pre>
 
</pre>
 +
 +
=== 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.
 +
<syntaxhighlight lang="apacheconf">
 +
<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>
 +
</syntaxhighlight>
 +
<syntaxhighlight lang="apacheconf">
 +
<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>
 +
</syntaxhighlight>
  
 
== Referències ==
 
== Referències ==
 
* [https://github.com/SpiderLabs/ModSecurity Github - Repositori de ModSecurity]
 
* [https://github.com/SpiderLabs/ModSecurity Github - Repositori de ModSecurity]
 +
* [https://github.com/coreruleset/coreruleset Github - Repositori d'OWASP Core Rule Set]
 +
* [https://owasp.org/www-project-modsecurity-core-rule-set/ OWASP - ModSecurity Core Rule Set]

Revisió de 14:33, 31 març 2022

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>

Referències