L’analyse de logs : la botte secrète des sysadmins contre les robots malveillants

Prenons l’exemple du CMS le plus répandu, WordPress : l’attaque la plus courante consiste dans un premier temps à multiplier les tentatives de connexion sur la page d’identification, accessible par défaut à l’adresse un-site-wordpress.ovh/wp-login.php. Si le mot de passe utilisé par l’administrateur du site attaqué est trop faible, le robot peut parvenir à le découvrir en s’aidant d’un dictionnaire des passwords les plus utilisés. Et là, c’est le drame : le robot s’authentifie en tant qu’administrateur, envoie une requête HTTP de type POST sur l’éditeur de thèmes de WordPress pour insérer un script malicieux. La brèche est ouverte. L’attaquant dispose alors d’un backdoor pour utiliser l’hébergement compromis à sa guise.

L’infrastructure des services d’Hébergement Web d’OVH reçoit un volume colossal de requêtes. On parle de plusieurs milliards de hits quotidiens, avec des pointes à plusieurs dizaines de millions par minute. Dès lors, identifier un comportement suspect dans cette masse d’informations revient à chercher une aiguille dans une botte de foin.

Tout administrateur système sait qu’il existe une arme précieuse dans ce genre de situation : l’analyse de logs. Ces journaux, où la moindre action relative à votre service d’hébergement est consignée, nous les mettons à votre disposition via https://logs.ovh.net/. Ils servent notamment à calculer vos statistiques de visites. Mais ils peuvent tout aussi bien être exploités pour détecter une attaque par force brute. Si l’on reste sur l’exemple de WordPress, cela se traduirait par :

192.0.2.124 un-site-wordpress.ovh - [12/Sep/2017:00:00:01 +0200] "POST /wp-login.php HTTP/1.1" 200 [...]
192.0.2.124 un-site-wordpress.ovh - [12/Sep/2017:00:00:01 +0200] "POST /wp-login.php HTTP/1.1" 200 [...]
192.0.2.124 un-site-wordpress.ovh - [12/Sep/2017:00:00:01 +0200] "POST /wp-login.php HTTP/1.1" 200 [...]
192.0.2.124 un-site-wordpress.ovh - [12/Sep/2017:00:00:02 +0200] "POST /wp-login.php HTTP/1.1" 200 [...]
192.0.2.124 un-site-wordpress.ovh - [12/Sep/2017:00:00:02 +0200] "POST /wp-login.php HTTP/1.1" 200 [...]
192.0.2.124 un-site-wordpress.ovh - [12/Sep/2017:00:00:02 +0200] "POST /wp-login.php HTTP/1.1" 200 [...]
[...]

Autant de requêtes en si peu de temps ? 192.0.2.124 est vraiment une adresse IP suspecte ! Dans le cas du type d’attaque évoqué précédemment, il est primordial de détecter les comportements suspects durant la phase de scan, alors que le robot n’a pas encore réussi a s’immiscer dans l’hébergement visé.

L’administrateur système, dont la compétence peut se mesurer à son degré de fainéantise, aime l’automatisation. Ne l’imaginez pas à quatre pattes en train de fouiller la botte de foin. Ingénieux lorsqu’il s’agit d’économiser ses efforts, le sysadmin va recourir à un gros aimant pour attirer à lui les fameuses aiguilles. En l’occurrence, l’aimant le plus connu est Fail2ban (pour faire bref : un système qui va bloquer les IP qui tentent de casser la sécurité d’un système).

À l’échelle d’un site, Fail2ban est parfait. À l’échelle de l’infrastructure qui nous préoccupe, c’est malheureusement inenvisageable. Nous travaillons sur des clusters de machines et Fail2ban n’est pas capable de faire de la corrélation entre plusieurs sources, ni d’ingérer un tel volume de données. C’est pourquoi nous avons décidé de mettre à l’épreuve OSSEC-HIDS.

OSSEC-HIDS, comment ça marche ?

OSSEC, pour Open Source SECurity, est un HIDS : Host-based Intrusion Detection System. C’est un ensemble d’outils qui vont travailler de concert pour assurer la surveillance de certains aspects du système d’information et détecter des tentatives d’intrusions. Parmi les nombreux outils proposés par OSSEC-HIDS, on trouve notamment un analyseur de logs en temps réel, un détecteur de rootkits, la surveillance en temps réel de l’intégrité de fichiers système ou encore de processus en cours d’exécution.

Vous êtes libres d’utiliser tout ou partie des outils qu’OSSEC-HIDS embarque, car chacun prend la forme d’un daemon que l’on peut activer ou non. Celui qui nous intéresse particulièrement ici, c’est l’analyse de logs en temps réel.

L’architecture d’OSSEC, de type client/serveur, est assez classique. Ce qui facilite son intégration aux infrastructures existantes : les agents sont chargés de collecter les logs et de les envoyer au serveur, lequel s’occupe du décodage et de l’analyse, dans le but d’établir des corrélations entre les informations extraites, et de déclencher des alertes ou des actions automatiques le cas échéant.

Côté agent, le daemon ossec-logcollector va observer toute modification des fichiers de logs que nous lui demandons de surveiller. Chaque nouvelle ligne est récupérée et transmise au serveur OSSEC-HIDS via un canal sécurisé, géré par le daemon ossec-agentd.

C’est le daemon ossec-remoted, exécuté côté serveur, qui reçoit tous les événements émis par les agents. Il reçoit les logs et les envoie à ossec-analysisd. Ce dernier est quant à lui chargé de décoder chaque ligne qu’il reçoit afin d’en extraire des informations, puis de les comparer aux règles qu’il connaît afin d’en déduire un comportement suspect ou non.

