1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Layanan web publik Canonical mengalami gangguan selama sekitar 20 jam mulai 30 April 2026 16:33 UTC, dan endpoint repositori Ubuntu juga belakangan ikut terdampak
  • Kelompok berhaluan pro-Iran yang mengaku bertanggung jawab atas serangan itu mengatakan mereka memakai layanan DDoS berbayar Beamed, yang mengiklankan bypass Cloudflare dan rotasi IP residensial
  • Infrastruktur pendaftaran dan routing yang terkait dengan domain Beamed mengarah ke catatan Cloudflare AS13335, Immaterialism, AS39287, dan Materialism s.r.l.
  • Reassignment AS39287 dan pembaruan sertifikat apex Canonical untuk archive.ubuntu.com dan security.ubuntu.com terjadi dalam jendela 24 jam yang sama pada 27 Februari 2026
  • Di tengah serangan, Canonical hanya memindahkan security.ubuntu.com dan archive.ubuntu.com ke Cloudflare, sehingga dalam catatan publik yang berpindah bukan tebusan melainkan langganan berbayar

Gangguan Canonical dan perpindahan ke Cloudflare

  • Pada 30 April 2026 16:33:37 UTC, sistem pemantauan Canonical menandai blog.ubuntu.com sebagai Service Down, dan dalam sekitar 10 menit layanan web publik lain seperti ubuntu.com, API advisori keamanan, portal pengembang, situs perusahaan, dan platform pendidikan juga ikut mati
  • Gangguan berlangsung sekitar 20 jam, dan tercatat sebagai Service Restored pada 1 Mei 2026 12:44 UTC
  • Kelompok yang mengaku bertanggung jawab memperkenalkan diri sebagai Islamic Cyber Resistance in Iraq atau 313 Team, kelompok berhaluan pro-Iran yang menyatakan menggunakan layanan berbayar
  • Beamed, yang disebut sebagai alat serangan, adalah produk denial-of-service komersial yang dijual di beberapa TLD; beamed.su digunakan sebagai situs pemasaran dan blog, sedangkan beamed.st dipakai sebagai portal login pelanggan
  • Tulisan blog Beamed pada April 2026 mengiklankan “bypass Cloudflare” dan menawarkan tiga teknik, termasuk rotasi IP residensial serta “endpoint hunting” manual untuk menemukan server asal
  • Seminggu setelah serangan, beamed.su dan beamed.st masih online, dan keduanya di-resolve ke alamat Cloudflare AS13335
  • Dua endpoint repositori Canonical, security.ubuntu.com dan archive.ubuntu.com, kemudian juga mulai menggunakan alamat Cloudflare AS13335

Beamed serta infrastruktur pendaftaran dan routing

  • Domain konsumen Beamed didaftarkan melalui registrar bernama Immaterialism Limited, yang menjual pendaftaran domain dengan tarif tetap dan API JSON
  • Immateriali.sm diproksikan melalui nameserver Cloudflare yaitu tani.ns.cloudflare.com dan trey.ns.cloudflare.com
  • Immaterialism Limited terdaftar di Companies House Inggris dengan nomor perusahaan 15738452 dan didirikan pada 24 Mei 2024
  • Saat pendirian, direkturnya adalah Nicole Priscila Fernandez Chaves dari Kosta Rika, menggunakan alamat kotak surat massal di Great Portland Street, London
  • Pada 11 April 2025 Fernandez Chaves mundur dari jabatan direktur tetapi tetap mempertahankan kepentingan ekonomi lebih dari 75%, dan Naomi Susan Colvin, warga Inggris, ditunjuk sebagai direktur pengganti di alamat yang sama

