Grâce à la contribution de Fréderic Jean, le script Perl Nagisk que j’avais développé il y a quelques temps passe en version 1.2. Cette nouvelle mouture apporte les nouveautés suivantes:
adaptation du script pour Asterisk version 1.6.13.2
modification de la commande pour avoir les informations sur les channels (« core show channels »)
ajout de l’option -p pour spécifier un peer
Pour rappel, Nagisk est un plugin pour Nagios permettant de récupérer, via NRPE, des informations sur votre serveur Asterisk (serveur PABX software).
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.
Il existe, sur le très juteux marché des outils réseaux pour le système d’informations, un grand nombre de logiciels permettant de calculer cette gigue de manière très précise. Malheureusement, la plupart sont trop chers car ils font beaucoup plus que ce que l’on veut faire.
Nous allons donc aborder dans ce billet deux techniques (mais il en existe d’autres) pour calculer simplement la gigue entre deux points de votre réseau en se basant sur des logiciels libres. Ces deux points pouvant se trouver sur le même réseau LAN ou bien séparés par des réseaux WAN (Internet, VPN dédié…).
Mesure de la gigue en utilisant IPerf
L’avantage de cette première technique est que Iperf est disponible sous Windows. Donc si votre réseau est composé de PC sous cet OS, il n’y aura pas de PC à déplacer pour faire vos tests.
Je pars sur le principe ou vous avez IPerf installé sur les deux postes (#A et B) de chaque coté dur réseau à valider.
Sur le PC #A:
iperf -s -u -i 1
Sur le PC #B:
iperf -c IP-A -u -i 1 -b 64K -t 60
PS: remplacer IP-A par l’adresse IP ou le nom d’hôte de la machine #A.
Par exemple, le résultat (à lire sur la dernière ligne, coté #B) sur ma liaison Internet donne:
J’ai donc une gigue moyenne de 2.563 ms (pour 1.5% de paquets perdus).
Mesure de la gigue en utilisant SJitter
SJitter est un programme que j’ai développé il y a maintenant quelques années mais qui me sert toujours pour effectuer les mesures de gigue. Contrairement à IPerf, il n’est disponible que sous GNU/Linux.
J’ai donc une gigue moyenne de 4.36 ms (la liaison était clairement plus chargée au moment de ce test).
Que faire des résultats ?
Il convient, selon vos système de ne pas avoir une gigue supérieure à 30ms (bien que les systèmes de VoIP et de codecs dernières générations accepte des gigue pouvant aller jusqu’à 50ms). Une bonne idée est également de surveiller cette gigue tout au long de l’année (par exemple en écrivant un petit script pour votre serveur Nagios).
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:
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.
Ce billet a été rédigé par Tony Roger (de la société LibrA-LinuX) en collaboration avec OpenSVC éditeur du logiciel libre du même nom.
LibrA-LinuX, spécialiste des formations Linux à la carte, propose des stages, afin de permettre à des utilisateurs de tous niveaux (débutants ou confirmés), d’aborder sereinement l’utilisation et l’administration de systèmes Linux (Debian, Ubuntu, RedHat, Fedora..). Dans le contexte d’un nouveau cursus de courslié aux technologies de Clustering sous Linux, nous vous proposons cet article ayant pour but de présenter une solution de clustering sous Linux, permettant de mettre en oeuvre simplement une architecture pour apporter la haute-disponibilité à vos applications critiques.
A l’instar des solutions existantes du monde libre (Linux HA) , cette solution utilise le logiciel libre OpenSVC (produit Français) qui, couplé à un mécanisme de bascule automatique (HeartBeat, Keepalived, OpenHA) permet une gestion centralisée de vos services sous Linux, indépendamment des couches applicatives (Services web apache, J2EE, base de données, stockage et serveurs de fichiers, messagerie, DNS ,LDAP …). L’atout majeur de cette solution consiste en cette couche d’abstraction (technologie de clustering autour d’OpenSVC) qui permet comme tout type de cluster actif/passif, le pilotage des ressources et services, la reprise de vos services en minimisant le temps d’interruption grâce au mécanisme de bascule automatique, mais garantit également la cohérence des données entre les noeuds du cluster, par la synchronisation de snapshots filesystem LVM.
Introduction
OpenSVC (framework python sous licence GPLv2) est un gestionnaire de « services » fonctionnant en mode cluster. Les services sécurisés sont définis comme des ensembles de ressources (IP, Volume de Disques, Filesystems, synchronisations, et lanceurs d’applications). Ces services sont ainsi pilotés via opensvc installé sur chacun des noeuds du cluster et compatible avec toutes les distributions Linux, FreeBSD, les unix Solaris et Opensolaris, HP-UX, AIX.
Dans le cadre d’un déploiement massif du framework OpenSVC, les développeurs du produit ont conçus un collecteur central, contenant la configuration des services, leurs états et les journaux d’actions de chacun des noeuds, que l’on peut consulter grâce à une interface web. La partie collecteur est quand à elle non libre et soumise à une tarification de licence par service /an, mais celle-ci n’est pas nécessaire au bon fonctionnement du cluster.
Les services typiques qui peuvent bénéficier d’une haute-disponibilité grâce à l’implémentation de cette solution sont :
Serveurs de fichiers et stockage : FTP, SAMBA, LV…
Serveurs de noms : DNS
Serveurs d’annuaire : LDAP
Base de données : Oracle, MySQL, PosgreSQL
etc …
Fonctionnalités et architecture
Les principales fonctionnalités et avantages que fournit ce gestionnaire de cluster Linux :
Scalabilité et mutualisation : permet de gérer des milliers de noeuds et services basés sur une seule et même technologie de clustering.
Compatibilité : OpenSVC fonctionne aujourd’hui sur les OS Linux, FreeBSD, Solaris, OpenSolaris, AIX et HP-UX et peut aisément être portés sur d’autres systèmes d’exploitation (python).
Cohérence des données entre des noeudssans stockage partagés : Permet de piloter les réplications des données par snapshot de filesystems LVM et synchronisation rsync, ZFS et réplication DRBD, mais également les systèmes de stockage (EMC SRDF, NetApp snapmirror). L’idéal pour un cluster OpenSVC étant 2 noeuds de production (PRD) en shared disk, avec un noeud de reprise (DR) en copie asynchrone.
Virtualisation : OpenSVC peut piloter des services eux-mêmes intégrés sous forme de machines virtuelles ou containers (kvm, xen , lxc, zones, jail, oracle Ldoms…)
Haute-disponibilité : La haute-disponibilité et la reprise des services est apportée par la compatibilité avec les mécanismes standards de bascules automatiques et battement de coeur (OpenHA, heartbeatd, keepalived). Gestion des IP virtuelles de service. Possibilité de définir des plans de reprise (Disaster recovery plans) dans la configuration des services.
Déploiement : Rapidité de déploiement des outils OpenSVC et des créations des containers de services
Standard et Open source: Le framework OpenSVC est sous licence GPLv2, le collector est quant à lui soumis à un système de licence
Tracabilité et audit : toutes les commandes executées par OpenSVC sont inscrites dans des journaux de logs en local sur chaque noeud, mais également centralisés sur le collector
Supervision: Remontée d’alertes mail, et flux RSS, intégration facilitée pour la remontée d’alertes vers des systèmes de supervision
Gestion centralisée (collecteur)
Le collecteur est une interface web de gestion de vos différents services clusterisés qui, au travers de différentes vues et tableaux de bords, apporte des fonctionnalités supplémentaires :
monitoring : pour afficher l’état des différentes ressources des services à l’aide d’un tableau de bord (graphique dynamique de la topologie de vos services)
audit : vous permettant de visualiser les journaux de logs des actions entreprises par OpenSVC et d’agir en conséquence
plan de reprise : pour concevoir des plans de reprise (disaster recovery plans)
délégation d’administration : possibilité d’assigner des responsables à des services ou groupe de services, aiguillage des alertes
nodes (asset): pour paramétrer les différentes informations matérielles et de géo-localisation de vos noeuds physiques, afin de pouvoir déterminer le périmètre des services impactés par un incident (fuite sur un rack…)
audit et performance système : pour monitorer les ressources systèmes (I/O, Mem, CPU …) de chacun des noeuds, les incohérences de paquetages entre les noeuds d’un service
alertes: pour visualiser les différentes remontées d’alertes du systèmes, et les gérer en ligne.
Mise en oeuvre
L’installation d’OpenSVC nécessite pyhton2.6 comme pré-requis et les packages pour CentOS, RedHat, Debian et Ubuntu sont disponibles dans le repository d’OpenSVC.
NutTCP est un outil de plus pour les administrateurs réseaux afin de mesurer simplement les liaisons entre deux machines (ou vers votre serveur dédié ou VPS sous GNU/Linux|BSD).
Installation de NutTCP
Rien de plus simple sous Debian ou Ubuntu:
sudo aptitude install nuttcp
Le logiciel se présente sous la forme d’un unique exécutable (nuttcp) qui fait office de client et de serveur selon les options qui lui sont accolés.
Un premier test basée sur TCP
Nous allons donc tester le réseau se trouvant entre deux machines (A et B soyons originaux). Nous utiliserons dans ce premier exemple un test basé sur le protocole TCP.
Sur la machine A, on lance le « serveur »:
A# nuttcp -S –nofork
Puis sur la machine client on va générer un flux TCP dans le sens B vers A (l’équivalent d’un upload). NutTCP va utiliser les ports TCP/5000 (pour le contrôle) et TCP/5001 (pour le transfert proprement dit des données). Il faut donc bien vérifier que ces deux ports sont ouverts entre vos deux machines.
Dans mon test, on obtient donc un débit de 401 Kbps (0.4013 Mbps).
Pour faire le même test mais dans le sens A vers B (c’est à dire un download):
B# nuttcp -b -r @IP_A
Il est possible d’ajouter certaines options:
-l : taille du buffer de lecture et d’écriture
-w : taille du buffer permettant de définir la taile de la fenêtre TCP
Un autre test basée sur UDP
Contrairement à TCP qui utilise la totalité de la bande passante disponible, le débit des flux UDP doit être fixé au niveau de l’application. On doit donc ajouter deux options:
-u : pour forcer NutTCP à travailler en UDP
-R <debit> : pour fixer le débit du flux UDP à <debit> Kbps
Sur la machine A, on lance le « serveur » comme pour le mode TCP:
Suite à un commentaire de Xavier sur un de mes billets, je me suis penché sur l’utilisation de RSnapshot. Ce logiciel libre permet d’automatiser une sauvegarde journalisée de vos machines et ceci localement comme à distance.
RSnapShot est disponible dans la plupart des dépôts des distributions GNU/Linux et *BSD. Nous allons illustrer cet article avec une installation et une configuration de RSnapShot sur un serveur Gandi sous Ubuntu 10.04 LTS.
Installation de RSnapShot
On utilise la version disponible dans les dépôts officiel:
sudo aptitude install rsnapshot
Configuration de RSnapShot
L’ensemble de la configuration est centralisé dans le fichier /etc/rsnapshot.conf.
sudo vi /etc/rsnapshot.conf
Attention à la syntaxe dans ce fichier, RSnapShot est assez pointilleux. Il veut que tout les répertoires finissent par un / et des tabulations entre chaque variables.
Les variables importantes à configurer sont les suivantes:
snapshot_root /.snapshots/
La variable snapshot_root permet de configurer le répertoire racine ou les sauvegardes seront stockées. Ce répertoire peut être sur le même disque que le disque système (c’est le cas de la configuration par défaut avec l’utilisation du répertoire /.snapshots/).
Je vous conseille pour ma part d’utiliser si possible un répertoire stocké sur un deuxième disque physique. Par exemple sur mon serveur Gandi, j’ai un deuxième disque qui est monté sur le répertoire /srv/backup. Je vais donc configurer la variable à /srv/backup/snapshots/ (noter le / à la fin du répertoire !).
Exemple: snapshot_root /srv/backup/snapshots/
cmd_ssh /path/to/ssh
Si vous voulez utiliser les fonctions de sauvegarde de serveur distant (en utilisant le protocole SSH), il faut dé-commenter la ligne précédente. Si vous avez besoin de passer des arguments spécifique à SSH, il faudra compléter la ligne ssh_args.
Exemple: cmd_ssh /usr/bin/ssh
interval monthly 3
Activation de la sauvegarde mensuelle (désactivé par défaut).
On passe ensuite aux variables permettant de configurer ce que l’on veut sauvegarder.
Sauvegardes locales
On parle ici d’une sauvegarde journalisée de répertoires de la machine ou RSnapShot est installé.
backup /home/ localhost/
Le répertoire /home/ sera sauvegardé dans le sous répertoire $snapshot_root/localhost/.
Exemple:
backup /home/ localhost/
backup /etc/ localhost/
backup /var/svn/ localhost/
Sauvegardes distantes
On peut également sauvegarder des répertoires de machines distantes. On utilise pour cela la configuration suivante:
On va ainsi sauvegarder le répertoire /etc/ de la machine exemple.com en utilisant une connexion SSH avec l’utilisateur root (il faut bien sur que la connexion SSH entre votre machine exécutant RSnapShot et example.com soit automatisée). En bonus on demande à RSnapShot de ne pas sauvergarder les fichiers core (exclude=core) et de limiter la bande passante à 1 Mbps (–bwlimit=1024).
Sauvegardes en utilisant des scripts
Une autre fonctions intéressantes de RSnapShot est la possibilité d’utiliser des script shell pour automatiser des sauvegardes un peu plus complexes.
Par exemple imaginons que l’on veuillent sauvegarder les données de son serveur SVN. On commence par créer le script shell /usr/local/bin/backup-svn.sh:
Au début du mois nous avons vu ensemble l’installation d’un serveur NGinx sous Ubuntu. Sous Debian, il faut mettre un peu plus les mains dans le cambouis, en effet il est parfois utile de partir des sources plutôt que des dépôts officiels (notamment au niveau de la présence ou non d’un module).
J’ai donc développé un petit script shell pour automatiser l’installation (ou la mise à jour) d’un serveur Web rapide, léger et performant sous une Debian (Squeeze ou Lenny).
Ce script va effectuer les choses suivantes:
installer la dernière version stable de NGinx (voir le numéro de version ici).
Il est bien sûr possible d’adapter ce script à vos besoins et de l’utiliser comme bon vous semble. Si vous rencontrez des erreurs ou que vous avez en tête des améliorations possibles, merci de laisser un commentaire en bas de ce billet.
Il faut lancer le script en root (droit d’administration):
su - -c "$PWD/nginxautoinstall.sh"
Si tout se passe correctement, le script devrait afficher:
Validation et test de performances
Votre serveur est maintenant opérationnel, il vous reste à mettre vos page HTML et scripts PHP dans le répertoire /var/www et tester le tout en entrant l’URL suivante dans un navigateur Web: http://@devotreserveur/.
Vous pouvez également tester les performances brutes de votre serveur en utilisant HTTPerf (disponible dans les dépôts Debian). Sur mon serveur de test (VPS Gandi 1 part), j’obtiens les perfos suivantes:
Avec NGinx, on obtient rapidement de très bonnes performances et le couple PHP-FPM, MemCached permet d’avoir une bonne base pour héberger, par exemple, votre blog WordPress (lire l’article sur le sujet dans ce blog).
Je suis bien sur preneur de tous commentaires/remarques sur le script.
WordPress n’a pas forcement bonne presse au niveau de la sécurité. Le coeur PHP du moteur WordPress est pourtant surveillé de très près et les corrections des failles sont assez rapides (voir par exemple la publication de la version 3.0.4).
Par contre les plugins, qui sont un avantage indéniable de WordPress par rapport aux autres CMS, sont également un talon d’Achille… En effet, WordPress dispose d’une base de plugins impressionnante (plus de 12.700 au moment de l’écriture de ce billet) dont les développeurs sont plus ou moins sensibilisés à la problématique de la sécurité… Ajouter des plugins à votre blog, c’est multiplier les risques au niveau de la sécurité.
Dans ce billet, nous allons voir comment installer puis configurer WordPress pour compliquer la tache des personnes voulant attaquer votre blog.
Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #3):
Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).
Partir sur de bonnes bases
Nous allons détailler l’installation, la configuration initiale puis la gestion des mises à jours de WordPress.
Installation de WordPress
Personnellement j’utilise sur mon serveur deux versions de WordPress en parallèle.
La première est celle du blog « de production » (celui que vous êtes en train de lire) utilise la version stable SVN (c’est à dire la 3.0.4 au jour d’aujourd’hui). J’utilise la commande suivante pour effectuer l’installation (dans le répertoire racine de mon serveur Web: /var/www/blog):
svn co http://core.svn.wordpress.org/branches/3.0/
La seconde, dite « de validation » me sert pour tester mon blog (thème et plugins) sur les futures versions de WordPress (3.1 par exemple). Elle n’est pas publique, seul les administrateurs peuvent y accéder. Pour installer cette version de WordPress, j’utilise la commande suivante dans un deuxième répertoire de mon serveur Web (/var/www/blogfutur):
svn co http://core.svn.wordpress.org/trunk/
Avant de suivre la fameuse installation en 5 minutes de WordPress, je vous conseille de changer le préfixe des tables MySQL en éditant la ligne suivante dans votre fichier de configuration wp-config.php et en remplacant wp_ par une chaine aléatoire (par exemple apvbty_):
$table_prefix = ‘apvbty_’;
Attention, cette manipulation est à faire seulement sur un nouveau blog. En effet, si vous avez déjà une base de donnée SQL existante il faut d’abord changer le nom du préfixe des tables dans MySQL (voir hack en fin de billet) sous peine de ne plus pouvoir accéder à vos données.
Une fois l’installation de WordPress finalisée, nous allons commencer par fixer les droits au niveau des fichiers dans ces répertoires. En partant sur l’hypothèse ou votre serveur Web tourne sous l’utilisateur www-data et dans le répertoire /var/www/blog, j’utilise les commandes suivantes:
chown -R www-data:www-data /var/www/blog
find /var/www/blog -type d -exec chmod 755 {} \;
find /var/www/blog -type f -exec chmod 644 {} \;
chmod 640 /var/www/blog/wp-config.php
find /var/www/blog/wp-content/themes -type d -exec chmod 775 {} \;
find /var/www/blog/wp-content/themes -type f -exec chmod 664 {} \;
Pour vous simplifier la vie, je vous conseille de mettre ces commandes dans un script shell afin de pourvoir rapidement les appliquer sur votre arborescence.
Mise à jour de WordPress
Comme nous l’avons vu, les développeurs de WordPress sont assez réactifs sur la correction des failles de sécurité. Encore faut-il que vous pensiez à mettre à jour votre instance de WordPress…
J’utilise un script shell pour mettre à jour WordPress à partir de SVN:
#!/bin/bash
# Simple script pour mettre a jour WordPress
# Test que le script est lance en root
if [ $EUID -ne 0 ]; then
echo « Le script doit être lancé en root: # sudo $0″ 1>&2
find $WPPATH/wp-content/themes -type d -exec chmod 775 {} \;
find $WPPATH/wp-content/themes -type f -exec chmod 664 {} \;
echo « 3) Fin de la mise a jour »
echo « En cas de pb: svn update -r$CURRENTVERSION »
Il est possible de lancer ce script toutes les nuits (par exemple par crontab) pour éviter de se retrouver avec un blog hacké quand vous partez en congés…
Le .htaccess
Ce fichier qui doit se trouver à la racine de votre site Web, contient des entrées utiles à la sécurité de votre site. Le mien commence par:
# MAIN
RewriteEngine On
ServerSignature Off
Options All -Indexes
Options +FollowSymLinks
# SVN protect
RewriteRule ^(.*/)?\.svn/ – [F,L]
# Secure .htaccess
<Files .htaccess>
Order Allow,Deny
Deny from all
</Files>
# Secure wp-config.php
<Files wp-config.php>
Order Deny,Allow
Deny from all
</Files>
# FILTER REQUEST
<IfModule mod_rewrite.c>
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
Certains plugins ajoutent pas mal de chose dans ce fichier (notamment W3 Total Cache, le plugin d’optimisation des performances que j’ai abordé dans ce billet).
Un peu de bon sens…
Vous avez donc entre les mains une installation toute propre et sécurisée de WordPress, c’est normalement à partir de ce moment là que les choses se gâtent…
On commence par l’erreur de base: ne pas utiliser un mot de passe « strong » pour le compte admin. Encore mieux, créer un nouveau compte administrateur et supprimer le compte admin par défaut.
L’installation des plugins apportent également son lot de failles de sécurité. C’est là qu’il faut se faire violence et n’installer que les plugins indispensables au bon fonctionnement de votre blog. Il faut également veiller à mettre à jour régulièrement vos plugins (l’interface d’administration de WordPress permet de faire cela très simplement).
Enfin vos thèmes peuvent également fragiliser votre blog en insérant des codes PHP ou JS. Si vous avez les compétences il faut faire un audit de votre thème ou au minimum utiliser des thèmes connus et validés.
Des plugins pour la sécurité
Parmis ces plugins, j’en utile trois dédiés à la sécurisation:
Secure WordPress permet d’automatiser certaines actions pour sécuriser votre blog.
WordPress File Monitor: Surveille les fichiers du moteur WordPress et vous alerte (par mail et/ou directement dans l’interface d’administration de WordPress) en cas de modification.
On peut également citer WordPress Security Scan qui permet de faire un audit de votre blog en testant notamment les droits de vos fichiers, les mots de passes, la base de données…
Quelques hacks en bonus
Compliquer la tache des attaques par force brute en supprimant l’indicateur (« mauvais mot de passe ») lors d’une tentative de connexion à l’interface d’administration. Il faut juste ajouter la ligne suivante à votre fichier functions.php (thème):
Si vous avez une base de données MySQL existante avec le préfixe par défaut (wp_) et que vous souhaitez le changer, il est possible de faire celà directement à la main par une requête MySQL ou alors plus simplement en utilisant le plugin WP-Security-Scan.
Tester votre WordPress
Pour tester la sécurité de votre blog, rien ne vaut une simulation d’attaque. Pour celà vous pouvez utiliser le logiciel libre Nikto.
On commence par installer Nikto sur un PC client sous Ubuntu (qui va simuler l’attaque):
sudo aptitude install nikto
Puis on lance le test (remplacer URL par l’URL de votre blog WordPress):
En début de semaine, j’ai été emmenée à donner un cours d’introduction aux technologies de Cloud Computing à l’école supérieure des ingénieurs de Luminy (ESIL à Marseille). Le sujet étant vaste pour les trois petites heures imparties, j’ai préféré axer mon cours sur certains aspects (notamment les architectures IAAS et l’utilisation de technologies ouvertes et libres).
Pour ceux que cela intéresse, voici (sous licence « CC By:« ):
NGinx est une des alternative au serveur Web Apache (il est actuellement utilisé par plus de 6% des serveurs Web). Il se targue d’être plus rapide, plus léger et facile à configurer.
Nous allons vérifier tout cela dans ce billet en détaillant une installation de NGinx 0.8.54 (Stable) sur une machine GNU/Linux (Ubuntu Desktop 10.10) avec en bonus le support FastCGI de PHP et de Perl !
Installation de NGinx
On commence par ajouter le dépôt officiel pour la version stable:
sudo add-apt-repository ppa:nginx/stable
sudo aptitude update
Puis on installe la bête (facile non ?):
sudo aptitude install nginx
Remarque: si un serveur Web (Apache ou autre) tourne déjà sur votre machine, l’installation de NGinx se passera normalement, par contre il n’arrivera pas à se lancer car le port HTTP par défaut (TCP/80) sera déjà occupé. La solution la plus propre est de configurer NGinx pour qu’il écoute sur un autre port (TCP/81 par exemple) puis faire vos tests en forcant l’utilisation de ce port dans votre navigateur Internet (en ajoutant :81 aux URL). Une fois Nginx validé, il suffira de supprimer l’autre serveur Web de votre machine, puis de reconfigurer Nginx sur le port par défaut (TCP/80).
Premier contact avec NGinx
Un script de démarrage nommé nginx a été installé dans le répertoire /etc/init.d. On peut voir la liste des commandes accepté par ce script en saisissant la ligne de commande suivante:
On ouvre un navigateur sur la même machine puis on entre l’UTL suivante: http://localhost/
La page suivante devrait s’afficher:
On peut ensuite arrêter le serveur:
sudo service nginx stop
Stopping nginx: nginx.
Puis passer à l’étape suivante…
Configuration du serveur NGinx
Les fichiers de configuration se trouvent dans le répertoire /etc/nginx. Les habitués d’Apache ne seront pas trop perturbés par la structure de l’arborescence de ce répertoire:
conf.d/: un répertoire contenant des fichiers de configuration additionnels
sites-available/: répertoire contenant la liste des fichier de configuration des sites disponibles
sites-enabled/: répertoire contenant la liste des fichiers de configuration des sites actifs (liens symboliques vers le répertoire site-availables)
On commence par jeter un coups d’oeil au fichier nginx.conf…. Quel bonheur par rapport à celui d’Apache :).
On passe ensuite au fichier du site par défaut /etc/nginx/sites-available/default (que l’on a activé tout à l’heure par la commande ‘sudo service nginx configtest’):
server {
listen 80
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {
try_files $uri $uri/ /index.html;
}
location /doc {
root /usr/share;
autoindex on;
allow 127.0.0.1;
deny all;
}
location /images {
root /usr/share;
autoindex off;
}
}
On peut donc voir que l’on a un site qui écoute sur le port TCP/80 (listen 80) et sert les pages se trouvant dans le répertoire /usr/share/nginx/www (root /usr/share/nginx/www) à partir de l’URL http://localhost/ (server_name localhost).
Nous allons nous baser sur cet exemple pour construire un nouveau fichier de configuration propre à nos besoins.
On commence par créer l’arborescence qui va héberger nos pages (par exemple /home/labo/www). Si le répertoire n’existe pas il faut le créer et lui donner les bons droits:
mkdir /home/labo/www
Enfin on édite une page de test:
# vi /home/labo/www/index.html
<html><body>Ma page</body></html>
Ensuite on passe à la création du fichier de configuration du site.
sudo vi /etc/nginx/sites-available/monsite
Avec le contenu suivant (à adapter à votre configuration):
# Mon site a moi
server {
listen 80;
root /home/labo/www;
index index.html index.htm;
server_name localhost;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to index.html
try_files $uri $uri/ /index.html;
}
}
On supprime le site par defaut et on active le notre:
cd /etc/nginx/sites-enabled
sudo rm default
sudo ln -s ../sites-available/monsite
On redémarre le serveur Nginx:
sudo service nginx restart
Restarting nginx: nginx.
Puis on teste la page: http://localhost/
Pour rendre le site « visible depuis l’extérieur », il faut changer la ligne:
server_name localhost;
Puis la remplacer par:
server_name www.mondomaine.com;
Il faut bien sur que le nom www.mondomaine.com pointe sur l’adresse IP de votre serveur Nginx…
Test des performances
Pour voir ce qu’il a dans le ventre, j’ai installé en Nginx et Apache sur ma machine. Nginx écoutant sur le port TCP/81 et Apache sur le port TCP/80.
J’ai ensuite utilisé le logiciel httperf (disponible dans les dépôts Ubuntu) pour simuler des requêtes sur le serveur.
On a donc un gain d’environ 30% en terme de requêtes supportées par le serveur.
Request rate / Request number
Support du PHP
De nos jours, un serveur Web sans support PHP c’est un peu comme un Ferrari avec des roues de 13 pouces. Dans l’optique d’avoir un serveur performant nous allons donc utiliser le module externe PHP FPM (PHP FastCGI) qui s’occupera de l’exécution des scripts PHP dans un processus indépendant de NGinx (merci à cet article qui m’a bien aidé).
Par défaut, le processus PHP-FPM va se mettre en écoute sur le port TCP/9000 et écouté les requêtes venant seulement de la machine locale (localhost).
Il ne reste plus qu’à modifier le fichier de configuration de votre site pour prendre en compte le langage PHP (fichier /etc/nginx/sites-available/monsite):
# Mon site a moi
server {
listen 80;
server_name localhost;
root /home/labo/www;
location / {
index index.php index.html;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
}
}
Attention de bien avoir configurer la variable root (« root /home/labo/www » dans mon exemple), sinon vous risquez de tomber sur une erreur 404 lors du passage du script PHP vers le process PHP-FPM.
On relance ensuite Nginx:
sudo service nginx restart
Restarting nginx: nginx.
Pour tester que le PHP fonctionne bien, le plus simple est de créer un fichier info.php (à mettre à la racine du site /home/labo/www/) contenant:
<?php
phpinfo();
?>
Puis de pointer votre navigateur Web vers l’URL: http://localhost/info.php
La page suivante devrait s’afficher:
Support de Perl
Tout comme PHP, nous allons utiliser FastCGI pour exécuter les scripts Perl depuis notre serveur NGinx. Le principe est le même. Un processus (fastcgi-wrapper.pl) va se mettre en écoute sur le port TCP/8999 puis attendre les demandes d’exécution envoyées par NGinx.
Contrairement à PHP, il n’existe pas (encore) de package Ubuntu permettant d’automatiser l’installation de ce processus. Il faut donc mettre un peu les mains dans le cambouis (merci à ce blog) !
On commence par installer le module Perl FCGI sur lequel le processus fastcgi-wrapper.pl va se baser:
sudo perl -MCPAN -e ‘install FCGI’
On installe le processus fastcgi-wrapper.pl qui va s’occuper de l’exécution des scripts Perl:
La plupart des tutos que j’ai trouvé sur le Net utilise ensuite un script init.d pas très beau à voir (http://lindev.fr/public/nginx/perl-fastcgi). En effet, pour arrêter le processus on a droit à un beau killall -9 perl ! Autant dire que si vous avez d’autres processus Perl en tache de fond de votre serveur cela risque de poser quelques problèmes :). J’ai donc écrit un nouveau script basée sur celui du wrapper PHP.
On automatise le lancement de ce script au démarrage du serveur: