Comment mon chat m’a signalé une attaque DDoS
(dannyguo.com)- À une époque où il n’y avait pas de rotation d’astreinte formelle, un chat a réveillé une personne endormie à 3 h du matin, ce qui lui a permis de voir immédiatement une alerte AWS CloudWatch et la panne du site web
- Après une alerte de unhealthy targets du load balancer, le site ne s’ouvrait plus et un grand volume de requêtes arrivait depuis de nombreuses IP liées à plusieurs pays
- Le produit n’étant proposé qu’aux utilisateurs américains, ce trafic international était anormal et tout indiquait une attaque DDoS
- Bloquer les IP une par une sur le serveur aurait été inefficace, mais une règle de blocage par pays déjà configurée dans AWS WAF a permis de bloquer des centaines de milliers de requêtes pendant environ une heure
- Au moment où l’attaque a commencé, la boîte mail du support client a reçu un message de menace affirmant avoir mis le site à l’arrêt via une vulnérabilité Apache et réclamant 5 000 dollars en Bitcoin ; l’entreprise n’a pas répondu
Une panne révélée à 3 h du matin
- À l’époque, la startup n’avait pas de rotation d’astreinte formelle et l’équipe fonctionnait en surveillant ensemble les alertes urgentes
- Vers 3 h du matin, le chat a réveillé la personne en lui toilettant les cheveux et, en regardant son téléphone, elle a vu qu’une alerte AWS CloudWatch était arrivée quelques minutes plus tôt
- L’alerte était due à des unhealthy targets du load balancer, et le site web ne se chargeait effectivement plus
- Le tableau de bord de monitoring montrait un grand volume de requêtes provenant de nombreuses adresses IP liées à plusieurs pays
- Comme le produit n’était proposé qu’aux utilisateurs américains, ce trafic international était inhabituel et la situation a été identifiée comme une attaque DDoS
Un déluge de requêtes bloqué avec AWS WAF
- La première réponse envisagée a été de bloquer les adresses IP au niveau du serveur, mais cela aurait pu être fastidieux et d’une efficacité limitée si l’attaquant utilisait encore plus d’IP sources
- En s’appuyant sur AWS Web Application Firewall déjà en place, une règle bloquant les requêtes provenant d’autres pays a été ajoutée pour répondre immédiatement à l’incident
- Après l’application de la règle, des centaines de milliers de requêtes ont été bloquées pendant environ une heure et le site web a recommencé à fonctionner
- Le déluge de requêtes s’est également arrêté, ce qui a permis de résoudre l’incident immédiat
L’e-mail de menace arrivé juste après l’attaque
- Ce matin-là, la personne a consulté un e-mail arrivé dans la boîte du support client au moment où l’attaque avait commencé
- L’expéditeur affirmait avoir trouvé une vulnérabilité du site web et fait planter Apache, mais l’entreprise n’utilisait pas Apache
- Il affirmait avoir arrêté tout le trafic du site web et pouvoir maintenir cela pendant plusieurs mois, en exigeant 5 000 dollars en Bitcoin en échange d’un « solution file »
- L’entreprise n’a pas répondu
- Le téléphone était en mode Ne pas déranger pendant la nuit, donc il est peu probable que les vibrations ou le son des alertes AWS aient réveillé le chat en premier
- L’auteur pense que son chat a somehow senti qu’il se passait quelque chose qui ne pouvait pas attendre le matin, et que c’était une façon bien moins désagréable d’être réveillé qu’une alerte PagerDuty
1 commentaires
Avis de Hacker News
Comme toujours, il est facile de passer à côté de la menace interne. Un mail de chantage à la grammaire suspecte ? Une demande de rançon en Bitcoin ? Vous n’avez jamais envisagé que le chat puisse être derrière l’attaque ?
Il n’y a pas beaucoup de séismes au Kansas, mais je me souviens encore du premier et seul que j’aie ressenti.
Je dormais profondément quand mon siamois m’a réveillé en me tapotant le visage avec sa patte, puis il s’est assis au bout du lit en grognant de façon inhabituellement agressive.
Moins de 30 secondes plus tard, ça a commencé à trembler. Je ne sais pas comment il l’a su, mais c’était assez incroyable. Il est parti en 2020 et il me manque encore.
Lors du récent séisme à NYC, on a aussi vu des vidéos de chiens hurlant avant que les gens ne ressentent les vibrations ; ça semble assez courant.
Quand j’ai vécu le séisme de magnitude 7,4 à Taipei il y a quelques semaines, ma seule pensée était que je devais retourner auprès de mon chien, comme promis. Avant que je parte, il était anxieux ; je ne sais pas s’il sentait que je m’en allais ou s’il percevait le séisme vers lequel je me dirigeais.
Dans la roche, il y a deux types d’ondes : les ondes P et S. Les ondes P sont des ondes de pression, donc plus rapides ; les ondes S oscillent latéralement et sont un peu plus lentes. Le chat a très probablement été réveillé par le sifflement des ondes P, qui arrivent un peu avant le séisme que les humains ressentent.
Le fait qu’il existe deux types d’ondes et que les ondes P arrivent en premier est expliqué ici : https://manoa.hawaii.edu/exploringourfluidearth/physical/oce...
Le téléphone était peut-être en silencieux, mais l’écran pouvait continuer à clignoter. Le mien se comporte comme ça dans ce mode.
Dans mon premier boulot, il y avait quelqu’un qui arrivait à repérer les incidents sur le tableau de bord de monitoring avant qu’ils ne se produisent. Il ne pouvait ni expliquer ni comprendre ce qu’il regardait, et personne d’autre ne parvenait à l’imiter, mais quand il disait que quelque chose clochait, une alerte suivait généralement peu après.
J’ai lu un article sur un chef de chantier qui avait gagné le respect des ouvriers parce qu’il repérait anormalement bien les canalisations enterrées ou dans les murs. Au début, il a commencé à croire à des pouvoirs paranormaux, puis il a fini par conclure qu’il avait appris inconsciemment des patterns typiques et des indices parfois contre-intuitifs. Par exemple, voir une bouche d’aération sur le mur d’un bâtiment et en déduire qu’il y avait probablement une conduite d’égout au sous-sol.
J’en étais arrivé à repérer assez précisément le moment où je me disais : « Ce jeu va bientôt planter, je devrais sauvegarder. » Je sauvegardais, je relançais 10 secondes plus tard, et effectivement ça plantait. Je ne sais toujours pas comment je le savais.
5 000 dollars, c’est une somme assez princière. En 2016, notre entreprise a reçu la même demande.
On a subi un DDoS et on a décidé de l’ignorer, même si on avait quand même cherché un peu de BTC au cas où. Ensuite, on a dépensé bien plus que 5 000 dollars à mettre en place un tas de protections anti-DDoS, mais ne pas donner d’argent aux maîtres chanteurs, ça en vaut la peine.
Nous n’avons répondu à aucun mail. Les attaquants étaient aussi assez stupides : ils n’ont attaqué que les serveurs web situés dans un endroit bien connecté.
Le service qui rapportait réellement de l’argent se trouvait dans les Caraïbes, avec seulement un T1 à 1,5 Mbps et un backup satellite à 0,5 Mbps. Il aurait été bien plus facile de le saturer, et plus longtemps ; cela aurait représenté environ 1 million de dollars de manque à gagner par heure.
Donner 5 000 dollars à un attaquant peut sembler moins cher que mettre en place une défense, mais une fois la défense en place, vous avez plus de chances de subir moins d’attaques à l’avenir. Et comme tu l’as dit, ne pas donner d’argent à des criminels a une valeur en soi.
À propos du passage « Je n’ai pas répondu, mais avec le recul, ça aurait été amusant de les troller », ne pas répondre est la seule réponse valable.
Si vous les provoquez, vous risquez surtout de vous faire davantage remarquer et de devenir la cible d’autres attaques. Qu’est-ce que vous y gagnez ?
Mais l’idée était amusante, surtout après avoir vu cette vidéo liée dans l’article : https://www.youtube.com/watch?v=dWzz3NeDz3E
Il y a quelque temps, un membre de ma famille a découvert que le lave-vaisselle fuyait grâce à une alerte chat.
La conclusion, c’est que soit le chat essayait de nous sauver, soit il essayait de nous tuer.
Une personne qui dormait dehors est réveillée par le cri d’un corbeau, au moment même où un grand félin, probablement un tigre, s’approchait furtivement.
Un personnage pense que le corbeau essayait d’avertir la personne ; un autre pense que l’oiseau signalait au tigre la présence du dormeur pour pouvoir manger les restes après le repas.
« Grammaire atroce », ça sent bien l’époque d’avant ChatGPT
Plus sérieusement, est-ce qu’on aura un jour un moyen de bloquer définitivement les attaques DDoS ? Toutes les menaces sont mauvaises, mais le DDoS me semble être le type d’attaque le plus basique. Pas besoin de compétence ou de connaissance particulière : il suffit de lancer un script, ou même de payer quelqu’un qui l’exécutera pour vous comme un service
Les adresses IP — et, en IPv6, les sous-réseaux — sont des ressources limitées pour les utilisateurs ordinaires, tout comme la bande passante. La plupart des attaques par amplification nécessitent de l’usurpation d’adresse IP, ce qui est souvent impossible avec des connexions classiques
Pour une attaque volumétrique, celui qui a le plus de bande passante gagne. L’attaquant peut utiliser l’amplification pour cela. Pour une attaque basée sur la charge ou au niveau applicatif, bloquer les IP des attaquants au niveau du pare-feu peut suffire. Dans ce cas, comme il y avait déjà un WAF/Cloudfront, il s’agit moins d’une attaque purement volumétrique que d’une attaque proche de la couche applicative
Trouver les IP attaquantes à bloquer revient à attribuer précisément le coût à chaque IP source, puis à attribuer aussi précisément le bénéfice lié à l’activité d’utilisateurs légitimes à chaque IP source, avant de bloquer les IP ou plages dont le coût dépasse largement le bénéfice
Ce n’est pas aussi facile que ça en a l’air. Les coûts prennent de nombreuses formes : connexions ouvertes qui monopolisent de la mémoire, handshakes TLS, requêtes coûteuses à parser pour le serveur web, requêtes déclenchant des requêtes de base de données coûteuses, bande passante d’entrée/sortie, etc. C’est pourquoi la plupart des gens mettent Cloudflare — ou, comme ici, Cloudfront — devant, puis contournent le problème avec des règles manuelles comme dans ce cas
Ce serait super d’avoir une façon de rendre la couche protocolaire résistante aux DDoS, mais je ne sais pas trop si c’est possible
Et puis il y a les DDoS volumétriques. On peut les arrêter si l’on dispose de plus de bande passante que tout le monde, mais c’est assez difficile, et on devient soi-même un attaquant potentiel
L’innovation ici consiste à propager des filtres de trafic via BGP. Le null routing en est le produit minimum viable : cette IP est attaquée, donc jetez le trafic vers elle aussi vite que possible. J’ai aussi vu des systèmes plus précis : jeter l’UDP, jeter les paquets fragmentés, jeter les paquets entrants et sortants sur certains ports UDP/TCP, etc.
La plupart de ces systèmes sont conçus pour que les routes spéciales ne se propagent pas directement au-delà des pairs, mais selon les cas, il peut être souhaitable qu’elles se propagent
Si la plupart de mes clients sont au Mexique et que le Canada me lance un DDoS, saturant le lien entre moi et le Canada, ce n’est pas forcément un gros problème. À condition que les routeurs grand public côté Mexique ne se mettent pas en tête d’aider ce goulot d’étranglement canadien
Je pensais qu’il avait connecté la mangeoire du chat aux alertes
En tout cas, c’est mignon. Comment s’appelait le chat ?
Il s’appelait Bamboo. Malheureusement, il est parti d’un cancer. Je l’ai appelé comme ça parce que l’une des premières choses qu’il a faites après son adoption a été d’essayer de manger mon bambou en pot
Sa mangeoire connectée pour chat dépendait d’Internet ; comme la nourriture ne sortait pas, le chat est allé protester auprès de l’administrateur
Ça me fait penser à ce livre : Dogs that Know When their Owners are Coming Home https://www.sheldrake.org/books-by-rupert-sheldrake/dogs-tha...
Bloquer les DDoS avec un seau à jetons est tellement facile que, d’habitude, le seul moment où mon chat doit me réveiller, c’est quand mon Discord se fait raid
Ça ressemble plutôt à une méthode où le pare-feu ou l’ingress jette les paquets qui génèrent une charge excessive avant qu’ils n’atteignent les serveurs applicatifs
Une attaque avec un volume de demandes de connexion ou un nombre d’adresses IP uniques suffisamment élevé peut quand même surcharger le service
Le seau à jetons fait généralement partie d’une stratégie de résilience globale ; ce n’est pas une solution miracle à tous les problèmes de déni de service