Technology

Mengenal Two Factor Authentication (2FA)

Saat ini untuk mengakses sebuah situs biasanya kita menggunakan password. Tapi password bisa bocor dan kadang gampang ditebak. Jika seseorang punya password kita, maka orang tersebut bisa login dan mengambil alih account kita. Untuk meningkatkan keamanan, maka selain password kita perlu memberikan bukti lain bahwa sesungguhnya yang ingin melakukan autentikasi benar-benar diri kita.

Sistem yang menggunakan lebih dari satu bukti/faktor untuk autentikasi dinamai “Multi Factor Authentication” (MFA). Two Factor Authentication merupakan subset dari MFA dengan hanya dua faktor saja. Biasanya password dan sesuatu yang lain. Website besar seperti GMail, Facebook dan Twitter semuanya mendukung 2FA. Di tulisan ini saya akan membahas kelebihan dan kelemahan berbagai faktor dalam 2FA.

MITM

Serangan generik untuk hampir semua jenis transaksi adalah MITM (man in the middle attack). Seseorang yang bisa mencegat paket jaringan dan menyimpan memodifikasi paket tersebut akan bisa mendapatkan password seseorang. Contoh “pencegatan” adalah dengan menggunakan WIFI gratis yang disetup oleh penyerang, atau penyerang mengganti setting router (DNS).

Dalam kasus hanya password saja, jika attacker sudah berhasil menyadap password, maka attacker akan bisa login lagi walaupun user sudah logout. Dalam kasus multi factor authentication, serangan MITM ini juga bisa dilakukan tapi lebih terbatas.

Sebenarnya dengan penggunaan SSL, MITM ini semakin sulit dilakukan. Sebuah website sulit berpura-pura menjadi website lain yang memiliki sertifikat SSL. Tapi ada faktor manusia yang sering kurang jeli dalam mengunjungi website. Contohnya jika ingin mengunjungi klikbca.com menjadi kilkbca.com maka seseorang bisa dengan mudah mendapatkan sertifikat SSL untuk website tersebut.

Varian lain MITM adalah seseorang mendaftarkan domain yang memakai karakter bahasa lain yang sulit dibedakan dari karakter latin (IDN Homograph Attack). Ketika mengunjungi situs tersebut, semua permintaan akan diteruskan ke situs asli, tapi sambil disadap dan atau dimodifikasi.

Saat ini beberapa browser sudah menangani agar tidak terjadi penipuan nama domain yang terlihat sama tapi berbeda, tapi sayangnya Firefox masih belum menangani ini dengan baik

Contoh kombinasi huruf latin dan non latin pada nama domain. Huruf Latin “e” dan “a” diganti dengan huruf Cyrillic “е” dan “а”.

Yang kamu tahu

Ini merupakan faktor autentikasi yang paling sederhana, intinya selain ditanya password, kita akan ditanya hal lain secara random. Ketika registrasi kita diminta mengisi beberapa pertanyaan dan jawaban (misalnya: apa group musik favorit Anda? Anda lebih suka Marvel atau DC?). Perhatikan bahwa ini berbeda dengan pertanyaan “password recovery” ketika kehilangan password. Pertanyaan ini selalu ditanyakan ketika login.

Cara ini hanya sedikit lebih aman dari password saja. Jika seseorang memonitor jaringan hanya sekali saja, maka dia tidak bisa login jika kebetulan mendapatkan pertanyaan yang berbeda, tapi jika dimonitor beberapa kali maka semua jawaban bisa ditemukan. Seperti halnya password, jawaban untuk berbagai pertanyaan ini bisa dicari dan ditebak. Jika sudah mendapatkan jawabannya maka akan mudah login di mana saja.

Dirimu

Biometrik merupakan autentikasi berdasarkan “apa adanya kita”, bisa berupa sidik jari, wajah, retina, DNA, bau badan, atau apapun. Metode autentikasi ini sudah umum dipakai secara lokal (misalnya ponsel, di gedung). Di ponsel, sidik jari atau wajah hanya akan mengunlock data di ponsel dan data tersebut yang akan dikirim ke server (jadi bukan biometrik kita yang langsung dikirim ke server).

Kelemahan sistem ini adalah: biometrik bisa disalin. Sidik jari bisa mudah dicuri dari segala permukaan yang kita sentuh, retina bisa difoto, bahkan pengenalan wajah juga bisa diakali. Biometrik juga tidak bisa diganti, jika data bocor — misalnya seseorang merekam dengan sidik jari atau retina Anda dan diposting ke Internet — maka Anda tidak bisa mengubah mata Anda. Ada kekhawatiran juga bahwa seseorang bisa diculik demi menjadi kunci akses untuk sesuatu yang berharga.

Yang kamu punya

Cara ini yang paling umum digunakan karena praktis: menggunakan benda yang kita pegang (ponsel/sms/app/token). Ketika login kita diminta memasukkan kode tertentu yang hanya bisa dipakai sekali (OTP, One Time Password). Secara umum serangan MITM bisa dilakukan seperti password, bedanya adalah: attacker hanya bisa login sekali ini saja karena berikutnya OTP-nya akan berbeda.

Setelah attacker bisa login, koneksi dari pengguna yang sebenarnya bisa diset agar selalu error atau diputus.

