क्या कोई समझा सकता है कि Cloudflare ने Canonical को ब्लैकमेल किया या नहीं?

 (flyingpenguin.com)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Canonical की सार्वजनिक वेब सेवाएँ 30 अप्रैल 2026 16:33 UTC से लगभग 20 घंटे तक बंद रहीं, और Ubuntu repository endpoints भी बाद में बाधित हुए
  • हमले की ज़िम्मेदारी लेने वाले ईरान-समर्थक समूह ने कहा कि उसने पेड DDoS सेवा Beamed का इस्तेमाल किया, जो Cloudflare bypass और residential IP rotation का प्रचार करती है
  • Beamed डोमेन से जुड़ा registration और routing infrastructure Cloudflare AS13335, Immaterialism, AS39287, Materialism s.r.l. के रिकॉर्ड तक जाता है
  • AS39287 reallocation और Canonical के archive.ubuntu.com·security.ubuntu.com apex certificates का renewal 27 फ़रवरी 2026 के उसी 24 घंटे के भीतर हुआ
  • हमले के दौरान Canonical ने केवल security.ubuntu.com और archive.ubuntu.com को Cloudflare पर शिफ्ट किया, और सार्वजनिक रिकॉर्ड में ransom के बजाय paid subscription के शिफ्ट होने जैसी संरचना दिखती है

Canonical outage और Cloudflare migration

  • 30 अप्रैल 2026 16:33:37 UTC पर Canonical की monitoring system ने blog.ubuntu.com को Service Down दिखाया, और लगभग 10 मिनट के भीतर ubuntu.com, security advisory API, developer portal, enterprise site, education platform जैसी सार्वजनिक वेब सेवाएँ भी बंद हो गईं
  • outage लगभग 20 घंटे तक चला, और 1 मई 2026 12:44 UTC पर Service Restored दर्ज हुआ
  • हमले की ज़िम्मेदारी लेने वाले समूह ने खुद को Islamic Cyber Resistance in Iraq या 313 Team के रूप में पेश किया, जो ईरान-समर्थक झुकाव वाला समूह है, और उसने कहा कि उसने पेड सेवा का उपयोग किया
  • हमले के टूल के रूप में बताए गए Beamed को कई TLDs पर बेची जाने वाली commercial denial-of-service सेवा के रूप में बताया गया है; beamed.su marketing और blog site है, जबकि beamed.st customer login portal है
  • Beamed की अप्रैल 2026 की blog post “Cloudflare bypass” का प्रचार करती है, और तीन तकनीकों का दावा करती है, जिनमें residential IP rotation और manual “endpoint hunting” के ज़रिए origin server ढूँढना शामिल है
  • हमले के एक हफ्ते बाद भी beamed.su और beamed.st ऑनलाइन थे, और दोनों Cloudflare AS13335 addresses पर resolve हो रहे थे
  • Canonical के दो repository endpoints security.ubuntu.com और archive.ubuntu.com भी बाद में Cloudflare AS13335 addresses का उपयोग करने लगे

Beamed और registration·routing infrastructure

  • Beamed के consumer-facing domains Immaterialism Limited नामक registrar के ज़रिए registered थे, और यह registrar fixed-fee तथा JSON API आधारित domain registration बेचता है
  • Immateriali.sm को Cloudflare nameservers tani.ns.cloudflare.com और trey.ns.cloudflare.com के माध्यम से proxy किया गया है
  • Immaterialism Limited यूके Companies House में company number 15738452 के तहत registered है, और इसकी स्थापना 24 मई 2024 को हुई थी
  • स्थापना के समय director Costa Rica की Nicole Priscila Fernandez Chaves थीं, और उसने London के Great Portland Street पर bulk mailbox address का उपयोग किया
  • 11 अप्रैल 2025 को Fernandez Chaves director पद से हट गईं, लेकिन 75% से अधिक economic interest बनाए रखा, और उसी पते पर UK resident Naomi Susan Colvin को successor director नियुक्त किया गया

