J'ai un probleme avec un site Web qui vient de se faire defacer, hebergé
sur un serveur mutualisé dont 8 sites ont été defacés aujourd'hui.
Le www etait en 777 et l'attaquant a eu un acces au serveur par une faille
venant de mon site ou d'un autre et n'a eu qu'a mettre un index.html.
Le pb est que je dois laisser des rep. en ecriture pour que PHP/Apache
(tournant sous nobody) puisse ecrire des fichiers, que ces rep. sont
devinable a cause des scripts PHP qui y sont et que donc n'importe qui
ayant acces a la machine peut y ecrire.
Comment concilier les 2 ?
En me loggant par SSH, je peux voir le /etc/password et ainsi connaitre
tous les comptes et les chemins vers les www.
Est-ce normal pour un hebergement même mutualisé ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Xavier Roche
Le www etait en 777 et l'attaquant a eu un acces au serveur par une faille venant de mon site ou d'un autre et n'a eu qu'a mettre un index.html.
Hmm. Un mutualisé qui laisse tourner un mod_php non renforcé, avec en prime tout le monde qui se voit et peut lire ses fichiers ? Avec je suppose également un /tmp executable, un inetd là ou il faut pour se lancer une porte dérobée en backdoor, etc. ?
Hum.
En me loggant par SSH, je peux voir le /etc/password et ainsi connaitre tous les comptes et les chemins vers les www. Est-ce normal pour un hebergement même mutualisé ?
Euh, non. Enfin franchement, non.
Le www etait en 777 et l'attaquant a eu un acces au serveur par une faille
venant de mon site ou d'un autre et n'a eu qu'a mettre un index.html.
Hmm. Un mutualisé qui laisse tourner un mod_php non renforcé, avec en
prime tout le monde qui se voit et peut lire ses fichiers ? Avec je
suppose également un /tmp executable, un inetd là ou il faut pour se
lancer une porte dérobée en backdoor, etc. ?
Hum.
En me loggant par SSH, je peux voir le /etc/password et ainsi connaitre
tous les comptes et les chemins vers les www.
Est-ce normal pour un hebergement même mutualisé ?
Le www etait en 777 et l'attaquant a eu un acces au serveur par une faille venant de mon site ou d'un autre et n'a eu qu'a mettre un index.html.
Hmm. Un mutualisé qui laisse tourner un mod_php non renforcé, avec en prime tout le monde qui se voit et peut lire ses fichiers ? Avec je suppose également un /tmp executable, un inetd là ou il faut pour se lancer une porte dérobée en backdoor, etc. ?
Hum.
En me loggant par SSH, je peux voir le /etc/password et ainsi connaitre tous les comptes et les chemins vers les www. Est-ce normal pour un hebergement même mutualisé ?
Euh, non. Enfin franchement, non.
Mihamina (R12y) Rakotomandimby
Thierry - :
Est-ce normal pour un hebergement même mutualisé ?
Peut être que ça n'a pas toujours été le cas. C'est peut-être "la chose" qui a tout ouvert comme ça, je veux dire.
Est-ce normal pour un hebergement même mutualisé ?
Peut être que ça n'a pas toujours été le cas. C'est peut-être "la chose" qui a tout ouvert comme ça, je veux dire.
Thierry
Xavier Roche écrivait news:f5u84b$uth$:
Le www etait en 777 et l'attaquant a eu un acces au serveur par une faille venant de mon site ou d'un autre et n'a eu qu'a mettre un index.html.
Hmm. Un mutualisé qui laisse tourner un mod_php non renforcé, avec en prime tout le monde qui se voit et peut lire ses fichiers ?
Quasiment. J'ai fait un tour du proprio et beaucoup ont des config.php lisible. Bref, au niveau droit que mettre pour qu'Apache/PHP puisse ecrire sans que les petits camarades ne puisse pas lire mes fichiers de conf, ni ecrire n'importe quoi dans les rep que je doislaisser en ecriture pour Apache ? Il y a une solution ?
Sinon : 2.4.20-29.7.progeny.9 #1 Fri Jan 7 17:11:38 EST 2005 i686 unknown
C'est pas un peu viellot ?
Avec je
suppose également un /tmp executable, un inetd là ou il faut pour se lancer une porte dérobée en backdoor, etc. ?
Hum.
En me loggant par SSH, je peux voir le /etc/password et ainsi connaitre tous les comptes et les chemins vers les www. Est-ce normal pour un hebergement même mutualisé ?
Le www etait en 777 et l'attaquant a eu un acces au serveur par une
faille venant de mon site ou d'un autre et n'a eu qu'a mettre un
index.html.
Hmm. Un mutualisé qui laisse tourner un mod_php non renforcé, avec en
prime tout le monde qui se voit et peut lire ses fichiers ?
Quasiment. J'ai fait un tour du proprio et beaucoup ont des config.php
lisible. Bref, au niveau droit que mettre pour qu'Apache/PHP puisse ecrire
sans que les petits camarades ne puisse pas lire mes fichiers de conf, ni
ecrire n'importe quoi dans les rep que je doislaisser en ecriture pour
Apache ?
Il y a une solution ?
Sinon :
2.4.20-29.7.progeny.9 #1 Fri Jan 7 17:11:38 EST 2005 i686 unknown
C'est pas un peu viellot ?
Avec je
suppose également un /tmp executable, un inetd là ou il faut pour se
lancer une porte dérobée en backdoor, etc. ?
Hum.
En me loggant par SSH, je peux voir le /etc/password et ainsi
connaitre tous les comptes et les chemins vers les www.
Est-ce normal pour un hebergement même mutualisé ?
Le www etait en 777 et l'attaquant a eu un acces au serveur par une faille venant de mon site ou d'un autre et n'a eu qu'a mettre un index.html.
Hmm. Un mutualisé qui laisse tourner un mod_php non renforcé, avec en prime tout le monde qui se voit et peut lire ses fichiers ?
Quasiment. J'ai fait un tour du proprio et beaucoup ont des config.php lisible. Bref, au niveau droit que mettre pour qu'Apache/PHP puisse ecrire sans que les petits camarades ne puisse pas lire mes fichiers de conf, ni ecrire n'importe quoi dans les rep que je doislaisser en ecriture pour Apache ? Il y a une solution ?
Sinon : 2.4.20-29.7.progeny.9 #1 Fri Jan 7 17:11:38 EST 2005 i686 unknown
C'est pas un peu viellot ?
Avec je
suppose également un /tmp executable, un inetd là ou il faut pour se lancer une porte dérobée en backdoor, etc. ?
Hum.
En me loggant par SSH, je peux voir le /etc/password et ainsi connaitre tous les comptes et les chemins vers les www. Est-ce normal pour un hebergement même mutualisé ?
Euh, non. Enfin franchement, non.
Thierry
"Mihamina (R12y) Rakotomandimby" écrivait news::
Thierry - :
Est-ce normal pour un hebergement même mutualisé ?
Peut être que ça n'a pas toujours été le cas. C'est peut-être "la chose" qui a tout ouvert comme ça, je veux dire.
C'etait pareil avant. Voire pire, le /home/ etait listable.
C'etait pareil avant. Voire pire, le home etait listable.
Et... personne n'a remonté ça au support technique? Et puis tant qu'à faire: c'est quel hébergeur?
Fabien LE LEZ
On 27 Jun 2007 22:35:26 GMT, Thierry :
Il y a une solution ?
Il y a des solutions pour sécuriser tout ça, mais c'est à l'hébergeur de les mettre en place. Et si l'hébergeur en question n'a pas les compétences ou la volonté pour ça, il faut changer d'hébergeur.
On 27 Jun 2007 22:35:26 GMT, Thierry <yarglah@com.invalid>:
Il y a une solution ?
Il y a des solutions pour sécuriser tout ça, mais c'est à l'hébergeur
de les mettre en place.
Et si l'hébergeur en question n'a pas les compétences ou la volonté
pour ça, il faut changer d'hébergeur.
Il y a des solutions pour sécuriser tout ça, mais c'est à l'hébergeur de les mettre en place. Et si l'hébergeur en question n'a pas les compétences ou la volonté pour ça, il faut changer d'hébergeur.
Malcom
On 28 juin, 19:08, Fabien LE LEZ wrote:
On 27 Jun 2007 22:35:26 GMT, Thierry :
Il y a une solution ?
Il y a des solutions pour sécuriser tout ça, mais c'est à l'hébergeur de les mettre en place. Et si l'hébergeur en question n'a pas les compétences ou la volonté pour ça, il faut changer d'hébergeur.
Peut tu modifier les droits sur ton répertoire www ? Si oui, celui-ci ne doit être accessible qu'au groupe nobody et au user sous lequel s'exécute Apache (en général www-data). Tu n'es aucunement obligé de laisser l'accès en écriture à tout le monde !
On 28 juin, 19:08, Fabien LE LEZ <grams...@gramster.com> wrote:
On 27 Jun 2007 22:35:26 GMT, Thierry <yarg...@com.invalid>:
Il y a une solution ?
Il y a des solutions pour sécuriser tout ça, mais c'est à l'hébergeur
de les mettre en place.
Et si l'hébergeur en question n'a pas les compétences ou la volonté
pour ça, il faut changer d'hébergeur.
Peut tu modifier les droits sur ton répertoire www ? Si oui, celui-ci
ne doit être accessible qu'au groupe nobody et au user sous lequel
s'exécute Apache (en général www-data). Tu n'es aucunement obligé de
laisser l'accès en écriture à tout le monde !
Il y a des solutions pour sécuriser tout ça, mais c'est à l'hébergeur de les mettre en place. Et si l'hébergeur en question n'a pas les compétences ou la volonté pour ça, il faut changer d'hébergeur.
Peut tu modifier les droits sur ton répertoire www ? Si oui, celui-ci ne doit être accessible qu'au groupe nobody et au user sous lequel s'exécute Apache (en général www-data). Tu n'es aucunement obligé de laisser l'accès en écriture à tout le monde !
Thierry
"Fabien LE LEZ" a écrit dans le message de news:
On 27 Jun 2007 22:35:26 GMT, Thierry :
Il y a une solution ?
Il y a des solutions pour sécuriser tout ça, mais c'est à l'hébergeur de les mettre en place.
Je viens de decouvrir un mode "run PHP as your user" (CGI ?) dans l'interface d'admin qui permettra de virer tous les droits d'ecriture pour "le reste du monde". C'eut été bien que ce soit le mode par defaut....
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
foq783hulfchumn852ugua13sn9sp62v0n@4ax.com...
On 27 Jun 2007 22:35:26 GMT, Thierry <yarglah@com.invalid>:
Il y a une solution ?
Il y a des solutions pour sécuriser tout ça, mais c'est à l'hébergeur
de les mettre en place.
Je viens de decouvrir un mode "run PHP as your user" (CGI ?) dans
l'interface d'admin qui permettra de virer tous les droits d'ecriture pour
"le reste du monde".
C'eut été bien que ce soit le mode par defaut....
Il y a des solutions pour sécuriser tout ça, mais c'est à l'hébergeur de les mettre en place.
Je viens de decouvrir un mode "run PHP as your user" (CGI ?) dans l'interface d'admin qui permettra de virer tous les droits d'ecriture pour "le reste du monde". C'eut été bien que ce soit le mode par defaut....
