Des visiteurs indésirables peuvent repérer que votre site est construit avec Joomla! et se servir de cette information à des fins peu reluisantes.

Il y a ceux qui vont essayer de pirater le site en testant des failles connues de Joomla! lui-même ou d'une de ses extensions ; d'autres pourraient vous contacter par mail ou téléphone pour simplement vous proposer leurs services, mais aussi, histoire de vous faire peur et de vous forcer la main, en vous faisant croire que votre site n'est pas à jour, voire qu'il est vérolé, même si vous ou le prestataire qui le gère le tenez scrupuleusement à jour et le surveillez attentivement.

Cet article a pour but de vous donner quelques directions pour vous protéger au mieux de ces indésirables.

En ce qui concerne les tentatives de piratage, à voir ce que peuvent enregistrer comme erreurs 404 les logs sur les serveurs ou la table des redirections du site lorsque la collecte de ces erreurs est activée dans le plugin de redirection, on peut dire que le plus souvent les pirates tirent à tout vat sans se soucier du CMS utilisé. On le voit par la présence dans ces adresses de termes concernant d'autres CMS. Dans ce cas, la solution est d'abord de sécuriser le site, de le tenir à jour en accédant régulièrement à l'administration pour savoir si des extensions utilisées ont une nouvelle version, de ne pas négliger les alertes reçues par mail depuis le site lorsqu'une nouvelle version de Joomla! vient de paraître, surtout lorsqu'il y a correction de failles récemment découvertes (à vérifier éventuellement sur https://www.joomla.fr). Cette première démarche est essentielle.

Dans la configuration générale de Joomla!, par défaut, le paramétrage masque la version dans le code-source des pages : cela permet d'éviter que le site soit ciblé en fonction de celle-ci, mais d'autres moyens permettent aux curieux qui le veulent vraiment de la connaitre. Nous y reviendrons, ce sera la deuxième phase de sécurisation, non indispensable mais fortement conseillée.

À ce stade, les démarcheurs indésirables ne sont pas exclus, car ils peuvent aisément savoir quelle est la version de Joomla! utilisée. Quelles que soient les diverses protections que vous appliquerez, l'analyse du code-source des pages pourra leur donner suffisamment d'indications leur permettant de savoir que vous utilisez bien Joomla!, même s'ils sont bloqués dans leur recherche de sa version.

Si vous recevez un mail ou un appel téléphonique d'une telle société et qu'elle vous propose simplement de s'occuper de la maintenance de votre site, cela peut vous agacer mais à vous de voir si vous en avez besoin ou si vous souhaitez changer de prestataire... Mais avant d'accepter, faites quelques recherches sur les offres, le lien prestataire-client devant être à mon sens basé sur une totale confiance.

Mais si le contact est justifié par des allégations vous assurant que votre site n'est pas à jour ou qu’il a été piraté, et surtout si avez confiance en votre propre prestataire ou en vos capacités à gérer vous-même votre site, ne vous laissez pas tenter d'accepter illico une intervention de leur part.

Si vous avez un prestataire habituel, contactez-le et prenez son avis ; si vous n'en avez pas, interrogez le forum francophone https://forum.joomla.fr pour avoir des avis multiples. En attendant, vérifiez vous-même si aucune mise à jour n'est à faire. Joomla! 3 signale dès sa page d'accueil d'administration si tel est le cas, pour Joomla! comme pour ses extensions installées et bénéficiant des alertes.
Dans le menu "Extensions->Gérer->Mises à jour", n'hésitez pas à "Purger le cache" et/ou à cliquer sur "Rechercher des mises à jour", celles-ci n'y étant pas toujours affichées d'emblée. Certaines extensions n'utilisant pas encore le système de mise à jour signalant celles-ci dans l'administration, il pourra être nécessaire de vérifier sur le site de leur auteur ; si vous avez un doute sur le numéro de version de plus récent de Joomla!, vérifiez sur https://www.joomla.fr ou https://www.joomla.org et pour les extensions une recherche sur https://extensions.joomla.org peut éventuellement être plus rapide qu'aller visiter le site de chaque auteur.
Pour ce qui est d'un éventuel piratage, vous pouvez déjà tester vous-même votre site sur https://sitecheck.sucuri.net avant de contacter votre prestataire ou le forum.

