VOTRE ESPACE

  Identifiant
 
  Mot de passe
   
Inscription gratuite

Présentation

  L'agent Snyke

Thèmes
d'utilisation

  Particuliers
  Webmasters
  Entreprises

  Forums

  Liste des forums
  Support

News

12/10: A la découverte des blogs avec le Kaléibloscope
02/09: PHONIT disponible en version béta: les blogs par téléphone.
26/07: Snyke héberge des blogs.
15/05: Pretty-RSS, intègre un annuaire RSS interactif.
15/02: Nouveau service: Pretty-RSS, des fils d'actualité dynamiques pour votre site
15/10:
les 1er inscrits utilisent le service gratuit Snyke ...
01/10: Snyke ouvre son service en ligne ....

15/09: SnyKe lance sa nouvelle interface utilisateur ...
11/09: Première version de l'agent SnyKe ...

Informations

  Notre Robot
  Pretty-RSS
  Phonit

  Fils Infos
  Forum RSS
  Le BLOG RSS

  Annuaire RSS
  Lecteur RSS
  Lecteur RSS en ligne
   Liste de flux RSS :
a- b- c- d- e- f- g- h- i- j- k- l- m- n- o- p- q- r- s- t- u- v- w- x- y- z
  World weather maps
  L'encyclopedie
   English
   German
   Spanish
   Italien
   Portuguais
   Japonais
  ODP-Mirror
  Dmoz-Tags
  RFC-Zone
  Finances


  Liens

 

Click to

changes
in this page


Sécurisation phpBB
précautions à prendre lors de l'installation de phpbb
(en complément des infos disponibles sur les forums phpBB-fr.com et phpBB.biz)

Protection des fichiers : chmod 644 est souvent TRES insuffisant

Sommaire:

Préambule:

Cette page existe suite à un incident (compromission du password de la base en particulier) constaté sur la configuration d'un gros forum français utilisant le logiciel phpBB. La faille ne provient pas du logiciel lui même mais d'une erreur dans son installation. La documentation officielle phpBB est exacte mais n'insiste peut-être pas assez sur certains points détaillés plus loin.

Ceci pour dire que nul n'est à l'abri d'une erreur et qu'il convient de faire attention lorsque l'on installe un logiciel sur une machine connectée à internet. Cette page destinée à un public large et aborde des points qui pourront sembler évidents pour certains, mais ce sont toujours ces points que l'on oublie et qui provoquent des failles et éventuellement des désastres !!!

Ceci est particulièrement vrai en hébergement mutualisé où une vulnérabilité chez un hébergé peut se propager chez les autres s'ils ne se protégent pas (ou mal). "L'hébergeur ferme la porte de l'immeuble mais si vous laissez votre clé sur le palier et que votre voisin a de mauvaises fréquentations ..." (C'est parfois de cette façon que des dizaines de sites se font "défigurer" en quelques secondes).

Cette page est particulièrement orientée Unix et hébergement mutualisé.

Le point sensible:

Il est primordial que le fichier qui contient les données d'accès à la base de données soit protégé de facon adéquate. Dans sa version standard ce fichier se nomme : config.php

Protection adéquate = seul l'utilisateur du fichier doit avoir le droit d'accès.
Utilisateur = le nom de l'utilisateur sous lequel votre serveur va traiter le fichier php.

Comment ca marche ?

Rappel sur la notion de "user/group/others":

Sous unix chaque fichier appartient à un "user" qui lui-même appartient à un "group". Tous les autres "users" qui n'appartiennent pas au "group" du "user" font partie des "others". Le propriétaire ("user") peut fixer les droits de "lecture, ecriture, execution" (Read, Write, eXec) de ses fichiers pour chacune des entités "user", "group", "others". Donc un fichier a en particulier les propriétés suivantes:

fileName, user, userGroup, userRights, groupRights, othersRights

De même que pour les fichiers, les process qui s'exécutent sur la machine, s'exécutent avec des droits particuliers d'un "user" et donc d'un groupe (important pour la suite), et si le process doit accéder à un fichier, le système vérifie que ce "user" a bien les droits sur le fichier en question.

