Le réseau est en panne

 

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

Submit your review
1
2
3
4
5
Submit
     
Cancel

Create your own review

Apsynet
Average rating:  
 0 reviews
Catégories : Développement & Web

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *