Vous pouvez lire ci-dessous les différentes recommandations concernant la sécurité du site Joomla :


SOMMAIRE :                1  - Comprendre et parler aux robots
                                       2  - Gestion fichiers Joomla
                                       3  - Consignes sécurité du site

 

 


1 - Comprendre et parler aux robots
Btn retour

Définitions

Avant de commencer à apprendre à discuter avec les robots, il est important de comprendre la différence qui existe entre l'exploration et l'indexation.
Explorer (crawling, en anglais) est le processus automatique qui suit simplement un lien et récupère le contenu d'un site web.
Indexer (indexing, en anglais) est le processus qui répertorie et donne un sens aux pages d'un site qui ont été explorées.

Le fichier robots.txt
C'est grâce au fichier robots.txt que vous pouvez contrôler quelle(s) partie(s) de votre site les robots peuvent suivre. Ce fichier est stocké dans le répertoire racine de votre site Joomla!
Voici à quoi ressemble son contenu :

User-agent: *
Disallow: /administrator/ Disallow: /cache/ Disallow: /components/ Disallow: /images/
Disallow: /includes/ Disallow: /installation/ Disallow: /language/ Disallow: /libraries/
Disallow: /media/ Disallow: /modules/ Disallow: /plugins/ Disallow: /templates/
Disallow: /tmp/ Disallow: /xmlrpc/

