mod_security apache

Installation et configuration de mod_security apache

Mod_security est un un pare-feu applicatif qui se présente sous la forme d’un module pour Apache. Son rôle est de détecter et de protéger le serveur contre des attaques en tout genre : injections SQL, cross-site scripting (XSS)… Voici comment l’installer et le configurer pour une utilisation basique.

Sous Centos

yum install mod_security

Ensuite toutes les règles se trouvent dans le dossier /etc/httpd/modsecurity.d/

ls /etc/httpd/modsecurity.d/
modsecurity_crs_10_config.conf
modsecurity_crs_20_protocol_violations.conf
modsecurity_crs_21_protocol_anomalies.conf
modsecurity_crs_23_request_limits.conf
modsecurity_crs_30_http_policy.conf
modsecurity_crs_35_bad_robots.conf
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_45_trojans.conf
modsecurity_crs_50_outbound.conf
modsecurity_localrules.conf
optional_rules

ls /etc/httpd/modsecurity.d/optional_rules/
modsecurity_crs_20_protocol_violations.conf
modsecurity_crs_21_protocol_anomalies.conf
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_42_comment_spam.conf
modsecurity_crs_42_tight_security.conf
modsecurity_crs_55_marketing.conf

Dans le fichier modsecurity_crs_10_config.conf, vérifier que SecRuleEngine est bien sur On

Commenter les directives suivantes:

#SecServerSignature “Apache/2.2.0 (Fedora)”
#SecComponentSignature “core ruleset/1.6.1″

Puisqu’Apache se charge deja de cacher tout ca.

Modifier la directive suivante de cette manière:
SecUploadKeepFiles RelevantOnly

Jeter un coup d’oeil dans les fichiers conf pour voir tout ce qui va être sécurisé!

Si jamais vous avez un domaine pour lequel vous ne souhaitez pas activer le mod_security (car il plante le site ou autre..). Ajouter la directive SecRuleEngine Off dans le virtualhost et redemarrer apache.

Installation et configuration de mod_evasive sous Apache

Le module mod_evasive va se charger de bloquer les attaques par force brut, par DOS et de flood de spam. Il peut même interagir avec iptables.

Mod_evasive bloque le trafic en provenance de la source pendant une période donnée en renvoyant vers une page 403

Sous centos/fedora:
[sh]yum install mod_evasive[/sh]

Editer le fichier de configuration /etc/httpd/conf.d/mod_evasive.conf et le configurer de la manière suivante:

Relancer httpd
/etc/init.d/httpd graceful

vi /etc/httpd/conf.d/mod_evasive.conf

DOSHashTableSize    3097
DOSPageCount        3
DOSSiteCount        50
DOSPageInterval     2
DOSSiteInterval     2
DOSBlockingPeriod   10
DOSEmailNotify      votreemail@votredomaine.com
#DOSSystemCommand “/sbin/iptables -I INPUT -s %s -j DROP”
DOSSystemCommand “/bin/echo %s >> /var/log/mod_evasive/dos_evasive.log && /bin/date >> /var/log/mod_evasive/dos_evasive.log”

DOSLogDir “/var/log/mod_evasive/”

DOSWhitelist 127.0.0.1
#DOSWhitelist 192.168.0.*
DOSWhiteList 88.248.70.*

DOSPageCount : Nombre maximal de requêtes qu’une adresse IP source peut réaliser sur la même ressource (même URL) pendant une unité de temps sans être ajoutée à la liste noire.

DOSSiteCount : Nombre maximal de requêtes qu’une adresse IP source peut réaliser sur le même enfant pendant une unité de temps sans être ajoutée à la liste noire.

DOSPageInterval : Temps évoquée dans la directive DOSPageCount (en seconde).

DOSSiteInterval : Temps évoquée dans la directive DOSSiteCount (en secondes).

DOSBlockingPeriod : Durée pendant laquelle tous les accès des adresses IP en liste noire seront refusés et recevront une erreur 403. Pas besoin de mettre beaucoup puisque l’IP sera blacklisté temps qu’elle n’arrête pas de flooder

DOSEmailNotify : Adresse email à prévenir lorsqu’une IP est interceptée

DOSSystemCommand : Commande a exécuter. Par exemple bloquer pat Iptables, ajouter l’adresse IP dans la blackliste du routeur, loguer l’IP…

DOSWhiteList : Adresse IP a ne jamais blacklister. Il est bon d’ajouter les adresses IP des GoogleBot.

Il faut ensuite créer le dossier des logs et mettre les droits pour qu’apache puisse ecrire dedans
mkdir /var/log/mod_evasive/
chown -R apache.apache /var/log/mod_evasive

Il n’est pas recommandé de bloquer les IP directement avec Iptables apr mod_evasive car dans ce cas la il faut autoriser l’utilisateur apache a utiliser Iptables. Et la ca devient très dangereux en terme de sécurité.

Mais bon pour ceux qui veulent le faire, editer le fichier /etc/sudoers et ajouter la ligne : apache ALL=NOPASSWD:/sbin/iptables (ce qui est gênant c’est justement le NOPASSWD……..)

Pour ma part, j’ai remarqué que dans les logs le message suivant revenait souvent :

Request Missing a Host Header
Request Missing an Accept Header
Request Missing a User Agent Header
...

Cela arrive quand le client qui se connecte au serveur utilise des headers mal configurés. Ce n’est pas vraiment un problème de sécurité en soit, à moins d’être paranoïaque. J’ai donc désactivé la couche qui vérifie les en-têtes comme ceci :

cd /etc/httpd/modsecurity.d/base_rules/
mv modsecurity_crs_21_protocol_anomalies.conf \
modsecurity_crs_21_protocol_anomalies.conf.disable

J’ai également désactivé les règles qui détectent les mauvais robots. Car celles-ci bloquent les requêtes faite sur le site avec wget ou curl, or beaucoup d’articles publiés préconisent d’utiliser ces commandes :

mv modsecurity_crs_35_bad_robots.conf \
modsecurity_crs_35_bad_robots.conf.disable

Désactivation de Mod_security pour un site web précis

L’utilisation de Mod_security a eu quelques effets de bord sur Tux-planet. En effet, j’ai eu pas mal de problèmes avec l’interface d’administration de WordPress. Le module avait tendance à bloquer certaines actions comme l’écriture d’articles ou la modifications d’options…

De nombreux sites donnent des règles d’exception à appliquer, pour moi, elles ne fonctionnaient pas. Comme je suis le seul à accéder à l’interface de gestion et que celle-ci est déjà protégée par un .htaccess, j’ai choisi de désactiver le module de sécurité pour cette partie du site.

Voici un exemple de configuration Apache à utiliser pour désactiver Mod_security sur un virtuahost :

# On desactive Mod_security pour l'admin de wordpress
<LocationMatch "/wp-admin">
  <IfModule mod_security2.c>
    SecRuleEngine Off
  </IfModule>
</LocationMatch>

Test de sécurité

Je déconseille fortement la mise en place de Mod_security sur un serveur en production, ne serait-ce parce que ce genre de firewall applicatif génère des faux-positifs. Voici quelques exemples de tests que l’on peut réaliser. Les actions suivantes doivent par exemple être bloquées :