En l'espace de deux mois, deux sites parmi les plus populaires de la presse alternative ont été violemment attaqués dans le but de les détruire. Malheureusement, l'un d'entre eux est, pour l'instant, resté sur le carreau.
Dans cet article, je décrirai brièvement les attaques dont ont été victimes d'abord Arrêt Sur Info de Silvia Cattori, puis Investig'Action de Michel Collon. Ensuite je présenterai des moyens que chaque éditeur de presse alternative peut assez facilement mettre en place pour s'en prémunir de manière efficace.
Quelle que soit l'opinion que l'on a sur tel ou tel site d'information, et si je conçois qu'on puisse être radicalement opposé aux idées, j'estime qu'il est parfaitement inacceptable en démocratie de s'en prendre aux voix dissidentes pour les faire taire. Au reste quand on connaît les cibles, il n'est pas très difficile de remonter aux responsables. Faut-il préciser que même au cas où on parviendrait à remonter jusqu'à la véritable adresse IP des attaquants, vous ne trouveriez pas un inspecteur de police ou un procureur pour recevoir votre plainte, ou bien celle-ci serait rapidement classée sans suite.
Arrêt Sur info : Le premier a avoir subi des attaques a été Arrêt Sur Info. Dans la mesure où le site était déjà abrité derrière CloudFlare, celles-ci ont pris la forme de requêtes multiples et répétées sur l'ensemble des archives, via le port 80. De simples requêtes comme celles que l'on fait lorsqu'on navigue sur le site, à la différence qu'elles étaient très nombreuses et ont mis le serveur sur les rotules. Une fois les pages en cache dans CloudFlare (après la première demande, donc), celles-ci sont ultérieurement servies par lui sans plus transmettre la demande au serveur qu'il protège.
Investig'Action : Les attaques, d'une rare violence, ont duré plus d'une semaine et étaient multiformes. En plus de la technique exposée ci-dessus, les attaquants ont fait appel au DDOS, une attaque en déni de service distribué. En pratique, un ou plusieurs serveurs envoient des requêtes UDP sur la machine pour en saturer le stack, la mettant dans l'impossibilité de répondre aux demandes ultérieures. Le serveur est totalement bloqué. Cependant, l'ampleur somme toute limitée de l'attaque DDOS et le fait qu'ils aient du combiner avec une saturation de requêtes HTTP simples semble indiquer que ce n'était pas une attaque massive, via des dizaines de serveurs, mais plutôt l'initiative d'une ou deux personnes, en faisant appel à des services gratuits que l'on trouve ça et là sur le web. En fait, il s'agit d'utiliser des soi-disant outils de stress-test comme outils de production pour faire tomber un serveur. Les attaques plus massives quant à elles nécessitent plus de ressources, ce qui s'avère souvent coûteux.
Dans le cas d'Arrêt sur Info, les conséquences ont été dramatiques. La WebMaster, qui est aussi rédac-chef du média a décidé, jusqu'à plus ample informé, de laisser le site en jachère, découragée par les attaques répétées, et devant les difficultés qui se posent pour sécuriser mieux son serveur. Résultat, plus aucun nouvel article publié, les auteurs sont dépités, les lecteurs aussi.
Pour InvestigAction, qui est un collectif, la situation a pu être rétablie après une semaine complète de blocage quasi-permanent, mais on imagine que cela leur aura causé un double préjudice. D'une part, un manque à gagner pour une organisation qui ne vit que de dons et de la vente de ses livres; et d'autre part, les frais liés à la remise en service et la protection de leur hébergement.
Objectivement, je crois qu'il est tout à fait concevable que d'autres sites de médias alternatifs aient aussi à faire face à des attaques dans les prochaines semaines ou les prochains mois. Vous aurez vu comme moi que les cibles ne sont pas anodines, et qu'elles indiquent assez clairement d'où pourraient provenir les attaques. Des petits Kévin autoproclamés justiciers, ou plus exactement exécuteurs des basses oeuvres à l'encontre de ceux qui osent s'exprimer en dehors des chemins balisés par la pensée unique.
Les mesures qui peuvent être prises dépendront avant tout de votre hébergement et du CMS que vous utilisez pour gérer le contenu de votre site. En gros, il y a deux types d'hébergements : mutualisé ou dédié. Et pour les CMS, il y en a deux qui sont très largement utilisés : Drupal et WordPress. Il y a bien encore ça et là des CMS Spip en production, parce qu'ils avaient la cote, à une époque, parmi les sites d'info alternative, mais il ne sera pas abordé ici.
C'est l'entrée de gamme de l'hébergement. De nos jours on en trouve à moins de deux euros par mois chez divers fournisseurs. Qui dit mutualisé dit partage des ressources. En gros, on parle d'un serveur sur lequel peuvent être installés des dizaines de sites différents correspondant à des clients différents. En général ces hébergements viennent avec de solides limitations en termes de bande passante, de quotas, du nombre de sous-domaines ou de bases de données que l'on peut créer. Plus grave dans le cas qui nous occupe, le client n'a de visibilité que sur sa propre zone d'hébergement, et nullement sur les paramètres du serveur. Il ne peut ni le stopper, ni le redémarrer, ni modifier des paramètres de la configuration du serveur. De plus, ces hébergements offrent rarement une protection contre les attaques telles des détecteurs d'intrusion ou des firewalls.
Mesures de protection spécifiques
Il s'agit d'une machine (physique) entièrement réservée au seul usage du client qui la configure entièrement selon ses propres besoins. Il a donc les droits nécessaires à l'installation de tous les logiciels qu'il estimera utile. De plus ces plans d'hébergement s'accompagnent souvent de connexions rapides et illimitées, voire même la protection d'un firewall d'infrastructure configurable par le client. Ce type d'hébergement commence aux alentours de 50 EUR/mois, soit tout de même 20 fois plus cher qu'un hébergement mutualisé.
On pourrait aussi parler du modèle hybride : une machine virtuelle sur un serveur mutualisé. Les avantages de la machine dédiée au point de vue de la configuration, mais les inconvénients de l'hébergement mutualisé en termes de restrictions, de quotas et de robustesse.
Mesures de protection spécifiques
C'est un proxy inversé. Il se place entre les clients et votre propre serveur. Faisant cela il masque aux clients la véritable adresse IP de votre serveur qui ne peut donc plus être attaqué directement pour peu que cette adresse n'ait pas été répertoriée. Malheureusement, certains se sont mis en tête qu'en fait CloudFlare servait principalement à masquer l'identité de truands qui se livrent à des activités illicites sur internet (trafic, spam, arnaques, ...). Et certains ont créé des applications qui scannent inlassablement le net en notant scrupuleusement l'adresse IP véritable des serveurs correspondant aux noms de domaines. Il est donc judicieux, après avoir abrité son serveur derrière CloudFlare de vérifier si ces applications sont capables de retrouver l'adresse IP de votre serveur. Et si cette adresse reste accessible, de demander à votre fournisseur de déplacer votre site sur une autre machine.
CloudFlare agit également comme cache. C'est-à-dire qu'il stockera localement une copie des pages que les utilisateurs ont déjà demandées. Et au cas où cette page est ultérieurement redemandée, il ira la chercher directement dans son infrastructure sans que votre serveur soit mis à contribution. C'est ce qu'on appelle le cache-hit, le nombre de pages qui ont été servies par lui, économisant autant de précieuses ressources sur votre serveur.
Se plaçant entre les clients qui peuvent s'avérer animés de mauvaises intentions et votre propre serveur, en cas d'attaque, ce sont les serveurs de CloudFlare qui prendront les coups, et non pas votre précieux serveur web.
Une autre fonctionnalité intéressante est la possibilité d'ajouter, pour une adresse IP, pour une groupe d'adresses IP, voire même un pays entier la nécessité pour l'utilisateur de prouver qu'il n'est pas un robot. Vous avez tous déjà probablement vu ceci :
Parmi les autres options, on peut aussi choisir le «javascript challenge», toujours pour s'assurer qu'on a bien affaire à un internaute et pas à un robot qui comme dans le cas d'Arrêt Sur Info était hostile et dont l'objectif était de mettre le serveur par terre en le submergeant de requêtes simultanées.
Il est absolument impératif de disposer d'un gestionnaire de cache aussi au niveau du CMS, ne serait-ce qu'au cas où pour l'une ou l'autre raison CloudFlare repasserait subitement en mode transparent et répercuterait toutes les demandes sur le serveur « origine » (le vôtre).
Dans Drupal, c'est prévu, il suffit de l'activer au niveau du panneau de configuration :
Pour ceux d'entre vous qui utilisent WordPress, il faut installer un plugin comme par exemple Super_Cache. Pour les autres CMS aussi, c'est indispensable, et s'ils ne le permettent pas, fuyez, pauvres fous ! Par les temps qui courent, vu la sophistication des CMS qui nécessitent tant et plus de cycles processeur pour afficher une simple page web, l'absence d'un gestionnaire d'antémémoire est un no-go. C'est tout simplement suicidaire.
À moins que vous ne soyez particulièrement débrouillard, la configuration de CloudFlare, sans parler de l'installation d'un serveur dédié sont des tâches qui nécessitent des compétences techniques spécifiques. Le minimum étant de pouvoir modifier chez votre « registrar » les serveurs de domaines à utiliser (qui devront être ceux de CloudFlare).
La question à poser ici étant : pouvez-vous risquer de vous faire réduire au silence pendant des jours voire plusieurs semaines, ou à jamais ? Il faut donc mettre en balance les frais éventuels qu'exigeraient l'intervention planifiée d'un technicien pour quelques heures de boulot avec les frais qu'occasionneraient la même intervention dans l'urgence qui s'ajouteraient à un éventuel manque à gagner.
Si vous aussi vous êtes responsable d'un site de presse alternative, si vous pensez que vous pourriez être un jour la cible d'attaques pour la seule raison de vos écrits, et si vous avez une question spécifique, vous pouvez me la poser via mon formulaire de contact, j'y répondrai dans toute la mesure du possible, au mieux de mes capacités.
