La démarche :

Nous partirons de la configuration faite dans l'article .
Nous allons voir une règle qui bloque l'accès, par exemple celle qui interdit l'accès via adresse IP même si se n'est pas à faire en production, ensuite nous allons voir comment la désactiver pour une URL puis pour le site.

Vérification de la configuration de base :

Configuration du VirtualHost : 

<VirtualHost *:80>
        ServerName alasta.lab
        ServerAlias www.alasta.lab

        #Pour les pages erreurs qui sont en locales
        ProxyPass /waf_pages !

        #Application a proteger
        ProxyPass / http://192.168.5.41/
        ProxyPassReverse  / http://192.168.5.41/

        #Pages d erreurs
        ErrorDocument 403 /waf_pages/errors/err_page_403.php

</VirtualHost>

Résultat :

Pour la suite nous avons besoins d'avoir l'id de la règle de blocage.

[27/May/2014:16:14:40 +0200] U4Sd0MCoBSgAACS4Au0AAAAD 192.168.5.26 55378 192.168.5.40 80
--d2cc1505-B--
GET /dvwa/ HTTP/1.1
Host: 192.168.5.40
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: security=high; PHPSESSID=fprfeh08669oes7ipookf8g314
Connection: keep-alive

--d2cc1505-F--
HTTP/1.1 403 Forbidden
Content-Length: 1274
Connection: close
Content-Type: text/html; charset=UTF-8

--d2cc1505-H--
Message: Access denied with code 403 (phase 2). Pattern match "^[\d.:]+$" at REQUEST_HEADERS:Host. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line "98"] [id "960017"] [rev "2"] [msg "Host header is a numeric IP address"] [data "192.168.5.40"] [severity "WARNING"] [ver "OWASP_CRS/2.2.8"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [tag "http://technet.microsoft.com/en-us/magazine/2005.01.hackerbasher.aspx"]
Apache-Error: [file "/builddir/build/BUILD/php-5.3.3/sapi/apache2handler/sapi_apache2.c"] [line 326] [level 3] PHP Notice:  Undefined variable: txt in /var/www/html/waf_pages/errors/err_page_403.php on line 19
Action: Intercepted (phase 2)
Apache-Handler: php5-script
Stopwatch: 1401200080369910 2171 (- - -)
Stopwatch2: 1401200080369910 2171; combined=442, p1=317, p2=76, p3=0, p4=0, p5=48, sr=91, sw=1, l=0, gc=0
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.8.
Server: Apache/2.2.15 (CentOS) DAV/2
Engine-Mode: "ENABLED"

--d2cc1505-Z--

C'est la règle ayant l'id "960017" qui bloque l'accès.

Désactivation pour une page ou répertoire :

Pour ce test nous allons seulement désactiver cette règle pour la page d'authentification, donc nous aurons la page d'authentification mais une fois celle-ci validée nous serons bloqué.
Configuration du VirtualHost : 

<VirtualHost *:80>
	ServerName alasta.lab
	ServerAlias www.alasta.lab

	#Pour les pages erreurs qui sont en locales
	ProxyPass /waf_pages !

	#Application a proteger
	ProxyPass / http://192.168.5.41/
	ProxyPassReverse  / http://192.168.5.41/

	#Pages d erreurs
	ErrorDocument 403 /waf_pages/errors/err_page_403.php

	<location "/dvwa/login.php" >
		#Desactivation de la regle 960017 pour le location indiqué ci-dessus
		SecRuleRemoveById 960017
	</location>
</VirtualHost>

Redémarrage d'Apache :

service httpd graceful

Résultat :
Page d'authentification :

Une fois la page d'authentification effectuée :

Désactivation pour l'application :

Nous allons désactiver le règle précédente mais pour toute l'application/site. Je le répéte cette règle n'est pas à désactiver en production, surtout sur un reverse proxy.

Configuration du VirtualHost :

<VirtualHost *:80>
        ServerName alasta.lab
        ServerAlias www.alasta.lab

        #Pour les pages erreurs qui sont en locales
        ProxyPass /waf_pages !

        #Application a proteger
        ProxyPass / http://192.168.5.41/
        ProxyPassReverse  / http://192.168.5.41/

        #Pages d erreurs
        ErrorDocument 403 /waf_pages/errors/err_page_403.php

        #Desactivation de la regle
        SecRuleRemoveById 960017

</VirtualHost>

Redémarrage d'Apache :

service httpd graceful

Résultat :
Page d'authentification :

Une fois la page d'authentification effectuée, on peut naviguer sur l'application sans soucis :

Conclusion :

Nous avons vu comment désactiver une règle assez facilement mais il faut grader à l'esprit que ce n'est pas parce qu'on a désactiver une règle pour une raison x ou y qu'une autre règle derrière ne va pas bloquer la requête.
Il est aussi possible de désactiver la règle pour une adresse IP, mais dans un environnement de production on ne connait pas l'adresse IP des clients.
Sinon dans le cas d'une autre règle, par exemple pour une requête SQL, on custom une règle mais là il faut connaître l'application.