Untuk meningkatkan keamanan, OTP biasanya akan diminta per transaksi. Inipun masih bisa MITM, tapi lebih sulit. Misalnya ketika user ingin transfer uang ke pihak A, attacker akan mengganti agar di browser user tampil transfer akan dilakukan ke pihak A, tapi data yang dikirim ke server adalah: transfer dilakukan ke pihak B. Beberapa bank mengatasi ini dengan mengirimkan SMS notifikasi jika kita mendaftarkan account tujuan yang baru.

Serangan berikutnya adalah: menyalin apa yang kamu punya jika bisa disalin. Atau dalam kasus tertentu: cukup bisa membaca apa yang kamu punya (contohnya dalam kasus SMS).

Ponsel/SMS

Sistem ini dipakai di banyak bank: setiap kali login atau melakukan transaksi, maka sistem akan mengirimkan SMS kode. Teorinya ini cukup aman karena (seharusnya) cuma pemilik ponsel yang bisa menerima kode ini. Tapi jika seseorang ditargetkan maka metode ini sudah tidak aman lagi. Baru-baru ini Reddit dihack karena menggunakan SMS sebagai faktor kedua.

Cara pertama untuk membaca SMS adalah: SIM Swapping. Intinya berpura-pura jadi orang lain untuk mendapatkan SIM card baru dari operator. Cara ini tidak bisa dipakai untuk hacking banyak orang sekaligus karena perlu proses untuk mendapatkan SIM card baru dan pengajuan massal akan sangat mencurigakan.

Cara lain adalah hacking ke jaringan SS7. Secara singkat: semua jaringan operator di dunia ini berhubungan, dan hubungan ini perlu telpon antar operator dan untuk roaming. Jika memiliki akses ke jaringan SS7, ada banyak vulnerability yang bisa digunakan untuk membaca SMS. Selain dengan bug, cara termudah adalah mengakses jaringan operator adalah melalui orang dalam (SMS tidak dienkrip). Cara ini tidak bisa dengan mudah digunakan secara massal karena akan cepat ketahuan siapa yang mengakses SMS banyak orang.

Cara ketiga adalah menginstall aplikasi di HP target. Jika aplikasi ini memiliki hak untuk mengakses SMS maka SMS OTP yang sampai akan bisa dibaca oleh attacker. Cara ini juga tidak mudah digunakan massal, harus menggunakan trik agar seseorang mau menginstall aplikasi tertentu (atau menggunakan bug spesifik untuk ponsel tertentu).

Cara terakhir yang sebenarnya sangat sederhana tapi sering berhasil adalah social engineering (intinya: menipu, tapi orang yang sering melakukan social engineering kurang suka kalau saya pakai istilah menipu). Caranya begini: penyerang melakukan transaksi, lalu butuh OTP, lalu dia menghubungi korban dengan mengatakan “mas, maaf saya tadi mau masukin nomor telepon untuk aplikasi gojek, eh salah masukin nomor mas, nanti kalo ada SMS masuk dari gojek bisa minta tolong bacain kodenya mas?”

Software Token

Software seperti Google Authenticator tergolong pada Software Token. Setiap kali kita ingin login ke website, kita perlu memasukkan angka yang muncul pada token. Ada banyak algoritma yang bisa dipakai namun saat ini ada TOTP standar yang dipakai di banyak layanan (Google, FB, Twitter, dsb). Standar TOTP ini sangat sederhana (saya pernah mengimplementasikan di jam tangan saya sejak 2011). Intinya adalah: ada satu string yang menjadi kunci untuk algoritma yang inputnya adalah waktu saat ini.

TOTP ini relatif aman untuk kebanyakan kasus. Serangan yang mungkin adalah jika seseorang menyalin key dari device kita. TOTP ini juga bisa diserang dengan teknik MITM.

Variasi lain token semacam ini adalah berdasarkan challenge dari website, website meminta kita memasukkan nomor tertentu ke aplikasi dan kita diminta memberikan angka ke website. Secara konsep tidak ada perbedaan dengan waktu (waktu diganti dengan bilangan random yang dihasilkan website).

Hardware Token

Ini seperti token software, tapi memiliki kelebihan karena tidak mudah menyalin nilai key-nya. Untuk token software, kita diminta memasukkan kode tertentu dalam proses setup, pada token hardware kode ini dimasukkan oleh pihak terkait (bank atau perusahaan). Di dalam device ini ada RTC (real time clock) atau istilah awamnya: ada jam-nya, supaya waktunya sinkron dengan server.

Jika ingin menyalin keynya maka token hardware perlu dibongkar sampai level chipnya (jadi lebih aman dibandingkan software). Sama dengan software token, hardware token juga tidak kebal MITM.

Chip berada dalam bulatan hitam resin epoksi menggunakan teknik Chip-on-board (COB)

Kelemahan token hardware adalah: repot karena tiap layanan perlu hardware yang berbeda. Untuk masalah ini, sebenarnya ada juga varian token ini yang memakai smart card, jadi sebelum memakai tokennya kita masukkan dulu kartu kita. Pemrosesan dilakukan di smart card. Walaupun lebih ringkas, cara ini tetap repot karena butuh banyak kartu untuk tiap website.

U2F (Universal 2nd Factor)

Ini juga merupakan hardware token, tapi terhubung ke komputer atau ponsel. Koneksi yang bisa dipakai adala: USB, BLE (bluetooth low energy) dan NFC. Kata kuncinya di sini adalah terhubung dengan komputer/ponsel sehingga langkah verifikasi bisa dilakukan otomatis. Ini berbeda dengan token lain di mana harus ada manusia yang memasukkan sesuatu ke komputer.

