Les problèmes du site FTV ou quand les Russes se vengent du dernier Major

Par yannis, le 30.06.2016

Bonjour à tous,

Vous avez certainement remarqué une certaine lenteur dans l'accès au site ces derniers jours, qui est devenue une indisponibilité totale hier. Ceci est malheureusement dû à deux attaques simultanées sur le site, dont une que j'ai tardé à identifier.

Les vecteurs d'attaque

La première attaque concernait le serveur de mail que nous utilisons pour vous spammer lorsque vous vous inscrivez et/ou demandez la réinitialisation de votre mot de passe. Le serveur était "public", j'entends par là qu'il ne demandait pas d'identifiant particulier pour émettre des mails. Il était prévu d'utiliser un serveur dédié à la gestion de mails, aussi bien par le site que pour les adresses internes que nous souhaitons créer (@froggedtv.com), ceci va donc connaître une accélération.

La seconde attaque concernait le wiki que nous avions mis en place sur le domaine wiki.froggedtv.com. Cette dernière attaque a consisté en l'ajout massif de pages sans liens les répertoriant depuis l'index. Il en a résulté une augmentation considérable de la base de données du serveur, passant le poids du wiki à plus de 18 Go.

Quand tu ne sais pas configurer ton serveur

Comme je l'ai dit juste avant, la première attaque a pu être effectuée à cause d'une mauvaise config du serveur de mail, qui reste à ce jour pour moi un secteur assez obscur je dois le reconnaître. Etant développeur et non "Admin sys", je n'ai pas pu professionnellement ou personnellement allouer beaucoup de temps à l'apprentissage de ce pan, pourtant très important, de la gestion d'un site.

Cependant cette attaque n'était qu'accessoire en comparaison de celle intervenue sur le wiki. En effet, lorsque j'ai installé notre base de données, j'ai choisi d'utiliser mysql, car c'est le plus rapide à configurer, le plus simple à utiliser, il est gratuit, etc. Tant d'avantages qui font que c'était un choix relativement évident pour un site de cette envergure (comprendre petit). Malheureusement, je n'ai pas pris le temps de configurer proprement mysql et l'ai laissé écrire ses données là où il le fait par défaut. Or, la partition principale du serveur est très petite, contrairement à celle réservée aux datas. De ce fait lorsque l'attaque sur le wiki a eu lieu, le disque a été saturé, mysql a planté, et le site est tombé.

la partition ou se trouvais mysql etais saturé

La partition ou se trouvait mysql était saturée

Pourquoi t'es nul ?

Pourquoi ai-je mis tant de temps à identifier cette attaque ? Et bien, dans un premier temps, celle sur le serveur de mail a été identifiée relativement rapidement et coupée dans les temps (quelques heures après le debut). Cependant celle sur le wiki était relativement vicieuse. Déja, elle concernait l'ajout de pages non référencées dans l'index du wiki, et de ce fait, l'ajout de pages n'était pas flagrant lorsque l'on naviguait sur le wiki.

Deuxièmement, les logs étaient tellement remplis qu'ils étaient à chaque fois automatiquement archivés par le serveur qui rendait par la suite des logs tout propres sans montrer ces attaques qui avaient lieu à des heures bien précises (tôt le matin généralement).

Enfin, l'absence de l'envoi de mail sur mon adresse perso concernant ces alertes, suite à la désactivation du serveur de mail (huhuhu).

Résolution

Pour résoudre cette attaque, j'ai dû couper le serveur de mail (il est toujours coupé actuellement), ce qui comme dit précédemment a favorisé l'efficacité de la deuxième attaque.

Concernant le wiki, j'ai dû déplacer la base de données dans un disque dédié aux données, mais j'ai perdu les données du wiki suite à une corruption de celles-ci lorsque je l'ai relancé (j'ai dû faire du ménage pour pouvoir relancer mysql et faire un export propre).

De ce fait, le wiki est pour l'instant indisponnible, je vais voir quel wiki nous allons choisir de mettre en place, et comment le sécuriser plus efficacement.