Héberger Administrer droits d'accès SSH FTP intrusion sécurité

Banni | 22 Messages

14 août 2007, 22:18

Je n'ai pas encore d'Apache-Php-Mysql en local, et je pigeais rien à l'informatique.
Mais j'ai pris quelques bouquins et y'é tout compris, les CSS, les Tables,
la variable de connexion qui contient le (Host, User, Password), et même
que le "client localHost" de la Base est le serveur php qui tourne à côté.
C'est vous dire si je suis une lumière !..
Mais à un moment donné, dans ma petite tête, il faut bien transférer cette Base chez l'hébergeur
en essayant de voir l'aspect sécurité...
Et là, incompréhensible !.. Rien mais rien je vous dis. Du chinois.


Ce qui a un peu évolué selon les suites du sujet.


(Je veux donc mettre un forum > sur un serveur plutôt "dédié" > le gérer à distance >
et en effet il nécessitera une protection maximale).
Modifié en dernier par Tomm le 17 août 2007, 06:30, modifié 2 fois.

ViPHP
ViPHP | 5924 Messages

15 août 2007, 00:08

Alors, on va répondre dans l'ordre.
Il faut installer un PhpMyAdmin "chez l'hébergeur" ?
La très grosse majorité des offres mutualisées ont un phpMyAdmin déjà installé, mais j'aurais envie de te dire que c'est strictement facultatif, ce n'est qu'une application te permettant de gérer les bases et tables, on peut faire exactement la même chose à partir d'un script fait maison. Le phpMyAdmin ne t'apporte rien que tu ne puisses faire toi même.
Mon serveur MySql aura un mot-de-passe ? Lequel sera inscrit dans un fichier protégé par mot-de-passe ?
Le tout mis dans des dossiers avec mot-de-passe ?
Le serveur SQL est une application, plus précisément un service, qui a pour rôle de recevoir des requètes du net (dans le rare cas où le serveur SQL est sur la même machine, la requète est transmise par un port local), de les traduire pour savoir exactement ce que le client veut faire, et ensuite d'effectuer les opérations de lecture et/ou écriture sur des fichiers stockés sur le disque dur du serveur, fichiers contenant les données de tes tables. Ces fichiers sont stockés hors de l'arborescence Web et FTP, et innaccessible de l'utilisateur par PHP ou accès SSH, par le système de droit linux, si ce n'est sur un autre serveur. Si l'administrateur fait bien son boulot, les fichiers sont donc innaccessibles de tout accès par tout utilisateur autre qu'un employé de l'hébergeur.
L'authentification marche selon l'utilisateur, l'IP de l'utilisateur et du mot de passe, c'est à dire que tels utilisateurs (potentiellement tous) vont avoir le droit de se connecter à partir de telles IP (potentiellement toutes) et avec tel mot de passe. Et ensuite, une fois authentifié, le serveur contrôle en fonction de l'utilisateur l'opération qu'il essaye de faire, et ce sur quoi il essaye d'agir, c'est à dire qu'un utilisateur a une liste de requètes autorisées (SELECT, UPDATE, DELETE, …) sur des bases ou tables précises. Tous ces droits sont stockés dans une base du serveur SQL, accessible exclusivement à l'administrateur de la base de données (l'hébergeur).
- où sont les points d'identification
Les points d'identification sont :
-A l'entrée de l'arborescence FTP, donc seul ton utilisateur peut accéder à ton FTP, le serveur FTP gère des droits précis par utilisateur FTP restreignant chaque utilisateur à son arborescence.
-A la connexion au serveur SQL, c'est à dire que comme je l'ai expliqué, seul un utilisateur précis peut voir telles bases, et faire telles requètes dessus, donc un autre utilisateur ne peut pas toucher ni accéder à tes bases.
- qui pourrait accéder à des "contrôles serveur" sans être utilisateur des Bases
Seuls les administrateurs peuvent accéder à ton arborescence FTP ou les données de tes bases.
- qui peut voir le système de répertoires Linux
Les administrateurs peuvent voir l'intégralité de l'arborescence du système.
Les utilisateurs de PHP peuvent en voir une partie par les fonctions de dossier, de fichier, et l'exécution de commandes, après, il faut voir ce que PHP permet pour empêcher que 2 utilisateurs puissent voir leurs dossiers respectifs (il est possible que ce soit géré au niveau d'apache). Et l'utilisateur Apache est restreint dans ses actions sur les programmes du système, donc aucun utilisateur ne peut prendre le contrôle du système. Par SSH, c'est plus précis, on se connecte sous un utilisateur précis sur le serveur, donc c'est au niveau des droits du système de fichier que ca se passe, et il est parfaitement possible d'empêcher un utilisateur d'accéder au répertoire d'un autre.
(Je veux donc mettre un forum > sur un serveur plutôt "dédié" > le gérer à distance >
et en effet il nécessitera une protection maximale).
Si tu vas chez un hébergeur mutualisé sérieux, tu n'as pas de raison de te soucier de l'aspect sécurité, ils ont sous la main des outils très divers et précis pour régler les droits. Tous ces outils sont libres donc s'ils n'étaient pas adaptés, ils seraient immédiatement améliorés par la communauté du libre.

