Sécuriser son blog WordPress #1

Date: 13/12/2010 | Catégories: Blog,Open-source,Planet-libre,Reseau,Systeme | Tags: ,,,,,,

Il n'y a rien de plus rageant que de se faire pirater son blog. En plus de réduire à néant notre amour propre, cela peut avoir, dans le cas d'une indisponibilité prolongée, des impacts non négligeables sur le "saint" référencement dans gOOgle et donc sur le trafic sur votre site (je suis bien placé pour en parler...).

Après avoir détaillé l'installation d'un blog WordPress sur un serveur VPS Gandi Ubuntu Server puis optimiser ce dernier en 12 étapes, nous allons donc aborder des techniques permettant de protéger votre blog WordPress hébergé sur un serveur dédié ou virtuel (mais un bon nombre de ces techniques sont aussi applicables sur n'importe quel site Internet). Il faut garder à l'esprit que cela ne garantira en rien une protection efficace à 100%. Si une personne compétente décide de pirater votre site, il y a de fortes chances qu'elle réussisse. Par contre, ces techniques vous protégeront sûrement d'une grande majorité des attaques lancées via des "script kiddies".

Cet article va être découpé en plusieurs billets (vous êtes en train de lire le #1):

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

Sécurisation du système d'exploitation

C'est la base de votre infrastructure. Ici, pas la place pour des systèmes d'exploitations (OS) de comique. Il faut du lourd, du sûr, du solide, du stable, du libre: c'est-à-dire une distribution GNU/Linux ou BSD.

Pour les serveurs Web, j'utilise FreeBSD ou Ubuntu Server, selon mon humeur. Comme je le répète assez souvent il vaut mieux choisir un système d’exploitation que l’on maîtrise bien. En discutant avec des “experts”, vous aurez autant de sons de cloches que d’OS...

Dans la suite de ce billet, nous travaillerons sur la sécurisation d'un serveur sous Ubuntu Server 10.04 LTS, ces méthodes sont applicables facilement sur une Debian (et toute autre distribution Debian like).

Pense bête lors de l'installation

Lors de la configuration des partitions du disque dur de votre serveur, ne tombez pas dans la facilité en faisant une partition unique qui contiendra le système, les application et vos données sur un même volume logique.

Séparer intelligemment les répertoires de son système permet de cloisonner les données et simplifie la ré-installation d’un système. Au minimum, il est conseillé de séparer au moins les partitions suivantes:

  • / (~ 5 Go)
  • /boot (~ 100 Mo)
  • /var (~ 12 Go)
  • /home (Tout l'espace restant)
  • /var/tmp (Voir plus bas)
  • /tmp (Voir plus bas)

Dans notre cas, l’idée est de ne pas stocker nos sites sur /var/www mais sur /home, qui contient tout l’espace.

Le répertoire /var, dédié principalement aux logs, pourra alors se remplir sans impacter votre arborescence principale sur / ou vos comptes sur /home.

Surveiller l'espace utilisé sur vos partition est important, une partition pleine empêcherait vos logs de s'écrire ou vos sites de fonctionner correctement. Le programme logwatch (décrit plus bas) vous fournit un récapitulatif de l'espace disque utilisé, il est donc utile pour surveiller ce point.

Utilisation de tmpfs

Sous les systèmes GNU/Linux, on a deux dossiers temporaires: /tmp et /var/tmp. Passer ces dossiers “World Writable” (c’est à dire que n’importe quel utilisateur/processus de votre système peut écrire et lire dans ces répertoires) en tmpfs (disque RAM). Il faut que votre serveur dispose d'une quantité de mémoire RAM conséquente car une partie de celle-ci sera utilisée pour stocker les fichiers temporaires.

Pour mettre en place tmpfs sur un système de fichier (/tmp dans cet exemple), éditez le fichier /etc/fstab et ajouter la ligne suivante :

tmpfs        /tmp     tmpfs        defaults,user_xattr          0    0

Je vous conseil de mettre tmpfs en place pour les répertoires /tmp, /var/tmp et /dev/shm. La rêgle pour savoir síl faut le mettre en place est "sur tous les répertoires dont le données sont volatiles". Ainsi, /var/lock devrait en faire partie, sauf que certains programmes, mal codé, n'apprécient pas que ce dossier soit vidé.

L’idée derrière l’utilisation de la RAM est de rendre ces répertoire très rapides. Le stockage sur RAM limite aussi intrinsèquement leur taille, que le noyau gère automatiquement pour étendre ou diminuer la taille de ces partitions en fonction des besoins du système.

Mise à jour du système

C'est un des principe de base de la sécurité de votre système informatique (malheureusement aussi un des plus rébarbatif):

"Toujours avoir un système et des applications à jour."

Pour m'aider dans cette lourde tache, j'utilise l'application cron-apt qui permet de vérifier automatiquement si des mises à jours sont disponibles. Si c'est le cas, le logiciel peut envoyer un mail et optionnellement, mettre à jour le système pour vous.

Installation de cron-apt:

sudo aptitude install cron-apt

Il faut ensuite configurer votre adresse mail dans le fichier /etc/cron-apt/config. Par défaut cron-apt s’exécute automatiquement tout les matins à 4h00.

Voici un exemple de mail envoyé:
Pour les machines sous Fedora, il existe une fonction équivalente directement dans Yum (lire ce billet pour plus d'informations).

Tuning de la sécurité

Configurer les paramètres de sécurité réseau par défaut dans le fichier  /etc/sysctl.conf.

Vous pouvez vous inspirer des billets suivants pour effectuer cette configuration:

Protection contre les "forks bombs"

Une attaque par "forks bombs" est de type DOS (Deny Of Service) qui utilise la commande système fork. Pour se protéger de telle attaque et limiter leurs impacts sur le reste du système,  il faut éditer le fichier /etc/security/limits.conf et y ajouter les lignes suivantes (en adaptant "username" à vos besoins):

username soft nproc        300

username hard nproc        350

username soft nice         0

username hard nice         0

username soft priority     5

username hard priority     5

username -    maxlogins    10

Ces limitations empêchent un utilisateur de se logguer plus de 10 fois sur la machine (en SSH notamment), de lancer plus de 350 processus simultanément (empêche les forks-bombs) et met une priorité faible a ses tâches par défaut (haute priorité < 0, normal 0, basse priorité > 0).

Source: http://www.cyberciti.biz/tips/linux-limiting-user-process.html

Firewall

Ne laisser passer que les flux réseaux utiles à l'utilisation de votre serveur par les utilisateurs (HTTP / HTTPs) et l'administration (SSH).

Concernant le protocole SSH, on lit souvent qu’il faut changer le port d’écoute du daemon SSHd (par défaut TCP/22). Mise à part le bloquage de certains scripts automatique, je ne pense pas que cette sécurité soit suffisante. En effet, un simple scan de votre machine avec Nmap permettra de retrouver facilement le port d’écoute.

Une solution plus efficace pour protéger cette porte d’entrée sur le serveur est d’utiliser la technique du “portknockers”. Avant de s’ouvrir, on doit taper à la porte de notre serveur en  envoyant une séquence de requêtes vers des ports prédéfinis. Par exemple avant de ce connecter en SSH sur le port TCP/22, il faudra envoyer “taper à la porte” des ports 2222, 3333 et 4444.

Le programme knockd permet de configurer facilement un “portknockers” sur son serveur Linux: https://help.ubuntu.com/community/PortKnocking

Fail2Ban analyse les logs de votre système et bloque automatiquement les indésirables au niveau du firewall iptables, ce qui est très efficace. Vous pouvez aussi bloquer manuellement des plages d’IPs considérées comme “malfaisantes”, il m’est arrivé de bloquer un pays entier cas de nombreux tentatives de piratage provenaient de ce site, et qu’aucun visiteur en provenance de ce pays ne viennent sur mes sites (bon c’est vrai cela fait un peu censure :)).

A installer à partir des sources:

sudo aptitude install fail2ban

Le fichier de configuration par défaut est /etc/fail2ban/jail.conf. Vous pouvez notamment y configurer les adresses IP à ignorer (par exemple l'adresse IP publique ou le nom d'hôte de votre propre box):

ignoreip = 127.0.0.1 home.mondomaine.com

Et également ajouter ou modifier les prisons (jail) pour des services spécifiques. Par exemple pour le serveur pure-ftpd:

#

# FTP servers

#


[pure-ftpd]

enabled = true

port = ftp,ftp-data,ftps,ftps-data

filter = pure-ftpd

logpath = /var/log/messages

maxretry = 6

Pour aller plus loin dans la configuration de fail2bna, vous pouvez lire ce billet.

Autres idées en vrac

  • instaurer des quota disk stricts par utilisateur (quotatool) : très utile pour éviter de bloquer tous ses sites à cause d’un script mal codé.
  • empecher le reboot par syskey /etc/inittab : intéressant mais peu utile, une personne avec un accès physique à votre serveur peut de toute façon faire à peu prêt tout ce qu’elle veut.
  • utiliser rsyslog pour envoyer les logs sur un serveur distant, sans accès de modification/suppression de logs de préférence : permet d’analyser les actions d’un pirate après détection du piratage (un pirate ne peut pas effacer toutes les traces laissées par les tentatives de piratage infructueuses). Un peu cher à mettre en place pour un site perso.

Les commentaires sont ouverts pour nous faire partager votre expérience dans la sécurisation de vos sites Internet.

Sources ayant servies à la rédaction de ce billet:

  • Pingback: Tweets that mention Sur le blog: Sécuriser son blog WordPress #1 -- Topsy.com()

  • jahman

    Salut,

    J’ai pas tout lu mais cela semble intéressant. quelques idées en vrac d’ordre général et pas lier à wordpress.

    tant qu’à « tuner » les répertoires temporaires autant les rendre « noexec » (pas de permission d’execution). ca améliore la sécu « en profondeur » comme dise les pro 😉 une autre remarque, ne pas installer de compilateur sur un serveur de prod (mais la je chipote 🙂

    pour apache
    vérifier que l’utilisateur www-data (ou autre) n’a pas d’accès shell /bin/false dans le fichier /etc/passwd
    vérifier que la méthode TRACE et OPTIONS sont bien interdite pour tous les arborescences et avec/sans ssl.
    logguer si nécessaire les variables POST qui ne le sont pas par défaut.

    du côté de php
    désactivier les erreurs
    pas d’ouverture de fichiers distants
    pas d’accès en dehors de l’arbo du serveur (open_basedir)
    pas de fonctions non indispensables (system, exec, shell_exec…)

    sinon tu peux également voir du côté des capabalities sous linux

    vérifier avec un petit « netstat -ntlpu » les services en écoutes sur ton serveur

    my 2 cents

    • > tant qu’à “tuner” les répertoires temporaires autant
      > les rendre “noexec”

      C’est vrai, mais cela peut poser des problèmes a certains programme qui utilisant le /tmp pour exécuter des programmes dans celui-ci. À ne mettre en place que lorsque l’on test a fond son système et que l’on sait se qu’on fait !

      > ne pas installer de compilateur sur un serveur de
      > prod

      Tout a fait d’accord. Les compilateurs sont régulièrement utilisés par les pirates pour faire augmentations de privilèges (passer d’un utilisateur standard à « root »), via l’exploitation de failles dans le noyau. Les « exploits » étant le plus souvent écris en C, un compilateur aide à utiliser l’exploit !

      Un bon compromis à la désinstallation complète des compilateurs est d’interdire leur utilisation à tous, sauf à root.

      Pour gcc et g++, on ferait :
      # chmod go= `which gcc`
      # chmod go= `which g++`

  • Quelques notes/questions :
    Sous Ubuntu, le reboot par syskey n’est il pas plutôt à empêcher côté Upstart (/etc/init/control-alt-delete.conf) ?

    Est-tu sûr que le paquet fail2ban a un problème ? Sous quelle version d’Ubuntu ? Il a toujours bien marché pour moi.

    Quelques idées pour en faire plus :

    Pour SSH : ne pas permettre l’authentification par mot de passe, exiger des clés (ou les deux).

    Limiter les droits des fichiers : le groupe www-data n’a pas besoin de pouvoir lire /etc/passwd ! (si plusieurs sites sont hébergés sur la machine, les faire tourner sous des utilisateurs/groupes différents plutôt que tout en www-data. éviter aussi comme on le voit souvent de donner des droits d’écritures à www-data sur les fichiers qu’il possède s’il n’en a pas besoin). Bref, respecter la règle du moindre privilège.

    Vu qu’on est sous Ubuntu, on peut aussi faire un peu d’apparmor pour sandboxer ce qui est sensible.

    • 1/ Fail2Ban
      En effet, le paquet Fail2Ban marche tres bien sous Ubuntu, sous Debian aussi d’ailleurs.

      2/ SSH
      Se connecter par clé est aussi préférable à mon avis ! Surtout qu’on peut lister facilement les clés autorisées et donc savoir facilement si un utilisateur de plus se connecte.

      3/ Apache et www-data
      Ce sera évoqué dans un autre billet, et en effet, www-data ne doit pas exécuter de code 🙂

    • Exact pour fail2bna, je viens de corriger le billet !

  • Pingback: wp-popular.com » Blog Archive » Sécuriser son blog Wordpress #1()

  • Pingback: Installation et utilisation de LOIC sous GNU/Linux()

  • source spécialisé blog. Notre société est composé d’experts certifiés dans le developpement de modules sur le CMS wordpress, de chefs de projets experts wordpress. Nous réalisons des sites WordPress pour les professionnels: portail, site communautaire, institutionnel, e-commerce…

  • Pingback: Sécuriser son blog Wordpress #2()

  • Pingback: Geek De France.fr » [TUTO] Sécuriser simplement Webmin()

  • Hello,

    On peut également conseiller d’utiliser logcheck http://logcheck.org/ pour avoir des remontés sur les logs.

    et peut-être aussi de mettre des filtres (iptables) directement sur le serveur pour limité les scans par exemple.

  • Pingback: Un serveur Jabber en 5 minutes chronos sous Debian/Ubuntu()

  • Pingback: Sélection de liens Wordpress — Sylvain Deloux Freelance()

  • Pingback: [TUTO] Sécuriser simplement Webmin | Paradiziak()

  • Pingback: Sécuriser son blog WordPress #3()

  • Merci pour le cron-apt, je connaissais pas!

    Le lien vers l’article sur le port-knoking est super intéréssant également.

    Bonne continuation!

  • Ollivier

    Bonjour Nico,

    Merci et félicitations pour ces 4 volets sur la sécurité Apache/Wordpress, je ne regrette qu’une chose ne pas être tombé sur tes billets auparavant !!!

    Une question de newbie, sur un hébergement mutualisé comportant CPanel, par exemple, pas question d’installer les extensions de sécu Apache que tu évoques j’imagine ? 🙁

    • Je confirme… D’un autre coté si l’hébergeur fait bien son boulot il a du les installer pour toi !

  • Pingback: Piratage en hausse, les hackers sortent de l'ombre()

  • Pingback: De retour en ligne après piratage – iToubib()

  • Pingback: Sécuriser son blog Wordpress #1 - Le blo...()

  • Pingback: SynerGeek.fr | Piratage en hausse, les hackers sortent de l'ombre()