Aujourd’hui, on ajoute une couche de sécurité supplémentaire avec l’installation du module ModSecurity pour Apache.
ModSecurity est un firewall pour les applications web (WAF) pour Apache.
Il permet de se prémunir contre pas mal d’attaques (connues/inconnues, injections SQL, failles XSS…) et permet de surveiller le traffic HTTP en temps réel. Très utile pour un serveur dédié sous Apache!
L’installation est très rapide, cela ne prend que quelques minutes et 3 étapes.
Etape 1 : installation de mod_security
On commence par éditer nos sources de dépôts :
nano /etc/apt/sources.listCode language: PHP (php)
et on ajoute les backports :
deb squeeze-backports main
On met à jour et on installe mod_security:
apt-get update
apt-get install libapache-mod-securityCode language: JavaScript (javascript)
On active le module :
a2enmod mod-security
Et on relance Apache pour prendre en compte nos changements :
/etc/init.d/apache2 restart
Etape 2 : configuration de mod_security
On crée quelques dossiers et fichiers nécessaires pour nos règles:
mkdir /var/asl
mkdir /var/asl/tmp
mkdir /var/asl/data
mkdir /var/asl/data/msa
mkdir /var/asl/data/audit
mkdir /var/asl/data/suspicious
mkdir /etc/apache2/modsecurity.d
mkdir /etc/asl/
touch /etc/asl/whitelist
touch /var/log/apache2/audit_logCode language: JavaScript (javascript)
On regarde sous quel utilisateur tourne Apache :
ps auxwww | grep apache
Chez moi, c’est www-data :
root 19268 2.3 9.4 567512 189456 ? Ss 14:45 0:01 /usr/sbin/apache2 -k start
www-data 19290 4.5 13.2 611288 265936 ? S 14:45 0:03 /usr/sbin/apache2 -k start
www-data 19291 0.5 10.8 581028 217700 ? S 14:45 0:00 /usr/sbin/apache2 -k start
www-data 19292 3.9 11.1 582540 224688 ? S 14:45 0:02 /usr/sbin/apache2 -k start
www-data 19293 1.2 11.1 583408 224768 ? S 14:45 0:00 /usr/sbin/apache2 -k start
www-data 19294 2.2 11.1 582024 223492 ? S 14:45 0:01 /usr/sbin/apache2 -k start
www-data 19295 1.0 10.9 581720 221420 ? S 14:45 0:00 /usr/sbin/apache2 -k start
www-data 19296 0.0 9.0 567512 183176 ? S 14:45 0:00 /usr/sbin/apache2 -k start
donc, on assigne à l’utilisateur www-data les droits sur les répertoires suivants:
chown www-data.www-data /var/asl/data/msa
chown www-data.www-data /var/asl/data/audit
chown www-data.www-data /var/asl/data/suspicious
chmod o-rx -R /var/asl/data/*
chmod ug+rwx -R /var/asl/data/*Code language: JavaScript (javascript)
On crée un fichier nécessaire pour mod_security :
nano /etc/apache2/conf.d/00_modsecurity.conf
et on y met :
Include /etc/apache2/modsecurity.d/*asl*.confCode language: PHP (php)
Ensuite, on crée le fichier de configuration :
nano /etc/apache2/conf.d/modsecurity_crs_10_config.conf
et on y met :
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType (null) text/html text/plain text/xml
SecResponseBodyLimit 2621440
SecServerSignature Apache
SecComponentSignature 200911012341
SecUploadDir /var/asl/data/suspicious
SecUploadKeepFiles Off
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogType Concurrent
SecAuditLog /var/log/apache2/audit_log
SecAuditLogParts ABIFHZ
SecArgumentSeparator "&"
SecCookieFormat 0
SecRequestBodyInMemoryLimit 131072
SecDataDir /var/asl/data/msa
SecTmpDir /tmp
SecAuditLogStorageDir /var/asl/data/audit
SecResponseBodyLimitAction ProcessPartial
SecPcreMatchLimit 100000
SecPcreMatchLimitRecursion 100000Code language: JavaScript (javascript)
Admins, si vous voulez échapper au filtrage de mod_security, ajoutez votre IP dans:
/etc/asl/whitelist
Etape 3 : installation des dernières règles mod_security
On télécharge les dernières règles :
wget https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0/master.zip -O modsec.zipCode language: JavaScript (javascript)
On décompresse :
unzip modsec.zipCode language: CSS (css)
et on les copie dedans :
cp modsec/* /etc/apache2/modsecurity.d/
Il ne nous reste plus qu’à relancer la configuration Apache :
/etc/init.d/apache2 reload
Test de mod_security
Et si on testait tout ça?
wget http://localhost/index.php?foo=http://fakeattacker.comCode language: JavaScript (javascript)
Nous retourne une belle ERROR 403: Forbidden :
http://localhost/index.php?foo=http://fakeattacker.com
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 403 ForbiddenCode language: JavaScript (javascript)
Parfait! Un petit tour dans les logs Apache nous le prouve également:
[error] [client xx.xx.xx.xx] ModSecurity: Access denied with code 403 (phase 2). Match of "beginsWith http://%{SERVER_NAME}/" against "MATCHED_VAR" required. [file "/etc/apache2/modsecurity.d/10_asl_rules.conf"] [line "455"] [id "340162"] [rev "193"] [msg "Atomicorp.com - FREE UNSUPPORTED DELAYED FEED - WAF Rules: Remote File Injection attempt in ARGS (AE)"] [data ""] [severity "CRITICAL"] [hostname "www.skyminds.net"] [uri "/index.php"] [unique_id "TYYG64eklt5yZMAAEwBmIoAAAAJ"]Code language: JavaScript (javascript)
A noter que lorsque ModSecurity est désactivé, cette requête nocive provoque une erreur 404 (not found), ce qui veut dire que le serveur essaie la requête. ModSecurity tue la requête directement (erreur 403, forbidden) avant que celle-ci n’atteigne le serveur.
Conclusion
Voilà, votre serveur est un peu plus sécurisé qu’avant. L’étape 3 sera à renouveler de temps en temps, histoire de mettre à jour les règles.
Votre site mérite performance et fiabilité. Grâce à mon expérience, je vous aide à optimiser WordPress/WooCommerce pour des résultats visibles.
Merci pour ce billet. Installé en quelques minutes sur une Squeeze.
J’ai eu par contre une erreur à l’étape 3 au moment de recharger la configuration d’apache et lors de l’installation des dernières règles de mod security
Il suffit de remplacer la variable REQBODY_ERROR par REQBODY_PROCESSOR_ERROR dans /etc/apache2/modsecurity.d/00_asl_z_antievasion.conf
Merci pour cette solution n47 !
Salut Matt,
Que du bonheur sur ton site!
Je viens de mettre en place ce tutoriel (les mains dans le dos), sur une nouvelle acquisition, un dédié ovh.
Dans la série “Unknown variable”.
En voici une autre.
# service apache2 restart
Syntax error on line 490 of /etc/apache2/modsecurity-rules/10_asl_rules.conf:
Error creating rule: Unknown variable: MATCHED_VARS
Action ‘configtest’ failed.
The Apache error log may have more information.
failed!
#
Il suffit de se rendre en ligne 490, et changer la variable MATCHED_VARS par MATCHED_VAR.
Opération à effectué également pour les lignes :
Syntax error on line 540 of /etc/apache2/modsecurity-rules/10_asl_rules.conf
Syntax error on line 1187 of /etc/apache2/modsecurity-rules/10_asl_rules.conf
Syntax error on line 1187 of /etc/apache2/modsecurity-rules/10_asl_rules.conf
Syntax error on line 2853 of /etc/apache2/modsecurity-rules/10_asl_rules.conf
Syntax error on line 2865 of /etc/apache2/modsecurity-rules/10_asl_rules.conf
Ben voilà, c’est dit …
J’t’en serre cinq, à tantôt …
Merci loreleil !
J’ai eu la même erreur en mettant les règles à jour. C’est étrange qu’ils ne la corrigent pas.
Hello Matt,
Pour ma part, c’est à la fin de l’étape 1 que ça a bogué!
Sous Ubu 12, apache ne trouve pas libxml2.so.2.
Donc —> vi /etc/apache2/mods-enabled/mod-secrity.load et remplacer le chemin LoadFile /usr/lib/libxml2.so.2 par LoadFile /usr/lib/i286-linux-gnu/libxml2.so.2.
Et viva la musica!
Merci Argile pour cette solution !
Salut tlm, j’ai corrigé comme vous les erreurs, mais j’en ai encore :s,
pouvez-vous m’aider?
Syntax error on line 66 of /etc/apache2/modsecurity.d/70_asl_csrf_experimental.conf:
Error creating rule: Unknown variable: UNIQUE_ID
Action ‘configtest’ failed.
Merci d’avance !
Salut skiti,
Vérifie que le module
unique_idsoit bien activé dans Apache :Bonjour,
Merci pour ce tuto.
J’ai le même soucis que skiti, et j’ai pourtant bien activé le module unique_id.
Je suis sous squeeze.
Merci d’avance
Même souci que Math, Unknown variable: UNIQUE_ID.
Bonjour,
Cela est dû au nouveau fichier (70_asl_csrf_experimental.conf) qui n’est pas vraiment stable :
Personnellement, je ne l’ai pas installé. Je suis sous Squeeze également.
Salut,
Concernant cette erreur:
Pour l’heure, il suffit de commenter les lignes suivantes, suivit d’un restart.
À bientôt Matt … ^¿^
Merci loreleil ! :)
J’ai préféré ne pas utiliser le fichier mais on peut bien sûr commenter les lignes qui posent problèmes (tout en sachant qu’il faudra refaire les changements à la prochaine mise à jour).
Bonjour,
J’ai suivi le tuto, ca affiche toujours l’erreur 404, et les logs error.log:
et:
sachant que le mode php5 est desactive, je travaille avec suphp et suexec
merci a vous
Bonjour Fred,
Les règles experimental et paranoid sont très instables : elles cassent pas mal de choses et causent beaucoup de faux-positifs.
A ta place, je les désactiverai. C’est ce que j’ai fait chez moi, je n’ai pas vraiment le temps de les débugger (et elles changent d’une version à l’autre).
Beaucoup d’erreurs avec ce mod ! La rétro-compatibilité de certaines règles laisse à désirer !
Salut,
Juste pour te signaler que les regles atomicorp ne sont plus dispo :( il ne les propose plus. C’est devenu payant, tu aurais une solution alternative ?
cheer
Salut Majeri,
Merci pour le suivi, je n’avais pas vu que les règles Atomicorp n’étaient plus disponible!
Je viens de modifier l’article utiliser les règles du projet OWASP ModSecurity Core Rule Set (CRS), qui ont l’air d’être mises à jours plus régulièrement.
Merci pour le tutorial.
Je pensais que mod security etait deploye par defaut sur tous les serveurs apache.
Merci pour ce tuto très clair :)