Reassignment AS39287 pada 27 Februari 2026

  • Pada 26 Februari 2026, Immaterialism Limited mengajukan dua perubahan ke Companies House pada hari yang sama
    • Kantor terdaftar dipindahkan dari 85 Great Portland Street ke 167-169 Great Portland Street
    • Detail person with significant control untuk Fernandez Chaves diubah
  • Keesokan harinya, 27 Februari 2026, infrastruktur routing yang mengumumkan ruang IP untuk Beamed dan layanan terkait berpindah yurisdiksi
  • Sistem otonom yang mengumumkan ruang alamat Materialism adalah AS39287, dan RIPE mengalokasikan nomor AS ini pada 24 Januari 2006
  • Identitas routing AS39287 tetap dipertahankan, tetapi catatan operator terdaftar dan negara berubah dua kali
  • Periode Privactually Ltd dan FLATTR-AS

    • Sekitar 2017 hingga sekitar 2020, AS39287 dimiliki perusahaan Siprus Privactually Ltd dan dioperasikan dengan nama FLATTR-AS
    • Flattr terhubung dengan proyek micropayment milik salah satu pendiri bersama The Pirate Bay, Peter Sunde Kolmosoppi
    • Kontak abuse untuk prefix di bawah pendaftaran itu adalah abuse@shelter.st
  • Periode ab stract ltd

    • Dari 2020 hingga 2026, nomor AS yang sama dialokasikan ulang ke perusahaan Finlandia ab stract ltd di Urho Kekkosen katu 4-6E, Helsinki
    • Objek maintainer dalam catatan RIPE adalah BKP-MNT, dan tokoh yang tercatat adalah pendiri The Pirate Bay lainnya, Peter Kolmisoppi
    • Nameserver otoritatif untuk domain operator abstract.fi adalah tiga nameserver Njalla: njalla.fo, njalla.no, dan njalla.in
    • Njalla adalah proxy domain privacy-as-a-service yang dibuat Peter Sunde dan dioperasikan melalui 1337 Services LLC di Saint Kitts dan Nevis
  • Reassignment ke Materialism s.r.l.

    • Pada 27 Februari 2026 12:11:48 UTC, RIPE mencatat reassignment ketiga, dan AS39287 menjadi milik Materialism s.r.l. di Bulevardul Metalurgiei, Bukares, Rumania
    • Reassignment itu mencakup 45.158.116.0/22, 2001:67c:2354::/48, dan 2a02:6f8::/32, dengan prefix IPv6 terakhir pertama kali dialokasikan pada Agustus 2008 di rezim sebelumnya
    • Selama tiga periode perpindahan itu, konfigurasi peering tetap dipertahankan, dan AS39287 terus memakai import/export yang sama dengan AS42708(Telia), AS37560(GTT), AS12552(GlobalConnect), AS34244(Voxility), dan AS54990
    • Jalur yang sama tetap keluar ke jaringan upstream yang sama, dan yang berubah dalam catatan publik hanya nama operator yang terlihat
    • Dalam daftar registrar domain terakreditasi IANA, basis pelanggan Immateriali.sm mencakup 1337 Services LLC, entitas transaksi di balik Njalla

Rotasi sertifikat Canonical pada hari yang sama

  • Catatan certificate transparency untuk endpoint repositori Canonical menampilkan beberapa entri dalam jendela 24 jam yang sama ketika reassignment routing terjadi
  • Pada 27 Februari 2026 06:14:03 UTC, Let’s Encrypt menerbitkan sertifikat apex baru untuk archive.ubuntu.com
  • Pada hari yang sama 19:13:35 UTC, Let’s Encrypt menerbitkan sertifikat apex baru untuk security.ubuntu.com
  • Dalam catatan certificate transparency 2026 untuk security.ubuntu.com, sebelum entri ini hanya ada sertifikat mirror regional, dan tidak terlihat sertifikat apex yang lebih awal dalam log yang tampak
  • Pada hari yang sama 22:14:03 UTC, sertifikat baru untuk clouds.archive.ubuntu.com diterbitkan
  • Selama sembilan hari berikutnya, pola yang sama berulang pada azure.archive.ubuntu.com, wildcard-gce.archive.ubuntu.com, dan wildcard-ec2.archive.ubuntu.com
  • Masing-masing sertifikat baru diterbitkan untuk hostname apex, bukan mirror regional
  • Sertifikat origin yang valid untuk hostname apex diperlakukan sebagai prasyarat untuk menempatkan hostname tersebut di balik content delivery network
  • Keserempakan antara reassignment routing pada 27 Februari 2026 dan rotasi sertifikat Canonical tidak dapat dijelaskan hanya dari catatan publik