La protection générale du site, étant entendu qu'impérativement on n'utilise jamais le pseudo "admin" et que le mot de passe d'accès à l'administration doit être solide, peut s'établir à plusieurs niveaux. Un des plus simples est de ne pas permettre l'accès direct à la page de connexion à l'administration : couple .htaccess/.htpasswd ou plus simplement des plugins comme AdminExile ou EasyCalcCheck + qui nécessitent l'ajout d'un identifiant spécifique à l'adresse de la page pour qu'elle s'ouvre ; l'authentification en deux étapes est aussi disponible.

Pour aller plus loin, des extensions plus complètes comme AdminTools, extension de Joomla!, ou aeSecure plus généraliste et agissant en amont (que j’utilise moi-même) vont permettre d'affiner, aeSecure ayant aussi des fonctionnalités d'optimisation notamment dans ses versions Premium et supérieures. Interdire l'accès à certains fichiers, masquer les erreurs système, empêcher l'accès aux infos de version, etc. sont un vrai "plus" que je vous conseille fortement !

On peut masquer totalement le fait que le générateur du site est Joomla! ou le remplacer par un autre libellé, allant plus loin que masquer sa version, comme je l'ai dit au début. Ce masquage peut n'être pas désiré. Avec la protection complète dont je viens de parler, en laissant ces infos, on peut signaler que c'est bien le CMS Joomla! sur lequel est construit le site, mais on interdit les visiteurs trop curieux d'en savoir plus. Et dans ce cas, être contacté par quelqu'un qui vous affirme que votre site n'est pas à jour ou sain doit impérativement vous paraître suspect !

Merci à Simon qui, en me posant la question de savoir si je connaissais une méthode pour créer un quickstart à la manière des auteurs de templates, avec ses propres exemples, m'a amené à chercher et trouver une solution !

Bien sûr, la première idée a été de proposer Akeeba backup, mais déployer une telle sauvegarde conserve les infos d'accès des utilisateurs originels, dont le super utilisateur, ce qui n'est pas la meilleure idée à mon sens.

Sur le net, j'ai trouvé deux sites expliquant comment faire pour créer un quickstart, mais leurs explications, si elles m'ont mis sur la voie, ne m'ont pas totalement convaincu. Pour avoir péniblement créé de tels packs il y a quelques années, lorsque j'avais traduit les articles et les autres exemples de la version 1.6, je savais bien qu'il fallait générer un fichier SQL du même type que ceux d'exemples livrés avec les packs d'installation standard de Joomla! afin de compléter les données installées par défaut. Je me suis donc aussi inspiré du pack "brochure Joomla!" pour prévoir comment exporter les données dans un fichier d'exemples spécifique.

