navigation
Parole d’Expert
par Matthieu BOUTHORS, Chef de Projet Agarik
Nous allons voir comment, au travers des différentes étapes nécessaires à la consultation d’un site internet, certaines vulnérabilités peuvent être présentes ainsi que les approches permettant de combattre ces risques.
Serveur DNS
La première étape lors de la consultation d’un site web est la conversion du nom de domaine (e.g. www.agarik.com) en adresse IP (e.g. 217.174.192.227). Cette étape se fait via une architecture hiérarchisée. Dans notre exemple, les serveurs racines fournissent les adresses des serveurs DNS gérant les .com. Puis ces derniers fournissent à leur tour les adresses des serveurs gérant le sous-domaine agarik.com et ainsi de suite jusqu’à obtenir la correspondance entre www.agarik.com et une adresse IP.
En cas de corruption de données sur un de ces serveurs DNS, il est possible de rediriger l’internaute sur un site malicieux pour, par exemple, lui subtiliser ses identifiants. En cas d’indisponibilité des serveurs DNS, la consultation sera normalement impossible.
Pour lutter contre les indisponibilités, les architectures DNS sont massivement redondées. Les serveurs racines (qui sont les plus stratégiques) ont par plusieurs fois été attaqués sans que Internet soit pour autant bloqué. La redondance a donc parfaitement joué son rôle. Pour lutter contre les corruptions de données, des protocoles tels que DNSSEC sont mis en place afin de valider les données échangées entre les serveurs DNS.
Connexion TCP
Le protocole HTTP s’appuie sur TCP. TCP se limitant au transport des paquets, son rôle est d’établir une session en mode connecté et de s’assurer le bon fonctionnement de celle-ci (renvoi des paquets perdus par exemple). Ce protocole étant maintenant éprouvé, les failles d’implémentations sont de nos jours quasi-inexistantes.
Par contre, la conception du protocole fait que certaines attaques, par déni de service, restent possibles. L’attaque la plus utilisée est le SYN-Flood. Elle consiste à envoyer un paquet pour initier une session “fantôme”, ce qui mobilisera côté serveur / équipement réseaux des ressources. Si ces ressources viennent à être saturées, le site ne sera plus accessible.
Pour combattre ces attaques, il convient d’utiliser des firewalls dimensionnés pour bloquer ces attaques. Il n’est ainsi pas rare de voir des firewalls avec des taux d’utilisation à moins de 10 % en temps normal. Ce “sur-dimensionnement” en temps normal permet d’éviter une saturation des ressources en cas d’attaques.
Serveur HTTP
Le protocole HTTP n’est pas un facteur de risque par lui même, certaines méthodes peuvent éventuellement conduire à des fuites d’informations ou faciliter l’exploitation d’autres failles. Mais il est relativement aisé de s’en prémunir en configurant le serveur HTTP en conséquence. La majeure partie des risques réside donc dans les applications et web services délivrés via HTTP. Ces applications sont intrinsèquement complexes et comportent de multiples points d’entrées éventuellement exploitables par un attaquant.
On distinguera plusieurs types de risques :
– les attaques par déni de service : le but sera de rendre le site inaccessible en chargeant le plus grand nombre de pages possibles. Ces attaques sont relativement peu sophistiquées et peu discrètes, il est donc possible de les détecter et de bloquer les adresses des attaquants en amont des serveurs HTTP.
– les attaques sur les données du site web : l’objectif de ces attaques sera d’accéder aux données (source des pages, base de données des utilisateurs, …) du site afin d’en faire un usage malveillant ou de les modifier. Ces attaques utilisent des failles dans le code du site web et/ou dans les middleware utilisés par le site (PHP, RoR, …). Ces attaques peuvent être effectuées de manière très discrète, pour s’en prémunir, il est donc important de mettre en place des solutions spécifiques appelées WAF – Web Application Firewall (e.g. mod_security sur Apache) tout en n’oubliant pas que ces outils ne pourront jamais bloquer 100% des failles présentes sur une application. Il reste donc important d’effectuer des revues de code et tests de vulnérabilités sur l’applicatif même si celui-ci est “protégé” par un WAF.
– les tentatives de prises de contrôle des serveurs web : l’objectif de ces attaques n’est plus le site hébergé mais les ressources des serveurs qui hébergent ce site. L’application web n’est donc plus la finalité de l’attaque mais juste une étape. Les serveurs sont généralement ensuite utilisés dans d’autres activités illégales. Le point d’entrée de ces attaques restant l’application web, les WAF sont aussi très utiles contre ces attaques.
Comme nous avons pu le voir, le point névralgique d’une plateforme web est l’application hébergée. D’expérience, la plupart des attaques ciblent désormais le contenu (défaçage, exfiltration de données personnelles, …) plutôt que le contenant. Face à ces menaces, il est donc important de penser à la sécurité au niveau de l’applicatif et non plus uniquement au niveau du réseau et des serveurs.