Lamunan-nya IMW

Hasil nonton CeBIT 2007 sudah terbit di KONTAN pada hari Jumat dengan judul “Indonesia menghilang dari CeBIT”. Silahkan cari majalah KONTAN untuk mengetahui isinya. Karena rutin mengunjungi CeBIT dan membuat artikel saya terakreditasi sebagai jurnalis di CeBIT.

Kali ini saya datang ke CeBIT 2 kali, pertama karena undangan perusahaan komputer forensik, dan yang ke-2 karena Dhava juga ngebet. Jadi kami bertiga ke CeBIT, saya, Dhava dan Adhit. Anthi, sang istri tercinta bisa istsirahat di rumah. Jadi saya melakukan tugas jurnalistik sembari ngajak DHAVA bermain

Dhava juga sibuk mencari komputer kecil subnotebook seperti Asus eeePC, dan di stand LINPUS dipajang beberapa subnotebook yang menggunakan Linux (LINPUS), kata Dhava gambarnya si Pingu yang bisa terbang.

Pulang dari CeBIT keretanya telat, terus harus menunggu di Minden. Sampai di Bielefeld, Anthi menjemput di Bahnhof, terus ke Mac Donald beli Happy Meal dan mainannya buat Dhava. Padahal kata Dhava, MacDonald itu tidak sehat. Jadi paling banyak 1 bulan 1 kali saja, walaupun Dhava suka minta tambah jadi 1 bulan 2 kali.

Situs KPU baru saja “disusupi” pesan cinta kembali. Tentu saja setelah kejadian terjadi (sayangnya pesan tersebut cukup lama masih nongol di situs KPU), perlu dilakukan analisis oleh pengelola untuk mengetahui apa yang terjadi dan siapa yang melakukan (ini tujuan berikutnya, polisi yang lebih tertarik sebetulnya untuk hal berikutnya).

Ketika kejadian terjadi di suatu situs , banyak Admin panik langsung mematikan sistem dan menghapus kesalahan tersebut sehingga sistem bisa up kembali. Saran saya “JANGAN !” . Tetapi sebaiknya lakukan langkah yang tepat untuk menyimpan bukti dengan cara menyimpan kondisi memori, kondisi file temporar, kondisi socket terbuka dan lain sebagainya. Pada dunia komputer forensik ini yang dikenal membuat “snapshot” dari sistem yang sedang berjalan. Setelah itu baru memeriksa sistem yang ada (analisis port mortem). Teknik mesin virtual saat ini memungkinkan kita menjalankan “image” sistem dengan snapshoot berjalan seperti kondisi tersebut.