Dari sisi user, penggunaan tokennya begini: di sebuah website kita perlu mendaftarkan token kita, caranya dengan mencolokkan device ke PC (atau mentap ke ponsel jika memakai NFC) dan menekan tombol di devicenya. Ketika akan login, kita juga diminta melakukan hal yang sama (colok lalu tekan tombol di device).

Di balik layar ada proses challenge response memakai ECC (Elliptic Curve Cryptography). Spesifikasi U2F ini terbuka, bisa didownload di website FIDO Alliance. Saya sendiri sudah pernah mengimplementasikan ini bertahun-tahun yang lalu. Implementasinya sudah dipakai di hardware yang sudah diproduksi.

MITM sangat sulit dilakukan karena browser akan memeriksa certificate SSL dari server, dan browser (bukan user) akan memastikan hal tersebut benar, jadi tidak mungkin website kilkbca.com meminta autentikasi untuk website asli klikbca.com.

Saat ini U2F ini cukup aman, dan bahkan Google baru-baru ini akan mulai menjual security key U2F. Seperti semua benda lain, kelemahan U2F ini adalah jika hardware dicuri. Kemungkinan kelemahan lain adalah JIKA ada kelemahan pada browser sehingga bisa dipaksa untuk membypass autentikasi.

Penutup

Demikian perkenalan singkat two factor authentication. Two (atau multi) factor authentication ini sebaiknya ditambahkan pada website untuk menambah keamanan (tidak sulit menambahkan ini). Secara umum 2FA juga bisa digunakan untuk hal lain, misalnya untuk mengamankan akses SSH ke server kita.

Troubleshooting di Linux

Ada banyak masalah di dunia IT setiap hari meskipun software dan hardware sudah terpasang dan tidak diubah sama sekali. Beberapa contohnya: sesuatu menjadi semakin lambat (misalnya karena jumlah data menumpuk terlalu banyak), sesuatu tidak bekerja sama sekali (disk penuh, hardware rusak), mendapat serangan DDOS, ISP tiba-tiba memblok suatu website, dsb.

Jika ada sesuatu yang baru, masalahnya bisa lebih banyak lagi. Sesuatu yang baru ini bisa dari hal rutin misalnya upgrade software (contohnya baru-baru ini: ada masalah SSL di Chrome terbaru jika memakai SSL certificate tertentu) ataupun dari penambahan hardware maupun software karena ada kebutuhan baru.

Di posting ini saya ingin membahas cara troubleshooting generik berbagai masalah yang berhubungan dengan Linux. Pendekatan saya adalah pendekatan programmer: semua masalah admin sebenarnya adalah masalah debugging software. Pada dasarnya administrasi sistem (selain bagian memasang hardware) hanyalah menjalankan program dengan parameter/setting tertentu. Prinsip “debugging” ini bisa diaplikasikan ke sistem operasi apapun tapi saya hanya akan membahas tools khusus Linux di artikel ini.

Bagi sebagian orang ini merupakan hal yang jelas/obvious (“tentu saja mencari masalah itu sama seperti debugging program”). Sayangnya saya masih sering orang yang bingung dalam troubleshooting, dan akhirnya hanya coba-coba. Dan kadang solusinya meskipun “berhasil” tapi ternyata membuka masalah security. Contohnya ketika ingin mengkonfigurasi agar DBMS (misalnya postgres atau mysql) bisa diakses dari jaringan lokal, tapi ternyata malah bisa diakses dari seluruh internet. Dalam kasus ini karena dari jaringan lokal berhasil diakses dan sudah dianggap OK.

Semua program sifatnya sama: membaca input, memproses sesuai dengan algoritma tertentu, dan membuat output. Bahkan masalah jaringan pun sama: inputnya adalah paket data di jaringan dan konfigurasi jaringan (IP, routing, rule firewall, dsb), dan sistem operasi akan menjalankan beberapa algoritma (filtering, routing, dsb), lalu outputnya adalah paket yang diberikan ke program atau diteruskan ke host lain.

Tiga jenis masalah utama yang saya temui adalah sesuatu tidak berjalan sama sekali, sesuatu lambat (masalah kinerja), dan sesuatu tidak bekerja sesuai yang diharapkan. Contoh kasus terakhir misalnya: seharusnya direktori ini yang muncul di web, tapi kok direktori lain yang muncul atau muncul pesan warning/error walaupun program berjalan.

Prekondisi

Sebuah program akan berjalan benar jika prekondisi dipenuhi. Contoh: program konversi citra bisa berjalan jika ada input yang valid, ada disk space yang cukup untuk output. Beberapa program berasumsi bahwa ini pasti benar, sehingga jika disk space habis, kasus tersebut tidak ditangani, dan hanya muncul error generik. Jadi langkah pertama adalah: cek prekondisi dasar sebuah sistem.

Sebelum masuk ke debugging spesifik Linux, hal pertama adalah mengecek hal-hal yang jelas dulu. Apakah koneksi internet jalan? tidak ada masalah di ISP, cloud provider, dsb. Apakah hardware baik-baik saja? misalnya ternyata komputer mati karena kabel dimakan tikus. Jika masalah non-software yang bisa dicek eksternal tidak ada masalah, kita bisa masuk ke bagian berikutnya.

Prekondisi berikutnya adalah: disk tidak error. Hal ini bisa dicek dengan dmesg, apakah ada pesan error dari kernel. Ini penting karena jika ada hardware bermasalah maka akan muncul error di sini. Jika ada error, sebuah filesystem akan di-remount menjadi readonly, artinya log file tidak bisa diandalkan (tidak valid).

