1. Avant de commencer

Dans ce tutoriel, je pars du principe que vous connaissez le fonctionnement d'Apache, de ses modules et de PHP. Ces derniers doivent d'ailleurs être installés sur votre serveur avec les paquets RPM ou DEB.

Dans l'exemple que nous allons suivre, nous utiliserons mod_suPHP sur le serveur de Tux-planet pour cloisonner deux sections du site :

• le site principal sous WordPress, qui tournera sous l'uid www-wordpress
• le forum sous FluxBB, qui tournera sous l'uid www-forum

2. Installation de suPHP

Pour installer suPHP sur une distribution à base de RPM, téléchargez les sources depuis le site officiel. Lancez ensuite les commandes suivantes en root pour compiler le module :

yum install gcc gcc-c++ automake autoconf make httpd-devel apr apr-devel
cd /usr/local/src
tar zxvf suphp-*.tar.gz && rm -f suphp-*.tar.gz && cd suphp-*
./configure --prefix=/usr/local/suphp-0.7.1 \
--sysconfdir=/etc \
--with-apxs=/usr/sbin/apxs \
--with-apr=/usr/bin/apr-1-config \
--with-logfile=/var/log/suphp.log \
--with-setid-mode=paranoid \
--with-min-uid=500 \
--with-min-gid=500 \
--with-apache-user=apache
make
make install

On poursuit avec la mise en place d'un lien symbolique :

cd /usr/local
ln -s suphp-0.7.1 suphp
ls -l

Une fois la compilation terminée, on devra se retrouver avec les deux fichiers suivants :

/usr/local/suphp/sbin/suphp
/etc/httpd/modules/mod_suphp.so

3. Configuration de suPHP

La configuration du module se situe dans le fichier /etc/suphp.conf. Recopiez le fichier d'exemple fourni avec le code source pour avoir une base de départ :

cp /usr/local/src/suphp-*/doc/suphp.conf-example /etc/suphp.conf

Ensuite, il vous faudra adapter la configuration. Pour ma part, j'utilise les options suivantes :

[global]
;Path to logfile
logfile=/var/log/suphp.log

;Loglevel
loglevel=info

;User Apache is running as
webserver_user=apache

;Path all scripts have to be in
docroot=/home/

;Path to chroot() to before executing script
;chroot=/mychroot

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=false

;Send minor error messages to browser
errors_to_browser=false

;PATH environment variable
env_path=/bin:/usr/bin

;Umask to set, specify in octal notation
umask=0027

; Minimum UID
min_uid=500

; Minimum GID
min_gid=500

[handlers]
;Handler for php-scripts
;x-httpd-php="php:/usr/bin/php"
x-httpd-php="php:/usr/bin/php-cgi"

;Handler for CGI-scripts
x-suphp-cgi="execute:!self"

Vous devez savoir que pour faire fonctionner correctement suPHP, il faut faire tourner PHP en mode CGI et non en mode CLI comme on le fait traditionnellement. Ce changement se situe au niveau de cette ligne, dans le fichier de configuration principal :

x-httpd-php="php:/usr/bin/php-cgi"

L'utilisation du mode CGI n'a pas d’impact sur la compatibilité des scripts. En revanche, si vous ne le faites pas, vous risquez de vous retrouver avec le message d'erreur suivant dans les logs :

Premature end of script headers

A noter également qu'ici j'utilise un umask de 0027. Cela signifie que lorsque les scripts php créeront des fichiers (logs, fichiers de cache, images...), les droits seront les suivants par défaut :

• 750 pour les dossiers : -rwx-r-x---
• 640 pour les fichiers : -rw-r-----

Voici une liste qui récapitule différentes possibilités d'utilisation d'umask :

• umask 0000 = 777 pour les dossiers & 666 pour les fichiers
• umask 0022 = 755 pour les dossiers & 644 pour les fichiers
• umask 0027 = 750 pour les dossiers & 640 pour les fichiers
• umask 0077 = 700 pour les dossiers & 600 pour les fichiers
• umask 0007 = 770 pour les dossiers & 660 pour les fichiers

