Menyikapi Situs Yang Diobrak-abrik Hacker

Jakarta - Akhir-akhir ini marak terjadi penyerangan (penyusupan) ke situs pemerintah bahkan situs POLRI juga tidak luput dari serangan tersebut. Mengenai alasan mengapa situs-situs tersebut diserang menurut saya bukanlah suatu yang layak dibahas secara Telematika karena bila bicara mengenai alasan maka topik bahasannya bisa dari A sampai Z, begitupun kemungkinan pelakunya bisa si A sampai si Z.

Sebenarnya yang perlu dilakukan cukup fokus terhadap apa yang dihadapi dan mencari solusi sesuai tahapan yang benar. Kita tidak perlu sesali bila situs kena hack, justru itu menjadi feed-back bagi kita bahwa situs kita belum terlindungi dengan benar dan perlu ada pembenahan, perlu ada pembelajaran.

Lalu pertanyaan berikut adalah mengapa situs D,E & F yang kena incar bukan X,Y & Z?

Di luar dugaan kemungkinan adanya niatan dari pihak tertentu (non teknis) salah satu jawaban paling logis dalam dunia hacking adalah apabila suatu metoda berhasil membobol suatu situs maka cara yang termudah untuk kembali sukses membobol situs lain pasti dengan mencari situs yang menggunakan cara yang sama seperti yang berhasil dibobol sebelumnya tersebut, betul bukan?

Hal itu karena tantangan (baca: kebanggaan) membobol situs pemerintah bukanlah kepada "seberapa sulit" bisa melakukan penerobosan melainkan "seberapa banyak" yang berhasil dibobol.

Ironisnya kenyataan yang ada di lapangan justru sangat membuka peluang untuk itu karena walau proyek-proyek pengadaan situs menghabiskan biaya yang tidak sedikit tapi ternyata situs yang terpasang sering kali sangat rentan atau misal menggunakan framework dari sumber yang sama dan banyak di internet.

Dengan demikian pasti memiliki kerentanan yang sama dan lebih parahnya lagi sangat umum terjadi pada situs pemerintah bahwa kurangnya kesadaran untuk memelihara situs (melakukan patching, upgrade), ini yang lazim terjadi walau tentu tidak mengeneralisir bahwa semua pengelola situs pemerintah seperti ini.

 

Hal lain tapi tidak dipungkiri bahwa maraknya pembobolan ini sangat mungkin dimanfaatkan oleh oknum tertentu untuk menjadikan "musibah massal" ini sebagai alasan mendapat proyek perbaikan situs, jadi tetap mungkin saja (walau tidak bermaksud menuduh) suatu situs dibobol oleh orang dalam sendiri.

Adapun pembuktian pencarian pelaku pembobol apakah itu dilakukan orang dalam atau luar sepenuhnya menjadi tugas kepolisian yang tentu mungkin bisa terlacak dengan rekam jejak, log, analisa alur akses, pemeriksaan setting firewall (bila ada) dan sebagainya. Namun itu semua secara Telematika tidak terlalu berarti karena pada akhirnya hanya upaya pencari pelakunya. Ketemu atau tidak ketemu pelakunya toh situsnya sudah "terkapar" dan perlu dipulihkan.


Yang perlu dilakukan pengelola situs adalah selain membantu pihak kepolisian dengan memberikan berbagai informasi yang dibutuhkan (guna pelacakan pembobol) pengelola situs harus segera melakukan perbaikan situs agar dapat kembali melayani masyarakat.

Tanpa bermaksud menganggap remeh situs yang dimiliki pemerintah tapi pada umumnya isinya (walau dinamik) sekedar informasi elektronik mengenai lembaga / institusi / departemen yang bersangkutan dan belum sampai ke data penting dan hal lain yang kelak mengganggu operasional dan merugikan Negara.

Sehingga untuk pemulihan situs dengan karakter seperti ini bukanlah hal yang sulit dilakukan (bagi yang paham dan berpengalaman), tidak butuh berhari-hari dan tidak akan mengeluarkan dana banyak. Salah satu contoh logis, sejauh apapun yang bisa dilakukan si hacker namun secara fisik aksesibilitas terhadap server tentu 100% ada pada kuasa pengelola dan begitu pula super user password (atau admin password).

Itu sudah cukup menjadi kunci sukses utama dalam pemulihan. Misal ternyata bahkan akses ke Super User itupun telah diambil alih si hacker maka pengelola dapat mengatasi dengan mengganti harddisk dengan yang lain dan 100% pengaruh si hacker sudah musnah dari server tersebut. Tidak rumit bukan?

 

 
Formulasi Langkah 5 R
 
 
Selanjutnya pihak pengelola cukup melakukan langkah yang saya formulasikan dengan istilahkan 5R --agar mudah diingat-- yaitu Recovery, Rebuild, Restore, Resolve dan Retain sebagai berikut:


Recovery

Upaya pengambilan data bergerak yang mungkin ada dari sejak terakhir backup dilakukan termasuk diantaranya semua file yang bersifat log atau hal yang bisa membantu yang berwajib untuk melakukan pelacakan pelaku. Anggap pekerjaan ini membutuhkan 2 jam.


