Cara Antisipasi Jika Web/Blog kita di acak-acak Hacker

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.