Mastering Cyber Security in This Crazy World!

Edisi 1 · RWID · Ecobook Edition

Ditulis oleh RWID Press, penerbit Remote Worker Indonesia.

Buku ini lahir daripada satu peristiwa sebenar: serangan automatik ke atas remoteworker.id pada 2 Oktober 2026. Daripada menyembunyikannya, kami membukanya dan menjadikan serangan itu bahan pengajaran. Setiap bab mengikut corak yang sama:

teori → cara lazim dalam industri → cara Ecosphere melakukannya → serpihan insiden sebenar.

Buku ini bukan ringkasan berita. Ia menerangkan mengapa sesebuah sistem dibina begini, bukan sekadar apa yang dipasang.

Buku ini terus membesar. Setiap serangan baharu yang menyerang RWID akan menjadi bab baharu dalam edisi seterusnya. Membeli buku ini bermakna memiliki catatan yang terus bertambah — bukan sekali baca lalu selesai. Semakin ramai yang cuba menjatuhkan kami, semakin tebal bukunya.

© RWID. Diterbitkan sebagai Ecobook.

Kata Pengantar

RWID (Remote Worker Indonesia) telah beroperasi sejak 2017. Pada 2025 ia tular — dan tularnya disertai tuduhan negatif daripada ramai orang yang tidak mengenalinya: scam. Saya sudah menceritakan sisi kemanusiaannya di halaman Selamat datang aplikasi ini, dan saya tidak akan mengulangi semuanya di sini. Yang perlu anda tahu hanyalah satu akibatnya: RWID berhenti, lalu setahun kemudian memutuskan untuk kembali.

Apabila memutuskan untuk kembali, saya menyusun semula keutamaannya. Bukan ciri dahulu. Bukan paparan dahulu. Keselamatan dahulu. Sebabnya mudah: tuduhan scam itu, betul atau salah, menyedarkan saya bahawa RWID tidak akan dapat membuktikan apa-apa jika sistemnya runtuh sebaik sahaja diserang. Pada 2025, saya membina dengan pantas, menggunakan banyak perkhidmatan pihak ketiga, dan menyesuaikan diri dengan cara yang pada pendapat saya sendiri tidak boleh dipertahankan. Salah satunya menyebabkan semua stored procedure RWID hilang. Sejak itu satu prinsip saya pegang: Zero Trust — jangan percaya apa-apa yang datang dari internet sehingga ia membuktikan dirinya.

Maka apabila RWID kembali pada 2026, saya membinanya di atas asas yang berbeza, dan saya mencabar dunia secara terbuka:

Hantaran itu — di Instagram dan Threads — ialah pencetusnya. Saya sengaja membuka diri. Serangan yang datang bukan kejutan; ia ialah tetamu yang kami jemput. Tujuannya satu: membuktikan, secara terbuka, bahawa sistem ini kukuh — dan jika ternyata belum, kami mahu tahu sekarang, bukan ketika berjuta-juta orang sedang menonton.

Buku ini lahir daripada jemputan itu. Ia menerangkan teori keselamatan yang mendasarinya, seni bina yang kami bina, dan serangan sebenar yang benar-benar kami tangkis beberapa jam selepas hantaran itu tersebar.

Satu perkara yang akan anda lihat berulang kali: kekuatan kami bukan pada satu tembok besar, tetapi pada cara kami menyusun sistem supaya satu pembaikan kecil dapat merebak dengan pantas ke semuanya. Itulah Ecosphere.

— RWID Press

Cara Membaca Buku Ini

Buku ini ditulis untuk pembina produk — terutamanya yang belajar sambil membina (vibe coder, solo builder, pemula hingga pertengahan). Tiada andaian bahawa anda sudah faham keselamatan. Yang saya andaikan: anda boleh membina aplikasi web, dan anda mahu membinanya mengikut piawaian pengeluaran.

Setiap bab mengikut corak yang sama, dan corak inilah yang menjadikan buku ini berguna:

1. Teori. Konsep asasnya, dan sebab di sebaliknya. Bukan hafalan.
2. Cara lazim dalam industri. Bagaimana dunia biasanya menanganinya.
3. Cara Ecosphere. Bagaimana platform yang kami bina menerapkannya.
4. Serpihan insiden. Potongan daripada serangan sebenar 2 Oktober 2026 yang menggambarkan perkara itu.