27 फ़रवरी 2026 का AS39287 reallocation

  • 26 फ़रवरी 2026 को Immaterialism Limited ने Companies House में एक ही दिन दो बदलाव दाखिल किए
    • registered office को 85 Great Portland Street से 167-169 Great Portland Street में बदला गया
    • Fernandez Chaves की person with significant control details बदली गईं
  • अगले दिन, 27 फ़रवरी 2026 को, Beamed और संबंधित सेवाओं के IP space की घोषणा करने वाला routing infrastructure jurisdiction बदलता दिखा
  • Materialism के address space की घोषणा करने वाला autonomous system AS39287 है, और RIPE ने यह AS number 24 जनवरी 2006 को assign किया था
  • AS39287 की routing identity बनी रही, लेकिन registered operator और country records दो बार बदले गए

  • Privactually Ltd और FLATTR-AS अवधि

    • लगभग 2017 से लगभग 2020 तक AS39287 Cyprus की कंपनी Privactually Ltd के पास था और FLATTR-AS नाम से operate किया जाता था
    • Flattr को The Pirate Bay के सह-संस्थापकों में से एक Peter Sunde Kolmosoppi के micropayment project से जोड़ा जाता है
    • उस registration के तहत prefixes का abuse contact abuse@shelter.st था

  • ab stract ltd अवधि

    • 2020 से 2026 तक वही AS number Finland की कंपनी ab stract ltd को reassign किया गया, जिसका पता Helsinki, Urho Kekkosen katu 4-6E था
    • RIPE records में maintainer object BKP-MNT था, और listed व्यक्ति The Pirate Bay के एक अन्य सह-संस्थापक Peter Kolmisoppi थे
    • operator domain abstract.fi के authoritative nameservers Njalla के तीन nameservers थे: njalla.fo, njalla.no, njalla.in
    • Njalla Peter Sunde द्वारा बनाया गया privacy-as-a-service domain proxy है, जिसे Saint Kitts and Nevis की 1337 Services LLC के माध्यम से operate किया जाता है

  • Materialism s.r.l. को reassignment

    • 27 फ़रवरी 2026 12:11:48 UTC पर RIPE ने तीसरा reassignment दर्ज किया, और AS39287 Romania के Bucharest, Bulevardul Metalurgiei स्थित Materialism s.r.l. के स्वामित्व में चला गया
    • reassignment में 45.158.116.0/22, 2001:67c:2354::/48, 2a02:6f8::/32 शामिल थे; इनमें आख़िरी IPv6 prefix पुराने सेटअप में पहली बार अगस्त 2008 में assign हुआ था
    • तीनों transition periods में peering configuration जस की तस रही, और AS39287 ने AS42708(Telia), AS37560(GTT), AS12552(GlobalConnect), AS34244(Voxility), AS54990 के साथ वही import/export configuration जारी रखी
    • वही routes वही upstream networks की ओर जाते रहे, और सार्वजनिक रिकॉर्ड में बदला सिर्फ़ दिखने वाला operator name था
    • IANA की accredited domain registrars list में Immateriali.sm के customer base में Njalla के पीछे की transactional legal entity 1337 Services LLC शामिल है

उसी दिन हुआ Canonical certificate rotation

  • Canonical के repository endpoints के certificate transparency records में routing reassignment वाले उसी 24-hour window के भीतर कई entries दिखती हैं
  • 27 फ़रवरी 2026 06:14:03 UTC पर Let’s Encrypt ने archive.ubuntu.com के लिए नया apex certificate issue किया
  • उसी दिन 19:13:35 UTC पर Let’s Encrypt ने security.ubuntu.com के लिए नया apex certificate issue किया
  • security.ubuntu.com के 2026 certificate transparency records में इस entry से पहले केवल regional mirror certificates थे, और visible logs में इससे पहले का कोई apex certificate नहीं दिखता
  • उसी दिन 22:14:03 UTC पर clouds.archive.ubuntu.com के लिए नया certificate issue हुआ
  • उसके बाद 9 दिनों तक यही pattern azure.archive.ubuntu.com, wildcard-gce.archive.ubuntu.com, wildcard-ec2.archive.ubuntu.com पर दोहराया गया
  • हर नया certificate regional mirror के बजाय apex hostname के लिए issue हुआ
  • apex hostname के लिए valid origin certificate को उस hostname को content delivery network के पीछे रखने की पूर्व-शर्त माना जाता है
  • 27 फ़रवरी 2026 को हुए routing reassignment और Canonical certificate rotation की एक-साथ घटना को केवल सार्वजनिक रिकॉर्ड से समझाया नहीं जा सकता

