Mengerahkan Berbagai Alat Kecil untuk Memblokir Bot

• Karena crawling dan scraping serampangan oleh perusahaan AI/mesin pencari besar, server dan layanan pribadi terdampak serius, dengan konsumsi sumber daya dan ketidakstabilan layanan yang terus terjadi
• Setelah mendeteksi trafik abnormal dengan pemantauan berbasis Zabbix·Loki, alat analisis log (lnav, goaccess) dan kueri berbasis SQL digunakan untuk mengidentifikasi secara rinci pola penyerang, IP, dan User Agent
• Dengan membangun sistem pertahanan bertahap di konfigurasi Nginx seperti pemblokiran 403 berbasis User Agent, rate limit, dan integrasi Fail2Ban, ratusan IP berbahaya berhasil diblokir dan stabilitas server dipulihkan
• Masalah utama adalah bot yang mencoba mengunduh seluruh repositori Gitea dalam bentuk tarball secara massal, dan trafik untuk tujuan pengumpulan data AI/pelatihan model meningkat tajam, bukan sekadar konsumen konten biasa
• Dalam jangka panjang, penulis mempertimbangkan strategi untuk memberi pengecualian pada layanan sah (seperti archive.org), tetap mempertahankan visibilitas di mesin pencari, namun melawan enshittification AI

---

Pendahuluan: Trafik bot membanjiri server kecil saya

• Belakangan ini, trafik dalam jumlah besar yang tidak jelas asalnya meningkat tajam pada blog lambdacreate yang dikelola secara pribadi serta beberapa layanan lain
• Layanan sah seperti Archive.org disambut baik, tetapi crawling data yang serampangan oleh perusahaan besar seperti Amazon, Facebook, OpenAI merugikan situs
• Seiring meningkatnya permintaan pengumpulan data untuk hal-hal seperti pelatihan model AI, fenomena ini menjadi makin serius
• Dalam situasi ini, alih-alih pembaca sungguhan (manusia), yang dihadapi justru terutama trafik bot dalam jumlah besar

Memastikan masalah: Mendiagnosis lonjakan trafik lewat alat pemantauan

• Alat pemantauan seperti Zabbix dan Loki digunakan untuk menganalisis konsumsi sumber daya server
• Terjadi peningkatan data pada instance Gitea hingga 20~30GB per hari, disertai berbagai peringatan CPU/memori
• Hasil analisis trafik nginx menunjukkan rata-rata bulanan 8req/s → melonjak sesaat hingga lebih dari 20req/s
• Trafiknya memang tidak berskala sangat besar, tetapi naik hampir 10 kali lipat dari biasanya dan menyebabkan kehabisan sumber daya

Analisis penyebab serangan: Analisis mendalam file log

• Log akses nginx dianalisis dengan SQL menggunakan lnav dan goaccess
  • Mengidentifikasi pola seperti IP pengunjung, UserAgent, dan Referrer
• Hasilnya menunjukkan bahwa ini bukan trafik rujukan dari layanan atau komunitas tertentu, melainkan crawling massal dari rentang IP tertentu
• Ditemukan banyak nilai UserAgent yang secara eksplisit menyebut atau memalsukan Amazonbot, OpenAI, Applebot, Facebook
• Karena hal ini mulai mengganggu penggunaan layanan yang sebenarnya, kebutuhan akan kebijakan pemblokiran yang kuat pun muncul

Solusi: Menggabungkan beberapa lapisan pertahanan seperti Nginx dan Fail2Ban

• Menggunakan Nginx map untuk segera mengembalikan 403 bagi UserAgent berbahaya, sekaligus menerapkan rate limit (pembatasan kecepatan kunjungan)
• Beban server diminimalkan dengan menurunkan frekuensi permintaan web bahkan untuk bot baru yang belum terdeteksi
• Berdasarkan log kemunculan 403, goaccess dan lnav digunakan untuk mendeteksi IP dan UserAgent berbahaya yang baru
• Dengan alat keamanan otomatis Fail2Ban, IP yang terlalu sering memicu respons 403 diblokir otomatis selama 24 jam
  • Tercatat lebih dari 735 auto-ban
• Tingkat penggunaan sumber daya nyata pun kembali normal secara signifikan
• Ke depan, penulis berencana menerapkan aturan pengecualian untuk layanan normal seperti archive.org, sambil tetap mengizinkan pengindeksan oleh mesin pencari dan terus memblokir crawling serampangan untuk pelatihan AI

