BGP Hijack yang Lolos RPKI: Pelajaran maxLength dari Insiden Virtualizor

Akhir Agustus 2026, satu blok alamat IP di jaringan Hetzner dibajak lewat BGP selama sekitar 33 jam. Selama itu, sebagian trafik ke server update Virtualizor (panel manajemen VPS dari Softaculous) dibelokkan ke server milik penyerang, yang kemudian menyajikan paket update berisi malware.

Yang membuat kasus ini menarik bagi operator jaringan: rute palsu tersebut berstatus RPKI valid. Bukan karena RPKI-nya rusak, melainkan karena konfigurasi ROA milik pemegang prefix terlalu longgar. Artikel ini menjelaskan konsep dasarnya, kronologi singkat insiden, dan langkah praktis agar jaringan Anda tidak mengalami hal serupa.

BGP hijack dalam bahasa sederhana

BGP (Border Gateway Protocol) adalah protokol yang dipakai jaringan-jaringan di internet, masing-masing dengan nomor AS (Autonomous System), untuk saling memberi tahu: “blok IP ini bisa dijangkau lewat saya.”

Masalahnya, BGP pada dasarnya mempercayai pengumuman tersebut. Jika sebuah AS mengumumkan prefix milik pihak lain, dan tetangganya tidak memfilter, rute palsu itu bisa menyebar. Router juga selalu memilih rute yang paling spesifik: pengumuman /24 akan mengalahkan /16 untuk alamat yang sama. Karena itu, mengumumkan potongan kecil (sub-prefix) dari blok milik orang lain adalah cara efektif untuk menarik trafik.

RPKI, ROA, dan ROV

RPKI (Resource Public Key Infrastructure) menambahkan lapisan verifikasi berbasis sertifikat:

• ROA (Route Origin Authorization) adalah objek bertanda tangan digital dari pemegang prefix yang menyatakan AS mana yang boleh menjadi origin (asal) prefix tersebut, beserta maxLength, yaitu panjang prefix paling spesifik yang masih diizinkan.
• ROV (Route Origin Validation) adalah proses di router yang memeriksa setiap pengumuman terhadap ROA. Hasilnya Valid, Invalid, atau Not Found, dan rute Invalid umumnya dibuang.

Batasan pentingnya: ROV hanya memeriksa AS origin, bukan seluruh jalur (AS path). Field origin di BGP tidak ditandatangani, sehingga penyerang bisa menulis AS korban sebagai origin, lalu menempatkan AS-nya sendiri seolah-olah sebagai penyedia transit korban. Teknik ini disebut forged-origin hijack.

Mengapa maxLength menentukan

RFC 9319 (BCP 185) memberi contoh: jika pemegang 192.168.0.0/16 membuat ROA dengan maxLength 24, maka setiap /24 di dalam blok itu dianggap sah selama origin-nya benar, termasuk /24 yang tidak pernah diumumkan oleh pemiliknya. Penyerang cukup mengumumkan salah satu /24 dengan origin palsu, dan rute itu akan lolos ROV sekaligus menang karena lebih spesifik. Ini disebut forged-origin sub-prefix hijack.

Jika ROA dibuat “minimal”, yaitu hanya mencakup prefix yang benar-benar diumumkan, sub-prefix palsu tersebut akan berstatus Invalid. Penyerang masih bisa mencoba forged-origin pada prefix yang sama panjang, tetapi dampaknya jauh lebih kecil karena tidak otomatis menang.

RFC 9319 juga mengutip pengukuran tahun 2017: sekitar 12% prefix dalam ROA memakai maxLength lebih panjang dari panjang prefix-nya, dan sekitar 84% di antaranya rentan terhadap serangan jenis ini.

Apa yang terjadi pada insiden Virtualizor

Berdasarkan analisis Ipregistry dan everyWAN (keduanya merujuk data publik RIPE RIS/RIPEstat dan laporan insiden vendor):

Aspek	Detail
Prefix yang dibajak	162.55.80.0/24, bagian dari 162.55.0.0/16 milik Hetzner (AS24940)
AS yang mengumumkan	AS62390, diteruskan melalui upstream AS6204
Waktu	28 Agustus 2026 sekitar 20:57 UTC hingga 30 Agustus 2026 sekitar 06:10 UTC (kurang lebih 33 jam)
ROA saat insiden	162.55.0.0/16, origin AS24940, maxLength 24
Status RPKI rute palsu	Valid

Dalam jalur yang teramati, AS24940 tetap tercantum sebagai origin, sementara AS62390 tampil seolah-olah sebagai transit Hetzner. Karena ROA mengizinkan AS24940 mengumumkan hingga /24, router yang menjalankan ROV pun menerima rute tersebut.

Beberapa poin lain dari sumber:

• Sertifikat TLS. Sekitar 33 menit setelah pengumuman pertama, sertifikat Let’s Encrypt untuk domain vendor muncul di log Certificate Transparency. Ipregistry mencatat sertifikat itu mencakup 26 nama domain, termasuk virtualizor.com dan softaculous.com, dan kini sudah dicabut. Artinya, pengguna yang terhubung ke server palsu tidak melihat peringatan sertifikat.
• Update berbahaya. Menurut vendor, klien update Virtualizor saat itu belum memverifikasi paket secara kriptografis. Vendor menyebut dampaknya mengenai “segelintir server”; satu penyedia hosting melaporkan 5 dari 34 hypervisor miliknya terkompromi. Tidak ada daftar pasti instalasi yang terdampak.
• Pemulihan. Diversi sempat berhenti setelah Hetzner mengumumkan /24 tersebut sendiri, lalu rute palsu muncul kembali sebelum akhirnya hilang. Data RIPEstat yang dikutip everyWAN menunjukkan maxLength ROA Hetzner berubah dari 24 menjadi 16 pada awal September 2026. Alasan perubahan itu belum dipublikasikan pemegang prefix.

Ada satu nuansa yang sering terlewat: everyWAN mencatat bahwa pengumuman darurat /24 oleh Hetzner sendiri juga hanya bisa valid karena maxLength 24. Dengan ROA minimal, langkah darurat semacam itu memerlukan penerbitan ROA baru terlebih dahulu. Karena itu, kemampuan menerbitkan ulang ROA dengan cepat saat insiden sama pentingnya dengan konfigurasi awalnya. RFC 9319 juga mengizinkan ROA untuk prefix yang memang disiapkan untuk mitigasi (misalnya DDoS) dibuat lebih dulu, asalkan prefix tersebut benar-benar mungkin diumumkan.

Pembanding: kasus Telegram, Juni 2026

Pada 16 Juni 2026, AS18101 (Rcom) mengumumkan prefix milik Telegram sebagai origin-nya sendiri. Penyebabnya masih diperdebatkan. Menurut catatan Anurag Bhatia, prefix Telegram sudah dilindungi ROA, sehingga jaringan yang menjalankan ROV menolak rute tersebut; penyebarannya terjadi melalui upstream yang tidak memfilter rute Invalid.

Kedua kasus ini saling melengkapi. Di kasus Telegram, ROA yang tepat bekerja, dan kebocoran terjadi di jaringan yang tidak menjalankan ROV. Di kasus Virtualizor, ROV bekerja sesuai desainnya, tetapi ROA terlalu longgar sehingga rute palsu dinilai sah. RPKI efektif bila dua sisi dikonfigurasi dengan benar: pemegang prefix menerbitkan ROA yang tepat, dan jaringan transit menegakkan ROV.

Checklist untuk operator jaringan dan pemilik blok IP

Konfigurasi ROA

1. Buat ROA untuk setiap prefix yang benar-benar Anda umumkan, termasuk yang diumumkan oleh pihak lain atas nama Anda.
2. Samakan maxLength dengan panjang prefix yang diumumkan, atau tidak perlu memakai maxLength sama sekali. Jika Anda mengumumkan /22 dan dua /23, buat ROA terpisah untuk ketiganya, bukan satu ROA /22 dengan maxLength 24.
3. Tinjau ulang ROA setiap kali kebijakan routing berubah, sebagaimana diwajibkan RFC 9319. APNIC juga menyarankan agar maxLength tidak lebih lebar dari yang diperlukan.
4. Siapkan prosedur penerbitan ROA darurat, lengkap dengan siapa yang punya akses ke portal RIR atau NIR dan berapa lama propagasinya.

Penegakan dan filtering

5. Aktifkan ROV di router edge dan buang rute Invalid.
6. Filter sesi BGP pelanggan berdasarkan ROA dan objek route di IRR.
7. Tanyakan secara tertulis kepada upstream Anda apakah mereka membuang rute RPKI Invalid.
8. Pertimbangkan ASPA, objek RPKI yang lebih baru untuk memvalidasi hubungan antar-AS di jalur. Ipregistry dan APNIC merekomendasikannya, meskipun dukungannya di perangkat dan jaringan belum merata.

Data dan koordinasi

9. Daftarkan objek route di IRR dan jaga kontak di database routing tetap aktif, sejalan dengan aksi MANRS.

Monitoring

10. Pasang alert untuk pengumuman more-specific yang tidak Anda buat, origin atau upstream yang tidak dikenal, serta perubahan ROA. Alat open source seperti BGPalerter memakai data BGP publik untuk keperluan ini.

Untuk penyedia software

11. Tandatangani paket update dan verifikasi tanda tangannya dengan kunci yang tidak dikirim lewat kanal yang sama. Insiden ini menunjukkan TLS saja tidak cukup jika rute ke server sudah dibajak.

Bagaimana Cloudku menerapkannya

Cloudku mengoperasikan jaringan BGP sendiri, AS133337, yang terhubung ke Internet Exchange BIX, CXC, dan JKT-IX serta dipantau NOC 24/7. Prefix kami terdaftar di IRR, dan prefix IPv4 kami dilindungi ROA RPKI.

Jika Anda memiliki blok IP sendiri dan ingin mengumumkannya melalui sesi BGP, layanan IP Transit dan Colocation Cloudku bisa menjadi titik awal. Pastikan ROA dan objek route Anda sudah sesuai dengan prefix yang akan diumumkan sebelum sesi dinyalakan. Kami juga menyediakan sejumlah tools gratis untuk kebutuhan jaringan sehari-hari.