Quels mécanismes mettons-nous en œuvre chez Kokiris pour protéger les services web de nos clients ?

Posté le 28 Sep, 2023

Préambule

Le WAF (Web Application Firewall) ne sera pas abordé dans cet article.

Le réseau OVH, un environnement de facto protégé

Notre infrastructure étant sur le réseau d’OVH Cloud, nous héritons directement des mécanismes de sécurité mise en œuvre par celui-ci.

le réseau OVH Cloud est protégé des tentatives de DDOS pouvant atteindre 1.3 Tbit/s ;
tous les équipements sont protégés par une suite d’équipements spécialisés ;
toutes les adresses ip sont par défaut en mitigation automatique ; ce qui veut dire que lors d’une attaque, en quelques secondes les équipements de protection protégeront le flux arrivant sur les serveurs clients. Cette mitigation, automatiquement déclenchée par défaut, peut aussi l’être manuellement sur décision de l’équipe technique Kokiris.

Pré-positionnement d’outils : l’admin-toolkit Kokiris

Nous déployons sur chaque serveur une boîte à outil d’administration, l’admin-toolkit, celle-ci contient une variété de scripts permettant au technicien d’établir si une attaque est en cours puis de la mitiger/bloquer.

L’idée étant de pouvoir prendre le plus rapidement possible une décision qualifiée afin de limiter l’impact de la saturation sur le service client.

~/admin-toolkit# tree -L 2
.
└── admin-toolkit-master-95e8589edd102dc486d028541bf02fbf2f5fb1cb
    ├── README.md
    ├── apache
    ├── archives
    ├── backup
    ├── ftp
    ├── fw
    ├── galipette.sh
    ├── install_rtm_OVH_All.sh
    ├── mysql
    ├── php
    ├── plesk
    ├── ssl
    ├── supervision
    ├── sys
    └── web

Analyse et qualification

Quelles questions se pose l’équipe technique lorsqu’un site web semble attaqué et comment qualifions-nous cet événement ?

Il est difficile de distinguer une attaque par saturation distribuée d’un pic de trafic plus ou moins « légitime », les conséquences étant bien souvent les mêmes.

Dans un premier temps, nous chercherons à qualifier le flux entrant pour ensuite prendre la décision la moins impactante : ne surtout pas bloquer le trafic légitime.

De ce fait nous évaluerons toujours la menace suivant cet ordre :

un pic de trafic suite à une campagne de publicité par exemple
un « browse » sauvage par un crawler quelconque
une attaque par saturation

Que le trafic soit légitime ou non, la conséquence reste la même : le serveur web est saturé et n’accepte plus de connexion

Si nous pensons que le trafic est potentiellement légitime, nous consultons l’historique de performance (métrologie) afin de savoir si le pic s’inscrit dans une variabilité « naturelle » .

Si nous pensons que ce n’est pas le cas ou que l’impact est significatif, nous mettons alors en œuvre des contre-mesures.

Activation des contre-mesures

Si le client possède un reverse-proxy HTTP (HRP Kokiris, normalement activé sur toutes les infrastructures multi-serveurs modernes) en amont, nous actionnons les éléments suivants :

limitation du nombre de connexion simultanée au front-end par adresse IP, par ressource appelée, par domaine, etc. ;

Exemple configuration de « rate limit »

   # rate control
   stick-table type ip size 100k expire 30s store http_req_rate(10s)
   http-request track-sc0 src
   http-request deny deny_status 429 if { sc_http_req_rate(0) gt 20 }

bannissement sur le front-end d’adresses IP selon leurs origines géographiques : géo-blocage ;
en dernier recours, limitation globale de connexion par front-end ou back-end afin d’éviter un effondrement du serveur.

Si le client ne possède pas de reverse-proxy HTTP, les actions suivantes seront réalisées :

sur le firewall, bannissement des adresses IP selon leurs origines géographiques : géo-blocage ;
sur le firewal, limitation du nombre de connexion simultanée par adresse IP unitaire (/32) ou global afin d’éviter un effondrement du serveur.

Auteur : Antonio M.