Sécurisation .htaccess et wp-config.php

Statut : non résolu

Ce sujet contient 20 réponses, 7 participants et a été mis à jour pour la dernière fois par Lumiere de Lune, le il y a 13 années et 8 mois.

15 sujets de 1 à 15 (sur un total de 21)

1 2 →

Auteur

Messages
1 juin 2011 à 13 h 44 min #495753
jeffrey-omega
Membre

Initié WordPress
23 contributions
Bonjour,

Ma configuration WP actuelle
– Version de WordPress : 3.1.3
– Version de PHP/MySQL :
– Thème utilisé : jeffrey-omega
– Extensions en place :
– Nom de l’hebergeur : goldzoneweb
– Adresse du site : http://japan.goldzoneweb.info

Problème(s) rencontré(s) : avoir plus de sécurité

Bonjour tout le monde
Aujourd’hui j’ai fait un teste au niveau de la sécurité sur mon installation wordpress et j’ai obtenu une bonne note de la part du plugin de teste « Ultimate Security Checker » 101 sur 104 comme vous pouvez le voir sur l’image si-dessous:

Maintenant le problème que je rencontre c’est que apparemment mon fichier wp-config est mal placer et que des personnes mal intentionnées pourraient en profiter pour faire des choses avec le fichier.

J’ai lu les conseilles que donne le plugin mais c’est un peu mal fait parce que pour toutes failles vérifiée par le plugin il y a des explications détaillée sauf pour la démarche à suivre pour réglé le problème du wp-config.php 😮 (il dit que le fichier doit être déplacé mais que ce n’est pas très conseillé car après on peut avoir des problèmes avec des plugins si ils sont mal codé ou d’autre choses)

Je me suis documenter sur le net et obtenu le code suivant à insérer dans le fichier « .htaccess »
```
# protect the htaccess file
<files .htaccess>
order allow,deny
deny from all
</files>

# disable the server signature
ServerSignature Off

# limit file uploads to 10mb
LimitRequestBody 10240000

# protect wpconfig.php
<files wp-config.php>
order allow,deny
deny from all
</files>

#who has access who doesnt
order allow,deny
#deny from 000.000.000.000
allow from all

#custom error docs
ErrorDocument 404 /notfound.php
ErrorDocument 403 /forbidden.php
ErrorDocument 500 /error.php

# disable directory browsing
Options All -Indexes

#redirect old to new
Redirect 301 /old.php http://www.yourdomain.com/new.php

#block referring domains
RewriteEngine on
RewriteCond %{HTTP_REFERER} digg.com [NC]
RewriteRule .* – [F]

#disable hotlinking of images with forbidden or custom image option
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www.)?yourdomain.com/.*$ [NC]
#RewriteRule .(gif|jpg)$ – [F]
#RewriteRule .(gif|jpg)$ http://www.yourdomain.com/stealingisbad.gif [R,L]

# php compression – use with caution
<ifmodule mod_php4.c>
php_value zlib.output_compression 16386
</ifmodule>

# set the canonical url
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com$ [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [R=301,L]

# protect from spam comments
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post.php*
RewriteCond %{HTTP_REFERER} !.*yourdomain.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
```
J’aimerais savoir ce que vous en pensez ? Et comment procéder parce que apparement c’est pas très conseiller de jouer avec.
1 juin 2011 à 14 h 07 min #774011

Lumiere de Lune
Participant

Maître WordPress
20531 contributions

Je vais te donner un conseil : laisse tomber

parce que tu es sur un serveur mutualisé et que la plupart des questions de sécurité sont traitées par ton mutu, et que ces plugins soit disant de sécurité ne servent pas à grand chose, puisqu’ils n’identifient pas les failles dans le code de wordpress.

Déplacer le wp-config.php est une connerie, ça ne sert à rien, si un hacker a les moyens d’y accéder ou d’y écrire quelque chose c’est déjà trop tard…

1 juin 2011 à 14 h 49 min #774012
jeffrey-omega
Membre

Initié WordPress
23 contributions
Lumière de Lune wrote:

Je vais te donner un conseil : laisse tomber

parce que tu es sur un serveur mutualisé et que la plupart des questions de sécurité sont traitées par ton mutu, et que ces plugins soit disant de sécurité ne servent pas à grand chose, puisqu’ils n’identifient pas les failles dans le code de wordpress.

