Jika ada masalah, blokir di level IP

• Baru-baru ini, saat menganalisis trafik web, ditemukan bahwa web bot bernama Thinkbot menghasilkan trafik paling banyak
• Bot tersebut mengabaikan robots.txt, dan bahkan kalimat perkenalannya sangat tidak serius, hanya kurang lebih berbunyi “kalau ada masalah, blokir saja IP-nya”
• Selama satu bulan, bot ini menggunakan 74 IP yang berbeda, yang tersebar di 41 blok jaringan
• Hasil investigasi menunjukkan bahwa semua blok jaringan ini dimiliki oleh Tencent, sehingga muncul kecurigaan apakah ini terkait dengan kemungkinan melimpahkan biaya Great Firewall ke pihak luar
• Pada akhirnya ditambahkan aturan pemblokiran besar-besaran yang mencakup lebih dari sekitar 470 ribu IP

---

Kemunculan Thinkbot

• Saat menganalisis trafik web, ditemukan bahwa web bot bernama Thinkbot menempati porsi teratas
• String User-Agent-nya sangat tidak serius, seperti berikut

  “Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In­_the­_test­_phase,­_if­_the­_Thinkbot­_brings­_you­_trouble,­_please­_block­_its_IP_address._Thank_you.)”.

  • Selain kalimat “jika menimbulkan masalah pada tahap pengujian, silakan blokir IP-nya”, bahkan tidak ada URL rujukan
• Bot ini sama sekali tidak menghormati file robots.txt dan tetap melakukan crawling
• Sebagai pengelola situs, upaya untuk memblokirnya juga sulit karena bot ini tidak memakai satu IP saja, melainkan 74 alamat IP
• Setelah ditelusuri balik dan dicek ASN-nya, trafik ini berasal dari 41 blok jaringan
• Ini berarti pertahanan dengan pemblokiran satu IP saja tidak mungkin memadai

Keterkaitan dengan Tencent

• Ke-41 blok jaringan ini semuanya dimiliki oleh Tencent
• Penulis mencurigai bahwa pemerintah Tiongkok bisa saja membiarkan atau mendorong hal ini, dan menafsirkannya sebagai upaya untuk melimpahkan biaya Great Firewall ke dunia luar
• Di dalam Tiongkok, pengumpulan konten tetap diizinkan, dan meskipun diblokir dari luar, dari sudut pandang CCP hal itu bukan masalah; namun bagi negara atau situs lain yang mencoba memblokirnya, ini menjadi beban tambahan

Tindakan pemblokiran firewall

• Penulis secara langsung menambahkan blok jaringan Tencent ke aturan firewall badbots
• Contoh: 43.130.0.0/18, 101.32.0.0/20, 150.109.96.0/19 dan lain-lain
• Total lebih dari 40 blok jaringan ditambahkan; meskipun ini tidak mencakup seluruh IP milik Tencent, aturan tersebut tetap mencakup lebih dari 476.590 IP unik

Kesimpulan dan analogi

• Penulis menggambarkan situasi ini sebagai kenyataan bahwa di internet kita tidak bisa lagi memiliki hal-hal baik
• Ini bukan sekadar contoh pemblokiran trafik bot, melainkan kasus yang menunjukkan menurunnya kepercayaan di seluruh ekosistem internet dan respons defensif yang tak terhindarkan

[aobamisaki]

Kalau memang ada masalah, blokir saja di level IP

Sebenarnya, narasi ancaman Tiongkok di bidang lain sudah lama menjadi kenyataan, dan sekarang Tiongkok tampaknya mulai mengancam keberlangsungan ekosistem internet secara keseluruhan juga.

Ini bukan sekadar pernyataan yang muncul dari sentimen kebencian atau bias politik, melainkan sesuatu yang benar-benar sedang menjadi kenyataan, dan tampaknya banyak orang perlu menyadari hal itu.

[aciddust]

Kenapa setiap kali kejadian seperti ini dibongkar, ujung-ujungnya CCP..

[mango]