Anda boleh membaca secara berurutan, atau melompat ke bab yang anda perlukan. Tanda → menunjuk ke bacaan lanjutan. Istilah teknikal Inggeris saya kekalkan jika itu memang istilah bakunya (payload, rate limit, query), supaya anda mengenalinya dalam mana-mana dokumentasi.

Buku ini tidak menggantikan amalan. Di bahagian akhir ada Tools: butang untuk menjalankan simulasi serangan di portal RWID, senarai semak penetapan keselamatan, dan templat laporan kepada penyedia perkhidmatan internet (ISP).

Kandungan

Bahagian 1 · Pentas

• 1 · Dunia yang Hidup
• 2 · Sekilas Insiden: satu IP, lapan belas minit
• 3 · Apa Itu Ecosphere (dan mengapa LXS sahaja tidak mencukupi)

Bahagian 2 · Mengapa Sistem Ini Kukuh

• 4 · Akar Teori: Domain-Driven Design & Bounded Context
• 5 · LXS: Linux Services sebagai bata binaan
• 6 · Gateway & Auth: sumber kekuatan yang membaiki dengan pantas

Bahagian 3 · Asas Keselamatan

• 7 · Keselamatan ialah Sifat Sistem, bukan Ciri
• 8 · Model Ancaman & Permukaan Serangan
• 9 · Deny-by-Default, Least Privilege, Defense-in-Depth

Bahagian 4 · Kelas Serangan & Pertahanan

• 10 · Suntikan & Query Berparameter
• 11 · XSS, Escaping, dan Content Security Policy
• 12 · Sesi & Pengesahan: daripada localStorage ke HttpOnly
• 13 · Pengurusan Rahsia
• 14 · SSRF, Open-Redirect, dan Pengesahan URL
• 15 · Abuse: Spam Pendaftaran, Bot, dan Scanner
• 16 · Rantaian Bekalan Perisian

Bahagian 5 · Operasi & Skala

• 17 · Tepi: WAF, DDoS, dan Mengapa Origin Hampir Tidak Terasa
• 18 · Observability & Alerting: Guard yang Menjerit
• 19 · Incident Response yang Tenang
• 20 · Kesiapsiagaan Skala & Kuota

Bahagian 6 · Kajian Kes & Alat

• 21 · Kajian Kes: Kronologi Lengkap 2 Oktober 2026
• 22 · Seni Bina Keselamatan Ecosphere, dari Hujung ke Hujung
• 23 · Tools: Uji Sistem Anda Sendiri

Buku ini terus membesar. Setiap serangan baharu yang menyerang RWID akan menjadi bab baharu dalam edisi seterusnya. Membeli buku ini bermakna memiliki catatan yang terus dikemas kini — bukan sekali baca lalu selesai.

1 · Dunia yang Hidup

Sebelum insiden, sebelum teori, ada satu perkara yang perlu anda lihat dahulu. Ini wajah RWID:

Globe itu bukan perhiasan. Ia tidak dibuat sembarangan. Ia direka sebagai monitor sistem global secara masa nyata — satu skrin yang menjawab soalan “apa yang sedang berlaku di seluruh dunia RWID?” tanpa perlu membuka papan pemuka teknikal.

Apa yang dipantaunya

• HQ RWID di Yogyakarta — titik emas yang menandakan rumahnya.
• HQ Ecosphere dan nod-nodnya — tempat platform berjalan, termasuk nod pengeluaran di luar negara. Jika sesebuah nod hidup atau mati, ia kelihatan di sini.
• Setiap ahli — apabila seseorang log masuk atau mendaftar, muncul denyutan di lokasinya, lengkap dengan nama dan bandar. Dunia ini bergerak kerana penghuninya.
• Degupan berterusan — denyut jantung dan isyarat aktiviti yang membuat “dunia” terasa hidup, bukan sekadar peta statik.

Ia sekali gus dua perkara: bukti sosial (pengunjung melihat komuniti itu nyata dan aktif) dan monitor operasi (dari mana trafik datang, nod mana yang sihat). Satu skrin, dua fungsi.