Untuk memeriksa sistem yang ada, maka hard disk asli tidak boleh dikutak-katik untuk itu perlu dibuat “image” dan image inilah yang bisa diselidiki. Untuk melakukan hal itu berbagai tool tersedia dari tool komersial seperti Encase [http://www.guidancesoftware.com/], Forensic Tool Kit (FTK) [http://www.accessdata.com/], XWays [http://www.x-ways.net], bisa juga dengan tool Open Source dd yang relatif ada di tiap sistem Unix/Linux, atau dd_rescue [http://www.garloff.de/kurt/linux/ddrescue/]. Untuk aplikasi Open Source dapat dengan mudah menggunakan distribution untuk forensik misal Helix [http://www.e-fense.com/helix/].

Setelah image disimpan baru lakukan proses analisis forensik standard. Dalam melakukan proses forensik ada kaidah utama yang diterapkan yaitu “Chain of custody” artinya setiap langkah yang dilakukan, siapa, bagaimana dan hasilnya harus tercatat rapih. Perangkat bantu atau metoda yang digunakan juga biasanya harus memenuhi kaidah Daubert (sebelumya yang diterapkan adalah kaidah Frey). Pada kaidah Daubert metoda dan perangkat bantu yang diterapkan telah melalui peer-review secara ilmiah. Oleh karena itu sekarang pada beberapa negara, perangkat bantu proprietary agar dapat digunakan untuk pekerjaan forensik harus melalui auditing dan pengujian terbuka terlebih dahulu. Beberapa polisi di negara maju lebih mengandalkan perangkat bantu open source untuk melakukan proses image ini.

Berkaitan dengan analisis forensik setelah kejadian (incident), maka akan dapat dilakukan lebih mudah dan lebih ditail lagi, bila sistem yang dibangun juga telah memiliki pertimbangan seperti itu. Dengan kata lain audit trail, benar-benar diterapkan. Sayangnya tidak banyak sistem yang dikembangkan untuk kepentingan pemerintah memenuhi kriteria tersebut. Sebagian sistem dikembangkan dengan asumsi sistem tidak pernah ada masalah. Saya kurang tahu apakah sistem seperti e-Procurement, Certificate Authority yang saat ini sudah diterapkan di situs pemerintah, telah menerapkan kaidah-kaidah audit trail dengan baik.

Tentu saja untuk tujuan forensik itu, maka pertimbangan disain sistem akan mulai dari filesystem manakah yang paling mudah untuk dilakukan forensik (menyimpan timestamp, dan metadata paling lengkap). Juga perlu dipertimbangkan filesystem manakah yang spesifikasinya terbuka, karena ini akan memudahkan proses penggunaan perangkat bantu. Seperti yang diungkapkan salah satu ahli forensik Jerman, Alexander Geschonneck [http://www.computer-forensik.org] di CeBIT 2008, untuk filesystem proprietary seperti NTFS, ketika seorang harus melakukan analisis forensik sering harus diterapkan teknik-teknik yang relatif berdasarkan reverse engineering. Di CeBIT 2008, di pertemuan forensik yang banyak dihadiri polisi dan praktisi forensik dari berbagai perusahaan sekuriti., ahli tersebut menyatakan kerumitannya untuk proses forensik file system NTFS yang digunakan di Windows VISTA.

Begitu juga untuk sistem operasi, sistem operasi manakah yang dapat dipasang perangkat lunak “instrumentasi” sehingga setiap proses, penggunaan resource dapat tercatat dengan ditail. Trend terbaru saat ini adalah dengan cara memasang sistem di atas Hypervisor Monitoring (seperti Xen) sehingga apa yang terjadi di atas sistem tersebut akan tercatat dengan baik di log. Instrumentasi ini juga perlu dilakukan untuk setiap komponen (akses ke web server, akses ke database server, akses ke shell, dan sebagainya). Dengan log yang baik maka proses analisis akan dimudahkan.

Tentu saja log-log ini perlu dikelola dengan baik dan tidak disimpan di 1 tempat. Sehingga perlu dibangun log aggregator server yang menyimpan log-log ini. Untuk kevalidan penyimpanan log, maka perlu dilakukan 2 metoda, penyimpanan real time dan penyimpanan secara regular. Di samping itu proses tanda tangan digital perlu dilakukan agar log ini sah sebaca bukti hukum. Kedua jenis log (real time berbentuk stream) dan regular (berbentuk file), membutuhkan proses tanda tangan digital yang berbeda.

Jadi mendisain sistem tentu saja bukan dengan asumsi, bila semuanya bekerja secara normal, tetapi juga ketika sistem berjalan tidak normal atau mengalami serangan. Bagi pembaca yang ingin mengetahui tahapan-tahapan digital forensik, bisa membaca beberapa tulisan kelompok kerja di bawah arahan Dr A. B. Mutiara dari Univ Gunadarma [http://nustaffsite.gunadarma.ac.id/blog/amutiara/>], yang telah menyediakan beberapa guideline komputer forensik dalam bahasa Indonesia dan beberapa kertas kerja dalam bidang komputer forensik. Juga bisa dibaca di blog Hendro Wicaksono [http://hendrowicaksono.multiply.com/blog]

Langkah berikut setelah mengumpulkan factual information adalah melakukan interpretation information. Beberapa metoda formal dapat diterapkan dari memanfaatkan petri-net, ataupun dengan Why Because Analysis [http://www.rvs.uni-bielefeld.de] dari Prof. Peter B Ladkin PhD, yang telah banyak digunakan untuk melakukan analisis kecelakaan transportasi (pesawat, kereta, dan lain sebagainya).

Ketika CMS dengan model dinamis yang mengakses database digunakan di depan dengan gagahnya oleh para developer tanpa firewall di tingkat aplikasi, maka mau tidak mau resiko XSS dan Sql injection hanya tinggal waktunya tiba. Masih ingat kasus KPU yang disebabkan kedua hal ini, walau katanya sudah ditutup oleh firewal berlapis-lapis. Memang itu adalah resiko model CMS dinamis yang tanpa pertimbangan matang. Tentu saja karena berbagai alasan (dari tidak tahu, malas, waktu kepepet dan lain halnya). Banyak developer lebih suka memasang aplikasi CMS langsung begitu saja.

Sekarang bagaimana mantra pelawan serangan XSS dan Sql injection? Dari hasil pertapaan di lembah Google sebetulnya banyak mantra yang dapat diturunkan, mantra ini banyak yang berupa teknik lama diterapkan di domain (masalah) baru. Teknis pertama adalah ketika sistem didevelop, di samping mendevelop sistem dengan hati-hati maka bisa dimanfaatkan metoda yang sudah “TUA” dalam bidang software verification (saran saya bagi pendevelop aplikasi web membaca buku teori dan hal-hal agak formal sangat dibutuhkan). Tool itu yang dikenal dengan sebutan “static analyzer“. Static di sini berarti sistem software dianalisis dalam situasi statis bukan ketika dijalankan (situasi dinamis). Artinya source code program akan diperiksa secara otomatis. Pada dasarnya celah XSs dan Sql bisa dianalisis dari source codenya, melakukan analisis secara manual tentu melelahkan untuk itu bisa digunakan Static Analyzer. Salah satu contohnya ada Pixy [http://pixybox.seclab.tuwien.ac.at/pixy/].

Mantra kedua adalah dipasang untuk sistem yang berjalan. Jurus pertama bisa dengan menggunakan modsecurity [http://www.modsecurity.org/], suatu firewall untuk aplikasi web. Pada dasarnya modul firewall ini akan menjadi satpam antara web server dan aplikasi web. Sehingga setiap akses ke web aplikasi web akan diperiksa terlebih dahulu berdasarkan aturan-aturan. Bila dilihat ada akses yang mencurigakan (stringnya mirip XSS attack atau SQL Injection) maka otomatis tidak diteruskan ke aplikasi web. Perlu diketahui bila Anda memasang rule terlalu banyak maka sering posting dimuntahkan (akan agak repot untuk forum dsb, tapi itu resiko dari keamanan).

Jurus kedua adalah menggunakan firewall database, yang berada di antara aplikasi web dan database engine. Misal dengan menggunakan GreenSQL [http://www.greensql.net]. Setiap perintah SQL yang melewati program ini akan dinilai berdasarkan suatu matriks resiko. Bila ada request yang mencurigakan maka tidak diteruskan ke database server. Saat ini GreenSQL sudah mendukung MySQL. Bebepera perintah SQl yang bersifat administratif tidak secara default diloloskan.

Mantra ketiga yang perlu dipertimbangkan adalah menggunakan model queue dalam proses interaksi, jadi ketika pengguna submit suatu masukan (via form atau lainnya), maka akan masuk ke queue terlebih dahulu, dan queueu ini dianalisis dan disubmit ke CMS sesungguhnya. Dengan cara ini maka tidak ada akses langsung ke sistem sesungguhnya. Dengan cara ini ada 2 database yang digunakan, database untuk front end (queue dari submission) dan database dari CMS yang juga terlindungi dengan mantra-mantra sebelumnya.

Koq repot ya, itulah resiko dari disain yang malas mikir (bandingkan bila rumus statis-statis ditetapkan dengan cerdas). Kali lain akan disambung dengan mantra-mantra lainnya, apalagi kalau situs sudah pakai AJAX, dsb. Semakin banyak komponen yang digunakan dan di luar kendali server, maka semakin banyak celah yang terbuka dan dapat dimanfaatkan. Solusi di atas saya berikan adalah yang bersifat Open Source, karena menurut saya solusi closed source tidak memenuhi persyaratan auditing (sebagai contoh static analyzer itu tidak bisa dijalankan bila kita tak memiliki source code). Gini hari koq ndak kenal Open Source.

Terkejut saya mendengar berita teman lama saya sesama dosen Univ. Gunadarma, Irwan Arifin yang juga lulusan Fisika UI (Angkatan 1983) beberapa hari yang lalu meninggal dunia. Begitu mengejutkan berita itu.

Masih teringat ketika Irwan dengan tangan dinginnya memegang kamera (apa saja) mampu menghasilkan foto-foto yang menawan yang kami gunakan untuk brosur dan poster dalam rangka mempersiapkan Open House di STMIK Gunadarma pada tahun 1989. Ketika itu kami adalah sekelompok mahasiswa Fisika UI yang juga aktif di STMIK Gunadarma mengembangkan laboratorium.   Bersama-sama dengan Irwan kami aktif mengembangkan Lab Mikroprosesor.  Walau kami akfit mengembangkan Lab di STMIK Gunadarma, kami tidak meninggalkan aktifitas juga mengembangkan Lab Elektronika di Fisika UI.  Irwan pun akhirnya memilih menjadi dosen tetap Univ Gunadarma seperti saya.

Pribadinya yang kalem terlihat dari sudut pandang untuk mengambil gambar foto yang selalu kami butuhkan untuk poster dan brosur.  Tidak jarang karena keterbatasan alat-alat Irwan memiliki idea genial untuk dapat menghasilkan foto yang baik. Saya tidak tahu apakah hobby fotografi itu masih dijalankan oleh Irwan.  Bagi Irwan peralatan adalah nomor ke-n untuk menghasilkan gambar yang baik.
Irwan pun jarang mengeluh mengenai kondisinya, melakukan pekerjaan yang diberikan pada dirinya. Sangat nerimo kesannya. Selamat jalan kawan …..

Ketika situs banyak hit-nya banyak orang mulai bingung mencari mantra sakti. Berbagai macam cara ditempuh, sda yang mencoba mijit-mijit setting cache, ada yang mencoba mijit-mijit setting database server, tapi yang lebih banyak langsung main naikin hardware (ndak peduli problemnya ada di mana). Satu mantra yang sangat mujarab tapi jarang dimanfaatkan orang Indonesia adalah “statis… statis… statis“. Maksud saya sedapat mungkin manfaatkan halaman statis, ketimbang dynamis (on the fly digeneratenya). Tentu para web developer banyak yang berkata “wah itu kuno” kan sekarang jamannya dinamis. Memang banyak developer pengen simplenya pakai CMS dan tidak memikirkan efisiensi dari halaman statis. Install Joomla, Wordpress, dan mudah-mudahan jalan kenceng pada hit berapapun.  Solusi tambal sulam tanpa melihat permasalahan dasar sering digunakan.  Mungkin perlu baca artikel Mbah Wirth “A plea for lean software“.

Halaman statis ini bukan berarti selalu statis tak pernah berubah, tetapi yangdimaksud di sini adalah menghasilkan halaman statis secara pintar dari kontent dinamis. Sehingga ketika hit sama ke entry tersebut, sebetulnya sudah mengakses versi statisnya. Tentu banyak developer yang protes ? Susah donk bikin CMS-nya, ya lah, sebagai developer Anda kan dibayar buat mikir he he he he

Keuntungan menggunakan halaman statis ini adalah bisa dilayani oleh web site secara cepat, dan bila butuh lebih cepat lagi bisa dilayani oleh web server di level kernel. Faktor lain adalah keamanan, dengan separasi konten statis dan dinamis secara pintar maka situs utama akan terlindungi. Tentu saja untuk melakukan hal ini secara pintar, langkah pertama adalah melakukan analisis frekuensi dari pengkinian halaman. Faktor lain adalah kemudahan proses backup dan cache.

OK kali lain dilanjutkan, yang penting sekarang camkan mantera ini, dan ucapkan “statis… statis…statis”