Quelqu’un peut-il expliquer si Cloudflare a fait chanter Canonical ?
(flyingpenguin.com)- Les services web publics de Canonical ont été interrompus pendant environ 20 heures à partir du 30 avril 2026 à 16:33 UTC, et les endpoints des dépôts Ubuntu sont eux aussi tombés en panne plus tard
- Le groupe pro-iranien qui a revendiqué l’attaque a déclaré avoir utilisé Beamed, un service DDoS payant, qui met en avant le contournement de Cloudflare et la rotation d’IP résidentielles
- L’infrastructure d’enregistrement et de routage liée au domaine Beamed mène à des traces concernant Cloudflare AS13335, Immaterialism, AS39287 et Materialism s.r.l.
- La réattribution d’AS39287 et le renouvellement des certificats apex de Canonical pour archive.ubuntu.com et security.ubuntu.com ont eu lieu dans la même fenêtre de 24 heures, le 27 février 2026
- Pendant l’attaque, Canonical n’a déplacé vers Cloudflare que security.ubuntu.com et archive.ubuntu.com, si bien que, dans les archives publiques, on voit non pas le versement d’une rançon, mais le transfert d’un abonnement payant
Panne de Canonical et bascule vers Cloudflare
- Le 30 avril 2026 à 16:33:37 UTC, le système de supervision de Canonical a marqué blog.ubuntu.com comme Service Down, puis en moins de 10 minutes, ubuntu.com, l’API des avis de sécurité, le portail développeur, le site entreprise, la plateforme éducative et d’autres services web publics ont cessé de répondre
- La panne a duré environ 20 heures et a été enregistrée comme Service Restored le 1er mai 2026 à 12:44 UTC
- Le groupe qui a revendiqué l’attaque s’est présenté comme Islamic Cyber Resistance in Iraq ou 313 Team, un groupe pro-iranien, et a indiqué avoir utilisé un service payant
- Beamed, l’outil pointé du doigt, est un produit commercial de déni de service vendu sur plusieurs TLD ; beamed.su sert de site marketing et blog, tandis que beamed.st sert de portail de connexion client
- Un billet de blog de Beamed publié en avril 2026 fait la promotion du « contournement de Cloudflare » et met en avant trois techniques, dont la rotation d’IP résidentielles et le « endpoint hunting » manuel pour retrouver le serveur d’origine
- Une semaine après l’attaque, beamed.su et beamed.st étaient toujours en ligne, et tous deux résolvaient vers des adresses Cloudflare AS13335
- Les deux endpoints de dépôts de Canonical, security.ubuntu.com et archive.ubuntu.com, ont eux aussi ensuite commencé à utiliser des adresses Cloudflare AS13335
Beamed et l’infrastructure d’enregistrement et de routage
- Le domaine grand public de Beamed a été enregistré via le registrar Immaterialism Limited, qui vend des enregistrements de domaines à tarif fixe et via une API JSON
- Immateriali.sm est proxyfié via les nameservers Cloudflare tani.ns.cloudflare.com et trey.ns.cloudflare.com
- Immaterialism Limited est enregistrée auprès de Companies House au Royaume-Uni sous le numéro de société 15738452, avec une constitution datée du 24 mai 2024
- À la création, l’administratrice était Nicole Priscila Fernandez Chaves, du Costa Rica, avec une adresse de boîte postale de masse à Great Portland Street, Londres
- Le 11 avril 2025, Fernandez Chaves a quitté son poste d’administratrice tout en conservant plus de 75 % d’intérêt économique, et Naomi Susan Colvin, résidente britannique à la même adresse, a été nommée administratrice remplaçante
Réattribution d’AS39287 le 27 février 2026
- Le 26 février 2026, Immaterialism Limited a déposé le même jour deux modifications auprès de Companies House
- Changement de siège social de 85 Great Portland Street à 167-169 Great Portland Street
- Modification des informations de Fernandez Chaves en tant que person with significant control
- Le lendemain, le 27 février 2026, l’infrastructure de routage annonçant l’espace IP utilisé par Beamed et les services associés a changé de juridiction
- Le système autonome annonçant l’espace d’adressage de Materialism est AS39287, un numéro attribué par le RIPE le 24 janvier 2006
- L’identité de routage d’AS39287 est restée la même, mais les archives sur l’opérateur enregistré et le pays ont changé à deux reprises
-
Période Privactually Ltd et FLATTR-AS
- D’environ 2017 à environ 2020, AS39287 a été détenu par la société chypriote Privactually Ltd et exploité sous le nom FLATTR-AS
- Flattr est lié au projet de micropaiement de Peter Sunde Kolmosoppi, l’un des cofondateurs de The Pirate Bay
- Sous cet enregistrement, le contact abuse des préfixes était abuse@shelter.st
-
Période ab stract ltd
- De 2020 à 2026, le même numéro AS a été réattribué à la société finlandaise ab stract ltd, située Urho Kekkosen katu 4-6E à Helsinki
- Dans les archives RIPE, l’objet maintainer était BKP-MNT, et la personne mentionnée dans le dossier était Peter Kolmisoppi, un autre fondateur de The Pirate Bay
- Les nameservers autoritatifs du domaine opérateur abstract.fi étaient les trois nameservers Njalla : njalla.fo, njalla.no et njalla.in
- Njalla est un service de proxy de domaines privacy-as-a-service créé par Peter Sunde et exploité via 1337 Services LLC à Saint-Christophe-et-Niévès
-
Réattribution à Materialism s.r.l.
- Le 27 février 2026 à 12:11:48 UTC, le RIPE a enregistré une troisième réattribution, et AS39287 est devenu la propriété de Materialism s.r.l., située Bulevardul Metalurgiei à Bucarest, en Roumanie
- La réattribution comprenait 45.158.116.0/22, 2001:67c:2354::/48 et 2a02:6f8::/32, ce dernier préfixe IPv6 ayant été attribué initialement en août 2008 sous le régime précédent
- Pendant les trois périodes de transition, la configuration de peering est restée inchangée, et AS39287 a continué à importer/exporter avec la même configuration vers AS42708 (Telia), AS37560 (GTT), AS12552 (GlobalConnect), AS34244 (Voxility) et AS54990
- Les mêmes routes continuaient à sortir via les mêmes réseaux upstream, et dans les archives publiques, seul le nom visible de l’opérateur changeait
- Dans la liste des registrars accrédités de l’IANA, la base client d’Immateriali.sm inclut 1337 Services LLC, l’entité commerciale derrière Njalla
Rotation des certificats Canonical le même jour
- Les archives de transparence des certificats des endpoints de dépôts Canonical montrent plusieurs entrées dans la même fenêtre de 24 heures que la réattribution du routage
- Le 27 février 2026 à 06:14:03 UTC, Let’s Encrypt a émis un nouveau certificat apex pour archive.ubuntu.com
- Le même jour à 19:13:35 UTC, Let’s Encrypt a émis un nouveau certificat apex pour security.ubuntu.com
- Dans les archives de transparence des certificats 2026 pour security.ubuntu.com, avant cette entrée, on ne voyait que des certificats de miroirs régionaux, sans certificat apex antérieur visible dans les logs
- Le même jour à 22:14:03 UTC, un nouveau certificat a été émis pour clouds.archive.ubuntu.com
- Au cours des neuf jours suivants, le même schéma s’est répété pour azure.archive.ubuntu.com, wildcard-gce.archive.ubuntu.com et wildcard-ec2.archive.ubuntu.com
- Chacun de ces nouveaux certificats a été émis pour des hostnames apex, et non pour des miroirs régionaux
- Un certificat d’origine valide pour un hostname apex est présenté comme une condition préalable pour placer ce hostname derrière un réseau de diffusion de contenu
- La simultanéité entre la réattribution du routage du 27 février 2026 et la rotation des certificats chez Canonical n’est pas expliquée par les seules archives publiques
Chronologie de l’attaque
- La chronologie repose sur les logs de panne à la minute figurant sur la page status.canonical.com, conservés dans un snapshot du fil Ubuntu Discourse 81470 vers 22:52 UTC le 30 avril
-
Les 10 premières minutes : panne générale du web public
- 16:33:37 : blog.ubuntu.com est marqué Down pour la première fois et enregistré comme Incident Start Time
- 16:34:10 : canonical.com Down
- 16:34:45 : academy.canonical.com Down
- 16:35:15 : developer.ubuntu.com Down
- 16:35:22 : maas.io Down
- 16:36:09 : jaas.ai Down, Ubuntu Security API (CVEs) Down
- 16:37:13 : Ubuntu Security API (Notices) Down
- 16:41:57 : assets.ubuntu.com Down
- 16:43:25 : ubuntu.com Down
- Les flux d’avis de sécurité sont tombés dans les 3 minutes après le début, et l’apex marketing est tombé en moins de 10 minutes
- À ce stade, les seuls hôtes pas encore touchés étaient security.ubuntu.com et archive.ubuntu.com, les endpoints de dépôts dont l’indisponibilité peut faire échouer
apt updatesur toutes les installations Ubuntu
-
Trois heures plus tard : attaque sur les endpoints de dépôts
- 19:34:38 : security.ubuntu.com est marqué Down pour la première fois
- 19:40:01 : archive.ubuntu.com Down
- Les endpoints de dépôts sont entrés en panne environ 3 heures après le début de l’attaque
- À partir de 19:40 UTC et pendant les 70 minutes suivantes, les deux endpoints de dépôts ont alterné entre Down et Operational sur le tableau d’état
- Le journal d’état enregistre sur cette période 5 bascules Down/Operational pour security.ubuntu.com et 4 bascules pour archive.ubuntu.com
- Ce schéma correspond à l’idée de tentatives de mitigation à l’origine — limitation de débit, filtrage géographique, scrubbing du trafic — qui auraient échoué sous la charge soutenue annoncée de 3,5 Tbps
-
Stabilisation après 20:50 UTC
- 20:50:29 : archive.ubuntu.com Operational
- 20:51:13 : security.ubuntu.com Operational
- Après cet écart de 44 secondes, les deux hôtes ne réapparaissent plus comme Down dans le snapshot capturé jusqu’à 22:52 UTC
- Les fluctuations cessent, et les deux endpoints se stabilisent ensemble à moins d’une minute d’intervalle, 4 heures et 17 minutes après le début de l’attaque
- Au moment de la rédaction, security.ubuntu.com et archive.ubuntu.com résolvent vers 104.20.28.246 et 172.66.152.176, des adresses exploitées par Cloudflare dans AS13335
- Les autres hôtes affectés — ubuntu.com, canonical.com, launchpad.net, snapcraft.io, login.ubuntu.com — résolvent encore vers l’espace AS41231 de Canonical, en 185.125.189.x et 185.125.190.x
- Les nameservers autoritatifs de ubuntu.com restent ns1.canonical.com, ns2.canonical.com et ns3.canonical.com
Bascule sélective vers Cloudflare
- Canonical n’a confié à Cloudflare que les deux enregistrements A visés par l’attaquant pour bloquer les dépôts : security.ubuntu.com et archive.ubuntu.com
- Les autres services sont restés sur l’infrastructure propre de Canonical et ont encaissé l’attaque avec les mesures d’atténuation existantes
- Les hôtes hors dépôts ont continué à fluctuer jusqu’à la fin du snapshot, puis ont récupéré via une combinaison de filtrage upstream et d’atténuation ou d’arrêt de l’attaque
- La première reconnaissance publique de Canonical a été publiée le 1er mai à 07:13 UTC, soit 10 heures après la stabilisation des endpoints de dépôts derrière Cloudflare
- Le rétablissement complet de tous les composants a été confirmé le 1er mai à 12:44 UTC, soit environ 20 heures après le début de l’attaque
La structure derrière la question du « chantage »
- Dans le chemin publiquement vérifiable, aucun paiement de rançon n’apparaît
- Aucun flux de cryptomonnaie d’une telle ampleur n’apparaît non plus dans les archives publiques
- Aucune demande n’a été publiée, et s’il y a eu négociation, elle s’est probablement déroulée en privé
- Ce qui apparaît dans les archives publiques, c’est le transfert d’un abonnement payant
- Les deux endpoints les plus précieux de Canonical, ceux dont l’échec peut provoquer une panne mondiale des mises à jour de sécurité automatiques, ont basculé dans une relation de service avec Cloudflare
- Dans le même temps, parmi les autres clients actuels de Cloudflare figurait aussi un opérateur de booter impliqué dans l’attaque contre Canonical
- Comme Beamed restait disponible à la location et que la durée de panne de l’infrastructure Canonical a fonctionné comme une échéance, la structure peut être interprétée comme une transaction conclue sans demande publique distincte
- Le protecteur tirerait ainsi des revenus des deux côtés tout en restant, à chaque étape, neutre vis-à-vis du contenu et dans la lettre des conditions de service
Comparaison avec le monopole des réseaux télégraphiques hippiques
- Dans les années 1930, le General News Bureau de Moses Annenberg vendait rapidement les résultats des hippodromes aux bookmakers à travers les États-Unis
- La comparaison avancée est que les bookmakers abonnés survivaient, tandis que ceux qui ne l’étaient pas perdaient leur capacité à fixer les cotes face à des concurrents abonnés
- Les revenus d’Annenberg reposaient sur un monopole de la validation des résultats hippiques, monopole qui rendait les bookmakers non officiels dépendants de son wire pour fonctionner
- Le gouvernement fédéral a brisé ce monopole en 1939 par une inculpation fiscale, et les services de wire qui ont suivi ont été réprimés jusqu’aux années 1940
- Un article de 1942 lié au maire LaGuardia rapporte l’arrestation de neuf personnes lors d’une opération visant un « wire service à un million de dollars par an » au service des opérateurs de paris hippiques et des poolroom bookmakers à New York, New Jersey, Westchester et Nassau County
- Cela alimente aujourd’hui la critique selon laquelle le marché de la protection DDoS occupe une position similaire vis-à-vis du marché des booters
- Les revenus de Cloudflare dépendent d’une position où l’entreprise valide si un service est joignable sur l’Internet public, et quand la même entreprise est aussi l’hébergeur d’un booter, menace et protection se retrouvent fusionnées dans un même flux de revenus
Les traces laissées dans les archives publiques
- Les traces de cet épisode restent dispersées entre plusieurs registres et documents d’entreprise
- Chez Companies House, on trouve les dépôts de société ; dans la base RIPE, la réattribution du routage ; dans les logs de transparence des certificats, les dates de rotation des certificats apex ; et sur la page d’état de Canonical, l’heure à laquelle les enregistrements ont changé
- Le 27 février 2026, trois préparatifs ont été menés à bien dans la même fenêtre calendaire
- Materialism s.r.l. a pris possession d’AS39287 et des anciens préfixes IPv6 qui lui étaient attachés
- Immaterialism Limited a déposé ses documents auprès de Companies House
- Côté Canonical, les deux hostnames apex qui seront ensuite déplacés derrière un réseau de diffusion de contenu ont renouvelé leurs certificats d’origine
- L’intervalle de 4 heures entre le début de l’attaque et l’apparition d’adresses Cloudflare pour les hostnames de dépôts Canonical est interprété comme la période où la décision d’achat a basculé
- Le 30 avril 2026 à 20:50:29 UTC, la nouvelle relation client est devenue publiquement visible
1 commentaires
Réactions sur Hacker News
Si je comprends bien, l’expression « louer de la capacité d’attaque auprès de Cloudflare » est inexacte
Le groupe a bien hébergé son site derrière Cloudflare, mais je n’ai jamais vu d’allégation selon laquelle l’infrastructure de Cloudflare aurait servi à l’attaque elle-même
Tout le texte semble confondre l’hébergement d’un site d’information exploité par l’attaquant avec l’hébergement de l’attaque elle-même
Qu’il s’agisse de sites web ou d’infrastructures de contrôle, tout était ciblé
La protection DDoS était fournie par des entreprises comme Akamai, avec un tarif sur devis, réservé aux grandes entreprises et sans aucune inscription anonyme
Cloudflare a changé le secteur en fournissant une protection DDoS gratuite à tout le monde, y compris aux services de DDoS-for-hire, et comme ils ne pouvaient plus se mettre mutuellement hors ligne, l’industrie du DDoS a pu vraiment se développer
Et cela ne semble pas être simplement du trafic proxifié, puisqu’au moins l’en-tête
CF-Connecting-Ipest absentJe ne sais pas si cela a été utilisé dans cette attaque, mais c’est utilisé dans certaines attaques
Cela dit, Cloudflare reste de loin moins pénible que presque tous les autres fournisseurs d’infrastructure
Je ne suis même pas sûr que le raisonnement tienne vraiment
Il y a beaucoup de serveurs de commande et contrôle hébergés sur AWS et beaucoup de victimes d’AWS, mais il est difficile d’en conclure qu’AWS est responsable ou pratique l’intimidation, et la réponse est généralement non
Tout le monde peut citer quelques sites qui, selon lui, ne devraient pas pouvoir utiliser l’hébergement Cloudflare
Le problème, c’est que cette liste n’est pas la même pour tout le monde
Cloudflare doit héberger n’importe quoi tant qu’il n’y a pas d’injonction légale
S’ils commencent à juger, selon un critère flou, si le contenu d’un site est « approprié », les gens auront de bonnes raisons d’être très en colère
L’affirmation selon laquelle ils louent de la capacité d’attaque depuis Cloudflare doit être étayée, et à ma connaissance les attaquants n’utilisent pas réellement l’infrastructure de Cloudflare pour l’attaque elle-même
Le ton général de ce billet est tellement différent de celui des billets sur Google que cela m’a assez déstabilisé
Je ne suis pas certain que Cloudflare soit un acteur malveillant, mais je pense qu’il faut agir comme si tout le monde pouvait l’être
Si le service annoncé attaque explicitement Cloudflare, cela semblerait évidemment violer des CGU raisonnables
C’est bien ce que disent aussi les conditions de Cloudflare
https://www.cloudflare.com/en-ca/website-terms/
La section « 7. PROHIBITED USES » indique qu’on ne peut pas utiliser un site web ou un service en ligne d’une manière susceptible d’endommager, désactiver, surcharger, perturber ou entraver les serveurs, API ou réseaux connectés de Cloudflare, ni transmettre des éléments destructeurs tels que virus, vers ou chevaux de Troie, ni tenter un accès non autorisé par piratage ou minage de cryptomonnaie, entre autres
Elle précise aussi que Cloudflare se réserve le droit de bloquer sur son Distributed Web Gateway des contenus qu’elle juge, à sa seule discrétion, illégaux, nuisibles ou contraires à ses conditions, y compris la diffusion de malwares, l’encouragement au phishing et d’autres formes d’abus techniques
Même s’ils supprimaient le site vitrine de l’attaquant, celui-ci pourrait aller sur GitHub Pages ou sur l’un des nombreux hébergeurs gratuits de sites statiques
À mes yeux, il n’existe absolument aucune preuve que Cloudflare ait rendu l’attaque elle-même possible
Ils n’ont pas choisi de rester complètement à l’écart
Leur prétention à ne pas intervenir doit être lue comme une approbation implicite
Parce que nous savons qu’ils expulsent réellement les utilisateurs qui leur déplaisent suffisamment
Ce genre d’articles semble partir de l’étrange croyance que Cloudflare ne répond pas aux signalements de sécurité ni aux injonctions légales
D’après mon expérience, Cloudflare répond de façon appropriée et relativement rapide par rapport au reste du secteur
Ils pourraient agir de manière plus proactive ou introduire plus de friction à l’inscription, mais leur refus de jouer à la police d’Internet se comprend
Je ne pense pas qu’il faille exiger carte bancaire, numéro de téléphone et copie de pièce d’identité simplement pour héberger du contenu sur Internet
Sinon, les autres îles coupaient leur connexion
Le recours aux forces de l’ordre était une solution de dernier ressort, parce que les tribunaux ne vont pas à la vitesse d’Internet et qu’avec la nature transfrontalière du réseau, personne ne voulait de règles imposées d’en haut par les gouvernements
Cloudflare a utilisé le capital-risque pour offrir gratuitement des choses coûteuses et acheter des parts de marché
Si vous faites en sorte que toutes les épiceries déménagent sur votre île, vous pouvez exploiter un repaire d’activités criminelles sans craindre l’ostracisme des autres
Demandez donc à ceux qui luttent contre les botnets, les malwares ou les escroqueries en ligne
Quand on arrive dans une impasse Cloudflare, il ne reste souvent qu’à abandonner
Les forces de l’ordre ne prendront pas un dossier avec seulement 7 000 machines infectées, et Cloudflare n’enquêtera pas ni n’agira de sa propre initiative
En pratique, moi je ne le fais pas
J’avais pourtant fourni suffisamment d’éléments pour lancer une enquête interne ou contacter le client fautif, mais ils ne l’ont pas fait
Dans le cas d’un stresser, tout ce qu’on verra de l’extérieur sera probablement le panneau de connexion
Ce n’est pas comme si ces sites annonçaient ouvertement ce qu’ils font
Cloudflare se présente comme de l’infrastructure
Cela signifie qu’ils se considèrent comme non responsables du contenu qu’ils transportent
En temps normal, pour protéger mon système des mauvais systèmes d’Internet, je peux les bloquer au niveau IP
Mais Cloudflare proxifie au niveau IP les bons systèmes, les mauvais et tout ce qu’il y a entre les deux
Normalement, on peut bloquer au niveau IP un site exploité par une organisation criminelle, ou contacter le
abuse@de l’organisation qui héberge le contenu pour le faire bloquer ou signalerCloudflare rend les deux impossibles
Et si j’envoie un signalement d’abus à Cloudflare, rien ne garantit qu’ils ne transmettront pas telles quelles mes coordonnées à la partie que j’ai signalée
Ils ont ajusté leur position au fil des années pour paraître plus responsables, mais le fond reste le même
Même si je voulais envoyer un signalement
abuse@au système caché derrière Cloudflare, je ne peux pas être certain qu’ils ne feront pas simplement suivre le message sans que je sache à quiBillet lié la semaine dernière :
« Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers? »
https://news.ycombinator.com/item?id=48025001
Je n’aime pas le rôle de CF dans l’Internet moderne, mais cet article ressemble surtout à un assemblage de spéculations reliant des points sans preuve, au-delà du fait que le renouvellement de certificat de Canonical et le déménagement de l’entreprise ont eu lieu le même jour
En revanche, il y a peut-être une piste annexe à regarder
Njalla semble avoir récemment procédé discrètement à une restructuration ou à un changement de propriétaire[1], et Njalla et immateriali.sm paraissent être des entités liées[2]
https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...
Comme le dit très brièvement l’article, Cloudflare protège gratuitement les attaquants en façade, puis facture les victimes pour le recours
On peut voir les services de protection DDoS comme une forme de racket numérique, avec une incitation à laisser les attaquants continuer
En gros : « Internet est dangereux, alors payez-nous pour protéger votre site contre les attaquants qui utilisent notre offre gratuite »
Même sans complicité active ni partage de revenus, il n’est pas clair de quel côté se place réellement un service de protection DDoS
Je suis d’accord avec le constat, mais Cloudflare n’a pas inventé les DDoS
Même si Cloudflare disparaissait magiquement demain, les crawlers IA ne s’arrêteraient pas
Quelle est l’alternative ? Ce ne sera quand même pas un Internet où il faut téléverser une pièce d’identité émise par l’État pour pouvoir le parcourir ?
Mais si l’on veut préserver l’anonymat relatif et la nature mondiale d’Internet, comment faire ?
Des gens pourraient former des coopératives pour assurer la défense, mais ce serait difficile à faire fonctionner à l’échelle mondiale
La protection DDoS consiste surtout à disposer d’une capacité excédentaire suffisante et à filtrer, ce qui exige des investissements importants
Cloudflare, comme dans le cas de The Daily Stormer[1], ne censure généralement pas les contenus présumés légaux qui transitent par ses systèmes, même si ce n’est pas à 100 %, et choisit de ne pas se poser en arbitre de la légalité
[1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
Tout à fait d’accord
Cloudflare protège des escrocs à très grande échelle et personne ne semble s’en soucier
Les fausses boutiques et pages de phishing derrière Cloudflare que j’ai signalées à Cloudflare n’ont pas été retirées
Pas une seule
Une entreprise qui gagne des milliards en prétendant protéger les gens devrait prendre cela au sérieux
Par exemple, une petite créance du type « j’ai subi un préjudice de 20 dollars et je demande les informations de paiement client fournies à Cloudflare, la banque émettrice et le numéro de compte afin d’identifier la partie à poursuivre en dommages-intérêts » me semble assez intéressante
Je n’ai encore entendu parler de personne qui l’ait tenté, mais si quelqu’un le fait, j’aimerais voir le résultat
À mes yeux, la situation actuelle est bien préférable
J’ai toujours pensé qu’Ubuntu était tombé parce que les serveurs Ubuntu ne pouvaient pas corriger copy.fail, ce qui permettait à ce groupe de hackers d’exploiter un maximum de cibles pendant cette fenêtre
modprobe(8)# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf# rmmod algif_aeadIl peut y avoir des processus qui utilisent cette fonctionnalité (
lsof | grep AF_ALG), mais si j’ai bien compris elle n’est pas largement utilisée, donc la désactiver ne poserait pas de problème sur la plupart des systèmesTous les serveurs apex devraient être configurés en haute disponibilité afin de maintenir l’équilibrage de charge, donc les utilisateurs normaux ne devraient rien remarquer pendant l’application du correctif copy.fail
Nos utilisateurs non plus n’ont absolument rien perçu quand nous avons déployé le correctif
Ce n’est pas de l’intimidation, c’est plus proche de l’extorsion
Et CF n’a fait ni l’un ni l’autre
Avec cette logique, on pourrait dire qu’un fabricant de claviers est responsable des actes illégaux rédigés avec ses produits
Continuer à fournir un service à une organisation utilisée pour soutenir une activité criminelle est très différent, et résilier un client pour activité illégale n’a rien de controversé
Si vous recevez une bombe dans un colis UPS, ce n’est pas la faute d’UPS
Mais si quelqu’un vous informe qu’un expéditeur utilise UPS pour envoyer des bombes aux gens, et qu’UPS ne fait rien, voire semble protéger cet expéditeur, est-ce qu’il n’y a pas une part de responsabilité ?
Dans ce scénario, le « fabricant de claviers » serait plus proche du fabricant de routeurs auprès duquel Cloudflare achète son matériel, pas de Cloudflare lui-même
Dans cette analogie, Cloudflare ressemble davantage à un agrégateur de journaux transportant à la fois des choses sordides et des commentaires normaux
En temps normal, on peut choisir de ne pas lire le journal sordide et laisser ceux qui le veulent décider par eux-mêmes
Mais dans le cas de Cloudflare, les grands journaux légitimes ont tous choisi de publier leur contenu via Cloudflare, donc quand du contenu problématique est publié à côté, on doit s’en prendre à Cloudflare au lieu de s’adresser à l’éditeur d’origine
Et Cloudflare peut en plus transmettre mes informations à des gens extrêmement déplaisants sans que je le sache à l’avance
Où trace-t-on la limite ?