4. Mise en place des groupes et utilisateurs

Dans notre cas, nous allons avoir besoin de deux utilisateurs dédiés pour les deux sections du site :

adduser www-wordpress -m -s /sbin/nologin
adduser www-forum -m -s /sbin/nologin

Vous devez ensuite déplacer les fichiers des sites dans les homedir des utilisateurs. Il ne faudra pas oublier de mettre en place les bons droits d'accès (seul le propriétaire et le groupe doivent avoir accès) :

chown -R www-wordpress: ~www-wordpress
chmod -R 750 ~www-wordpress

chown -R www-forum: ~www-forum
chmod -R 750 ~www-forum

Pour éviter certains problèmes de droits (chargement des fichiers .htaccess, compatibilité avec mod_deflate...), on ajoute l'utilisateur apache aux groupes des utilisateurs qui exécuteront les sites :

usermod -G www-wordpress,www-forum apache

Pensez également à relancer le processus apache pour prendre en compte chaque modification de droits, le fichier /etc/group est rechargé au démarrage du serveur uniquement :

service httpd restart

5. Configuration d'Apache et des virtualhosts

Au niveau de la configuration d'Apache, il faut ajouter la ligne suivante au fichier /etc/httpd/conf/httpd.conf pour charger le module :

LoadModule suphp_module         modules/mod_suphp.so

Et utiliser ces lignes dans chaque virtualhost pour lequel on souhaitera utiliser un identifiant différent d'Apache, afin de faire tourner les scripts PHP :

<Location "/">
  # Configuration de suPHP
  suPHP_Engine on
  suPHP_UserGroup www-wordpress www-wordpress
  suPHP_ConfigPath /etc/
  suPHP_AddHandler x-httpd-php
  AddHandler x-httpd-php .php .php3 .php4 .php5
  # Configuration de PHP
  php_admin_flag engine on
</Location>

Ensuite, on recharge la configuration d'apache pour prendre en compte les modifications :

service httpd reload

6. Test de suPHP

Pour tester le bon fonctionnement de suPHP, on peut utiliser le bout de code PHP suivant à la racine de chaque site :

echo "<?php echo exec('/usr/bin/whoami'); ?>" > suphp-test.php

Et l'appeler ensuite pour vérifier que l'uid utilisé est le bon :

http://localhost/suphp-test.php

7. En cas de problème

La mise en place du module suPHP n'est pas forcément évidente. C'est rare que cela marche du premier coup et il faut souvent revoir les droits d'accès et la configuration pour obtenir quelque chose qui fonctionne.

Donc en cas de problème, je vous conseille de regarder les messages dans les fichiers de logs :

tail -f /var/log/suphp.log /var/log/httpd/error_log

Vous pouvez aussi jouer sur l'option suivante du fichier /etc/suphp.conf, qui permet d'afficher des messages d'erreur dans le navigateur :

errors_to_browser=true

Tableau comparatif des offres de serveurs dédiés à 50€

Avant de commencer, voici un petit comparatif des offres de serveurs dédiés à 50€ qui existent aujourd'hui sur le marché français. J'ai pris ces références car elles correspondent à la gamme du serveur qui héberge le site.

A l'heure où j'écris ces lignes, on peut résumer les choses ainsi : si vous avez besoin du Raid et du trafic illimité, il vaut mieux aller chez Online. Et si vous voulez plus de RAM et de CPU à la place, il vaut mieux s'orienter vers un Kimsufi.

Personnellement, j'aurai tendance à opter plus pour le RAID, car quand un disque dur lâche, votre serveur tombe en panne directement. Et c'est à ce moment là qu'il faut prier très fort pour que les sauvegardes fonctionnent.

Disponibilité du serveur Dedibox de Tux-planet

Voici le rapport de la société Pingdom concernant les indisponibilités du serveur. Sur un an, l'uptime est de 99,84%, plutôt pas mal alors que le serveur n'est même pas en cluster.

Le temps de réponse moyen est de 641 ms.