Par défaut, cette syntaxe empêche les moteurs de recherche d'indexer le répertoire contenant les images de votre site. Si vous souhaitez que votre site soit également présent dans la recherche de "Google Image", vous devez autoriser l'accès au dossier images (c'est à dire, là où Joomla stocke les images de votre site).
Pour ce faire, vous allez remplacer la ligne :
Disallow: /images/ par : Allow: /images/
Il est fortement conseillé de nommer vos images contenues dans ce dossier avec des titres descriptifs.
Encore une fois, cela indique simplement aux robots quels liens doivent être suivis ou non. Pour qu'une page ne soit plus indéxée, vous devez appliquer une directive "noindex". Cela peut être facilement mis en oeuvre depuis la page de l'article dans l'onglet "Publication" :

Explications :
Index : indique aux robots indexeurs d'indéxer cette page,
Noindex : indique aux robots indexeurs que cette page ne doit pas être indexée,
Follow : indique aux robots que les liens sur la page doivent être suivis,
Nofollow : indique aux robots que les liens de la page ne doivent pas être suivis.

Le fichier index.php
Google traite également le fichier index.php séparément de votre page d'accueil, ce qui signifie qu'une page test.fr et la page test.fr/index.php pourraient être considérées comme étant du contenu dupliqué (même si elles sont la même chose). Si vous avez activé la réécriture des URL (SEF) dans les paramètres SEO de la configuration globale de Joomla, vous pouvez remédier à cela en interdisant l'indexation d'une page s'appellant index.php. Pour ce faire, insérez la ligne suivante dans votre fichier robots.txt : Disallow: /index.php

À destination des utilisateurs de Joomla! débutants, ce petit didacticiel sur le paramétrage du fichier robots.txt pour rendre visible votre site par les robots d'indexation.
https://www.fred-net.fr/blog/joomla/...fichier-robots

A titre d'info pour les débutants, vous pouvez également tester et détecter les erreurs de votre fichier robots.txt via GSC (Google Search Console) : https://www.google.com/webmasters/tools/home?hl=fr

 

 


2 - Gestion des fichiers Joomla

Dossier racine de Joomla!®Btn retour
Légitime
: configuration.php, index.php et robots.txt
(Sous Joomla 1.5, vous aviez aussi index2.php et index3.php)
Particulier : htaccess.txt que vous pouvez renommer en .htaccess si vous activez la réécriture des URLs.
Peuvent être supprimé car inutiles: CONTRIBUTING.md, htaccess.txt, LICENSE.txt, joomla.xml, README.txt, robots.txt.dist, web.config.txt peuvent être supprimés sans problème.
Danger – Fichiers php  Si vous avez d’autres fichiers php, éditez-les et regardez leur contenu.
A priori, ces fichiers ne devraient pas se trouver là. Ils sont donc suspects=>
- à éditer afin d’en évaluer le caractère dangereux.
- à analyser si vous avez un fichier htaccess ou php.ini, jetez-y un coup d’œil. Vous pourriez avoir quantité d’autres fichiers comme les fichiers de propriétés Google, Bing, ..., à analyser au cas par cas.

Dossier administrator de Joomla!
Légitime: uniquement  index.php et seulement ce fichier.
Particulier : .htaccesset .htpasswd pourraient être présents si vous avez protégé votre administration (à éditer pour analyse).
Danger –Fichiers php  Si vous avez d’autres fichiers php, éditez-les et regardez leur contenu. À priori, ces fichiers ne devraient pas se trouver là. Ils sont donc très fortement suspects.

Dossier cache de Joomla!®
Légitime : uniquement index.html
Particulier : .htaccess pourrait être présent si vous avez protégé ce dossier (à éditer toutefois pour analyse)
Les autres fichiers, tous les autres fichiers, peuvent être supprimés sans autre forme de procès. À priori aucun fichier php ne devrait s’y trouver. Si c’est le cas, probabilité d’un virus

Dossier components de Joomla!®
Légitime: uniquement index.html
Particulier : .htaccess pourrait être présent si vous avez protégé ce dossier (à éditer pour analyse)
Danger –Fichiers php   Aucun autre fichier n’est attendu dans ce dossier et certainement pas des scripts .ph

Dossier images de Joomla!®
Légitime
: uniquement index.html
Particulier: .htaccess pourrait être présent si vous avez protégé ce dossier (à éditer pour analyse)
À priori, peuvent être supprimés car inutile : les dossiers banners, headers et sample data et les images joomla_black.png et powered_by.png.
Danger –Fichiers php  Aucun fichier.php n’est attendu dans le dossier /images et sous-dossiers. La probabilité de trouver des virus dans/images (et sous-dossiers) est très forte si le site a été hacké.1430/04/2016

Dossier language de Joomla!®
Légitime: uniquement index.html  Particulier: .htaccess pourrait être présent si vous avez protégé ce dossier (à éditer pour analyse)
Remarque : il y a un fichier.php dans chaque dossier langue. Le script se nomme fr-FR.localise.php (où fr-FR est le code ISO de la langue).Si  vous trouvez d’autresfichiers.php, ils sont suspects

 


3 - Consignes de sécurité d’un site Joomla
Btn retour  Written by Christophe Avonture | 01-09-2014 | Published in 2014

Et si on se penchait sur la sécurité de votre site Joomla! ? Vous l’aimez bien votre site, vous le trouvez beau ; vous y avez consacré tellement d'énergie. Vous êtes fier du résultat et nul doute que vous pouvez l'être. Votre site est beau et utile.  Vous l’avez mis sur le net pour en faire profiter le plus grand nombre. Permettez-moi de faire une comparaison : imaginons que votre site devienne votre maison. Quand vous n’êtes pas chez vous, laissez-vous la porte ouverte ? Vos baies vitrées sont-elles grandes ouvertes en votre absence ? Non, bien sûr. Et votre site internet ? Avez-vous songé à fermer les portes et les fenêtres afin d'éviter que des cambrioleurs n'y pénètrent ?
Surveillons la sécurité de votre site http://www.morguefile.com/archive/display/123195
Voyons de plus près ce que sont ces portes et fenêtres
A priori, un site Joomla! ne contient que deux portes d’entrée, celle de devant, côté rue et celle côté jardin.

Côté rue, c’est le fichier index.php qui se trouve à la racine du site et est donc accessible au travers de l’URL http://votresite/index.php. Tout le monde connaît cette adresse puisqu’il suffit de taper http://votresite pour y accéder. Aucune clef n’est requise pour l’ouvrir. Votre site est public.

Côté jardin
, c’est aussi un fichier index.php dont l’URL est : http://votresite/administrator/index.php.

Dans un monde idéal, vous devriez être le seul à connaître l’existence de cette porte. Malheureusement, les hackeurs savent en tester l’existence puisqu’il suffit d’accéder à l’URL http://votresite/administrator/index.php et voir si le serveur répond "Oui, il y a une porte, je vous la montre" (code HTTP 200) ou "Non, il n’y a rien" (code 403, 404 ou autre).
Avons-nous des fenêtres dans notre site Joomla! ? Malheureusement oui et en très grand nombre : ce sont tous les programmes que nous installons c'est à dire les composants, les modules, les plugins, les templates, les librairies... qui viennent toutes avec quantité de fichiers PHP.  En théorie, nous l’avons vu ci-dessus, aucun fichier PHP ne devrait jamais être exécutable depuis une URL à l’exception de nos deux index.php mais à dire vrai, vous n’en savez rien.
Qu’est-ce qui vous dit que vous n’avez pas installé un composant qui propose un fichier PHP exécutable au travers d’une URL telle que, par exemple, http://votresite/components/com_dummy/helpers/send.php où send.php serait un fichier légitime de com_dummy et qui permettrait d’envoyer un email au webmaster si un bug est détecté dans com_dummy. Vous n’en savez rien et parfois le développeur ne le sait pas lui-même lorsqu’il utilise des librairies de code prêt à l’emploi. Il est juste impossible de faire un tel suivi de toutes vos extensions. Chaque script ainsi appelable serait, dans notre comparaison, une fenêtre de notre maison : il convient de la fermer.
Vous pourriez aussi avoir des fichiers PHP dans, par exemple, le dossier /media : un composant tout à fait légitime aurait prévu un fichier PHP pour générer une feuille de style dynamiquement, un PHP pour générer une miniature d’une image, etc. Tout cela de manière parfaitement légitime pour ces développeurs.

Le souci: vous n’avez aucune vue sur ces fenêtres ! Vous ne sauriez même pas déterminer si ces scripts sont légitimes ou malsains. En effet, les pirates déposent ici et là des fichiers PHP dans des dossiers tels que /administrator/components/com_admin, /components/com_content, /libraries/cms, /media/com_content... c'est à dire le plus souvent dans des dossiers natifs de Joomla!. Les fichiers ajoutés ont des noms "passe-partout" comme "content.php", "article.php", "food.php"... tous inexistants lors d’une installation fraîche de Joomla!.

- Sécurisons notre maison et installons deux gardes du corps : à l’entrée et à la sortie
Il existe plusieurs applications de type "pare-feu" (firewall en anglais). Elles visent à ajouter ici et là des protections, des restrictions d’exécution, des interdictions d’accès à des dossiers sensibles, etc.

- La majorité des protections sont mises en place par l’ajout de fichiers nommés .htaccess dans des dossiers sensibles comme /media, /images, /stories ou encore /tmp. Les dossiers mentionnés ici ont toute une caractéristique commune : à priori, il ne faut jamais y autoriser l’exécution d’un script PHP. En d’autres mots : une URL telle que http://votresite/media/food.php ne devrait jamais pouvoir être accédée parce que food.php n’a aucune raison légitime de se trouver dans le dossier des médias.
- Imaginons le scénario suivant : un hackeur a réussi à exploiter une faille d’un composant se trouvant sur votre site ; une vieille version que vous aviez installée et oubliée de mettre à jour ou que vous aviez mal paramétrée (ayant par exemple autorisée n’importe qui à uploader un fichier). Cette situation n’a rien d’exceptionnel puisque la majorité des sites web ne sont maintenus que pendant un court laps de temps. Le site vieillissant, il n’est pas à l’abri d’une telle déconvenue. Le constat : tôt ou tard, un pirate réussira à pénétrer votre site et déposer un fichier PHP malsain où bon lui semble.

Idéalement, il faudrait donc deux gardes du corps : l’un va analyser tout ce qui rentre sur votre site et qui veillera à interdire tout qui n’est pas attendu (exemple : upload de fichiers) et l’autre va interdire l’exécution de code PHP non désiré.

Garde du corps n° 1 : interdire les entrées non autorisées dans votre maison

Il s’agit de choisir les bons réglages pour votre site : veillez précautionneusement à parcourir tous les écrans des réglages de Joomla!, à bien maîtriser les permissions (ACLs)... et à parcourir les écrans de réglages des différents composants installés pour restreindre les droits selon vos souhaits. Ainsi, vous pourriez avoir un composant de gestion de téléchargement de fichiers; peut-être n’est-il pas nécessaire d’autoriser quelqu’un à charger un fichier depuis le frontend. Si c’est le cas, interdisez le droit "d’upload" à quiconque.

Pour être totalement certain qu’aucun upload ne pourra être fait par quiconque (y compris vous), vous pourriez créer un fichier php.ini à la racine de votre site et y inclure cette ligne :

file_uploads=off

Si votre hébergeur prend en charge la "surcharge" du fichier php.ini, vous venez d’interdire l’upload : un pirate ne pourra plus installer, via le web, un code malsain sur votre site. C’est d’emblée une protection maximale... (mais fortement génante sur un site vivant).

Si votre hébergeur ne le gère pas, voici l’équivalent à mettre dans son fichier .htaccess :
<IfModule mod_php5.c>
php_flag file_uploads Off </IfModule>

(Attention : les mises à jour de Joomla!, d’extensions... ne fonctionneront plus, il vous faudra, par exemple, remettre la valeur sur "on" ou temporairement renommer le fichier php.ini afin qu’il ne soit plus traité par le serveur).

Garde du corps n° 2 : contrôler les sorties

Et si le garde à l’entrée était défaillant ? Et si un pirate était parvenu à sauver sur notre serveur un fichier PHP qui contient un virus, un relai pour générer du spam, etc. ?
Ce scénario est plus que probable puisque l’attaque pourrait avoir été faite par FTP ou via un site non sécurisé hébergé sur le même serveur que vous et chez un hébergeur très peu regardant à l’isolation des sites (un site corrompu pourrait à son tour corrompre tous les sites étant sur le même serveur web.
Le second garde du corps doit donc présumer qu’il travaille seul et ne pas se soucier si les blocages ont été ou non mis en place.
Une technique essentielle est d’interdire l’exécution des fichiers PHP qui se trouveraient dans des dossiers où il n’est pas attendu qu’ils puissent être exécutés, comme nous l’avons vu plus haut. Sous Joomla!, il y a plusieurs dossiers de ce type dont /images, /logs, /media, /stories et /tmp. A aucun moment, c’est à dire jamais, une URL telle que http://votresite/tmp/dummy.php ne devrait être exécutée. Jamais... sauf exceptions que vous mettrez alors en place au cas par cas.
Les exceptions sont ces composants dont les développeurs n’ont pas été assez stricts sur l’isolation des codes et la structure des dossiers de Joomla!.

Pour sécuriser votre site, repérez ces dossiers "PHP interdit" et placez-y un fichier .htaccess avec le contenu ci-dessous.

Pour les dossiers /logs et /tmp, la ligne ci-dessous pour interdire toutes les URLs vers http://votresite/logs ou http://votresite/tmp. En effet, ces dossiers sont réservés à des usages internes de Joomla!.
(JYR : créer un fichier texte, écrire : "deny from all" et/ou "allow from 12.345.678.90 (indiquez ici l'adresse IP)",renommez en .htaccess et le mettre sous le réperoire concerné.)
Deny from all

Pour les dossiers /images, /media et /stories :

AddHandler cgi-script .php .pl .py .jsp .asp .sh .cgi

Options -ExecCGI

Il s’agit ici de retirer le droit d’exécuter un fichier PHP. Une URL http://votresite/images/dummy.php ne permettra donc plus d’exécuter ce virus.

Notez que, dans le cas de ces dossiers, vous pourriez éventuellement rencontrer des problèmes d’exécution de certains composants. Il convient donc de tester en profondeur et de long en large votre site après avoir mis en place ces fichiers .htaccess.

Aller plus loin

Certains dossiers comme par exemple /components, /modules ou /plugins ne possèdent pas de fichier PHP dans le dossier racine. Vous n’aurez donc jamais un appel http://votresite/plugins/un-script.php. Vous pourriez donc parfaitement y placer un fichier .htaccess qui interdirait l’exécution de code PHP dans le dossier racine (/components par exemple) mais qui l’autoriserait dans un sous-dossier ;

d’autres dossiers n’ont pas pour vocation d’être accessibles depuis une URL, par exemple, le dossier /libraries. Il s’agit ici de librairies de fichiers source qui seront inclus par Joomla! Lors de l’exécution d’une fonction. Ici encore, vous n’aurez jamais une URL du type http://votresite/libraries/un-script.php. Vous pouvez là aussi interdire l’exécution d’un script PHP s’il est appelé depuis une URL.

Ces fichiers .htaccess correctement programmés et mis à bon escient dans les différents dossiers de Joomla! Vous permettront de protéger votre site web efficacement puisque, peu importe si un virus a pu être déposé sur votre site, il ne pourra pas être exploité s’il a été placé dans un dossier protégé.

Gardez cependant toujours à l’esprit que la sécurité 100% n’existe pas (il suffit de sauver le virus dans un sous-dossier de /components/com_content par exemple pour qu’il puisse alors être exécuté dans l’état actuel de votre protection, comme vu ci-dessus).

Quelques autres conseils :

Ne mettez jamais vos backups dans des dossiers tels que /backups, /_backups... ou encore de sauver vos backups à la racine de votre site avec un nom tel que "backup.zip" (ou backup.tar, backup.tar.gz, backup.gz, etc.). Il y a en effet des scripts spécialement développés pour lancer des requêtes (GET ou HEAD) http://votresite/backup.zip au petit bonheur la chance ;
Si vous deviez installer phpMyAdmin, ne le faites pas à la racine de votre site (exclu donc http://votresite/phpmyadmin (ou /phpMyAdmin ou /pma ou ...)) car ici aussi, j’ai constaté de telles connexions sur mes sites ;

Supprimez les fichiers LICENSE.txt, README.txt et web.config.txt (si vous êtes sous Apache) se trouvant à la racine de votre site puisqu’ils sont accessibles depuis une URL et permettent de savoir que vous avez un site en Joomla! ;

Supprimez le fichier joomla.xml que vous trouverez à la racine de votre site car il est 1. inutile et 2. accessible depuis une URL (http://votresite/joomla.xml). Il dévoile que vous avez un Joomla! et la version de celui-ci ;
Instaurez un mot de passe Apache (lisez un des nombreux tutoriels sur les fichiers .htpasswd) pour sécuriser votre dossier /administrator. Si vous disposez d’une adresse IP fixe, utilisez un blocage par liste blanche : seules les adresses IP autorisées pourront accéder à votre administration. A défaut d'un mot de passe / restriction par IP, interdisez l'accès aux fichiers .ini, .sql, .sh, .txt ou encore .xml de votre administration (ceci afin de bloquer des URLS telles que http://votresite/administrator/components/com_admin/admin.xml) ;

Pensez à mettre vos fichiers /index.php, /administrator/index.php et /templates/votretemplate/index.php en chmod 444 pour ne plus les rendre modifiables ;
Gardez à l’esprit que, comme pour d’autres matières (optimisation du site, référencement...), la sécurité est un processus permanent et ne présumez jamais que vos gardiens sont infaillibles. Faites des sauvegardes régulières, testez-les en local, faites vos mises à jour de manière régulière, analysez les fichiers logs de votre serveur Apache, surveillez les changements qui sont apportés sur les fichiers de votre site, soyez alerté lorsqu'un nouveau fichier est créé...
La sécurité de votre site est une partie de votre maintenance, on l’oublie trop souvent et on s'en souvient toujours trop tard.