La procédure que j'ai suivie est donc celle-ci, procédure modifiée après tests complémentaires :

  • Installation d'une version neuve de Joomla! (avec GetJoomla FR pour accélérer la procédure), avec un super utilisateur qui ne devra plus l'être lors de l'installation du quickstart, et les exemples "brochure" dans cet essai ;
  • En fin d'installation, je n'ai pas supprimé mais seulement renommé le dossier "installation" afin de pouvoir lui redonner son nom d'origine dans le quickstart, sans devoir recopier le même dossier depuis le pack standard de même version ;
  • Installation des extensions souhaitées, en l'occurrence JCE 2.6.7.1, Akeeba backup5.2.5, Acymailing 5.6.1 et Kunena 5.0.5 (versions gratuites) ainsi que le template gratuit JoomSpirit 123 ;
  • Je n'ai fait aucun paramétrage de ces extensions ni utilisation d'Akeeba backup afin de ne pas embarquer de données inutiles lors de la création du fichier de données ;
  • Vérification de l'absence de fichiers dans les dossiers "cache" en dehors des index.html, sinon, supprimer ces fichiers de cache ;
  • Copie de l'ensemble des dossiers et fichiers du site d'origine vers un nouveau dossier, ou simplement conservation du dossier d'origine ; on redonne le nom "installation" au dossier d'installation précédemment renommé ;
  • Il restait alors à exporter les données et créer un ficher SQL d'exemples. La méthode a été celle-ci :
    • Ouverture de la base de données avec phpMyAdmin, sélection de la base pour affichage de ses tables ;
    • Clic sur le bouton "Export" et passage en mode personnalisé ;
    • Sélection de l'envoi du fichier non compressé pour pouvoir le modifier ensuite directement ;
    • Sélection de toutes les tables ; désactivation des "clés étrangères" (par habitude) ;
    • Coche des paramètres "CREATE TABLE" et "IF NOT EXISTS" afin de pouvoir ajouter les tables des extensions complémentaires, "Vider la table avant d'insérer" et "INSERT IGNORE" (probablement inutile) pour l'insertion des données ;
    • Export demandé de la structure et des données ;
    • Validation de l'export.
  • Une fois ce fichier obtenu, ouverture dans notepad++ pour modifications :
    • Remplacement de toutes les occurrences du préfixe des tables par "#_" afin que les noms comme "np6rb_nom-de-la-table" deviennent "#__nom-de-la-table" (double trait de soulignement) ;
    • Recherche de la table "#__usergroup_map" et dans la partie "INSERT IGNORE INTO", remplacement du "8" correspondant au groupe "super utilisateur" par "2" correspondant à celui d'enregistré, afin que le créateur du site de départ ne soit plus autorisé à gégrer ce nouveau site ; on peut à l'inverse lui conserver son statut si on doit ensuite intervenir sur le nouveau site pour aider son responsable ;
    • Enregistrement de ce fichier sous le nom de "sample_demo_fr.sql" dans le dossier "installation/sql/mysql" et suppression des autres fichiers exemples, pour simplifier le choix de l'utilisateur ;
    • Ajout dans le fichier "installation/language/fr-FR/fr-FR.ini" de la ligne suivante, pour que le texte "Données exemple" soit proposé dans la page d'ajout des exemples :
      • INSTL_SAMPLE_DEMO_FR_SET="Données exemples"
      • INSTL_SAMPLE_DEMO_FR_SET_DESC=""Données exemples du site de démonstration"_QQ_"RobertG démo"_QQ_"""
  • Dernière étape : on compresse l'ensemble des dossiers et fichiers du site (pas son propre dossier, et en excluant le fichier configuration.php) pour créer le quickstart, et on teste sur le même serveur ou un autre afin de s'assurer qu'on n'a pas fait d'erreur.

Un problème est apparu avec Kunena : cette extension a mémorisé le chemin d'accès au template défini par défaut lors de son installation, ce qui provoque une erreur lors de l'affichage du forum sur le nouveau site, nécessitant de changer de template dans les paramètres de Kunena, ce qui ne me paraît pas normal. Je n'ai pas trouvé comment, sauf aller dans la base de données, corriger ce lien vers ce template.

La cause en était en fait la présence d'un dossier "cache/kunena/" que je n'avais pas remarqué. Une fois celui-ci supprimé, l'accès à l'accueil du forum fonctionne. Il faut donc s'assurer que les dossiers "cache" ne comportent plus que le fichier index.html

N'hésitez pas à me contacter si vous relevez des erreurs dans ma procédure !

Sur les serveurs mutualisés OVH, le nom de domaine principal doit toujours être placé dans le répertoire "www".

Que ce soit par l'utilisation de l'installation de Joomla! en "module OVH" ou par transfert d'un site préparé en local ou tout simplement du pack d'installation, l'erreur fréquente est de placer le contenu du site dans un sous-répertoire, par exemple "Joomla1.6", ce qui va obliger le visiteur à saisir l'adresse "http://www.monsite.tld/Joomla1.6" ou l'auteur du site à créer dans le répertoire "www" un fichier .htaccess redirigeant vers ce sous-répertoire, dont le nom apparaîtra ainsi dans la barre d'adresse du navigateur. Certains pensent que cela facilite l'indexation du site, si le nom de ce sous-répertoire correspond à un mot-clé important du site. Je n'en suis pas convaincu, c'est pourquoi je préconise de ramener tout le site dans ce répertoire racine "www" par une procédure très rapide.