Le support chez Online

Les gars de chez Online m'avaient demandé de ne pas passer par le support technique en cas de problème, mais plutôt de les contacter directement par mail.

Mais, je n'aime pas trop être privilégié et encore moins déranger les gens. Du coup, j'ai tout de même ouvert des tickets comme un client normal. Et de ce côté ci, je suis satisfait du service. Ces derniers répondent très rapidement, voici quelques exemples :

Moins de 7 heures pour un ticket fait à 1h du matin :

| --> Tuxplanet - Bonjour, Sur ma console, je peux ... - mardi 12 juillet 2011 à 01:11:47
| --> Philou14 - Bonjour, Sébastien Bilbeau a ecrit: ... - mardi 12 juillet 2011 à 07:54:47

Moins de 10 minutes pour un ticket fait à 23h du soir :

| --> Tuxplanet - Bonjour, J'ai vu sur les ... - jeudi 27 octobre 2011 à 22:51:32
| --> Philou14 - Bonjour, Sébastien Bilbeau a ecrit: ... - jeudi 27 octobre 2011 à 23:01:38

Environ 33 minutes pour ticket fait à 18h un lundi soir :

| --> Tuxplanet - Bonjour, Quand j'essaye de me connec... - lundi 31 octobre 2011 à 18:18:22
| --> Philou14 - Bonjour, Sébastien Bilbeau a ecrit: ... - lundi 31 octobre 2011 à 18:51:30

Test du débit réseau

J'ai essayé de faire quelques tests de débit réseau en utilisant la commande wget. Je rappelle que le serveur est câblé en Gigabit.

Test du débit entre une connexion Free 20 Mbps et une Dedibox :

$ wget -4 -O /dev/null www.tux-planet.fr/public/image.iso
2011-11-17 00:12:45 (931 KB/s) - «/dev/null» sauvegardé [728784896/728784896]

Test du débit entre une connexion Renater 100 Mbps (réseau national éducation et recherche) et une Dedibox :

$ wget -4 -O /dev/null www.tux-planet.fr/public/image.iso
2011-10-29 10:29:37 (3.49 MB/s) - '/dev/null' saved [728784896/728784896]

Test du débit entre une Dedibox et le réseau Free :

$ wget -4 -O /dev/null http://test-debit.free.fr/image.iso
2011-10-29 10:20:32 (89.9 MB/s) - '/dev/null' saved [678526976/678526976]

Test du débit entre deux Dedibox :

$ wget -4 -O /dev/null http://88.191.93.4/image.iso
2011-10-29 10:23:02 (11.2 MB/s) - '/dev/null' saved [728784896/728784896]

Test du débit entre une Dedibox et un serveur OVH :

$ wget -4 -O /dev/null http://91.121.82.94/image.iso
2011-10-29 10:24:16 (10.1 MB/s) - '/dev/null' saved [728784896/728784896]

Test de débit entre une Dedibox et le réseau Bouygues Telecom (qui possède un peering privé avec Free) :

$ wget -4 -O /dev/null http://testdebit.bbox.fr/image.iso
2011-10-29 10:19:10 (99.6 MB/s) - '/dev/null' saved [728784896/728784896]

Les plus

Pour moi, les plus chez Online sont :

