Le réseau était à peine né que déjà il tombait en panne : un câble mal branché, un faux contact ou un clou bien intentionné mais mal planté, furent les premiers coupables du redoutable « Déni de Service » (DOS ou Denial Of Service), synonyme de l’arrêt brutal et total des services du réseau.
Une fois l’architecture physique éprouvée sont venues les premières pannes logicielles s’attaquant aux systèmes (Ping of Death) ou aux applications serveurs (Nimda), pour ne citer que celles qui sont restées dans les mémoires.
La base est maintenant solide
Avec les années et le progrès de la diffusion des mises à jour, on peut maintenant raisonnablement faire confiance à l’ensemble de l’infrastructure pour résister à ces attaques, volontaires ou non, aussi longtemps qu’elles restent isolées.
2017 : plus rien à craindre ?
Pour ce qui des applications Internet, une attaque par Déni de Service Distribué (DDOS ou Distributed Denial Of Service : en clair de multiples machines convergent sur la victime) est toujours à peu prés imparable donc peu de chance qu’elle survienne par accident, ou éventuellement en cas de succès soudain de votre site. Mais dans tous les cas si un pirate décider de s’en prendre à votre site et s’il dispose du contrôle d’un nombre suffisant de machines, rien ne pourra le stopper. Ceci dit, même une attaque concertée ne durera pas car ce type d’attaque mobilise des ressources, certes beaucoup moins que l’on l’imagine en général. Souvent, quelques dizaines ou centaines de machines d’un botnet suffisent pour saturer un serveur, mais dans tous les cas l’attaque cessera après quelques heures.
Un simple DOS
Pour les applications Intranet il reste un ennemi : nos propres utilisateurs.
Le problème est simple : les échanges entre le client et le serveur se font sous la forme de « Questions du client / Réponses du serveur ». Si la réponse du serveur lui coûte plus de temps que celui nécessaire au client pour poser la question, le risque est présent.
Le risque est qu’un seul utilisateur puisse mettre à mal le serveur ! C’est un risque applicatif et le risque est d’autant plus grand qu’un serveur est par essence amené à servir plusieurs clients.
Lutter par l’architecture
Pour cela il faut agir à plusieurs niveaux. Tout d’abord, il faut dimensionner suffisamment le serveur applicatif, le serveur de base de données et la connectivité vers les clients, mais aussi entre les serveurs. Éventuellement, si cela est possible, distribuer les tâches entre plusieurs machines.
Certaines tâches peuvent même être dupliquées : un serveur Web Intranet et un serveur dans la DMZ pour les accès externes ou la mobilité.
Lutter par l’application
Il faut ensuite limiter les capacités de nuisance des comptes utilisateurs : donner un outil de construction de requêtes à un client Web peut s’avérer dangereux, tout autant que des requêtes mal conçues qui pourront non seulement saturer un serveur, mais aussi mettre à mal la patience de l’utilisateur qui dès lors s’acharnera à recharger une page qui n’arrive pas, en décuplant l’impact négatif sur le serveur.
100% de disponibilité… ou pas ?
Nombreux sont ceux qui visent une disponibilité de 99.9% et spécifient un nombre d’utilisateurs démesuré en s’appuyant sur le dicton « trop fort n’a jamais manqué », mais souvent trop fort est aussi trop cher.
Ce qui est important, c’est de traiter la montée en charge, non pas comme un prérequis mais comme une phase de la vie d’un site Web, d’avoir les outils de mesure, d’anticiper la croissance et prendre les « attaques » comme un outil de test comme un autre.
Olivier Piochaud, Président Directeur Général d’Apsynet