Il faut donc tout simplement, avec un client FTP, déplacer par glisser-déposer tout le contenu de votre répertoire « Joomla1.6 » (pour conserver l'exemple précédent) vers « www », ou passer par net2ftp disponible depuis le Manager OVH, et utiliser la fonction « Déplacer ». Ceci ne va prendre que quelques secondes. Ce répertoire vide doit ensuite être supprimé, puisque devenu inutile.

Il est ensuite nécessaire de supprimer la référence à ce sous-dossier dans les valeurs des chemins d’accès aux répertoires « logs » et « tmp » du fichier « configuration.php », soit à la main (en prenant bien soin d'enregistrer le fichier en UTF-8 NO BOM), soit avec MoovJla.php : le site sera alors fonctionnel directement sur l’adresse du nom de domaine.

Si votre hébergeur vous permet la création de sous-domaines (ce que me permettaient les différents comptes mutualisés sur lesquels j'ai pu tester, chez PHPNET, OVH et 1and1), l'important à mon sens est de bien utiliser ce que permet l'hébergeur, à savoir l'isolement complet du site principal et des sous-domaines.

  • le site principal doit être dans son propre répertoire : obligatoirement "www" chez OVH s'il s'agit du nom de domaine principal lié au pack d'hébergement, dans un sous-répertoire du répertoire racine, défini par l'utilisateur, chez PHPNET et 1and1
  • chaque site en sous-domaine doit être placé dans son propre dossier au même niveau que celui du nom de domaine, ceci permettant d'interdire un accès au sous-domaine avec une adresse du type "mon-nom-de-domaine/dossier-du-sous-domaine" et ne permettre d'ouvrir le sous-domaine que par son propre nom
  • selon l'hébergeur, le lien à faire entre le nom du sous-domaine et le dossier contenant le site sera déterminé à un moment différent, mais il est de toutes manières toujours nécessaire d'avoir au moins créé le dossier avant de tenter ce lien :
    • chez PHPNET, c'est à la création du nom de sous-domaine que le lien se fait avec son répertoire (liste déroulante ou saisie manuelle selon le type de compte d'hébergement)
    • chez OVH, c'est également à la création que ce lien se fait, par saisie manuelle (remplacer "www" par le nom du dossier du site)
    • chez 1and1, cela demande deux étapes : créer le nom du sous-domaine, qui le lie par défaut à la racine, puis sélectionner ce nom dans la liste des domaines et cliquer sur le bouton de menu "Destination" ->"Modifier la destination : selon qu'il y a beaucoup de dossiers ou pas, il faudra soit saisir à la main le nom du dossier de destination du sous-domaine, soit le sélectionner dans une liste déroulante.

Dans tous les cas, il faut attendre quelques instants pour que le lien entre le nom et le répertoire du site soit bien interprété et qu'il soit donc possible d'accéder au site en question.

À cette adresse, vous trouverez un utilitaire permettant de créer un nouveau mot de passe pour un compte existant de super-administrateur :

http://www.joomlafrance.org/Les_News/Addon_et_Hack/Retrouver_son_mot_de_passe_administrateur_de_Joomla.html

Il est également possible d'intervenir directement dans la base de données en passant par phpMyAdmin.

Il faut sélectionner et éditer le compte présent dans la table "jos_users" (si le préfixe de table a été fixé à "jos_"), puis, sur la ligne "password", sélectionner le cryptage MD5 et entrer le nom du nouveau mot de passe en clair. Il suffit alors de cliquer sur le bouton "Exécuter" pour que ce nouveau code soit attribué au super administrateur.

passe

Autre solution encore plus simple : utiliser la fonction "mot de passe oublié" depuis le formulaire d'identification du site, si elle est activée.