Déplacer le wp-config.php est une connerie, ça ne sert à rien, si un hacker a les moyens d’y accéder ou d’y écrire quelque chose c’est déjà trop tard…

Justement si tu déplaces le fichier quelque part où les hackers ne cherche pas sa va leur compliquer la vie et ainsi avoir un peu plus de sécurité sur son site
How about creating a separate PHP file in a non-WWW accessible location and use the WP-Config to include that file.

Say for example that your web include path for your server was /home/yourname/public_html/. You can actually save a file in the /home/yourname/ area and it won’t be web accessible. Meaning that even if somebody were able to read your wp-config, they wouldn’t get anything valuable.

Here are the steps that I took.

Create a « config.php »

Within this config.php file I included the following:
PHP:
I uploaded this file to a non-WWW readable location. Normally this should be the directory before « public_html » or « www ».

Modify the WP-Config

I then modified the « wp-config.php » file to include the file. If somebody were to somehow read the contents of my WP-Config, all they would see is this:
PHP:
Please note that the include paths change from server to server, but hopefully you get the idea. Save your sensitive information in a non-WWW location, and have the WP-Config file read it in. This way you won’t have to change anything if you have to upgrade WordPress.

Conclusion

If a person with malicious intent finds your WP-Config file and can actually read the contents, your website is exposed. Devlounge wrote an article earlier today that revealed how easy it is for a hacker to change your password (and get admin access to your blog) using phpMyAdmin.

You can never be too careful about these things, so protect your WP-Config and make sure you have a recent database backup.

If there are any more ways to protect the WP-Config that I didn’t already mention, please feel free to add them in the comments.
1 juin 2011 à 17 h 13 min #774013

shamateur
Membre

Padawan WordPress
82 contributions

Si ta vraiment peur pour ton wp.config.php, tu peux toujours stocker les variables sensibles de ce fichier dans un autre fichier situé dans un autre repertoire protégé par un .htaccess + chmod. Il ne restera plus qu’à faire un require_once dans ton wp.config.php et pour noyer le poisson tu fais des « leurres » avec plusieurs require de fichiers php vides, comment ça je suis parano moi 😆

Mais bon comme le dit Lumière de Lune, si un hacker parvient à accéder à ton wp-config.php cette « parade » ne vas pas le retarder bien longtemps…

1 juin 2011 à 17 h 18 min #774014

jeffrey-omega
Membre

Initié WordPress
23 contributions

shamateur wrote:

Si ta vraiment peur pour ton wp.config.php, tu peux toujours stocker les variables sensibles de ce fichier dans un autre fichier situé dans un autre repertoire protégé par un .htaccess + chmod. Il ne restera plus qu’à faire un require_once dans ton wp.config.php et pour noyer le poisson tu fais des « leurres » avec plusieurs require de fichiers php vides, comment ça je suis parano moi 😆

Mais bon comme le dit Lumière de Lune, si un hacker parvient à accéder à ton wp-config.php cette « parade » ne vas pas le retarder bien longtemps…

Bon alors effectivement je vais laisser tomber sujet résolut lol merci pour vos réponses

1 juin 2011 à 18 h 33 min #774015

RunWP
Membre

Initié WordPress
18 contributions

Salut

Lumière de Lune wrote:

Je vais te donner un conseil : laisse tomber

parce que tu es sur un serveur mutualisé et que la plupart des questions de sécurité sont traitées par ton mutu, et que ces plugins soit disant de sécurité ne servent pas à grand chose, puisqu’ils n’identifient pas les failles dans le code de wordpress.

Déplacer le wp-config.php est une connerie, ça ne sert à rien, si un hacker a les moyens d’y accéder ou d’y écrire quelque chose c’est déjà trop tard…

Si je peux me permettre, je ne suis pas tout à fait d’accord la dessus, surtout où se situe ce config.php, et de ce qu’il contient.

Théoriquement, donc de base et sans protection particulière, tout fichier se trouvant dans le répertoire du vitualhost (le www en général) est accessible via une simple URL.
Tous ces fichiers sont alors potentiellement vulnérables.

