Gestion de Contenu, de Communauté et de groupes de travail collaboratif - Open Source, français, sécurisé, stable et performant

  • MODULES

    Pour étendre les nombreuses fonctionnalités disponibles de base - modules.npds.org est à votre disposition.

    Des modules complémentaires, une communauté de développeurs active, des forums pour vos questions ... NPDS  est aussi une plateforme de développement !
  • STYLES

    Vous cherchez des thèmes graphiques pour votre portail ou votre communauté : styles.npds.org est à votre disposition.

    Des thèmes du plus simple au plus sophistiqué. Des thèmes facilement modifiables et toujours en Open-Source - Laissez simplement parler votre imagination !
  • BIBLES

    La documentation indispensable pour personnaliser et exploiter toute la puissante de NPDS  est à votre disposition sur bible.npds.org.

    Vous pouvez participer à l'effort de documentation - rien de plus simple : contactez un membre de la Team de développement et nous vous ouvrirons un compte sur le Wiki !
Devenir membre    |    Identifiant : Mot de Passe : -
Au delà de la gestion de contenu 'classique', NPDS met en oeuvre un ensemble de fonctions spécifiquement dédiées à la gestion de Communauté et de groupes de travail collaboratif.
Il s'agit d'un Content & Community Management System (CCMS) robuste, sécurisé, complet, performant et parlant vraiment français.

Gérez votre Communauté d'utilisateurs, vos groupes de travail collaboratif, publiez, gérez et organisez votre contenu grâce aux puissants outils disponibles de base.
  • Multi langues (Français, Anglais, Allemand, Espagnol, Chinois)
  • Respect des standards : UTF8, XHTML, CSS, ...
  • Système de blocs avancés
  • Installation et administration complète et centralisée
  • Editeur HTML intégré
  • Gestionnaire de fichier en ligne
  • Gestion des groupes de membres
  • Ecriture collaborative de documents (PAD)
  • Forums évolués
  • Mini-sites (pour les membres et les groupes de travail)
  • Chat temp réel
  • Système de News et de rubriques complet (édition, révision, publication)
  • ...
Gratuit et libre (Open-Source), développé en PHP, NPDS est personnalisable grâce à de nombreux thèmes et modules et ne requiert que quelques compétences de base.
NPDS Workplace - groupe de travail collaboratif
 NPDS WorkSpace - tous l'univers du travail collaboratif.
Modéré par : developpeur jpb Jireck 
Index du Forum » » Sécurité » » Revoir le tutorial 2 pour les chmods  
2 pages [ 1 | 2 ]
AuteurRevoir le tutorial 2 pour les chmods
Anonyme
19765  

Anonyme
  Posté : 11-05-2006 06:50

Dans le tuto 2 "transfert d'un site local vers un serveur" on indique en étape 4 les chmod des fichiers à respecter. Il me semble que les chmods indiqués ne sont pas assez stricts en terme de sécurité. Par exemple un chmod 777 sur tous les répertoires et sous-répertoires, un chmod 766 sur pas mal de fichiers (l'administrateur pourrait chnager le chmod juste avant de faire une modif et ne pas permettre l'écriture entre temps), etc...
Des chmods plus stricts ne pourraient-ils pas être une barrière supplémentaire pour les hackers et autres rigolos nuisibles ?

  Citation   
Anonyme
19765  

Anonyme
  Posté : 11-05-2006 06:55

Pourquoi le chmod 744 sur tous les fichiers PHP, et pas 544 ?

  Citation   
GiamDoc
7063       
 

GiamDoc
  Posté : 11-05-2006 10:41

ouai et d'ailleurs pourquoi chmod et pas bonjour, et au revoir

  Profil  E-mail  www  Citation   
jpb
2015       
 

jpb
  Posté : 11-05-2006 12:05

Oui Giam c'est plus à la Ch'mode bonjour et au revoir...

  Profil  www  Citation   
Anonyme
19765  

Anonyme
  Posté : 11-05-2006 14:23

Bonjour l'humour !! si c'est tout ce que vous avez à dire c'est pas la peine, j'ai plus l'age de recevoir des leçons de politesse dont tout le monde se fout dans un forum soi disant technique;
Au revoir cette fois ci

  Citation   
nadir
202     

nadir
  Posté : 11-05-2006 14:48

Et la tendresse bordel ?
Je propose un post pour tous ceux qui ne se foutent pas de la politesse (dont la notion reste toute relative).

  Profil  www  Citation   
developpeur
24560       
 

developpeur
  Posté : 11-05-2006 16:13

notre anonyme sais au moins à quoi servent vraiment les chmod et surtout comment marche 99,99% des serveurs webs ?

  Profil  E-mail  www  Citation   
patdef
373      
 

patdef
  Posté : 11-05-2006 16:40

Bonjour...

Cela dit, je reste aussi persuadé qu'il y a des erreurs dans le tutorial.
Par exemple, rendre executable un fichier php sur un serveur, je vois pas trop l'intérêt, même si l'on est propriétaire du fichier...

A moins que quelqu'un m'explique mon erreur. Merci d'avance pour vos explications.

Au revoir...

  Profil  Citation   
Anonyme
19765  

Anonyme
  Posté : 11-05-2006 17:36

notre anonyme sais au moins à quoi servent vraiment les chmod et surtout comment marche 99,99% des serveurs webs ?
__________________________________________________________________________
Je n'ai pas cette prétention, mais vu votre réaction je suppose que ma remarque devait être idiote ?

  Citation   
Anonyme
19765  

Anonyme
  Posté : 11-05-2006 18:16

Bonjour...

Cela dit, je reste aussi persuadé qu'il y a des erreurs dans le tutorial.
Par exemple, rendre executable un fichier php sur un serveur, je vois pas trop l'intérêt, même si l'on est propriétaire du fichier...

A moins que quelqu'un m'explique mon erreur. Merci d'avance pour vos explications.

Au revoir...
____________________________________________________________________________
Bonjour,

Bon ça me rassure de voir que je suis pas tout seul à délirer. Je pensais que la protection des fichiers par Unix pouvait interdire à une personne non autorisée de venir les modifier ou supprimer sur un serveur. Mais je dois certainement me tromper vu la réaction qu'a provoquée mon message, bien impoli, il est vrai.

Au revoir

  Citation   
patdef
373      
 

patdef
  Posté : 11-05-2006 19:46

Allez, il n'est pas si impolit que ça ton message. Enfin, moi, il ne me gène pas particulièrement.
La, je n'ai pas le temps de t'expliquer mais si ça t'intéresse, dis le et je te consacrerai un peu de temps.

  Profil  Citation   
Anonyme
19765  

Anonyme
  Posté : 12-05-2006 07:08

Allez, il n'est pas si impolit que ça ton message. Enfin, moi, il ne me gène pas particulièrement.
La, je n'ai pas le temps de t'expliquer mais si ça t'intéresse, dis le et je te consacrerai un peu de temps.
----------------------------------------------------------------------------
Bonjour,

Merci de ton message. Oui je suis vivement interessé, et comme moi certainement beaucoup d'utilisateurs NPDS non spécialistes systèmes et réseaux, par une explication claire à ce sujet.

Merci d'avance pour le temps que tu pourras y consacrer.

  Citation   
patdef
373      
 

patdef
  Posté : 12-05-2006 09:40

Bon, je vais essayer de répondre à tes questions dans le désordre ; attention cependant, je n'ai pas la prétention d'être un expert, et je vais certainement ommettre quelques points, voire dire quelques bétises... (merci de me corriger dans ce cas)

Tout d'abord, une présentation rapide des propriétés des fichiers sous Unix/Linux pour ceux qui ne sont pas au courant (pardon pour les autres)

1) les droits sur un fichier unix sont : lecture, écriture, execution.
2) les droits possible sur un répertoire unix sont : lecture, écriture, traversé
3) ces droits sont affecté à trois catégories d'utilisateurs :
le propriétaire, les membres du groupes, les autres

Remarques :
Un fichier texte peut-etre exécutable. Cela veut dire qu'il existe un interpréteur pour ce fichier. Un peu comme un fichier bat sous ms-dos ou windows. Sauf qu'ici, ce n'est pas l'extension du fichier qui dit si le fichier doit être exécuter par le shell, mais bien sa propriété.

Un répertoire n'est pas exécutable. Mais on a la possibilité d'autoriser ou non la traversé de ce répertoire. On peut par exemple autoriser de traverser un répertoire sans voir son contenu.