Linimasa serangan

  • Linimasa ini didasarkan pada log gangguan per menit yang ada di halaman status.canonical.com milik Canonical, yang tersisa sebagai snapshot di Ubuntu Discourse thread 81470 sekitar 30 April pukul 22:52 UTC
  • 10 menit pertama: gangguan luas pada web publik

    • 16:33:37: blog.ubuntu.com pertama kali ditandai Down dan dicatat sebagai 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
    • Feed advisori keamanan tumbang dalam 3 menit sejak awal, dan apex pemasaran mati dalam 10 menit
    • Pada saat ini, host yang belum diserang adalah security.ubuntu.com dan archive.ubuntu.com, dua endpoint repositori yang bisa menyebabkan kegagalan apt update di seluruh instalasi Ubuntu
  • Tiga jam kemudian endpoint repositori diserang

    • 19:34:38: security.ubuntu.com pertama kali ditandai Down
    • 19:40:01: archive.ubuntu.com Down
    • Endpoint repositori mulai terganggu sekitar 3 jam setelah serangan dimulai
    • Dari 19:40 UTC selama 70 menit berikutnya, kedua endpoint repositori bolak-balik antara Down dan Operational di papan status
    • Log status mencatat 5 kali pergantian Down/Operational untuk security.ubuntu.com dan 4 kali untuk archive.ubuntu.com selama periode itu
    • Pola ini selaras dengan upaya mitigasi di origin seperti rate limiting, filter regional, atau traffic scrubbing yang gagal di bawah beban berkelanjutan sebesar 3.5 Tbps yang diumumkan
  • Stabilisasi setelah 20:50 UTC

    • 20:50:29: archive.ubuntu.com Operational
    • 20:51:13: security.ubuntu.com Operational
    • Setelah jeda 44 detik ini, dalam snapshot yang berlanjut hingga 22:52 UTC kedua host tidak lagi muncul sebagai Down
    • Flapping berhenti, dan kedua endpoint stabil bersama dalam selang kurang dari satu menit pada 4 jam 17 menit setelah serangan dimulai
    • Saat penulisan, security.ubuntu.com dan archive.ubuntu.com di-resolve ke 104.20.28.246 dan 172.66.152.176, alamat yang dioperasikan Cloudflare di AS13335
    • Host terdampak lain seperti ubuntu.com, canonical.com, launchpad.net, snapcraft.io, dan login.ubuntu.com masih di-resolve ke ruang AS41231 milik Canonical, yaitu 185.125.189.x dan 185.125.190.x
    • Nameserver otoritatif untuk ubuntu.com tetap ns1.canonical.com, ns2.canonical.com, dan ns3.canonical.com

Perpindahan selektif ke Cloudflare

  • Canonical hanya menyerahkan dua A record yang menjadi target penolakan repositori oleh penyerang, yaitu security.ubuntu.com dan archive.ubuntu.com, ke Cloudflare
  • Layanan lain tetap berada di infrastruktur Canonical sendiri dan bertahan di bawah mitigasi yang sudah ada
  • Host non-repositori terus mengalami flapping hingga akhir snapshot, lalu pulih melalui kombinasi filtering upstream dan mitigasi serangan atau berhentinya serangan
  • Pengakuan publik pertama dari Canonical muncul pada 1 Mei 07:13 UTC, yaitu 10 jam setelah endpoint repositori stabil di belakang Cloudflare
  • Pemulihan penuh semua komponen dikonfirmasi pada 1 Mei 12:44 UTC, sekitar 20 jam setelah serangan dimulai