Wow.. benar-benar keren..

[choi1]

Keren..

[reagea0]

Ini China lagi.

[GN⁺]

Opini Hacker News

• Saat mengembangkan web crawler, saya berusaha membuatnya seramah mungkin. Saya memeriksa robots.txt dengan ketat, melakukan crawling secara lambat, mencantumkan identitas dengan jelas di string User Agent, dan hanya menggunakan satu alamat IP. Namun, saya jadi mengalami berbagai trik anti-bot yang diterapkan justru pada file robots.txt itu sendiri. Baru-baru ini, robots.txt diunduh sangat lambat seperti serangan slow loris, sehingga tanpa sengaja saya menganggapnya sebagai 404 lalu terus melakukan crawling. Setelah pengalaman itu, saya mengubah kode agar jika timeout maka diperlakukan sebagai Disallow /. Ironisnya, bahkan saat berusaha mematuhi aturan, saya malah harus menulis kode untuk mendeteksi alat anti-bot

  • Rasanya seperti menyembunyikan bel pintu demi mencegah pencuri

  • Seperti di aplikasi server, di sisi klien pun jika lawan terlihat jahat atau berperilaku salah, saya diam-diam memutus koneksi TCP. Pihak sana harus menyadari sendiri setelah membuang-buang sumber daya untuk sementara waktu

  • Saya rasa besar kemungkinan fenomena ini tidak disengaja. Bot jahat yang memang tidak mematuhi aturan robots.txt sejak awal juga tidak akan mengunduh file itu, jadi ini bisa jadi lebih karena kesalahan atau ketidakmampuan daripada niat buruk

  • Sanksi yang hanya menghukum orang yang berusaha patuh pada aturan justru terasa kontraproduktif

  • Saya menghargai usaha untuk benar-benar mematuhi aturan. Membatasi robots.txt mungkin bisa jadi sebuah kesalahan, tetapi beberapa crawler memang mencari halaman yang lebih menarik dari robots.txt, jadi memperlambatnya bisa membantu menghindari masalah dengan cepat. Pada akhirnya, cara seperti ini menghalangi informasi bot dan memperlambat mereka, dan dari sudut pandang operator situs yang dirugikan bot jahat, mereka mau tak mau jadi tidak terlalu peduli membedakan bot jujur dari yang tidak

• Saya penasaran apa kesamaan situs web yang benar-benar dirugikan parah oleh bot. Saya sudah bertahun-tahun menjalankan web server dari rumah dengan TLD .com, peringkatnya juga lumayan tinggi di Google untuk kata kunci terkait, dan saya tidak punya pengaturan khusus pemblokiran bot di router maupun server. Saya pernah menghitung permintaan bot karena penasaran, tetapi kebanyakan hanya melakukan port scan atau mengambil halaman indeks, dan hampir tidak mengikuti tautan yang dimuat secara dinamis. Baik di era Apache 2 maupun sekarang saat menjalankan beberapa situs dengan Axum, saya tidak melihat dampak mencolok dari bot. Mungkin karena directory listing, saya tidak tahu, jadi saya ingin mendengar penjelasannya

