Laisser un commentaire

Les CHMOD pour l'hébergement internet

Les CHMOD, ça parait simple et complexe à la fois. D’ailleurs, la plupart du temps, les développeurs s’en préoccupent peu, ou pas du tout. Pourtant, une mauvaise configuration peut faire survenir des bugs dans de nombreuses applications. Plus grave, cette mauvaise configuration ne garantie pas une sécurité optimale et peut faciliter le hack de votre site et l’intrusion dans vos serveurs. Faisons donc un petit tour des bonnes pratiques.

Petit rappel sur les chmod

Révisons rapidement les chmod pour bien commencer, on a trois types de permissions, lesquelles peuvent être notées de manières symboliques par x (execute), w (write) ou r (read), ou de manière octale, respectivement 1, 2 et 4. Ces droits sont applicables aux fichiers comme aux répertoires :

De plus, il faut savoir que ces droits s’appliquent à trois types d’utilisateurs :

Voici un petit tableau récapitulatif :

Droits Chiffre Calcul
0 0 + 0 + 0
r– 4 4 + 0 + 0
-w- 2 0 + 2 + 0
–x 1 0 + 0 + 1
rw- 6 4 + 2 + 0
-wx 3 0 + 2 + 1
r-x 5 4 + 0 + 1
rwx 7 4 + 2 + 1

Les bons réglages pour l’hébergement

On doit maintenant se poser la question des chmod à attribuer à nos fichiers pour être dans des conditions de sécurité acceptables. Le mieux, c’est de tout mettre à 777

Le chmod 777 de commitstrip

Vous l’aurez donc compris, le conseil du chmod 777, c’était une boutade.

Par défaut, les répertoires sont en général à 755 – ce qui autorise tout pour le propriétaire du fichier (premier chiffre), donne le droit à la lecture et à l’exécution (listage dans le cas des répertoires) pour les autres (4+1 pour le groupe [second chiffre] et les autres [troisième chiffre]) – et les fichiers à 644 – autorise la lecture et l’écriture pour le propriétaire (4+2) et la lecture uniquement pour les autres.

Le white listing

La meilleur politique consiste, comme toujours en sécurité informatique, à ne rien autoriser mis à part ce qui est nécessaire. Vous pouvez donc limiter les autorisations à 555 (lecture et listage) pour les répertoires n’ayant pas de contenu ayant vocation à changer. Typiquement un répertoire contenant des images ou des fichiers HTML et/ou PHP. En ce qui concerne les fichiers, 444 (lecture seule) suffira pour leur majorité, tels que les images, les fichiers HTML, CSS, JavaScript, PHP…

Moteur PHP

Au cas où vous vous posiez la question : non, les fichiers PHP n’ont pas besoin d’être exécutable. C’est en effet le moteur PHP qui lit leur contenu et les exécute, mais ils ne sont pas eux-même des exécutables (la plupart du temps).

Vous modifierez au cas par cas les droits des fichiers et des répertoires s’ils ont besoin de droits supplémentaires. Par exemple dans le cas d’un exécutable, il faudra au moins lui donner le droit d’exécution en plus de celui de lecture, donc 555 (ou 550 celon l’utilisateur qui lance l’exécutable).

De même, en ce qui concerne les fichiers de logs, n’oubliez pas de leur accorder le droit en écriture, sans quoi il ne loggeront pas grand chose… Concernant les répertoires, il faudra donner le droit d’écriture au propriétaire si le répertoire reçoit des uploads ou si PHP créé de nouveaux fichiers à l’intérieur par exemple, donc droits à 755.

Propriétaire, groupe et autres…

On parle depuis tout à l’heure de permissions accordées à trois niveaux d’utilisateurs. Cela implique, vous l’avez compris, qu’il est d’une part important de bien configurer les droits, mais d’autre part, qu’il faut aussi veiller à ne pas mettre n’importe quel utilisateur en tant que propriétaire !

En effet, la plupart du temps, le propriétaire a 7 (tous les droits), donc si votre propriétaire est le serveur, Apache par exemple (en général c’est l’utilisateur www-data sur les Debian et dérivés), il pourra facilement modifier vos fichiers et cela facilitera grandement le travail d’un attaquant ayant trouvé une faille sur votre serveur.

Plusieurs politiques peuvent donc être mises en place. La plupart du temps, le propriétaire des répertoires et fichiers est un utilisateur distinct des processus Apache (ou autre serveur) et appartenant aussi à un autre groupe (www-data est aussi le groupe correspondant au processus Apache). Par exemple l’utilisateur Linux sous lequel est loggué le développeur.

On peut déclarer root comme propriétaire, seul root aura donc les droits de propriétaire (root a de toute façon déjà tous les droits sur l’ensemble des répertoires du serveur). Il faudra alors être root pour faire ce que les autres et/ou le groupe n’ont pas le droit de faire.

On peut aussi n’accorder que des droits succins au propriétaire – les mêmes que ceux des “autres” – dans ce cas, il faudra passer en root pour éditer, supprimer etc, le fichier/répertoire.

J’ai parlé ici des utilisateurs, mais la même logique s’applique bien entendu aux groupes, bien qu’ils ne soient souvent pas pris en compte dans l’hébergement, ne laissez pas à un groupe (www-data au hasard) la possibilité de faire n’importe quoi !

Pour toutes les commandes relatives à l’administration des droits, des utilisateurs et des groupes, je vous recommande mon article sur l’administration des systèmes Linux.

J’espère que ce petit article aura su vous éclairer sur la gestion des droits pour votre hébergement ! N’hésitez pas à me signaler toute erreur ou omission.

Commentaires

Rejoignez la discussion !

Vous pouvez utiliser Markdown pour les liens [ancre de lien](url), la mise en *italique* et en **gras**. Enfin pour le code, vous pouvez utiliser la syntaxe `inline` et la syntaxe bloc

```
ceci est un bloc
de code
```