Pendant des semaines de tentatives d’attaques DDoS, nous ne faisons rien

Nous subissons une attaque DDoS, mais nous ne faisons rien

• Depuis plusieurs semaines, quelqu’un tente une attaque DDoS.
• Il inonde le serveur de millions de requêtes pour essayer de télécharger le fichier de configuration des millions de fois.
• Rien qu’au cours des 5 derniers jours, plus de 800�0 tentatives de téléchargement ont eu lieu, et le fichier de configuration pèse environ 200 MB par téléchargement.
• L’essentiel du trafic provient de l’UE, en particulier d’Allemagne et du Royaume-Uni.
• L’attaque est toujours en cours au moment où cet article de blog est rédigé.

Ce que nous faisons dans cette situation urgente

• Nous ne bloquons pas les adresses IP de l’attaquant.
• Nous utilisons Cloudflare, mais nous n’activons pas le mode "Under Attack".
• Le CPU du serveur reste presque inactif la majeure partie du temps pendant l’attaque.
• En général, nous ne faisons presque rien.

Pourquoi ?

• Le service peut traiter des milliards de requêtes par mois sans problème et sans coûter cher.
• Nous avons environ 8 services API et des bases de données, et ils peuvent gérer des milliards de requêtes par mois, même sans cache.
• Nous avons Cloudflare et une bande passante illimitée.

Comment est-ce possible ?

• Le design de l’application TablePlus est simple, et cette philosophie s’applique aussi aux services backend, maintenus au minimum.
• Nous n’utilisons pas de services tiers comme Vercel ou Netlify. À la place, nous utilisons des serveurs web sans limites.
• Par le passé, le monolithique créait des goulots d’étranglement à cause de VPS/processeurs faibles, mais aujourd’hui, des VPS puissants peuvent traiter des milliards de requêtes par mois sur une seule instance.
• Nous construisons donc un service monolithique pour chaque application. C’est facile à déployer et à maintenir.

Parlons du monolithique

• Nous avons tendance à tout complexifier, mais ce n’est pas un problème tant qu’on ne subit pas de pression ou de contraintes.
• Nous n’aimons pas la complexité, donc nous choisissons le monolithique. Nous intégrons dans un seul service tout ce dont l’application a besoin.
• Le déploiement est simple. Il ne faut qu’un seul fichier de configuration, un build et un déploiement.
• Avec moins de dépendances, il est plus facile de déboguer et d’identifier les goulots d’étranglement.

Un framework web unique en Go ou Rust, s’il est correctement implémenté, peut traiter des milliards de requêtes par mois

• Nous choisissons des frameworks hautes performances.
• Nous indexons la base de données pour réduire le temps de récupération à mesure que le volume de données augmente.
• Nous séparons la base de données principale de la base de données de logs/d’usage afin que les problèmes de performance n’affectent pas le cœur du métier.
• Nous utilisons un reverse proxy puissant comme Nginx pour traiter et répartir les requêtes vers l’API principale.
• Nous plaçons tout derrière Cloudflare et le configurons correctement.
• Nous utilisons un CDN avec protection DDoS.
• Nous ne plaçons pas de gros fichiers à télécharger sur un VPS sans CDN ni cache.

Parlons du déploiement

• Chez TablePlus, nous simplifions au maximum le processus de déploiement.
• Nous n’utilisons ni Docker, ni Kubernetes, ni conteneurs, et aucune configuration d’environnement n’est nécessaire.
• Nous utilisons des binaires. Ils peuvent être copiés puis exécutés comme processus sur un serveur Linux.
• Nous choisissons Go et Rust. Ce sont des langages hautes performances qui peuvent produire des fichiers binaires pour le déploiement.

Mise à jour

• Vercel nous a contactés et a indiqué disposer de fonctionnalités capables de protéger le site dans ce type de situation.
• Avec le contrôle des dépenses, il est possible de définir une limite de dépenses, et il existe un mode de challenge contre les attaques, similaire au mode "Under Attack" de CF.

L’avis de GN⁺

• Cet article souligne l’importance d’une infrastructure robuste et d’une stratégie de déploiement simplifiée pour maintenir un service stable malgré une attaque DDoS.
• Il montre que l’architecture monolithique peut réduire la complexité, simplifier le déploiement et favoriser l’optimisation des performances.
• L’utilisation efficace des services cloud et d’un CDN pour renforcer la résilience face aux attaques DDoS peut aussi servir de bon exemple pour d’autres entreprises.
• Cette approche apporte notamment des pistes pour construire une infrastructure rentable, en particulier pour les startups en phase initiale ou les PME.
• Cependant, une approche monolithique ne convient pas à tous les systèmes ni à toutes les applications ; il est donc important de choisir une architecture adaptée aux besoins et au contexte de chacun.

