Proxy Residensial vs Blokir IP: Apa yang Masih Efektif

Sekitar seperempat dari exit node proxy residensial yang dijual penyedia besar berjalan di perangkat yang pemiliknya sama sekali tidak tahu bahwa perangkat itu menjadi bagian dari infrastruktur orang lain. Perkiraan itu berasal dari bertahun-tahun riset akademik yang mengukur jaringan semacam ini, dan itu menjelaskan banyak hal, termasuk bagaimana sebuah firma keamanan baru-baru ini menemukan exit proxy residensial di dalam rentang IP yang dialokasikan untuk Executive Office of the President. Ketika peneliti memperhatikan trafik itu, separuhnya masuk antara pukul 17.00 dan tengah malam waktu Eastern, dan internet pun bereaksi seperti biasanya, dengan bercanda. Tapi di balik candaan itu ada pelajaran nyata untuk kita semua: proxy residensial adalah cara paling efektif untuk mengalahkan pertahanan berbasis IP, dan kalau threat model kamu masih menganggap "IP residensial" sebagai sinyal kepercayaan, kamu sudah tertinggal satu generasi.

Saya menghabiskan empat tahun mengelola deteksi untuk sebuah perusahaan SaaS menengah, dan pergeseran itu terlihat langsung di dashboard kami. Sekitar waktu crew credential stuffing pindah dari proxy datacenter ke exit residensial, daftar blokir IP kami turun dari menangkap 80% trafik serangan menjadi hampir tidak menangkap apa-apa. Serangan yang sama, tooling yang sama, hanya hop terakhirnya yang berbeda. Artikel ini membahas kenapa itu terjadi dan apa yang benar-benar efektif ketika reputasi IP sudah tidak berfungsi.

Cara Kerja Proxy Residensial yang Sebenarnya

Proxy residensial pada dasarnya hanyalah exit node yang berjalan di perangkat konsumen, seperti ponsel, smart TV, set-top box, atau router rumah. Pelanggan jaringan proxy membayar untuk trafik yang keluar dari perangkat-perangkat ini, dan tugas penyedia proxy adalah memastikan jutaan perangkat tersedia di setiap wilayah. Pasokannya datang dari tiga sumber, diurutkan dari yang paling "terhormat".

1. SDK opt-in. Aplikasi gratis seperti VPN, widget cuaca, game mobile, dan aplikasi "dapatkan uang dengan berbagi bandwidth" menyertakan SDK proxy. Persetujuannya terkubur di syarat layanan yang tidak pernah dibaca siapa pun, tapi secara teknis ada. Model inilah yang selalu disebut penyedia besar ketika membicarakan etika.
2. Firmware yang disusupi dan malware. Botnet sudah bertahun-tahun mencari uang dengan menjual ulang proxy. Streaming box Android murah yang di-flash dengan firmware mencurigakan dari pabrik adalah node proxy begitu tersambung ke internet. Pemiliknya mengira baru membeli media player.
3. Sewa botnet terang-terangan. Segmen bawah pasar ini tidak berpura-pura. Kalau sebuah penyedia menawarkan lima puluh juta IP rotasi tanpa kebijakan sumber yang jelas, kamu tinggal berhitung.

Bagian pentingnya adalah bagaimana ini terlihat dari sisi defender. Trafiknya datang dari ASN residensial seperti Comcast, BT, atau Deutsche Telekom. IP-nya tergeolokasi ke kota yang masuk akal. Reverse DNS-nya mengembalikan sesuatu seperti pool-96-225-14-7.nycmny.fios.verizon.net. Setiap heuristik yang kita bangun di tahun 2010-an mengatakan ini manusia di rumahnya. Padahal bukan. Ini relay seharga $3 per gigabyte, dan manusia di rumah itu tidak tahu sama sekali bahwa ini ada.

Poin terakhir ini layak ditekankan, karena inilah bagian cerita yang seharusnya membuatmu khawatir meski kamu tidak pernah membeli atau melawan proxy. SDK yang me-relay bandwidth itu adalah software yang dikendalikan dari jauh oleh pihak lain, berjalan di dalam perimeter jaringanmu. Sekarang ia menjual bandwidth. Tidak ada yang secara arsitektural mencegah operatornya, atau siapa pun yang meretas operatornya, menugaskan node-node itu untuk hal yang lebih buruk. Proxy SDK di perangkat dalam jaringan sensitif bukan masalah bandwidth. Itu pijakan yang punya bagian penagihan.

Mengapa Pertahanan Berbasis IP Sudah Mati

Reputasi IP masuk akal ketika penyalahgunaan datang dari tempat yang memang terlihat mencurigakan: bulletproof hosting, rentang datacenter yang dibajak, open proxy di VPS yang terlupakan. Kamu bisa memetakan lingkungan-lingkungan buruk itu satu per satu. Proxy residensial mengakhiri era itu dengan memindahkan trafik buruk ke lingkungan yang baik, satu ruang tamu yang disusupi setiap kali.

Ekonominya membuat keadaan makin buruk. Ruang IP datacenter terbatas dan sangat dipantau, sekali kamu membakar satu /24, ia masuk setiap blocklist dalam sehari. Exit node residensial hampir tak terbatas dan memulihkan diri sendiri. Satu kali run credential stuffing bisa berganti di puluhan ribu IP rumah tangga yang berbeda, masing-masing hanya mengirim dua atau tiga request, sehingga tidak pernah memicu rate limit per IP. WAF kamu melihat sepuluh ribu "pengguna" yang berbeda. Memblokir satu IP tidak ada gunanya; memblokir seluruh ASN berarti memblokir pelanggan aslimu.

Inilah sebabnya klaim "trafiknya datang dari Gedung Putih" perlu catatan, dan para skeptis dalam diskusi cerita ini benar untuk mempertanyakannya. Memiliki ruang IP tidak berarti setiap pengumuman rentang itu memetakan ke satu lokasi fisik. Organisasi besar mengumumkan rentang dari banyak situs, menjalankan guest network, lab, dan overlay carrier NAT. IP exit di rentang sebuah organisasi memberitahumu siapa pemilik registrasi ruang itu, bukan di meja siapa paket itu sebenarnya berasal. Saat kamu melakukan analisis ini di jaringanmu sendiri, dan kamu memang harus, perlakukan atribusi sebagai hipotesis yang diuji terhadap log flow internal, bukan kesimpulan.

Sinyal Deteksi yang Masih Berfungsi

Reputasi IP memang sudah mati, tapi trafiknya tidak sepenuhnya tak terlihat. Exit proxy punya sidik jari. Tidak ada satu sinyal pun yang cukup sendirian, dan setiap sinyal punya penjelasan yang sah, tapi jika ditumpuk, hasilnya sangat efektif. Ini langkah standar dalam detection engineering modern: berhenti mencari bukti tunggal yang meyakinkan dan mulai membangun skor dari sinyal-sinyal lemah. Filosofi yang sama muncul dalam behavioral fingerprinting untuk script yang diobfuskasi. Kamu tidak perlu membaca kodenya kalau bisa mengkarakterisasi bagaimana ia berperilaku.

Analisis ASN dan bentuk koneksi

Mulailah dari ASN, tapi jangan berhenti di "ini residensial atau bukan". Pertanyaan yang berguna adalah apakah ASN itu cocok dengan klien yang diklaim. Request yang mengaku pengguna desktop Chrome tapi datang dari rentang 5G konsumen milik operator seluler patut dicurigai. Begitu juga trafik dari ASN ISP konsumen yang menghantam API kamu dengan konkurensi seperti datacenter. Node proxy memang rumah sungguhan, dan rumah sungguhan punya batasan nyata: upload bandwidth konsumen, tabel NAT, dan berbagi alamat carrier-grade NAT. IP exit yang melayani empat puluh pelanggan proxy berbeda dalam satu jam menghasilkan pola koneksi yang tidak akan pernah dihasilkan rumah tangga mana pun.

Fingerprint TLS dan TCP

Di sinilah kamu bisa menangkap operator yang ceroboh. Sebagian besar pelanggan proxy menjalankan trafiknya lewat software klien penyedia atau library HTTP standar, seperti Python requests, net/http di Go, atau Node. Masing-masing punya TLS ClientHello yang khas: urutan cipher suite, daftar extension, dan supported groups. Hash JA3 dan JA4 memungkinkanmu membandingkan apa yang dikatakan handshake TLS tentang klien dengan apa yang diklaim user agent-nya. "Chrome 126 di Windows" yang mengirim fingerprint TLS Go adalah bot yang memakai kostum. Beberapa jaringan proxy canggih melakukan TLS passthrough penuh dari mesin pelanggan, sehingga kebohongannya tetap utuh, tapi kebanyakan tidak, dan bahkan yang bagus pun bocor di lapisan TCP. Klien Windows yang diklaim tapi punya TTL dan window size yang menunjukkan Linux menambah satu poin lagi di skor.

Pola latensi dan waktu

Setiap proxy residensial menambah satu hop melalui perangkat konsumen di uplink konsumen. Hop itu punya biaya. Jika layananmu juga melihat latensi sebenarnya dari klien lewat WebRTC, pengukuran edge CDN, atau bahkan distribusi waktu request dalam satu sesi, kamu bisa membandingkan RTT jaringan dengan geografi yang diklaim. "Pengguna di Denver" dengan RTT 4 ms ke datacenter Virginia-mu jelas bukan di Denver. Waktu dalam sesi juga penting: browsing manusia punya jeda membaca, gerakan mouse, dan ritme yang tidak teratur. Trafik yang dialirkan lewat proxy dari skrip otomasi punya kualitas metronom, dengan interval antar-request yang konsisten, tanpa idle drift, dan pengiriman form instan. Bahkan ketika penyerang menambahkan jitter, itu tetap jitter yang diambil dari distribusi yang tidak akan pernah dihasilkan manusia.

Heuristik perilaku

Sinyal terkuat adalah apa yang dilakukan klien, bukan apa dirinya. Pengguna sungguhan berkeliaran. Bot menjalankan rencana. Sesi yang login, langsung membuka halaman pengaturan lewat URL yang tidak ditautkan jalur UI mana pun, mengubah email, lalu mengirim request payout dalam sembilan puluh detik bukan manusia, apa pun kata IP-nya. Lacak entropi urutan: apakah sesi melintasi aplikasimu seperti frontend-mu benar-benar menggerakkannya, atau mengakses endpoint dengan urutan yang hanya akan dipilih oleh orang yang membaca dokumentasi API-mu? Agregasi lintas-sesi adalah fitur pembunuhnya di sini. Satu IP residensial yang membuat tiga request terlihat tidak bersalah. Tiga ratus IP residensial yang masing-masing membuat tiga request dengan fingerprint TLS yang sama, resolusi layar yang sama, dan urutan endpoint yang sama adalah satu operasi dengan tiga ratus kostum.

Berburu Proxy SDK di Jaringanmu Sendiri

Masalah inbound yang mendapat perhatian, tapi cerita yang memicu semua ini sebenarnya cerita outbound: sebuah perangkat di jaringan yang seharusnya lebih tahu diri sedang me-relay trafik orang lain. Itu skenario yang bisa kamu tangani, karena kamu mengendalikan perimeter. Anggap saja suatu saat ada pengguna yang memasang streaming box yang sudah disusupi atau menginstal "VPN gratis" di ponsel kerja. Tugasmu adalah membuat kejadian itu terdengar nyaring.

Logika deteksinya cukup lurus karena proxy SDK punya postur yang khas. Node ada untuk menerima instruksi dan me-relay trafik, yang berarti:

• Koneksi control-channel yang persisten. Sesi TLS berumur panjang ke domain atau IP yang tidak dikenal, sering dengan payload periodik yang kecil. Buat baseline tujuan egress-mu; perangkat klien yang memegang koneksi enam jam ke host di negara tempat tidak satu pun vendor software-mu beroperasi layak untuk diperiksa.
• Fan-out koneksi yang tinggi dari perangkat klien. Workstation yang membuat koneksi keluar ke ratusan IP eksternal berbeda per jam berperilaku seperti infrastruktur, bukan manusia. Laptop itu untuk browsing; relay itu untuk me-relay.
• Flow yang diinisiasi dari luar ke subnet klien. Banyak framework proxy membuka tunnel inbound atau memakai traversal NAT gaya STUN. Jika sebuah perangkat di VLAN tamu atau IoT-mu menerima koneksi dari internet, ada yang sangat salah dengan segmentasimu. Cari tahu penyebabnya.
• Pola upload yang tidak simetris. Ponsel atau TV box yang volume upload-nya mendekati volume download sedang menyajikan konten atau me-relay trafik. Keduanya tidak normal untuk perangkat konsumen.
• Baseline waktu dalam sehari. Peneliti yang menemukan exit di jaringan pemerintah mengandalkan hal ini: aktivitas yang terkonsentrasi di jam malam menunjukkan perangkat di jaringan pribadi, bukan jaringan tamu. Versimu sendiri lebih sederhana: beri alert ketika pola trafik perangkat berubah karakter, bukan hanya volumenya.

