*Ce texte s’adresse aux webmasters qui ne sont pas des brutes du PHP ni des adaptes chevronnés de la sécurité. Les lignes qui suivent sont en partie basées sur l’incontournable manuel Cracking Drupal ainsi que sur divers retours d’expériences, notamment de la communauté Drupal France. Merci à eux.*

Lorsque l’on est développeur à la souris sous Drupal, que l’on doit monter un site à petit ou moyen trafic, on doit s’assurer un minimum que l’installation ne va pas se casser la figure dès la première injection XSS d’un adolescent boutonneux en mal de sensations fortes. Mais on n’a pas toujours le socle de connaissances nécessaires ni les infrastructures nécessaires. Par exemple, on n’a pas les mêmes possibilités sur un serveur dédié que sur un serveur mutualisé.

Retour rapide sur les bases : Drupal est un CMS dont certains vont jusqu’à dire qu’il s’agit d’un framework, permettant de bâtir des sites Internet, assez rapidement, que ce soit des sites institutionnels comme celui de la Maison Blanche ou des sites de e-commerce. Cela peut aussi être de simples blogs et forums, comme ici ou comme sur le site de l’association Drupal France.  Comme la majorité des CMS, son « empreinte » est assez flagrante dans le code source.

Quels sont les points importants à vérifier avant une propulsion publique ?

Les permissions des utilisateurs

Par défaut, il existe quatre formats de textes utilisables par les utilisateurs : le texte brut, le HTML filtré, le HTML tout court et le PHP. Le plus sage et le plus facile est de limiter l’usage des formats. Pour faire simple : l’anonyme n’a recours qu’au texte brut et l’administrateur à tous les formats. S’il y a des utilisateurs authentifiés, avec des permissions particulières notamment pour la parution des contenus, on procède au cas par cas. Personnellement, ici, tout le monde est en texte brut sauf moi et sur les précédentes plateformes que j’ai eu à gérer dans un cadre professionnel, les utilisateurs authentifiés étaient limités au HTML filtré.

On peut égalment recourrir à Content Access qui va personnaliser les dropits accès en fonction des contenus mais il faudra également penser à paramétrer le flux RSS afin qu des utilisateurs n'ayant pas accès à certains contenus ne reçoivent pas pour autant des "notifications" dans leur flux. Il faut donc penser à coupler ce module avec RSS Permissions. 

L’administration des modules

Sur Drupal, on différencie le core – qui compose donc le cœur de base de Drupal – et les modules complémentaires, par exemples Views qui doit certainement être l’un des modules complémentaires les plus utilisés. L’administrateur a – de base – tous les droits d’administration sur les modules. Mais s’il existe des utilisateurs authentifiés qui ont accès au back-office, le mieux est de réduire leur possibilité d’administration. Cela peut paraître très sévère mais, pour reprendre l’expression d’un ami, « un bon administrateur est un dictateur. Il décide et les autres ferment leur gueule. ». Pour avoir vécu la désactivation d’un module par un utilisateur authentifié sur une autre plateforme il y a quelques mois de cela, ayant ainsi entraîné la disparition de la moitié des fonctionnalités de la plateforme, je pense qu’il s’agit d’un bon conseil.

Les contenus et les commentaires

Selon le degré d’ouverture de votre site, vous devrez modérer vos commentaires d’une façon ou d’une autre. Au départ, on est dans un gentil monde bisounours et on laisse le site ouvert aux quatre vents niveau commentaires. Fondamentalement, c’est une erreur car le site, selon la façon dont son référencement est fait, va rapidement être repéré par des robots spammeurs, qui joyeusement polluer la plateforme. En étant confiné dans le back-office, ils feront moins de dégâts et encore moins s’ils sont cantonnés au texte brut pour le dépôt de commentaires.

Le blocage d’IP

Sous les versions précédentes de Drupal, le BanIP était un module complémentaire. A présent, il est intégré dans le core de Drupal ce qui facilite grandement la vie. Il convient donc de l’activer, de même que le syslog, tracker, trigger qui vous permettront de suivre presque à la trace ce qui se passe sur le site.

Le spam

Comme tous les sites – sauf s’il s’agit de sites ne permettant ni contact, ni inscription, ni commentaire – vous subirez du spam. Mais vous ne serez pas totalement démuni. Sous Wordpress, Akismet fait bien le job de filtre, sur Drupal, le résultat n’est pas folichon. Mais il existe plusieurs autres systèmes bloquant totalement le spam.

Le premier est Bad Behavior qui joue les garde-fous mais ma préférence va à Honeypot. Comme vous le savez certainement, les robots spammeurs remplissent de façon automatique tous les champs qui se présentent à eux. Honeypot fournit une petite ligne supplémentaire, invisible aux internautes légitimes, que les robots complètent automatiquement.

Honeypot bloque alors la soumission même du commentaire et si on est farceur, on peut aussi mettre une limitation de temps dans la soumission des commentaires, bloquant toute nouvelle soumission depuis une même adresse IP pendant un certain laps de temps, que le webmaster peut configurer comme il le souhaite.

Seul point faible : il ne gère pas les IPv6, de même qu’à ce jour, Drupal dans son ensemble, ne les prend en compte.

Le firewall

Fail2Ban est un petit firewall*, également sous forme de module, qui permet de fournir, entre-autres, une whitelist d’adresses IP légitimes. Nécessite évidemment d’avoir une IP statique en IPv4. On peut aussi le paramétrer de telle façon à ce qu’il garde certaines informations en cas d’activité sur la plateforme.

L’IDS

C’est au détour d’un cache de site qui n’est plus disponible que je suis tombée sur Tiny-IDS, un système de détection d’intrusion, adapté à Drupal. Il possède cinq niveaux de sensibilité et génère automatiquement un rapport par email lorsqu’une activité curieuse est détectée. Attention avec le mode paranoïaque car l’IDS enverra alors des alertes emails pour toutes les activités du site – y compris celles qui ne sont pas nécessairement suspectes.

Cette première couche d’information vous permet d’avoir quelques outils reconnus, qui ont fait leur preuve. Mais cela n’est évidemment suffisant et aucun système n’est 100% étanche. La prochaine partie s’intéressera à un niveau supérieur. 

* Ce sont les développeurs de Drupal qui ont défini Fail2Ban comme un firewall.