Inilah yang kelihatan ketika ada serangan

Itu ialah tangkapan globe semasa serangan 2 Oktober 2026 berlangsung. Nama-nama asing muncul daripada satu titik yang sama — Cikarang — bertalu-talu, pantas, dan tidak wajar: barisan tanpa jeda dari bandar yang sama, dengan corak yang mustahil dilakukan manusia biasa. Dunia yang tadinya tenang tiba-tiba sesak dengan satu-satunya sumber.

Dan kerana setiap denyutan disertai bunyi, saya tidak perlu sedang merenung skrin untuk tahu ada sesuatu yang tidak kena. Telinga menangkap dahulu, sebelum mata sempat membaca. Sebaik sahaja bunyi itu datang bertalu-talu, refleksnya satu: buka globe, dan di sana sudah jelas.

Itulah nilai sebenar sebuah monitor: bukan sekadar memaparkan data, tetapi menjadikan yang tidak kena kelihatan dan kedengaran — mustahil untuk terlepas pandang.

Globe bukan satu-satunya yang menjerit. Di saluran Telegram, bot kami menghantar amaran yang sama — secara automatik, daripada guard yang memantau tepi:

Dua isyarat datang hampir serentak: mata (globe) dan mesin (Telegram). Itu bukan kebetulan. Sistem memang direka untuk memberitahu dari lebih satu arah — supaya satu kejadian yang terlepas daripada pandangan tetap tertangkap di tempat lain. Pengesanan yang baik tidak bergantung pada satu deria.

Mengapa ini penting untuk sebuah buku keselamatan

Kerana di sinilah keanehan itu kelihatan. Apabila sesebuah sistem dipantau sebagai satu dunia yang hidup, perkara yang tidak wajar menjadi ketara — nama yang pelik, denyutan yang tidak pada tempatnya. Bukan kerana ada yang membaca log pada pukul tiga pagi, tetapi kerana dunia itu sendiri menunjukkan bahawa ada sesuatu yang tidak kena.

Monitor yang baik bukan sahaja memaparkan angka; ia membuat yang salah terasa salah. Globe inilah contoh paling jelas bagi prinsip itu, dan insiden yang kita bincangkan bermula dari Bab 2 ialah buktinya.

→ Bab 2 · Sekilas Insiden.

2 · Sekilas Insiden: satu IP, lapan belas minit

Sebelum masuk ke teori, mari lihat dahulu apa yang sebenarnya berlaku. Ini petikan yang sudah kami terbitkan sebagai catatan kejuruteraan dalam dokumentasi Ecosphere, dipermudah untuk pembaca buku ini.

Pada 2 Oktober 2026, sekitar pukul 18:16–18:37 WIB, satu alamat IP di Cikarang, Jawa Barat, menjalankan scanner kerentanan automatik terhadap remoteworker.id. Dalam tempoh itu, tepi kami (Cloudflare) menyekat 397 permintaan. Scanner itu menyasarkan endpoint log masuk dan pendaftaran (/signin, /signup, /api/auth/register), menghantar probe suntikan, dan mengimbas laluan-lubang WordPress yang sudah berpuluh tahun dikenali.

Yang penting bukan angkanya. Yang penting ialah apa yang tidak berlaku:

• Tiada satu pun data yang bocor.
• Pemproses (CPU) pelayan pengeluaran kekal di bawah beban normal; hos hampir tidak berkelip.
• Tiada satu pun akaun sampah yang dapat masuk, kerana email verification adalah wajib.
• Pelayan lama kami malah tidak pernah melihat majoriti permintaan itu, kerana semuanya ditolak di tepi.

Satu-satunya kesan yang sempat terlepas: 43 akaun sampah yang mendaftar dari IP itu. Semuanya kami padam; 30 pendaftar sebenar kekal utuh.

Pengajaran pertama: serangan yang berjaya menjadikan anda lebih kuat bukan serangan yang gagal, tetapi serangan yang dikesan, ditahan, dan dilaporkan dengan bukti.

Insiden ini bukan kejutan. Ia ialah jawapan kepada cabaran yang kami sebarkan sendiri. Selebihnya buku ini menerangkan mengapa sistemnya dapat setenang itu, dan apa yang boleh anda tiru untuk sistem anda.