Lalu cek disk space sistem. Jika disk space penuh, maka log mungkin akan gagal ditulis jadi kita tidak mendapatkan error message yang benar. Disk space bisa dicek dengan df (disk free). Jika ternyata memang penuh, kita bisa memakai program du (disk usage) untuk mencari tahu direktori/file mana yang memakan space banyak. Masalah disk ini juga kadang bisa dilihat dari “wa” (berapa banyak I/O yang menunggu) di program “top“. Secara umum, pelajarilah berbagai nilai yang muncul di program top, karena ini sangat berguna.

Membaca Pesan Error

Jika hardware dan disk space sudah aman, maka prekondisi dasar sudah terpenuhi. Berikutnya ketika melihat sesuatu yang error adalah: membaca pesan error yang memang sudah diberikan oleh program. Kadang program perlu dikonfigurasi agar mengoutputkan log dan kadang level loggingnya perlu ditingkatkan agar lebih jelas errornya.

Log system biasanya bisa dibaca di /var/log. Tapi ini belum tentu benar, log system bisa dikirim ke sistem lain. Kita baca membaca konfigurasi program di mana log disimpan. Jika program memakai syslog, kita perlu membaca konfigurasi syslog.

Jika memang sudah jelas dari error messagenya (misalnya: “file abc not found”) maka tanganilah error itu (buat file abc-nya, atau mungkin salah path file-nya). Sayangnya kadang error message tertentu seperti “resource temporarily unavailable”, penyebabnya bisa banyak. Salah satu cara mencari solusi tentunya adalah dengan mencari pesan error di internet plus nama program yang berhubungan, misalnya “docker resource temporarily unavailable” (jika konteksnya ketika memakai docker). Jika ketemu orang dengan masalah yang sama dan gejala yang sama, maka mungkin itu solusinya.

Mencari masalah di internet juga sering kali merupakan cara terbaik, karena kadang solusi suatu masalah sangat panjang. Tapi jika kita tidak mengerti akar suatu permasalahan, kadang solusinya juga bisa melenceng jauh.

Membaca status program

Kita bisa mengecek apakah program sudah dijalankan dengan parameter yang benar dan dengan environment yang benar menggunakan filesystem /proc. Ini terutama dibutuhkan jika program dijalankan oleh skrip atau program lain. Dengan mengetahui PID (process id , proses adalah instance program yang sedang berjalan) kita bisa membaca status di /proc/PID.

Beberapa yang penting misalnya “cwd” adalah link ke direktori program saat ini. File “environ” berisi environment variable ketika aplikasi dijalankan. File “cmdline” berisi parameter ketika program dijalankan. Masih banyak lagi file-file lain yang berguna untuk mengecek status program saat ini.

Membaca Dokumentasi dan Changelog

Masalah lain yang mungkin ditemui ketika upgrade software adalah: suatu fitur diubah atau hilang. Dalam kasus ini yang perlu dibaca bukan hanya file log tapi juga dokumentasi aplikasi tersebut.

Beberapa aplikasi memiliki tool atau opsi untuk mengecek apakah file konfigurasi sudah benar atau belum (terutama untuk mengetahui apakah di versi terbaru opsi masih valid), ini bisa digunakan untuk mencari tahu sumber error. Contohnya apache memiliki “apachectl configtest”.

Debugging Masalah Jaringan