En notation octal, les bits de configuration sont dans l'ordre : lecture, écritue, exécution/traversé
Donc
1 = execution/traversé
2 = écriture
3 = execution/traversé + écriture
4 = lecture
5 = lecture + execution/traversé
6 = lecture + écriture
7 = lecture + écriture + execution/traversé

Un fichier ou un répertoire sont affecté à un propriétaire et à un groupe. La notation est dans l'ordre
propriétaire, groupe, autre. Dans la notation couramment présenté sur ce forum, on donne 3 chiffres successifs : xyz.
x correspond aux droits que le propriétaire a sur ce fichier
y correspond aux droits que les membres du groupe ont sur ce fichier
z correspond aux droits des autres utilisateurs sur le fichier

Donc si vous avez bien suivi jusque là, un fichier avec les propriétes 755 est :
accessible en lecture, écriture, exécution pour le propriétaire
accessible en lecture, exécution pour les membres du groupe
accessible en lecture, exécution pour les autres

Dernière précision : de façon générale, un programme a les droits de celui qui lance le programme. Cela afin de garantir la sécurité du système. Pour les serveurs, on utilise des utilisateurs spéciaux. Ces utilisateurs n'ont pas vraiment d'existance, mais permettre de controller les actions de ces programmes. Par exemple, l'utilisateur associé à un serveur Apache peut-être www-data.



Alors, revenons à tes questions :

1er message :
Dans le tuto 2 "transfert d'un site local vers un serveur" on indique en étape 4 les chmod des fichiers à respecter. Il me semble que les chmods indiqués ne sont pas assez stricts en terme de sécurité. Par exemple un chmod 777 sur tous les répertoires et sous-répertoires, un chmod 766 sur pas mal de fichiers (l'administrateur pourrait chnager le chmod juste avant de faire une modif et ne pas permettre l'écriture entre temps), etc...
Des chmods plus stricts ne pourraient-ils pas être une barrière supplémentaire pour les hackers et autres rigolos nuisibles ?
Pourquoi le chmod 744 sur tous les fichiers PHP, et pas 544 ?


Pourquoi un chmod 777 sur les répertoires ?
Un serveur web répond aux requétes des navigateurs web. Dans le cas de npds, les pages sont dynamiques. C'est à dire que leur contenu s'adapte aux diverses requètes à l'instant où ces demandes ont lieu. Cette adaptation est faite par l'intermédiaire de fichier et d'appel à une base de donnée. Il est donc nécessaire de permettre à ce serveur d'accéder à certains fichiers en écriture. Il faut aussi que le serveur puisse créer ses propres fichiers. D'où l'accés en écriture recommandé.

Pourquoi un chmod 766 sur pas mal de fichiers ?
Comme je viens de le dire, le serveur a besoin d'écrire de façon dynamique dans certains fichiers. Ceux sont ces fichiers pour lesquelles ont autorise l'écriture.
Par contre, il n'y a pas d'intérêt a les rendres exécutables pour leur propriétaire. Il n'y a pas d'interpréteur de page php accéssible par le shell sous linux. C'est uniquement le serveur web qui se charge de les interpréter. Donc 666 conviendrait trés bien.

Pourquoi le chmod 744 sur tous les fichiers PHP, et pas 544 ?
Bon, d'abord pourquoi les rendres accessibles en écriture pour le propriétaire du fichier. Bin, pour les éditer pardis ! Mais bon, cela dépend après tout de chacun. C'est sûr que quelqu'un qui n'a nullement l'intention de changer quoi que ce soit à ces fichiers pourrait ce passer de ce droit d'écriture sur ces fichiers. Dans le doute, on conseille donc l'accés en écriture.
On considère cependant que ces fichiers ne doivent pas être modifiée par le serveur web, d'ou l'interdiction d'écriture pour les non propriétaires du fichier.
Pour le droit d'éxécution, même remarque que précédemment.

Des chmods plus stricts ne pourraient-ils pas être une barrière supplémentaire pour les hackers et autres rigolos nuisibles ?
Bin oui et non. On a besoin de créer des fichiers. On ne peut donc pas tout interdire. On concentre donc la protection sur l'interprétation des requêtes envoyés par les navigateurs. C'est les fichiers php qui assurent eux même leur protection, en vérifiant que les ordres qui leurs sont envoyés sont autorisés. L'équipe de sécurité se concentre sur cette tache, d'où peut-être leur raillerie quand à tes remarques.