attack timeline

  • timeline Canonical के status.canonical.com page पर मौजूद minute-by-minute outage logs पर आधारित है, जो 30 अप्रैल लगभग 22:52 UTC पर Ubuntu Discourse thread 81470 में snapshot के रूप में बचा था

  • शुरुआती 10 मिनट: सार्वजनिक वेब में व्यापक outage

    • 16:33:37: blog.ubuntu.com पहली बार Down दिखा और 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
    • security advisory feed शुरू होने के 3 मिनट के भीतर गिर गया, और marketing apex 10 मिनट के भीतर गिर गया
    • इस समय तक जिन hosts पर हमला नहीं हुआ था, वे security.ubuntu.com और archive.ubuntu.com थे; ये दोनों ऐसे repository endpoints हैं जिनसे सभी Ubuntu installations में apt update fail हो सकता है

  • 3 घंटे बाद repository endpoints पर हमला

    • 19:34:38: security.ubuntu.com पहली बार Down दिखा
    • 19:40:01: archive.ubuntu.com Down
    • repository endpoints हमले की शुरुआत के लगभग 3 घंटे बाद प्रभावित हुए
    • 19:40 UTC से अगले 70 मिनट तक दोनों repository endpoints status board पर Down और Operational के बीच बार-बार बदलते रहे
    • status logs में इस अवधि के दौरान security.ubuntu.com के Down/Operational transitions 5 बार और archive.ubuntu.com के transitions 4 बार दर्ज हुए
    • यह pattern origin पर rate limiting, regional filtering, traffic scrubbing जैसी mitigations की कोशिश, लेकिन घोषित 3.5 Tbps के sustained load के नीचे उनके विफल होने के संकेत से मेल खाता है

  • 20:50 UTC के बाद stabilization

    • 20:50:29: archive.ubuntu.com Operational
    • 20:51:13: security.ubuntu.com Operational
    • इस 44-second gap के बाद 22:52 UTC तक चलने वाले captured snapshot में दोनों hosts फिर से Down नहीं दिखे
    • flapping रुक गया, और दोनों endpoints हमले की शुरुआत के 4 घंटे 17 मिनट बाद एक मिनट से कम अंतर पर साथ स्थिर हो गए
    • लिखे जाने के समय security.ubuntu.com और archive.ubuntu.com 104.20.28.246 और 172.66.152.176 पर resolve हो रहे थे, और ये addresses Cloudflare द्वारा AS13335 में operate किए जाते हैं
    • अन्य प्रभावित hosts जैसे ubuntu.com, canonical.com, launchpad.net, snapcraft.io, login.ubuntu.com अभी भी Canonical के AS41231 space, 185.125.189.x और 185.125.190.x, पर resolve हो रहे थे
    • ubuntu.com के authoritative nameservers अब भी ns1.canonical.com, ns2.canonical.com, ns3.canonical.com हैं

selective Cloudflare migration

  • Canonical ने केवल उन दो A records, security.ubuntu.com और archive.ubuntu.com, को Cloudflare पर दिया जिन्हें attackers ने repository denial के लिए target किया था
  • बाकी सेवाएँ Canonical के अपने infrastructure पर रहीं और मौजूदा mitigations के तहत हमले को झेलती रहीं
  • non-repository hosts snapshot के अंत तक flapping करते रहे, और बाद में upstream filtering तथा attack mitigation या attack के रुकने के संयोजन से recover हुए
  • Canonical की पहली सार्वजनिक acknowledgment 1 मई 07:13 UTC पर आई, जो repository endpoints के Cloudflare के पीछे stabilize होने के 10 घंटे बाद थी
  • सभी components की पूर्ण recovery 1 मई 12:44 UTC पर confirm हुई, जो हमले की शुरुआत के लगभग 20 घंटे बाद था