ViPHP
ViPHP | 5924 Messages

15 août 2007, 00:49

Les utilisateurs de PHP peuvent en voir une partie par les fonctions de dossier, de fichier, et l'exécution de commandes, après, il faut voir ce que PHP permet pour empêcher que 2 utilisateurs puissent voir leurs dossiers respectifs (il est possible que ce soit géré au niveau d'apache).
Je viens de trouver, c'est géré au niveau d'une directive de PHP : http://www.php.net/manual/fr/features.s ... en-basedir
Cette directive assure que toute opération de php sur le système de fichier devra se faire dans un des dossiers définis par open-basedir, sachant que l'on peut limiter par utilisateur donc un hébergeur mettra typiquement open_basedir = "." (plus peut être les dossiers de certains binaires utiles pour un script), ce qui assurera qu'aucun utilisateur ne pourra agir sur un autre dossier que le dossier . , c'est à dire le dossier de base de son arborescence.

Banni | 22 Messages

15 août 2007, 09:39

Séquiltoyai tu dis : "La très grosse majorité des offres mutualisées ont un phpMyAdmin déjà installé, ...
? "Mutualisé" veut-il dire que plusieurs "sites" domicilient leurs Bases sur le même serveur SQL ?

?? on aurait donc plusieurs "utilisateurs root" avec une feuille de papier entre les Bases ?
... fichiers contenant les données de tes tables. Ces fichiers sont stockés hors de l'arborescence Web et FTP, et innaccessible de l'utilisateur par PHP ou accès SSH, par le système de droit linux, si ce n'est sur un autre serveur. Si l'administrateur fait bien son boulot, les fichiers sont donc innaccessibles de tout accès par tout utilisateur autre qu'un employé de l'hébergeur.
Si je comprends bien tu nous décris la structure d'un "serveur mutualisée"... J'ai donc :

c) - "un bout de disque-dur" avec dedans une "arborescence FTP", dans laquelle j'ai mon arborescence Web

d) - Le fichier de données de ma Base n'est pas dans mon arbre FTP

e) - J'entends qu'on use parfois d'un fichier de connexion avec ses mots-de-passe dedans. Est-il dans mon arbre FTP ou "en dehors".
L'authentification marche selon l'utilisateur, l'IP de l'utilisateur et du mot de passe, c'est à dire que tels utilisateurs (potentiellement tous) vont avoir le droit de se connecter à partir de telles IP (potentiellement toutes) et avec tel mot de passe. Et ensuite, une fois authentifié, le serveur contrôle en fonction de l'utilisateur l'opération qu'il essaye de faire, et ce sur quoi il essaye d'agir, c'est à dire qu'un utilisateur a une liste de requètes autorisées (SELECT, UPDATE, DELETE, …) sur des bases ou tables précises. Tous ces droits sont stockés dans une base du serveur SQL, accessible exclusivement à l'administrateur de la base de données (l'hébergeur).
f) Donc ça c'est le module PHP d'authentification des utilisateurs de la Base
(C'est à dire les utilisateurs du Forum avec le mécanisme de cession).
Mais moi, celui qui attribue des droits et modifie la structure des tables :

g) est-ce que j'utilise strictement ce même point d'authentification mais avec le privilège "root" ?

