Serveur dédié : sécuriser Apache 2 avec ModSecurity

modsecurity

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.

Voyons comment améliorer votre site »

Gravatar for Matt Biscay

Développeur certifié WordPress & WooCommerce chez Codeable, administrateur système et enseignant-chercheur, je mets mon expertise au service de vos projets web.

Ma priorité : des sites performants, fiables et sécurisés, pensés pour offrir la meilleure expérience utilisateur. J’accompagne chaque client avec écoute et pédagogie, pour transformer vos idées en solutions concrètes et durables.

Profitez de solutions WordPress et WooCommerce sur-mesure, pensées pour optimiser durablement votre site.
Explorez les leviers pour booster l’impact de votre site web.

20 pensées sur “Serveur dédié : sécuriser Apache 2 avec ModSecurity”

  1. 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

    Syntax error on line 37 of /etc/apache2/modsecurity.d/00_asl_z_antievasion.conf:
    Error creating rule: Unknown variable: REQBODY_ERROR
    Action 'configtest' failed.
    The Apache error log may have more information.
     failed!

    Il suffit de remplacer la variable REQBODY_ERROR par REQBODY_PROCESSOR_ERROR dans /etc/apache2/modsecurity.d/00_asl_z_antievasion.conf

    Reply
  2. 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 …

    Reply
  3. 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!

    Reply
  4. 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 !

    Reply
    • Bonjour,

      Cela est dû au nouveau fichier (70_asl_csrf_experimental.conf) qui n’est pas vraiment stable :

      These are experimental CSRF mitigation rules. The 10_asl_rules.conf rules are designed to also handle CSRF attacks, however these rules are for more advanced environments.

      These rules work by injecting javascript code into the response, and special cookies, and must be tuned for the system to prevent false positives. If you do not understand what this means, do not use these rules.

      They are currently not supported and are experimental.

      Source

      Personnellement, je ne l’ai pas installé. Je suis sous Squeeze également.

      Reply
  5. Salut,

    Concernant cette erreur:

    Syntax error on line 66 of /etc/apache2/modsecurity-rules/70_asl_csrf_experimental.conf:
    Error creating rule: Unknown variable: UNIQUE_ID
    Action ‘configtest’ failed.
    The Apache error log may have more information.
    failed!

    Pour l’heure, il suffit de commenter les lignes suivantes, suivit d’un restart.

    ligne65 #SecRule RESPONSE_HEADERS:/Set-Cookie2?/ …
    ligne66 # SecRule UNIQUE_ID “(.*)” …..

    À bientôt Matt … ^¿^

    Reply
    • 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).

      Reply
  6. Bonjour,

    J’ai suivi le tuto, ca affiche toujours l’erreur 404, et les logs error.log:

    ModSecurity: Access denied with code 404 (phase 1). Match of "streq %{SESSION.IP_HASH}" against "TX:ip_hash" required. [file "/etc/apache2/modsecurity.d/70_asl_csrf_experimental.conf"] [line "56"] [id "340206"] [msg "Warning - Sticky SessionID Data Changed - IP Address Mismatch."] [hostname "www.domaine.com"] [uri "/"] [unique_id "USG0WCU7OmsAACHBBn0AAAAD"]

    et:

    ModSecurity: Access denied with code 403 (phase 2). Pattern match "(?:< ?object[ /+\\\\t].*?((type)|(codetype)|(classid)|(code)|(data))[ /+\\\\t]*=|< ?applet[ /+\\\\t].*?code[ /+\\\\t]*=|< ?base[ /+\\\\t].*?href[ /+\\\\t]*=|)" at REQUEST_URI_RAW. [file "/etc/apache2/modsecurity.d/15_asl_paranoid_rules.conf"] [line "469"] [id "340152"] [rev "23"] [msg "Atomicorp.com UNSUPPORTED DELAYED Rules: PARANOID MODE Cross Site Scripting Attack (IE variant)"] [hostname "www.domaine.com"] [uri "/URL.html"] [unique_id "USG0XSU7OmsAACHABQwAAAAC"]

    sachant que le mode php5 est desactive, je travaille avec suphp et suexec

    merci a vous

    Reply
    • 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).

      Reply
  7. Beaucoup d’erreurs avec ce mod ! La rétro-compatibilité de certaines règles laisse à désirer !

    Reply
  8. 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

    Reply
  9. Merci pour le tutorial.
    Je pensais que mod security etait deploye par defaut sur tous les serveurs apache.

    Reply

Opinions