“blackmail” होने या न होने के बारे में संरचना

  • सार्वजनिक रूप से verifiable path में ransom payment का कोई movement नहीं दिखता
  • उस स्तर का कोई cryptocurrency flow भी सार्वजनिक रिकॉर्ड में नहीं दिखता
  • कोई demand note सार्वजनिक नहीं हुई, और अगर negotiation हुई भी हो तो संभव है कि वह निजी तौर पर हुई हो
  • सार्वजनिक रिकॉर्ड में जो move होता दिखता है, वह paid subscription है
  • Canonical के दो सबसे मूल्यवान endpoints, यानी वे repository endpoints जो automatic security updates की वैश्विक विफलता पैदा कर सकते हैं, Cloudflare के साथ service relationship में shift हो गए
  • साथ ही Cloudflare के अन्य मौजूदा customers में वह booter operation भी शामिल था जो Canonical पर हमला कर रहा था
  • Beamed का लगातार hire के लिए उपलब्ध रहना और Canonical infrastructure के outage window का deadline की तरह काम करना, इस संरचना को बिना किसी अलग सार्वजनिक demand के भी deal हो जाने जैसा बनाता है
  • protector दोनों तरफ़ से revenue कमाता है, और फिर भी हर क्षण content-neutral और terms of service की भाषा के भीतर बना रहता है

horse-racing wire monopoly से तुलना

  • 1930s में Moses Annenberg का General News Bureau पूरे अमेरिका के bookmakers को race tracks के results तेज़ी से बेचता था
  • तुलना यह दी जाती है कि subscribed bookmaker बच गए, जबकि non-subscribed bookmaker subscribed rivals की वजह से odds set करने की क्षमता खो बैठे
  • Annenberg का revenue race results की verification पर monopoly पर निर्भर था, और इस monopoly ने informal bookmakers को उसके wire पर निर्भर बना दिया
  • federal government ने 1939 में tax indictment के ज़रिए इस monopoly को तोड़ा, और बाद की wire services पर 1940s तक crackdown हुआ
  • 1942 Mayor LaGuardia coverage में न्यूयॉर्क, न्यू जर्सी, Westchester और Nassau County के race-gambling operators तथा poolroom bookmakers के लिए “$1 million a year wire service” पर छापे और 9 गिरफ़्तारियों का ज़िक्र है
  • इससे यह आलोचना निकलती है कि आज का DDoS protection market booter market के साथ संबंध में एक समान स्थिति में है
  • Cloudflare का revenue इस स्थिति पर निर्भर करता है कि खुले इंटरनेट पर कौन-सी सेवा reachable है, और जब वही कंपनी booter की hosting provider भी हो, तो threat और protection की भूमिकाएँ एक ही revenue stream में मिल जाती हैं