Struktur di balik apakah ini “pemerasan”

  • Dalam jalur yang dapat diverifikasi secara publik, tidak ada pembayaran tebusan yang berpindah
  • Tidak ada arus kripto sebesar itu yang tampak dalam catatan publik
  • Surat tuntutan juga tidak dipublikasikan, dan jika ada negosiasi kemungkinan besar berlangsung secara privat
  • Yang berpindah dalam catatan publik adalah langganan berbayar
  • Dua endpoint Canonical yang paling bernilai, yakni endpoint repositori yang dapat menyebabkan kegagalan global pada pembaruan keamanan otomatis, beralih ke hubungan layanan dengan Cloudflare
  • Pada saat yang sama, pelanggan aktif Cloudflare lainnya mencakup operator booter yang menyerang Canonical
  • Karena Beamed tetap dapat disewa dan durasi gangguan pada infrastruktur Canonical bekerja seperti tenggat waktu, situasinya ditafsirkan sebagai struktur di mana transaksi terjadi tanpa tuntutan publik terpisah
  • Pihak pelindung memperoleh pendapatan dari kedua sisi sambil, pada setiap momennya, tetap netral terhadap konten dan berada dalam bunyi ketentuan layanan

Perbandingan dengan monopoli jaringan komunikasi pacuan kuda

  • Pada 1930-an, General News Bureau milik Moses Annenberg menjual hasil arena pacuan kuda secara cepat kepada bookmaker di seluruh Amerika Serikat
  • Bookmaker yang berlangganan bertahan, sementara yang tidak berlangganan disebut kehilangan kemampuan menetapkan odds karena pesaing mereka yang berlangganan
  • Pendapatan Annenberg bergantung pada monopoli atas verifikasi hasil pacuan kuda, dan monopoli ini membuat bookmaker informal bergantung pada wire miliknya untuk bisa beroperasi
  • Pemerintah federal memecah monopoli ini melalui dakwaan pajak pada 1939, dan layanan wire susulan terus ditindak hingga 1940-an
  • Laporan tahun 1942 terkait Mayor LaGuardia menyebut penangkapan 9 orang dalam penggerebekan terhadap “wire service senilai 1 juta dolar per tahun” untuk penjudi pacuan kuda dan poolroom bookmaker di New York, New Jersey, Westchester, dan Nassau County
  • Dari sini muncul kritik bahwa pasar perlindungan DDoS saat ini menempati posisi serupa dalam relasinya dengan pasar booter
  • Pendapatan Cloudflare bergantung pada posisinya dalam memverifikasi apakah layanan dapat dijangkau di internet publik, dan ketika perusahaan yang sama juga menjadi penyedia hosting bagi booter, peran ancaman dan perlindungan menyatu dalam satu aliran pendapatan

Jejak yang tersisa dalam catatan publik

  • Jejak insiden ini tersisa tersebar di berbagai registry dan pengungkapan perusahaan
  • Companies House menyimpan berkas perusahaan, database RIPE memuat reassignment routing, log certificate transparency mencatat tanggal rotasi sertifikat apex, dan halaman status Canonical mencatat waktu ketika record berubah
  • Pada 27 Februari 2026, tiga persiapan selesai dalam jendela kalender yang sama
    • Materialism s.r.l. mengambil kepemilikan AS39287 beserta prefix IPv6 lama yang menyertainya
    • Immaterialism Limited mengajukan dokumen ke Companies House
    • Di pihak Canonical, dua hostname apex yang nanti dipindahkan ke belakang content delivery network memperbarui sertifikat origin mereka
  • Jeda 4 jam dari awal serangan hingga alamat Cloudflare muncul pada hostname repositori Canonical ditafsirkan sebagai rentang ketika keputusan pembelian berpindah
  • Pada 30 April 2026 20:50:29 UTC, hubungan pelanggan baru itu menjadi terlihat secara publik

