Posting ini sekedar catatan untuk diri sendiri mengenai pemakaian SSD. Kalau tidak dicatat tidak akan ingat tentang mulai naiknya kapasitas penyimpanan. Dulu waktu punya Nokia 3650, MMC yang kami pakai cuma 16 MB, sedangkan sekarang memori internal HP saya saja sudah 128 GB.
Saya mulai memakai SSD tahun 2012, waktu itu harganya masih 3400 baht untuk kapasitas 60 GB. Sekarang harganya 750 baht untuk kapasitas 120 GB dan bisa lebih murah lagi jika beli merk nggak jelas di AliExpress. Kapasitas 60 GB sudah jarang ditemui di kota ini.
Setelah dipakai agak lama, ternyata saya cukup suka memakai Thinkpad X230, dan jadinya menginstall banyak program di ThinkPad tersebut. Tadinya 60 GB terasa cukup, tapi jika saya masukkan berbagai data (terutama email dan virtual machine) akhirnya terasa kurang juga. Jadi akhirnya kemarin beli SSD 240 GB dengan harga 1290 baht.
Dulu waktu saya mulai memakai SSD, belum semua sistem operasi mendukung TRIM (dan belum semua SSD mendukung perintah ini), tapi sekarang ini sudah jadi default di semua OS baru. Perintah TRIM memungkinan pemakaian SSD lebih awet karena controller SSD bisa diberitahu data mana yang sudah tidak terpakai, jadi bisa lebih mengoptimalkan algorima “wear leveling”. Penjelasan detailnya agak panjang, jadi bisa dibaca di berbagai artikel di web (misalnya ini).
Sekarang semua komputer saya sudah memakai SSD, minimal untuk OS-nya. Saya juga masih memakai HDD ntuk penyimpanan data yang besar. Saya sudah mencoba beberapa merk SSD, termasuk juga beberapa kali mencoba SSD merk China (King Dian), dan sejauh ini semuanya masih awet. Tapi hal ini bukan jaminan, adik saya punya pengalaman buruk dengan SSD dari China yang dibeli online (rusak dalam beberapa bulan), jadi mungkin ini untung-untungan. Untuk data yang penting, saya memilih SSD bermerk dengan garansi, dan tetap membackup data karena SSD bisa rusak tiba-tiba sewaktu-waktu.
Seringkali ketika ingin menuliskan topik security, saya bingung mulai dari mana karena banyak sekali topik security yang butuh dasar ilmu komputer yang baik. Tanpa satu dasar yang baik, penjelasan topik security bisa jauh ke mana-mana. Selain itu saya juga sering dapat pertanyaan yang aneh-aneh.
Contoh pertanyaan konyol yang sering saya dapatkan adalah: saya diberi string dalam base64 dan ditanya apa artinya. Atau bagaimana mendecode string heksa yang adalah sebuah hash. Ini sama saja dengan bertanya: 763748 itu angka apa? bisa berupa apa saja, mungkin nomor Induk mahasiswa, mungkin sisa saldo rekening Anda, 6 digit terakhir nomoer telepon gebetan Anda, PIN iPad kakek Anda, dsb.
Kalau bisa melihat isi gembok, lebih gampang membukanya tanpa kunci
Di sisi lain ada pertanyaan yang benar, tapi sulit dijawab dengan singkat, misalnya mengenai SSL pinning. Saya tadinya ingin menuliskan tentang SSL pinning dan bagaimana caranya membypass hal tersebut. Supaya pembahasannya tuntas, saya perlu membahas banyak hal.
Hal pertama adalah cara kerja SSL, yang melibatkan penggunaan public key cryptography. Di sini perlu diketahui mengenai kunci publik, kunci privat. Kemudian perlu dijelaskan mengapa SSL pinning ini diperlukan. Lalu perlu dijelaskan mengenai certificate (yang bisa ada dalam berbagai format). Perlu dijelaskan juga bagaimana mendapatkan sertifikat SSL ini atau bagaimana membuat sendiri (untuk self signed certificate). Dari sertifikat itu, kita perlu mengekstrak informasi hash public key untuk melakukan pinning.
Itu baru sampai topik dasarnya, belum masuk ke bagian: bagaimana SSL pinning diimplementasikan. Untuk Android bisa dengan kode Java (dengan berbagai library), bisa dengan native code (misalnya dengan libcurl + openssl), bisa dengan fitur Android OS 7 ike atas (Network Security Configuration). Untuk iOS pembahasannya juga akan banyak.
Setelah itu baru bisa masuk ke topik bagaimana bypass SSL pinning. Inipun bisa dengan banyak teknik, bisa dengan patching APK/IPA, bisa dengan Frida, bisa dengan berbagai tool yang sudah ada. Biasanya 99% orang yang bertanya ke saya cuma membaca: pakai tool ini atau pakai skrip frida “universal” ini, dan hasilnya nggak jalan, dan mereka bingung harus meneruskan dari mana.
Untuk memudahkan pembahasan berbagai topik security, saya akan mulai menulis berbagai topik kecil yang terpisah. Sebagian topik ini mungkin akan terlalu dasar bagi banyak orang, tapi daripada saya harus menjelaskan ulang puluhan kali, akan lebhi baik jika saya tuliskan saja.
Rencananya topik-topik yang akan saya bahas yang praktis saja, walau kenyataannya dalam hidup ini kita perlu tahu sangat banyak hal untuk dapat mengevaluasi security sebuah sistem. Contohnya baru-baru ini saya membaca mengenai pentingnya ilmu geometri dalam menemukan bug di library grafik.
Sejak tulisan saya mengenai bug Go-jek tahun 2016, sudah ada banyak sekali driver yang meminta bantuan saya untuk: unsuspend status driver atau membantu hack aplikasi Go-jek. Saya masih bisa sedikit mengerti kalau ada yang bertanya soal Go-jek, tapi banyak juga driver Grab yang bertanya hal serupa. Semua jawaban saya sama: saya tidak bisa membantu masalah Anda. Silakan diselesaikan dengan pihak Go-jek/Grab.
Biasanya jawaban tersebut dianggap kurang memuaskan, jadi perlu dijawab panjang. Saya sudah capek menjelaskan, jadi akan saya tuliskan jawaban saya di sini agar gampang dilink untuk menjawab. Biasanya pertanyaan awal disambung dengan: Kan dulu Anda bisa ngehack Go-jek, pasti bisa lagi dong?. Begini ya: dulu keamanan mereka itu lemah sekali. Kira-kira keamanannya seperti ini:
Intinya saat itu siapa saja bisa masuk dan mengambil data driver, dan juga data penumpang. Artinya dari mulai KTP, foto wajah, sampai nama Ibu kandung driver bisa diambil, demikian juga informasi penumpang dan berbagai rute yang diambil juga bisa dilihat siapa saja.
Waktu itu penting bagi saya memberitahu bug itu ke dunia, karena penumpang dan driver perlu tahu bahwa data mereka bocor. Kalau tiba-tiba ada penagih hutang kartu kredit datang ke rumah karena ada yang mengambil alih identitas (berpura-pura jadi seseorang, istilahnya: identitiy theft) dari informasi yang bocor tersebut dan berhutang kartu kredit atas nama orang tersebut, maka driver atau penumpang bisa sangat rugi
Setiap kali menemukan bug, saya beritahu bug itu ke pihak terkait, lalu mereka akan menambal bugnya. Di contoh gambar di atas: gemboknya sudah diganti dan dikunci lebih baik. Tidak berarti sistemnya 100% aman, tapi sekarang tidak sembarang orang bisa mengambil data.
Go-jek sekarang sudah lebih aman dari ini
Ada juga yang bertanya: apakah tidak mau mencoba ngehack Go-jek lagi? Jawabannya: saya tidak tertarik. Saya sudah punya banyak kerjaan pentesting yang jelas pasti dibayar, daripada mencari bug Go-jek yang mungkin ada, mungkin tidak ketemu, dan tidak dibayar. Bahkan seumur hidup saya sampai saat ini, baru memakai Gojek di bulan lalu ketika liburan di Indonesia.
Bug Go-jek itu sudah 3 tahun yang lalu dan cuma satu episode yang pernah terjadi di hidup saya, dan saya sudah move on ke hal-hal lain baik yang berhubungan dengan security ataupun tidak. Ada banyak cerita security yang saya ceritakan di sini, dan banyak juga yang tidak diceritakan. Beberapa hal seputar security setelah go-jek yang ditulis di blog saya tapi mungkin tidak dibaca kebanyakan orang misalnya: saya menemukan bug di Mastercard (dapat 8500 USD), saya mendapatkan training security gratis di Belanda, saya menang CTF sehingga bisa jalan-jalan gratis sekeluarga ke Disneyland Hong Kong, membongkar algoritma keamanan Pokemon Go Plus, dsb. Dan masih banyak lagi hal-hal yang tidak saya tuliskan.
Nasihat saya: jika ada masalah, selesaikanlah dengan pihak Go-jek/Grab. Liburan terakhir saya ke Indonesia, saya sempat “dikerjai” driver yang menyatakan statusnya sudah sampai tempat penjemputan, dan tiba-tiba jadi “dalam perjalanan”, dan sekian menit kemudian “tiba di tujuan”, padahal drivernya belum nongol. Apakah saya ngehack langsung sistemnya? atau menghubungi teman yang kerja di Grab? nggak, saya memakai jalur resmi untuk melaporkan kelakuan driver tersebut dan semua bisa beres dalam waktu singkat.
Melakukan sesuatu yang tidak sesuai aturan juga berisiko bagi orang yang membantu Anda. Misalnya Anda ketemu orang dalam yang bisa membantu unlock status driver, maka jika ketahuan, maka orang tersebut kemungkinan besar akan dipecat. Jika orang eksternal berhasil menemukan jalan masuk dan ketahuan maka bisa ditangkap polisi. Andaikan saya bisa masuk pun, saya tidak akan mengambil risiko hidup saya demi hidup Anda (apalagi saya tidak kenal Anda).
Saya tahu bahwa sebuah sistem kadang tidak sempurna, dan kadang mungkin Anda benar disuspend karena kesalahan sistem. Tapi sistem Go-jek/Grab bukanlah milik saya, jadi mohon selesaikanlah dengan pemilik sistem dengan cara yang legal.
Minggu lalu karena kombinasi beberapa hal, saya memutuskan ingin membeli Thinkpad bekas dan ngoprek FreeBSD di laptop itu. Laptopnya dipesan hari Minggu dan sampai hari Rabu siang lalu. Saat ini laptop ini sudah berhasil: diganti SSD-nya, ditambah RAM-nya, diinstall Coreboot (software open source pengganti BIOS), dan sudah diinstall FreeBSD 12 dengan segala setting yang membuat semuanya berjalan normal.
Kalau dipikir-pikir sebenarnya nggak ada alasan yang kuat untuk harus beli laptop dan install FreeBSD, cuma seneng aja ngoprek di hardware langsung. Sekitar 10 tahun yang lalu saya pernah ngoprek FreeBSD, di Virtual Machine. Porting kernel ARM untuk NAS yang dulu saya miliki. Dibandingkan virtual machine, ngoprek langsung di hardware punya tantangan sendiri.
Sebenarnya yang saya pesan dari Shopee adalah Thinkpad X220, tapi ternyata malah dikirim X230 (yang lebih baik), jadi ya saya terima aja. Spesifikasinya: Core i5-3320M 2.6 Ghz, RAM 4 G, HDD 300 GB. Laptopnya memiliki lisensi Windows 7. Ketika sampai, saya test bahwa semua hardware berjalan normal (kecuali suara, entah kenapa tidak ada suara di Windows 7, sepertinya masalah driver). Secara umum kondisi laptop cukup baik, yang agak mengganggu hanya ada cacat di layar, ada noda agak terang tapi relatif kecil. Saya punya SSD lama 60 GB yang tidak saya pakai, jadi saya ganti saja dengan SSD supaya lebih cepat sebelum saya install FreeBSD (60 GB sudah lebih dari cukup buat sistem yang lengkap).
Instalasi FreeBSD bisa saya lakukan cepat sekali, dan setelah mengikuti beberapa tutorial di Internet untuk mengubah berbagai konfigurasinya, semua bisa berjalan normal. Ini mengingatkan saya jaman dulu memakai laptop Linux, harus banyak konfigurasi berbagai hal supaya berbagai fitur bisa jalan. Saat ini kalau saya memakai Linux, semua fitur sudah jalan tanpa perlu dioprek. Berbagai fitur yang langsung dicoba adalah: WIFI, Sound, Power management (termasuk juga berbagai shortcut untuk meredupkan layar, close lid untuk hibernate, dsb).
Hal berikutnya yang ingin saya lakukan adalah menginstall Coreboot (dulu namany LinuxBIOS). Coreboot adalah proyek open source pengganti BIOS. Salah satu turunan proyek ini adalah Libreboot yang lebih strict dari coreboot, sama sekali tidak memakai “blob” proprietary.
Untuk menginstall coreboot pada X230 kita perlu membongkar dulu laptopnya dan memakai SPI Flash Programmer. Beberapa jenis Thinkpad yang lebih lama tidak butuh programmer ini, tapi versi X230 dan beberapa versi yang lebih baru sudah diproteksi sedemikian rupa sehingga tidak bisa dilakukan dengan software saja. Langkah yang diperlukan adalah mengekstrak BIOSnya, mengambil beberapa komponennya, mengganti sisanya dengan coreboot dan menuliskan kembali hasilnya ke chip tersebut. Langkah ini cuma diperlukan sekali saja, karena setelah itu BIOS akan bisa diflash langsung dari OS Linux/FreeBSD.
Membaca SPI Flash biasanya saya lakukan dari Raspberry PI (seperti ketika hacking Pokemon Go), tapi tidak berhasil ketika saya coba membaca BIOS Thinkpad ini. Kemungkinan besar masalahnya adalah kabelnya terlalu panjang. Karena kabel dari klip SPI-nya memang panjang sekali, saya mencoba mencari cara lain, dan teringat bahwa saya pernah membeli SPI Flasher berbasia CH341 yang belum pernah saya pakai. Ternyata dengan SPI Flasher ini BIOS-nya langsung terbaca.
Klip SPI Flash ini sangat berguna
Waktu membongkar laptopnya, saya lihat bahwa RAM-nya adala 1 x 4 GB DDR3, dan masih ada satu slot kosong. Saya teringat masih punya DDR3 lama dari laptop dulu, dan ternyata masih bisa dipakai. Sekarang total RAM-nya laptop ini adalah 6 GB. Ada peringatan di halaman Coreboot bahwa RAM bisa tidak terdeteksi. Tapi ternyata booting bisa berjalan dengan baik, dan bisa masuk ke FreeBSD.
Sekarang ada masalah baru: batere tidak terdeteksi oleh sistem operasi sehingga tidak diketahui kapasitasnya. Sebelum memakai coreboot, saya sudah cek bahwa baterenya masih bisa dipakai sekitar 3 jam, yang biasanya lebih dari cukup karena saya memakai laptop ini terutama ketika mengantar Jonathan Tae Kwondo, dengan waktu ganti baju dsb, akan selesai sekitar 2 jam.
Status batere adalah hal yang sangat penting untuk sebuah laptop, jadi saya baca-baca apa masalahnya. Ternyata ada banyak yang mengalami, dan solusinya adalah dengan compile kernel development terbaru. Setelah saya cek, ternyata patchnya sangat kecil, jadi saya patch saja kernel saat ini. Kompilasi kernel FreeBSD sangat mudah. Kompilasi pertama kali agak lama karena butuh ‘buildworld’ yang akan mengcompile semua requirement untuk kompilasi kernel dan semua tool standar sistem, setelah itu kita hanya perlu ‘make buildkernel’ dan ‘make installkernel’.
Saya mengecek di AliExpress dan Shopee Thailand, ternyata masih banyak yang menjual berbagai parts dan aksesori untuk Thinkpad. Komponen pengganti standar seperti Batere, Layar LCD, Keyboard masih banyak dijual. Bahkan karet penyangga “kaki” laptop yang sering lepas juga masih bisa dicari di AliExpress. Card tambahan untuk 3G/4G/GPS juga masih dijual, walaupun saat ini saya belum tertarik untuk memakainya.
Dari sisi software, banyak software Linux bisa berjalan di FreeBSD, bahkan Wine juga tersedia untuk menjalankan aplikasi Windows. Kebetulan saya butuh Wine karena gagal mengkompilasi ucblogo untuk FreeBSD dan butuh solusi cepat. Saya memakai ucblogo karena Jonathan selesai membaca komik Secret Coders, yang mengajarkan pemrograman dengan bahasa LOGO dan implementasi yang dipakai adalah ucblogo. Saya perlu memahami beberapa hal dasar yang tidak obvious (seperti mengedit/menyimpan file) agar Jonathan bisa membuat karya yang disimpan.
Beberapa hal yang tidak bisa dilakukan saat ini adalah: menonton Netflix karena masalah DRM (meski Chromium bisa diinstall tapi tidak bisa meload plugin Netflix). Untuk developer: Docker juga tidak ada di FreeBSD. VirtualBox seharusnya bisa berjalan, tapi saat ini hang ketika saya jalankan. Tapi berbagai kelemahan ini saat init tidak mengganggu bagi saya karena saya bisa menonton Netflix di HP atau komputer lain, dan saya tidak harus memakai docker (kalaupun sangat butuh, bisa SSH ke server lain).
Seiring bertambahnya usia, kebanyakan orang akan makin malas ngoprek hal-hal seperti ini, tapi bagi saya hal-hal seperti ini sangat menyenangkan. Saya jadi teringat dulu waktu saya ngoprek Linux di laptop di dekade lalu. Saya juga senang ternyata masih ingat dengan berbagai hal di FreeBSD walaupun jarang menyentuh OS ini. Tulisan iseng ini diketik dan diposting dari Thinkpad X230.
Tanggal 1 Februari nanti akan ada perubahan bersangkutan dengan DNS (Domain Name System). Secara singkat: berbagai domain yang terdaftar di berbagai DNS server yang tidak compliant dengan standar EDNS akan bermasalah sejak tanggal itu. Sebagai user: kemungkinan beberapa domain menjadi tidak bisa diakses sejak tanggal tersebut (atau beberapa hari/minggu setelahnya).
Sayangnya penjelasan singkat tersebuttidak cukup dan bikin penasaran banyak orang: sebenarnya apa sih yang akan terjadi? Saya coba cari sekilas belum ada penjelasan dalam bahasa Indonesia yang mudah dimengerti, jadi saya akan mencoba menjelaskannya di sini. Sebelum masuk ke penjelasan flag day ini, saya akan mulai dulu dengan penjelasan singkat tentang DNS dan sedikit sejarahnya karena ini ada hubungannya dengan masalah saat ini.
Apa itu DNS?
Pada Internet Protocol (IP) ketika sebuah program melakukan koneksi ke sebuah server berdasarkan nama, maka diperlukan proses translasi dari nama menjadi alamat IP. Proses translasi ini dulunya hanya memakai file teks (hosts.txt) ketika internet belum besar. Sampai sekarang pun ini masih didukung berbagai sistem operasi dengan file hosts.
Ketika jumlah domain makin banyak, maka diperlukan sistem baru. Mulai tahun 1983 sudah dibuat standar DNS (RFC 882 dan RFC 883), dan pada tahun 1984 software berdasarkan standar tersebut sudah mulai dibuat (namanya BIND). Kemudian pada tahun 1987 dibuat standar baru (RFC 1034 dan RFC 1035) menggantikan standar pertama.
Sebenarnya cara kerja DNS cukup sederhana: daripada semua nama dikelola satu pihak, biarlah dikelola masing-masing pihak dengan hierarki tertentu. Kenapa bentuknya hierarki seperti ini? Setiap level dari hierarki ini bisa diatur oleh sebuah otoritas untuk nama tersebut. Saya ambil contoh sebuah universitas ITB yang memiliki banyak jurusan.
Tiap jurusan bisa punya subdomain sendiri (misalnya if.itb.ac.id untuk informatika)
Tiap jurusan bisa memiliki DNS server sendiri, supaya bisa menambah/mengubah subdomainnya sendiri (tidak perlu repot lapor ke universitas)
Di level itb.ac.id perlu diset, bahwa NS record untuk if.itb.ac.id ditangani oleh server tertentu di jurusan informatika
Ini berlaku untuk semua domain, bukan hanya domain organisasi seperti itu. Ketika kita mencari apakah IP untuk sebuah domain blog.compactbyte.com, maka pertama yang dilakukan adalah:
Mencari tahu server mana yang menangani .com. Untuk pertanyaan paling atas ini bisa ditanyakan ke root name server (ada beberapa di dunia ini). Kita akan mendapatkan daftar server-server (bisa lebih dari satu) yang menangani domain .com
Kita bisa bertanya ke salah satu server tersebut: mana server yang menangani compactbyte.com?
Kita bisa bertanya ke server yang menangani compactbyte.com: apa alamat untuk blog.compactbyte.com
Proses di atas dinamakan resolving, dan proses selangkah demi selangkah dari titik atas itu disebut recursive resolving. Tentunya kalau saya membuat program, saya tidak akan menulis sendiri kode untuk melakukan resolving. Sudah ada library resolver yang akan melakukan semua proses di atas.
Server-server di atas memiliki daftar seluruh domain .com di dunia
Sebenarnya dalam dunia nyata, proses seperti itu tidak benar-benar dilakukan karena lambat, tiap kali ingin pergi ke facebook, harus mencari dulu di root server mana yang menangani .com, lalu mana yang menangani facebook.com dst. Dalam praktiknya: kalau sudah tahu nama domainnya, hasilnya akan dicache. Jadi setiap kali proses tidak perlu lagi bertanya ke root server untuk .com karena jawaban sudah dicache.
Supaya lebih efektif biasanya kita memakai sebuah server DNS publik. Ini biasanya dari ISP tapi bisa juga memakai milik Google (8.8.8.8), Cloudflare (1.1.1.1), dan masih banyak lagi. Ketika kita bertanya ke DNS milik ISP kita, maka biasanya jawaban bisa instan karena banyak orang mengakses situs yang sama dan jawabannya masih diingat (dicache). DNS server semacam ini disebut sebagai “caching server“.
Artikel di Wikipedia memberikan gambar yang lebih real mengenai proses ini. Ketika kita bertanya ke DNS milik ISP, maka server tersebut bisa bertanya ke server DNS lain, atau melakukan sendiri proses rekursif yang saya jelaskan di atas untuk mencari IP sebuah domain.
Di dalam server DNS, catatan pemetaan nama ke IP disimpan sebagai sebuah record. Tepatnya lagi ini disebut sebagai address record (singkatnya satu huruf: A). DNS juga memiliki berbagai record lain. Contoh record lain adalah mail exchanger (singkatnya MX) untuk mengetahui server mana yang digunakan untuk menangani email. Kenapa harus ada banyak record? karena kegunaannya berbeda-beda. Contohnya dengan adanya record MX yang terpisah dari record address (A) maka kita bisa punya email yang dihosting di server lain (misalnya Google) dan tidak harus di server kita sendiri.
Saya juga akan menjelaskan sedikit apa yang terjadi waktu kita membeli domain. Domain kita akan didaftarkan di server TLD. Lalu biasanya tempat kita membeli domain akan mengeset otomatis name server ke server milik registar tempat kita membeli. Ini bisa kita ubah agar memakai server lain, misalnya server sendiri atau Cloudflare
Blog ini memakai cloudflare
Beberapa hal yang perlu diketahui adalah:
Di dalam mesin (PC/Mobile) ada software resolver
Dalam server DNS juga ada resolver untuk bertanya pada server DNS lain
Software di berbagai server ini bisa berbeda (tidak hanya ada satu software server DNS, ada banyak, dan masing-masing ada banyak versi)
Satu server DNS bisa menangani banyak domain
Extension Mechanism for DNS (EDNS)
Spesifikasi awal DNS kurang fleksibel sedangkan diperlukan banyak fitur baru untuk DNS baik itu untuk meningkatkan performance maupun security. Contoh masalah performance: pada sistem DNS lama ukuran paket yang bisa ditransfer maksimum hanya 512 byte via UDP. Dalam hal security: sebuah DNS server bisa dibajak dengan relatif mudah karena tidak ada signature atau tanda tangan digital yang menyatakan bahwa record yang terdaftar adalah benar adanya.
Pada tahun 1999 diperkenalkanlah Extension Mechanism for DNS. Kemudian standar ini diperbaiki lagi tahun 2013. Jadi EDNS ini sudah dicetuskan 20 tahun yang lalu. Mekanisme EDNS ini backward compatible dengan DNS. Di atas EDNS ini dibangunlah berbagai teknologi baru seperti DNSSEC (Domain Name System Security Extensions).
Untuk mengetahui apakah sebuah server DNS kompatibel dengan EDNS, maka ini yang dilakukan:
Resolver akan menanyakan record OPT yang tidak dikenali oleh DNS server lama
Server lama (tidak mendukung EDNS) akan mengabaikan OPT, dan menjawab record yang bisa dijawab
Server yang baru (mendukung EDNS) akan menjawab bahwa OPT didukung
Sejak diciptakannya, DNS sudah menjadi sistem yang sangat kompleks, dengan 185 RFC yang total halamannya lebih dari 2000 halaman jika dicetak. Ini membuat detail DNS sulit dipahami, dan banyak orang tidak mau pusing memakai software baru yang mendukung berbagai fitur DNS, selama semuanya masih berjalan normal. Ini salah satu alasan kenapa orang tidak mengupdate semua ke server versi terbaru.
Masalah EDNS
Sekarang masalahnya adalah: ada server yang tidak menjawab jika ditanya dengan record OPT, atau jawabannya tidak benar (silakan lihat presentasi ini untuk berbagai jawaban yang salah). Sebenarnya yang diharapkan cuma ini:
Kalo kamu mendukung EDNS, jawab yang tegas dengan benar
Kalo kamu tidak mendukung EDNS, jawablah bahwa tidak mendukung EDNS
Banyak server yang jawabannya tidak jelas, atau bahkan tidak menjawab. Untuk mengatasi ini, resolver DNS harus bekerja ekstra (istilahnya untuk akal-akalan ini adalah workaround): Jika server ditanya dengan protokol EDNS dan menjawab dengan sempurna, maka diasumsikan server tersebut memang mendukung EDNS. Tapi jika ternyata tidak mendukung, maka ditunggu dulu sampai timeout, terus dicoba lagi ditanya pakai protokol DNS lama (dan kadang tidak menjawab juga, tunggu lagi sampai timeout).
Proses ini tentunya membuat lambat proses resolving. Karena sudah lama sekali standar ini diperkenalkan, maka diputuskan begini:
Mari kita stop workaroundnya: kalau jawaban server nggak standar, ya sudah ignore aja servernya (anggap sudah mati)
Mari kita buat internet lebih aman dengan mengadopsi standar baru
Kapan ini harus dilakukan? setelah dilihat bahwa sebagian besar (>90% server) sudah mendukung EDNS, maka diputuskan bahwa tanggal 1 Februari 2019 merupakan saat yang tepat. Berbagai DNS publik dunia akan menghentikan workaround yang dilakukan dan berbagai software yang tadinya mendukung workaround juga akan diupdate.
Flag Day
Kenapa namanya flag day? nama ini sifatnya historis. Dulu ada perubahan definisi ASCII di sistem operasi Multics yang dilakukan di Flag Day (hari bendera amerika). Sejak itu istilah ini digunakan untuk perubahan besar pada sistem komputer.
Seperti dijelaskan di atas: software resolver ini ada di device (PC/mobile) kita, dan juga ada di DNS publik seperti ISP dan Google). Biasanya resolver di mesin (komputer/ponsel) kita hanya akan bertanya ke caching server lain di ISP atau DNS publik lain.
Pada flag day, resolver publik yang besar (seperti Google, Quad9, CloudFlare) akan mematikan support untuk workaround. Server DNS untuk domain tertentu yang tidak menjawab dengan benar akan dianggap mati. Sebenarnya yang diharapkan bukan semua server harus support EDNS, tapi harus menjawab dengan jujur dan benar support atau tidak support. Jika kita memakai salah satu server DNS publik tersebut (baik langsung maupun tidak langsung), maka kita akan gagal mengakses domain-domain tertentu.
Untuk sementara waktu, ketika ISP belum mengupdate softwarenya, mungkin situs tersebut masih bisa diakses, tapi setelah beberapa waktu, berbagai ISP di dunia akan mengupdate server/resolver mereka dengan versi terbaru dan akhirnya domain-domain tersebut akan tidak bisa diakses sama sekali jika software DNS pada server yang tercantum di nama domain tidak diupdate.
Sebagai catatan: bukan pemilik domain yang harus mengupdate software, tapi pemilik server DNS yang dipakai di domain tersebut. Jadi misalnya Anda membeli domain dari sebuah registrar dan memakai nameserver registrar, maka registrar tersebut yang harus mengupdate software DNS-nya. Alternatif lain adalah: pemilik domain bisa memakai server DNS lain yang sudah memakai software DNS terbaru.
Selain perubahan di DNS publik, ada juga perubahan kode pada berbagai library resolver dan server DNS, misalnya BIND supaya mendrop workaround. Contoh realnya perubahan kode yang dilakukan di BIND bisa dilihat di URL ini:
Domain yang Anda miliki bisa dicek di situs https://dnsflagday.net. Jika hasilnya OK, maka sudah aman. Jika hasilnya STOP, maka ini sangat berbahaya, dan jika hasilnya SLOW maka sebaiknya setting server diperbaiki atau versinya diupdate. Sebelum panik, cobalah testnya sekali lagi, karena jika server sedang sibuk, kadang hasilnya bisa salah. Jika mengerti penggunaan dig, maka sebaiknya cek juga secara manual dari jaringan yang dekat dengan server (misalnya jika server di Indonesia, cek dari ISP Indonesia).
Ketika hasilnya SLOW atau STOP akan muncul link yang menjelaskan masalah detail eksaknya untuk domain tersebut. Jika situs Anda cuma diakses puluhan atau ratusan orang, response “SLOW” mungkin tidak apa-apa, tapi jika situs Anda sangat ramai, ya sebaiknya diperbaiki.
Seperti yang sudah saya sebutkan sebelumnya, sebagai pemilik domain, yang bisa dilakukan adalah:
Pindah name server ke yang sudah mendukung software terbaru
Menghubungi pemilik server DNS untuk mengupdate softwarenya
Jika Anda sekedar pemakai sebuah situs, Anda bisa juga memeriksa situs tersebut dan memberi tahu adminnya, supaya dia bisa melakukan perubahan yang perlu. Ini terutama untuk situs yang kecil/kurang populer karena situs besar biasanya sudah menangani ini.
Penutup
Kadang masalah tertentu sulit dijelaskan tanpa mengetahui detail teknis, dan DNS Flag Day ini merupakan salah satu contohnya. Semoga artikel ini cukup bisa menjelaskan. Secara umum: tidak perlu panik. Para admin mungkin harus bekerja ekstra keras, tapi persiapan DNS Flag Day ini sudah cukup lama, jadi harapannya semua akan berjalan lancar pada tanggal yang ditentukan nanti.
Ini saya tuliskan karena sering sekali mendapatkan pertanyaan baik langsung maupun di group yang menurut saya tidak jelas dan kemudian membuang waktu semua orang. Jika seseorang bertanya dengan cara yang baik maka kemungkinan dijawabnya akan lebih besar dan lebih cepat.
Cari dulu di Google
Ada satu hal penting sebelum bertanya: cobalah dulu mencari dengan Google. Sekarang ini Google bisa ditanya dengan bahasa natural: “apa ibukota Indonesia?” dan akan dijawab “Jakarta”. Berbagai pesan error juga bisa dicopy paste ke Google untuk mencari jawabannya.
Kalau sudah mentok, bisa bertanya ke group atau langsung ke seseorang. Misalnya: “saya berusaha mencari tahu tentang topik X, sudah saya cari di Google dengan kata kunci berikut, tapi tidak ketemu jawabannya. Apakah ada kata kunci lain yang lebih baik?”
Salam sambil bertanya
Hal pertama adalah mengenai salam. Di dunia nyata, biasanya kita memberi salam dulu, menunggu jawaban, lalu bertanya. Di dunia maya tidak perlu seperti itu, beri salam sambil bertanya akan lebih efisien. “Selamat siang”, nunggu saya menjawab beberapa jam kemudian, lalu saya jawab “Selamat sore”, beberapa jam kemudian orang tersebut sudah tidak online, tidak tahu tadinya ingin bertanya apa. Kadang saya sedang online dan bisa langsung menjawab: “selamat siang”, lalu harus menunggu orang tersebut mengetikkan pertanyaan panjangnya.
Akan lebih efisien jika langsung: “Selamat siang, saya ingin bertanya mengenai <jelaskan masalahnya>”. Untuk sebagian pertanyaan, saya sudah tahu jawabannya dan bisa langsung saya jawab, atau bisa saya berikan linknya. Untuk pertanyaan yang lebih rumit, saya bisa mikir dulu untuk menjawab nanti (atau kadang perlu menunggu sampai rumah untuk mengirimkan suatu dokumen atau artikel di komputer saya). Jika pertanyaan via email, maka subjectnya harus jelas, bukan sekedar: “Halo”, “Salam kenal”, dsb.
Tanya di tempat yang benar
Tujuannya ada banyak group, dengan banyak sub group (misalnya untuk security ada Forensic, Web Security, Reverse Engineering, dsb) adalah supaya diskusinya terfokus. Jika semua group dipakai untuk tanya apa saja, ya buat apa ada banyak group?
Buat apa ada group Python, Javascript, dsb kan sama-sama programming? kenapa nggak boleh nanya SQL injection di Reverse Engineering, kan sama-sama security? Sekalian aja kenapa gak boleh bertanya tentang memelihara burung di group botani, kan sama-sama mahluk hidup.
Kenali topik Anda apa dan tanyakan di group yang sesuai. Jangan maksa bertanya topik yang di luar group. Jika jawabannya adalah: carilah group lain, maka carilah group lain ada banyak daftar group telegram, Facebook dsb di berbagai website.
Pertanyaan harus jelas
Pertanyaan juga sebaiknya yang jelas. Sering kali di sebuah group yang anggotanya sudah beberapa ratus atau bahkan beberapa ribu (Group Telegram anggotanya bisa ribuan) seseorang datang cuma bilang: “Halo, ada yang tau XX” dengan XX adalah sesuatu yang sangat umum, misalnya “Ada yang tahu Tensorflow?” (di group Machine Learning), “ada yang tahu mysql?” (di group Database), “Ada yang tahu heap? (di group Reverse Engineering).
Kalau setiap anggota group yang anggotanya 2000 orang harus menghabiskan 2 detik dari menerima notifikasi sampai membaca pesannya, Anda menghabiskan total 4000 detik di bumi ini dari semua orang. Ini seperti orang yang memblokir lift karena sedang ngobrol dengan temannya, atau parkir di pinggir jalan yang sudah sempit sehingga orang sulit lewat: semuanya membuang waktu orang lain.
Pertanyaan seperti itu nggak jelas, dan dari ribuan orang kemungkinan ada yang tahu jawabannya (apalagi bertanya di group yang memang membahas topik itu). Masalahnya adalah: Anda ingin tahu apa? misalnya bertanya “Ada yang tahu mysql?”, lalu dijelaskan “mysql adalah dbms bla bla bla”, lalu ternyata yang ingin ditanyakan adalah: “mysql saya gak jalan”. Biasanya kemudian ada yang mengambil asumsi tertentu (Mysql di Linux dengan systemd), dan kemudian langsung menjawab dengan systemcl, tapi ternyata Mysql-nya di Windows.
Jadi pertanyaan harus jelas: bukan dengan mulai “siapa yang tahu topik X”, tapi tanyakan dengan jelas apa yang ingin Anda ketahui. Lalu berikan konteks yang jelas: saya sedang berusaha melakukan X tapi gagal. Berikan informasi tambahan yang perlu misalnya: saya coba di Linux, atau saya coba dengan software versi X, atau apapun yang kira-kira penting. Contoh info yang penting: ini saya download dari situs lain karena situs resminya down (ternyata di situs itu cuma ada versi lama), saya compile sendiri (ternyata salah opsi ketika compile), dsb.
Jika pertanyaan berhubungan dengan kode program, sertakan kode programnya. Jika sangat singkat (1 fungsi kecil) bisa langsung di teks pesan, tapi jika lebih panjang, masukkan ke gist atau pastebin. Jangan mengirimkan image/screenshot source code. Image sulit dibaca, tidak bisa copy paste dengan mudah untuk menunjukkan salahnya, dan kadang tidak lengkap. Jika ada pesan error: tunjukkan dengan lengkap (tapi jika errornya panjang, masukkan ke gist atau pastebin).
Bersiap menerima jawaban
Bagian berikutnya adalah: bersiaplah menerima jawaban. Tanyalah ketika Anda sedang di depan komputer, kadang sudah dijawab dengan sangat cepat, tapi kemudian dijawab lagi dengan “Oh saya lupa versinya, nanti saya cek lagi” atau “OK, nanti saya coba kalo sudah di desktop”. Kenapa nggak nanya pas sedang di depan desktop? Ini terutama jika pertanyaan diajukan ke group dengan ribuan orang di dalamnya, yang biasanya merespon dengan cepat. Yang lebih menyebalkan lagi adalah: sudah dijawab baik dengan jawaban yang sudah jelas, atau direspon dengan pertanyaan klarifikasi, tapi kemudian tidak dibalas sama sekali oleh penanya awal.
Jika jawaban semua orang adalah: pelajari dulu topik X. Maka jangan ngeyel. Jika ada yang bertanya: saya coba bongkar aplikasi X dengan ida pro, kok munculnya “db” semua ya? Setelah dijawab, kembali ke pertanyaan sederhana “ini artinya apa?” dst. Bisa terlihat bahwa orang tersebut masih buta soal reversing. Semua orang menyarankan coba dulu bongkar aplikasi lain, supaya paham hal-hal dasar, lalu dijawab: tapi saya maunya langsung bongkar aplikasi X. Maunya disuapi belajar langkah demi langkah.
Ada banyak hal yang tidak bisa dijawab dengan singkat (pertanyaanya sangat umum). Coba jika ada yang bertanya: saya bingung konsep diferensial di kalkulus, tolong jelaskan ke saya? Apakah Anda bisa menjelaskannya dengan singkat dan bisa dipahami lewat chatting? (beberapa pertanyaan sejenis ini misalnya: saya bingung konsep managemen memori di C). Jadi jawaban yang bisa diberikan paling-paling: coba baca buku X atau Y, lihat video Youtube, lalu coba-coba sendiri.
Sharing
Terakhir: ucapkan terima kasih. Ini tujuannya selain untuk kesopanan juga untuk menutup topik (bahwa jawaban yang diberikan sudah cukup jelas dan membantu). Kadang masih ada beberapa jawaban ekstra karena dikira topiknya belum selesai.
Bentuk terima kasih yang paling bagus adalah dengan membagikan apa yang Anda tahu. Jika Anda tahu jawaban sesuatu, atau mengerti topik sesuatu, Anda bisa menuliskannya di blog misalnya, supaya orang berikutnya bisa membaca jawaban Anda. Jadi jangan cuma jadi orang yang pasif menerima jawaban untuk kepentingan sendiri saja.
Jika tidak dijawab
Meskipun sudah bertanya dengan baik dan sopan, belum tentu pertanyaan Anda dijawab, dengan banyak alasan:
Memang tidak ada yang tahu jawabannya
Orang yang tahu jawabannya sedang tidak ada waktu untuk menjawab, atau mungkin terlewat membaca pertanyaan itu
Reputasi Anda jelek, orang sudah malas menjawab
Tidak ada kewajiban bagi orang lain untuk menjawab
Coba renungkan juga: berapa kali Anda menjawab seseorang, ketika ada yang bertanya dan Anda tahu jawabannya. Apakah Anda menunggu orang lain yang menjawabnya? atau Anda sendiri orang yang suka membantu orang lain? (bukan hanya mengenai menjawab pertanyaan, tapi secara umum berbuat baik pada orang yang tidak Anda kenal). Menjawab pertanyaan orang lain itu sekedar amal, tidak wajib.
Penutup
Sekalian saya ingin menyampaikan uneg-uneg mengenai berbagai kondisi group teknologi saat ini. Kebanyakan group ini noise nya sangat tinggi (banyak sampahnya) karena banyak anggota yang tidak peduli sopan-santun.
Untuk orang yang suka berjualan, mengirimkan pengumuman seminar dsb, tolong jangan memotong diskusi yang sedang berjalan. Jika ada seseorang sedang di tengah sesi tanya jawab, tiba-tiba ada yang nyelonong memforward message mengenai seminar, itu sangat mengganggu. Kalo saya admin groupnya, sudah saya ban orang yang seperti itu.
Orang-orang tersebut tidak peduli dengan isi group, yang kepikiran cuma begini: oh ternyata group itu aktif (ada message baru), saya forward deh info seminarnya tanpa peduli mengganggu diskusi (sering kali butuh 2-3 detik buat scroll message teks yang panjang sekali). Bahkan sering kali tidak melihat bahwa baru saja beberapa pesan sebelumnya info itu sudah diforward oleh orang lain.
Jangan ngejunk di group yang berfokus pada hal tertentu. Sudah ada group keluarga, group SD/SMP/SMU/jurusan/universitas, group kantor, group temen kompleks dsb yang bisa dipakai untuk ngejunk, kirim-kirim meme, politik, dsb. Kalau semua group hanya dipakai untuk meme politik, buat apa bikin group baru?
Mungkin sebagian akan mikir: ah ribet banget sih, santai aja lah ngejunk. Salah satu alasan banyak orang yang memiliki ilmu jarang mau sharing atau menjawab di group adalah: 90% waktunya dipakai untuk membaca sampah, jadi daripada waktunya dibuang percuma mereka memilih pergi. Ya silakan saja memiliki group penuh sampah, tapi jangan salahkan juga kalau tidak ada orang berkualitas yang mau join. Sebaliknya jangan sakit hati jika dikick dari group yang berkualitas karena sering tidak sopan atau ngejunk.
Meneruskan cerita sebelumnya tentang self hosting, kali ini saya ingin membahas lebih jauh lagi mengenai email. Sekarang ini email (dan nomor HP) menjadi “kunci” bagi banyak layanan. Kebanyakan layanan memerlukan email untuk login dan untuk fitur lupa password. Berbagai notifikasi transaksi keuangan juga masuk ke email. Jika kita kehilangan akses email, akibatnya cukup fatal.
Banyak layanan juga meminta verifikasi via email jika kita login di komputer baru atau IP yang baru. Jadi jika account email kita dihack atau diblokir, kita tidak bisa login. Email ini sangat penting, jika sampai kehilangan akses maka urusannya rumit, seperti jika kita kehilangan dompet. Sekarang setelah tahu betapa pentingnya email ini, kita perlu berusaha mengamankannya.
Contoh verifikasi dari Steam
Email gratisan
Sebagian besar orang menggunakan dua jenis email ini: email kantor dan email gratisan dari berbagai provider (Google/Yahoo/Outlook dsb). Sebenarnya kemungkinan account kita tiba-tiba ditutup oleh Google atau berbagai perusahaan ini cukup kecil, tapi tetap ada. Bisa saja kita sudah taat peraturan, tapi ada kesalahan pada sistem yang membuat account diblokir. Selama lebih dari 14 tahun memakai Google, baru sekali saya mengalami masalah.
Selain Google sebenarnya ada banyak layanan email gratis lain, misalnya protonmail yang terenkripsi, outlook.com dari Microsoft, bahkan Yahoo juga masih memberikan email gratis. Tapi semua email gratisan ini agak mengkhawatirkan karena sebagai pengguna gratis, kita ini “bukan siapa-siapa” dan bisa ditendang kapan saja.
