Dossier WordPress – Sécuriser davantage WordPress avec le fichier .htaccess

Cet article a 3 années. Il commence à dater, lisez-le donc en gardant son âge en tête ! Merci

Dossier Sécurité WordPress - Partie 4/4 Le fichier .htaccess permet de communiquer avec la machine qui héberge votre site internet.
Le fichier dont je ferai référence dans cet article doit être placé à la racine de votre blog, c’est à dire au même niveau que votre fichier wp-config.php.
Dans certains cas, il est possible de placer un fichier .htaccess dans un dossier pour limiter l’impact sur les fichiers. Les instructions du fichier .htaccess placé dans un dossier prend le dessus sur le fichier .htaccess parent, si les instructions rentrent en conflit.

N’oubliez pas de faire une sauvegarde systématique de votre fichier .htaccess avant toute intervention. Vous pourrez facilement replacer en ligne votre sauvegarde si jamais le nouveau fichier est mal écrit.

Empêcher la navigation dans les dossiers

Certains hébergeurs ne bloquent pas la possibilité de naviguer directement dans les dossiers d’un site. (désolé pour la personne qui reconnaitra le dossier Galerie de son site ;) )
Ainsi, en tapant http://mon_super_site.net/wp-includes/ il est parfois possible de naviguer dans les fichiers de ce dossier, puis dans les sous-dossiers.
Pour bloquer cette possibilité il suffit de rentrer cette ligne de code dans votre fichier .htaccess :

Options -Indexes

Attention, ce code n’empêche pas le contenu d’un dossier d’être indexé, il faudra renseigner le fichier robots.txt pour cela.

Modifier le « register globals »

Ce paramètre existe depuis PHP4 et permet de sécuriser les variables globales.
Il est important de régler le register_globals à off.
Il est possible de régler ceci grâce au fichier .htaccess, avec la ligne suivante :

php_flag register_globals off

Si vous êtes chez OVH ce sera plutôt :

SetEnv REGISTER_GLOBALS 0

Attention, chez OVH ce paramètre est par défaut réglé à on !

Merci à Julio pour l’info sécu !

Bannir des adresses IP

Il peut arriver qu’une personne qui ne vous aime pas (si si ça arrive), ou qu’un robot se mette à poster non-stop sur votre blog, 10, 20 commentaires indésirables par jour.
Les robots et les personnes indésirables peuvent être bannis grâce à leur adresse IP. WordPress vous la donne lorsque la personne poste un commentaire sur votre blog, mais elle peut aussi apparaître dans les mails de contact grâce à certains plugins proposant des formulaires de contact.
En ajoutant ce code à votre fichier .htaccess, vous bannirez les personnes visitant votre site avec l »adresse IP 123.456.789 et l’adresse IP 987.654.321.

order allow,deny
allow from all
deny from 123.456.789
deny from 987.654.321

Pour bannir davantage d’IP, il suffit de dupliquer la dernière ligne autant de fois que nécessaire en renseignant l’IP à bannir.

Autoriser votre seule adresse IP dans le dossier wp-admin

Cette technique n’a d’intérêt que si le nombre d’intervenant est limité et connu, et surtout si vous éditez votre site depuis le même ordinateur.
De même, il vous faudra une IP fixe, ou alors vous serez obligé d’autoriser une plage d’IP.

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Wordpress Admin Access Control"
AuthType Basic

order deny,allow
deny from all
allow from 123.456.789

Si vous souhaitez rajouter des autorisations pour d’autres IP, dupliquez simplement la dernière ligne en renseignant la bonne adresse.
Le fichier .htaccess doit être placé dans le dossier /wp-admin de votre installation.

Interdire l’accès aux fichiers importants

Interdire l’accès à wp-config.php qui est le fichier qui liste certaines informations sur l’installation de WordPress, notamment les identifiants de connexion à votre base de données, ainsi que le préfixe des tables.
Pour éviter qu’il puisse être atteint directement, interdisez simplement son affichage :

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

Une autre solution consiste à placer wp-config.php à l’extérieur du dossier www de votre espace web. En effet, WordPress arrive à le retrouver même à l’extérieur de www.

De la même manière il est possible d’interdire l’accès au fichier readme.html ou au fichier .htaccess lui-même.

# protect readme.html
<files readme.html>
order allow,deny
deny from all
</files>
# protect .htaccess
<files .htaccess>
order allow,deny
deny from all
</files>

Article original (en)

Limiter l’appel au script de commentaires

