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

De Wiket
Salta a la navegació Salta a la cerca
 
Línia 61: Línia 61:
 
<syntaxhighlight lang="apacheconf">
 
<syntaxhighlight lang="apacheconf">
 
<VirtualHost _default_:80>
 
<VirtualHost _default_:80>
 +
        ServerName grup3ieti.tk
 +
        ServerAlias www.grup3ieti.tk
 +
 
         <Location />
 
         <Location />
 
                 <RequireAny>
 
                 <RequireAny>
Línia 76: Línia 79:
 
<syntaxhighlight lang="apacheconf">
 
<syntaxhighlight lang="apacheconf">
 
<VirtualHost _default_:443>
 
<VirtualHost _default_:443>
 +
        ServerName grup3ieti.tk
 +
        ServerAlias www.grup3ieti.tk
 +
 
         Header always set Strict-Transport-Security "max-age=15780000; includeSubDomains"
 
         Header always set Strict-Transport-Security "max-age=15780000; includeSubDomains"
  

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