Kesimpulan: Kekuatan kombinasi alat dan perlunya keamanan layanan pribadi

• Dengan menerapkan rangkaian pertahanan berlapis ini, pengoperasian blog pribadi yang lancar dan aksesibilitas layanan berhasil dipulihkan
• Terbukti bahwa pemanfaatan banyak alat kecil untuk administrasi sistem dan otomasi efektif untuk keamanan server pribadi
• Di lingkungan di mana bahkan server pribadi ikut dicrawl secara serampangan karena meningkatnya permintaan pelatihan AI, pemblokiran aktif dan otomasi pengelolaan menjadi hal yang esensial

[GN⁺]

Komentar Hacker News

• Saya sering melihat banyak crawler nakal hanya berpura-pura menjadi mesin pencari besar. Ada yang bilang tidak perlu tertipu oleh info user-agent, tetapi cara favorit saya adalah menaruh informasi jebakan di robots.txt (misalnya gzip bomb), lalu mengatur agar crawler yang terdeteksi mengaksesnya diblokir mulai permintaan berikutnya. Ini cukup mudah diterapkan dengan Caddy, dan biasanya efektif menangkap pelanggar yang paling parah. Saya tidak bermaksud membela perilaku bot, tetapi kalau beberapa bot seperti ini saja bisa menjatuhkan situs, itu juga bukti bahwa situs tersebut sangat rentan terhadap penyerang yang benar-benar berniat jahat.

  • Komentar terakhir itu benar-benar tepat sasaran. Mungkin saya dari generasi berbeda, tetapi saya tidak paham kenapa penulis belakangan ini begitu terobsesi menekan pemakaian resource sekecil mungkin. Rasanya seperti kakek-nenek yang heboh mematikan lampu LED, atau mengemudi 24 km demi menghemat biaya bahan bakar 5 sen. 20 request per detik itu nyaris bukan apa-apa. Bahkan kalau halamannya dibuat dinamis pun—meski saya juga bertanya kenapa harus begitu, karena waktu yang sama jauh lebih berguna dipakai untuk mengatur caching—ini tetap bukan hal besar. Memang belakangan tulisan bergaya "fuck the bots" sedang populer, tetapi topik ini sendiri sama sekali bukan hal baru. Ada banyak cara yang lebih produktif untuk menanganinya tanpa membuang waktu.

  • Saya ingin mendengar lebih detail tentang cara memasang gzip bomb lewat robots.txt. Setahu saya kebanyakan AI mengabaikan robots.txt, jadi saya penasaran apakah ini pada akhirnya hanya menjebak crawler yang naif. Bukan mau menentang siapa pun, saya hanya ingin tahu lebih banyak soal cara menerapkannya tanpa merugikan pihak yang beritikad baik.

  • Saya mengelola salah satu wiki terbesar di bidang saya, tetapi hampir mustahil meyakinkan orang lain di tim pengembang untuk memakai gzip bomb. Mereka bersikeras bahwa risikonya terlalu besar (dengan pola pikir "karena aturan UE") sehingga tidak layak dicoba. Saya penasaran apakah ada situs publik nyata yang benar-benar memakai metode seperti ini.

• Akhir-akhir ini saya benar-benar kesal karena bot sama sekali tidak menghormati file robots.txt. Saya pikir orang yang membuat ini benar-benar egois. Kalau memang membuat bot seperti itu, ya tanggung sendiri akibatnya.

  • Kalau menaruh jebakan (honeypot) di file robots, itu tetap membantu menyaring bot yang memang sengaja cari gara-gara, meski yang benar-benar mengabaikannya total mungkin tidak akan tertangkap.

  • Hal serupa juga bisa dikatakan kepada orang-orang yang memakai chatbot, mesin pencari, atau alat pembanding harga. Sebenarnya para pengguna inilah pendorong ekonomi utama yang membuat scraper terus bermunculan.