1 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News
  • Sepemahaman saya, ungkapan menyewa kapasitas serangan dari Cloudflare itu tidak akurat
    Memang benar kelompok itu meng-host situs di balik Cloudflare, tetapi saya belum pernah melihat klaim bahwa infrastruktur Cloudflare dipakai untuk serangan itu sendiri
    Seluruh tulisan ini tampaknya mencampuradukkan hosting situs panduan yang dijalankan penyerang dengan hosting serangannya sendiri

    • Dulu tidak banyak operator DDoS bermasalah, karena mereka saling menjatuhkan satu sama lain dengan DDoS hingga offline
      Baik situs web maupun infrastruktur kontrol, semuanya jadi target serangan
      Perlindungan DDoS disediakan oleh perusahaan seperti Akamai, harganya harus ditanyakan dulu, hanya terjangkau perusahaan besar, dan pendaftaran anonim sama sekali tidak mungkin
      Cloudflare mengubah industri dengan menyediakan perlindungan DDoS gratis untuk siapa saja, termasuk layanan DDoS-for-hire, dan ketika mereka tidak lagi bisa saling memaksa offline, industri DDoS benar-benar bisa tumbuh besar
    • Saya tidak tahu soal kasus spesifik ini, tetapi karena saya banyak menangani manajemen trafik HTTP, di log terbaru saya lebih sering melihat IP Cloudflare untuk probing atau request yang mengganggu
      Sepertinya itu juga bukan trafik yang diproksikan, setidaknya tidak ada header CF-Connecting-Ip
      Saya tidak tahu apakah dipakai dalam serangan ini, tetapi memang dipakai dalam sebagian serangan
      Meski begitu, Cloudflare tetap jauh lebih tidak mengganggu dibanding hampir semua penyedia infrastruktur lain
    • Saya juga bingung pada bagian itu, dan mengingat penulis cukup teliti dan akurat pada elemen lain, rasanya seperti sengaja dibuat kabur
    • Betul, keduanya adalah hal yang sangat berbeda
      Saya juga tidak yakin logikanya benar-benar nyambung
      Banyak juga server command-and-control yang di-host di AWS dan banyak korban AWS, tetapi bukan berarti AWS bertanggung jawab atau melakukan intimidasi, dan menurut saya jawabannya umumnya tidak
  • Siapa pun bisa memilih beberapa situs yang menurut mereka tidak boleh memakai layanan hosting Cloudflare
    Masalahnya, daftar itu berbeda untuk tiap orang
    Cloudflare harus meng-host apa pun sampai ada perintah hukum yang sah
    Kalau mereka mulai menilai apakah isi situs “layak” berdasarkan standar yang kabur, orang-orang jelas akan marah besar dengan alasan yang sah
    Klaim menyewa kapasitas serangan dari Cloudflare harus punya dasar, dan setahu saya para penyerang tidak memakai infrastruktur Cloudflare untuk serangan sebenarnya
    Nuansa umum di tulisan ini terlalu berbeda dari nuansa di tulisan terkait Google, jadi cukup membingungkan

    • Melihat sikap dasar yang sangat curiga, hampir mendekati jijik, terhadap entitas global yang ingin melintang di begitu banyak bagian internet sebagai semacam pengamat di tengah itu justru menggembirakan
      Saya tidak yakin Cloudflare adalah aktor jahat, tetapi menurut saya kita harus bersikap seolah semuanya bisa begitu
    • Sebagian besar syarat layanan perusahaan punya klausul yang melarang merusak atau menyerang perusahaan itu sendiri
      Jika layanan yang diiklankan secara eksplisit menyerang Cloudflare, syarat layanan yang wajar jelas akan menganggap itu pelanggaran
      Di syarat Cloudflare sendiri memang tertulis begitu
      https://www.cloudflare.com/en-ca/website-terms/
      Pada “7. PROHIBITED USES” disebutkan bahwa situs web atau layanan online tidak boleh digunakan dengan cara yang dapat merusak, menonaktifkan, membebani berlebihan, mengganggu, atau menghambat server atau API Cloudflare maupun jaringan yang terhubung, serta tidak boleh mengirim item destruktif seperti virus, worm, trojan horse, dan lain-lain, atau mencoba akses tanpa izin lewat peretasan maupun penambangan kripto
      Selain itu, Cloudflare menyatakan berhak memblokir konten di Distributed Web Gateway yang menurut penilaiannya sendiri ilegal, berbahaya, atau melanggar syarat, termasuk distribusi malware, promosi phishing, dan penyalahgunaan teknis lainnya
    • Saya tidak tahu bagaimana Cloudflare bisa mencegah ini
      Sekalipun situs panduan penyerang diturunkan, mereka tinggal pindah ke GitHub Pages atau salah satu dari banyak hosting situs statis gratis
      Menurut saya tidak ada bukti sama sekali bahwa Cloudflare memungkinkan serangan yang sebenarnya
    • Cloudflare sudah memilih-milih dalam penegakannya
      Mereka tidak benar-benar memutuskan untuk sepenuhnya berada di luar urusan ini
      Klaim tidak ikut campur harus dibaca sebagai persetujuan tersirat
      Karena kita tahu mereka benar-benar mengusir pengguna yang cukup tidak mereka sukai
    • Kebanyakan orang di bumi ini mungkin bisa dengan mudah sepakat pada irisan yang sama dari daftar situs yang memang tidak boleh memakai Cloudflare
  • Tulisan seperti ini tampaknya berangkat dari keyakinan aneh bahwa Cloudflare tidak menanggapi laporan keamanan atau perintah hukum
    Dari pengalaman saya, Cloudflare merespons dengan pantas dan relatif cepat dibanding industri secara umum
    Mereka mungkin bisa bertindak lebih proaktif atau menambah lebih banyak friksi dalam proses pendaftaran, tetapi alasan untuk tidak berperan sebagai polisi internet bisa dipahami
    Saya tidak merasa orang harus diminta kartu kredit, nomor telepon, sampai salinan identitas hanya untuk meng-host konten di internet

    • Internet bisa berfungsi lama karena para penanggung jawab tiap pulau kecil umumnya bertindak sejalan dengan kepentingan keseluruhan pulau-pulau lain
      Kalau tidak, pulau lain akan memutus koneksi ke mereka
      Penegakan hukum adalah jalan terakhir, karena pengadilan tidak bergerak secepat internet, dan karena sifat internet yang lintas batas, tak seorang pun ingin regulasi pemerintah dari atas
      Cloudflare memakai modal ventura untuk menyediakan hal-hal mahal secara gratis dan membeli pangsa pasar
      Jika Anda membuat semua toko kelontong pindah ke pulau Anda, Anda bisa menjalankan sarang aktivitas kriminal tanpa takut dikucilkan pihak lain
      Tanyakan saja pada orang yang melawan botnet, malware, dan penipuan online
      Saat mencapai jalan buntu Cloudflare, Anda tinggal menyerah
      Penegak hukum tidak akan menangani kasus yang hanya melibatkan 7.000 komputer terinfeksi, dan Cloudflare juga tidak akan menyelidiki lalu menindak sendiri
    • Menurut saya seharusnya tidak perlu bicara dengan Cloudflare sama sekali untuk meng-host konten di internet
      Dan memang saya sendiri tidak melakukannya
    • Cloudflare dan AWS bahkan tidak mau menyelidiki laporan abuse yang saya kirim dengan alasan tidak ada URL yang melanggar atau “resource spesifik”
      Saya sudah memberi cukup bukti untuk memulai investigasi internal atau menghubungi pelanggan yang menyalahgunakan layanan, tetapi itu tidak dilakukan
      Kalau itu layanan stresser, dari luar yang terlihat mungkin hanya panel login
      Situs-situs seperti ini juga tidak terang-terangan mengiklankan apa yang mereka lakukan
    • Itu bukan keyakinan yang aneh
      Cloudflare memosisikan dirinya sebagai infrastruktur
      Artinya, mereka menganggap diri mereka tidak bertanggung jawab atas konten yang mereka angkut
      Dalam situasi normal, untuk melindungi sistem saya dari sistem buruk di internet, saya bisa memblokir di lapisan IP
      Tetapi Cloudflare memproksikan sistem baik, sistem buruk, dan semua yang ada di antaranya pada lapisan IP
      Biasanya Anda bisa memblokir situs yang dijalankan organisasi kriminal di level IP, atau menghubungi abuse@ organisasi yang meng-host konten agar diblokir atau dilaporkan
      Cloudflare membuat keduanya tidak bisa dilakukan
      Dan ketika Anda mengirim laporan abuse ke Cloudflare, juga tidak ada jaminan bahwa informasi kontak Anda tidak akan diteruskan mentah-mentah ke pihak yang Anda laporkan
      Mereka memang sudah beberapa tahun mengubah posisinya agar tampak lebih bertanggung jawab, tetapi inti masalahnya tetap sama
      Bahkan jika saya ingin mengirim laporan abuse@ ke sistem yang bersembunyi di balik Cloudflare, saya tidak bisa yakin mereka tidak akan sekadar meneruskannya tanpa saya tahu kepada siapa
  • Tulisan terkait minggu lalu:
    “Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers?”
    https://news.ycombinator.com/item?id=48025001

  • Saya memang tidak suka peran CF di internet modern, tetapi tulisan ini tampak seperti sekumpulan spekulasi yang menghubung-hubungkan titik tanpa dasar selain fakta bahwa pembaruan sertifikat Canonical dan perpindahan perusahaan terjadi pada hari yang sama
    Meski begitu, ada cerita sampingan yang patut dilihat
    Tampaknya Njalla baru-baru ini diam-diam melakukan restrukturisasi organisasi atau perubahan kepemilikan[1], dan Njalla serta immateriali.sm tampaknya adalah badan hukum yang saling terkait[2]
    https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
    https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...

  • Seperti dikatakan tulisan itu dengan sangat ringkas, Cloudflare melindungi penyerang di sisi depan secara gratis dan menagih korban untuk biaya pemulihan
    Layanan pertahanan DDoS bisa dilihat seperti pemerasan uang keamanan digital, dan itu menciptakan insentif untuk membiarkan penyerang terus menyerang
    Ibaratnya, “internet berbahaya, jadi bayar kami kalau mau melindungi situs Anda dari para penyerang yang memakai tier gratis”
    Bahkan tanpa kolusi aktif atau bagi hasil sekali pun, tidak jelas layanan pertahanan DDoS ini sebenarnya berpihak ke mana

    • Kalau begitu apa solusinya?
      Saya setuju dengan kritiknya, tetapi Cloudflare bukan penemu DDoS
      Kalaupun Cloudflare lenyap secara ajaib besok, crawler AI tidak akan berhenti
      Apa alternatifnya? Masa iya dunia internet mengharuskan kita mengunggah identitas resmi pemerintah hanya untuk bisa menjelajah?
    • Di lingkungan lokal atau negara, kita bisa menegakkan kendali terhadap penyerang dan memonopoli kekerasan
      Tetapi kalau kita ingin mempertahankan anonimitas relatif dan sifat global internet, bagaimana caranya?
      Orang-orang mungkin bisa membentuk koperasi untuk menangani pertahanan, tetapi sulit menjalankannya sebagai entitas skala global
      Pertahanan DDoS pada dasarnya banyak bergantung pada kapasitas berlebih yang cukup besar untuk menyerap lalu memfilter, jadi investasi yang dibutuhkan sangat besar
    • Ada penjelasan yang lebih sederhana juga
      Cloudflare, seperti dalam kasus The Daily Stormer[1], meskipun tidak 100%, pada umumnya tidak menyensor konten yang diperkirakan legal yang melewati sistemnya, dan secara sadar memilih untuk tidak menjadi penentu legalitas
      [1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
    • Ini adalah struktur pemerasan uang keamanan yang lahir dari kelemahan mendasar dalam protokol dasar internet
  • Sangat setuju
    Cloudflare melindungi para penipu dalam skala besar dan tidak ada yang peduli
    Toko online palsu yang saya laporkan ke Cloudflare, halaman phishing di balik Cloudflare, tidak ada satu pun yang diturunkan
    Tidak satu pun
    Kalau sebuah perusahaan menghasilkan miliaran dengan melindungi orang, mereka seharusnya menangani hal seperti ini dengan serius

    • Jika Anda tidak menuntut tindakan dari Cloudflare lewat proses hukum, kecil kemungkinan mereka akan mendengarkan
      Misalnya gugatan kecil seperti, “Saya dirugikan 20 dolar dan untuk mengidentifikasi pihak yang akan saya tuntut ganti rugi, saya meminta informasi pembayaran pelanggan yang diberikan ke Cloudflare, bank penerbit, dan nomor rekening,” tampaknya cukup masuk akal
      Saya belum pernah dengar ada yang mencobanya, tetapi kalau ada yang melakukannya saya ingin melihat hasilnya
    • Apakah Anda benar-benar ingin lebih banyak organisasi raksasa yang secara sewenang-wenang menyensor situs web tanpa mekanisme banding atau proses hukum?
      Menurut saya keadaan sekarang jauh lebih baik
  • Saya selalu mengira Ubuntu tumbang karena server Ubuntu dibuat tidak bisa menambal copy.fail, sehingga kelompok peretas itu bisa mengeksploitasi sebanyak mungkin target selama rentang waktu itu

    • Di Ubuntu, mitigasi copy.fail bisa dilakukan dengan beberapa pengaturan modprobe(8)
      # echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
      # rmmod algif_aead
      Mungkin ada proses yang memakai fitur ini (lsof | grep AF_ALG), tetapi setahu saya ini tidak dipakai luas, jadi pada mayoritas sistem menonaktifkannya tidak akan menimbulkan masalah
    • Patch copy.fail bisa diterapkan dengan gangguan minimal, dan VM, berapa pun ukurannya, paling lama hanya butuh reboot 30 detik
      Semua server apex seharusnya diatur dengan high availability agar load balancing tetap berjalan, jadi pengguna biasa tidak akan merasakan apa-apa saat patch copy.fail diterapkan
      Pengguna kami juga sama sekali tidak merasakannya saat kami mendistribusikan patch
  • Itu bukan intimidasi, lebih dekat ke pemerasan
    CF tidak melakukan keduanya

  • Kalau mengikuti logika ini, produsen keyboard juga bisa dianggap bertanggung jawab atas tindakan ilegal yang ditulis dengan produknya

    • Ini bukan penjualan perangkat, ini layanan
      Tetap menyediakan layanan kepada organisasi yang dipakai untuk mendukung aktivitas kriminal adalah hal yang sangat berbeda, dan memutus pelanggan karena aktivitas ilegal bukan sesuatu yang kontroversial
    • Ini bukan kasus yang sama
      Kalau Anda menerima bom dalam paket UPS, itu bukan salah UPS
      Tetapi kalau seseorang memberi tahu UPS bahwa ada orang yang memakai UPS untuk mengirim bom ke orang lain, lalu mereka tidak mengambil tindakan apa pun, bahkan tampak melindungi pengirim bom itu, bukankah di situ ada tanggung jawab tertentu?
    • Ini analogi yang keliru
      Dalam skenario ini, “produsen keyboard” lebih mirip produsen router tempat Cloudflare membeli perangkatnya, bukan Cloudflare itu sendiri
      Dalam analogi ini, Cloudflare lebih dekat ke agregator surat kabar yang memuat berbagai hal kotor bersama komentar normal
      Dalam keadaan biasa, Anda bisa memilih tidak membaca koran kotor itu, dan membiarkan orang yang ingin membacanya memutuskan sendiri
      Tetapi dalam situasi Cloudflare, surat kabar utama yang normal semuanya memutuskan menerbitkan kontennya lewat Cloudflare, dan jika ada hal bermasalah yang terbit bersama mereka, Anda harus mempersoalkannya ke Cloudflare alih-alih ke penerbit aslinya
      Dan Cloudflare mungkin akan meneruskan informasi Anda kepada orang-orang yang sangat tidak menyenangkan tanpa Anda ketahui sebelumnya
    • Atau seperti menyalahkan perusahaan air karena menjual air
      Di mana garis batasnya harus ditarik?