• Rasanya banyak orang pintar terlalu terobsesi dengan isu web scraping. Kalau aktivitas bot itu tidak benar-benar menimbulkan beban besar atau masalah serius pada situs, selain beberapa pengecualian tentu saja, kebanyakan ini cuma permainan ‘merebut bendera’ yang tidak berarti. Bedanya, di permainan ini Anda bahkan tidak pernah menemukan bendera lawan, hanya kehilangan waktu. Menurut saya, respons terbaik adalah membuat produk web yang cepat dan dirancang dengan baik meskipun ada banyak peserta yang menyebar dan sulit diidentifikasi yang menimbulkan beban. Secara realistis, pendekatan ini juga sangat meningkatkan kepuasan pengguna manusia yang sesungguhnya

  • Dari pengalaman saya, mungkin Anda hanya belum menyadari seberapa serius masalah ini. Di pekerjaan sebelumnya saya menangani performa aplikasi untuk web app, dan sebagian pengguna memang sangat cepat, tetapi kebanyakan lambat. Saat menganalisis log performa, ternyata 60% dari seluruh request berasal dari bot yang sudah dikenal, belum termasuk bot aneh lainnya. Bahkan ada beberapa perusahaan yang pada praktiknya melakukan serangan DoS ke layanan kami, dan ini pernah membuat situs down. Masalahnya, bot selalu hanya mengambil respons yang sudah di-cache, sehingga percakapan pengguna nyata terus terdorong keluar dari cache LRU. Ada bot yang meng-scrape ulang semua halaman yang pernah dikunjungi setiap beberapa menit, ada juga yang terus menaikkan throughput sampai layanan melambat. Kadang mereka juga mencoba menjalankan JavaScript dan mengirim form. Hanya Googlebot yang satu-satunya berperilaku sopan. Bahkan 40% traffic masuk yang nyata terkonsentrasi pada satu URL saja, jadi manfaat yang didapat dari bot ini pun nyaris tidak ada. Baru belakangan saya sadar bahwa banyak bot itu dipakai perusahaan AI tahap awal untuk mengumpulkan data

  • Seorang teman menjalankan instance gitea kecil yang terbuka untuk publik tetapi hanya dipakai sesama teman. Namun, setiap jam ada ribuan request bot masuk. Walaupun tidak berdampak langsung ke layanannya, setidaknya itu terasa seperti gangguan

  • Saya membayar mahal untuk mendapatkan data demi membuat produk web yang cepat. Jadi dengan memblokir entitas seperti ini, itu bukan buang waktu, melainkan benar-benar bisa menghemat bandwidth dan biaya server. Berkat itu, pelanggan sungguhan juga tetap mendapat manfaat yang sama tanpa kontennya di-scrape. Saya tidak paham logika yang menganggap ini sebagai eksploitasi terhadap seseorang

  • Menurut saya ini lebih mirip permainan whack-a-mole daripada 'capture the flag'. Dari pengalaman pribadi, di forum yang mencoba mengidentifikasi dan memblokir 'bot jahat', selalu muncul lebih banyak bot lagi tanpa akhir

  • Memang banyak orang pintar di antara kita, tetapi kita juga cenderung terlalu terobsesi pada masalah teknis. Jika tidak melakukan apa-apa, rasanya akan terus mengganggu pikiran, dan setidaknya kalau memblokir sesuatu rasanya jadi sedikit kurang menjengkelkan

• Saya selalu heran betapa banyak orang di Hacker News yang menganggap serius robots.txt. Sangat mengesankan bahwa ada begitu banyak orang dengan niat baik. Tetapi robots.txt bukan solusi yang nyata. Orang harus tahu bahwa robots.txt itu ada, lalu harus menambahkan kode pemeriksaan robots.txt ke crawler mereka, jadi ada kompleksitas tambahan. Saya penasaran apakah ada solusi praktis lain. Hal-hal seperti ‘micropayment’ atau ‘Merkle tree besar untuk verifikasi identitas asli’ sudah lama dibicarakan, tetapi tidak pernah benar-benar diimplementasikan

  • Rasanya hampir tidak ada pengembang bot yang tidak tahu soal robots.txt. Hanya saja ada orang-orang yang keliru mengira proyek mereka adalah kasus istimewa yang boleh mengabaikan aturan semua orang

  • robots.txt tidak punya kekuatan hukum

