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):
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
Pour certaines applications, notamment la voix sur IP, la variation du délais de transit (aussi appelée gigue) est une des caractéristique les plus importante à étudier avant une installation et à superviser à travers le temps.
LibrA-LinuX, spécialiste des
