OVHcloud Web Hosting Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
probleme sur SLB
Incident Report for Web Cloud
Resolved
Nous avons eu un probleme sur la carte de repartition
de charge SLB. La carte principale a envoyé signal de
panne à la carte de secours alors qu'elle n'avait pas
de probleme. Les 2 cartes ont été en production ce qui
a provoqué une panne de l'hébergement mutualisé et
les offres HA.

Nous avons redemarré la carte principale et la secondaire
est actuellement en production. Le systeme est surchargé
à cause du redemarrage très violent. Sous environ 5 minutes
la situation devrait être à nouveau stable.

Update(s):

Date: 2006-04-29 23:47:33 UTC
Bonjour,
Nous avons reçu aujourd'hui une attaque sur 720plan à partir
de 1h00 du matin. Vers 13h00 l'attaque a saturé le système de
répartition de l'hébergement mutualisé. Il s'agit de l'attaque
de type synflood spoofé sur le port 80 en TCP avec une vitesse
d'environ 100'000 syn/sec. Pour faire simple: 100'000 faux
nouveaux visiteurs par seconde essaient de se connecter sur 720plan.

L'attaque est maîtrisée depuis plusieurs heures et même si nous
la recevons toujours, nous n'enregistrons plus de dégradation
de service. Nous avons mis en place des filtrages efficaces qui
permettent séparer les vraies visiteurs de vos sites de l'attaque.


Explications techniques:
--------------------------
Ce type d'attaque fait parti des attaques les plus complexes à
filtrer pour les hébergeurs, puisqu'il est difficile de distinguer
la vraie connexion du vrai visiteur dans l'ouragan de toutes
les fausses connexions. Nous avons déjà reçu ce type d'attaque à
multiples reprises et depuis des années. C'est toujours un test
que nous avons passé avec plus ou moins de succès à chaque fois.
Depuis 2 ans environ, nous avons décidé prendre devant en passant
le système de répartition de charge sur des cartes SLB de Cisco.
L'objectif était de ne plus avoir à passer de test mais d'avoir
une structure solide qui tient toutes les attaques. En effet, une
carte SLB sait gérer 1'000'000 connexions simultanées et donc cela
constitue une réponse au problème des attaques. Depuis la mise en
production des cartes SLB, nous avons reçu déjà plusieurs dizaines
d'attaques sur la carte SLB sans aucune dégradation sur la qualité
du service. Les parades que nous avons mis en place grâce ces attaques
précédentes ont permit contenir par exemple aujourd'hui l'attaque entre
1h00 et 13h00. Mais l'attaque a été plus importante que les précédentes.
En effet, elle a saturé la SLB à 1'000'000 connexions simultanées à
13h00 et donc la SLB n'acceptait plus des nouvelles connexions pour
l'ensemble des plans et des clients HA.

2 problèmes nous ont trompé dans l'analyse et ont retardé la résolution
du problème: ce Vendredi nous avons transféré le routage de l'hébergement
mutualisé sur 2 nouveaux routeurs qui ne possèdent pas encore le système
de détection d'attaque (il s'agissait d'un test de la future installation
de routage de l'hébergement mutualisé qu'on prépare pour Juin et qui
n'est pas encore fini). Nous avons dû remettre en place le routage
standard en urgence ce qui a provoqué une coupure sur tout le réseau
d'Ovh. Aussi, nous avons mis dans la SLB les nouveaux serveurs (sur le port
81) en vue du futur changement de l'installation. La carte SLB s'est donc
retrouvée avec 2 fois plus des serveurs que d'habitude à vérifier (en temps
normal cela ne pose pas de problème) mais après un reboot, la carte n'arrivait
pas tout vérifier et crash-ait immédiatement. Ces 2 problèmes de circonstances
ont provoqué des retards anormales dans la gestion de l'attaque.

Une fois ces problèmes résolus, nous avons mis en place des solutions en place.
Actuellement l'attaque continue toujours mais il n'y a plus aucun problème
sur aucun hébergement. L'attaque est vérifiée et filtrée en temps réel et
les paramètres que nous avons mis en place permettent filtrer efficacement
les vraies visiteurs de l'attaque.