Autre message :
Je pensais que la protection des fichiers par Unix pouvait interdire à une personne non autorisée de venir les modifier ou supprimer sur un serveur.

Tu pense bien, mais ici le problème vient plus des requêtes exterieur par l'interface web que du serveur lui même. Les serveurs sont pour la plupart peut accessibles. Leur administrateur ont de toute façon tous les droits qu'ils souhaitent, et une personne qui a accés à ses machines de façon frauduleuse à déjà cassé la pluspart de ses protections... Il n'y a plus grand chose à espérer protéger dans ce cas...

Enfin, chaque hébergeur à sa propre politique de gestion de ces machines. On pourrait donc en théorie sécuriser un peu plus parfois les fichiers en autorisant uniquement les membres du groupes du fichier en accés en écriture au fichier. Mais il serait possible que rien ne marche dans certains cas.

Voila, j'espère avoir été assez clair, et n'avoir pas dit trop de conneries...

  Profil  Citation   
Anonyme
19765  

Anonyme
  Posté : 12-05-2006 11:25

Merci infiniment pour cette réponse on ne peut plus claire et trés didactique.

J'ai quelques remarques que je te soumets:

- Pour le chmod 544 au lieu de 744: le propriétaire n'édite pas le fichier directement sur le serveur, mais généralement sur pc, avec re-transfert ensuite sur le serveur, donc en quoi le schmod 544 serait génantsur le serveur ?

- ne serait-il pas interessant de rassembler dans un même répertoire en schmod 777 les quelques fichiers qui doivent être accéssibles en écriture par le serveur Web afin de pouvoir verrouiller en écriture tous les autres répertoires ?

- ne faudrait-il pas également limiter au maximun l'écriture de fichiers et mettre les infos en base de données chaque fois que c'est possible ?
Je prends l'exemple du fichier config.php qui est souvent hacké, ne pourrait-il pas ne contenir que les infos suivantes:

$dbhost = "localhost";
$dbuname = "root";
$dbpass = "";
$dbname = "toto";
$mysql_p = "0";
# =======================
$system = 0;
$system_md5 = 1;

avec tout le reste des infos en base de données, afin de pouvoir le verrouiller en écriture ?


Merci de tes réponses

Bien cordialement

  Citation   
patdef
373      
 

patdef
  Posté : 12-05-2006 16:27

Citation : Anonyme
J'ai quelques remarques que je te soumets:

- Pour le chmod 544 au lieu de 744: le propriétaire n'édite pas le fichier directement sur le serveur, mais généralement sur pc, avec re-transfert ensuite sur le serveur, donc en quoi le schmod 544 serait génantsur le serveur ?
Si tu veux. Mais tu n'auras pas rendu ton applicatif web plus résistant pour autant. Car de toute façon le serveur n'est pas propriétaire du fichier, mais appartient soit au groupe, soit est carrément un utilisateur quelconque. Tu empèche juste tes propres modifications. Et si tu n'as pas l'habitude d'éditer tes fichiers directement sur le serveur, il n'y a pas de risque que ça arrive.

- ne serait-il pas interessant de rassembler dans un même répertoire en schmod 777 les quelques fichiers qui doivent être accéssibles en écriture par le serveur Web afin de pouvoir verrouiller en écriture tous les autres répertoires ?
Pourquoi pas. Mais a partir du moment ou il n'y a ne serait qu'un seul répertoire accessible en écriture, tu n'empècheras jamais le serveur d'y écrire. Et ce qu'il faut donc empécher, ce n'est pas l'écriture proprement dite, mais l'accés en écriture non prévu (par injection de code)

- ne faudrait-il pas également limiter au maximun l'écriture de fichiers et mettre les infos en base de données chaque fois que c'est possible ?
Je prends l'exemple du fichier config.php qui est souvent hacké, ne pourrait-il pas ne contenir que les infos ... avec tout le reste des infos en base de données, afin de pouvoir le verrouiller en écriture ?
On ne peut pas tout mettre dans une base :
- difficile d'y mettre les accés à la base par exemple,
- et si tu prends le cas de supercache, le but est justement de ne pas accéder à la base...
Cela dit, il est effectivement possible de protéger le fichier config.php, si tu acceptes de ne plus pouvoir le modifier en ligne.


  Profil  Citation   
Aller à la page : [ 1 | 2 ]
  
Sauter à :

Temps : 0.0194 seconde(s)