Application à un serveur Web:

Un server Web est un process (pour simplifier !) qui tourne sous le nom d'un user. Généralement un "user" spécifique est créé par exemple : "user" apache_user du "group" apache_group. Pour que le serveur puisse avoir le droit de lire et de servir ou éxecuter les fichiers que vous "user" avez créés sous votre nom, il convient de lui donner les bons droits.

Un server web a besoin de plusieurs type de droits:

Pour les fichiers statiques (html, ..) :
Pour les répertoires
:
Pour les programmes (php, cgi, ...) :

lecture
lecture, execution
lecture, execution

Comment donner les bons droits dans ce cas sachant que le serveur ne tourne pas sous votre nom de user et qu'il ne fait pas partie de votre groupe ? Deux solutions (entre autres):

  • Changer le propriétaire des fichiers et rendre le server propriétaire. Dans ce cas les droits sont à donner uniquement au propriétaire : Bonne solution.
  • Donner les droits à la catégorie "group" et "others" : C'est moins bien mais si vous êtes seul sur cette machine ou que vous faites "confiance" aux autres, pourquoi pas. A éviter impérativement dans les cas décrits ci-dessous. (le fameux "chmod 644")

Erreurs à éviter:

En hébergement mutualisé (les hébergements économiques où vous partager les machines et bande passante avec d'autres sites) il convient d'être très très prudents surtout si les scripts sont acceptés. Donner des droits élargis en lecture à des fichiers statiques (html, ...) ne semble pas sensible (ils sont destinés à être diffusés tel quel sur le web!), par contre les fichiers dynamiques (php, cgi, ...) sont destinés à être exécutés et non lus directement. La divulgation de leurs contenus peut révéler des données sensibles comme des données de connexion à des bases de données (par exemple le fichier config.php).

En hébergement mutualisé (la plupart des petits sites), une configuration courante est de placer tous les utilisateurs dans le même groupe. Il faut donc considérer que votre voisin (un site hébergé comme vous) peut obtenir une visibilité dès que vous donnez les droits au "group" (et encore plus si vous donnez les droits à "others"). "Généralement" vos voisins ne seront pas agressifs vis à vis de votre site, mais si un intrus prend le controle de leur site, il aura la même visibilité que votre voisin sur vos données. Vous êtes donc vulnérable de manière indirecte.

La solution retenue par certains hébergeurs est de faire tourner les process (ou sous process) des serveurs qui servent du contenu actif sous le nom des utilisateurs. Dans ce cas les droits utilisateur suffisent et il faut supprimer tout autre droit. (Les fichiers statiques peuvent continuer à être servis par un process générique et il faut dans ce cas laisser les droits en lecture à l'entité group et others)

Il donc faux d'affirmer qu'un chmod 644 est suffisant pour protéger un forum phpBB. Tout dépend de l'environement dans lequel est hébergé le site et c'est aussi quelquechose qu'il convient de vérifier. Avant tout il faut conseiller une protection en 400, 600 ou 700 par ordre de préférence.

Conclusions/Conseils:

  • Les droits sur le fichier config.php en particulier doivent être limités au user (chmod 600).C'est lui qui contient les données de connexion à la base.
  • Si ces droits ne sont pas suffisants chez votre hébergeur, cherchez à savoir et à comprendre pourquoi pour analyser l'impact. Préférer la fuite et changez d'hébergeur si les réponses vous semblent hasardeuses !
  • Supprimez tous les droits en écriture pour "group" et "others" de vos répertoires web.

Dans tous les cas vérifiez et revérifiez toujours les droits que vous donnez à vos fichiers. Une erreur d'inattention est vite arrivée et là ....

Voir aussi : Discussion sur le sujet (forum)

PS : Restez humbles ! La protection absolue n'existe pas.

Autre pages sur sécurisation phpBB:

to the top

 



Snyke Home | Données personnelles | Contactez-nous | Supportez Snyke

© SnyKe 2003 - Tous droits réservés
Synke™ est une marque déposée. Reproduction et diffusion strictement interdite - Droits d'usage strictement personnel
Tout utilisateur du site accepte de se conformer aux conditions d'utilisation