Memblokir koneksi dari AWS ke layanan on-premises saya

 (consulting.m3047.net)
1 poin oleh GN⁺ 2024-09-01 | 1 komentar | Bagikan ke WhatsApp
  • Internet publik dapat terpecah menjadi ekosistem terfragmentasi yang berpusat pada penyedia cloud besar, dan pemblokiran akses dari AWS ke on-premises ini adalah contoh operasional yang menunjukkan arah tersebut
  • Sasaran pemblokiran terutama adalah upaya koneksi TCP yang dibuka klien di dalam AWS ke layanan on-premises, sementara koneksi keluar dari klien lokal ke layanan yang di-host di AWS tetap dimungkinkan
  • Layanan on-premises yang dioperasikan mencakup web, demo Trualias, DNS, dan SMTP; DNS menyediakan fallback UDP dan TCP serta akses publik terbatas untuk telemetri keamanan
  • Pemblokiran AWS berawal dari respons terhadap traffic ping berlebihan dan crawler/scanner yang abusive, dan saat ini mengelola 53 CIDR ruang alamat AWS yang diamati sebagai target atau sumber abuse
  • Jika penyedia cloud besar tidak memublikasikan informasi forensik seperti reverse DNS, whois, namespace DNS, dan pola abuse dengan lebih baik, fragmentasi yang hampir tidak dirasakan pengguna di dalam cloud dapat makin menguat

Kemungkinan fragmentasi yang diciptakan cloud besar

  • Jika penyedia cloud besar menjadi bulletproof infrastructure yang “too big to fail”, mereka dapat secara langsung menyebabkan fragmentasi internet
  • Fenomena ini belum sepenuhnya menjadi kenyataan, tetapi dipandang sudah mulai terjadi atau akan segera muncul
  • Ekosistem cloud native memiliki infrastruktur yang disesuaikan dibandingkan internet nyata, dan tiap layanan cloud disusun di sekitar fitur yang membedakannya, bukan arsitektur umum
  • Banyak layanan berjalan secara mandiri di dalam cloud tertentu, dan ada hambatan terhadap interoperabilitas yang transparan dengan internet umum
  • Komunitas cloud native memperlakukan internet umum seperti sumber daya eksternal, dan lebih banyak berinteraksi dengan ekosistem penyedia cloud tertentu daripada dengan internet itu sendiri

Arus komersialisasi internet publik

  • Sebelum 1989, internet tidak memiliki akses publik umum, dan merupakan jaringan bersifat privat yang digunakan lembaga pemerintah, militer, riset, dan pendidikan
  • NSF mengelola inti backbone, dan akses publik awal diizinkan dengan syarat traffic nonkomersial
    • Layanan komersial itu sendiri tidak dilarang, tetapi traffic yang melewati backbone NSFNet tidak boleh berupa iklan atau traffic layanan berbayar
  • Penyedia komersial membangun internet komersial terpisah, dan pada 1995 NSFNet menonaktifkan akses publik
  • Setelah seleksi besar-besaran sekitar tahun 2000, model iklan berbasis data perilaku pengguna dan penjualan data perilaku pengguna bertahan
  • Dalam arus AI saat ini, yang menonjol adalah pengumpulan massal konten yang dapat diakses, lalu “dicuci” untuk digunakan dalam pelatihan model; kurasi dan pelatihan terutama dilakukan di cloud, dan semakin sering oleh penyedia cloud itu sendiri

Memblokir koneksi AWS pada layanan on-premises

  • Sebagian besar akses masuk dari AWS ke server on-premises dinonaktifkan
  • Secara teknis, fokus utamanya adalah traffic TCP, dan klien serta server dapat dibedakan melalui handshake awal
    • Klien di dalam AWS yang mencoba terhubung ke layanan on-premises diblokir
    • Klien di jaringan lokal yang terhubung ke layanan yang di-host di AWS tetap dimungkinkan
  • Beberapa layanan yang dibuka ke internet dijalankan secara lokal
    • Layanan web
    • Demo Trualias
    • Server DNS
    • Server email SMTP
  • Selama bertahun-tahun, kebijakan no crawl dipertahankan, dan aset yang disediakan terutama ditujukan untuk pengguna individual di internet
  • Server DNS menggunakan UDP dan fallback TCP serta menyediakan telemetri keamanan publik terbatas
    • Contoh kueri: dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt
    • Ini juga dapat berguna bagi layanan yang berjalan di cloud, tetapi jika ingin bergantung padanya untuk operasi, diharapkan menghubungi terlebih dahulu

