By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,058 Members | 1,217 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,058 IT Pros & Developers. It's quick & easy.

Sécurité des fichiers surun serveur

P: n/a
Bonjour,

Plusieurs fichiers PHP d'un programme open source de compteur de visites
viennent de se faire hacker sur mon serveur (hébergement mutualisé chez un
fournisseur d'accès). Le hacker a déposé un code permettant visiblement de
passer un script en argument tout en signant son passage (rory). Je voulais
savoir quel était la meilleure façon de sécuriser ces fichiers. Comme c'est
un serveur Unix, j'ai déjà corrigé les autorisations d'écriture qui étaient
déficientes (un write all sur le dossier principal !). Mais, est-ce
suffisant ? Que puis-je faire d'autre ?

D'avance merci de votre aide.

Christophe

Aug 30 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Chris wrote:
Bonjour,

<snip>

In future, please use English, this is internation newsgroup. Free
translation with Google (for others):

Hello,

Several files PHP of an open program source of meter of visits have
been just made hacker on my waiter (lodging mutualized in a supplier of
access). The hacker deposited a code obviously making it possible to
pass a script in argument while signing its passage (rory). I wanted
to know which was the best way of making safe these files. As it is a
Unix waiter, I already corrected the authorizations of writing which
were defective (Write all on the principal file!). But, is this
sufficient? What can I make of other? In advance thank you for your
assistance.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

Aug 30 '05 #2

P: n/a

Le 30.8.2005 16:25, «*Chris*» <cm****@hotmail.com> a écrit*:
Bonjour,

Plusieurs fichiers PHP d'un programme open source de compteur de visites
viennent de se faire hacker sur mon serveur (hébergement mutualisé chez un
fournisseur d'accès). Le hacker a déposé un code permettant visiblement de
passer un script en argument tout en signant son passage (rory). Je voulais
savoir quel était la meilleure façon de sécuriser ces fichiers. Comme c'est un
serveur Unix, j'ai déjà corrigé les autorisations d'écriture qui étaient
déficientes (un write all sur le dossier principal !). Mais, est-ce suffisant
? Que puis-je faire d'autre ?

D'avance merci de votre aide.

Christophe


Sorry, I am upset and I didn't see I sent my post to an english speaking PHP
newsgroup. I translate my message.

Some files from an open source software (log analyzer) I use have been
hacked on my server (commercial shared hosting). It is an Unix server and I
failed to set the proper permissions (I set chmod 777 on the main folder).
Now, I set the correct permission, but I wonder if I can do something else
to secure it.

Thanks for your help,

Christophe
Aug 30 '05 #3

P: n/a
I think it's funny that Google translated "serveur" (as in a web
server, file server, whatever) into "waiter".

Aug 30 '05 #4

P: n/a
Chris wrote:
Some files from an open source software (log analyzer) I use have been
hacked on my server (commercial shared hosting). It is an Unix server and I
failed to set the proper permissions (I set chmod 777 on the main folder).
Now, I set the correct permission, but I wonder if I can do something else
to secure it.


AW Stats perhaps? Upgrade and be sure to stay current and follow the
directions. Also, make sure that you protect the directory with a
password (Apache's Basic Auth should be enough) so people can't run the
script without the correct credentials.

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com
Aug 30 '05 #5

P: n/a

Le 30.8.2005 20:39, dans 6K********************@onvoy.com, «*Justin
Koivisto*» <ju****@koivi.com> a écrit*:
AW Stats perhaps? Upgrade and be sure to stay current and follow the
directions. Also, make sure that you protect the directory with a
password (Apache's Basic Auth should be enough) so people can't run the
script without the correct credentials.

Thanks for the tip.

Christophe

Aug 31 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.