Il faut donc obligatoirement rajouter des fichiers/codes pour protéger tout ça sinon il y aura un risque.

WP met normalement en place de la réécriture, qui normalement devrait éviter d’appeler via une simple URL ce fichier config.php car tout transit par le index.php.
Cependant, et pour peu qu’il y ait un jour un souci sur ce point, ne serait que temporairement, tout pourra devenir accessible via une URL.

L’idée de mettre un require dans ce config.php vers un fichier qui lui contiendra les config mais qui surtout ce trouvera en-dehors du virtualhost est à mon sens très loin d’être idiote.

Si on observe un peu comment font la plupart des projets types FrameWork, ils préconisent quasi tous de faire ainsi.
Certains même l’imposé, c’est à dire qu’il y ait qu’un seul et unique fichier dans le virtualhost, l’index.php, et tout le reste doit se trouver en dehors du virtualhost.

D’ailleurs, et si on réfléchi un peu, les seuls fichiers qui eux demandent à être accessibles via une URL sont ceux du genre : JS, CSS, images (jpg, png, gif, flash, mp3).
Mais tout le reste comme tous les fichiers Php n’ont normalement rien à faire dans le virtualhost.

A savoir qu’un projet comme DotClear permet de séparer tout ça, et même de séparer la partie admin.
Ceci dit, je découvre tout juste WordPress, pour le moment je ne vois pas s’il y a vraiment moyen d’en faire autant.

Pour conclure, déporter le contenu de ce config.php en dehors du virtualhost est à mon sens le minimum à faire, surtout qu’il contient le nom du serveur de Bdd, le username et le mot de passe, de quoi tout supprimer, suffit de pouvoir le lire qu’une seule fois.
Ceci peu non seulement retarder l’éventuel hacker, il peut même se casser les dents à vouloir y accéder, ne jamais y parvenir même.
Ceci sans tomber dans la paranoïa non plus.

1 juin 2011 à 18 h 37 min #774016

jeffrey-omega
Membre

Initié WordPress
23 contributions

RunWP wrote:

Salut

Lumière de Lune wrote:

Je vais te donner un conseil : laisse tomber

parce que tu es sur un serveur mutualisé et que la plupart des questions de sécurité sont traitées par ton mutu, et que ces plugins soit disant de sécurité ne servent pas à grand chose, puisqu’ils n’identifient pas les failles dans le code de wordpress.

Déplacer le wp-config.php est une connerie, ça ne sert à rien, si un hacker a les moyens d’y accéder ou d’y écrire quelque chose c’est déjà trop tard…

Si je peux me permettre, je ne suis pas tout à fait d’accord la dessus, surtout où se situe ce config.php, et de ce qu’il contient.

Théoriquement, donc de base et sans protection particulière, tout fichier se trouvant dans le répertoire du vitualhost (le www en général) est accessible via une simple URL.
Tous ces fichiers sont alors potentiellement vulnérables.

Il faut donc obligatoirement rajouter des fichiers/codes pour protéger tout ça sinon il y aura un risque.

WP met normalement en place de la réécriture, qui normalement devrait éviter d’appeler via une simple URL ce fichier config.php car tout transit par le index.php.
Cependant, et pour peu qu’il y ait un jour un souci sur ce point, ne serait que temporairement, tout pourra devenir accessible via une URL.

L’idée de mettre un require dans ce config.php vers un fichier qui lui contiendra les config mais qui surtout ce trouvera en-dehors du virtualhost est à mon sens très loin d’être idiote.

Si on observe un peu comment font la plupart des projets types FrameWork, ils préconisent quasi tous de faire ainsi.
Certains même l’imposé, c’est à dire qu’il y ait qu’un seul et unique fichier dans le virtualhost, l’index.php, et tout le reste doit se trouver en dehors du virtualhost.

D’ailleurs, et si on réfléchi un peu, les seuls fichiers qui eux demandent à être accessibles via une URL sont ceux du genre : JS, CSS, images (jpg, png, gif, flash, mp3).
Mais tout le reste comme tous les fichiers Php n’ont normalement rien à faire dans le virtualhost.

A savoir qu’un projet comme DotClear permet de séparer tout ça, et même de séparer la partie admin.
Ceci dit, je découvre tout juste WordPress, pour le moment je ne vois pas s’il y a vraiment moyen d’en faire autant.

