[Réglé] : CHMOD

[Cap Langues]

Bonsoir,
J'aurais besoin de chmoder 2 fichier en 444 pour sécuriser un de mes sites, mais les fichiers sont attribué à apache, comment puis-je changer le chmod (avec mon compte DA, il me dit que je n'ai pas les droits, apparemment il faut un accès root).

Sinon, si je vous donne le chemin des fichiers, pouvez vous modifier juste 2 chmod staff?

Merci

[Spinacle]

Effectivement, il faut modifier les fichiers en SSH dans ce cas.

[Cap Langues]

les 2 fichiers, il vaut mieux que je les mettent en 444, ce sont les fichiers de configuration.

[Tyrtamos]

Bonjour,

Une autre solution serait d'uploader par ftp un fichier php (dans un répertoire lui-aussi créé par ftp), dont le script serait construit pour changer les droits de ces 2 fichiers (fonction chmod()).

En effet, le script php s'exécutant pour le compte d'apache peut modifier les droits des fichiers appartenant à apache.

Tyrtamos

[Cap Langues]

Bonnes idées, mais le hic, c'est que je ne sais absolument pas le faire.

[Tyrtamos]

Bonjour,

Ce serait bien d'avoir une page php qui permette de naviguer dans le site et d'effectuer quelques tâches d'administration comme ça. Mais ce ne serait pas prudent pour la sécurité!

A défaut, voilà ce que je vous propose.

Vous uploadez par ftp à la racine de votre site, la page php "modifdroits.php, qui ne contient que:

Code: [Select]

<?php
$fichier='rep1/rep2/fichieramodifier';
chmod($fichier, 0444);
?>
Attention: le chemin du fichier est ici un chemin absolu par rapport à la racine du linux, et non par rapport à la racine du site. Je vous conseille donc un chemin relatif (=qui ne commence pas de "/").