Cette technique permet de vérifier d’où est appelé le script qui envoie les commentaires en base de données.
Il a l’avantage de limiter une partie du spam.
Si le referer existe, et s’il s’agit de votre blog, alors le commentaire est posté. Autrement il ne l’est pas et l’utilisateur du script est redirigé.

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !.*yourblog.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://yourblog.com [R=301,L]

N’oubliez pas de remplacer yourblog.com par l’URL exacte de votre blog.
Article original (en)

5G Blacklist 2012

Développée par Perishable Press, ce code vous permet de vous protéger contre pas mal de choses.
Tout est expliqué sur le site (en anglais, mais Google peut traduire si ce n’est pas votre fort), je vous laisser donc découvrir 5G Blacklist 2012.

Bonux : Bloquer l’indexation de contenus sensibles

Rien à voir avec le fichier .htaccess, il s’agit ici du fichier robots.txt utilisé par les moteurs de recherche.
Il est possible d’empêcher l’indexation des fichiers du système WordPress par les moteurs de recherche en renseignant ceci dans votre fichier robots.txt qui se trouve à la racine de votre site :

User-Agent: *
Disallow: /wp-*

Et bien d’autres techniques

Il existe de nombreuses autres techniques dont certaines sont détaillées sur cette page :
AskApache mod_rewrite security
Merci à Mr Xhark pour son partage dans un de ses commentaires.

Un récent article de BoiteAWeb a été publié concernant la sécurité de WordPress et ses éventuelles faiblesses.
Je vous invite à le lire, c’est une réflexion à laquelle vous pouvez participer.

Le mot de la fin

Nous avons fait le tour de ce dossier.
Si vous avez manquez quelque chose, le sommaire ci-dessous vous y mènera.
Ce dossier n’a pas la prétention d’être exhaustif, aussi, si vous avez des plugins, hooks ou astuces à partager, n’hésitez pas à commenter ce dossier. Votre contribution sera ajoutée au dossier et un lien vers votre site sera fait pour vous en remercier.
De même, si vous croisez des erreurs faites m’en part.

À bientôt ;)