Pour conclure, déporter le contenu de ce config.php en dehors du virtualhost est à mon sens le minimum à faire, surtout qu’il contient le nom du serveur de Bdd, le username et le mot de passe, de quoi tout supprimer, suffit de pouvoir le lire qu’une seule fois.
Ceci peu non seulement retarder l’éventuel hacker, il peut même se casser les dents à vouloir y accéder, ne jamais y parvenir même.
Ceci sans tomber dans la paranoïa non plus.

merci pour votre réponse 🙂 Alors sa veut dire que je dois faire ce qui est marqué dans le tuto que j’ai vu ?

1 juin 2011 à 19 h 01 min #774017

RunWP
Membre

Initié WordPress
18 contributions

Alors sa veut dire que je dois faire ce qui est marqué dans le tuto que j’ai vu ?

Je n’est pas vu de lien concernant ce tuto, mais si je me tiens au code que tu as mis, c’est ce qui est prévu.

De mon coté c’est aussi ce que je préconise, soit de ne pas laisser de fichiers sensibles comme ce config.php dans un virtualhost (ou www ), soit potentiellement accessible via une URL, mais de le déporter en dehors, qui là ne sera plus possible.

Pour le reste j’en sais rien, du moins il est trop tôt encore, je débute avec WP.

2 juin 2011 à 5 h 55 min #774018

Franck (fge)
Modérateur

Maître WordPress
9572 contributions

Le code PHP étant exécuté, lorsque vous accédez au fichier par une URL, vous avez un jolie page blanche… De plus, si dans le .htaccess vous interdisez l’accès à ce fichier, je ne vois pas bien comment il est possible de récupérer les infos qu’il contient… D’autant que les mots de passe peuvent être récupérés par des rootkits sur les PC ayant enregistré le mot de passe dans un navigateur par exemple.

2 juin 2011 à 6 h 35 min #774019

Lumiere de Lune
Participant

Maître WordPress
20531 contributions

Le contenu du fichier .php ne peut absolument pas s’afficher dans un browser internet, donc pour avoir accès à son contenu, même en en connaissant l’adresse, il faut avoir accès au transfert de fichier -> donc au ftp

Si c’est le cas, le hacker a donc déjà craqué un nombre de protections nettement plus importantes, et peut de toute façon voir où se trouve le fichier en question.

Par ailleurs, « déporter le fichier wp-config.php » en dehors d’une chemin accessible par une url a de nombreux risques sur le fonctionnement interne de wordpress, où des plugins peuvent faire benoitement appel à ce fichier wp-config.php et se retrouver coincés. (et n’est pas toujours possible sur un mutualisé)

Maintenant, et c’est le plus important, et la raison de mon conseil à jeffrey-omega, on modifie les paramètres de bases d’une appli, comme déplacer le fichier wp-config, quand on sait ce qu’on fait, et qu’on comprend comment le système fonctionne. Or les questions qu’il posent prouvent que ce n’est pas le cas.

Est ce que son blog est suffisamment stratégique pour attirer des hackers pointus ? Ou simplement des gens qui cherchent à exploiter automatiquement les failles de WP ? Etre à jour des versions, avoir un mot de passe correct, et ne pas cliquer sur n’importe quelle url dans les mails sont les trois consignes de sécurité les plus essentielles.

(PS : et de toute façon, le chemin vers ton config.php doit être quelque part en clair dans ton index.php)

2 juin 2011 à 9 h 02 min #774020

RunWP
Membre

Initié WordPress
18 contributions

En intervenant ainsi, je savais d’avance que cela ferait réagir.

Qu’on aime bien WP car on l’utilise depuis longtemps, qu’on se passionne même, rien de plus normal.
Cependant, faut tout de même rester objectif.

Si on sillonne les sites (forum, blog, etc …) digne de ce nom sur Php et Apache, il est dit (extrêmement souvent même) que tout fichier confidentiel ne doit pas se trouver dans un virtualhost.
Ceci est incontestable, ça fait partie du BABA des règles de base de la sécurité dans ce domaine.

Que WordPress ne l’ai pas respectée, je n’y peux rien.

