Nous voici donc dans le dernier volet de notre saga sur la sécurisation d'un serveur Web hébergeant un blog WordPress. Si vous avez suivi les recommandations des billets précédant vous devriez  avoir un serveur avec un niveau de sécurité acceptable...

La perfection n'existant pas, du moins en sécurité informatique, il est nécessaire d'avoir sous la main les moyens de remonter rapidement votre serveur en cas de piratage.

Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #4):

• #1 - Sécurisation du système d'exploitation
• #2 - Sécurisation du serveur Web Apache et du moteur PHP
• #3 - Sécurisation de WordPress
• #4 - Sauvegarde, maintenance et supervision du serveur

Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (un dernier grand merci à lui ).

Sauvegardes régulières

En effet, quelque soit les moyens que vous aller mettre en oeuvre, votre serveur ne sera jamais protégé à 100%. Il est donc essentiel d'avoir une sauvegarde récente de l'ensemble de votre blog, c'est à dire:

• vos fichiers statiques (images, videos, fichiers de données...)
• votre base de donnée SQL
• une procédure (ou encore mieux un script comme celui-ci) à jour de réinstallation de votre serveur

Voici donc le détail de ces actions.

Sauvegarde des fichiers statiques

J'effectue cette sauvegarde en deux étapes.

1) La première est un backup de l'ensemble de mon répertoire Web (contenant WordPress et les fichiers statiques) sur un deuxième disque qui est attaché à mon serveur virtuel (VPS). Ainsi en cas de crash disque, les données seront disponibles localement. Attention de bien vérifier auprès de votre hébergeur que ce deuxième disque virtuel est bien sur un disque physique différent de celui sur lequel est hébergé votre blog !

J'utilise le logiciel RSnapShot pour effectuer cette tache. J'ai rédigé un billet sur le sujet que vous pouvez consulter ici.

2) La seconde étape est de copier de manière régulière (et si possible automatique) ces sauvegardes sur une autre machine. En effet, si un méchant hackeur pirate votre serveur, il y a de fortes chances qu'il s'en prenne également à vos sauvegardes locales.

Pour cela, j’utilise le service "in the cloud" Dropbox (en attendant un service équivalent basée sur des clients libres). Pour installer et utiliser Dropbox sur un serveur sans interface graphique, vous pouvez suivre cette procédure. J’archive avec une commande tar l’ensemble du répertoire WordPress puis je le copie dans un sous répertoire de ma Dropbox.

Sauvegarde de la base de donnée SQL

J'utilise le plugin WordPress WP-DBManager qui, en plus d'optimiser automatiquement ma base de donnée,  sauvegarde et envoi une archive directement sur mon adresse mail (la fréquence des expéditions est configurable).

Il est également possible d'automatiser une commande mysqldump dans votre crontab systeme et comme les fichiers statiques copier l'archive dans une copie locale et dans votre Dropbox.

Re-installation rapide de son serveur "from scratch"

Ce point est souvent négligé, à tort !

Quoi de plus long que de ré-installer et re-configurer un serveur en production sous la pression du temps... Avoir un script qui reproduit ces étapes de configuration est plus qu’utile en cas de problème : piratage ou bien panne matérielle. En cas de piratage, il faudra évidemment chercher la cause du problème et la résoudre avant de remettre son serveur en ligne et bien entendu modifier tous les mots de passes (système, WordPress, base de donnée SQL...).

Maintenance et supervision

Dans la première partie de cette série de billets, nous avons installé le logiciel cron-apt qui envoie automatiquement un mail quand des mises à jour son disponible pour votre serveur. Il faut bien sûr prendre le temps de lire ces mails et de les traiter le cas échéant.

On peut également installer le logiciel log-watch qui surveiller pour vous les fichiers de log et envoyer automatiquement un rapport par mail. J'ai personnellement laissé tombé ce type de logiciel sur mon serveur personnel car la quantité des informations remontées nécessitait trop de temps pour être interprétée . Dans le même ordre d'idée il y a également logcheck qui permet de recevoir un rapport toutes les heures sur les lignes "anormales" trouvées dans les logs.

aptitude install logcheck

Le fichier de configuration se trouve dans /etc/logcheck/logcheck.conf. La liste des fichiers de log à surveiller dans /etc/logcheck/logcheck.logfiles.

Il faut également surveiller les rootkit (petit programme permettant d'obtenir les droits d'administration de votre serveur en se basant sur des failles connues). Pour cela il faut installer un détecteur de rootkit comme  chkrootkit:

sudo aptitude install chkrootkit

Puis le lancer régulièrement (le plus simple est de le faire par crontab et d'envoyer le résultat par mail).

sudo chkrootkit

A noter que dans la version actuelle de chkrootkit (0.49). Un faux positif est détecté sous Ubuntu 10.04 LTS dans le fichier /etc/init:

Searching for Suckit rootkit... Warning: /sbin/init INFECTED

Le message est donc à ignorer jusqu'à la prochaine mise à jour.

Pour conclure ce chapitre quelques logiciels que l'on peut installer:

• tmpreaper : vider le /tmp régulièrement
• vérifier l’intégrité des fichiers systèmes avec Samhain (disponible dans les dépots Ubuntu).

Conclusion

Vous l’aurez compris, sécurisé son système prend du temps, consomme des performances non négligeables et demande des connaissances approfondies. C’est néanmoins une étape fondamentale pour se protéger des pirates et autres scripts automatisés qui se feront une joie de rentrer dans votre site web ou pire, votre serveur.

Les applications présentées devraient néanmoins vous permettre de limiter la casse, mais gardez à l’esprit que la plupart des attaques se faisant via votre site web, le protéger correctement reste une des meilleurs solutions existantes.

/etc/logcheck/logcheck.conf