• Kami juga melihat pola bot seperti itu di log kami. Cukup mengganggu, tetapi setidaknya mereka mengaku sebagai bot dan traffic nyatanya tidak banyak. Sebagian besar traffic justru berasal dari bot yang berpura-pura sebagai browser sungguhan, atau masuk dari berbagai IP di Brasil dan Asia. Saya sudah mencoba segala macam cara selama seminggu terakhir untuk memblokir bot, jadi saya bagikan pengalaman yang mungkin berguna.

  • Ada request dari ratusan IP, tetapi masing-masing hanya beberapa kali sehari, dan semuanya menyamar dengan UA nyata

  • Mereka hampir tidak pernah mengirim URL referrer, tetapi bot Huawei Cloud kadang mengirim referrer juga, meski traffic-nya kecil

  • Upaya utama saya adalah membatasi bandwidth URL yang mengandung id= menjadi 1Kb/s dengan harapan jika lambat mereka akan menyerah, tetapi bot sama sekali tidak peduli dan tetap terus meminta

  • Mereka juga beradaptasi dengan koneksi keep-alive, jadi saya mematikan keep-alive sepenuhnya di /cgit/, tetapi tetap saja mereka menghabiskan semua koneksi

  • Metode yang saya pakai sekarang adalah hanya mengizinkan URL dengan id= jika ada query string notbot; jika tidak ada referrer, saya tampilkan pesan 403 yang memberi tahu bahwa jika Anda pengguna sah, tambahkan parameter notbot. Cara ini mengurangi beban dan memperbaiki koneksi pengguna sah, tetapi bot tetap terus meminta dan hanya menerima 403 berulang-ulang

  • Kesimpulannya, sepertinya hanya ada dua pilihan: memakai pendekatan ad hoc yang disesuaikan per situs, atau menyerahkannya ke pihak seperti Cloudflare yang punya sumber daya cukup besar. Solusi pemblokiran bot yang standar punya keterbatasan karena pihak yang punya banyak sumber daya pada akhirnya bisa mengakalinya atau sanggup menanggung biayanya

  • Ada juga cara memblokir lebih awal dengan 403 untuk substring UA yang jarang dipakai seperti MSIE 3.0 atau HP-UX. Setelah itu kumpulkan log 403 dan blokir ASN yang bermasalah secara terpisah, lalu ulangi lagi permainan whack-a-mole itu

  • Saya memakai perangkat lunak keluarga publicfile dari djbwares milik Bernstein. Saya juga menambahkan alat static GEMINI UCSPI-SSL, dan mengambil ide dari spesifikasi GEMINI untuk melarang fragment dan query parameter dalam URL request. Alasannya sama seperti logika pelarangan di GEMINI, dan itu juga bisa diterapkan pada layanan HTTP statis. Dalam konfigurasi server, untuk menangani query parameter dengan benar saya harus membuat banyak nama file aneh secara terpisah, dan itu tidak realistis. Berkat ide ini, percobaan serangan terhadap kerentanan CGI atau PHP bahkan tidak pernah mencapai filesystem, karena sudah disaring di tahap pemecahan request. Bagi operator situs statis, saya merekomendasikan memblokir query parameter seperti di GEMINI. Tentu saja ini pengecualian jika dalam kategori situs statis Anda benar-benar ingin memakai query parameter

