Segmentation et besoins d'accès à...

Les accès à un système d'informations correctement organisé doivent respecter les principes de segmentation et de besoin d'en savoir, ici transformé en besoin d'accéder à. En résumé, si une entité (individu, programme, équipement...) n'a pas besoin d'accéder à une autre entité (même liste que précédemment, à laquelle on ajoute les données), l'accès doit être impossible. S'il est sympathique de considérer que personne n'abusera d'une possibilité d'accès excédant le strict nécessaire, il n'en demeure pas moins que c'est une très mauvaise idée.

La limitation des accès au strict nécessaire évite beaucoup de mésaventures, la plus évidente étant l'accès malveillant par une entité non autorisée. Cela n'empêchera pas un accès malveillant par une entité autorisée, mais cela réduit quand même singulièrement le spectre.

Un cas d'école

Un samedi, le responsable informatique d'une entreprise nous a appelés, quelque peu paniqué : son serveur Web accusait une charge système significative et très inhabituelle. Il craignait une attaque et la prise de contrôle de son système par des tiers dont les intentions n'étaient pas forcément amicales.

Investigations

L'examen des journaux d'activité du serveur Web, réalisé durant l'incident, a très rapidement orienté les investigations vers une attaque en force brute sur la page de connexion (administrative) du CMS sous-jacent au serveur Web. Au début de nos investigations, nous avons constaté que, sur la dernière heure, le serveur avait reçu 51918 tentatives de connexion, provenant de 1853 adresses IP différentes. Nous avons soigneusement examiné les URLs activées, et personne n'est allé au-delà de la page de connexion. Du fait de la taille relativement modeste du système, ce volume et le traitement nécessaire de chacune des requêtes ont suffit pour saturer l'ordinateur, provoquant indirectement un déni de service.

La supposition initiale est donc la bonne. Son serveur est sous attaque, et c'est une tentative de prise de contrôle. A un bémol près, légèrement positif : les visiteurs indélicats n'ont pas encore trouvé la bonne combinaison de compte/mot de passe.

Trouver un mot de passe n'est pas très compliqué. Il suffit de bons outils, d'un bon dictionnaire, et d'un peu de temps. Plus le mot de passe est long et aléatoire, plus le temps nécessaire augmente. La politique de mots de passe de l'entreprise, concernant les accès au serveur Web, est relativement stricte et, surtout, à peu près respectée. Cela explique sans doute qu'aucune des plus de 50000 tentatives n'a été couronnée de succès. Cela ne signifie pas que tous les comptes disposent d'un mot de passe robuste, seulement que les 51918 premières tentatives ont échoué. Peut-être que la 52000 sera couronnée de succès...

Du fait de l'intervalle temporel très limité, nous considérons que ces quelques 52000 requêtes, bien que provenant de presque 2000 adresses IP différentes, ne sont qu'une seule et même attaque par un réseau de zombies.

Le nombre de requêtes réalisées par chaque adresse IP participant à l'attaque est très variable, allant d'un minimum de 1 tentative (pour 27 adresses) à un peu plus de 200 (pour quatre adresses). Un outil comme fail2ban, inspectant en temps réel le journal du serveur Web à la recherche de tentatives répétées de connexions, aurait pu ralentir l'attaque.

Modifications apportées

Lorsque l'on constate une attaque distributée, comme ici, il est illusoire de bloquer sélectivement les adresses IP détectées. Même quand c'est fait automatiquement (fail2ban, déjà cité), cela ralenti l'attaque sans la bloquer. Pour peu que le réseau de zombies agresseur soit performant et dispose de nombreux ordinateurs, ce n'est plus qu'un problème de séquencement approprié pour passer en-dessous du seuil de détection. Cela ne signifie pas que fail2ban et consors sont inutiles : beaucoup d'outils d'attaque en force brute ne sont pas sophistiqués au point de détecter qu'ils sont bloqués et d'en déterminer les seuils de blocage.

Nous avons recommandé une modification très simple : interdire l'accès aux URLs administratives du CMS à toute IP qui ne correspond pas à l'une des adresses IP publiques (fournies par les FAI) de l'entreprise. Quelques directives Allow from dans la configuration du serveur Apache, un redémarrage du service, et le tour est joué.

Ce changement signifie a priori que les utilisateurs ne peuvent plus modifier le contenu du serveur depuis leur domicile (ou d'ailleurs, dès lors qu'ils ne sont plus sur le réseau de l'entreprise). La société ayant mis en place un VPN permettant la connexion à distance à (une partie de) son système d'informations, cela ne constitue en fait pas une dégradation des fonctionnalités. Les utilisateurs désireux de travailler sur le serveur Web depuis l'extérieur de l'entreprise ouvrent une connexion VPN vers l'entreprise, et rebondissent vers le serveur Web.

Nous avons aussi fait une revue des comptes des utilisateurs, et constaté que tous les comptes étaient de niveau administrateur total du CMS et que certains comptes actifs correspondaient à des collaborateurs ayant quitté l'entreprise. Ces situations ont été corrigées, en dégradant les comptes vers de simples droits d'édition (sauf ceux des vrais administrateurs du CMS) et en détruisant les comptes des ex-collaborateurs.

Bilan

La défense statique reste une bonne chose, même si elle ne suffit pas dans tous les cas, loin s'en faut. Qu'est-ce qui a sauvé cette entreprise ?

1. une bonne politique de choix de mots de passe, respectée par les utilisateurs du site Web.
2. des sondes sur le fonctionnement du serveur, qui ont permis de lever l'alerte sur la charge système.

Autant le premier point relève clairement de la sécurité du système d'informations, autant le second est plutôt du ressort de l'exploitation. Il ne faut jamais négliger l'importance de l'exploitation des systèmes dans la gestion de leur sécurité : les exploitants (comme les utilisateurs) sont souvent les premiers à relever un dysfonctionnement ou une situation inhabituelle.

Malgré tout, le boulet n'est pas passé loin. Il aurait suffit d'un seul compte avec un mot de passe faible, par rapport aux 52000 premières tentatives, pour que l'attaque réussisse. Qu'avait donc oublié notre nouveau client ?

1. La page de connexion administrative était accessible à tous les internautes. La seule protection était donc la qualité des mots de passe, heureusement plutôt bonne. Cependant, un seul niveau de sécurité, ce n'est justement qu'un seul niveau de sécurité. L'accès administratif, qui n'est maintenant possible que depuis le réseau interne, ajoute une nouvelle couche de sécurité : un malveillant doit d'abord prendre le contrôle d'un poste interne. Ce n'est pas impossible, c'est seulement plus difficile. Le cas échéant, le système d'informations du client gardant trace de toute la navigation Web, il devrait être plus facile de remonter au poste à l'origine de l'incident.
2. Tous les comptes des utilisateurs du service Web étaient de niveau administrateur avec contrôle total, alors que la majorité des utilisateurs n'ont besoin que d'ajouter des articles et modifier quelques informations dans la base de données. Seuls deux utilisateurs, chargés du maintien opérationnel du système, ont réellement besoin des accès les plus étendus. Tous les autres ont donc été dégradés vers des accès minimaux correspondant effectivement à leurs besoins.
3. Des comptes obsolètes étaient toujours actifs sur le serveur (et disposaient des droits d'administration). Ces comptes ont été éliminés.

Les modifications apportées sont très simples :

1. un durcissement de la configuration du serveur Apache, pour limiter l'accès aux URLs administratives,
2. une modification des procédures de création de comptes sur le CMS, pour ne leur donner par défaut que des droits d'édition,
3. une modification de la procédure de départ d'un collaborateur, pour que son (éventuel) compte sur le CMS soit désactivé.

Il n'y a rien de particulièrement complexe ou onéreux à mettre en place. Cela reste pourtant de la vraie sécurité.