Cette page appartient aux archives web de l'EPFL et n'est plus tenue à jour.
This page belongs to EPFL's web archive and is no longer updated.

PolyLAN 4: Debriefing

Historique du déroulement de la LAN:

* vendredi, 3h00: Dans un moment d'inattention, notre développeur web flingue la base de données des inscrits. Le backup planifié pour son serveur de développement n'a pas fonctionné. La plupart des données vitales peuvent être récupérées, à l'exception des n° de tickets des joueurs, que nous finissons par saisir à la main. Moralité: la prochaine fois, plutot que d'utiliser des tickets générés aléatoirements, prendre le hachage du nom du joueur concaténé avec une clef secrète, de manière à pouvoir regénérer les tickets en cas d'accident.

* samedi, 10h00: premier cafouillage, certains nouveaux arrivés semblent ne pas obtenir accès à Internet. La whitelist dynamique d'IPs authentifiées, composant bricolé à la hâte le vendredi soir, est d'abord suspectée. La majorité des joueurs étant déja enregistrée, la whitelist est désactivée, sans succès.
Un examen sommaire du traffic révèle la présence d'une tempête ARP. Les logs du noyau de la passerelle confirment le débordement du cache ARP. Quelques recherches sur le web nous apprennent que l'implémenation ARP de linux ne s'adapte pas a des réseaux de couche 2 importants. Comme mesure provisoire, la taille du cache ARP est augmentée, ce qui atténue légèrement le problème, mais moins que ce que nous attendions.

Les joueurs commencent à se plaindre de problèmes pour l'accès à Internet. Un deuxième examen sommaire indique un nombre important de requètes ARP vers des machines inexistantes, nous indiquant la présence d'un ver sur notre réseau. L'utilisation d'un masque de sous-réseau trop large (classe A) nous aura paradoxalement rendu service, en rendant le réseau inutilisable bien avant qu'un nombre important d'hôtes soient infectés. Nous partons à la chasse aux machines infectées. Nous gravons à la hâte un antivirus sur un CD et le faisons circuler.

Samedi, ~12h ? : L'activité du ver est à son comble, Les switches ne répondent plus. Comme dernier recours, nous abaissons drastiquement le seuil du mécanisme de contrôle de broadcast de nos deux switches principaux. L'accès à internet est immédiatement rétabli, mais au détriment des joueurs cherchant une partie, car la plupart des mécanismes de découverte de partie des jeux actuels font une utilisation intensive du broadcast. Nous profitons de l'accalmie pour retrouver et désactiver les machines responsables. Une fois les machines problématiques déconnectées, devant les demandes des joueurs, nous élevons à nouveau le seuil de contrôle de broadcast.

* Samedi, ~17h00: Off duty jusqu'a dimanche, 06h00. Pendant ce temps, Nitro a identifé la présence d'un autre ver, source de SYN flooding, et a recompilé le noyau de la passerelle avec le support pour les SYNCookies.

Dimanche, 06h00: la situation est calme, j'en profite pour me documenter sur la scalabilité d'ARP sous linux. Les noyaux de nos deux serveurs réseau supportant déja le Netlink et les démons ARP, l'arpd inclus dans le package iproute2 est mis en service manuellement. Le débordement du cache ARP est immédiatement résolu.

08h00: Les joueurs se réveillent progressivement. Une charge inhabituelle de la passerelle nous alerte, nous constatons a nouveau la présence de traffic de scan sur la passerelle. Quelques machines sont identifiées. Nous suspectons une variante de SDBot, non détectée par Stinger, et malgré la recommandation avisée de winsec.epfl.ch, impossible de déployer ePO sur les machine des joueurs. Les dites machines sont isolées, mais trop tard, le réseau est de nouveau saturé...

11h00: Nous gravons un CD contenant le SP2 pour Windows XP, et demandons à tous les joueurs de se mettre a jour. Parallèlement à cela, le traffic a destination du port 445(microsoft-ds), cible de notre ver, est surveillé, et les machines arborant un comportement de scanner sur ce port sont automatiquement isolées.
Concernant l'installation du Service Pack 2, aucun problème de compatibilité n'est signalé avec les jeux utilisés. Les hésitations de certains, conséquence de la mauvaise réputation du SP2, sont vite dissipées par les témoignages d'autres joueurs dans la salle. Seul un récalcitrant contaminé refuse d'interrompre sa partie (de CS, je souiigne) pour mettre a jour et nettoyer sa machine, mais finit par se plier à nos arguments lorsque nous lui expliquons le danger qu'il représente pour le reste du réseau.

Une fois installée l'isolation semi-automatique des machines infectées, plus aucun problème de réseau majeur n'a été signalé chez les participants. (Excepté bien sur chez les personnes concernées.)
Posted by Maxime Augier on Wednesday 2 March 2005 at 19:37