lolloj - Fotolia
La cybersécurité se traite aussi au-delà du pare-feu applicatif
Le pare-feu applicatif est loin d’être le seul élément contributif de la sécurité d’applications et services Web. Hébergeurs et fournisseurs de capacités réseau jouent aussi leur rôle, à plein.
La dimension collective de la sécurité peut être aisément oubliée, ou du moins négligée. Pour autant, elle est bien réelle et le domaine de la protection des applications et des services Web est bien approprié pour en faire la démonstration.
Le Français OVH est ainsi largement réputé pour son système de protection contre les attaques en déni de service distribué (DDoS). Et elles ne sont pas négligeables : début 2018, Akamai indiquait avoir observé une telle attaque par amplification/réflexion, s’appuyant sur le service de base de données en mémoire memcached pour générer un trafic de 1,3 Tbps. OVH avait alors également observé une attaque comparable sur l’un de ses clients. Github avait encaissé de son côté jusqu’à 1,35 Tbps. Netscout mesurait lui 1,7 Tbps. Selon ce dernier, les attaques DDoS coûtent environ 500 M€ à 550 M€ par an aux entreprises françaises, du fait des indisponibilités induites.
Un premier niveau de filtrage essentiel
Sébastien Mériot, responsable du CSIRT d’OVH, revendique un service de protection capable « d’une capacité de 7,2 Tbps pour détecter et mitiger automatiquement les attaques en déni de service distribué ». Il en traite en moyenne 2000 par jour, heureusement bien en deçà de ses capacités.
On retrouve également la protection contre les DDoS chez NBS System, « avec l’aide de multiples partenaires spécialisés dans le domaine ». Mais Emile Heitor, responsable de son département recherche expertise, souligne que l’hébergeur développe en fait deux WAF, CerberHost, et Naxsi, ce dernier étant distribué en open source.
Et CerberHost ne se contente pas de fonctionnalités courantes sur un pare-feu applicatif : « nous contrôlons également les interactions qui ont lieu entre le serveur web et une base de données, détectant une activité anormale vers cette dernière ».
En outre, explique Emile Hector, « pour le cas où l'attaquant tenterait d’exécuter des programmes autres que ceux prévus dans le cadre de l'application web, un autre module de CerberHost détecte et interdit son lancement ».
Enfin, NBS System ajoute à cela un durcissement de la couche de base de la pile logicielle : « parce que le système sur lequel fonctionne le site web fait lui-même partie intégrante de la surface d'attaque, nous durcissons ce dernier avec des techniques de restriction appliquées aux programmes utilisant le système d'exploitation ».
Et complémentaire du WAF
Accessoirement, Sébastien Mériot fait référence à Naxsi, mais également ModSecurity, entre autres, soulignant que « les briques de sécurité intégrées aux solutions proposées par [OVH] sont compatibles avec l’implémentation WAF à l’initiative du client », jusqu’à l’interfaçage avec le pare-feu réseau proposé par l’hébergeur.
Et la complémentarité est claire : « un système de protection tel que l’anti-DDoS d’OVH permet au WAF de gagner en efficacité en éliminant les requêtes bruyantes pouvant altérer les performances ».
Raphaël Maunier, co-fondateur d’Acorus Networks, ne dit pas autre chose. Le Français propose un service de protection des applications web, Cloud Protect, contre les attaques en déni de service, mais aussi les bots malveillants.
Pas question pour autant de se passer de pare-feu applicatif – Acorus propose d’ailleurs un tel module optionnel : « un WAF est souvent nécessaire en bout de chaîne pour traiter certaines attaques applicatives ».
Et il y a une bonne raison à cela : le WAF est « très sensible aux attaques par déni de service, car en analysant finement chaque requête, il est très consommateur de ressources et sera un des premiers éléments à “tomber” lors d’une attaque ». D’où l’importance d’un premier niveau de filtrage, en amont, qu’il s’agisse d’un WAF déployé et administré en interne, ou d’une solution tierce.