Reverse DNS dan pengecualian SMTP

  • Jika masalahnya hanya layanan web, langkah mitigasi lain seperti pemeriksaan reverse DNS dapat digunakan
  • Penyedia cloud sering mengoperasikan reverse DNS dengan buruk, dan ini sesuai dengan narasi bahwa resource di dalam cloud bersifat sementara
  • AWS cenderung lebih baik dalam reverse DNS dibanding banyak penyedia cloud lain, dan kabarnya reverse DNS untuk instance dapat disetel, tetapi belum pernah dicoba langsung
  • SMTP diberi pengecualian
    • Kecuali masalahnya sangat parah, koneksi ke server mail tetap diizinkan meskipun koneksi layanan lain diblokir
    • Secara teknis SMTP dapat dijalankan tanpa reverse DNS yang akurat, tetapi dalam praktiknya pihak lain tidak akan menerima email jika tidak ada reverse DNS yang akurat
  • Dengan mengevaluasi reverse DNS, dapat dibuat penilaian awal apakah SYN berasal dari server mail yang sah
    • Layanan reputasi dapat memberi skor pada reverse DNS
    • Ada pola yang umum pada resource sewaan dan sementara
  • Dari ada-tidaknya atau bentuk reverse DNS saja, dapat diperkirakan secara wajar apakah sebuah alamat termasuk milik penyedia cloud

Alasan pemblokiran alamat AWS dimulai

  • Ini berawal dari pemblokiran netblock yang dapat diidentifikasi milik beberapa layanan abusive, lalu berlanjut menjadi bukti konsep untuk memblokir secara selektif penyedia hosting kecil
  • Dalam kasus AWS, titik awalnya adalah traffic ping berlebihan
    • Ping adalah protokol tanpa koneksi, sehingga asalnya dapat dipalsukan
    • Respons atas permintaan ping yang dipalsukan akan dikirim bukan ke penyerang, melainkan ke lokasi nyata yang dipalsukan tersebut
  • Untuk menekan respons ping tanpa henti, perlu dibuat aturan firewall sementara, tetapi skala Amazon terlalu besar sehingga jumlah aturannya menjadi banyak
  • Rentang alamat AWS mulai dikumpulkan, dan saat ini ada 53 CIDR yang mewakili ruang alamat AWS yang diamati sebagai target abuse atau sumber abuse
  • Terkadang aturan firewall sementara hingga dua kali lipat jumlah itu juga diamati
  • Memblokir crawler dan scanner abusive yang disewa dari penyedia cloud “too big to fail” adalah efek samping yang baik, dan tidak disayangkan jika mereka menghilang dari log web

Dampak yang dialami pengguna cloud

  • Sebagian besar resource populer atau resource yang berpotensi di-deploy ke cloud di-host di GitHub
  • Orang yang men-deploy resource lain ke cloud harus mempertahankan repositori sendiri untuk staging
  • Jika repositorinya berada di AWS, pemeriksaan update tidak lagi bisa dilakukan
    • Harus memeriksanya dari desktop
    • Harus memeriksanya dari resource hosting privat
    • Arrangement terpisah dapat dibahas
  • Keadaan hanya memiliki smartphone, bucket S3, dan instance EC2 sulit disebut “berada di internet”, tetapi dari smartphone seharusnya tetap bisa mengakses resource semacam itu

Mitigasi pencurian data dan penggunaan yang tidak dimaksudkan

  • Pencurian data, yaitu materi open source yang diambil alih tanpa izin untuk tujuan yang tidak dimaksudkan, juga merupakan ancaman yang memerlukan mitigasi tersendiri
  • Pemblokiran AWS juga berfungsi sebagai salah satu mitigasi semacam itu
  • Materi terkait cats, bunnies, dan birds juga dibahas bersama dalam konteks mitigasi
    • cats dan bunnies muncul karena ada sangat banyak video terkait dan sebagian dapat dibeli
    • birds lebih efektif pada OSI layer 2, dan didokumentasikan dalam RFC sebagai metode pengiriman IP datagram

Informasi publik yang dibutuhkan dari penyedia cloud besar

  • Penyedia cloud besar perlu menyediakan sistem distribusi informasi forensik yang lebih baik daripada saat ini
  • DNS dan whois berpotensi menjadi alat untuk mendistribusikan informasi yang berguna
  • Penyedia besar seharusnya dapat mengoperasikan reverse DNS sendiri
  • Mungkin diperlukan whois untuk tiap alamat, informasi tambahan yang dienkodekan dalam reverse DNS, serta informasi publik terpisah di namespace DNS
  • Storm center blog yang membahas pola abuse saat ini dan blok alamat yang terdampak juga merupakan salah satu cara yang mungkin
  • Pada SMTP, selain reverse DNS, ada SPF yang dipublikasikan melalui record DNS TXT
  • Dengan hanya satu alamat IP, seharusnya informasi untuk menjawab pertanyaan berikut dapat ditemukan
    • Apakah resource di balik alamat tersebut mengirim ping
    • Berapa banyak ping yang dikirim
    • Apakah membuat koneksi TCP outbound
    • Terhubung ke layanan apa
    • Siapa yang mengendalikan resource tersebut
    • Apakah resource sedang diserang
    • Jenis serangannya apa
    • Mitigasi seperti apa yang diinginkan dari resource lain di internet
  • Mitigasi yang tepat membantu semua pihak, tetapi mitigasi yang salah sasaran tidak demikian

