Apache Guacamole

Apache Guacamole adalah clientless remote desktop gateway. Atau mudahnya: jika kita menginstall ini di sebuah gateway (atau di server remote), kita bisa mengakses Windows (via RDP), Linux (via VNC), atau SSH ke manapun dengan menggunakan browser saja.

Saat ini saya masih memakai Mini PC Router yang dibeli sekitar 2 tahun lalu. Mini PC ini cukup powerful untuk menjalankan berbagai aplikasi (memorinya 4 GB, dengan SSD 120 GB) termasuk juga Apache Guacamole yang memakai Java. Meskipun dalam 99% kasus saya lebih suka memakai aplikasi SSH langsung, tapi Guacamole ini sangat berguna ketika butuh akses GUI.

Dengan chrome melakukan koneksi ke rumah, lalu menjalankan Firefox

Sebelum memakai Guacamole saya memakai Team Viewer, tapi dulu sempat ada kecurigaan bug di team viewer yang memungkinkan orang masuk ke komputer kita. Selain masalah bug itu, TeamViewer juga kadang error ketika melakukan remote connection ke Linux. Solusi berikutnya yang saya coba adalah SSH + Port forwarding plus remote desktop dan VNC viewer. Hal ini cukup merepotkan, jadi jarang saya lakukan.

Sekarang dengan browser saja saya bisa melakukan koneksi ke rumah via Guacamole ke server Windows dan juga Linux. Untuk Linux saya menggunakan beberapa VNCServer (di satu server) untuk tujuan tertentu. Misalnya ada satu VNCServer untuk pentesting (yang memakai OWASP ZAProxy dengan GUI).

Saya juga memasang guacamole di server dedicated di Eropa. Kadang download sesuatu lebih cepat dilakukan dari server di Eropa. Dalam 90% kasus biasanya download bisa dilakukan di command line, tapi ada website yang melakukan banyak proteksi sehingga sulit dilakukan.

Contoh proteksi downloadnya:

  • Hanya boleh ada 1 koneksi setiap waktu
  • Harus memakai Cookie dan Cookienya terikat pada IP tertentu (jadi ketika dicopy paste ke server, jadi tidak valid)
  • Harus memakai user agent tertentu (jadi jika memakai command line, user agent harus dicopy persis)
  • Download menggunakan Javascript dan file didekrip di level Javascript

Daripada menghabiskan waktu mengakali, yang saya lakukan adalah:

  • membuka guacamole
  • memilih koneksi VNC ke server di Eropa
  • menjalankan browser di dalam koneksi VNC
  • mendownload file via browser yang berjalan di cloud
  • mentransfer file dari server ke rumah

Sepertinya langkah tersebut merepotkan, tapi dalam kasus tertentu bisa menghemat waktu sangat banyak. Kadang download yang butuh 3 jam bisa dilakukan dalam 10 atau 15 menit.

Penjelasan DNS Flag Day

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:

https://gitlab.isc.org/isc-projects/bind9/commit/615ebc39e39abd06e97131339cb508a8651ac65c

Apakah domain saya akan baik-baik saja?

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.

Kisah sebuah bug kecil

Saya mau cerita tentang sebuah bug yang saya perbaiki dan dapat bounty 200 USD plus kerjaan ekstra yang menyusul dari ini. Meski secara nilai ini kecil dibandingkan banyak proyek lain, tapi ada banyak hal yang membuat gembira dari satu bug kecil ini sehingga ingin saya ceritakan.

Maaf, ini bukan cerita tentang serangga, tapi bug software

Cerita singkatnya: teman saya memakai software open source QZ, sebuah library untuk printing via web browser. Jadi jika client menginstall software ini di PC-nya maka web app yang memakai library QZ bisa mengakses langsung printer lokal. Langsung di sini artinya bisa mengirimkan kode mentah, sehingga printing bisa cepat dan mendukung berbagai fitur spesifik printer. Fitur semacam ini dibutuhkan untuk software Point Of Sales, aplikasi bank atau sejenisnya yang butuh langsung mencetak ke printer yang tidak standar (misalnya printer thermal, printer buku tabungan, dsb). Lanjutkan membaca “Kisah sebuah bug kecil”

SSH Tunneling dan Internet Gratis

Saat ini sepertinya semua developer sudah memakai SSH sehari-hari. Sebagian mungkin sudah mengenal beberapa fitur ekstra SSH, tapi kebanyakan tidak tahu fitur lengkapnya. Wajar saja sih, meski RFC untuk SSH ini singkat (terbagi dalam beberapa RFC), ada banyak fitur di luar RFC yang diimplementasikan oleh berbagai software SSH. Sampai-sampai ada beberapa buku yang khusus hanya membahas SSH saja.

Di tulisan ini, saya tidak akan membahas semua fitur SSH, hanya beberapa fitur yang menarik yang berhubungan dengan port forwarding, serta pembahasan bagaimana SSH ini bisa menjadi jalan untuk internet gratis atau tanpa restriksi.

Fitur paling dasar yang dikenal orang adalah login ke server lain, dan berikutnya mungkin melakukan scp atau sftp ke server lain untuk mentransfer file. Fitur menarik berikutnya adalah X11 forwarding yang untuk mengakses aplikasi GUI di server (unix) lain.
client-server

SSH mendukung multi channel dalam satu koneksi, dan ini bisa dimanfaatkan untuk TCP/IP forwarding (mengenai ini bisa dibaca di RFC 4254). Saya akan jelaskan beberapa kegunaan forwarding ini. Channel yang dibentuk oleh mekanisme forwarding ini disebut juga sebagai tunnel.

Lanjutkan membaca “SSH Tunneling dan Internet Gratis”

Jaringan di Rumah

Waktu sampai di Chiang Mai dulu, kami cuma diberi modem dengan 1 port ethernet, (kami memakai ISP 3BB). Risna memakai Macbook, saya memakai laptop Linux. Koneksi internet saya share via Wifi.

2864360241_9c32dc9f4f_b

Tapi lama-lama setting ini kurang bagus, kalau butuh koneksi WIFI berarti komputer saya harus menyala. Jadi saya beli WRT54GL, dioprek, ditambahi SD Card.

Lanjutkan membaca “Jaringan di Rumah”