• Un réseau stable et rapide
• La possibilité de démarrer facilement sur un Live CD Ubuntu en cas de gros problème sur le serveur
• L'accès à l'interface web d'administration DRAC et à la console vKVM
• La possibilité de lancer une procédure de test du matériel (test de la RAM avec Memtest, test du disque dur pour vérifier la température, les logs SMART et faire une vérification de bas niveau, le test du débit réseau, test de l'alimentation)

Les moins

Il n'est pas possible de faire du bonding, alors que le serveur possède deux cartes réseau :

$ /sbin/ifconfig -a | grep eth
eth0 Link encap:Ethernet HWaddr 00:xx:xx:xx:xx:xx
eth1 Link encap:Ethernet HWaddr 00:xx:xx:xx:xx:xx

Le manager de chez Online est moins complet que ce qui existe chez OVH. Les outils de monitoring sont par exemple un peu plus pauvres. Chez OVH, on vous propose de surveiller la charge de votre CPU et tout un tas d'autres choses à base de graphique MRTG. Chez Online, il n'y a que deux graphiques sur la consommation de la bande passante.

$ ssh user@serveur
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
48:95:46:71:ab:c8:e8:2d:99:48:15:33:ad:ae:8f:6f.
Please contact your system administrator.
Add correct host key in /home/pti-seb/.ssh/known_hosts to get rid of this message.
Offending key in /home/pti-seb/.ssh/known_hosts:6
RSA host key for serveur.fr has changed and you have requested strict checking.
Host key verification failed.

Pour résoudre ce problème, il faut mettre à jour votre fichier known_hosts. Vous pouvez le faire automatiquement avec cette ligne de commande :

ssh-keygen -R adresse-ip-du-serveur

Voici un exemple d'utilisation :

$ ssh-keygen -R mon_serveur
/home/pti-seb/.ssh/known_hosts updated.
Original contents retained as /home/pti-seb/.ssh/known_hosts.old

Attention : si jamais vous n'avez pas réinstallé votre serveur ou changé quoique ce soit au niveau d'OpenSSH, ce message est sans aucun doute révélateur d'un attaque de type Man in the Middle sur votre réseau.

Sommaire

• Fonctionnement
• Installation et configuration du serveur
• Configuration d'un client Linux
• Configuration d'un client Windows
• Configuration du navigateur Internet
• Testez votre adresse IP, la rapidité de la connexion et résoudre les problèmes de lenteur
• La sécurité liée à ce genre de service

Fonctionnement 

Pour mettre en place ce système, il nous faut bien entendu un serveur dédié avec SSH. Si vous êtes la seule personne à l'utiliser, vous n'aurez pas besoin d'une machine très puissante. La plupart des serveurs dédiés bas de gamme devrait faire l'affaire.

Voici un petit schéma qui explique le fonctionnement d'une connexion Internet à travers un tunnel SSH :

La méthode reste assez simple, si l'on ne rentre pas dans les détails :

1. On branche le navigateur Internet de son PC en mode proxy sur l'adresse 127.0.0.1:8080
2. Le trafic est alors acheminé à l'aide d'un tunnel SSH chiffré, vers le serveur
3. Celui-ci s'occupe ensuite d'aller chercher les informations sur Internet à votre place
4. Les données reviennent sur la machine cliente par le même chemin

Installation et configuration du serveur 

Aucune configuration particulière n'est nécessaire sur le serveur dédié. Normalement, le serveur openSSH est installé et activé sur la plupart des distributions Linux ou Unix, et la configuration par défaut suffit.

Si jamais ce n’est pas le cas, ouvrez un terminal et lancez les commandes suivantes pour une distribution à base de RPM par exemple :

yum install sshd
/etc/init.d/sshd start

Configuration d'un client Linux 

Notre serveur est maintenant opérationnel. Nous allons donc pouvoir y connecter notre machine cliente sous Linux par le biais d'un tunnel SSH. Pour y arriver, ouvrez un terminal sur votre ordinateur et lancez la commande suivante :

ssh user@serveur -C -N -D 8080

Cette commande va alors ouvrir un tunnel et en même temps une session SSH vers le serveur. Il faudra absolument garder celle-ci ouverte pour que le tunnel ne soit pas fermé.

Voici quelques explications concernant les options utilisées :

• user@serveur : le compte SSH et l'adresse IP du serveur
• -C : permet de compresser le trafic et utiliser moins de bande passante
• -N : ne pas ouvrir de shell
• -D 8080 : permet de créer le tunnel SSH. Tout le trafic envoyé sur le port local (8080) sera redirigé dans le tunnel vers le serveur et ensuite vers Internet

Configuration d'un client Windows 

Sous Windows, le protocole SSH n'est pas disponible par défaut. Pour y remédier, on peut utiliser le célèbre logiciel Putty. Une fois lancé :

• Allez dans les menus Connection → SSH → Tunnels
• Indiquez 8080 dans le champ Source port et chochez les case Dynamic et Auto
• Cliquez ensuite sur Add :



• Retournez dans le menu Session et indiquez le compte de connexion et l'adresse du serveur dans le champ host :



• Pour finir, cliquez sur Open

Configuration du navigateur Internet 

Voici comment configurer votre navigateur en mode proxy socks. Avec Firefox, Allez dans le menu Options → Avancé → Réseau → Paramètres et utilisez la configuration suivante :

A la suite de cela, vous devriez pouvoir naviguer sur Internet comme vous le faites normalement.

Une remarque de @niluje en commentaire : il faut faire attention, si quelqu'un sniff le trafic au niveau du navigateur, il ne récupérera certes pas le trafic car il est chiffré mais il pourra voir toutes les requêtes DNS. Pour que les requêtes DNS soient aussi socks, il faut saisir l'adresse about:config dans Firefox et changer la valeur network.proxy.socks_remote_dns à true.

Testez votre adresse IP, la rapidité de la connexion et résoudre les problèmes de lenteur 

Voici quelques commandes bash très pratiques pour tester votre adresse IP et la rapidité de la connexion en passant par le tunnel. Ces dernières sont à utiliser sur la machine cliente Linux (si vous utilisez Windows, il faudra faire autrement) :

$ curl --socks5 127.0.0.1:8080 www.whatismyip.org
$ curl --socks5 127.0.0.1:8080 -w 'Lookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nTotal time:\t%{time_total}\n' -o /dev/null -s www.tux-planet.fr

Lookup time: 0.000
Connect time: 0.001
Total time: 0.035

Et sans tunnel :

$ curl www.whatismyip.org
$ curl -w 'Lookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nTotal time:\t%{time_total}\n' -o /dev/null -s www.tux-planet.fr

Lookup time: 0.001
Connect time: 0.009
Total time: 0.045

Si l'écart entre une connexion avec et sans tunnel SSH est trop important, la navigation sur Internet sera alors très lente. Si c'est votre cas, pensez à vérifier la configuration DNS du serveur (fichier /etc/resolv.conf) car c'est souvent la cause n°1 de ce genre de problème. Des commandes de test sont disponibles ici.

La sécurité liée à ce genre de service 

La meilleure façon de sécuriser ce genre de serveur est d'utiliser un firewall et d'autoriser uniquement les connexions SSH depuis des adresses IP connues. Voici un exemple de script IPTABLES qui devrait faire l'affaire dans la plupart des cas (pensez à adapter les variables) :

#!/bin/bash

# Variables
export IF_RESEAU="eth0"
export MY_IP="88.xxx.xxx.xxx"

# On efface toutes les regles existantes
/sbin/iptables -F

# On supprime d'eventuelles regles personnelles
/sbin/iptables -X 

# Mise en place des regles par defaut (on refuse tout par default)
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP

# On accepte les connexions sur la boucle locale (sur lo == 127.0.0.1)
/sbin/iptables -A INPUT  -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# On autorise ssh que pour certaines adresses IP
/sbin/iptables -A INPUT -i $IF_RESEAU -p tcp --dport ssh --source $MY_IP -j ACCEPT

# On interdit le ssh pour les autres
# A mettre apres la liste des machines autorisee au ssh
/sbin/iptables -A INPUT -i $IF_RESEAU -p tcp --dport ssh -j DROP

# On accept le DNS + HTTP + HTTPS en sortie
/sbin/iptables -A OUTPUT -o $IF_RESEAU -p udp --dport 53    -j ACCEPT
/sbin/iptables -A OUTPUT -o $IF_RESEAU -p tcp --dport http  -j ACCEPT
/sbin/iptables -A OUTPUT -o $IF_RESEAU -p tcp --dport https -j ACCEPT

# On autorise les connexions deja etablies ou relatives a une autre connexion a sortir
/sbin/iptables -A OUTPUT -o $IF_RESEAU --match state --state ESTABLISHED,RELATED -j ACCEPT

# On autorise les connexions deja etablies a entrer
/sbin/iptables -A INPUT -i $IF_RESEAU --match state --state ESTABLISHED,RELATED -j ACCEPT

# On sauvegarde la configuration de iptables
/etc/init.d/iptables save

# On redemarre le service iptable pour prendre en compte la nouvelle configuration
/etc/init.d/iptables restart

# Chargement du module de gestion des connexion state
# (autorisation des connexions deja etablies a passer le firewall)
# Sur distrib ovh, pas possible car noyau monolitique
/sbin/modprobe ip_conntrack

Si vous utilisez ce script, désactivez le démarrage automatique d'IPTABLES au boot du serveur, cela vous évitera des problèmes :

chkconfig iptables off
chkconfig ip6tables off

Mais, il est important de garder à l'esprit que si quelqu'un pirate le serveur, il pourra potentiellement capturer l'ensemble de votre trafic en sortie (avec tcpdump par exemple). C'est un peu le revers de la médaille. Il est donc important d'avoir un serveur à jour et de continuer à utiliser vos méthodes traditionnelles de connexions sur les sites sensibles (ex: utilisation de HTTPS).

Les caractéristiques techniques de la machine sont tout simplement impressionnantes :

• 256 Processeurs Intel Atom Dual Core à 1,66 Ghz - architecture 64 bits
• 1 To de DRAM DDR3
• 8 cartes réseau de 8 ports Ethernet chacune (cf. cette photo)
• Stockage possible sur 64 Disques Dur ou SSD (format 2,5")
• Système de Load Balancing en Round Robin pour répartir la charge
• Peut gérer 1,28 Terabit de trafic par seconde
• Basse consommation (< 2,5 Kw)
• Format : 10 U

En revanche, je n'ai pas trouvé le prix du serveur, ça ne doit pas être donné.

Vous pouvez lancer ces deux commandes en une seule fois de la manière suivante (pensez également à adapter le login et l'adresse IP du serveur) :

dd if=/dev/zero of=test bs=100M count=1; scp test user@server:/dev/null;

J'obtiens par exemple un taux de transfert de 11 Mo/s chez moi entre deux machines câblées en 100 MB/s :

test      100%  100MB  11.1MB/s   00:09

Et un taux de 50 Mo/s entre deux machine câblées en 1 Gb/s :

test      100%  500MB  50.0MB/s   00:10

Dans un premier temps, lancez cette commande pour connaître la taille maximum autorisée dans Postfix :

# postconf -d | grep message_size_limit
message_size_limit = 10240000

Ici, la limite est de (10240000 / 1024) / 1024 = 9,76 Mo. Pour augmenter cette valeur, il suffit d'utiliser postconf de la manière suivante :

postconf -e 'message_size_limit = 20240000'

Puis, on recharge la configuration du serveur :

/etc/init.d/postfix reload

Pour finir, renvoyez vos mails et contrôlez que le message d'erreur n'apparaît plus dans le fichier /var/log/maillog.

Voici la vidéo de présentation :

P.S : J'ai bien aimé les vitrages par-balles, va falloir vous équiper d'un gros lance-roquettes si vous voulez voler un serveur.

Installation de Mod_evasive

Pour installer Mod_evasive sur une distribution à base de RPM (Red Hat, centOS, Fedora...), ouvrez un terminal et lancez la commande suivante en root :

yum install mod_evasive

Ou celle-ci pour une distribution à base de Debian :

sudo apt-get install libapache2-mod-evasive

Configuration basique de Mod_evasive

Toute la configuration de Mod_evasive se trouve dans le fichier /etc/httpd/conf.d/mod_evasive.conf (ou /etc/apache2/conf.d/mod-evasive pour une distribution à base de debian). Voici un exemple de configuration à utiliser :

<IfModule mod_evasive20.c>
  DOSHashTableSize 3097
  # Pas plus de 2 pages par seconde
  DOSPageCount 2
  DOSPageInterval 1
  # Pas plus de 150 requetes par seconde (images, CSS...)
  DOSSiteCount 150
  DOSSiteInterval 1
  # Periode en seconde pendant laquelle on bloque le client
  DOSBlockingPeriod 10
  # Dossier contenant les IP blaclistes
  DOSLogDir "/var/lock/mod_evasive"
</IfModule>

On met ensuite en place le dossier qui va stocker les adresses IP blacklistées :

mkdir -p /var/lock/mod_evasive
chown -R apache:apache /var/lock/mod_evasive

Et on relance le serveur Apache pour prendre en compte les modifications, avec cette commande pour une distribution à base de RPM :

/etc/init.d/httpd restart

Ou celle-ci pour une distribution à base de Debian :

/etc/init.d/apache2 restart

Pour tester le module, je vous recommande de mettre des valeurs assez faibles et de regarder ce qui se passe. Normalement, toutes les images de vos sites ne s'afficheront pas et le dossier /var/lock/mod_evasive devrait se remplir.

Pour finir, on peut mettre en place la crontab suivante pour puger le dossier de blacklist de temps en temps :

# Menage mod_evasive
00 5 * * * find /var/lock/mod_evasive -mtime +1 -type f -exec rm -f '{}' \;

Installation de Mod_security

Pour installer Mod_security sur une distribution à base de RPM (Red Hat, centOS, Fedora...), ouvrez un terminal et lancez la commande suivante en root :

yum install mod_security

Ou celle-ci pour une distribution à base de Debian :

sudo apt-get install libapache2-mod-security2

Configuration basique de Mod_security

Pour mettre en place la configuration minimale sur une distribution à base de Debian, il suffit de recopier le fichier d'exemple comme ceci :

sudo cp /usr/share/doc/mod-security-common/examples/modsecurity.conf-minimal /etc/apache2/conf.d/mod-security.conf

Pour une distribution à base de RPM (Red Hat, CentOS...), la configuration par défaut est déjà installée dans le dossier /etc/httpd/modsecurity.d.

L'étape suivante sera la mise en place de quelques options de base pour que le module fonctionne correctement. Voici un exemple de configuration à mettre à la fin du fichier /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf :

# On active mod_security pour tous les sites
SecRuleEngine On

# Signature du serveur
SecServerSignature "Skynet"

# On autorise mod_security a analyser
# le corps des requets et des reponses
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Taille maximum des requetes recues (128k)
SecRequestBodyLimit 131072

# Store up to 128 KB in memory
SecRequestBodyInMemoryLimit 131072

# Taille maximum des requetes de reponse (512k)
SecResponseBodyLimit 524288

# On indique un repertoire ou mod_security peut stocker des informations
SecDataDir "/var/tmp/modsecurity"

# Gestion des logs
# Les trois options sont On, Off et RelevantOnly
# Permet de ne journaliser que les requetes qui generent une alerte
SecAuditEngine RelevantOnly
# On precise quels statuts doivent etre journalise
# Ex: ^[45] log les erreurs 4XX et 5XX du serveur
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/httpd/modsecurity-audit.log

# Gestion du log de debuggage
SecDebugLog /var/log/httpd/modsecurity-debug.log
SecDebugLogLevel 0

On créé ensuite le répertoire qui contiendra des informations pour Mod_security :

mkdir /var/tmp/modsecurity
chown -R apache:apache /var/tmp/modsecurity

Et on relance Apache pour prendre en compte les modifications :

/etc/init.d/httpd restart

Et on scrute les fichiers de logs pour détecter les éventuels problèmes :

tail -f /var/log/httpd/modsecurity-audit.log
tail -f /var/log/httpd/error_log

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 :

• saisir "OR 1=1" dans un champ de recherche
• ajouter "<script>xss</script>" à la fin d'une url du site
• ajouter "/../../etc/passwd" à la fin d'une url du site
• ...

Pensez également à tester les formulaires légitimes. Par exemple, l'ajout de commentaires pour un site à base de WordPress, ou l'ajout de message sur un forum doivent fonctionner normalement.