YaCaP : mise en place de protection sur les serveurs web de redirection et les serveurs frontaux (authentication YaCaP, popup,...)

Publié le 2010/03/25 à 14:56:16
Dernière mise à jour le 2010/03/25 à 15:17:13

Depuis le début d'année 2010, les serveurs web qui constituent le cluster YaCaP ont eu à traiter des trafics anormaux et très importants durant des périodes allant de quelques secondes à quelques heures.

Ces trafics anormaux peuvent s'apparenter à des attaques de déni de services, sauf que les sources ne sont pas de "vrais pirates" ou de "vrais utilisateurs mal attentionnés". Le problème peut être expliqué par deux constatations :

  • les serveurs Web YaCaP (les redirecteurs et les frontaux) sont en rupture entre le client et l'internet quand le client n'est pas authentifié
==> ceci entraîne que toute application qui utilise les ports Web (80 et 443) va solliciter les redirecteurs et les frontaux YaCaP tant que le client n'est pas authentifié
  • de nouveaux logiciels ou certains add-ons / plugins de navigateurs utilisent les ports Web (80 et 443) selon des méthodes très brutales : connexions massives, pas de gestion des timeout, (re)tentative infinies, ...
==> ceci entraîne une charge potentiellement très élevées sur les redirecteurs et les frontaux de YaCaP

Afin de maîtriser la charge des serveurs Web YaCaP, l'équipe réseau du CIRIL a mis en oeuvre plusieurs technologies pour :

  • limiter les accès non licites à ces serveurs
  • pour traiter encore plus rapidement les connexions licites

Toutes ces mesures ont pour but de proposer un service toujours plus fiable et performant, et ceci également durant des périodes de charges intensives dû à des logiciels ou à des clients malveillants.

Parmi les techniques mises en oeuvre, on peut énumérer :

  • la limitation du nombre de connexions simultanées par client (nombre max. de connexion TCP / client)
  • la limitation du nombre de connexions par quantum de temps par client (nombre max. de connexion TCP / sec / client)
  • la limitation du nombre de requêtes HTTP par quantum de temps par client (nombre max. requêtes HTTP(S)/sec)
  • l'ajustement des ressources disponibles pour traiter l'ensemble des requêtes (nombre de processus disponibles et stratégie d'ajustement en cas de charge intensive)
  • la limitation des ressources allouées à un client
  • l'accélération des négociations HTTPS (handshake SSL) par l'utilisation d'un nouveau cache SSL
  • la mise en place de supervision spécifique pour le suivi de ces paramètres et de leur impact

Après quelques semaines de tests et d'ajustements, ces techniques sont maintenant en production. Elles ont déjà permis d'absorber des hausses des trafics anormales avec un impact quasi nul sur le service de portail captif.

Après une période d'observation plus longue (quelques semaines à plusieurs mois), nous pensons compléter les mesures mises en place avec de nouvelles autres.

Nous invitons les administrateurs et les utilisateurs à nous faire remonter toutes difficultés qui pourraient être liées à la mise en place de ces limitations.

Le service de portail captif est détaillé sur cette page?.