This is a user-submitted French translation of my "777: The number of the beast" blog post. Please do not post questions in the comments in French. My French is very rusty :)

Je vous promets, cet article n'a rien à voir avec la religion, il traite de la sécurité des sites web. Le démon que je mentionne se refaire au fait d'ouvrir une éventuelle porte pour permettre aux pirates de compromettre votre site. Cet article est long mais je vous promets que vous allez apprendre des choses que vous n'avez jamais imaginées. Faisons la lumière sur le mystère du numéro 777 et tuons le démon !

Il était une fois dans l'univers Unix

La plupart des sites sont hébergés dans des serveurs Unix ou une de ses différentes variantes (Solaris, FreeBSD....etc.). Ce qu'il y a en commun entre ces systèmes, est le modèle de sécurité du système des fichiers qui est basé sur les notions (utilisateur, groupe, propriétaire et permissions). En voici un résumé de ce modèle :

Les variantes du système Unix ont des utilisateurs, chacun appartient à un ou plusieurs groupes. Chaque fichier possède un et un seul propriétaire. L'utilisateur propriétaire du fichier peut ne pas appartenir au groupe propriétaire du fichier, ce qui permet une énorme flexibilité. Le système sait qui est autorisé à faire quoi sur n'importe quel fichier et répertoire en utilisant les permissions.

Les permissions sont exprimées sous forme de trois chiffres écrits en utilisant le système octal. Le premier chiffre informe le système des autorisations accordées au propriétaire du fichier. Le second chiffre l'informe des autorisations accordées au groupe propriétaire. Quant au dernier chiffre, il informe le système des autorisations accordées au reste du monde. Les chiffres communément utilisés sont : 4(lecture seule), 5(lecture et exécution), 6 (lecture et écriture) et 7(lecture, écriture et exécution). Pour les répertoires, l'exécution signifie la possibilité de lister leurs contenus.

Mais, comment est-ce que le système est dans la possibilité de lire ces permissions ? Juste comme les fichiers et les répertoires, chaque programme qui s'exécute dans le système possède également un utilisateur et un groupe. Apache, le serveur web communément utilisé est aussi un programme qui s'exécute avec les droits d'un utilisateur et d'un groupe. Même chose pour le serveur FTP qui s'exécute sous l'utilisateur avec lequel vous vous êtes connectés.

Maintenant, vous sentez le problème. Le système d'exploitation sait qui demande un droit selon l'utilisateur et le groupe du programme qui en fait la demande. Le système sait également de quel droit d'accès il s'agit (lecture, écriture, exécution). Quand le système trouve le fichier ou le répertoire demandé, Il vérifie l'utilisateur et le groupe propriétaire ainsi que les différents droits d'accès. Le système vérifie d'abord si le programme appelant s'exécute sous l'utilisateur propriétaire du fichier auquel cas le premier chiffre est utilisé pour déterminer les droits. Si ce n'est pas le cas, Le système vérifie si le programme s'exécute sous le groupe du fichier ou répertoire et utilise le second chiffre. Au cas où ses deux tests échouent, le système utilise le dernier chiffre pour décider des droits d'accès attribués. Ce système est à la fois élégant et effectif jusqu'à ce que quelqu'un décide de l'utiliser maladroitement.

Un peu comme l'histoire de la pomme d'Adam !

La plupart des hébergeurs mutualisés sont configurés pour exécuter PHP comme étant un module Apache. Cela veut dire que vos fichiers PHP s'exécutent sous le même utilisateur que celui de votre serveur web. Mais lorsque vous transférez vos fichiers en utilisant FTP et étant donné que le serveur FTP s'exécute sous l'utilisateur avec lequel vous vous êtes connectés ; alors tous les fichiers et les répertoires transférés se verront attribués l'utilisateur FTP comme propriétaire et son groupe comme groupe propriétaire.

S'agissant des fichiers PHP, vous allez vous retrouver dans le cas de figure suivant :

Vos fichiers sont possédés par un utilisateur « user »  et un groupe « users » différents de ceux sous lesquels le module PHP s'exécute. Comme conséquence, Vos scripts PHP ne pourront plus écrire ou modifier des fichiers si vous utilisez les paramètres de permissions par défaut (644). Pire encore, vos scripts PHP ne pourront même pas lister le contenu des répertoires de votre propre site web!

Pourquoi est-ce un problème? Bon, les applications Web modernes, comme Joomla !, Wordpress et Drupal ont besoin du droit d'écriture pour maintes raisons : cache, installation de composants, les fichiers de log, transfert de fichiers avec interface Web, Sauvegardes,...etc.). Comme l'utilisateur et le groupe du programme s'exécutant (ici Apache) sont différents de l'utilisateur et du groupe propriétaires des fichiers et répertoires, l'unique façon d'attribuer les droits de lecture, d'écriture et d'exécution au module PHP et d'appliquer les permissions 777 sur chaque répertoire et fichier de votre site web.

Cela fonctionne bien, bon, plutôt un peu plus que bien pour nuire au bien être de votre site web. Appliquer les permissions 777 revient à souhaiter la bienvenue aux pirates du monde entier, Comment?

Dans un serveur mutualisé, vous n'êtes pas l'unique utilisateur. D'autres sites ont également des utilisateurs dans le système. Pour rendre les choses pires encore, les chemins d'accès aux différents sites sont faciles à deviner ; généralement sous le format (/home/username/public_html. Si quelqu'un veut pirater votre site, Tout ce qu'il aura à faire est de créer un compte dans le système et d'éditer un de vos fichiers pour y insérer un code malicieux. Avec les permissions 0777, il pourra accomplir cette tâche sans pour autant posséder votre identité (nom d'utilisateur et mot de passe) Le dernier chiffre indique les droits d'accès applicables pour le reste du monde, souvenez-vous. Et il se trouve que la personne qui veut hacker votre site y appartient !

Un pirate intelligent n'a même pas besoin de créer un utilisateur dans le système. Le serveur exécute plusieurs programmes (serveur web, serveur FTP, serveur DNS, serveur SSH, serveur Mail,...etc.). Si un des serveurs est vulnérable, le hacker peut l'exploiter pour écrire dans les fichiers de votre site !

De plus, si un des sites hébergés dans le même serveur que le votre a été compromis, il y a de forte chance que le votre y sera également car les permissions 0777 le permettent.

En d'autre termes, l'attribution des permissions 777 crée un énorme problème de sécurité et vous expose aux hackers même les plus novices, Vous me croyez maintenant lorsque je vous dis que 777 et le numéro du démon ?

Temps d'appeler un exorciste !

Il y a différentes façons d'éradiquer les permissions 777 de votre serveur. Cela dépend de sa configuration. Accrochez vos ceintures, on est entrain de franchir la zone « fais-le-toi-même). Un conseil, n'essayez jamais d'appliquer des changements directs sur votre site live. Faites une sauvegarde, Téléchargez-la en local et copiez-la dans trois supports différents.

Cas où le serveur mutualisé utilise suPHP pour exécuter PHP

C'est le cas idéal. suPHP est une solution intelligente au problème des permissions. Au lieu d'exécuter PHP sous l'utilisateur et le groupe propriétaires du serveur Web, suPHP l'exécute sous l'utilisateur et le groupe propriétaires du fichier PHP en question. Cela signifie que seul le premier nombre des permissions est important, alors que le second et le dernier peuvent être mis à 4(lecture seule) ou 5(lecture et exploration des fichiers) pour les répertoires. N'utilisez pas 0 car vous allez tout simplement interdire l'accès au contenu non-PHP (images, JavaScripts et CSS). Dans ce cas donc, les meilleures permissions sont : 0644 pour les fichiers et 0755 pour les répertoires.

Si vous êtes incertain, il y a une façon très simple pour découvrir si votre hébergeur utilise suPHP. Identifiez-vous dans le backend de votre site Joomla ! Dans outils systèmes, cliquez sur Info système. Si le paramètre serveur web interface PHP affiche CGI ou FastCGI, alors, il y a de fortes chances que votre hébergeur utilise suPHP. Posez-lui la question tout simplement.

Cas du simple serveur mutualisé

Il y a des serveurs mutualisés qui n'utilisent pas suPHP. Ce sont généralement ceux qui mettent de 2000 à 3000 sites sur la même machine. En effet, suPHP utilise trop de ressources et les propriétaires de tels serveurs préfèrent ne pas l'utiliser pour qu'ils puissent mettre un plus grand nombre de sites sans entraîner le serveur au chaos. Même dans ce cas, vous pouvez protéger votre site.

La méthode (fausse) généralement utilisée, consiste à mettre tous vos fichiers sous l'utilisateur et le groupe du serveur Web. La façon très simple qui vous permet de faire ça est de faire une sauvegarde avec  Akeeba Backup, de supprimer tous les fichiers et répertoires du site web et ensuite de restaurer le tout en utilisant Kickstart. Tous vos fichiers seront possédés par l'utilisateur sous lequel le serveur web s'exécute et peuvent donc utiliser les permissions 0644 pour les fichiers et 0755 pour les répertoires. Pourquoi cette méthode est fausse ? Ben, si un autre site hébergé sur la même machine que le votre est compromis, alors, le pirate pourra écrire dans vos fichiers étant donné que l'utilisateur propriétaire est le même sur les deux sites (l'utilisateur sous lequel le serveur web s'exécute). Félicitations, votre site vient d'être piraté.