Tidak ada yang membutuhkan deep packet inspection, dan itu penting kalau kamu peduli menjalankan jaringan yang bisa dipercaya orang. Metadata flow seperti NetFlow, log conn Zeek, dan VPC flow log membawa semua sinyal di atas. Kalau kamu belum menyimpan dan membuat baseline data flow egress, itu celah yang harus ditutup sebelum membeli apa pun. Titik buta di sini mirip dengan yang ada di logging autentikasi cloud: datanya ada, tapi tidak ada yang melihatnya sampai terjadi insiden.

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

Ini baru langkah awal, bukan produk jadi. Atur threshold fan-out sesuai baseline-mu sendiri, dan bersiaplah menghadapi false positive dari media server dan backup agent sampai kamu memasukkannya ke whitelist. Intinya, perburuan ini murah. Sehari analisis log bisa menemukan apa yang bisa dicari sebuah appliance seharga enam digit.

Segmentasi adalah Perbaikan yang Sebenarnya

Ini opini kuat saya, dibentuk dengan cara yang sulit: kamu tidak akan pernah menang dalam perlombaan deteksi melawan perangkat konsumen yang disusupi. Pasokannya terlalu besar dan vendor yang mengirim firmware tidak aman tidak menghadapi konsekuensi apa pun. Yang bisa kamu lakukan adalah membuat perangkat yang disusupi itu membosankan. Streaming box yang terinfeksi di VLAN IoT yang tersegmentasi dengan benar bisa menjual bandwidth-nya ke jaringan proxy, menyebalkan dan mungkin memalukan kalau rentang IP-mu sensitif, tapi ia tidak bisa menjangkau file share, API internal, atau apa pun yang bisa mengubah rasa malu menjadi pelanggaran data.

Polanya selalu sama dalam tinjauan insiden. Organisasi punya jaringan datar, atau jaringan "tamu" yang bisa menjangkau DNS internal dan antarmuka manajemen, atau kebijakan bring-your-own-device yang hanya ditegakkan oleh klik setuju. Lalu sebuah Android murah atau ponsel dengan SDK bawaan bergabung ke jaringan, dan IP egress organisasi mulai muncul di inventaris penyedia proxy. Perbaikan setelah kejadian adalah apa yang seharusnya dilakukan sebelumnya: client isolation di guest network, perangkat IoT di VLAN dengan akses egress saja dan tujuan RFC1918 diblokir, serta perangkat pribadi yang jauh dari zona kepercayaan produksi. Defense in depth memang tidak glamor, tapi seperti yang sudah kami bahas dalam konteks pertahanan berlapis versus kontrol tunggal yang kuat, lapisanlah yang menyelamatkanmu ketika satu kontrol gagal, dan selalu ada satu yang gagal.

Ada juga percakapan kebijakan yang layak dilakukan secara internal. Aplikasi "gratis" adalah cara SDK-SDK ini masuk. Kalau staf bisa memasang software sembarangan di perangkat yang menyentuh jaringanmu, berarti kamu sudah menyerahkan perimeter ke perusahaan ad-tech mobile. Sebagian organisasi menjawab dengan MDM dan allowlist aplikasi; untuk kebanyakan, segmentasi jaringan mencapai containment yang sama dengan biaya politik yang lebih kecil.

Apa yang Sebenarnya Diajarkan Cerita Ini

Lepaskan spekulasi politiknya dan ceritanya adalah demonstrasi bersih dari dua fakta. Pertama, deteksi proxy residensial sudah berkembang menjadi kategori produk. Peneliti sekarang bisa mengenumerasi exit node dalam skala besar dan memetakannya ke ruang IP, yang merupakan telemetri sangat berguna. Kedua, dan ini yang lebih tidak nyaman, setiap jaringan hanya berjarak satu pembelian perangkat yang ceroboh dari menjadi infrastruktur orang lain. Jaringan paling terjaga di dunia pun masih punya manusia di dalamnya, dan manusia suka mencolokkan sesuatu.

Kalau kamu hanya mengambil satu hal: cek apakah IP egress organisasimu muncul di inventaris proxy residensial. Beberapa layanan bisa memberitahumu, dan threat intel feed-mu mungkin sudah memuatnya. Menemukan rentang kamu terdaftar bukan bukti kompromi, karena carrier-grade NAT dan ruang alamat bersama mengaburkan gambarannya, tapi itu titik awal yang murah dan berisyarat tinggi untuk sebuah perburuan. Lalu periksa fan-out egress-mu, koneksi berumur panjang, dan desain VLAN-mu.

Para penyerang pindah ke lingkungan yang baik bertahun-tahun lalu. Para defender yang menyadarinya adalah mereka yang berhenti memeriksa alamat dan mulai mengamati perilaku.