Rebuild

Ini adalah upaya pembangunan kembali struktur sistem bisa sekedar pada tingkat aplikasi web yang mungkin hanya beberapa menit saja. Misal keadaan yang terjadi sangat parah sehingga tahap ini harus dari tahap instalasi sistem operasi maka baik pada Linux atau Windows server tahap instalasi dan setting bisa dilakukan (secara tidak terburu-buru) diprakirakan menghabiskan waktu sekitar 2 jam.

Kemudian dilanjutkan dengan instalasi piranti lunak atau tools yang biasa digunakan, waktunya tergantung dari jumlah piranti yang diperlukan untuk direinstalasi. Dalam melakukan ini skala prioritas sangat berguna yakni utamakan yang penting dan sangat diperlukan segera ada dan selebihnya bisa dilakukan setelah tahapan 5R ini selesai.


Restore

Ini adalah pengembalian database dari file backup. Tentu keberhasilan ini tergantung dari kerajinan pengelola melakukan backup baik full-backup (Differential) maupun update-backup (Incremental). Apabila ternyata pengelola tidak memiliki backup maka saya pribadi lebih menganjurkan agar pengelola tersebut diberi sanksi yaitu diganti oleh pihak lain.

Mungkin hal itu terlihat sangat ekstrim tapi patut diketahui bahwa kelalaian melakukan backup adalah suatu hal yang tidak boleh ditolerir dengan alasan apapun dan menjadi tugas utama pengelola situs.

Dengan analogi sopir maka dia tidak boleh memarkir kendaraan pada lokasi yang retan kecelakaan atau kehilangan bukan? Dapat dikatakan anggaplah pengelola situs (server admin / db admin / web admin / webmaster dan segala posisi yang terkait dengan pekerjaan tersebut) utamanya digaji hanya untuk backup data dan selebihnya itu sekedar tugas tambahan J. Yang ingin ditekankan adalah apalah arti kerja berbulan-bulan apabila tidak dapat menyimpan pekerjaannya tersebut secara baik.

Tentu disini penting juga langkah rutin latihan restore, sebagai bagian dari DRP (Disaster Recovery Plan) bahwa data yang dibackup harus dipastikan dapat dipulihkan (restorable). Durasi pekerjaan ini tergantung dari besarnya backup yang dimiliki dan jenis restore yang dilakukan.

 
Resolve

Menuntaskan tahapan pemulihan dengan melakukan pengujian dan pemastian bahwa segalanya telah kembali normal (atau lebih baik dari kondisi sebelumnya) atau setidaknya pemulihan telah sampai pada tingkat yang dapat dipertanggungjawabkan atau diterima oleh pimpinan, lalu dipastikan sistem pelindung telah terpasang dan diaktifkan, patch yang diperlukan telah dipasang. Bila semua dinyatakan "SIAP" maka layanan ini bisa segera dibuka kembali.

Pada tahap ini sangat diperlukan adanya pencatatan mengenai apa yang dipasang, ditingkatkan, perbedaan dengan setting terdahulu. Sehingga apabila terjadi penyerangan berikut maka pengelola tidak perlu melakukan fall-back (atau kembali ke sistem sebelum tahap 5R) melainkan cukup mengulang tahapan 5R dengan benar, mungkin saja ada langkah yang terlupa atau ada langkah mendetil yang terlewati.

 
Retain

Secara parallel (karena situs telah dibuka kembali) dilakukan pengujian terhadap situs untuk dipastikan bahwa setidaknya situs tidak akan rubuh dengan modus operandi yang sama dan juga diuji dengan cara lainnya.

 

Tahap 5R ini bukan jaminan bahwa sistem akan lebih kuat karena dalam dunia ICT tidak ada istilah lebih kuat. Yang perlu diutamakan bukan sekedar keamanan (Secure) tetapi juga kecepatan (Speed), stabil (Stable) dan lancar (Smooth) keempat ini bisa diingat dengan istilah 4S (lagi-lagi ini bukan istilah baku namun agar mudah mengingatnya) dan perlu disadari dibalik sistem ICT tersebut adalah manusia yang mungkin lalai melakukan semua tahapan tersebut secara mendetil dan benar walau sudah diterapkan SOP (Standard Operating Procedure).

Sehingga control berupa check-recheck akan sangat membantu. Tahapan 5R ini setidaknya dapat memberikan panduan kepada pengelola situs untuk tidak panik lalu malah melakukan banyak langkah yang tidak perlu dan justru lupa pada skala prioritas manfaat dan kepentingan situs tersebut.

Semoga informasi ini bermanfaat untuk kita semua dan membuat liat lebih sering belajar dalam melakukan trouble shooting yang baik, dan pesan ini untuk kita semua termasuk untuk diri saya sendiri.

*Penulis: Abimanyu Wachdjoewidajat merupakan akademisi dari UIN Syarif Hidayatullah serta praktisi telematika. Ia bisa dihubungi melalui blog http://awam.multiply.com.

Artikel yang Berkaitan

Posted in: