Kann mir jemand erklären, ob Cloudflare Canonical erpresst hat?
(flyingpenguin.com)- Die öffentlichen Webdienste von Canonical fielen ab dem 30. April 2026 um 16:33 UTC für rund 20 Stunden aus; die Ubuntu-Repository-Endpunkte wurden erst später ebenfalls gestört
- Die pro-iranische Gruppe, die die Verantwortung für den Angriff beanspruchte, gab an, den kostenpflichtigen DDoS-Dienst Beamed genutzt zu haben, der mit Cloudflare-Umgehung und rotierenden Residential IPs wirbt
- Die mit den Beamed-Domains verbundene Registrierungs- und Routing-Infrastruktur führt in den Aufzeichnungen zu Cloudflare AS13335, Immaterialism, AS39287 und Materialism s.r.l.
- Die Neuzuweisung von AS39287 und die Erneuerung der Apex-Zertifikate von Canonical für archive.ubuntu.com und security.ubuntu.com erfolgten am 27. Februar 2026 innerhalb desselben 24-Stunden-Fensters
- Während des Angriffs verlagerte Canonical nur security.ubuntu.com und archive.ubuntu.com zu Cloudflare; in den öffentlichen Aufzeichnungen erscheint damit statt eines Lösegelds ein Wechsel zu einem kostenpflichtigen Abonnement
Ausfall bei Canonical und Wechsel zu Cloudflare
- Am 30. April 2026 um 16:33:37 UTC markierte das Monitoring-System von Canonical blog.ubuntu.com als Service Down; innerhalb von etwa 10 Minuten fielen auch ubuntu.com, die Security-Advisory-API, das Entwicklerportal, die Unternehmensseite und die Bildungsplattform aus
- Die Störung dauerte rund 20 Stunden und wurde am 1. Mai 2026 um 12:44 UTC als Service Restored vermerkt
- Die Gruppe, die die Verantwortung für den Angriff beanspruchte, stellte sich als Islamic Cyber Resistance in Iraq bzw. 313 Team vor, eine pro-iranische Gruppe, und erklärte, einen kostenpflichtigen Dienst eingesetzt zu haben
- Das als Angriffswerkzeug genannte Beamed ist ein kommerzieller Denial-of-Service-Dienst, der unter mehreren TLDs verkauft wird; beamed.su dient als Marketing- und Blog-Seite, beamed.st als Kunden-Login-Portal
- Ein Blogeintrag von Beamed aus dem April 2026 wirbt mit „Cloudflare-Umgehung“ und nennt drei Techniken, darunter rotierende Residential IPs und manuelles „endpoint hunting“, um den Origin-Server zu finden
- Noch eine Woche nach dem Angriff waren beamed.su und beamed.st online; beide lösten auf Cloudflare-AS13335-Adressen auf
- Auch die beiden Repository-Endpunkte von Canonical, security.ubuntu.com und archive.ubuntu.com, verwendeten danach Cloudflare-AS13335-Adressen
Beamed und die Registrierungs- und Routing-Infrastruktur
- Die Kundendomains von Beamed wurden über einen Registrar namens Immaterialism Limited registriert, der Domainregistrierungen zu Festpreisen und per JSON-API anbietet
- Immateriali.sm wird über die Cloudflare-Nameserver tani.ns.cloudflare.com und trey.ns.cloudflare.com proxied
- Immaterialism Limited ist im britischen Companies House unter der Firmennummer 15738452 eingetragen und wurde am 24. Mai 2024 gegründet
- Bei der Gründung war die Direktorin Nicole Priscila Fernandez Chaves aus Costa Rica; verwendet wurde eine Massenbriefkastenadresse in der Great Portland Street in London
- Am 11. April 2025 schied Fernandez Chaves als Direktorin aus, behielt aber mehr als 75 % wirtschaftliches Interesse; am selben Standort wurde die in Großbritannien ansässige Naomi Susan Colvin als Nachfolgerin bestellt
Die Neuzuweisung von AS39287 am 27. Februar 2026
- Am 26. Februar 2026 reichte Immaterialism Limited beim Companies House am selben Tag zwei Änderungen ein
- Wechsel des eingetragenen Sitzes von 85 Great Portland Street zu 167-169 Great Portland Street
- Änderung der Angaben zu Fernandez Chaves als person with significant control
- Am folgenden Tag, dem 27. Februar 2026, wechselte die Routing-Infrastruktur, die den IP-Raum von Beamed und verbundenen Diensten ankündigte, die Zuständigkeit
- Das autonome System, das den Adressraum von Materialism ankündigt, ist AS39287; RIPE wies diese AS-Nummer am 24. Januar 2006 zu
- Die Routing-Identität von AS39287 blieb erhalten, aber der registrierte Betreiber und die Länderangaben änderten sich zweimal
-
Zeit von Privactually Ltd und FLATTR-AS
- Etwa von 2017 bis 2020 wurde AS39287 von der zyprischen Firma Privactually Ltd gehalten und unter dem Namen FLATTR-AS betrieben
- Flattr ist mit dem Micropayment-Projekt von Peter Sunde Kolmosoppi, einem der Mitgründer von The Pirate Bay, verbunden
- Der Abuse-Kontakt für Präfixe unter dieser Registrierung war abuse@shelter.st
-
Zeit von ab stract ltd
- Von 2020 bis 2026 wurde dieselbe AS-Nummer an die finnische Firma ab stract ltd in Urho Kekkosen katu 4-6E, Helsinki, neu zugewiesen
- Das Maintainer-Objekt in den RIPE-Aufzeichnungen war BKP-MNT; als Person war dort Peter Kolmisoppi, ein weiterer Gründer von The Pirate Bay, eingetragen
- Die autoritativen Nameserver der Betreiberdomain abstract.fi waren die drei Njalla-Nameserver njalla.fo, njalla.no und njalla.in
- Njalla ist ein von Peter Sunde gegründeter Privacy-as-a-Service-Domain-Proxy, betrieben über 1337 Services LLC in St. Kitts und Nevis
-
Neuzuweisung an Materialism s.r.l.
- Am 27. Februar 2026 um 12:11:48 UTC verzeichnete RIPE die dritte Neuzuweisung, und AS39287 ging an Materialism s.r.l. in Bulevardul Metalurgiei, Bukarest, Rumänien
- Die Neuzuweisung umfasste 45.158.116.0/22, 2001:67c:2354::/48 und 2a02:6f8::/32; das letzte IPv6-Präfix war im vorherigen Regime erstmals im August 2008 zugewiesen worden
- Während aller drei Übergänge blieben die Peering-Einstellungen erhalten; AS39287 setzte Import/Export mit AS42708 (Telia), AS37560 (GTT), AS12552 (GlobalConnect), AS34244 (Voxility) und AS54990 in derselben Konfiguration fort
- Dieselben Routen gingen zu denselben Upstream-Netzen; in den öffentlichen Aufzeichnungen änderte sich nur der sichtbare Betreibername
- In IANAs Liste akkreditierter Domain-Registrare taucht Immateriali.sm mit 1337 Services LLC auf, der Transaktionsgesellschaft hinter Njalla innerhalb des Kundenstamms
Zertifikatsrotation bei Canonical am selben Tag
- In den Certificate-Transparency-Aufzeichnungen für die Repository-Endpunkte von Canonical erscheinen mehrere Einträge innerhalb desselben 24-Stunden-Fensters, in dem auch die Routing-Neuzuweisung stattfand
- Am 27. Februar 2026 um 06:14:03 UTC stellte Let’s Encrypt ein neues Apex-Zertifikat für archive.ubuntu.com aus
- Am selben Tag um 19:13:35 UTC stellte Let’s Encrypt ein neues Apex-Zertifikat für security.ubuntu.com aus
- Vor diesem Eintrag gab es in den CT-Logs von 2026 für security.ubuntu.com nur Zertifikate für regionale Mirror; ein früheres sichtbares Apex-Zertifikat erscheint dort nicht
- Am selben Tag um 22:14:03 UTC wurde ein neues Zertifikat für clouds.archive.ubuntu.com ausgestellt
- In den folgenden neun Tagen wiederholte sich dasselbe Muster bei azure.archive.ubuntu.com, wildcard-gce.archive.ubuntu.com und wildcard-ec2.archive.ubuntu.com
- Jedes der neuen Zertifikate wurde für einen Apex-Hostnamen und nicht für einen regionalen Mirror ausgestellt
- Ein gültiges Origin-Zertifikat für einen Apex-Hostnamen gilt als Voraussetzung dafür, diesen Hostnamen hinter ein Content Delivery Network zu stellen
- Die Gleichzeitigkeit von Routing-Neuzuweisung und Zertifikatsrotation bei Canonical am 27. Februar 2026 wird durch die öffentlichen Aufzeichnungen allein nicht erklärt
Zeitachse des Angriffs
- Die Zeitachse basiert auf den minutengenauen Ausfallprotokollen der Seite status.canonical.com, die am 30. April gegen 22:52 UTC als Snapshot im Ubuntu-Discourse-Thread 81470 erhalten blieben
-
Die ersten 10 Minuten: Ausfall weiter Teile der öffentlichen Webpräsenz
- 16:33:37: blog.ubuntu.com wird erstmals als Down markiert und als Incident Start Time vermerkt
- 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
- Die Security-Advisory-Feeds fielen innerhalb von 3 Minuten nach Beginn aus; die Marketing-Apexes innerhalb von 10 Minuten
- Zu diesem Zeitpunkt noch nicht betroffen waren security.ubuntu.com und archive.ubuntu.com; diese beiden Endpunkte sind Repository-Endpunkte, die auf allen Ubuntu-Installationen ein Scheitern von
apt updateauslösen können
-
Drei Stunden später Angriff auf die Repository-Endpunkte
- 19:34:38: security.ubuntu.com wird erstmals als Down markiert
- 19:40:01: archive.ubuntu.com Down
- Die Repository-Endpunkte fielen erst etwa 3 Stunden nach Beginn des Angriffs aus
- Ab 19:40 UTC wechselten die beiden Repository-Endpunkte in den nächsten 70 Minuten auf der Statusseite wiederholt zwischen Down und Operational
- Das Statusprotokoll verzeichnet in diesem Zeitraum 5 Wechsel bei security.ubuntu.com und 4 Wechsel bei archive.ubuntu.com zwischen Down und Operational
- Dieses Muster passt zu Versuchen, am Origin Gegenmaßnahmen wie Rate Limiting, regionale Filter oder Traffic Scrubbing einzusetzen, die jedoch unter der behaupteten Dauerlast von 3,5 Tbps scheiterten
-
Stabilisierung nach 20:50 UTC
- 20:50:29: archive.ubuntu.com Operational
- 20:51:13: security.ubuntu.com Operational
- Nach diesem Abstand von 44 Sekunden erscheinen beide Hosts im bis 22:52 UTC reichenden Snapshot nicht mehr als Down
- Das Flapping hörte auf; beide Endpunkte stabilisierten sich gemeinsam in weniger als einer Minute Abstand 4 Stunden und 17 Minuten nach Angriffsbeginn
- security.ubuntu.com und archive.ubuntu.com lösen zum Zeitpunkt des Schreibens auf 104.20.28.246 und 172.66.152.176 auf; diese Adressen werden von Cloudflare in AS13335 betrieben
- Andere betroffene Hosts wie ubuntu.com, canonical.com, launchpad.net, snapcraft.io und login.ubuntu.com lösen weiterhin auf den AS41231-Adressraum von Canonical auf, also 185.125.189.x und 185.125.190.x
- Die autoritativen Nameserver von ubuntu.com bleiben ns1.canonical.com, ns2.canonical.com und ns3.canonical.com
Selektiver Wechsel zu Cloudflare
- Canonical verlagerte nur die beiden A-Records security.ubuntu.com und archive.ubuntu.com, auf die der Angreifer für die Repository-Blockade zielte, zu Cloudflare
- Alle übrigen Dienste blieben auf der eigenen Infrastruktur von Canonical und hielten dem Angriff unter den bestehenden Gegenmaßnahmen stand
- Nicht-Repository-Hosts flackerten bis zum Ende des Snapshots weiter und erholten sich danach durch eine Kombination aus Upstream-Filtering sowie Abwehr oder Abbruch des Angriffs
- Die erste öffentliche Bestätigung von Canonical erschien am 1. Mai um 07:13 UTC, also 10 Stunden nachdem sich die Repository-Endpunkte hinter Cloudflare stabilisiert hatten
- Die vollständige Wiederherstellung aller Komponenten wurde am 1. Mai um 12:44 UTC bestätigt, also rund 20 Stunden nach Beginn des Angriffs
Die Struktur hinter der Frage der „Erpressung“
- In dem öffentlich nachvollziehbaren Pfad ist keine Lösegeldzahlung zu sehen
- Auch kein Kryptofluss dieser Größenordnung erscheint in den öffentlichen Aufzeichnungen
- Ein Forderungsschreiben wurde nicht veröffentlicht; falls es Verhandlungen gab, liefen sie vermutlich nicht öffentlich ab
- Was sich in den öffentlichen Aufzeichnungen bewegt, ist ein kostenpflichtiges Abonnement
- Die beiden wertvollsten Endpunkte von Canonical, also die Repository-Endpunkte, die weltweit Ausfälle automatischer Sicherheitsupdates verursachen können, wechselten in eine Dienstbeziehung mit Cloudflare
- Gleichzeitig gehören zu den anderen aktuellen Kunden von Cloudflare auch die Booter-Betreiber, die Canonical angriffen
- Dass Beamed weiter anmietbar blieb und die Ausfallzeit der Canonical-Infrastruktur wie eine Frist wirkte, lässt die Struktur als ein Geschäft ohne gesondert veröffentlichte Forderung erscheinen
- Der Schützer erzielt Einnahmen von beiden Seiten und bleibt dabei zu jedem Zeitpunkt formal inhaltsneutral und innerhalb des Wortlauts seiner Nutzungsbedingungen
Vergleich mit dem Monopol der Rennbahn-Drahtdienste
- In den 1930er Jahren verkaufte Moses Annenbergs General News Bureau Rennergebnisse von Rennbahnen in den gesamten USA mit hoher Geschwindigkeit an Bookmaker
- Bookmaker mit Abonnement überlebten; über Bookmaker ohne Abonnement hieß es vergleichsweise, sie verlören durch abonnierende Konkurrenten die Fähigkeit, Quoten festzulegen
- Annenbergs Einnahmen beruhten auf einem Monopol über die Verifizierung von Rennergebnissen; dieses Monopol zwang inoffizielle Bookmaker dazu, sich für ihren Betrieb auf seine Drahtdienste zu verlassen
- Die Bundesregierung brach dieses Monopol 1939 mit einer Steueranklage; nachfolgende Wire Services wurden bis in die 1940er Jahre hinein verfolgt
- Ein Bericht von 1942 zu Mayor LaGuardia berichtet, dass neun Personen bei einem Schlag gegen einen „1-Million-Dollar-Wire-Service pro Jahr“ für Rennwettanbieter und Poolroom-Bookmaker in New York, New Jersey, Westchester und Nassau County festgenommen wurden
- Daraus folgt die Kritik, der heutige DDoS-Schutzmarkt befinde sich in einer ähnlichen Position gegenüber dem Booter-Markt
- Die Einnahmen von Cloudflare hängen von einer Position ab, in der das Unternehmen auf dem öffentlichen Internet die Erreichbarkeit eines Dienstes verifiziert; wenn dasselbe Unternehmen zugleich Hosting-Anbieter von Bootern ist, verschmelzen Bedrohungs- und Schutzrolle zu einem einzigen Einnahmestrom
Die in öffentlichen Aufzeichnungen hinterlassenen Spuren
- Die Spuren dieses Vorfalls sind über mehrere Register und Unternehmensoffenlegungen verteilt
- Beim Companies House liegen Unternehmensunterlagen, in der RIPE-Datenbank die Routing-Neuzuweisung, in den Certificate-Transparency-Logs die Daten der Apex-Zertifikatsrotation und auf der Statusseite von Canonical die Zeitpunkte der geänderten Records
- Am 27. Februar 2026 wurden innerhalb desselben Kalenderfensters drei Vorbereitungen abgeschlossen
- Materialism s.r.l. erhielt das Eigentum an AS39287 und dem dazugehörigen alten IPv6-Präfix
- Immaterialism Limited reichte Unterlagen beim Companies House ein
- Auf Seiten von Canonical erneuerten die beiden Apex-Hostnamen, die später hinter ein Content Delivery Network verschoben wurden, ihre Origin-Zertifikate
- Die Vier-Stunden-Spanne zwischen Angriffsbeginn und dem Auftauchen von Cloudflare-Adressen bei den Repository-Hostnamen von Canonical lässt sich als das Zeitfenster lesen, in dem eine Kaufentscheidung bewegt wurde
- Am 30. April 2026 um 20:50:29 UTC wurde die neue Kundenbeziehung öffentlich sichtbar
1 Kommentare
Hacker-News-Kommentare
So wie ich es verstehe, ist die Formulierung, man könne sich bei Cloudflare Angriffskapazität mieten, unzutreffend
Es stimmt zwar, dass die Gruppe ihre Website hinter Cloudflare gehostet hat, aber ich habe keine Behauptung gesehen, dass die Cloudflare-Infrastruktur selbst für den Angriff verwendet wurde
Der ganze Text scheint das Hosting einer vom Angreifer betriebenen Hinweisseite mit dem Hosting des eigentlichen Angriffs zu vermischen
Ob Website oder Kontrollinfrastruktur, alles war ein Angriffsziel
DDoS-Abwehr wurde von Firmen wie Akamai angeboten, der Preis war auf Anfrage, nur für Großunternehmen realistisch, und eine anonyme Anmeldung war völlig ausgeschlossen
Cloudflare hat die Branche verändert, indem es allen kostenlose DDoS-Abwehr anbot, einschließlich DDoS-for-hire-Diensten; als sie einander nicht mehr offline drängen konnten, konnte die DDoS-Industrie erst richtig wachsen
Es scheint auch nicht nur proxied Traffic zu sein; zumindest fehlt der Header
CF-Connecting-IpIch weiß nicht, ob es bei diesem Angriff so war, aber bei manchen Angriffen wird es verwendet
Trotzdem ist Cloudflare weiterhin weit weniger lästig als fast alle anderen Infrastrukturprovider
Ich bin mir auch nicht sicher, ob die Logik überhaupt aufgeht
Es gibt viele bei AWS gehostete Command-and-Control-Server und viele AWS-Opfer; trotzdem würde man kaum sagen, AWS trage dafür Verantwortung oder betreibe Erpressung, und die Antwort ist im Allgemeinen wohl nein
Jeder kann wohl ein paar Websites nennen, die seiner Meinung nach keine Cloudflare-Hosting-Dienste nutzen sollten
Das Problem ist, dass diese Liste bei jedem anders aussieht
Cloudflare sollte alles hosten, bis es eine rechtmäßige Anordnung erhält
Sobald man anfängt, nach irgendeinem vagen Maßstab zu beurteilen, ob Inhalte einer Website „angemessen“ sind, werden die Leute völlig zu Recht sehr wütend
Die Behauptung, man könne sich bei Cloudflare Angriffskapazität mieten, braucht Belege, und soweit ich weiß, verwenden Angreifer die Cloudflare-Infrastruktur nicht für die eigentlichen Angriffe
Der Grundton dieses Textes unterscheidet sich so stark von dem in Beiträgen über Google, dass mich das ziemlich irritiert
Ich bin nicht sicher, ob Cloudflare ein böswilliger Akteur ist, aber ich finde, man sollte sich so verhalten, als wäre es jeder
Wenn ein beworbener Dienst Cloudflare ausdrücklich angreift, sollte das nach vernünftigen Bedingungen natürlich ein Verstoß sein
In den tatsächlichen Cloudflare-Bedingungen steht das auch so
https://www.cloudflare.com/en-ca/website-terms/
Unter „7. PROHIBITED USES“ steht, dass man Websites oder Online-Dienste nicht in einer Weise nutzen darf, die Cloudflare-Server, APIs oder verbundene Netzwerke beschädigen, deaktivieren, überlasten, stören oder beeinträchtigen könnte; außerdem dürfen keine zerstörerischen Inhalte wie Viren, Würmer oder Trojaner übertragen und kein unbefugter Zugriff etwa durch Hacking oder Krypto-Mining versucht werden
Außerdem behält sich Cloudflare das Recht vor, Inhalte im Distributed Web Gateway zu blockieren, die nach eigenem Ermessen rechtswidrig, schädlich oder vertragswidrig sind; dazu gehören auch die Verbreitung von Malware, die Förderung von Phishing und sonstiger technischer Missbrauch
Selbst wenn man die Hinweisseite der Angreifer entfernt, könnten sie einfach zu GitHub Pages oder einem der vielen kostenlosen Hostings für statische Websites wechseln
Meiner Ansicht nach gibt es überhaupt keine Beweise dafür, dass Cloudflare den eigentlichen Angriff ermöglicht hat
Es hat sich nicht entschieden, völlig außen vor zu bleiben
Die Behauptung, man greife nicht ein, sollte als stillschweigende Zustimmung gelesen werden
Denn wir wissen, dass Nutzer, die ihnen genug missfallen, tatsächlich hinausgeworfen werden
Solche Beiträge scheinen auf der seltsamen Annahme zu beruhen, Cloudflare reagiere nicht auf Sicherheitsmeldungen oder rechtliche Anordnungen
Meiner Erfahrung nach reagiert Cloudflare im Branchenvergleich angemessen und relativ schnell
Es könnte proaktiver vorgehen oder den Anmeldeprozess mit mehr Reibung versehen, aber dass es nicht die Rolle der Internetpolizei übernehmen will, ist nachvollziehbar
Ich finde nicht, dass man zum Hosting von Inhalten im Internet Kreditkarte, Telefonnummer und sogar eine Ausweiskopie vorlegen müssen sollte
Sonst haben die anderen Inseln ihre Verbindung getrennt
Strafverfolgung war das letzte Mittel, weil Gerichte sich nicht mit der Geschwindigkeit des Internets bewegen und wegen seines grenzüberschreitenden Charakters niemand staatliche Regulierung von oben wollte
Cloudflare hat Venture Capital genutzt, um teure Dinge kostenlos anzubieten und Marktanteile zu kaufen
Wenn man alle Lebensmittelgeschäfte auf die eigene Insel verlegt, kann man ohne Angst vor Ächtung einen Zufluchtsort für kriminelle Aktivitäten betreiben
Frag einfach Leute, die gegen Botnets, Malware und Online-Betrug kämpfen
Wenn man bei einer Cloudflare-Sackgasse ankommt, muss man einfach aufgeben
Strafverfolgungsbehörden werden keinen Fall mit nur 7.000 infizierten Computern übernehmen, und Cloudflare untersucht das auch nicht selbst und greift nicht ein
Ich tue das tatsächlich auch nicht
Ich hatte genügend Belege geliefert, um eine interne Untersuchung zu starten oder den missbräuchlichen Kunden zu kontaktieren, aber das wurde nicht getan
Bei einem Stresser ist von außen wahrscheinlich nur das Login-Panel sichtbar
Solche Websites werben auch nicht offen damit, was sie tun
Cloudflare positioniert sich selbst als Infrastruktur
Das heißt, man sieht sich nicht als verantwortlich für die Inhalte, die man transportiert
Unter normalen Umständen kann ich zum Schutz meiner Systeme vor schlechten Systemen im Internet auf der IP-Ebene blockieren
Aber Cloudflare proxyt auf der IP-Ebene gute Systeme, schlechte Systeme und alles dazwischen
Normalerweise kann man von kriminellen Organisationen betriebene Websites auf IP-Ebene blockieren oder
abuse@der Organisation kontaktieren, die die Inhalte hostet, um sie sperren oder melden zu lassenCloudflare macht beides unmöglich
Und wenn ich eine Missbrauchsmeldung an Cloudflare sende, gibt es keine Garantie, dass meine Kontaktdaten nicht unverändert an die Partei weitergegeben werden, die ich gemeldet habe
Es hat seinen Standpunkt über Jahre etwas verändert, um verantwortungsbewusster zu wirken, aber im Kern ist es gleich geblieben
Selbst wenn ich eine
abuse@-Meldung an ein hinter Cloudflare verborgenes System senden möchte, kann ich nicht sicher sein, dass sie nicht einfach weitergereicht wird, ohne zu wissen, an wenVerwandter Beitrag von letzter Woche:
„Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers?”
https://news.ycombinator.com/item?id=48025001
Ich mag die Rolle von CF im modernen Internet nicht, aber dieser Beitrag wirkt wie ein Bündel von Spekulationen, das ohne Grundlage Punkte verbinden will, außer dass die Zertifikatserneuerung von Canonical und ein Firmenumzug am selben Tag stattfanden
Es gibt aber eine Randgeschichte, die einen Blick wert ist
Njalla scheint kürzlich still und leise eine Umstrukturierung oder einen Eigentümerwechsel vorgenommen zu haben[1], und Njalla sowie immateriali.sm scheinen verwandte Gesellschaften zu sein[2]
https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...
Wie der Beitrag sehr knapp sagt, schützt Cloudflare Angreifer kostenlos an der Front und stellt den Opfern die Kosten für Abhilfe in Rechnung
DDoS-Abwehrdienste kann man als digitale Schutzgelderpressung sehen, weil ein Anreiz entsteht, Angreifer weiter angreifen zu lassen
Es läuft auf so etwas hinaus wie: „Das Internet ist gefährlich, also zahl uns, damit wir deine Website vor Angreifern schützen, die unsere Gratis-Stufe nutzen“
Selbst ohne aktive Komplizenschaft oder Gewinnbeteiligung ist nicht klar, auf welcher Seite DDoS-Abwehrdienste stehen
Ich stimme der Kritik zu, aber Cloudflare hat DDoS nicht erfunden
Selbst wenn Cloudflare morgen auf magische Weise verschwände, würden AI-Crawler nicht aufhören
Was ist die Alternative? Hoffentlich nicht eine Welt, in der man zum Surfen im Internet einen staatlich ausgestellten Ausweis hochladen muss?
Wie soll das funktionieren, wenn man die relative Anonymität und den globalen Charakter des Internets bewahren will?
Menschen könnten Genossenschaften gründen und die Verteidigung übernehmen, aber es wäre schwierig, das als globalen Akteur zu betreiben
DDoS-Abwehr beruht meist darauf, über ausreichend Überkapazität zu verfügen und zu filtern, daher sind die nötigen Investitionen erheblich
Cloudflare zensiert mutmaßlich legale Inhalte, die durch seine Systeme laufen, im Allgemeinen nicht, wenn auch nicht zu 100 %, wie der Fall The Daily Stormer zeigt[1], und entscheidet sich bewusst dagegen, selbst zum Schiedsrichter über die Rechtmäßigkeit zu werden
[1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
Stimme völlig zu
Cloudflare schützt Betrüger in riesigem Ausmaß, und niemanden scheint das zu kümmern
Kein einziger der Fake-Shops, die ich an Cloudflare gemeldet habe, keine einzige Phishing-Seite hinter Cloudflare wurde abgeschaltet
Nicht eine einzige
Wenn ein Unternehmen Milliarden damit verdient, Menschen zu schützen, sollte es so etwas ernst nehmen
Zum Beispiel klingt eine Kleinklage nach dem Muster „Ich habe 20 Dollar Schaden erlitten und verlange zur Identifizierung des Beklagten die bei Cloudflare hinterlegten Kundenzahlungsdaten, die ausstellende Bank und die Kontonummer“ ziemlich vernünftig
Ich habe noch nicht gehört, dass das jemand versucht hat, aber falls doch, würde ich das Ergebnis gern sehen
Ich halte den jetzigen Zustand für deutlich besser
Ich habe immer gedacht, Ubuntu ging down, weil man die Ubuntu-Server daran hindern wollte, copy.fail zu patchen, damit diese Hackergruppe in der Zwischenzeit möglichst viele Ziele ausnutzen konnte
modprobe(8)-Einstellungen abmildern# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf# rmmod algif_aeadEs könnte Prozesse geben, die diese Funktion nutzen (
lsof | grep AF_ALG), aber soweit ich es verstehe, wird sie nicht breit eingesetzt, sodass das Deaktivieren auf den meisten Systemen kein Problem sein sollteAlle Apex-Server werden ohnehin mit Hochverfügbarkeit konfiguriert sein, damit Lastverteilung erhalten bleibt, also sollten normale Nutzer beim copy.fail-Patch überhaupt nichts merken
Unsere Nutzer haben beim Ausrollen des Patches ebenfalls nichts bemerkt
Das ist keine Erpressung, sondern eher Abzocke
CF hat beides nicht getan
Nach dieser Logik könnte man auch Tastaturhersteller für illegale Handlungen verantwortlich machen, die mit ihren Produkten geschrieben wurden
Einer Organisation, die zur Unterstützung krimineller Aktivitäten eingesetzt wird, weiter Dienste bereitzustellen, ist etwas völlig anderes, und Kunden wegen illegaler Aktivitäten zu kündigen, ist keineswegs umstritten
Wenn du in einem UPS-Paket eine Bombe bekommst, ist das nicht die Schuld von UPS
Aber wenn jemand darauf hingewiesen wird, dass UPS benutzt wird, um Menschen Bomben zu schicken, und UPS trotzdem nichts unternimmt und sogar den Bombenversender zu schützen scheint, trägt es dann nicht zumindest eine gewisse Verantwortung?
In diesem Szenario wäre der „Tastaturhersteller“ eher der Routerhersteller, dessen Geräte Cloudflare kauft, nicht Cloudflare selbst
In dieser Analogie ist Cloudflare eher ein Zeitungsaggregator, der alles Mögliche Dreckige zusammen mit normaler Berichterstattung mitliefert
Unter normalen Umständen könnte man die schmutzigen Zeitungen einfach nicht lesen und es denjenigen überlassen, die sie lesen wollen
Aber in der Cloudflare-Situation haben sich die wichtigsten seriösen Zeitungen alle entschieden, ihre Inhalte über Cloudflare zu veröffentlichen, und wenn problematische Dinge daneben mitveröffentlicht werden, muss man sich an Cloudflare wenden statt an den ursprünglichen Herausgeber
Nur könnte Cloudflare meine Informationen im Voraus unwissentlich an sehr unangenehme Leute weitergeben
Wo sollte man die Grenze ziehen?