h) puis-je avec ce "root" accéder aux options de configuration du serveur ?
(Sinon ça signifie qu'il manque un point d'authentification aux deux ci-dessous).
Les points d'identification sont :
A l'entrée de l'arborescence FTP, donc seul ton utilisateur peut accéder à ton FTP, le serveur FTP gère des droits précis par utilisateur FTP restreignant chaque utilisateur à son arborescence.
i ) ? C'est à dire que ce "point d'identification" est le même lors de ma connexion SSH, que
celui de l'hébergeur qui se connecte à mon arborescence FTP (avec mon mot-de-
passe) depuis le clavier du serveur ?
? Ou petite précision : l'hébergeur peut-il se connecter à un autre point plus global du système de
fichiers pour accéder à l'intérieur de mon arborescence FTP.
-A la connexion au serveur SQL
,
(ok : l'authentification d'un utilisateur de la Base)
Les utilisateurs de PHP peuvent en voir une partie par les fonctions de dossier, de fichier, et l'exécution de commandes, après, il faut voir ce que PHP permet pour empêcher que 2 utilisateurs puissent voir leurs dossiers respectifs (il est possible que ce soit géré au niveau d'apache).Et l'utilisateur Apache est restreint dans ses actions sur les programmes du système, donc aucun utilisateur ne peut prendre le contrôle du système. Par SSH, c'est plus précis, on se connecte sous un utilisateur précis sur le serveur, donc c'est au niveau des droits du système de fichier que ca se passe, et il est parfaitement possible d'empêcher un utilisateur d'accéder au répertoire d'un autre.
Je viens de trouver, c'est géré au niveau d'une directive de PHP : http://www.php.net/manual/fr/features.s ... en-basedir <http://www.php.net/manual/fr/features.safe-mode.php> Cette directive assure que toute opération de php sur le système de fichier devra se faire dans un des dossiers définis par open-basedir, sachant que l'on peut limiter par utilisateur donc un hébergeur mettra typiquement open_basedir = "." (plus peut être les dossiers de certains binaires utiles pour un script), ce qui assurera qu'aucun utilisateur ne pourra agir sur un autre dossier que le dossier . , c'est à dire le dossier de base de son arborescence
... Du chinois j'te dis.

j ) ...heu : comment s'assurer qu'un hébergeur a paramétré correctement open_basedir,
car tu dis quand même qu'un "code malin" en php pourrait accéder à des fichiers.

k) je comprends pas le terme "utilisateur Apache" Y'aurait-il encore un 4ième point d'identification d'un "technicien de maintenance Apache", sans rapport avec Sql et les arbres FTP, mais d'où finalement il aurait quand-même un accès à des fichiers ?

L ) et enfin, existe-t-il un accès SSH "plus large" que sur 1 seul arbre FTP d'utilisateur (avec un point d'identification et un mot-de-passe tout à fait "légal")
Modifié en dernier par Tomm le 07 sept. 2007, 00:32, modifié 1 fois.

ViPHP
ViPHP | 5924 Messages

15 août 2007, 13:10

? "Mutualisé" veut-il dire que plusieurs "sites" domicilient leurs Bases sur le même serveur SQL ?
Enormément de sites le font, oui, c'est le principe de tous les hébergements à moins de 20€ par mois.
?? on aurait donc plusieurs "utilisateurs root" avec une feuille de papier entre les Bases ?
???? Tu n'as pas compris, c'est l'administrateur, l'hébergeur, qui a l'accès root, toi tu as un accès utilisateur, restreint à tes bases.
- J'entends qu'on use parfois d'un fichier de connexion avec ses mots-de-passe dedans. Est-il dans mon arbre FTP ou "en dehors".
Bah si tu veux te connecter à ta base, tu dois mettre tes identifiants SQL dans un fichier accessible à toi, donc dans ton arborescence FTP.
Donc ça c'est le module PHP d'authentification des utilisateurs de la Base
(C'est à dire les utilisateurs du Forum avec le mécanisme de cession).
Non, ca n'a rien à voir. PHP ne gère absolument rien au nveau des autentifications. C'est le serveur SQL qui gère tout. Et l'histoire de l'autentification des membres d'un forum, c'est complètement différent, c'est le script de forum qui gère ça.
Mais moi, celui qui attribue des droits et modifie la structure des tables :

g) est-ce que j'utilise strictement ce même point d'authentification mais avec le privilège "root" ?