La bonne méthode est un peu longue. Tous vos fichiers doivent être possédés par votre compte (çàd : utiliser FTP pour les transférer vers le serveur), excepté ceux pour lesquels vous voulez que le serveur web (donc Joomla !) ait le droit d'écriture. Puisqu'on parle Joomla ! ici, Il faut faire ce qui suit :

  • Supprimer les répertoires cache, tmp et logs de la racine du site.
  • Installer Joomla! eXtplorer ou NinjaXplorer . Ces gestionnaires de fichiers s'exécutent sous Joomla et utilisent donc le même utilisateur et le même groupe que votre serveur Web.
  • Créer les répertoires cache, tmp et logs en utilisant un des deux gestionnaires de fichiers précédemment cités.
  • Attribuer temporairement les permissions 777 aux répertoires cache, tmp et logs.
  • Utiliser votre client FTP pour créer des fichiers .htaccess dans lesquels vous allez écrire les directives
  • order deny, allow
  • deny from all
  • Mettre le fichier .htaccess dans les trois répertoires (cache, tmp et logs)
  • Attribuer aux fichiers .httaccess les permissions 0644 toujours en utilisant le client FTP (ex : FileZilla)
  • Revenez au gestionnaire de fichiers de Joomla (eXtplorer ou NinjaXplorer) et attribuer les permissions 0700 aux répertoires cache, tmp et logs. (NB, Vous serez peu être dans l'obligation d'attribuer les permissions 0744 pour le répertoire cache et d y supprimer le fichier .htaccess afin de permettre à quelques plugins Joomla de fonctionner. Si vous voulez mon conseil, juste désinstaller les plugins en question).
  • Dans la configuration générale de Joomla, Activer la couche FTP, ne sauvegardez pas votre mot de passe.

Pour résumer, nous nous sommes assuré que les répertoires « cache, tmp et logs » sont possédés par l'utilisateur sous lequel le serveur web s'exécute. Ainsi PHP (Joomla donc) possède la permission d'écriture sur ces trois répertoires. Nous avons ensuite utilisé les fichiers .htaccess pour interdire l'accès à ces répertoires depuis le web. Puisque les fichiers .htaccess sont transférés par le client FTP, ils ne peuvent être réécrits. Même si un pirate essaye d'exploiter le site en créant des fichiers dans l'un de ces répertoires, il ne pourra pas les exécuter et son attaque va échouer. En utilisant Joomla, vous êtes amenés à écrire sur d'autres répertoires (principalement durant l'installation de nouveaux composants). C'est pour ça que nous avons activé la couche FTP, et puisque nous n'avons pas sauvegardé le mot de passe, il n'est écris sur aucun fichier de notre site et Joomla nous le demandera à chaque fois.

Mission accomplie avec beaucoup de préjudice !

Cas du serveur dédié

C'est ma partie favorite. Puisque votre serveur est dédié, ceci implique qu'il y aura uniquement un seul site qui y sera hébergé. Cependant vous voulez exploiter chaque cycle CPU à bonne escient. Du coût, vous n'allez pas utiliser suPHP. Ceci est tellement bien jusqu'à ce que vous décidiez d'installer ISPConfig, Plesk, cPanel ou tout autre gestionnaire dans votre serveur. Pourquoi ? Parce qu'au moment d'installer un de ces gestionnaires, votre cerveau s'arrête de fonctionner et vous commencez à accepter les paramètres par défaut. Tous les gestionnaires de serveurs présupposent que vous voulez configurer votre serveur en mode mutualisé et configure Apache pour utiliser un utilisateur différent de celui qui possède l'un et l'unique site web (le votre)! Comme résultat, et comme vous ne pouvez pas utiliser la couche FTP pour des problèmes de performances, vous commencez à attribuer les permissions 777.

Agh ! Vous laissez le démon vous posséder. Pourquoi vous faites ça, mais pourquoi ? La solution est si simple ! Peu importe le gestionnaire de serveurs que vous utilisez, vous êtes l'administrateur du système. Vous pouvez toujours éditer la configuration d'Apache et l'instruire à s'exécuter sous l'utilisateur propriétaire (vous). A partir de ce point, vous pouvez juste utiliser les permissions 0700 pour les répertoires et 0600 pour les fichiers et le tour est joué !

En résumé

Nous sommes des humains, et les humains sont sujets aux erreurs même dans le domaine de la sécurité. Etre expert ne permet pas d'éliminer les erreurs complètement. Au moment d'écrire cet article, je me suis douté de mes propres pratiques, vous savez ? J'ai fait des conneries sur quelques sites et j'ai appliqué la meilleure configuration sur d'autres. C'est impossible d'être parfait mais c'est utile d'écrire ces bonnes pratiques. Vous pouvez utiliser cet article comme référence la prochaine fois que vous aurez à configurer un des sites de vos clients ou même le votre.

Rappelez-vous que la sécurité est comme une contraception, c'est optionnel, mais uniquement lorsque vous vous en foutez des conséquences. Dans le web, c'est encore plus grave ; le pirate ne viendra pas demander votre permission pour compromettre votre site ! Et à la fin de la journée, vous vous rendrez compte que c'est entièrement votre faute.

Soyez bien, soyez en sécurité et ne laissez aucun logiciel décider à votre place que les permissions 777 sont tout sauf un démon.

No comments