• Sejak suatu waktu saya mulai bertanya-tanya apakah pendekatan menggunakan whitelist rentang IP benar-benar mungkin dilakukan. Saya juga membayangkan pendekatan yang dikelola lewat upaya komunitas seperti daftar adblock

  • Sayangnya, justru bot yang paling patuh biasanya memakai IP yang stabil, sedangkan pelaku jahat kapan saja bisa memakai proxy rumahan. Jika Anda melarang IP proxy residensial, pengguna nyata bisa ikut terdampak, dan pelaku jahat tinggal pindah ke tempat lain. Dari pengalaman menghadapi ribuan IP nyata, informasi berbasis IP saja sulit dijadikan dasar keputusan; perlu informasi tambahan

  • Perusahaan Pokémon Go juga pernah mencoba cara ini untuk mencegah scraping setelah peluncuran. Mereka membagi IP ke dalam tiga kategori: blacklist (Google Cloud, AWS, dll.), IP tidak tepercaya (residensial), dan whitelist (IPv4 normal, dll.). Awalnya cara ini berhasil menangkap scraper utama, tetapi scraper terbesar justru mengoperasikan peternakan modem terminal untuk mengakalinya. Akibatnya, pengguna biasa menyerah bermain tanpa peta, sementara pemain hardcore malah meningkatkan penggunaan scraper berbayar. Pada akhirnya beban server justru bertambah. Saya menganggap ini salah satu dari banyak keputusan buruk yang pernah dibuat Pokémon Go

  • Banyak perusahaan AS sudah menerapkan ini. Namun, saat Anda berada di luar negeri dan mereka tetap menagih tanpa menyediakan cara untuk membatalkan layanan, itu jelas tidak masuk akal

  • Whitelist dan blacklist tidak harus dipilih secara biner. Sebagian besar traffic ada di wilayah abu-abu. Jika suatu IP sudah dimasukkan ke whitelist lalu terdeteksi gejala aneh, Anda harus menghapusnya dari whitelist, mengumumkannya, memberi tahu pihak terkait, menerima notifikasi, lalu berkoordinasi lagi sampai masalahnya dianggap selesai; secara praktis ini sangat rumit. Whitelist hanya efektif di antara mitra yang punya hubungan saling percaya. Blacklist berguna untuk memblokir alamat yang bermasalah, atau CIA, Rusia, Tiongkok, penyedia cloud, dan sebagainya. Pendekatan realistisnya adalah hanya memasukkan ke whitelist tempat-tempat seperti host internal perusahaan yang punya sistem anti-penyalahgunaan yang kuat

  • Saya sedang membuat whitelist bot positif melalui proyek open source GoodBots. PR sangat diterima

• Saya memakai cara mengirim semua request dengan header kustom, lalu memblokir semua request lainnya

• Di sisi luar saya memakai proxy Cloudflare, dan secara internal saya menempatkan Crowdsec dan Modsecurity CRS di depan Traefik. Setelah disetel agar mengurangi false positive, sistem ini berjalan sangat stabil. IP yang diblokir sementara dan IP yang dilaporkan saya kirim ke Crowdsec, lalu log-nya diposting ke kanal Discord. Rata-rata saya memblokir puluhan IP berbeda per hari. Dari pengamatan saya, percobaan mengakses resource privat atau menargetkan CVE jauh lebih sering datang dari IP AS daripada IP Tiongkok. Saya tidak peduli pada crawling konten publik; sisanya semua hanya bisa diakses lewat SSO atau intranet. Memblokir upaya exploit atau flooding itu sendiri lebih efektif daripada memblokir negara tertentu

  • Pendekatan seperti Crowdsec memang menarik, tetapi saya menganggap menyerahkan seluruh traffic server ke perusahaan komersial sebagai risiko besar

  • Pada akhirnya percobaan serangan yang serius kemungkinan besar sudah diblokir di tempat seperti Cloudflare WAF

• Banyak gedung apartemen hanya bisa keluar ke internet lewat beberapa alamat IP saja (lihat Carrier-grade NAT)

  • Itulah sebabnya pemblokiran IP bisa menimbulkan false positive. Tapi saya tetap menganggap penerapan prinsip seperti ini ada nilainya. Pada akhirnya ada tanggung jawab terhadap tetangga juga

• Lebih dari separuh traffic saya berasal dari bot Bing, Claude, dan Facebook. Mereka bukan penyumbang traffic utama, tetapi hanya menghabiskan sumber daya server dan menjadi penyebab utama saat situs melambat (AI, Microsoft, dan Facebook sering kali mengabaikan akal sehat). Tiongkok dan sejenisnya hanya sebagian dari traffic jahat; masalah sebenarnya adalah perusahaan-perusahaan AS yang mengabaikan robots.txt atau DNS rate limit

  • Saya punya banyak pertanyaan yang membuat penasaran, dan saya menanyakan semuanya ke Claude. Infrastruktur seperti ini memang belum ada, tetapi saya ingin model bisnis di mana operator situs diberi kompensasi sebanding dengan sumber daya yang dipakai LLM pilihan saya karena pertanyaan-pertanyaan bodoh saya. Semacam YouTube Premium yang membayar kreator. Meski secara praktis rasanya mustahil