• Saya paham penulis bilang "sekarang sudah tidak peduli", tetapi saya melihat Google, ripe.net, dan semrush ada dalam daftar IP yang diblokir. Untuk perusahaan lain mungkin saya tidak tahu, tetapi saya jelas tidak akan memblokir Google. Kalau Anda ingin situs dikenal orang, menurut saya tidak perlu juga memblokir Semrush atau ripe.net. Walaupun konten saya discrape AI atau pihak aneh lain, kalau situsnya sejak awal memang publik, kita seharusnya sudah siap bahwa pada tingkat tertentu isinya akan dimanfaatkan. Ibaratnya seperti mengundang tamu ke motel sambil mematikan papan lampunya.

  • Semrush sudah lama benar-benar sangat mengganggu di berbagai tingkatan, sampai selama 8 tahun saya bahkan menaruh pesan khusus di robots.txt. Pada akhirnya saya sampai harus melibatkan tim legal agar mereka akhirnya tenang. Dari sudut pandang saya, tidak ada nilainya membiarkan perusahaan "SEO" menggerus situs secara kasar sambil mendorong pengunjung sungguhan pergi. Kompetitor Semrush juga sama parahnya. Scraper AI yang sekarang pun kualitasnya sangat buruk, sampai saya pernah berulang kali mengirim surat keberatan resmi kepada investor besar dan tim PR mereka. Secara teknis maupun hukum, saya nyaris mati-matian mengembalikan situasi ke keadaan normal.

  • Masalah nyatanya adalah bot menyedot lalu lintas dalam jumlah besar—bandwidth, memori, CPU, dan resource disk. Di pengantar juga disebut ini perilaku yang tidak bisa diterima. Saya merasa tidak ada alasan untuk sengaja memberikan traffic seperti itu kepada scraper. Google juga menjalankan scraper AI, jadi mungkin itulah sebabnya mereka masuk daftar blokir.

  • Ada juga bot jahat sungguhan yang menyamar sebagai Google. Dulu scraping Google relatif lebih sopan, tetapi kalau penulis sudah mendapatkan traffic yang dibutuhkan entah memblokir mereka atau tidak, mungkin memang tidak ada alasan untuk peduli.

  • Saya heran apakah selama 10 tahun terakhir orang masih belum sadar bahwa Google seharusnya tidak dipakai, apalagi sekarang muncul situasi di mana Google menyensor situs-situs independen dengan AI. Saya juga menautkan komentar terkait langsung. Menurut saya sekarang Google lebih dekat menjadi risiko (liability) daripada aset (asset).

• Karena bot, file log server saya membengkak berlebihan, sampai di server saya logging sekarang dimatikan total. Bot terus-menerus menggaruk API, form, bahkan bagian situs yang hanya bisa diakses lewat klik di website. Anthropic, openAI, Facebook, dan lainnya juga masih terus men-scrape situs saya.

  • Kalau API itu hanya bisa diakses lewat klik, saya penasaran bagaimana bot bisa mencapainya.

  • Saya ingin tahu lebih detail soal API itu—apakah maksudnya bagian dari UI atau area yang biasanya hanya dipakai manusia, atau memang tidak ada jalur lain sama sekali. Belakangan AI agent meniru pola perilaku pengguna sungguhan, jadi kita sedang masuk masa ketika membedakan manusia dan bot hampir mustahil.

• Saya tadinya menganggap bagus karena bot crawler AI mengisi header User-Agent dengan jujur, tetapi saya agak terkejut bahwa justru itu yang menyebabkan traffic sebesar ini. Kebanyakan website sebenarnya tidak butuh data sesering itu, dan traffic-nya tetap terlalu besar. Kalau itu blog pengembang, saya makin tidak mengerti.

  • Kebanyakan crawler AI memang mematuhi robots.txt, tetapi ada juga kasus ketika mereka diblokir lalu langsung berganti ke user-agent browser dan mencoba crawl lagi dari IP residensial. Namun karena begitu banyak pihak yang secara palsu menyamar sebagai OpenAI/Amazon/Facebook, kita tetap harus berhati-hati membedakan kasus yang benar-benar akurat.