h) puis-je avec ce "root" accéder aux options de configuration du serveur ?
(Sinon ça signifie qu'il manque un point d'authentification aux deux ci-dessous).
Le problème ne se pose pas puisque tu n'es root que si tu as un dédié, et si tu as un dédié, c'est toi qui gère tout. Au passage, un compte root, traditionnellement, et le compte qui a tous les droits, donc si tu parles d'un compte root, implicitement tu parles d'un compte qui peut tout faire.
C'est à dire que ce "point d'identification" est le même lors de ma connexion SSH, que
celui de l'hébergeur qui se connecte à mon arborescence FTP (avec mon mot-de-
passe) depuis le clavier du serveur ?

? Ou petite précision : l'hébergeur peut-il se connecter à un autre point plus global du système de
fichiers pour accéder à l'intérieur de mon arborescence FTP.
Alors un serveur n'a pas de clavier, et personne ne se connecte avec tes identifiants (à moins que tu les aies donnés). L'hébergeur, ou plutôt ses employés, se connectent avec un compte ayant toutes les autorisations, ils n'ont pas besoin de ton mot de passe.
...heu : comment s'assurer qu'un hébergeur a paramétré correctement open_basedir,
car tu dis quand même qu'un "code malin" en php pourrait accéder à des fichiers.
Les bons hébergeurs connaissent leur métier, ils configurent les sécurités comme il faut.
J'ai peut être dit que peut être était-ce possible, mais la directive open-basedir prouve qu'en fait, pour cela aussi, il y a une mesure de protection, donc ce n'est pas possible.
je comprends pas le terme "utilisateur Apache" Y'aurait-il encore un 4ième point d'identification d'un "technicien de maintenance Apache", sans rapport avec Sql et les arbres FTP, mais d'où finalement il aurait quand-même un accès à des fichiers ?
Non, mais le système linux a son système d'autorisations pour l'accès aux fichiers, chaque programme se lance sous un nom d'utilisateur, et chaque nom utilisateur du système a des droits précis d'éxécution, d'écriture, et de lecture, sur les fichiers du disque. C'est un système complètement indépendant du système d'utilisateurs du FTP, ainsi que du serveur SQL, même si le service FTP et le service SQL doivent obéir aussi aux droits du système de fichier.
et enfin, existe-t-il un accès SSH "plus large" que sur 1 seul arbre FTP d'utilisateur (avec un point d'identification et un mot-de-passe tout à fait "légal")
Pour les besoins de la configurations, il y a un accès SSH root ou équivalent pour que l'hébergeur puisse accéder à la machine, mais je ne pense pas que les hébergeurs sérieux le laissent accessibles du net.
(On va se faire un bon "tuto" là...)
J'y pense, parce que tu n'as vraiment pas l'air de comprendre ce que je te dis.

Banni | 22 Messages

16 août 2007, 04:31

...
Modifié en dernier par Tomm le 17 août 2007, 20:59, modifié 1 fois.

ViPHP
ViPHP | 5924 Messages

16 août 2007, 13:23

Alors :

SSH n'a rien à voir avec Apache, c'est un protocole qui permet de se connecter à distance sur une machine, par exemple pour de la gestion. C'est simplement un terminal de gestion. Il utilise les utilisateurs du système Linux.

Apache ignore tout du FTP, les deux applications sont totalement indépendantes, on peut notamment avoir l'un sans l'autre.

Si une personne a des identifiants pour un compte d'utilisateur du système qui a suffisamment de droits sur tes répertoires, et qu'il peut l'utiliser par une connexion SSH, alors il n'a besoin de rien d'autre, mais seuls les administrateurs possèdent ces comptes. Si jamais il t'est donné un compte SSH, alors il suffit de ne pas perdre ses mots de passe pour s'assurer que personne n'accédra à ses dossiers.

La liste d'utilisateurs FTP est indépendante de la liste d'utilisateurs du système, et possède ses propres droits sur les dossiers, mais dans tous les cas, le FTP doit avoir les droits (au niveau du système) sur les dossiers auquel il accède.

Apache reçoit des connexions HTTP et HTTPS et ne gère aucune table particulière d'utilisateurs pour une quelconque autentification. La seule autentification que l'on peut avoir sous apache, c'est une autentification par Require user, ou Require group, dans des fichiers .htaccess ou encore dans la configuration globale, mais Apache n'est pas fait particulièrement pour gérer des droits. L'énorme majorités des connexions au serveur ne requiert aucune autorisation, puisque n'est sensé être dans le document root, racine de l'arborescence web, que des documents dont la diffusion est souhaitée.