→ Teruskan ke Bab 3 · Apa Itu Ecosphere untuk memahami asas yang menjadikan semua ini mungkin.

3 · Apa Itu Ecosphere (dan mengapa LXS sahaja tidak mencukupi)

Menerangkan “LXS” tanpa menerangkan Ecosphere adalah seperti menerangkan bata tanpa menerangkan bangunan. Jadi kita mulakan dengan bangunannya.

Masalah yang ingin dijawab

Cara piawai membina aplikasi pada tahun 2020-an menimbun lapisan: aplikasi dibungkus container, container diorkestrasi Kubernetes, ditambah service mesh, message broker, dan sederet perkhidmatan terurus. Untuk pasukan besar, itu wajar. Untuk seorang yang membina produk, itu beban: setiap lapisan menambah permukaan yang boleh silap, dan — yang lebih penting untuk buku ini — permukaan yang boleh diserang.

Ecosphere mengambil arah lain. Ia menganggap aplikasi sebagai himpunan keupayaan kecil yang saling melengkapi, bukan satu monolit raksasa mahupun himpunan container yang tidak terkira.

Istilah-istilah terasnya

• Domain. Satu tanggungjawab yang jelas dan berdikari — identiti, artikel, dompet, pemberitahuan. Setiap domain mempunyai datanya sendiri dan berinteraksi melalui kontrak, bukan melalui import kod antara satu sama lain.
• LXS (Linux Services). Cara sesebuah domain dikemas menjadi satu binari sedia-jalan dengan kontrak yang tegas: pemboleh ubah yang diperlukan, port, memori, dan laluan mana yang dibukanya. Perinciannya di Bab 5.
• Estate. Rangkaian LXS + kod teras (domain core) yang membentuk satu aplikasi yang lengkap. remoteworker.id ialah sebuah estate.
• Registry. Katalog LXS berversi. Anda menggunakan semula keupayaan yang sudah teruji berbanding menulis semula.

Mengapa ini penting untuk keselamatan

Satu ayat: satu keupayaan di satu tempat bermakna satu tempat untuk membaiki. Jika ada kelemahan pada LXS pengesahan, anda membaikinya sekali, menerbitkan versi baharu, dan semua estate yang menggunakannya boleh naik versi. Anda tidak membaiki kod log masuk yang disalin dalam sepuluh projek.

Itulah yang kami namakan kekuatan yang dipropagasikan: pembaikan pantas di satu titik merebak ke seluruh sistem, bukan tertinggal di satu aplikasi.

Cuba sendiri

Ecosphere bukan teori yang terkunci dalam buku ini. Platformnya terbuka untuk dicuba — bermula daripada pemasangan, dokumentasi, hingga komposisi aplikasi pertama anda:

→ https://getecosphere.com

Semakin ramai orang membina di atasnya, semakin ramai yang turut memperkukuh asas yang sama. Itu sebahagian daripada niatnya: keselamatan yang dikongsi, bukan dipelihara sendiri-sendiri.

Dalam bab seterusnya kita gali dua akar teorinya — Domain-Driven Design dan konsep LXS itu sendiri — sebelum masuk ke bab yang paling penting bagi kekuatan kami: Gateway dan Auth.

4 · Akar Teori: Domain-Driven Design & Bounded Context

Sebelum ada LXS, idea itu sudah wujud lebih dahulu: Domain-Driven Design (DDD). Buku ini tidak akan mengajar DDD secara penuh, tetapi satu konsepnya perlu anda fahami, kerana di situlah keselamatan kami bertumpu.

Bounded context: satu perkataan, satu makna

Bayangkan perkataan “user”. Dalam domain identiti, user bermaksud akaun dengan kata laluan dan sesi. Dalam domain artikel, user hanyalah penulis. Dalam domain dompet, user ialah pemilik baki. Jika anda memaksa satu takrifan “user” untuk semuanya, kod anda perlahan-lahan menjadi saling bergantung, dan setiap perubahan menyentuh segalanya.

Bounded context ialah jawapannya: tetapkan sempadan yang jelas. Setiap konteks mempunyai modelnya sendiri, datanya sendiri, dan kontraknya sendiri. Mereka tidak saling meminjam jenis data.