38 commentaires et un trackback sur “Dossier WordPress – Sécuriser davantage WordPress avec le fichier .htaccess”

  1. Nicolas dit :
    16 février 2012

    Super dossier proche de l’exhaustivité. Bien pratique dans mon cas vu que je suis justement en train de finaliser mon blog, merci ! ^^

  2. BoiteAWeb dit :
    19 février 2012

    J’ajouterais qu’il est impératif de mettre le « register_globals » à « off ».
    Ceci est à faire dans le php.ini mais via .htaccess vous pouvez aussi le faire :
    « php_flag register_globals off »
    Si vous êtes chez OVH ce sera :
    « SetEnv REGISTER_GLOBALS 0″

    Attention, chez OVH ce paramètre est à « on » par défaut !!!

    En tout cas, très bon dossier, il en existe des 100aines mais dans celui là je sens que tout a été test » en vrai et pas juste pompé à droite à gauche.
    Merci pour le temps passé à faire les tests et tous ces articles précieux.

  3. Geoffrey dit :
    20 février 2012

    Merci pour cette précision !

    En fait j’utilisais déjà cette ligne sur mon htaccess sans savoir exactement à quoi ça correspondait.
    Une fois (il y a de ça 2 ans) j’ai eu une variable phpsessid qui s’est affichée dans mon URL en passant sur un fichier .php de mon site. Cela me semblait bizarre et OVH conseillait ce paramétrage.

    Je ne pensais pas que c’était problématique niveau sécu.
    Je rajoute !

    J’ai essayé de tout tester, tout en me documentant sur d’autres ressources pour tenter de transmettre le moins d’erreur possible.
    Merci d’avoir gardé un œil sur le contenu du dossier, ça me rassure :)

  4. BoiteAWeb dit :
    20 février 2012

    Je suis en train de faire un article sur ça, RDV fin de semaine.

  5. Geoffrey dit :
    20 février 2012

    Tu nous tiens au Juiz ;)

  6. Geoffrey dit :
    3 mars 2012

    L’article de BoiteAWeb a été ajouté à ce dernier article du dossier sécurité.
    Vous le trouverez ici : Que manque t-il à WordPress au niveau sécurité ?
    Bonne lecture.

  7. cyril dit :
    16 mars 2012

    Salut et merci pour ces infos!!

    J’ai juste une demande par rapport :

    Empêcher la navigations dans les dossiers :

    Options -Indexes

    J’ai placé ceci à la fin de mon fichier .htaccess

    mais les dossiers sont toujours visible…

    Une idée?

    Merci

    • Geoffrey dit :
      16 mars 2012

      Bonjour,
      Pas d’idée à première vue.
      Sur quelle machine es-tu hébergé, ou de quelle offre d’hébergement bénéficies-tu ?
      Merci ;)

  8. BoiteAWeb dit :
    16 mars 2012

    « Les dossiers sont visibles »
    Voulais-tu dire « lecontenu des dossiers est encore visible » ?
    Car les dossiers seront tout de mêê accessible mais seront en errur 403

  9. alex dit :
    7 avril 2012

    Hello,

    merci pour ce beau dossier très complet.
    Je n’y connais pas grand chose :) petite question pour le premier truc ou je dois mettre « Options -Indexes  » dans le fichier htacess…je met ca ou? n’importe où ? y’a pas un endroit spécifique? entre certaine balise??

  10. Geoffrey dit :
    7 avril 2012

    N’importe où oui, ou presque.
    Chaque ligne d’un fichier .htaccess représente une instruction (ou une condition dans certains cas)

    Il est cependant possible de définir une condition d’appartenance à un dossier :
    <Directory /web/docs>
    Options - Indexes
    </Directory>

    Ce morceau de code signifie que dans le dossier /bew/docs/ l’option d’indexation des fichiers en l’absence de DirectoryIndex est interdite (d’où la présence du « – » devant « Indexes ».

    Pour répondre à ta question, tu peux très bien le mettre tout à le fin de ton document.
    Tu peux également commenter le document ainsi :
    # Ceci est un commentaire
    Options - Indexes
    # Ceci est un commentaire... aussi

    La doc si tu aimes lire : http://httpd.apache.org/docs/trunk/fr/mod/core.html#options

    Je n’y connais pas grand chose non plus, je découvre au fur et à mesure des besoins :)
    Bonne continuation.

  11. alex dit :
    7 avril 2012

    Je pourrais re-faire un copier coller de mon message :) tant l’utilité de l’article est importante.

    Donc ca marche parfaitement !
    Un grand grand merci à toi pour ta réponse rapide :) et toutes ces belles astuces. je pense que mon blog devrait être plus sécurisé maintenant. encore merci

  12. 8 avril 2012

    « Mieux vaut tout savoir chercher, que chercher à tout savoir » – Albert E. ;)

  13. alex dit :
    16 avril 2012

    Au passage, j’avais eu un pb sur mon site depuis quelques jours (semaines), un petit malin avait tout simplement ajouté un … de code dans mon fichier comment de wp-includes…

    la classe à dallas donc :(

    au passage j’ai désactiver l’éditeur de plugin et de thème. Je n’ai pas trouvé cet astuce sur votre site ?

  14. Geoffrey dit :
    16 avril 2012

    Hello,
    Mince, il faudrait que tu installes http://wordpress.org/extend/plugins/exploit-scanner pour vérifier si d’autres fichiers du cœur n’ont pas été touchés, et au quel cas les remplacer par ceux d’origine.

    C’est une bonne idée de désactiver les éditeurs, mais je ne sais pas si ça rentre dans le cadre « sécurité »… peut-être plutôt prévention de mauvaise manip. Je l’ajoute dans la partie « hook ». Merci.

    Bonne soirée.

  15. 18 avril 2012

    100% sécurité. Imaginons qu’un compte admin se fasse voler, le pirate ne peut pas toucher aux fichiers PHP !
    Pour exploit-scanner ce ne sera pas suffisant bien sûr, j’ai déjà vu une backdoor dans wp-config.php, ficher non scanné par le plugin pour des raisons évidementes !

    • Geoffrey dit :
      18 avril 2012

      Effectivement, m’enfin là il faut sécuriser en amont, parce qu’il n’y a pas que les fichiers qui peuvent être touchés :p
      Mais j’ai imaginé ce scénario (au moins limiter les dégâts), d’où l’ajout du bout de code dans le dossier.
      Merci Julio :)

  16. 18 avril 2012

    « il n’y a pas que les fichiers qui peuvent être touchés »
    Quoi d’autre, qu’ai je raté/oublié ?

    • Geoffrey dit :
      18 avril 2012

      Je voulais dire qu’une personne qui arrive à obtenir des accès à un compte admin a déjà dû forcer une autre porte mettant en danger bien d’autres données. (ce ne sont que des suppositions)
      Ensuite une personne qui a accès à cette interface d’édition (WP) peut également pourrir la base de données. (oui je sais, ça reste des fichiers en un sens)

  17. 18 avril 2012

    Obtenir un accès admin, euh j’ai deviné le pass de l’admin, je n’ai enfoncé aucune porte.
    L’installation de plugin peut effectivement poser probleme, il vaut mieux donc forcer l’install des plugins via FTP, un bon chmod sur /plugins/ est suffisant il me semble.
    Maintenant, ajouter des articles ouè super, mais là, j’ai pas root le site victime :p
    Le but ultime étant de root le serveur ;)

  18. 1 juillet 2012

    Bonsoir,

    Sur le net j’ai put voir qu’on pouvait ajouter ces lignes dans le htaccess :

    SetEnv REGISTER_GLOBALS 0 (comme l’à précisé Boiteweb)
    SetEnv ZEND_OPTIMIZER 1
    SetEnv MAGIC_QUOTES 0

    Est ce que ces 2 lignes supplémentaires serviront à optimiser le blog ou juste la ligne : « SetEnv REGISTER_GLOBALS 0″ sera utile ?
    Ce code peut être mit n’importe ou dans le htaccess ? Car sur un site il parle de le mettre entre # BEGIN et # END.

    Merci pour vos renseignements
    Bonne soirée

  19. 1 juillet 2012

    SetEnv REGISTER_GLOBALS 0
    N’optimise rien, c’est que de la sécurité.

  20. Geoffrey dit :
    1 juillet 2012

    Bonsoir,

    Zend optimizer est un environnement d’exécution que je ne connais qu’à travers la mise en cache de fichier, pas au niveau sécurité. Mais son activation ne fait pas de mal.

    Le second sert à désactiver les magic quotes qui, par ailleurs, ne sont pas toujours activées par défaut. Pour savoir s’il faut les désactiver ou non, je t’invite à lire ce petit article :
    Magic Quotes – SDZ

    Dans tous les cas ces instructions peuvent être placées en tout début de fichier ou en fin, l’idéal étant de ne pas mélanger ces lignes avec celles renseignées par défaut par WordPress.
    Bonne soirée.

  21. 1 juillet 2012

    Bonsoir,

    Oui je sais que SetEnv REGISTER_GLOBALS 0 n’optimise en rien, je parlais pour les 2 autres lignes (je me suis peut être mal exprimé).

    Merci pour les infos,je vais regarder le lien que tu m’a envoyé.
    Sinon j’ai mit ce bout de code au début du htaccess avec cette ligne :

    SetEnv PHP_VER 5_4
    SetEnv REGISTER_GLOBALS 0

    Comme ça, ça ne devrait pas se mélanger avec les autres codes.

    Bonne soirée

  22. Joao dit :
    16 novembre 2012

    Bonjour,
    Actuellement je suis victime de spam au niveau des commentaires, j’ai don suivi vos instructions, j’ai placé ceci sur le htaccess :

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
    RewriteCond %{HTTP_REFERER} !^$
    RewriteCond %{HTTP_REFERER} !.*receitas.pasteldenata.info.* [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule (.*) http://receitas.pasteldenata.info [R=301,L]

    Est-ce correct?
    Merci d’avance.

    • Geoffrey dit :
      16 novembre 2012

      Bonjour,

      Oui cela me semble correct :)
      J’utilise ce code, mais ça ne supprime pas tout le spam.
      Ces derniers temps il s’est aussi multiplié sur ce blog…

  23. Joao dit :
    16 novembre 2012

    J’ai vu aussi sur un autre site ceci :
    # Pour se protéger contre des commentaires de Spam

    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]

    Qu’en pensez-vous?

  24. Geoffrey dit :
    17 novembre 2012

    Bonsoir,
    C’est le même code sauf que le « mien » prend en compte la navigation privée de l’utilisateur. (Du plus en plus fréquente, notamment pour les utilisateur de Chrome)

  25. 28 juin 2013

    Bonjour, je sais que le post est assez vieux, mais je ne trouve pas ma réponse ailleur alors j’essaye , j’ai un wp qui est en construction et j’aimerais bloquer l’acces de toutes mes pages aux internautes mais j’aimerais y avoir acces, y’a t il un moyen de le faire via l’htacces ?

    Merci.

    • Geoffrey dit :
      29 juin 2013

      Hello,
      Tu peux essayer ceci :
      Order Allow, Deny
      Deny from all
      Allow from 123.456.789.123

      En remplaçant l’adresse IP par la tienne :)

  26. 3 octobre 2013

    Hello,

    Je l’ai déjà dit, mais super article.

    De mon coté j’ai été victime ce matin d’un drole de phénomene. Deux fichier .html se sont retrouvé sur mon wordpress dans le dossier wp-admin…

    Le fichier.htacess qui était dans mon wp-admin s’est retrouvé sans toute la partie de ma version de php et 5G Blacklist…

    Du coup quand on allait sur mon site :
    Votre serveur utilise la version 4.4.9 de PHP mais WordPress 3.6.1 nécessite au moins la version 5.2.4.

    Etrange…

    Bon d’un autre coté et heuresement j’avais un fichier htacess sur mon pc.

    Du coup, je vire les fichiers, je remet mon htacess mais pas dans mon dossier wp-admin. Pourquoi ?

    Tout simplement car quand je le met dans le dossier wp-admin je me retrouve avec le mête message d’erreur…du coup il est bien présent mais dans mon dossier www

    Une idée de :

    Comment faire pour le remettre dans wp-admin

    Comment être sur que ce vilain monsieur (ou madame) n’a pas chargé d’autre merde

    Merci

    • Geoffrey dit :
      4 octobre 2013

      Hello,
      Je n’ai pas bien compris le problème lié au htaccess. Mais ce que je te conseille c’est de re-télécharger WordPress, supprimer tous les fichiers sauf ceux de wp-content/ et remettre en place les fichiers originaux de WP.
      Ensuite tu replaces ton htaccess à la racine pour avoir la bonne version de PHP et les règles de réécriture de WordPress, et plus si affinité avec Apache :p
      S’il y a faille de sécurité ça doit venir d’un des plugins installés, essaye de faire des recherches sur le net pour voir si tu trouves des informations, ou consulte un expert en sécurité si tu en sens le besoin.
      Avec une base propre des fichiers WP ça devrait déjà être bien :)

  27. 3 octobre 2013

    J’ajoute que j’ai une erreur 403 dans je veux activer un plugin :/

  28. 4 octobre 2013

    Désolé si je n’ai pas été très clair…

    Pour faire simple, j’ai regardé mes Log à la recherche d’une connexion étrange….

    Je n’ai vu ça que sur mes log FTP. Je ne comprends pas comment il a fait pour y rentrer. J’ai depuis changé mon mdp.

    Voici ce qui s’est passé :
    « <« [DEBUG] Command [dele] [.htaccess]
    [NOTICE] Deleted /homez.346/cineasie//www/.htaccess
    « > »
    [DEBUG] Command [pasv] []
    [DEBUG] Command [stor] [rImnDd.html]
    [NOTICE] /homez.346/cineasie//www/rImnDd.html uploaded (372 bytes, 2.54KB/sec)
    [DEBUG] Command [pasv] []
    [DEBUG] Command [stor] [aImnDd.html]
    [NOTICE] /homez.346/cineasie//www/aImnDd.html uploaded (400 bytes, 2.49KB/sec)
    [DEBUG] Command [quit] []
    [INFO] Logout.
    « > »

    Il y’a donc eu la suppression de mon fichier .htacess
    puis l’ajout de deux beaux fichiers .html qui bien sur n’était pas là pour faire du bien.

    J’ai depuis supprimer ces fichier. Rajouter un .htacess

    Mais en effet, le plus sage semble de tout refaire au propre…

    Ce genre d’intrusion peut-elle se faire via un plugin ?

  29. Hicham dit :
    1 décembre 2013

    Merci pour ces infos très utiles. Tu m’enlèves une épine du pied : sur de nombreux blogs, j’ai trouvé l’instruction
    « <« Options All -Indexes »> » qui ne fonctionnait pas, provoquant un internal server error, et en fait il suffisait de mettre « <« Options -Indexes »> » sans le all pour que ça fonctionne.
    Merci encore.

  30. Tony dit :
    2 décembre 2013

    Excellent article, je suis bluffé par l’ingéniosité de certaines astuces.
    La petite astuce que j’aime bien en ce qui me concerne, c’est celle qui consiste à mettre des faux dossiers « admin » dans le robots.txt. Ensuite, il suffit de consulter les logs pour savoir les adresses IP qui tentent d’accéder à ces faux dossier admin. Ca donne une liste d’IP mal intentionnées qu’il suffit de blacklister.

  31. 31 mars 2014

    Bonjour
    je vous recommande d installer l extension Wp better security il permet de sécurisé facilement votre site WordPress,de masquer l accès a la page login et de renommer votre wp-admin (entre autre)

Laisser un commentaire

Certains codes HTML ne sont pas échappés automatiquement. Pour afficher du code dans votre commentaire, merci d'échapper vos chevrons en utilisant "&lt;" et "&gt;" en lieu et place de "<"" et ">".

Il est difficile de proposer un support pour tous les articles de ce blog. En ne fournissant pas un moyen de consulter votre code bogué, vous vous assurez de ne pas avoir de réponse adaptée. Utilisez CodePen.io à défaut d'une page web.

Les sites qui en parlent

 
Le studio web