सार्वजनिक रिकॉर्ड में बची हुई निशानियाँ

  • इस घटना के निशान कई registries और corporate filings में बँटे हुए हैं
  • Companies House में corporate filings हैं, RIPE database में routing reassignments हैं, certificate transparency logs में apex certificate rotation की तारीखें हैं, और Canonical के status page में record बदलने का समय बचा है
  • 27 फ़रवरी 2026 को एक ही calendar window में तीन तैयारियाँ पूरी हुईं
    • Materialism s.r.l. ने AS39287 और उससे जुड़े पुराने IPv6 prefixes का ownership लिया
    • Immaterialism Limited ने Companies House filings जमा कीं
    • Canonical की तरफ़ वे दो apex hostnames, जिन्हें बाद में content delivery network के पीछे ले जाया गया, अपने origin certificates renew कर चुके थे
  • attack शुरू होने से Canonical repository hostnames पर Cloudflare addresses दिखने तक का 4-hour gap उस अंतराल के रूप में पढ़ा जा सकता है जिसमें खरीद का फ़ैसला move हुआ
  • 30 अप्रैल 2026 20:50:29 UTC पर नया customer relationship सार्वजनिक रूप से दिखाई देने लगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News की राय

  • मेरी समझ में Cloudflare से attack capacity किराये पर लेना वाला वाक्यांश सटीक नहीं है
    यह सही है कि उस समूह ने अपनी साइट Cloudflare के पीछे host की थी, लेकिन मैंने ऐसा दावा नहीं देखा कि Cloudflare का infrastructure खुद हमले में इस्तेमाल हुआ
    पूरी पोस्ट ऐसा लग रहा है जैसे हमलावरों की info site host करने और खुद attack host करने, इन दोनों बातों को मिला रही हो

    • पहले इतने problem वाले DDoS operators नहीं थे, क्योंकि वे एक-दूसरे को DDoS करके offline कर देते थे
      वेबसाइट हो या control infrastructure, सब target बनते थे
      DDoS protection Akamai जैसी कंपनियाँ देती थीं, कीमत पूछने पर मिलती थी, सिर्फ बड़ी कंपनियों की पहुँच में थी, और anonymous signup तो बिल्कुल नहीं होता था
      Cloudflare ने किसी को भी, यहाँ तक कि DDoS-for-hire services को भी, free DDoS protection देकर industry बदल दी, और जब एक-दूसरे को offline धकेलना बंद हुआ तो DDoS industry सच में बढ़ सकी
    • इस खास incident के बारे में नहीं जानता, लेकिन HTTP traffic को काफी handle करने की वजह से हाल के logs में Cloudflare IPs ज़्यादा बार scanning या परेशान करने वाले requests में दिख रहे हैं
      ऐसा नहीं लगता कि यह सिर्फ proxied traffic की वजह से है, कम से कम CF-Connecting-Ip header तो नहीं होता
      नहीं जानता कि इस attack में भी इसका इस्तेमाल हुआ या नहीं, लेकिन कुछ attacks में होता है
      फिर भी Cloudflare अब भी लगभग हर दूसरे infrastructure provider से कम परेशान करने वाला है
    • मैं भी इस हिस्से पर अटक गया था, और क्योंकि लेखक बाकी मामलों में काफी thorough और accurate था, यह जानबूझकर धुंधला किया गया लगा
    • हाँ, ये दोनों बिल्कुल अलग बातें हैं
      तर्क भी मुझे खास पक्का नहीं लगता
      AWS पर भी बहुत से command-and-control servers host होते हैं और AWS भी victim बनता है, लेकिन इससे यह कहना मुश्किल है कि AWS जिम्मेदार है या धमका रहा है; मेरा जवाब ज़्यादातर नहीं ही होगा

  • कोई भी कुछ ऐसी sites चुन सकता है जिनके बारे में उसे लगे कि उन्हें Cloudflare hosting service नहीं मिलनी चाहिए
    समस्या यह है कि हर व्यक्ति की सूची अलग होगी
    Cloudflare को कानूनी आदेश मिलने तक कुछ भी host करना चाहिए
    अगर वह किसी धुंधले मानक से तय करने लगे कि साइट की सामग्री “उपयुक्त” है या नहीं, तो लोग जायज़ तौर पर बहुत नाराज़ होंगे
    Cloudflare से attack capacity किराये पर लेना वाले दावे के लिए सबूत चाहिए, और जहाँ तक मुझे पता है, हमलावर असली attacks के लिए Cloudflare infrastructure का इस्तेमाल नहीं कर रहे
    इस पोस्ट का overall tone और Google पर लिखी जाने वाली पोस्टों का tone इतना अलग है कि यह काफी अजीब लगता है

    • दुनिया भर में फैली उस entity के प्रति, जो इंटरनेट के बड़े हिस्से पर middleman observer की तरह बैठना चाहती है, एक बुनियादी ऊँचा संदेह, लगभग तिरस्कार तक, देखना उत्साहजनक है
      मुझे यकीन नहीं कि Cloudflare malicious actor है, लेकिन मेरा मानना है कि सबको उसके साथ ऐसा ही बरताव करना चाहिए
    • ज़्यादातर कंपनियों की terms में यह clause होता है कि आप कंपनी को नुकसान न पहुँचाएँ, या उस पर हमला न करें
      अगर advertised service साफ़ तौर पर Cloudflare पर attack करने की बात करे, तो किसी भी reasonable terms के तहत यह निश्चित ही violation लगेगा
      Cloudflare की अपनी terms में भी यह लिखा है
      https://www.cloudflare.com/en-ca/website-terms/
      “7. PROHIBITED USES” में लिखा है कि आप वेबसाइट या online service का उपयोग ऐसे तरीके से नहीं कर सकते जो Cloudflare servers या APIs, या जुड़े हुए networks को नुकसान पहुँचाए, disable करे, overload करे, interfere करे, या impair करे; और आप virus, worm, trojan horse जैसी destructive चीज़ें transmit नहीं कर सकते, न ही hacking या crypto mining जैसी गतिविधियों से unauthorized access की कोशिश कर सकते हैं
      इसके अलावा Cloudflare अपने sole discretion पर Distributed Web Gateway में ऐसे content को block करने का अधिकार रखता है जिसे वह illegal, harmful, या terms का उल्लंघन मानता है; इसमें malware distribution, phishing enable करना, और अन्य technical abuse भी शामिल हैं
    • मुझे नहीं पता Cloudflare इसे कैसे रोक सकता था
      अगर वह attackers की info site हटा भी दे, तो वे GitHub Pages या कई free static site hosting सेवाओं पर चले जाएँगे
      मेरे हिसाब से Cloudflare ने खुद attack को संभव बनाया, इसका ज़रा भी सबूत नहीं है
    • Cloudflare पहले से ही चुन-चुनकर कार्रवाई करता है
      उसने पूरी तरह बाहर रहने का फैसला नहीं किया है
      non-intervention का दावा दरअसल implicit approval की तरह पढ़ा जाना चाहिए
      क्योंकि हमें पता है कि जिन users से उसे काफी आपत्ति होती है, उन्हें वह सच में बाहर कर देता है
    • धरती पर ज़्यादातर लोग अपनी-अपनी सूचियों के उस common subset पर आसानी से सहमत हो जाएँगे, जिन sites को सच में Cloudflare का उपयोग नहीं करना चाहिए

  • ऐसी पोस्टें मानो इस अजीब विश्वास पर टिकी होती हैं कि Cloudflare security reports या legal orders का जवाब नहीं देता
    मेरे अनुभव में Cloudflare industry के बाकी हिस्सों की तुलना में उचित और अपेक्षाकृत तेज़ response देता है
    वह शायद और proactive हो सकता है या signup process में और friction जोड़ सकता है, लेकिन internet police बनने से इनकार करने की वजह मुझे समझ आती है
    मुझे नहीं लगता कि इंटरनेट पर content host करने के लिए credit card, phone number, और ID copy तक देना ज़रूरी होना चाहिए

    • इंटरनेट लंबे समय तक इसलिए चला क्योंकि हर छोटे द्वीप के ज़िम्मेदार लोग आम तौर पर बाकी द्वीपों के हित में व्यवहार करते थे
      अगर वे ऐसा नहीं करते, तो दूसरे द्वीप उनसे connection काट देते
      law enforcement आख़िरी उपाय था, क्योंकि courts इंटरनेट की गति से नहीं चलते, और इंटरनेट के cross-border स्वभाव के कारण कोई भी ऊपर से आने वाला सरकारी regulation नहीं चाहता था
      Cloudflare ने venture capital के पैसे से महँगी चीज़ें free में देकर market share खरीदा
      अगर आप सारी किराना दुकानों को अपने ही द्वीप पर ले आएँ, तो बाकी लोगों द्वारा बहिष्कृत होने की चिंता बिना आप criminal activity का अड्डा चला सकते हैं
      botnets, malware, और online fraud से लड़ने वालों से पूछ लीजिए
      जब आप Cloudflare dead end पर पहुँचते हैं, तो बस हार माननी पड़ती है
      7,000 infected computers वाले case को law enforcement नहीं उठाएगी, और Cloudflare भी खुद investigate करके कार्रवाई नहीं करेगा
    • मेरा मानना है कि इंटरनेट पर content host करने के लिए Cloudflare से बात करने की ज़रूरत ही नहीं होनी चाहिए
      मैं तो वास्तव में ऐसा नहीं करता
    • Cloudflare और AWS ने मेरी भेजी abuse reports पर सिर्फ इसलिए जाँच तक नहीं की क्योंकि उनमें infringing URL या “specific resource” नहीं था
      मैंने इतना evidence दिया था कि वे internal investigation शुरू कर सकते थे या abusive customer से संपर्क कर सकते थे, लेकिन उन्होंने ऐसा नहीं किया
      अगर वह stresser service है, तो बाहर से आपको सिर्फ login panel ही दिखेगा
      ऐसी sites खुलकर यह advertise भी नहीं करतीं कि वे क्या कर रही हैं
    • यह कोई अजीब विश्वास नहीं है
      Cloudflare खुद को infrastructure के रूप में position करता है
      यानी वह मानता है कि जो content वह carry करता है, उसके लिए वह जिम्मेदार नहीं है
      सामान्य स्थिति में इंटरनेट की खराब systems से अपनी system को बचाने के लिए आप IP layer पर block कर सकते हैं
      लेकिन Cloudflare IP layer पर अच्छे, बुरे और बीच के सारे systems को proxy कर देता है
      आम तौर पर आप criminal groups द्वारा चलाई जा रही site को IP level पर block कर सकते हैं, या content host करने वाले संगठन के abuse@ पर संपर्क करके उसे block/report कर सकते हैं
      Cloudflare दोनों रास्ते रोक देता है
      और जब आप Cloudflare को abuse report भेजते हैं, तो इसकी भी कोई गारंटी नहीं कि वह आपकी contact info उसी party को जस की तस forward नहीं करेगा जिसके खिलाफ आपने report की है
      उसने सालों में खुद को थोड़ा ज़्यादा responsible दिखाने की कोशिश की है, लेकिन मूल बात वही है
      अगर आप Cloudflare के पीछे छिपी system को abuse@ report भेजना चाहें, तो यह भरोसा नहीं किया जा सकता कि वह उसे बस आगे नहीं बढ़ा देगा जबकि आपको पता भी नहीं होगा कि किसे भेजा गया

  • पिछले हफ्ते की संबंधित पोस्ट:
    “Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers?”
    https://news.ycombinator.com/item?id=48025001

  • आधुनिक इंटरनेट में CF की भूमिका मुझे भी पसंद नहीं, लेकिन यह पोस्ट Canonical certificate renewal और company relocation एक ही दिन होने की बात को छोड़कर, बिना सबूत बिंदुओं को जोड़ने वाली अटकलों की गठरी लगती है
    हाँ, side story के तौर पर देखने लायक बात है
    लगता है Njalla ने हाल में चुपचाप कोई restructuring या ownership change किया है[1], और Njalla तथा immateriali.sm जुड़े हुए corporate entities लगते हैं[2]
    https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
    https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...

  • जैसा कि पोस्ट बहुत संक्षेप में कहती है, Cloudflare हमलावरों को मुफ्त fronting protection देता है और victims से remedy के लिए पैसे लेता है
    DDoS mitigation service को डिजिटल protection racket की तरह देखा जा सकता है, और इससे attackers को attack जारी रखने का incentive मिलता है
    बात कुछ ऐसी बनती है: “इंटरनेट ख़तरनाक है, और free tier इस्तेमाल करने वाले attackers से अपनी वेबसाइट बचानी है तो हमें पैसे दो”
    भले ही active collusion या revenue sharing न हो, फिर भी DDoS mitigation services किसके पक्ष में हैं, यह बिल्कुल साफ़ नहीं है

    • तो फिर समाधान क्या है?
      मैं आलोचना से सहमत हूँ, लेकिन DDoS Cloudflare ने invent नहीं किया
      अगर Cloudflare कल जादू से गायब भी हो जाए, तो AI crawlers रुक नहीं जाएँगे
      विकल्प क्या है? क्या ऐसी दुनिया, जहाँ इंटरनेट देखने के लिए आपको government-issued ID upload करनी पड़े?
    • किसी मोहल्ले या देश में आप attackers पर नियंत्रण और हिंसा पर monopoly स्थापित कर सकते हैं
      लेकिन अगर इंटरनेट की relative anonymity और global nature को बचाए रखना है, तो यह कैसे किया जाए?
      लोग cooperatives बनाकर defense संभाल सकते हैं, लेकिन उन्हें worldwide scale पर चलाना मुश्किल होगा
      DDoS defense मुख्यतः इतना excess capacity रखने और filtering करने पर टिका है कि आप attack झेल सकें, और इसके लिए निवेश बहुत बड़ा चाहिए
    • एक और सरल व्याख्या भी है
      Cloudflare, The Daily Stormer case[1] की तरह 100% नहीं तो भी, सामान्यतः अपनी system से गुजरने वाले अनुमानतः legal content को censor नहीं करता, और खुद को legality का judge बनाना नहीं चुनता
      [1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
    • यह इंटरनेट के base protocols की बुनियादी कमज़ोरियों से जन्मी हुई protection racket structure है

  • पूरी तरह सहमत
    Cloudflare बड़े पैमाने पर scammers की रक्षा करता है और किसी को फ़र्क नहीं पड़ता
    जिन fake shopping malls और phishing pages की मैंने Cloudflare को report की, और जो Cloudflare के पीछे थे, उनमें से एक भी नहीं हटाया गया
    एक भी नहीं
    अगर कोई कंपनी लोगों की रक्षा करके billions कमाती है, तो उसे इसे गंभीरता से लेना चाहिए

    • अगर आप legal process के ज़रिए Cloudflare पर कार्रवाई का दबाव नहीं डालते, तो उसके सुनने की संभावना कम है
      उदाहरण के लिए, “मुझे 20 डॉलर का नुकसान हुआ, और damages claim के target की पहचान करने के लिए मैं Cloudflare को दिए गए customer payment information, issuing bank, और account number की माँग करता हूँ” जैसी small claims court कार्रवाई काफ़ी ठीक लगती है
      अभी तक किसी के ऐसा करने की खबर नहीं सुनी, लेकिन अगर कोई करे तो नतीजा देखना दिलचस्प होगा
    • क्या आप वाकई ऐसी और बड़ी संस्थाएँ चाहते हैं जो appeal mechanism या legal process के बिना मनमाने ढंग से websites censor करें?
      मुझे तो मौजूदा स्थिति कहीं बेहतर लगती है

  • मैं हमेशा सोचता था कि Ubuntu इसलिए down हुआ क्योंकि Ubuntu servers को copy.fail patch नहीं करने दिया गया, ताकि वह hacking group उस दौरान जितने हो सकें उतने targets exploit कर सके

    • Ubuntu में copy.fail को modprobe(8) की कुछ settings से mitigate किया जा सकता था
      # echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
      # rmmod algif_aead
      हो सकता है कुछ processes इस feature का उपयोग करते हों (lsof | grep AF_ALG), लेकिन मेरी समझ में इसका व्यापक उपयोग नहीं है, इसलिए ज़्यादातर systems पर इसे disable करने से समस्या नहीं होनी चाहिए
    • copy.fail patch को बहुत कम downtime के साथ apply किया जा सकता है, और VM चाहे किसी भी size का हो, reboot में ज़्यादा से ज़्यादा 30 seconds लगेंगे
      सभी apex servers निश्चित ही high availability में configured होंगे ताकि load balancing बनी रहे, इसलिए सामान्य users को copy.fail patching के दौरान कुछ महसूस नहीं होना चाहिए
      हमारे users को भी patches deploy करते समय बिल्कुल कुछ महसूस नहीं हुआ

  • यह blackmail नहीं बल्कि extortion के ज़्यादा क़रीब है
    CF ने दोनों में से कुछ भी नहीं किया

  • इस तर्क से तो keyboard manufacturers को भी अपने products से लिखी गई अवैध चीज़ों के लिए जिम्मेदार ठहराया जा सकता है

    • यह device sale नहीं, service है
      किसी ऐसे संगठन को लगातार service देना जो criminal activity support करने में इस्तेमाल हो रहा हो, बहुत अलग बात है, और illegal activity के आधार पर customer terminate करना कोई विवादास्पद बात नहीं है
    • यह वही मामला नहीं है
      अगर आपको UPS parcel में bomb मिले तो वह UPS की गलती नहीं है
      लेकिन अगर किसी को बताया जाए कि कोई UPS का इस्तेमाल लोगों को bomb भेजने के लिए कर रहा है, और फिर भी UPS कुछ न करे, बल्कि bomb भेजने वाले की रक्षा करता हुआ लगे, तो क्या कुछ जिम्मेदारी नहीं बनती?
    • यह गलत analogy है
      इस scenario में “keyboard manufacturer” की तुलना Cloudflare से नहीं, बल्कि उस router manufacturer से होगी जिससे Cloudflare equipment खरीदता है
      इस analogy में Cloudflare उस newspaper aggregator के ज़्यादा करीब है जो हर तरह की गंदगी और वैध commentary को साथ लेकर चलता है
      सामान्य हालात में आप गंदे अख़बार न पढ़ें, और जो पढ़ना चाहें वे खुद तय करें
      लेकिन Cloudflare की स्थिति में बड़े वैध अख़बारों ने भी Cloudflare के माध्यम से content publish करना चुन लिया है, और जब problematic चीज़ें भी साथ publish होती हैं, तो मूल publisher से पूछने के बजाय आपको Cloudflare से पूछना पड़ता है
      और Cloudflare आपकी जानकारी पहले से बताए बिना बहुत अप्रिय लोगों तक पहुँचा भी सकता है
    • या फिर यह ऐसा है जैसे पानी बेचने पर water utility को जिम्मेदार ठहराना
      रेखा आखिर कहाँ खींची जाए?