Akibat dari internet yang terfragmentasi

  • Jika cara seperti ini meluas, hal itu dapat mengarah pada balkanized internet
  • Orang yang menjalani kehidupan online di dalam gelembung penyedia cloud besar mungkin hampir tidak menyadari ketidaknyamanannya
  • Ketidaknyamanan yang disadari pun dapat dianggap sebagai akibat memilih penyedia cloud tertentu

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-01
Komentar Hacker News

  • Semua penyedia cloud besar memublikasikan daftar rentang IP yang dapat dibaca mesin
    Contoh: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-rang...
    https://www.microsoft.com/en-us/download/details.aspx?id=565...
    https://support.google.com/a/answer/10026322?product_name=Un... dan lain-lain

    • Saya belum mengeceknya hari ini, tetapi misalnya file JSON Amazon pada dasarnya menyamarkan fakta bahwa mereka menggunakan 3.0.0.0/8, terlepas dari apakah mereka benar-benar memilikinya atau tidak
      Saya tidak berniat memainkan semacam permainan “mari blokir daftar JSON raksasa Amazon”, dan aturannya hanya 53 buah. Saya bisa menerima sejumlah efek samping, dan situs-situs yang berada di AWS juga tetap bisa diakses dengan baik

  • Di internet sekarang, kecepatan munculnya trafik agresif begitu infrastruktur dipublikasikan itu gila
    Baru-baru ini saya mengiklankan satu subnet /23 lewat BGP untuk konfigurasi anycast, dan begitu route naik serta trafik mulai mengalir ke router, tcpdump langsung membanjiri layar dengan port scan ke semua IP dalam rentang itu
    Tentu saja bukan karena route itu sendiri; sepertinya banyak pihak memindai semua rentang IP secara membabi buta dan terus-menerus. Rentang ini tidak diiklankan selama bertahun-tahun, jadi kecil kemungkinan ia ada di daftar server aktif seseorang
    Mengejutkan bahwa layanan web internal seperti GitLab masih dibiarkan terekspos langsung ke internet. Menurut saya setidaknya harus ada lapisan perlindungan tambahan seperti VPN agar layanan tidak dapat ditemukan dari internet publik
    Satu-satunya yang bisa diakses publik hanyalah SSH ke satu host bastion, dan nantinya saya juga ingin menghilangkannya dengan menambahkan lapisan VPN

    • Lebih baik menyesuaikan ulang ekspektasi. Port scan bukan hal besar, dan bahkan agak sulit disebut serangan; itu seperti radiasi latar internet
      Seperti di ruang angkasa ada radiasi latar, di internet juga ada radiasi latar internet. Jika Anda tidak menjalankan layanan yang rentan, port scan semacam ini risikonya kurang lebih setara dengan makan satu pisang ekstra dalam sebulan
      Itu terasa mengganggu hanya karena Anda melihatnya langsung di konsol. Sama seperti membawa penghitung Geiger yang terlalu sensitif ke pesawat bisa membuat Anda kaget, tetapi jika Anda tidak mengetahuinya, itu tidak membahayakan
      Saya juga terkejut dengan layanan internal yang terekspos ke internet, alasannya ada dua. Saya tidak memercayai sistem autentikasi kebanyakan program, dan saya tidak ingin pihak luar tahu layanan internal apa yang digunakan. Ada juga alasan yang lebih dekat ke privasi daripada keamanan teknis murni
      Sebaliknya, hal-hal yang memang harus berada di internet, punya pintu depan yang kuat, atau diyakini cukup tersandbox, boleh saja berada di internet sepanjang hari
      Port scan adalah versi internet dari berkeliling kota dan mencatat rumah mana yang lampunya menyala. Memang bisa terasa agak seperti penguntit, tetapi itu informasi publik
      Sebagai catatan, ssh -w membuat antarmuka tunnel VPN, tetapi tidak otomatis mengonfigurasi pengaturan lainnya seperti produk VPN sungguhan
    • Kalau ingin menambahkan lapisan VPN di atasnya, saya penasaran perangkat lunak VPN apa yang akan dipakai. Secara pribadi, saya belum menemukan yang terasa dapat dipercaya seperti OpenSSH
    • SSH publik yang salah konfigurasi sama sekali tidak boleh dipasang. Secara harfiah bisa ditembus dalam hitungan detik
      Internet makin terasa seperti sesuatu yang terjadi di balik blackwall dalam Cyberpunk
    • Ini bukan hanya soal “sekarang”. Bahkan 25 tahun lalu, cukup umum skrip atau bot terus memeriksa server web yang terekspos, dan itu sering terlihat di log akses web
      Jika log akses yang ditolak di firewall diaktifkan, percobaan ke port yang dikenal maupun tidak dikenal akan mengalir masuk terus-menerus
      Jika Anda mengekspos sesuatu, bahkan komponen web yang disembunyikan jauh di dalam, pastikan itu tidak menjadi pintu masuk ke data dan infrastruktur
      Yang sedikit berbeda dibanding dulu adalah sumber trafiknya, serta kriteria untuk memutuskan apakah harus menerima atau memblokirnya. Jumlah server/layanan legal, proxy di sisi pengguna akhir, penyedia cloud, dan crawler meningkat pesat
    • Ini terdengar seperti masalah yang khusus untuk IPv4. Kalau beralih ke IPv6 saja, bukankah pemindaian IP praktis tidak realistis bagi pelaku jahat?

  • Ini benar-benar disayangkan. Dengan begitu, konten Anda sama sekali tidak akan muncul di mesin pencari, tidak tertangkap oleh Marginalia, dan berisiko tidak tersimpan juga di Wayback Machine
    Jika memang itu yang diinginkan, mungkin memang tepat untuk memblokir semua cloud dan pusat data. Bahkan, tergantung di mana sebuah ISP kecil menjalankan gateway CGNAT-nya, pengguna ISP itu pun bisa ikut terblokir. Kemungkinannya kecil, tetapi bukan mustahil
    Penyalahgunaan nyata yang disebutkan dalam tulisan itu tampaknya hanya ping dengan alamat sumber yang dipalsukan. Tidak bisa diketahui apakah paket ping yang dipalsukan itu berasal dari AWS. Sebab alamat sumber adalah alamat yang diinginkan spoofer untuk menerima balasan, bukan alamat milik spoofer
    Mitigasi yang jauh lebih tidak invasif adalah melakukan pembatasan laju pada ping, misalnya sekitar 10 per detik
    Internet memang sedang mengalami balkanisasi, tetapi penyebab utamanya bukan pemblokiran rentang IP, melainkan media sosial yang menjadi silo demi pendapatan iklan dan data, serta tren memonetisasi data untuk pelatihan AI. Contoh seperti kontrak eksklusif Reddit/Google lebih mendekati hal ini
    Sulit memahami pola pikir yang mengeluh bahwa konektivitas IP mengalami balkanisasi sambil memblokir penyedia tertentu hanya karena beberapa ping. Yang menciptakan balkanisasi adalah pihak yang memblokir

    • Di mesin pencari sekarang hampir tidak ada yang muncul selain situs besar seperti ladang konten raksasa penuh iklan, Wikipedia, Stack Overflow, situs berita dan media besar, serta YouTube
      Sudah cukup lama sejak blog pribadi atau situs hobi kecil terlihat di hasil pencarian
      Jika butuh Wikipedia atau Stack Overflow, kita bisa mencari langsung di situs tersebut. Saya berharap ada opsi untuk mengecualikan “kandidat yang selalu muncul” dan melihat konten berekor panjang yang lebih luas
    • Ini tampaknya keluhan karena “terpaksa” mengambil langkah yang dapat menyebabkan balkanisasi
      Namun nada keseluruhannya lebih terasa seperti merangkai gigitan nyamuk menjadi narasi sejarah yang megah
    • Meski ISP kecil sekalipun, mengapa mereka menjalankan gateway CGNAT di tempat yang bukan ruang IP mereka sendiri?
      Menjalankan gateway CGNAT di cloud kemungkinan akan menimbulkan banyak masalah. Pelanggan tidak lagi terlihat memakai IP residensial, sehingga mungkin tidak bisa menonton layanan seperti Netflix, dan besar kemungkinan lebih sering berhadapan dengan CAPTCHA anti-bot dari Cloudflare atau Google
      Saya penasaran apakah ada contoh nyata yang diketahui
    • Saya penasaran apa asumsi yang membuat “tidak muncul di mesin pencari” dipandang sebagai kekurangan atau kerugian. Saya tidak berbagi pandangan itu, tetapi sedang mencoba memahaminya
    • Penulis sudah lama mengatakan bahwa ia mempertahankan kebijakan melarang crawling. Mungkin ia tidak akan peduli, dan melihat enshittification Google, itu mungkin justru pilihan yang tepat

  • Hetzner, DigitalOcean, Linode, OVH, dan Contabo sudah saya blokir selama beberapa waktu
    Ini bisa dilakukan dengan pemblokiran ASN di pfBlocker NG, atau dengan aturan UFW: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...

    • Jika memblokir secara menyeluruh seperti ini, organisasi yang sah bisa saja tidak dapat mengakses situs. Jika itu situs yang menjual sesuatu, ini bisa menjadi masalah
      Misalnya, jika suatu organisasi menjalankan sendiri WireGuard atau solusi VPN lain di atas penyedia cloud, lalu orang-orang mengakses lewat sana, IP keluar akan terlihat sebagai IP penyedia cloud
    • Saat ini banyak perusahaan besar maupun kecil memakai VPN atau solusi serupa dengan exit node di cloud. Pemblokiran seperti ini pada akhirnya bisa membuat komputer kerja tidak dapat mengakses situs web
    • Astaga, kenapa sampai Hetzner juga?
    • Menurut saya ini seharusnya bersifat resiprokal seperti di dunia nyata. Jika seseorang memblokir sebuah penyedia, penyedia itu juga harus bisa memblokir balik
      Ini bahkan bisa dibuat otomatis. Dengan begitu adil dan tiap pihak tahu apa yang terjadi. Kalau tidak, daripada main-main kotak pasir seperti ini, pakai saja senjata sungguhan

  • Hal pertama yang terpikir oleh saya adalah desktop nyata yang berjalan di AWS, terutama layanan seperti Amazon Workspaces, bisa ikut terblokir
    Namun tampaknya ruang IP untuk layanan seperti itu juga didokumentasikan secara publik, jadi jika perlu IP tersebut bisa diizinkan secara terpisah
    Meski begitu, dengan memakai proxy atau VPN, pemblokiran semacam ini sangat mudah dilewati

    • Bagi Anda mungkin mudah. Namun melihat banyak orang yang belakangan berbondong-bondong ke serverless, tampaknya sebagian besar teknisi pun tidak ingin mengurus jaringan atau infrastruktur mereka sendiri

  • Dulu sekali, puluhan server Amazon mulai membuat server on-premise kami lambat, jadi kami melakukan hal seperti ini
    Mungkin itu semacam upaya SSO, tetapi kami tidak pernah benar-benar melacaknya sampai tuntas. Kami hanya membuat skrip yang secara berkala mengunduh daftar rentang IP Amazon dan memblokir semuanya, lalu selesai

  • Saya paham. Jika saya ingin membangun tembok terhadap sebagian besar internet dari sesuatu yang saya buat, saya juga akan melakukan hal yang sama. Tidak jauh berbeda dengan memblokir seluruh negara
    Saya juga memahami keinginan untuk mengurangi kebisingan dan hanya mengizinkan “kelompok kecil teman”
    Namun saya melakukannya hanya pada layanan tertentu, bukan seluruh domain. Server Mumble saya hanya dibuka untuk 3–4 negara tempat teman-teman saya berada, dan penyedia cloud dikecualikan. Blog teknis saya saya biarkan bisa dilihat siapa pun di seluruh dunia
    Saya teguh pada pandangan bahwa pengetahuan bersama bermanfaat bagi semua orang. Jika catatan saya tentang string inisialisasi modem untuk modem C64 300 baud membantu bahkan satu orang saja, orang itu tidak perlu mengulangi penderitaan yang saya alami, dan dunia menjadi sedikit lebih baik
    Saya memahami dorongan seperti itu muncul karena berbagai alasan. Tidak apa-apa. Masing-masing silakan mengurusnya sendiri

    • Zen InterSLIP Dialing Script yang saya tulis secara harfiah berkeliling dunia
      Amazon terlalu besar untuk diabaikan. Saya paham banyak lalu lintas ICMP dan SYN adalah sampah. Saya juga ingin membantu pemblokiran, dan sebenarnya mitigasi sudah saya siapkan secara default
      Masalahnya, Amazon mengganggu mitigasi saya “dalam skala besar”, sehingga merepotkan. Amazon tidak membantu memilah mana sekam dan mana biji. Pendekatannya seperti “kirimkan PCAP untuk masalah ping”
      Jika saya mengirim materi ke Amazon dan tidak mendapat respons apa pun, tidak ada yang bisa dipelajari. Saya tidak butuh lalu lintas baik maupun buruk, maupun lalu lintas spoofing yang menyerang mereka
      Jika mereka tidak berniat membantu saya agar bisa membantu mereka, saya tidak membutuhkan semuanya. Saya hanya berusaha menjaga hidup saya tetap sederhana

  • Melihat hal seperti ini membuat saya merindukan internet yang dulu. Sulit sekali menjelaskan betapa kerennya internet sebelum komersialisasi
    Kesenangan pahit karena pernah menebak dengan tepat bahwa hasil akhirnya akan seperti ini sama sekali tidak cukup sebagai kompensasi atas apa yang hilang

    • Ah, benar. Omong kosong bernuansa nostalgia. Internet sejak awal memang soal uang

  • Dibandingkan tempat seperti DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent, bahkan Google, AWS itu masih setingkat Pramuka
    Khususnya DigitalOcean, menurut saya membuat kesalahan besar dengan memasarkan diri ke komunitas “keamanan siber”

    • Sebenarnya kalau membaca tulisannya, ada kalimat “sebagai proof of concept, saya memblokir beberapa penyedia hosting kecil”, dan itu merujuk ke DigitalOcean. Karena alasan yang Anda sebutkan

  • Pengungkapan kepentingan: AWS saat ini adalah pemberi kerja saya
    Mungkin saya melewatkan sesuatu yang jelas, tetapi jika penulis percaya traffic ping itu dipalsukan, bagaimana ia tahu sumbernya adalah AWS?

    • AWS punya reputasi sangat buruk sebagai sumber penyalahgunaan dalam jumlah besar, serta scraper dan crawler murahan. Crawler buruk dan serangan sungguhan sering kali sulit dibedakan
      Dari pengalaman, saya terlalu sering melihat traffic yang luar biasa besar berasal dari AWS, dan dalam beberapa kasus akhirnya sampai pada solusi yang sama, yaitu memblokir seluruh AWS
      Saya tidak tahu apakah AWS tidak peduli atau responsnya lambat. Bisa jadi proses pelaporannya terlalu sulit
      Hal jelas yang terlewat adalah ini: AWS adalah sumber raksasa traffic “buruk”, dan terlalu sulit menghentikan pelanggan yang bermasalah, sementara terlalu mudah bagi pelaku jahat untuk menyewa kapasitas yang tidak masuk akal
      Saya hampir tidak pernah melihat GCP atau Azure menjadi sumber traffic gila pada tingkat yang sama