Les permissions des fichiers et dossiers (CHMOD, abréviation de Change Mode) recommandées sur Joomla (ou d'autres applications PHP) dépendent en partie des hébergeurs.

Un même droit est parfois interprêté différemment selon l'hébergeur (déjà vu), une même application requiert parfois différents droits selon l'hébergeur. Certains serveurs vont automatiquement bloquer certains droits sur certains contenus.

Mais quand un site commence à être mature, il subit de moins en moins de modifications structurelles. On peut alors fermer certaines portes - comme on fermerait l'accès au compteur électrique - et mettre en place une politique des moindres privilèges.

La mise en place d'une politique des moindres privilèges doit être suivie de tests et d'une communication fine avec son hébergeur. Il n'y a rien d'exhautif et rien de parfait, n'hésitez pas à modifier progressivement les permissions vers le bas selon vos propres observations. Il s'agit de fermer au maximum, puis de ne ré-ouvrir que le strict nécessaire.

  • En m'inspirant des pratiques habituelles sur Joomla (dossiers en 755, fichiers en 644 et configuration.php en 444), je passe tous les fichiers en 444 (pas les dossiers, que je laisse en 755). Ensuite je passe les fichiers de logs en 644. Et si le serveur en question mentionne des erreurs, je ne passe que le strict nécessaire en 644.
  • Videz/vérifiez régulièrement les répertoires tmp et cache.
  • Surveillez l'apparition de fichier index.htm ou index.html à la racine de votre site.
  • Pensez aussi à vérifier régulièrement l'intégrité de tous les contenus extra-Joomla que vous auriez vous-même mis à coté du site.

Attention : avant chaque mises à jour, il vous faut repasser tous vos dossiers en 755 et vos fichiers en 644 !

Ceci sauf en parfaite connaissance de cause (des MAJ d'extensions précises et bien connues de vous par exemple). Sous peine de planter des MAJ, de façon visible ou invisible (avec ou sans avertissement dans l'administration). Après votre mise à jour, vous rétablirez des permissions plus restrictives.

De même si vous souhaitez faire des modifications du code, vos fichier doivent être en 644.

Les formulaires d'inscription et de connexion

1ère porte d'entrée de vos sites, chacun, même un robot ou un pirate, a accès à au moins 2 formulaires de n'importe quel site un peu dynamique : le formulaire d'inscription et celui de connexion. Et un formulaire peut potentiellement injecter du code malfaisant dans votre BDD.

La présence de ces formulaires publiques est normale et souhaitable. Forcer les utilisateurs à s'inscrire eux-mêmes (ne pas les inscrire à leur place) est gage de sécurité (personnalisation des mots de passe, moins de transmission de mot de passe par email...).

Ainsi si la présence de ces formulaires est indispensable, un petit captcha le sera tout autant. Cela sur tous les formulaires accessibles au public (possibilité de masquer automatiquement les captcha aux utilisateurs connectés).

Les méthodes de Captcha fonctionnent très bien, et sont natives sur Joomla. Il s'agit d'API tiers gratuites, que vous activez et paramétrez depuis l'administration Joomla.

L'administration Joomla vous permet de modifier les contraintes requises sur les mots de passe. N'hésitez pas à choisir la plus appropriée (1 symbole, 1 chiffre et 1 majuscule par exemple).

Il y a également la possibilité de forcer la ré-initilaisation des mots de passe utilisateurs.

La double authentification, native également, est intéressante, au moins pour votre administration. La méthode par Google Authenticator fonctionne très bien, mais d'autres existent. À noter qu'à aucun moment vous ne mentionnez vos mots de passe Joomla à Google (uniquement l'identifiants des comptes concernés, + évidemment les différentes informations au sujet de la connexion, date, navigateur, clics... on connaît Google). Mais il s'agit d'une clé secrète générée toutes les 30 secondes et reçue personnellement par l'utilisateur via une application portable (+ quelques clés secrètes permanentes valables une fois). C'est donc assez séduisant et sécurisant.

Une méthode supplémentaire peut également être adoptée, qui consiste à chaque parution de MAJ Joomla de bloquer l'inscription, et idéalement la connexion. Cela le temps de faire la MAJ et quelques tests fonctionnels.

Autres

J'ai également l'habitude de bloquer le référencement des formulaires d'inscription, directement sur les contenus Joomla quand c'est possible, mais aussi dans le fichier robots.txt. De cette façon par exemple (récupérez avant cela les liens vers vos propres pages et pensez à l'éventuel multi-linguisme) :

Disallow: /enregistrement
Disallow: /enregistrement*
Disallow: /enregistrement/
Disallow: /enregistrement/*

Disallow: /fr/enregistrement
Disallow: /fr/enregistrement*
Disallow: /fr/enregistrement/
Disallow: /fr/enregistrement/*

 

J'évite aussi de dépasser les 2/3 d'occupation de la mémoire disponible, car selon les caractéristiques de votre hébergeur cela peut perturber vos droits en écriture (et planter un site en pleine mise à jour, déjà vu...).

Notes sur quelques sociétés d'hébergement

Siteground

  • CHMOD contrôlés par l'hébergeur sur de nombreux types de serveurs (2017).
  • Existence d'un scanware apparemment assez efficace, avec rapport hebdomadaire par email. Disponible sur plusieurs types de serveur. Payant mais très accessible.

Infomaniak

  • Obligation de passer ses répertoire en 2777 pour les mises à jour. Vérifiez après la MAJ que configuration.php est bien en 444 (mai 2017).
  • Existence d'un antivirus-scanware sur leur console d'administration, à lancer manuellement.

 

Il n'y a certainement pas de panacée en matière de sécurité web, elle serait immédiatement détournée et constiturait une faille de sécurité... Ces conseils ne sont donc ni exhaustifs ni formels (en particulier ceux sur les permisisons CHMOD, qui ne peuvent pas toujours être appliqués tels quels). Soyez surtout attentif, surveillez vos sites et les parutions de mises à jour, envoyez-vous des emails automatiques au niveau des principales entrées de vos sites (inscription, création et modification de contenus...) et bien sûr faîtes régulièrement vos sauvegardes, en n'oubliant pas qu'une sauvegarde non-testée n'est pas une sauvegarde.

Bon courage !