Donc ce que préconise ce tuto est encore une fois loin d’être une bêtise, et tenter de dire ou de prouver que cela est inutile pour X ou Y raison est totalement absurde.
Il n’y rien de plus normal à mon sens de trouver ce genre de tuto, car c’est WP qui ne respecte pas cette règle de base.
Que certains tentent de l’améliorer là aussi rien de plus normal.

La vrai question est : est ce que tout le monde peut l’appliquer ?
Je partage donc totalement le fait qu’il faut savoir ce qu’on fait, c’est à dire que si on déplace un fichier (ou une partie du code peu importe) tel le config.php qui fait partie du core de WP, il faudra mesurer son impact (lors des mise à jour par exemple).
Si on ne se sent pas de le faire, alors il serait plus raisonnable de laisser les choses telles WP l’a prévu.
Sinon on le fait.

Lumière de Lune wrote:

Le contenu du fichier .php ne peut absolument pas s’afficher dans un browser internet, donc pour avoir accès à son contenu, même en en connaissant l’adresse, il faut avoir accès au transfert de fichier -> donc au ftp

(PS : et de toute façon, le chemin vers ton config.php doit être quelque part en clair dans ton index.php)

Oui, ceci est valable pour un internaute qui s’improviserait pirate/hacker du jour au lendemain, mais pour les autres ???

Le but recherché en déplaçant ce fichier (ou contenu en partie), n’est pas de camouflé le chemin, le but est de faire en sorte qu’il ne puisse pas être atteint, donc même être lu.
Ce n’est pas grand chose, les pirates les plus aguerries arriveront surement à l’atteindre ou a obtenir sont contenu, mais ça reste néanmoins une règle de base.

2 juin 2011 à 12 h 03 min #774021

wasicu
Membre

Maître WordPress
2752 contributions

Le débat m’intéresse alors je le suis. Juste une petite précision pour Jeffrey : Perso, je trouve que c’est pas malin de provoquer les hackers qui aiment justement ce genre de défis, en annonçant haut et fort quels sont les plugins utilisés pour sécuriser ton blog. (Dans le footer) Mais bon c’est perso.

2 juin 2011 à 12 h 59 min #774022

Lumiere de Lune
Participant

Maître WordPress
20531 contributions

RunWP wrote:

Si on sillonne les sites (forum, blog, etc …) digne de ce nom sur Php et Apache, il est dit (extrêmement souvent même) que tout fichier confidentiel ne doit pas se trouver dans un virtualhost.
Ceci est incontestable, ça fait partie du BABA des règles de base de la sécurité dans ce domaine.

Peux tu m’indiquer « facilement » où se trouve mon virtual host non accessible par une url de mon site sur des hébergements mutualisés comme free, ovh, 1&1 ?

RunWP wrote:

Que WordPress ne l’ai pas respectée, je n’y peux rien.

Comme tous les autres CMS qui ont vocation à pouvoir être installés sur un mutualisé (Drupal, Prestashop, entre autre)

RunWP wrote:

Donc ce que préconise ce tuto est encore une fois loin d’être une bêtise, et tenter de dire ou de prouver que cela est inutile pour X ou Y raison est totalement absurde.
Il n’y rien de plus normal à mon sens de trouver ce genre de tuto, car c’est WP qui ne respecte pas cette règle de base.

Merci pour l’absurdité.
Tu auras au moins l’obligeance de reconnaître que je n’ai pas émis un avis dans l’absolu mais dans un cas particulier.

Ma position est tout simplement « on touche à ce genre de choses quand on sait ce qu’on fait ». Vu le nombre de fois où on met deux pages sur ce forum à expliquer aux gens que leur .htaccess chez 1&1 est celui qui se trouve à la racine du site et pas celui dans les fichiers logs, et vu l’impact que ce genre de modifs peut avoir quand elle mal maitrisée, tu m’excuseras de rester sur ma position absurde.
Que certains tentent de l’améliorer là aussi rien de plus normal.

RunWP wrote:

Le but recherché en déplaçant ce fichier (ou contenu en partie), n’est pas de camouflé le chemin, le but est de faire en sorte qu’il ne puisse pas être atteint, donc même être lu.