Untuk masalah jaringan biasanya masalahnya adalah tentang konektivitas (sesuatu tidak bisa diakses atau paket tidak diteruskan). Saya memakai gabungan banyak tool untuk debugging. Tool dasar pertama adalah “ping” (mengecek konektivitas ke host lain) dan traceroute untuk mengetahui route yang diambil paket. Program “ip” juga memiliki opsi untuk mengecek route di host saat ini: “ip route get to TUJUAN” (misalnya “ip route get to TUJUAN").

Sering kali program tidak bisa diakses dari host lain karena memang hanya menerima koneksi dari localhost. Ini bisa dicek dengan program netstat (terutama dengan opsi -l untuk melihat program yang statusnya “listening”). Setelah diperbaiki konfigurasinya kadang program menolak karena filter di dalam program tersebut. Contohnya: postgreSQL memiliki opsi listen_interface di postgresql.conf, tapi jika sudah diset, postgresSQL akan mengecek ke pg_hba.conf untuk mengecek apakah IP spesifik tertentu diijinkan untuk melakukan koneksi atau tidak. Dalam semua kasus kita perlu memahami hal-hal seperti ini.

Jika host bisa dihubungi dengan ping tapi ada service yang tidak bisa diakses dari host lain, maka saya akan memakai netcat untuk mengetes. Kadang saya pakai juga “nmap” untuk mengecek semua port untuk mengecek apakah ISP memblock port tertentu.

Jika masalahnya ada di firewall yang kita kontrol (bukan firewallnya ISP) maka kita perlu mendebug masalahnya dengan logging. Baik iptables maupun nftables mendukung logging untuk mencari tahu kenapa sebuah paket di-drop.

Senjata andalan terakhir adalah tcpdump dan wireshark. Kedua program ini dapat menangkap semua paket yang lewat. Jika yang bermasalah adalah komputer lokal, saya akan langsung memakai wireshark dengan GUI yang enak dilihat. Jika masalahnya di komputer remote, saya akan memakai tcpdump. Kadang output tekstual tcdump sudah cukup, tapi jika masih kurang, saya akan memakai opsi -w untuk menuliskan hasil capture ke file pcap yang bisa dicopy ke desktop lalu dilihat isinya secara visual.

Debugging Program

Kebanyakan program memiliki beberapa opsi dasar untuk debugging. Biasanya opsi yang penting adalah: menampilkan log, atau menaikkan level logging dan membuat agar program tidak berjalan di latar belakang (foreground mode atau no daemon mode). Dua hal ini biasanya sudah cukup untuk mencari tahu kebanyakan error.

Jika semua pendekatan sudah mentok maka pendekatan programming akan saya ambil. Pertama adalah dengan strace dan ltrace. Kedua program low level ini berguna untuk tracing, strace untuk syscall dan ltrace untuk library call. Kadang program-program ini bisa dipakai tanpa pengetahuan programming, tapi biasanya butuh pengetahuan programming terutama jika masalahnya kompleks.

Tracing di sini berarti semua pemanggilan library (untuk ltrace) dan system call (untuk strace) akan ditampilkan. Contoh paling sederhana adalah untuk debugging: kenapa aplikasi tidak membaca file sesuatu yang tercantum di konfigurasi. Dari hasil tracing bisa dilihat apakah filenya namapakcagegagal dibuka (misalnya masalah permission) atau ternyata tidak ditemukan (mungkin karena salah nama file, atau programnya menambahkan prefix/suffix tertentu sehingga tidak ketemu).

Contoh memakai strace untuk mengecek file apa yang dicoba dibuka oleh sebuah aplikasi dalah dengan membatasi output hanya syscall open dan access saja.

strace -e open,access namaprogram

Debugging berikutnya sudah sangat butuh skill programming, yaitu memakai debugger gdb. Dengan menginstall debug symbol, umumnya berbagai masalah crash bisa dicari tahu sebabnya. Andaikan debug symbol tidak cukup, maka langkah berikutnya adalah: compile ulang aplikasinya, lalu debug di level source code.

Compile ulang ini tidak sesulit jaman dulu. Di Debian kita bisa dengan mudah menggunakan “apt-get source namapackage” untuk mendownload source code package tertentu, dan “apt-get build-dep namapackage” untuk mendownload seluruh library/tool yang diperlukan untuk membuat package tersebut. Selanjutnya kita bisa mengcompile dan mendebug program dengan mudah.

Masalah performance

Masalah yang cukup sulit dicari adalah masalah performance karena biasanya tidak ada pesan di log. Masalah performance juga biasanya sangat spesifik pada aplikasi atau software server tertentu. Tapi Sebelum mengecek spesifik software tersebut cek dulu penggunaan CPU dan memory dengan top.

Apakah ada proses yang memakan banyak CPU atau memori? jika ada, harus diperhatikan karena itu mungkin sumber masalah utama. Jadi ketika database tiba-tiba lambat, belum tentu server databasenya bermasalah, mungkin saja ada proses lain yang memakan terlalu banyak CPU atau memori dan efeknya terasa ke query database.

Sebuah program bisa melakukan banyak langkah, dan kadang langkah tertentu menghambat langkah berikutnya, dan secara total aksi tertentu menjadi sangat lambat. Contoh sederhana: sebuah program bisa melakukan reverse DNS lookup untuk memetakan IP menjadi nama, dan menampilkan informasi tersebut ke log file. Jika ada masalah dengan DNS, maka proses yang tujuannya hanya informatif (melog informasi) ini butuh waktu lama karena masih menunggu respons dari server DNS.

Dari sudut pandang programmer, ada banyak tool yang bisa dipakai untuk debugging masalah performance. Tool ini meliputi software profiler spesifik untuk bahasa/teknologi tertentu (misalnya ada profiler khusus untuk Java, Python dsb), dan juga profiler system secara umum (misalnya Systemtap dan perf).

Penutup

Semua langkah ini biasanya cukup untuk menemukan masalah dan memperbaiki masalah tertentu. Namun demikian tidak semua masalah bisa diselesaikan dengan mudah.

Beberapa masalah tiba-tiba hilang karena restart program (jika masalahnya ada di programnya), atau restart komputer (jika masalahnya ada di kernelnya). Dalam kasus ini akar permasalahan harus dicari, karena pasti akan muncul lagi.

Selain itu tidak semua masalah bisa diatasi dengan singkat, contohnya: ketika upgrade program tertentu, program tersebut butuh upgrade library, dan setelah upgrade library, program lain yang closed source ternyata berhenti berjalan. Akhirnya program harus dijalankan di chroot atau Docker dengan library lama dan ini butuh waktu.

Semoga langkah-langkah yang diberikan di tulisan ini berguna. Intinya sih jangan semuanya hanya proses coba-coba, tapi pahamilah akar masalahnya.

Harddisk yang tidak pernah cukup

Ini sekedar cerita dan catatan kenapa desktop saya sekarang punya 3 SSD dan 3 HDD, dan kenapa saya punya komputer lain yang jadi server dengan 1 SSD dan 3 HDD. Ceritanya ini juga sekaligus jadi catatan untuk diri sendiri.

Singkatnya kalau Anda rajin bereksperimen seperti saya, ruang harddisk sepertinya akan selalu tidak cukup. Misalnya ingin mengcompile ROM Android (bukan aplikasi Android, tapi source code kernel, OS dan berbagai aplikasi Android yang membentuk ROM Android), satu versi saja butuh disk space 100 GB untuk source codenya dan 150 GB lagi untuk membuild-nya. Sedangkan untuk development aplikasi Android juga butuh space cukup banyak: folder .android saya (yang berisi SDK dan VM, tidak semua versi saya install) sudah 20GB.

Mengcompile Firefox? butuh 30 GB, Chromium butuh 100 GB. Belum lagi ketika eksperimen dengan Raspberry Pi atau yang lain: tiap backup 1 SD Card biasanya seukuran SD cardnya (umumnya saya memakai 8-32 GB, tergantung devicenya).

Bisa dibayangkan juga berapa lama perlu download source code semuanya. Setelah selesai bereksperimen tentu semuanya bisa dihapus, tapi berapa jam lagi harus download jika ingin mulai lagi? kadang masih lebih baik menyimpan versi lama dan ketika ingin bereksperimen dengan versi baru tinggal “git pull” (atau sejenisnya).

Selama lebih dari 5 tahun saya pernah eksklusif memakai Linux di Desktop, bahkan akan saya bela-belain memakai Wine untuk menjalankan aplikasi tertentu yang hanya jalan di Windows. Tapi sejak punya anak, saya ingin lebih banyak bekerja dibandingkan berantem dengan tool. Saat itu Windows sudah cukup bagus. Kebanyakan tools support Windows dan saya tidak perlu mengakali banyak hal, saya juga menyiapkan server Linux terpisah jika ada kebutuhan oprek di Linux. Sudah berkali-kali saya mencoba Linux di VM dan sering ada masalah kecil terutama jika sudah berusaha mengakses hardware, jadi komputer server terpisah lebih masuk akal.

Enam tahun yang lalu saya kembali memakai Windows di Desktop dengan SSD yang ukurannya cuma 60 GB. Tentunya ini nggak cukup untuk berbagai aplikasi dan virtual machine, jadi konfigurasi desktop saat itu:

1 SSD untuk Windows (60 GB)
1 HDD untuk data, program besar, dsb (1 TB)

Waktu itu server Linux dipakai untuk development Linux dan juga sekaligus server media yang berisi musik dan film (dulu Netflix belum masuk Thailand jadi kombinasi antara membajak dan rip dari DVD). Saya mulai dengan 1 HDD saja. Jadi konfigurasi server:

1 HDD (OS + Data, 1 TB)

Suatu saat harddisk yang berisi data di desktop saya rusak, seingat saya itu baru kali pertama saya mengalami harddisk yang tiba-tiba error tidak terbaca tanpa ada gejala apa-apa. Untungnya sebagian data sudah dibackup, tapi tetap butuh waktu restore dan ribet bekerja dengan 1 SSD 60 GB saja. Saya tidak ingin kejadian seperti ini lagi: saya beli 2 HDD yang saya set dengan konfigurasi RAID-1, sekarang konfigurasi desktop:

1 SSD untuk Windows (60 GB)
2 HDD (RAID) untuk data, program, dsb (1 TB)

Saya memakai RAID software Windows, karena jika memakai RAID dari hardware (motherboard/BIOS) jika ada masalah maka recoverynya sulit dan sulit berpindah ke merk lain. Tapi lama-lama harddisk RAID ini penuh karena saya banyak bereksperimen dengan virtual machine (VM). Satu VM bisa belasan hingga puluhan GB. Belum lagi installer masing-masing OS untuk berbagai sistem operasi.

Nah masalah dengan RAID ini: jika ingin mengupgrade ukuran disk ya harus beli sekaligus 2 disk. Padahal kedua disk ini masih baik-baik saja. Jadi akhirnya saya putuskan: 1 HDD lagi untuk hal-hal yang kurang penting seperti installer, VM, source code open source. Kalaupun rusak tidak apa-apa, datanya bisa dibuat ulang atau didownload ulang. Jadi sekarang konfigurasi desktop:

1 SSD untuk Windows (60 GB)
2 HDD (RAID) untuk foto, dokumen penting (1 TB)
1 HDD (non- RAID) untuk berbagai file besar yang kurang penting (2 TB)

Saya akhirnya mengupgrade SSD desktop dari 60 GB, jadi 180 GB, lalu kemudian jadi 480 GB karena makin banyak hal-hal yang perlu diakses dengan cepat. SSD lama saya pindahkan ke server dengan 2 tujuan: (1) Mudah upgrade kapasitas data karena Sistem operasi ada di SSD terpisah (tidak perlu reinstall/copy), dan (2) server akan lebih booting cepat dengan SSD. Jadi konfigurasi server:

1 SSD (Linux, 60 GB)
1 HDD (Film, musik, 1 TB)

Meskipun saya merasa desktop saya cukup powerful, tapi saya tidak bisa melakukan semua hal di desktop, contohnya: Development atau pentest aplikasi iOS. Saya punya Macbook dan hasil pekerjaannya perlu dibackup. Risna dan saya juga kadang bekerja memakai laptop, ini pun perlu dibackup. Saya memakai git untuk menyimpan source code, dan saya juga butuh backup database, dan berbagai file penting lain. Semua ini saya backup ke server.

Sebagai catatan: saya sudah memakai Dropbox, OneDrive dan Google Drive untuk backup data penting di cloud. Tapi saya juga tidak 100% percaya dengan cloud. Saya juga mengikuti berbagai berita cloud storage dengan seksama. Misalnya banyak yang tidak tahu kalo OneDrive dulunya tidak punya file history (dan kelabakan ketika kena malware) dan baru pada July 2017 mereka mengimplementasikan fitur tersebut. Bagi saya: lebih baik punya backup ekstra daripada ketika butuh file internet sedang mati atau lambat.

Akhirnya saya mulai khawatir karena mulai banyak data penting di server, jadi saya tambahkan 2 HDD (RAID) jadi sekarang konfigurasi server:

1 SSD (Linux, 60 GB)
1 HDD (Film, Musik, 1 TB)
2 HDD (RAID, backup data penting, 2 TB)

Selama beberapa tahun saya tidak butuh sama sekali akses ke desktop Linux. Biasanya hanya butuh akses console (di server) atau sesekali cukup menggunakan VM. Tapi karena ada proyek yang butuh akses desktop Linux untuk hardware tertentu dan tidak cukup memakai VM, maka saya tambahkan lagi 1 SSD lama dari laptop yang hanya 60 GB ke desktop dan saya isi Linux. Dengan ini saya bisa dual boot ke Linux.

1 SSD untuk OS Windows (480)
2 HDD (RAID) untuk foto, dokumen penting (2 TB)
1 HDD (non- RAID) untuk berbagai file besar yang kurang penting (3 TB)
1 SSD untuk OS Linux (60 GB)

Di sini ternyata harddisk Non-RAID (HDD oprekan) menjadi penting untuk bertukar data dengan Windows karena sangat sulit mengakses data di RAID Windows dari Linux dan rawan error.

Sebagai catatan, meskipun lebih dari 95% pekerjaan bisa dilakukan di dalam virtual machine, tapi beberapa hal tetap butuh OS dengan akses hardware langsung. Beberapa hardware dengan mudah saya hubungkan ke server dan diprogram secara remote, tapi tidak semua pemrograman sifatnya non visual.

Contoh: akses GPU langsung di dalam VM cuma bisa dengan konfigurasi hardware/software tertentu dan kadang tetap error. Saya juga cuma punya GPU bagus di desktop, jadi kalau butuh akses GPU di Linux ya harus dual boot.

Contoh lain: Emulator Android x86 sangat lambat di Windows jika memakai prosesor AMD karena sampai bulan lalu tidak mendukung virtualization, dan baru saja ditambahkan fitur supaya virtualization bisa dipakai di Windows dengan prosesor AMD. Untuk prosesor Intel dari dulu ada software Intel^® Hardware Accelerated Execution Manager/HAXM di Windows/macOS. Untuk prosessor AMD di Linux bisa memakai KVM (Kernel Based Virtual Machine) tapi dulu tidak ada solusinya di Windows.

Belum lama ini ketika saya mengerjakan proyek Raspberry Pi, ternyata tetap harus di depan Pi-nya karena akses kamera dengan tunelling ke HDMI tidak bisa diemulasikan dengan Qemu. Berbahagialah Anda kalau pekerjaan programming Anda masih bisa ditangani dengan emulator/virtual machine.

Setelah proyek yang berhubungan dengan Linux selesai, saya sudah melupakan Linuxnya dan saya biarkan SSD-nya (siapa tahu butuh lagi). Sekarang saya kembali berurusan dengan proyek yang butuh akses Linux. Kali ini 60 GB untuk Linux tidak cukup, dan tadinya terpikir untuk membeli lagi SSD 240 GB atau yang lebih besar, tapi kemudian ingat masih punya SSD lama 60 GB.

Karena masih malas untuk membeli SSD baru (plus harus mengcopy OS), saya colok saja SSD ini. Untungnya casing saya punya slot SATA sehingga jika butuh disk sementara bisa dicolok.

1 SSD untuk Windows (480 GB)
2 HDD (RAID) untuk foto, dokumen penting (2 TB)
1 HDD (non- RAID) untuk berbagai file besar yang kurang penting (3 TB)
1 SSD untuk OS Linux (60 GB)
1 SSD untuk data di Linux (60 GB)

Bagian terakhir ini sifatnya sementara, dan nanti rencananya untuk kedua SSD untuk Linux ini akan saya ganti saja dengan SSD lebih besar.

Sejauh ini saya tidak menyesali konfigurasi saat ini. Setelah memakai RAID ternyata sudah kejadian 2 kali salah satu harddisknya rusak dan bisa segera direcover. Meskipun sepertinya merepotkan punya banyak disk, tapi lebih repot lagi kalau data kita hilang.

Memakai SSD terpisah untuk Windows dan Linux juga terkesan boros (kenapa nggak satu SSD aja dipartisi?). Tapi menurut saya ini lebih reliable, jika SSDnya error saya masih bisa mengakses data dari OS lain, jika ingin mengupgrade salah satunya juga lebih gampang.

Sebagai catatan, tulisan ini dibuat karena saya baru beli HDD 4 TB sebagai pengganti disk 3TB yang sudah mulai penuh. Semoga ini bisa bertahan cukup lama.

Berhentilah Jadi Script Kiddie

Saya sering mau ketawa tapi juga merasa sedih, kasihan dan juga marah kalau liat ada posting tentang ajakan DDOS sebuah situs. Ketawa karena mereka berusaha men-DDOS situs yang dilindungi Cloudflare (atau cloud firewall lain) dan ketawa karena mereka memakai tools-tools tua yang parah. Kalau memilih target jangan malu-maluin lah, ibaratnya mau menyerang klub malam maksiat tapi yang diserang malah papan iklan klub malam tersebut di pinggir jalan.

Copy paste ajakan semacam ini sangat banyak yang beredar di Facebook/WA/Telegram

Di posting ajakan mereka biasanya juga diberikan daftar tool yang bisa dipakai. Saya lihat ada batch file yang sekedar melakukan ping, dan ada salah satu tool DDOS Android bahkan mengirimkan IMEI dan Device ID ke server yang diserang, jadi memudahkan untuk dilacak balik. Mereka ini benar-benar script kiddies yang memakai skrip yang bahkan tidak mereka mengerti. Sebagai catatan “kiddie” di sini bukan menunjukkan umur, tapi skill yang seperti anak-anak.

Sebagai catatan ada banyak teknik DDOS yang menarik dan ada yang spesifik satu OS/server/aplikasi tertentu. Di tulisan ini DDOS yang saya maksud di sini hanya DDOS generik dengan ping (ICMP), UDP, dan request flooding. Lanjutkan membaca “Berhentilah Jadi Script Kiddie”

HP Murah sudah cukup

Sejak kenal smartphone Nokia 3650, kami tidak lagi bisa memakai feature phone dan selalu memakai smartphone. Setelah mencoba berbagai ponsel yang murah maupun mahal, kesimpulan saat ini: HP murah (asal bukan yang murah banget) sudah cukup .

Di posting ini sekedar ingin cerita HP yang pernah kami beli, dari mulai iPhone dan Samsung baru yang harganya 10 jutaan, sampai HP saat ini yang harganya hanya 3 jutaan. Berikut dengan alasan kenapa selalu berganti dan cukup di HP biasa saja.

iPhone 5s dan Samsung Note 4. Dulunya harga barunya masing-masing sekitar 10 juta rupiah.

HP Mahal tidak selalu bagus

HP termahal pertama yang dibeli adalah iPhone 5s 32 GB. iPhone ini diluncurkan September 2013 di Amerika dan kami beli Desember 2013 (belum lama setelah masuk Thailand), jadi harganya masih sangat mahal (sekitar 10 juta rupiah). Risna mendapati bahwa iPhone ini terlalu kecil, mengetik juga tidak terlalu enak (karena sebelumnya memakai Blackberry keyboard fisik lalu Blackberry Z10 touch screen yang keyboard virtualnya memang lebih baik). Lanjutkan membaca “HP Murah sudah cukup”

AlphaSmart Dana

AlphaSmart Dana adalah device Palm OS lama dengan form factor keyboard yang sudah tidak diproduksi lagi. Device ini dulu cukup populer di banyak sekolah di Amerika, terutama digunakan untuk anak-anak yang kesulitan menulis dengan pulpen/pensil. Device ini saat ini masih populer di kalangan penulis karena beberapa hal: keyboardnya enak dipakai untuk mengetik, minim gangguan (karena tidak bisa mengakses internet), relatif ringan (sekitar 1 kg), memakai 3 Batere AA biasa (atau yang rechargable) dan tahan beberapa puluh jam sebelum perlu mengganti batere lagi. Ada dua versi Dana, Wireless dan non wireless, yang akan dibahas di sini adalah versi wireless yang kami punya.

Stiker biru kecil di tengah Dana itu ditempelkan supaya gampang membedakan dari Dana yang lain.

Untuk mentransfer data ke komputer, ada beberapa opsi. Opsi pertama adalah menggunakan mode keyboard, dengan ini seolah-olah Alphasmart akan “mengetik ulang” isi file ke editor apapun yang terbuka di layar komputer. Dengan cara ini AlphaSmart Dana bisa terkoneksi ke device apa saja yang menerima input dari USB keyboard (termasuk juga tablet atau ponsel, asalkan bisa memberikan cukup daya). Kabel yang digunakan adalah kabel USB printer standar. Opsi kedua adalah dengan menggunakan jaringan WIFI (sayangnya yang disupport hanya WEP). Opsi terakhir adalah dengan menggunakan SD Card Lanjutkan membaca “AlphaSmart Dana”

Lulusan Kuliah IT seharusnya bisa apa?

Tahun lalu saya membaca mengenai skill yang seharusnya dimiliki lulusan SMK. Entah kenapa tulisan ini beredar lagi di timeline saya tahun ini. Ketika saya baca lagi mengenai skill yang diharapkan, kebanyakan skill ini bahkan tidak dimiliki oleh lulusan Sarjana Informatika/Ilmu Komputer/Teknologi Informasi (berikutnya akan saya singkat jadi: lulusan/sarjana IT).

Sudah menjadi fakta bahwa banyak lulusan IT yang tidak bisa memprogram (silakan baca artikel: Why can’t programmers.. program?). Separah ini:

Like me, the author is having trouble with the fact that 199 out of 200 applicants for every programming job can’t write code at all. I repeat: they can’t write any code whatsoever.

Sebelum diskusi masuk ke masalah pekerjaan, kesuksesan, jiwa entrepreneur, dsb saya ingin menekankan dulu: lulusan apapun dengan skill bagaimanapun bisa bekerja di berbagai bidang yang tidak sesuai jurusan yang diambilnya. Tapi jika sebuah negara ingin bisa maju di bidang tertentu, ya tentunya yang diharapkan adalah lulusan dari bidang tersebut memiliki skill yang baik dan berkontribusi di bidangnya. Lanjutkan membaca “Lulusan Kuliah IT seharusnya bisa apa?”