• Saya pembuat tirreno. Platform kami dioptimalkan untuk pengguna login langsung, tetapi juga efektif dipakai untuk mendeteksi dan memblokir bot. Kami menganonimkan IP dengan mengganti oktet terakhir dengan tanda bintang (*) sehingga subnet yang sama dikelompokkan sebagai satu akun. Sistem ini bisa dibuat menghasilkan blacklist otomatis untuk anomali traffic (error 500/404, percobaan login brute-force, IP pusat data, dll.). Dengan blacklist API tirreno, traffic yang tidak diinginkan bisa diarahkan ke halaman error. Kami juga menyediakan dashboard pemantauan untuk membantu pengelolaan dan mengurangi false positive.
  Github tirreno, demo admin

  • Sekarang banyak ISP memakai struktur CGNAT, jadi satu IP bisa mewakili ratusan pengguna nyata. Saya penasaran bagaimana Anda menangani masalah itu.

  • Saya juga sedang mengembangkan pemblokiran bot berbasis rentang IP publik. Kalau ada ide perbaikan, saya selalu terbuka.

  • Karena metode penggantian oktet terakhir IP, saya akan digabung sebagai satu pengguna dengan tetangga alamat yang sama sekali tidak ada hubungannya dengan saya. False positive dari IP pusat data juga tidak bisa dianggap sepele. Pada praktiknya, kalau sesuatu tidak diblokir, saya bisa saja harus klik 87 lampu lalu lintas agar lolos. Akhirnya ini terasa seperti dalih untuk bisa bilang bahwa data pribadi saya tidak dikumpulkan tanpa persetujuan, bahkan saat langkah menghindari false positive tetap menyulitkan. Tolong pastikan ada mekanisme umpan balik yang membuat pelanggan langsung sadar saat mereka benar-benar kehilangan pengguna berbayar.

• Ada satu hal yang sudah lama saya pikirkan: mungkinkah membuat struktur "page knocking", yaitu membuka halaman-halaman dalam urutan tertentu untuk memperoleh hak masuk? Misalnya, halaman lain baru akan tampil normal alih-alih 404 jika pengguna lebih dulu mengakses URL privat tertentu.

  • Arsitektur seperti itu tidak cocok untuk kasus ketika pengguna biasa harus bisa menemukan proyek lewat mesin pencari dan langsung mulai memakainya tanpa membuat akun atau autentikasi tambahan.

  • Dari sisi kegunaan, sebaik apa pun desainnya, ini hampir pasti akan menimbulkan ketidaknyamanan. Orang yang memakai bookmark atau mengirim tautan ke temannya pun kemungkinan hanya akan terus menemui 404.

• Server kecil saya berjalan cukup lancar, jadi belakangan saya tidak mengecek status fail2ban.
  Perbandingan hasil perintah:

  sshd-ddos:      0
  postfix:       583
  dovecot:     9690
  postfix-sasl: 4227
  nginx-botsearch: 1421
  nginx-http-auth: 0
  postfix-botnet:  5425
  sshd:         202157
  

Saya agak kaget menemukan lebih dari 220.000 IP sudah diblokir.

• Bot yang kami lacak dengan nama 'DotBot/1.2' meninggalkan lebih dari 220 ribu request dalam dua minggu terakhir. Polanya meminta nama file dan folder webserver secara acak. Karena penasaran ingin tahu sejauh mana ia akan terus menggali, saya sengaja belum memblokirnya dan hanya mengamati.

• Saya mulai berpikir apakah struktur pengindeksan terpusat untuk AI atau mesin pencari seharusnya beralih ke model push atau submit. Kalau berbagi langsung hanya saat saya mau, masalah scraping seperti ini mungkin akan banyak berkurang.

• Ketika saya masih kecil di tahun 90-an, saya pernah menerima telepon dari ISP yang memberi tahu bahwa komputer saya terinfeksi botnet dan koneksi internet saya akan diputus. Mungkin kita perlu kembali ke masa seperti itu, lalu memblokir seluruh ASN dari ISP yang membiarkan perilaku seperti ini agar masalahnya selesai.

  • Proxy residensial bukan disediakan langsung oleh ISP, melainkan terjadi karena pengguna di berbagai belahan dunia—secara sengaja atau tanpa sadar—memasang malware lalu membiarkan komputer mereka dipakai sebagai proxy. Belum lama ini ada artikel bagus tentang hal itu di HN.

  • Saya mengatur aturan firewall yang menampilkan peringatan setiap kali perangkat tertentu di jaringan saya mencoba membuat koneksi keluar ke port yang terkait malware. Daftar port itu perlu diperbarui berkala karena target malware terus berubah, tetapi meski sederhana, ini tetap lapisan pertahanan tambahan.