Même si nous ne sommes pas contents de nous pour la rapidité de résolution
du problème, cette attaque a mis en évidence plusieurs points qui sont
très encouragent:
- La solution hardware que nous avons choisi (SLB de Cisco) permet gérer
ce genre d'attaque avec succès, quelque soit la taille de l'attaque.
Il suffit mettre en place les bons paramètres. Cela prend un peu de temps
pour tester et trouver les bons paramètres en fonction de l'attaque, mais
vu l'expérience d'aujourd'hui, nous pensons être capable d'adapter les
paramètres sans dégradation du service dans le futur. La configuration que
nous avons actuellement en production pour 720plan est déjà appliquée pour
les autres plans et elle permet encaisser déjà une belle attaque.
- La future installation qu'on est en train de préparer sera encore plus
robuste que l'actuelle puisqu'elle permettra distribuer le risque d'une
panne plan par plan. En effet, on prévoit d'utiliser une carte SLB par plan
carrément. Si un plan est éventuellement attaquée et par des problèmes de
circonstances, cela se passe mal, ce plan là uniquement connaîtra une
dégradation de service.

Ce n'est jamais un plaisir de recevoir une attaque, mais cela fait parti
de notre travail de les gérer correctement. Nous ne sommes pas satisfait
de l'expérience d'aujourd'hui. Il faut accepter de ne pas réussir à tous
les coups. Si, vous ne recevez plus ce genre d'email que vous êtes en
train de lire, ça sera la meilleur preuve que nos conclusions tiennent
la route.

Désolé pour les pannes d'aujourd'hui.

Amicalement
Octave


Date: 2006-04-29 18:01:17 UTC
Depuis environ 45 minutes, tout est en fonctionnement sur les
2 cartes de repartition de charge. Nous continuons les travaux
pour eventuellement demarrer un autre systeme de repartition
de charge.

Concernant l'attaque, elle continue. Il s'agit de synflood
spoofé. Normalement, nous avons mis en production les cartes
SLB de Cisco pour palier à ce genre d'attaque. Jusqu'au là
cela fonctionnait.

L'attaque est maitrisée dans la mesure où même 720plan qui
est attaqué reste en fonctionnement. Nous avons appris à
gerer cette attaque, même si cela nous a pris anormalement
beaucoup de temps.



Date: 2006-04-29 16:31:33 UTC
Les 2 cartes SLB ne veulent plus redemarrer du tout. On est
en train de monter un systeme de repartition de charge basé
sur Linux. On pense que dans environ 1h tous les plans vont
être à nouveau up.

Date: 2006-04-29 14:50:10 UTC
720plan est attaqué ce qui provoque que la carte n'arrive pas
gerer les connexions. Nous avons separé 720plan sur la carte
SLB de secours alors tout les autres plans sont sur la carte
principale. Tout est en fonctionnement sauf 720plan qui
reste attaqué.

Date: 2006-04-29 13:47:22 UTC
La carte SLB en production n'arrive pas à stabiliser le nombre
des serveurs que nous avons dans le cluster. C'est à dire qu'en
boucle elle ajoute et enleve les serveurs. La consequence est
que les connexions se coupent et plus rien ne fonctionne.

Nous avons ralongé les temps de checks.

90plan est passé sur la carte SLB de secours. Si ceci n'aide pas
nous allons passer 240plan sur cette carte aussi. Ainsi, on pense
que la carte principale pourra se stabiliser.

Date: 2006-04-29 13:15:19 UTC
La carte en production se coupe au bout d'un serveur temps.
On cherche l'origine du probleme.

Date: 2006-04-29 12:08:29 UTC
La situation est stable désormais.

C'est la 2ème panne sur le systeme de repartition de charge
depuis quelques mois dû au même probleme techniquement.
Visiblement il existe des bugs dans le systeme CSM de Cisco
dans une configuration avec une carte principale et une
carte de secours. La carte de secours recoit l'information
que la carte principale est en panne, alors que ce n'est pas
le cas.

Nous allons donc simplifier la structure de repartition de
charge dans les jours qui viennent. L'objectif est d'avoir
quelque chose de plus simple et donc plus robuste.
Posted Apr 29, 2006 - 11:35 UTC
This incident affected: Web Hosting || Datacenter GRA (Cluster002, Cluster003, Cluster006, Cluster007, Cluster011, Cluster012, Cluster013, Cluster014, Cluster015, Cluster017, Cluster020, Cluster021, Cluster023, Cluster024, Cluster025, Cluster026, Cluster027, Cluster028, Cluster029, Cluster030, Cluster031).