La grande force d’OSSEC-HIDS est que toute la partie décodage et définition de règles se fait grâce à une syntaxe à base de XML très souple, très modulable et donc très puissante. On peut rapidement atteindre un niveau de filtrage très fin.

En fonction de ce qu’OSSEC-HIDS détecte, l’émission d’alertes peut se faire via message électronique (ossec-maild) ou via Syslog-NG (ossec-csyslogd). Enfin le daemon ossec-execd est chargé d’exécuter les active responses, c’est-à-dire les actions automatiques en réponse aux menaces détectées.

Focus sur l’analyse de logs

Nous le verrons un peu plus loin, en fonction du volume d’agents que vous aurez, ossec-analysisd et ossec-remoted auront tendance à être les plus gros consommateurs de CPU, car c’est de cette ressource dont OSSEC-HIDS a besoin pour fonctionner efficacement.

L’analyse de log est découpée en trois étapes :

Le pré-décodage n’est autre que l’extraction d’informations de base de notre ligne de log, comme la date, le nom de la machine émettrice ou encore le nom du programme qui a généré cette ligne. ossec-analysisd sait comment pré-décoder la ligne, car l’administrateur détermine dans la configuration d’OSSEC-HIDS le formatage utilisé par le log en entrée : Syslog, Snort, MySQL, etc.

La phase de décodage est sensiblement la même, sauf qu’ici c’est l’administrateur qui définit les règles de décodage afin d’extraire les informations qui l’intéressent : adresse IP source, utilisateur, ID, etc. Toutes ces informations sont extraites et formatées en interne par OSSEC-HIDS sous forme de champs clé/valeur que les daemons vont s’échanger pour traiter l’événement, jusqu’en bout de chaîne où ossec-execd les passera en argument aux scripts d’active response.

Exploiter OSSEC-HIDS dans le contexte du service d’Hébergement Web OVH

Vous avez compris le principe général de fonctionnement de cet outil. Voyons maintenant comment nous l’avons déployé dans le cadre du service d’Hébergement Web d’OVH.

Premier problème (de taille) : notre infrastructure compte plusieurs milliers de machines. Si nous centralisons le contrôle d’OSSEC sur un seul serveur, il ne tiendrait pas la charge plus de quelques secondes. Nous avons donc fait le choix de déployer un serveur OSSEC-HIDS par cluster, dont le plus gros est composé de plusieurs centaines de machines.

N’ayant pas trouvé de benchmark afin d’estimer au plus juste la puissance nécessaire, nous sommes partis sur un VPS Cloud 3 pour héberger ce premier serveur OSSEC (4 vCores ; 3,1 GHz, 8 Go de RAM). Nous déployons ensuite l’agent sur les machines du cluster, et nous le configurons de manière à ce que seuls les logs d’accès Apache soient transmis. Aucune action ou analyse pour le moment.

On observe clairement la montée en charge progressive du daemon ossec-remoted dans le dernier graphique (courbe orange). Aujourd’hui, ce serveur ingère et analyse quelque 700 millions de lignes chaque jour.

Nous avons donc de la marge sur notre VPS pour commencer à voir ce qu’OSSEC-HIDS a dans le ventre. Nous déployons alors les premières règles d’analyse. Nous restons sur l’idée de départ, c’est-à-dire détecter les tentatives de connexion indésirables sur la page d’authentification de WordPress. L’efficacité du système est directement dépendante des seuils de détection mis en place : à partir de combien de tentatives, et dans quel intervalle de temps donné peut-on considérer qu’une adresse IP est suspecte ? OSSEC-HIDS dispose en effet d’un certain nombre de conditions possibles, que l’on peut combiner à loisir afin de créer les règles désirées.

Le système est en apprentissage constant, et nous affinons régulièrement ces seuils. Voyez plutôt ce que ça donne sur un de nos clusters qui héberge environ 330 000 sites, et pour les attaques par force brute visant WordPress uniquement :

Pour générer cet histogramme, nous avons configuré OSSEC-HIDS afin qu’il envoie ses propres logs vers l’offre Logs Data Platform d’OVH. Toutes ces données sont stockées et triées dans un Elasticsearch. Elles nous permettent aujourd’hui d’identifier de nouveaux comportements suspects, d’observer des attaques que nous n’étions pas capables de détecter auparavant et d’imaginer de nouvelles solutions pour vous protéger de façon toujours plus efficace.

Et ensuite ?

Nous sommes résolus à approfondir notre expertise sur OSSEC-HIDS, car nous sommes convaincus que c’est un outil très prometteur. Nous savons aujourd’hui détecter un large panel d’attaques et identifier les adresses IP qui nous causent le plus de problèmes, pour réagir rapidement si besoin.

Maintenant que nous avons un certain recul sur les différents modes opératoires utilisés par le bots malveillants, nous allons pouvoir déléguer à OSSEC-HIDS la prise de décision sur les actions à entreprendre lorsqu’un comportement suspect est observé.

Cette prise de recul et cette analyse humaine sont nécessaires, et importantes, car le volume de données traité implique forcément la détection de faux positifs. Des faux positifs dont nous nous efforçons évidemment de réduire le nombre au maximum.

Nous allons notamment profiter  de la technologie Armor, qui vous protège déjà d’un certain nombre d’attaques, comme la classique SYN-Flood, pour bloquer les IP suspectes le plus en amont possible de nos infrastructures.

Affaire à suivre, nous vous en reparlerons sans doute !