Vous pouvez remplacer le 0444 par ce que vous voulez, y compris 0777, mais n'oubliez pas le zéro devant parce que c'est un nombre octal (ce n'est pas par défaut pour chmod() de php).

Une fois la page uploadée, il suffit de l'appeler dans un navigateur pour que l'opération soit exécutée.

Bien sûr, ça ne marche que pour les pages crées par php, et de ce fait appartenant à apache.

Et je vous suggère de supprimer cette page modifdroits.php quand c'est fini!

On pourrait utiliser le même principe pour supprimer certains fichiers qui, étant créés par php, ne peuvent être supprimés par ftp.

Ok?

Tyrtamos

[Cap Langues]

Merci, c'est déjà plus sécurisé, mais j'ai tout de même un doute au niveau sécurité.
Si j'ai un répertoire en 777, n'importe qui pourrait injecter un fichier de ce genre et changer tous les chmod, non?

[thd]

Salut Cap,
si c'est pour ton site joomla, utilise JoomlaXplorer.
ThD

[Tyrtamos]

Je ne suis pas spécialiste de la sécurité des sites web, mais ça me semble un peu plus difficile que ça.

Pour télécharger un fichier sur un site, il ne faut pas seulement le droit d'écriture sur le répertoire, il faut aussi accéder au site avec un protocole qui permette le téléchargement, ftp par exemple, donc avec un mot de passe.

Par contre, un pirate peut utiliser une faille de programmation dans un script php.

Imaginez par exemple que vous ayez construit une page qui efface les fichiers, avec le nom du fichier passé en paramètre. Cela pourrait ressembler à cela:

Code: [Select]

<?php
$fichier=$_GET['fichier'];
unlink($fichier);
?>
Si un pirate s'en aperçoit, il peut appeler lui-même avec un simple navigateur, comme vous pourriez le faire vous-même:

Code: [Select]

http://www.votresite.com/modifdroits.php?fichier=nimportequelfichier
Avec les dégats que vous pouvez imaginez... De plus, le chemin du fichier étant absolu par rapport à la racine linux: il pourrait essayer de détruire un fichier mal protégé du système linux. Enfin, il pourrait essayer de passer une commande shell au lieu d'un simple fichier et, pourquoi pas, une commande "wget" qui pourra télécharger un fichier exécutable et essayer de lui passer la main.... Etc...

D'où l'importance de vérifier strictement tous les paramètres passés avant de les utiliser, et de garantir en particulier l'absence de code shell entouré d'apostrophes inversés. Il faut aussi effacer ce genre de fichier utilitaire après usage.

Il y a aussi les très nombreuses précautions que les hébergeurs (dont Edel) prennent dans la configuration du serveur. Par exemple, empêcher qu'on puisse lister le contenu des répertoires, empêcher qu'on puisse exécuter du code binaire dans les sites, etc...

Mais je préfèrerais que quelqu'un de plus expérimenté que moi vous donne une réponse plus complète sur ce sujet.

Tyrtamos

[staff]

Bonjour

Merci de votre post de grande qualité comme toujours

Nous travaillons sur plusieurs axes pour éviter ces soucis:

1 - Restriction des outils comme wget au root. Vous désactivation totale.

2 - Interdiction a Apache d'aller chercher des fichiers PHP ailleurs que sur le serveur lui même.
Par exemple:
http://www.votresite.com/modifdroits.php?fichier=http://....

Ne passe pas.

3 - Blocage de toutes les fonctions faisant appel au shell depuis PHP

Ce n'est pas absolument inviolable, mais 99% des attaques deviennent impossibles. Les Kernels de Linux sont tout simplement pourris de failles. Beaucoup de Linuxiens disent que Linux est plus sûr que Windows, mais il n'est est rien du tout. Chaque mois, des exploits Linux sortent. Ils permettent de prendre le contrôle totale de n'importe quelle machine Linux placée en réseau. Biensûr, il y a des correctifs qui sont mis en ligne assez vite. Entre temps, beaucoup de machines se retrouvent compromises avec des dégâts économiques considérables.

[Cap Langues]

Un grand merci à tous pour toutes ces lumières sur la question.

Clair suffisamment concis, que demander de mieux!!!!

[Tyrtamos]

Merci du compliment, staff!

On sait que linux n'est pas beaucoup plus sûr que windows quand on compare les OS standards. Mais il est certain aussi qu'on peut rendre linux plus sûr parce qu'il en a les potentialités.

Par exemple, le montage des sites sur une partition séparée avec "noexec" comme option empêche facilement l'exécution de code binaire. Et seul root peut démonter.

Mais il est vrai aussi que lorsqu'on fait la liste de tout ce qu'il faut faire pour sécuriser un serveur "lamp" à partir d'une distribution standard, on se retrouve avec une liste très impressionnante de choses à faire pour la sécurité. A commencer par virer tout ce qui n'est pas absolument utile pour le serveur (dont le graphique). Le partitionnement contribue aussi à la sécurité (5 ou 6 partitions avec les bonnes options). On peut même prévoir une partition séparée pour les mail (/var/spool/mail) pour qu'un attaque dos ne coince pas le système ni les sites ni les bases de données mysql. On peut aussi restreindre strictement à root l'exécution de toutes les commandes système (y compris ls, cp, ...). Etc... On peut même recompiler le kernel pour retirer tous les modules inutiles (pilotes correspondant à des périphériques qu'on n'a pas), et intégrer en dur les pilotes utiles, ce que microsoft aura du mal à permettre à ses clients...

Il existe des bouquins là-dessus. Et on peut passer plusieurs semaines à temps plein sur un tel sujet, même en connaissant bien linux.

Linux a enfin un avantage: chaque trou de sécurité est comblé assez vite grâce au code ouvert et au nombre de personnes impliquées.

Bien sûr, c'est comme pour son domicile: on ne peut pas empêcher à coup sûr un cambrioleur de rentrer, on ne peut seulement que multiplier les obstacles pour lui donner envie d'aller ailleurs... D'où l'intérêt de surveiller fréquemment les fichiers log .

Tyrtamos

[Cap Langues]

Pour conclure, dans tous les cas, il n'existe aucun système sûr à 100%, comme je dis toujours si quelqu'un à su le faire, il y a forcément quelqu'un pour le défaire.

Et la polémique Linux/Microsoft, je ne dirais qu'une chose, tout dépend des besoins que l'on a.
Au Luxembourg par exemple, il existe beaucoup d'établissement financier qui ont leurs serveurs sous windows 2003 avec un niveau de sécurité très élevé à mon avis.

Et ce qui pour moi, contribue le plus à la sécurité du système, c'est l'administrateur (ou technicien), donc ici, Edel qui nous protège de bien des soucis.

[Tyrtamos]

Et ce qui pour moi, contribue le plus à la sécurité du système, c'est l'administrateur (ou technicien), donc ici, Edel qui nous protège de bien des soucis.

Il n'y aucun doute là-dessus!

Tyrtamos

[staff]

C'est clair, en terme de potentiel, on est d'accord. Linux offre de nombreuses options en termes de sécurité, mais encore faut-il avoir le temps et les connaissances pour les utiliser toutes. La communauté Linux réagit assez vite, mais il reste des aberrations:

Exemple: On est en mars 2007, les toutes dernières versions de CentOS sont encore distribuées avec le SSH1 actif ! Pourtant, il y a 15000 ans qu'on sait que ce protocole est peu sûr et personne ne doit l'utiliser.

Ainsi, chaque fois qu'on fait une install, on doit aller manuellement désactiver le SSH1 et ne laisser que le SSH2. Si un admin met plusieurs serveurs en ligne et oublie un sous SSH1, le risque est là.

Pareil pour les partitions. Par exemple, sur tous nos dédiés on installe une partition /tmp avec noexec, nosuid. C'est un truc tout bête mais qui décourage la moitié des attaques, pourtant, il n'est pas inclut par défaut dans les install...

Rien que le register_globals, ca fait seulement 15 jours qu'il par défaut sur OFF avec les distributions de Direct Admin. Avant, chaque fois qu'on mettait à jour PHP, il passait sur ON.