Et ? Toutes les informations du wp-config peuvent être facilement hackées, à partir du moment où on a accès à l’admin de WordPress, même de façon indirecte. Toutes les informations peuvent être décryptées via une simple suite d’instructions php faisant appel aux constantes WordPress. Tu peux même avoir accès en direct à la base de données, via l’admin de WP

Des plugins comme timthumb ou autres, qui fonctionnent en obligeant à configurer certains répertoires sont extrêmement dangereux.

2 juin 2011 à 19 h 53 min #774023

RunWP
Membre

Initié WordPress
18 contributions

Ca raisonne comme un air de polémique tout ça.
Bien dommage. 😉

De mon coté je ne fais que dire une généralité, c’est à dire que mettre des fichiers confidentiels dans le www (ou virtualhost, qui est défini dans Apache, plus exactement dans le httpd.conf par défaut) c’est par définition un manque de sécurité.
Nier cette évidence est, là encore désolé, une absurdité, ou alors une méconnaissance, car ça fait parti du BABA.
J’y peux rien, c’est ainsi.

Après ça, qu’un hébergeur ou encore qu’un WordPress ne le permettre, ceci n’a rien avoir, c’est un autre problème, donc limite hors sujet.

Au même titre que celui qui s’aventure à modifier le Core de son projet, il faut qu’il sache ce qu’il fait, ça coule de source.
Donc 2 choses une : Soit il pense pouvoir retomber sur ces pieds, même en cas de bug lié à cette modif, soit il pense qu’il ne pourra pas.

Ceci sera mon mot de fin, je ne souhaite pas débattre plus longtemps, les informations sont suffisamment abondantes sur le Net sur ce point.

Lumière de Lune wrote:

Peux tu m’indiquer « facilement » où se trouve mon virtual host non accessible par une url de mon site sur des hébergements mutualisés comme free, ovh, 1&1 ?

T’as question est mal posée, c’est à se demander si tu sait ce que représente un Virtualhost.
C’est pourtant simple, car c’est en général le www.

Je l’ai suffisamment répété : Tout ce qui ce trouve dans le virtualhost est par définition publique, donc tout fichier peut être potentiellement atteint via HTTP (ou URL, navigateur ou autre).
Du coup, et à l’inverse, tout ce qui ce trouve en-dehors ne le sera pas.
Suffit donc de pouvoir créer par exemple un autre répertoire au même niveau que le www, comme monRepPerso, et y mettre le config.php dedans.
Le répertoire monRepPerso étant en-dehors, il est naturellement inconnu du serveur Web (Apache), sauf pour Php et du système de fichier.

Cependant, ce n’est pas pour autant l’arme absolue, j’insiste, c’est juste une sécurité de base.

Ceci sera mon mot de fin, je ne souhaite pas débattre plus longtemps, les informations sont suffisamment abondantes sur le Net sur ce point.

Bonne soirée. 🙂

2 juin 2011 à 20 h 25 min #774024

Lumiere de Lune
Participant

Maître WordPress
20531 contributions

C’est toi qui ne veut pas entendre.
Je sais ce que c’est qu’un serveur dédié, j’ai même deux machines virtuelles sur lesquels j’ai des serveurs locaux, mais je sais aussi ce que c’est qu’un mutualisé
Toi par contre, tu ne sembles pas exactement savoir certaines choses.

Comme par exemple le fait que sur beaucoup de serveurs mutualisés, le nom de domaine est lié au virtual host, quelle que soit son nom, et donc qu’on n’a accès à RIEN en dehors du virtualhost en question. Donc ton « ce qui se trouve en dehors » n’est nulle part.

« suffitque » ben oui mais chez de nombreux hébergeurs, « suffitque » n’existe purement et simplement pas comme possibilité. Peut être n’en a tu jamais fait l’expérience, ou peut être est ce que à l’époque tu n’y faisais pas attention.

« suffitque » certes mais uniquement si tu as accès à des hébergements dont le prix est supérieur à ce que de très nombreuses personnes qui bloguent pour leur plaisir refuseraient de payer. Et encore une fois, la stratégie de WordPress est d’être disponible partout.

Et puisque tu dis que les informations sont si abondantes, sois gentil, prouve le et réponds à ma question : comment puis stocker un wp-config « en dehors » sur free.fr ou sur un mutualisé 1&1 ?
Auteur

Messages