[GN⁺]

Avis Hacker News

• Résumé du premier commentaire :

  • L’auteur du commentaire estime que se vanter des performances du site est exagéré.
  • « 1 milliard de requêtes par mois » ne représente que quelques centaines de requêtes par seconde, ce qui reste trivial et ne peut pas vraiment être considéré comme une attaque DDoS.
  • Comme le site est derrière un CDN (Cloudflare), il ne semble pas qu’il y ait eu quoi que ce soit de particulier de fait côté performances.
  • Qu’un fichier de 200 Mo soit mis en cache et servi via un CDN est tout à fait normal, et s’en vanter donne l’impression d’une conception inadaptée.

• Résumé du deuxième commentaire :

  • 4 To de trafic mensuel sont difficiles à considérer comme une attaque DDoS.
  • 6 millions de requêtes par mois ne représentent qu’environ 2 requêtes par seconde, et à cette échelle exploiter un service monolithique ne pose aucun problème.
  • On suppose que la plupart des requêtes sont gérées par le cache de Cloudflare au niveau CDN.

• Résumé du troisième commentaire :

  • Le site est un simple site marketing statique, sans forum de discussion, et les retours sont traités via les issues GitHub.
  • Il est étrange de se vanter qu’un déploiement simple puisse gérer des téléchargements de fichiers statiques plusieurs millions de fois par jour.
  • Cloudflare assure toute l’atténuation, et en réalité cela n’est peut-être même pas nécessaire vu le faible volume réel de trafic.

• Résumé du quatrième commentaire :

  • Le trafic supplémentaire décrit ressemble à un « abus insignifiant du service » plutôt qu’à une véritable attaque DDoS.
  • Tant que cet abus ne provoque ni surcoût ni épuisement des ressources, il peut être ignoré.
  • Il est fréquent de constater qu’une grande partie d’une infrastructure à mise à l’échelle automatique n’effectue aucun travail utile, et il est préférable de garder un œil sur le trafic.
  • Il y a une plainte concernant la journalisation : si le stockage des logs est bon marché et abondant, ce n’est pas un problème, mais il serait préférable de classer automatiquement le trafic abusif et de limiter son traitement habituel.

• Résumé du cinquième commentaire :

  • 50 millions de requêtes mensuelles en provenance du Royaume-Uni peuvent correspondre au niveau généré par l’exécution d’un seul script.
  • L’auteur s’attend à ce qu’un serveur Go puisse traiter 250 fois plus de requêtes par seconde sans optimisation particulière.
  • Les conseils en eux-mêmes ne sont pas mauvais, mais leurs chiffres ne constituent pas une preuve de la validité de ces conseils.

• Résumé du sixième commentaire :

  • Distribuer des binaires peut être préférable à l’usage de Docker, mais cela soulève des questions de sécurité concernant l’hôte qui exécute ces binaires.
  • Un service monolithique unique hébergé sur un seul VPS est peu coûteux et intéressant, mais un problème matériel peut entraîner une indisponibilité importante.
  • En regroupant tout dans un service unique, on peut perdre la défense en profondeur, ce qui pourrait permettre un accès au stockage des données en cas de problème de sécurité.

• Résumé du septième commentaire :

  • « 1 milliard de requêtes par mois » est un niveau qu’un seul serveur peut gérer, et un simple script mal conçu peut générer un tel trafic.

• Résumé du huitième commentaire :

  • Il met en doute le fait que plusieurs milliards de requêtes mensuelles puissent être considérés comme une grosse attaque DDoS.

• Résumé du neuvième commentaire :

  • Construire un service monolithique pour chaque application facilite le déploiement et la maintenance.
  • Il suffit de déployer un fichier binaire, sans Docker, Kubernetes, dépendances ni environnement d’exécution.

• Résumé du dixième commentaire :

  • En lisant le titre, il s’attendait à quelque chose de plus important, mais le fait d’être derrière Cloudflare est un élément essentiel.
  • Selon la répartition du trafic, cela pourrait bien fonctionner sur un VPS même sans Cloudflare.
  • Les attaques DDoS de couche 7 venues de Russie atteignent une ampleur telle que les grands fournisseurs échouent en raison de problèmes de capacité.