Peraturan yang mengikat (dan mengapa ini soal keselamatan)

Sistem yang dibina di atas sempadan tegas mempunyai sifat yang berharga untuk keselamatan:

1. Tanpa import antara domain. Sesebuah domain berkomunikasi dengan domain lain melalui kontrak awam (biasanya HTTP), bukan dengan memanggil fungsi dalamannya. Maknanya permukaan serangan sesebuah domain tertutup kemas: yang boleh memanggilnya hanya melalui pintu yang diisytiharkan.
2. Storan berasingan. Setiap domain mempunyai pangkalan datanya sendiri. Kerentanan di satu domain tidak secara automatik membuka seluruh pangkalan data. Blast radius kecil.
3. Rujukan, bukan salinan. Domain menyimpan rujukan kepada data milik domain lain (sebuah ID), bukan salinannya. Tiada data yang berganda dan tidak konsisten di banyak tempat.
4. Identiti eksplisit di sempadan. Operasi tulis tidak menyimpulkan pemilik daripada token secara senyap; ia meminta bukti yang eksplisit.

Ringkasnya: pengehadan yang jelas ialah kawalan keselamatan. Apabila sesebuah komponen hanya boleh dicapai melalui satu pintu yang diisytiharkan, memikirkan keselamatannya jauh lebih mudah berbanding kod yang saling bersambung ke mana-mana.

Dari konsep ke binari

DDD menerangkan bagaimana memikirkan sempadan. Ia tidak menerangkan bagaimana mengemas sempadan itu menjadi sesuatu yang boleh dijalankan dan dikomposisi dengan selamat. Untuk itu kita memerlukan LXS — perbincangan bab seterusnya.

→ Bab 5 · LXS: Linux Services sebagai bata binaan.

5 · LXS: Linux Services sebagai bata binaan

LXS ialah cara sesebuah domain dikemas menjadi satu binari yang sedia dijalankan, lengkap dengan kontrak yang boleh dibaca oleh mesin mahupun manusia. Ia dijalankan secara native di dalam LXC — tanpa lapisan virtualisasi yang berat, tanpa image container yang menimbun.

Apa isi kontrak sebuah LXS

Setiap LXS mengisytiharkan dirinya secara terbuka:

• Pemboleh ubah persekitaran yang diperlukannya (serta yang mana satu ialah rahsia).
• Port yang didudukinya.
• Sumber (memori, cakera) yang dimintanya.
• Laluan yang dibukanya — dan pada tahap akses apa (public, auth, role:...).
• Rangkaian: masuk dari mana, keluar ke mana.

Kontrak ini bukan dokumentasi pasif. Semasa deploy, platform memeriksa sama ada estate benar-benar memberikan apa yang diminta — dan menolak komposisi yang tidak sepadan. Sebuah LXS tidak boleh mengakses sesuatu secara senyap yang tidak diisytiharkannya.

Versi yang tidak berubah

LXS diterbitkan dalam versi yang immutable: [email protected] bermaksud tepat binari itu. Anda tidak mengubah versi yang sudah diterbitkan; anda membaiki dengan menerbitkan versi baharu. Akibatnya, membaiki kelemahan menjadi tindakan yang tegas dan boleh dijejaki: satu versi baharu, satu catatan perubahan, satu keputusan untuk naik versi di estate yang terjejas.

Satu domain, satu binari

Peraturan “satu LXS = satu domain” memastikan binari kekal kecil dan fokus. Permukaan serangannya pun kecil: proses ini tidak membawa keupayaan yang tidak diperlukannya. Tiada interpreter besar, tiada rangka kerja serba guna; hanya apa yang perlu.

Keupayaan bersama, bukan salinan

Ini inti seluruh buku: Log masuk, pemberitahuan, storan, artikel — semuanya ialah keupayaan yang sama dalam hampir setiap aplikasi. Kami tidak menyalinnya ke setiap projek; kami menerbitkannya sekali sebagai LXS, kemudian menggunakannya berulang kali. Apabila ada masalah keselamatan pada salah satunya, pembaikannya tidak perlu diulang di sepuluh tempat.

Ada dua LXS yang paling menentukan kekuatan kami. Kedua-duanya dibincangkan dalam bab seterusnya.

→ Bab 6 · Gateway & Auth: sumber kekuatan.

6 · Gateway & Auth: sumber kekuatan yang membaiki dengan pantas

Jika buku ini ada satu bab yang paling saya mahu anda ingat, inilah babnya.

Dalam banyak sistem, keselamatan disebarkan: setiap perkhidmatan menjaga dirinya sendiri, menyalin logik log masuk, dan mempunyai tafsiran sendiri tentang siapa yang boleh masuk. Hasilnya mudah diduga: tidak konsisten, sukar diaudit, dan membaiki satu kelemahan bermakna menyentuh banyak tempat.

Kami melakukannya sebaliknya. Dua LXS memegang hampir semua keputusan keselamatan, dan kedua-duanya dipasang di hadapan setiap estate.

Gateway: pintu hadapan yang menolak secara lalai

Gateway ialah satu-satunya pintu masuk dari internet ke perkhidmatan estate. Ia bekerja secara deny-by-default: sesuatu laluan hanya boleh dilalui jika estate menuliskannya secara eksplisit, berserta tahap aksesnya (public, auth, role:superadmin). Tiada “forward semuanya”. Tiada jalan pintas.

Akibatnya:

• Perkhidmatan dalaman tidak perlu (dan tidak boleh) didedahkan secara langsung. Hanya pintu hadapan yang bercakap dengan dunia luar.
• Setiap permintaan diperiksa sekali di satu tempat. Jika ada peraturan baharu atau kelemahan pada logik akses, ia dibaiki di gateway, semua estate mendapatnya.
• Apabila belajar daripada insiden seperti 2 Oktober, kami menambah peraturan hanya di satu titik — dan seluruh estate serta-merta turut selamat.

Auth: satu pihak berkuasa identiti

Auth ialah LXS yang memegang identiti: kata laluan, sesi, token, peranan. Ia juga boleh berperanan sebagai penyedia identiti (OIDC) supaya beberapa aplikasi boleh berkongsi satu akaun. Kerana semua estate menggunakan Auth yang sama, model sesinya pun seragam — dan itu penting, kerana sebahagian besar serangan web menyerang sesi.

Salah satu keputusan yang paling berimpak ialah memindahkan sesi daripada localStorage ke cookie HttpOnly. Cookie HttpOnly tidak boleh dibaca oleh skrip mana-mana pun di halaman, supaya satu celah XSS tidak secara automatik bermakna kecurian sesi. Perubahan ini pun dilakukan sekali di Auth, kemudian terpakai di semua estate yang menggunakannya. (Kisah lengkapnya ada di Bab 12.)

Mengapa ini “kekuatan yang dipropagasikan”

Bayangkan tiga dunia:

• Dunia salinan. Log masuk disalin dalam 10 aplikasi. Kelemahan sesi ditemui. Anda membaiki 10 tempat. Beberapa terlepas. Yang terlepas kekal rapuh selama berbulan-bulan.
• Dunia monolit. Satu pembaikan menjangkau semuanya — tetapi hanya aplikasi itu. Aplikasi lain tetap mempunyai masalahnya sendiri.
• Dunia LXS. Auth dibaiki sekali, dinaikkan versinya, dan semua estate yang mengomposisikannya boleh naik versi. Satu pembaikan, liputan luas, tercatat.

Itulah sebabnya saya menyebut gateway dan auth sebagai sumber kekuatan kami. Bukan kerana kedua-duanya sempurna, tetapi kerana kedua-duanya membolehkan kami bergerak pantas apabila ketidaksempurnaan itu dikesan — dan itu jauh lebih penting daripada dakwaan “selamat” yang tidak dapat dibuktikan.

Serpihan insiden

Apabila scanner 2 Oktober menembak laluan-laluan masuk, bukan setiap perkhidmatan yang menahan. Gateway-lah yang menolak majoriti, dan Auth yang memastikan firewall pendaftaran (pengesahan emel) kekal utuh. Kami tidak perlu menyentuh dua puluh komponen; cukup satu pintu dan satu pihak berkuasa.

→ Setakat ini asas konseptualnya. Bahagian 3 bermula daripada prinsip keselamatan yang terpakai untuk sistem apa pun, LXS mahupun bukan.