Sécurité Joomla : La faille humaine !

Nous avons été récemment hacké par un mauvais plaisantin, qui a utilisé une faille de sécurité mise en évidence par le pirate Méfisto. Généralement, ce hack se traduit par la présence d'un fichier c99.php ou c9.php ou thumbs.php dans l'un des dossiers de votre site Joomla. Pour peu que vous ayez dans l'arborescence enfante ou voisine des dossiers en accès public (777), c'est une boucherie : Dans le style que je vous pollue votre serveur avec des sites pornos et autres portails de phishing : Vous avez envie de finir en tôle ?

Amateurs de Joomla, méfiance ! L'ennemi vous guette sans relâche, mais vous pouvez lui opposer une résistance efficace en intervenant à 4 niveaux :=> Tout d'abord, respectez scrupuleusement les critères d'installation de Joomla : Lors de l'installation de votre package stable (1.0.11 à ce jour),; Joomla effectue des diagnostics, veillez à ce que tout soit au vert comme ci-dessous.

=> Ensuite, Joomla vérifie si un certain nombre de droits d'écriture sont garantis. En phase de développement, OK pour faire un CHMOD -R 777 global sur tout le répertoire. Toutefois, veillez à rapidement régresser vers un prudent CHMOD -R 755 une fois vos paramétrages effectués, sauf sur certains répertoires sensibles, tel que celui des medias ou du cache.

=> Par ailleurs, soyez extrêmement vigilants quand à l'installation d'extensions tierce partie : Composants, modules et mambots sont des hôtes potentiels de failles de sécurité extrêmement dangereuses. J'écrirai prochainement dans ces colonnes sur ce sujet, mais retenez d'ores et déjà que le loup entre dans la bergerie dès que votre extension est développée en dehors du cadre strict et orthodoxe de l'API joomla, notamment en matière de contrôle d'accès aux fonctionnalités. Une bonne mesure conservatoire est de s'assurer que l'extension que vous envisagez de mettre en production comporte bien le contrôle d'accès global suivant : defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not allowed.' );un certain nombre de composants ont récemment été incriminés, alors ne vous fiez à personne. Voici un début de liste : Extcalendar, jd-wordpress , jd-wiki, com_smf, ...=> Enfin, vous pouvez un peu blinder votre interpréteur PHP en réglant 3 variables comme suit :- register_globals=OFF : Combien de fois faudra-t-il le répéter ?!- allow_url_fopen=OFF : Ca mange pas de pain, et ça évite bien des soucis. Mais pourquoi ce paramètre est-il par défaut à ON ? Appelez-moi le directeur.- open_basedir : Affectez lui des restrictions explicites. Je reviendrai sur ce sujet dans un prochain post.

Allez, courage, on les aura ;)

Bookmark and Share

Commentaires

Authentifiez vous pour commenter.