Keamanan Aplikasi – Pencegahan Risiko Malware
273
Malware (Malicious Ware) merupakan perangkat lunak. Perilaku dari malware yakni menyebabkan kerusakan pada sistem maupun jaringan komputer. Dalam penyelenggaraannya, sistem elektronik yang menunjang urusan pemerintahan dapat terserang malware. Sehingga malware dapat berpengaruh terhadap performa dari aplikasi pemerintahan. Tulisan ini betujuan untuk menjadi bahan literasi digital terkait keamanan aplikasi, bagaimana pencegahan risiko malware terhadap operasi aplikasi tanpa diperlukan kepakaran dalam dunia IT.
Sebelum masuk kepada inti, perlu diketahui bahwa ada risiko siber yang sifatnya pasif dan risiko siber yang sifatnya aktif.
Risiko siber yang bersifat pasif, lebih kepada reaksi atas aksi yang dilakukan entitas pengguna komputer. Misal, pengguna komputer mengunduh malware, lalu kemudian melakukan instalasi malware.
Sedangkan risiko siber yang bersifat aktif, lebih mengacu kepada tindakan aktif, aktifitas penyerangan, cracking, hacking, yang mana tidak ada aksi dari pengguna komputer yang dengan sengaja melakukan pembobolan atau perusakan keamanan sistem komputernya tersebut.
Adapun pencegahan risiko siber yang bersifat aktif, cenderung dapat dimitigasi oleh entitas penegak hukum berkenaan siber yang mana memiliki kekuatan advokasi serta sumber daya untuk melakukan pelacakan pelaku-pelaku cyber crime. Sebab risiko siber aktif semisal cyber crime cenderung dapat dilakukan oleh entitas-entitas dengan sumber daya memadai, baik pendanaan, dukungan advokasi yang kuat, jejaring dengan kuantitas dan mutu yang mencukupi. Ciri tersebut lebih dekat kepada karakteristik entitas yang dikenal dengan sebutan mafia. Sedang mafia tidak terbatas pada lingkup non pemerintahan saja, melainkan juga dapat menjangkau entitas pemerintahan. Dalam artian keberpihakan terbagi kepada kepentingan pemerintahan dan golongan (jejaring mafia). Istilah yang cukup umum melekat kepada pelaku-pelaku cyber crime yakni black-hat hacker dan atau gray-hat hacker. Kesamaan dari keduanya yakni masuk kepada privilege sistem operasi yang bukan haknya, dan tanpa sama sekali adanya restu, keterangan fungsi delegasi/ perwakilan, dari pengguna yang memiliki privilege. Privilege mengacu kepada individu manusia, bukan instansi, yang mana setiap individu memiliki log aktivitasnya sendiri untuk dipertanggungjawabkan. Adapun white-hat hacker, tidak termasuk ke dalam ranah cyber crime, namun lebih kepada jasa berbayar pengujian celah kerentanan yang mana dalam praktik atau prosedurnya tidak menyalahi hukum, dilakukan dengan transparansi kepada kliennya, tanpa dilakukan secara rahasia, diam-diam, dan yang semisal.
Dikarenakan banyak keterbatasan yang dapat dilakukan entitas-entitas sistem elektronik pada umumnya terkait risiko siber yang sifatnya aktif, maka pencegahan risiko siber aktif dikecualikan dalam bahasan ini, tulisan berkenaan hal tersebut relevan untuk diangkat oleh entitas penanganan cyber crime. Konsentrasi tulisan ini hanya membahas pencegahan risiko siber yang sifatnya pasif, risiko-risiko yang dapat diperkirakan (acceptable risk).
Bicara tentang operasi aplikasi, akan mengacu kepada faktor-faktor internal dan eksternal yang berpengaruh terhadap operasi aplikasi. Faktor internal mengacu kepada kode sumber (source code) dari aplikasi. Faktor eksternal dapat mencakup kepada lingkungan operasi aplikasi (cloud services/ on premises).
Dalam beberapa percobaan uji kelayakan operasi sistem informasi APTIKA DISKOMINFO SP KUTIM, besaran risiko berkenaan operasi aplikasi sangat dipengaruhi kepada di mana aplikasi itu diletakkan, karena kode sumber yang digunakan untuk aplikasi merupakan kode sumber terbuka (open source), sifatnya generik, diambil dari sumber yang resmi, tidak mengambil dari kode sumber ‘bajakan’. Risiko selanjutnya berasal dari faktor-faktor lainnya (selain dari penempatan sistem informasi). Maka kita akan membahas dari hal-hal yang paling berpengaruh terhadap aplikasi ini, yakni cloud services.
1. Pilih Layanan Cloud Service dengan Firewall Memadai
Bilamana aplikasi sudah cukup bersih, (telah dilakukan scan dengan antivirus dalam atau setelah proses pengembangannya), maka tibalah saatnya untuk migrasi dari media pengembangan (komputer developer) ke media produksi (cloud hosting). Maka aplikasi yang berjalan pada media produksi beroperasi sebagaimana mestinya. Kita dapat simulasikan diri kita untuk berpikir sebagai seorang attacker. Bagaimana agar supaya malware dapat menembus DMZ (Demilitarization Zone/ Zona Demilitarisasi)? Maka kita harus melakukan information gathering berkenaan jalan-jalan masuk hingga sampai kepada server. Yang mana itu berarti kita harus mengenali kerentanan yang dimiliki firewall, reverse proxy (jika ada), router, dsb. Apa yang tidak dapat dikenali oleh firewall dan serangkaian sistem keamanan? Penyamaran. Enkripsi. File tidak serta-merta masuk ke server dengan identitas yang terang-terangan malware. Bagaimana supaya file bisa masuk ke path yang menjadi root aplikasi? Kembali lagi kepada hasil information gathering, apa celah yang dimiliki aplikasi. Adakah jalan untuk menyisipkan malware? Bilamana ada, maka semuanya menjadi semakin mungkin, jika permission access pada root path atau sub direktori aplikasi tersebut writeable. Apabila file telah sampai kepada target path yang prospektif, maka tinggal jalankan mekanisme eksekusi file dan eksploitasi. Maka ini termasuk kepada risiko aktif (domain penanganan cyber crime). Selama ‘tikus’ (black hat) lebih kuat daripada ‘kucing’ (penanganan cyber crime) selama itu black-hat atau gray-hat dibiarkan begitu saja tanpa adanya penegakan hukum, selama itu pula cyber crime dilestarikan. Asumsikan hal tersebut terjadi, ini dapat dimitigasi atau dikurangi risikonya dengan layanan cloud services dengan firewall yang relevan terhadap perkembangan risiko siber, karena bilamana ada metode dari firewall yang akurat dalam mengidentifikasi virus dan malware (misal decrypt file terenkripsi/ mencurigakan) maka paket data yang akan masuk dan atau paket data yang akan keluar DMZ akan diblokir jika hasil identifikasi positif virus/ malware. Dalam skenario lain, malware yang tereksekusi dan berjalan dalam sistem dapat di-scan baik dengan scan berkala, real time, by event, atau metode lainnya. Sehingga dampak negatif risiko dapat ditekan, bahkan bisa jadi hingga 100%.
Maka perbendaharaan mekanisme firewall dalam menghadapi berbagai bentuk virus/ malware, berpengaruh terhadap kelangsungan operasi aplikasi yang diletakkan pada DMZ.
Pertanyaannya kunci bagi klien adalah bagaimana cara awam mengetahui cloud services memiliki firewall yang memadai? Jawabnya adalah coba layanan tersebut. Bilamana sistem anda terserang malware, maka anda telah mengetahui bahwa firewall pada cloud service tersebut, pada saat itu, belum relevan terhadap perkembangan malware.
2. Pilih Layanan Cloud Service dengan Pelayanan Pelanggan yang Baik
Asumsikan anda selaku system administrator telah mengunduh suatu perangkat lunak dari sumber resmi, tidak ada keterangan bahwa perangkat lunak tersebut berbahaya. Fungsi berjalan sebagaimana mestinya, namun ternyata oleh malware scanner vendor diidentifikasi sebagai malware. Apa ekspektasi klien layanan hosting akan hal tersebut? Tentu klien ingin agar tidak ada risiko sama sekali atau risiko berkurang. Hal yang mengacu kepada hal tersebut yakni kecepatan dalam identifikasi pada saat terjadi perubahan pada sistem. Apabila positif malware, maka faktor berpengaruh selanjutnya yakni kecepatan dalam penyampaian kepada klien. Untuk tingkat yang lebih paranoid, mungkin hal yang diinginkan klien adalah hapus otomatis malware beserta segala malware services tersisa yang bermula dari malware trigger. Apa mekanisme yang digunakan penyedia layanan hosting agar scan dan identifikasi malware dapat berlangsung sebelum adanya sistem yang terserang malware? Itu merupakan urusan penyedia layanan hosting. Apa mekanisme yang digunakan penyedia layanan hosting untuk memberi tahu klien terhadap risiko siber yang dihadapi aplikasi klien? Itu pelayanan pelanggan. Semakin baik pelayanan pelanggan, maka pelayanan pelanggan akan lebih aware dalam customer relationship. Mengkondisikan “delivery” menjadi “delivered”, mengkondisikan “unread” menjadi “read”. Sejauh ini, yang cukup relevan untuk suksesnya penyampaian pesan yakni pilihan mail client yang memungkinkan pop up pada mobile phone. Hal tersebut tidak mengganggu klien yang sedang dalam acara atau pertemuan penting, tidak mengganggu privasi, dsb. Penggunaan mail client relevan untuk hal-hal yang sifatnya tidak darurat. Namun mekanisme delivery yang lebih tepat kebutuhan sedikit banyaknya dipengaruhi oleh tingkat urgensi pesan dan tingkat urgensi aktifitas klien. Apabila lebih urgent pesan, maka mekanisme penyampaian pesan merupakan urusan penyedia layanan hosting.
Pertanyaan kunci yang dapat anda jadikan pertimbangan pemilihan layanan cloud service yakni apakah jika terjadi suatu anomali atau kejadian tertentu (misal anomali traffic, sedang maintenance, identifikasi file atau proses mencurigakan atau positif malware/ virus) pesan sampai? Sampai kepada siapa? Kapan kejadiannya dan kapan sampainya.
3. Pilih Layanan Cloud Service dengan Layanan Konsultasi yang Memadai
Dalam praktiknya, sebagian besar operasi tidak serta-merta ditangani 100% oleh kecerdasan buatan, melainkan ditangani manusia. Maka mekanisme transfer pengetahuan menggunakan jaringan komputer atau kabel data tidak dapat digeneralisir. Transfer pengetahuan manusia dalam penyelesaian masalah, yakni dengan pertukaran informasi. Pertukaran informasi antar manusia, yakni komunikasi. Jadi bilamana suatu layanan pelanggan bermasalah dalam hal komunikasi, komunikasi bermasalah dalam konsultasi, maka masalah operasi siber itu adalah suatu keniscayaan.
Penyediaan kapasitas berupa perbendaharaan tautan artikel teknis, help desk, IT support dan atau tim tanggap insiden siber merupakan resource yang sulit untuk ditawar penyedia layanan. Hal tersebut semata untuk memberi arahan kepada klien, apa yang merupakan benefit untuk dilakukan oleh klien terhadap operasi sibernya. Karena itulah jalan transfer pengetahuan bagi manusia untuk menyelesaikan masalah. Komunikasi dan informasi. Apakah take down sistem yang perlu tindak lanjut merupakan komunikasi? Atau informasi? Jika tidak masuk ke dalam keduanya, maka online adalah pilihan.
Dari beberapa poin di atas, tampak bahwa hal yang berpengaruh terhadap pencegahan risiko siber lebih mengacu kepada manajemen mutu layanan hosting, manajemen pelayanan pelanggan dan customer relationship, kapasitas konseling/ konsultan, dan itu jauh lebih relevan dalam kesinambungan cloud service daripada pengadaan kapasitas interpersonal atau perorangan yang sudah ahli/ terampil dalam keamanan siber dan administrasi sistem.
Pertanyaan kunci yang dapat anda jadikan pertimbangan berkenaan hal ini adalah, ketika anda mengalami kendala atau memerlukan arahan teknis, apakah ada pelayanan pelanggan (semisal online/ offline help desk) yang tersedia? Apakah pelayanan pelanggan dapat membantu/ membimbing anda dalam problem solving? Bagaimana dokumentasi hasil asistensi/ konsultasi dapat anda akses?
4. Gunakan Kode Sumber Terbuka atau Kode Sumber Resmi
Aplikasi akan bersumber pada kode program. Kode sumber (source code) program, ada yang terbuka (open source) dan ada yang tertutup (closed source). Dalam kaitannya dengan anggaran, open source merupakan kode sumber bebas anggaran/ biaya, sedangkan closed source merupakan kode sumber yang memiliki lisensi berbayar.
Open source memiliki keunggulan dalam kuantitas dukungan. Baik itu dukungan troubleshoot, dukungan pengembangan, dukungan pemutakhiran sistem, jumlah SDM yang familiar dalam penggunaan atau mekanisme bagi pakai, dsb. Sehingga merupakan suatu kewajaran apabila banyak pihak, baik internal pemerintahan maupun eksternal pemerintah (yang mengerti IT), baik relawan maupun komersil, menganjurkan penggunaan open source. Kekurangannya, sebagian jenis produk berkenaan pengembangan perangkat lunak dan operasi aplikasi yang dihasilkan open source memerlukan kemampuan tingkat dasar dalam hal administrasi sistem, yang mana administrasi sistem berbasis opensource lumrahnya berdiri di atas varian distro dari kernel Linux.
Closed source memiliki keunggulan dalam besaran mutu layanan, memiliki UX design yang tak hanya berfungsi, namun juga nyaman, minimalis, elegan, menyenangkan hati bila memandangnya. Maka tak ayal bagi pengguna komputer pada umumnya, cenderung akan memilih produk-produk closed source. Namun terlepas dari hal tersebut, kekurangan dari closed source yakni berbayar.
Tak jarang kita temui pada kondisi pemerintahan maupun non pemerintahan, suatu komputer pada awalnya datang dari program pengadaan, berisi perangkat lunak closed source. Segalanya nyaman, hingga datang waktu di mana PC tersebut harus diinstal ulang. Yang murah, instal ulang sendiri. Setelah diinstal ulang sendiri, aplikasi closed source yang semula belum bayar tapi nyaman digunakan, tiba-tiba perlu dilakukan aktivasi lisensi untuk program paket perkantoran. Apa ekspektasi dari pengguna komputer? Ada pilihan untuk menggunakan program usulan anggaran pembelian lisensi dengan menunggu satu dua tahun (jika disetujui), nampaknya jika ingin segera bekerja, menunggu satu bulanpun tidak akan dijadikan pilihan. Maka cari tempat instal ulang yang menawarkan instalasi Ms. Office gratis, kalau bisa sekalian dengan Photoshop-nya, gratis. Bilamana ada utilitas dan game premium yang dapat dijalankan pada komputer tersebut tanpa bayar, akan lebih menyenangkan. Install Ubuntu Desktop? Bukan pilihan, tidak ada regulasi, tidak ada suruhan, tidak ada teladan, semua tidak pakai itu, instal driver printer sulit, sudah diinstal, kadang tidak berfungsi dengan baik.
Setelah komputer dengan program closed source ada di tangan pengguna, apakah pengguna melakukan update system? Belum tentu dilakukan walaupun telah terpikirkan, baru diinstal ulang, ekspektasinya aman, tidak ada virus, semuanya update. Apa yang terjadi bila belum dapat dipastikan update keamanan berhasil dilakukan? Maka tidak dapat dipastikan pula keamanan sistem telah mengikuti perkembangan keamanan sistem yang sesuai dengan risiko siber terkini. Bagaimana dengan closed source? Apakah ada patch yang mengacu kepada malware? Lumrahnya aplikasi closed source jika mekanismenya dalam mendapatkan tidak resmi, maka itu dinamakan ’aplikasi bajakan’. Aplikasi bajakan rentan terhadap malware, apalagi bilamana tidak ada pemutakhiran keamanan sistem. Maka penyelesaian untuk penggunaan closed source yakni penggunaan perangkat lunak dengan lisensi resmi.
Bilamana instansi tidak ada program perencanaan berkenaan lisensi yang rutin, maka mitigasinya dapat membudayakan penggunaan aplikasi open source. Atau rutin ganti perangkat keras.
Pertanyaan kunci berkenaan hal di atas yakni apakah open source telah mencukupi, atau segalanya tidak dapat berjalan jika tidak menggunakan closed source? Apakah dari sisi anggaran, lebih memadai untuk menggunakan open source, atau ada kepastian jangka panjang pendanaan untuk penggunaan closed source? Mengingat kendala utama berkenaan closed source yakni jatuh tempo lisensi.
5. Update Sistem
Pemutakhiran sistem cukup perlu dilakukan berkenaan keamanan sistem. Sistem lama, cukup menyusahkan untuk dibobol. Sistem terbaharukan, lebih sulit untuk dibobol. Update sistem yang dimaksud yakni update OS/ sistem operasi dan update aplikasi.
Pada sistem operasi server, misal Ubuntu Server, update dapat dengan menggunakan kombinasi
# apt update
Pada sistem operasi windows, anda cukup menemukan textfield Search pada taskbar anda, ketikkan “Update”. Pilih Check for updates.
Pada aplikasi berbasis framework (misal laravel), update dapat dilakukan dengan ekspresi commands
$ cd /path/ke/root/directory/aplikasi
$ composer update
Pada aplikasi berbasis CMS (misal wordpress), update dapat dilakukan dengan login ke dashboard, klik Dashboard > Updates.
Pada sistem android, anda dapat masuk ke pengaturan, tentang perangkat, anda dapat menelusuri tombol yang tersedia berkenaan versi perangkat lunak mobile anda.
Pada aplikasi play store, klik ikon/ logo akun anda (pojok kanan atas), pilih kelola aplikasi & perangkat. Pada bagian Update tersedia, pilih Update semua. Aplikasi terlalu banyak? Anda dapat mengurangi aplikasi dengan hapus aplikasi yang anda rasa perlu dihapus. Jika masih banyak, itulah beban kebutuhan/ keinginan anda.
Pertanyaan kunci berkenaan hal di atas yakni kapan terakhir kali anda update sistem/ aplikasi? Bila tidak ada rutinitas berkenaan update, ada atau tidak otomasi yang teruji berhasil dan anda gunakan untuk update berkala?
6. Gunakan Malware Scanner
Pada client-host, bilamana sistem diperbaharui secara berkala, maka normatif sistem akan melakukan pemutakhiran sistem malware removal. Sehingga, tanpa antivirus sekalipun, sistem memiliki lapisan keamanan tersendiri berkenaan mitigasi risiko malware.
Pada server-host, apabila cloud service telah ada pada kondisi manajemen mutu tertentu, bisa jadi anda telah mendapatkan fasilitas malware scanner untuk sistem server yang anda order. Yang mana pengguna hanya perlu melakukan akses pada layanan malware scanner untuk dapat memantau sistemnya. Namun tidak semua layanan hosting menyediakan fitur tersebut. Pengguna tetap dapat melakukan mitigasi risiko secara mandiri dengan pemasangan malware scanner/ removal dengan lisensi open source maupun closed source.
Pertanyaan kunci berkenaan hal di atas yakni ada atau tidak monitoring tools yang dapat anda gunakan kapanpun anda perlu untuk memantau eksistensi malware pada sistem anda?
7. Tutup Port yang Tidak Digunakan
Terkadang suatu sistem server dapat dengan mudah dilakukan port scanning, semisal dengan kombinasi pencarian web berikut
shodan.io/domain/nama-domain-anda
atau command berikut pada sistem server
$ netstat -tunlp
Mungkin dari sana anda dapat mengetahui port yang terbuka. Semakin banyak jalan masuk, maka semakin banyak jalan untuk attacker melakukan information gathering. Bila memang anda mampu menjamin semua port yang tidak diperlukan aman beserta rantai informasi aplikasi/ services yang menyertainya, maka tidak mengapa. Namun jika tidak, maka menutup port yang tidak digunakan sampai kapanpun, lebih dekat pada bijaksana.
Menutup port dapat dilakukan dari berbagai sisi. Sisi networking, sisi firewall, sisi sistem operasi. Akses pengguna mungkin akan terbatas pada networking dan firewall. Akses pengguna cenderung kepada layanan sistem operasi jika layanan yang diorder adalah VPS. Pada sistem operasi, untuk mengetahui status port atau protokol dapat dengan kombinasi
# ufw status
Jika status tidak aktif, dapat lakukan enable
# ufw enable
Untuk membuka port tertentu dapat menggunakan kombinasi
# ufw allow nama-atau-nomor-port
semisal
# ufw allow https
atau
# ufw allow 443
Untuk menutup port tertentu dapat menggunakan kombinasi
# ufw deny nama-atau-nomor-port
semisal
# ufw deny http
atau
# ufw deny 80
Keterangan lebih lanjut berkenaan port, dapat anda lakukan pencarian dengan kata kunci “well known port number”.
Anda dapat mencoba gunakan netstat untuk scan port anda. Identifikasi port yang dipaparkan sistem, apakah anda menggunakannya atau tidak. Bilamana lupa/ tidak mengetahui jenis protokol dari port, identifikasi melalui “well known port number”. Tutup port yang tidak digunakan dengan kombinasi command # ufw deny nama-atau-nomor-port.
Pertanyaan kunci berkenaan hal di atas yakni, apa port yang anda perlukan untuk menjalankan operasi sistem elektronik? Apa port yang anda inginkan untuk menjalankan operasi sistem elektronik? Apabila port yang anda inginkan ditutup, apakah memiliki dampak terhadap pemenuhan/ ekspektasi proses bisnis yang tersedia pada sistem elektronik?
8. Hapus Aplikasi
Apabila dirasa perlu, anda dapat menghapus aplikasi. Baik aplikasi yang tidak membawa pengaruh terhadap operasi sistem, maupun aplikasi yang tidak digunakan sampai kapanpun.
Pada sistem operasi server dengan distro Ubuntu, anda dapat menggunakan kombinasi kode berikut
# apt purge nama-aplikasi
# apt autoremove
semisal
# apt purge vim
# apt autoremove
Pertanyaan kunci berkenaan hal di atas yakni, apa aplikasi yang anda perlukan untuk menjalankan operasi sistem elektronik? Apa aplikasi yang anda inginkan untuk menjalankan operasi sistem elektronik? Apabila aplikasi yang anda inginkan ditutup, apakah memiliki dampak terhadap pemenuhan/ ekspektasi proses bisnis yang tersedia pada sistem elektronik?
9. Scan Aplikasi
Untuk scan aplikasi terhadap malware dengan target kata kunci tertentu, Anda dapat menggunakan kombinasi pencarian berikut
site:nama-domain kata-kunci-1
site:nama-domain kata-kunci-2
site:nama-domain kata-kunci 1 OR kata-kunci-2
semisal
site:aptikakutim.online slot
site:aptikakutim.online gacor
site:aptikakutim.online pinjol OR hacked by
Scan aplikasi menggunakan peramban web memudahkan untuk menemukan file atau path yang mengacu pada trigger dari malware. Malware dapat berawal dari file ekstensi *.php, *.css, *.js, dsb. Gunakan kode sumber terbuka melalui sumber resmi, atau gunakan kode sumber tertutup dengan lisensi resmi untuk meminimalisir keberadaan trigger malware sebab penggunaan kode sumber malware.
Untuk melakukan scan dari sisi sistem operasi, prosedur lebih panjang, serta kemampuan yang diperlukan adalah kemampuan tingkat lanjut. Namun jika ingin mencoba dengan sederhana, anda dapat melacak perubahan pada file dan direktori dengan kombinasi berikut
$ ls -alt -–full-time
Dengan kombinasi tersebut anda dapat melihat waktu perubahan dari file dan direktori. Bilamana ada hal yang mencurigakan, anda dapat telusuri file dan direktori tersebut dengan command
# cd path/menuju/direktori
misal
# cd /var/www/nama.domain.anda.tld
Trigger dan atau malware, lumrahnya memiliki waktu perubahan file/ direktori yang mencurigakan. Tidak sama dengan waktu perubahan file lain, juga lumrahnya tidak sama dengan waktu perubahan file dan direktori yang anda ubah, terkadang memiliki nama yang eyecatching, tidak familiar dengan penamaan file dan direktori sistem (framework).
Apabila menemukan, anda dapat melakukan isolasi dengan kombinasi
# tar -cvzf nama-malware.tar.gz /path/menuju/malware
Malware yang ‘dibungkus’ memudahkan IT forensik untuk menelusuri dan menangani malware. Setelah dibungkus, hapus malware dengan command
# rm -f /path/menuju/malware
Sistem yang sudah terserang, bisa jadi memiliki proses berkenaan malware yang masih berjalan, walaupun file trigger dari malware telah dihapus. Untuk memeriksa service dengan frekuensi kemunculan yang mencurigakan dapat gunakan command
# top
Lumrahnya nama proses yang digunakan malware bersifat repetitif, terkadang malware menggunakan resource yang cukup banyak, apakah itu resource perangkat keras, bandwidth, dsb.
Apabila mendapati, penanganan/ tindak lanjut berkenaan malware tidak dicantumkan pada artikel Pencegahan Risiko Malware. Apabila memungkinkan, serahkan saja pada IT forensik, hindari penanganan malware dengan kapasitas administrasi sistem operasi yang tidak terspesialisasi untuk IT forensik.
Pertanyaan kunci berkenaan hal di atas yakni, apakah anda telah melakukan scanning harian (hari kerja)? Dengan kata kunci minimal “slot”, ”gacor”, ”pinjol”, ”hacked by” apakah hasil scan mengindikasikan adanya malware? Bagaimana cara anda update kata kunci sesuai dengan tren malware terkini?
10. Lingkungan Operasi yang Berbeda
Mungkin sebagian menganut paham bahwa keterpaduan yakni semua ada dalam satu server, satu host, satu web server. Bagaimana jika yang satu itu terserang pada tingkat sistem operasi? Tingkat web server? Semua sistem dikorbankan? Maka relevansi terhadap sistem yang ’kecil’ (Monolith) cenderung lebih mudah mitigasi risikonya apabila diisolasi pada satu (virtual) server. Terkait sistem yang ’besar’, dengan keanekaragaman perilakunya, mungkin lebih akurat apabila menganut arsitektur micro services. Tentu dua jenis arsitektur ini berbeda. Monolith lebih tepat untuk sistem yang sederhana. Sedangkan micro services lebih tepat untuk sistem dengan fitur yang fungsinya terpecah-pecah dalam suatu bagian parsial dari sistem. Bisa jadi suatu sistem, beberapa docker lebih tepat untuk aplikasi dengan arsitektur micro services, dan satu VPS lebih tepat untuk satu aplikasi monolith atau beberapa aplikasi monolith yang merupakan satu kesatuan tak terpisahkan (misal terintegrasi/ berdependensi). Sehingga apabila ada terjadi risiko siber, maka risiko itu terisolir pada rangkaian sistem itu saja.
Berkenaan kendala keterpaduan aplikasi monolith dan silo datanya. Belum ditemukan penyelesaian yang lebih baik dari soft-copy panduan dan aktor pembimbing yang menyertai panduan berkenaan standarisasi create, read, update dan delete menggunakan Restful-API untuk berbagi pakai data serta standarisasi keamanannya.
Pertanyaan kunci berkenaan hal di atas yakni, apakah aplikasi anda merupakan aplikasi dengan arsitektur monolith atau micro services? Sudahkah anda menyediakan resource yang memungkinkan mitigasi risiko/ isolasi yang memadai untuk potensi risiko operasi sistem elektronik (semisal satu VPS untuk satu aplikasi monolith atau suatu kesatuan sistem yang saling terintegrasi/ berdependensi)? Apakah Unit Kerja yang berkenaan dengan operasi aplikasi menyediakan sekurang-kurangnya satu SDM untuk menjadi simpul jaringan pengelolaan teknis sistem elektronik perwakilan Unit Kerja?
11. Permission Access
Diasumsikan anda seorang black hat hacker dengan misi yang diberikan kepada pihak yang membayar agar meletakkan trigger malware pada root directory aplikasi berbasis web, apa harapan anda? Maka harapannya root directory aplikasi dapat ditulis (writeable). Maka lapisan keamanan akan bertambah apabila direktori dan sub direktori dapat dikondisikan seoptimal mungkin agar tidak writeable. Lumrahnya direktori yang harus writeable yakni berkenaan storage/ file.
Command berkenaan permission access yang cukup lumrah untuk diberlakukan pada direktori beserta sub direktorinya yakni
$ sudo chmod -R 755 nama-direktori
Sedang untuk file, sebagian sistem dapat memberlakukan 644.
Pada 755, ada tiga digit. Digit pertama adalah untuk root, digit kedua untuk user group, digit ketiga adalah untuk publik.
Perhitungan untuk satu digit, yakni rwx (read-write-executable). Read bernilai 4, write bernilai 2, sedangkan executable bernilai 1. R+W+X = 4+2+1 = 7.
7 = 4+2+1 (readable, writeable, executable)
6 = 4+2. (readable, writeable)
5 = 4+1 (readable, executable)
4 = 4 (readable)
Berikut contoh serangkaian permission yang dapat dituliskan dalam satu file otomasi untuk operasi web framework. Misal framework yang digunakan laravel dan file otomasi kita beri nama automation.sh.
cd /var/www/path/ke/root/directory
sudo chown -R $USER:www-data .
sudo usermod -a -G www-data $USER
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache
Anda dapat mengeksekusi file otomasi tersebut dengan command sh, misal
$ sh ./automation.sh
Pertanyaan kunci berkenaan hal di atas yakni, apakah anda menggunakan framework, CMS, atau native web programming? Pada sistem anda, direktori apa saja yang memerlukan writeable permission?
12. Ownership
Dalam kaitannya dengan kepemilikan suatu file dan atau direktori web server, sistem linux mengenali 3 kepemilikan. Satu, root. Dua, user/grup. Tiga, www-data.
Bilamana privilege yang sedang digunakan adalah root, sedang command untuk konfigurasi yang diberikan adalah $USER, maka user akan didefinisikan sebagai root. Contoh command
# chown -R $USER:www-data .
Bilamana privilege yang sedang digunakan adalah user/group, dan command untuk konfigurasi yang diberikan adalah $USER, maka user akan didefinisikan sebagai user/group. Contoh command
$ sudo chown -R $USER:www-data .
Maka privilege yang sedang digunakan berpengaruh terhadap ownership apabila menggunakan inisialisasi $USER. Tanda paling mudah untuk mengenali privilege yang sedang aktif adalah simbol pada awal command. $ untuk user privilege dan # untuk root privilege. Cara lain untuk mengenali anda sebagai user atau root dengan eksekusi command whoami.
Pada CMS (misal wordpress) dengan file manager yang diatur manual, ownership yang diperlukan yakni www-data pada direktori /wp-content/uploads.
$ sudo chown -R www-data /path/ke/uploads
Namun pada framework (misal laravel) terkadang diperlukan ownership sebagai user/group untuk FTP. Sehingga user perlu ditambahkan ke user/group dari web server.
$ sudo usermod -a -G www-data $USER
$ sudo chown -R $USER:www-data /path/ke/root/directory
Pertanyaan kunci berkenaan hal di atas yakni, apa sistem yang anda gunakan? Apa direktori yang memerlukan pengaturan ownership? Apakah hanya pada level direktori itu atau perlu pengaturan secara rekursif -R?
13. Periksa Login Terakhir
Gunakan command
$ last
Sistem akan menampilkan daftar login. Bilamana anda login terkhir jumat siang dan weekend tidak merasa login, maka seharusnya tidak ada login antara jumat malam hingga anda login lagi. Bilamana anda mendapati adanya login yang mencurigakan, anda dapat cek commands yang sudah dilakukan sebelumnya (tekan tombol atas) dan atau periksa waktu perubahan direktori dengan command ls -alt --full-time.
Dalam kasus serangan malware, bisa jadi tidak ada riwayat login, namun ada jejak waktu perubahan file/ direktori.
Pertanyaan kunci berkenaan hal di atas yakni, kapan anda login terakhir? Apakah ada login di antara waktu anda login akhir-akhir yang bukan anda melakukannya? Apa command dan apa waktu perubahan file/ direktori yang dapat anda identifikasi pada sesi login mencurigakan tersebut?
14. SSH Hardening
SSH (Secure Shell Protocol) dapat diartikan sebagai protokol, perangkat lunak, layanan. Digunakan untuk melakukan remote login ke sistem komputer. Dalam praktiknya, bilamana tidak ada attacker/ black hat di dunia ini, tidak ada pengaturan yang perlu dilakukan berkenaan keamanan SSH, tidak ada kerumitan apapun berkenaan keamanan siber. Namun dikarenakan tidak adanya garansi yang menjamin bahwa pasti tidak ada attacker/ black hat yang mungkin hidup di dunia ini, maka kita asumsikan attacker/ black hat hacker itu ada.
Ada banyak metode untuk penguatan keamanan SSH, namun pada tulisan ini hanya dibahas empat hal. Yang pertama, disable permit root login. Yang kedua, ganti port standar SSH. Yang ketiga batasi percobaan login. Yang keempat pemanfaatan authentication key.
Pertama, disable permit root login. Terkadang untuk pengaturan awal SSH, root password telah diatur pada saat order atau pengaturan awal layanan VPS. Diasumsikan password tersebut bocor. Maka kredensial kehilangan dua poin keamanan. Yang pertama username, karena root itu lumrah diketahui sebagai nama user, dan root itu anonymous. Berbeda halnya jika login sebagai user terlebih dahulu kemudian login sebagai root, maka untuk dapat menggunakan sudoer privilege ia harus login dengan nama akun yang terang terlebih dahulu baru kemudian ia diidentifikasi sebagai root. Maka root login secara normatif sebaiknya digunakan untuk membuat user saja pada pengaturan awal VPS, lalu kemudian dilakukan disable. Adapun command sebagai berikut.
$ nano /etc/ssh/sshd_config
Tekan kombinasi tombol Ctrl+W, ketikkan PermitRootLogin, enter. Apabila anda telah sampai pada baris PermitRootLogin, ganti nilai menjadi no.
...
PermitRootLogin no
...
Kedua, ganti port standar SSH. Setiap layanan, memiliki jalan akses. Jalan akses itu kita sebut sebagai port. Setiap port itu memiliki label. Labelnya adalah nomor. Aliasnya adalah nama. Label bawaan dari port SSH yakni 22 namun dapat diubah. Aliasnya adalah SSH/ ssh. SSH memiliki sekurang-kurangnya tiga kekuatan keamanan. Yang pertama yakni password, yang kedua yakni nomor port, yang ketiga yakni nama user. Penggunaan port standar rentan terhadap aktivitas attacker yang kerap disebut sebagai bruteforce. Outcome dari bruteforce yakni password. Jadi pengubahan port ke yang bukan port standar tak hanya menguatkan keamanan dari sisi penamaan port agar tak mudah ditebak attacker, melainkan juga penguatan pada sisi password dari aktivitas bruteforce. Untuk pengaturan, masih menyambung dari konfigurasi di atas, sehingga baris perubahan pada /etc/ssh/sshd_config kurang lebih sebagai berikut.
...PermitRootLogin no...Port nomor-port-baru...
Bagaimana menentukan nomor port baru? Kembali identifikasi nomor port baru pada “well known port numbers”. Apakah nomor port baru yang anda tentukan secara acak menyamai nomor port yang telah ada? Jika ya, maka ganti nomor port ke port yang tidak terdata pada tabel “well known port numbers”.
Ketiga, batasi Percobaan Login. Anda dapat membatasi percobaan login dengan opsi MaxAuthTries. Nilai default dari opsi tersebut adalah 6. Namun anda dapat menguranginya. Sehingga perubahan yang dilakukan pada /etc/ssh/sshd_config kurang lebih sebagai berikut.
...
PermitRootLogin no
...
Port nomor-port-baru
...
MaxAuthTries 3
...
Apabila anda belum menyimpan dan belum menutup /etc/ssh/sshd_config, tekan kombinasi tombol Ctrl+O, Ctrl+M, Ctrl+X. Bila gagal simpan, maka untuk simpan memerlukan sudoer privilege (gunakan $ sudo ... atau # ... ).
Restart service
# systemctl restart ssh
Lalu periksa pada firewall, apakah new port telah dibuka atau belum
# ufw status
Bila port belum dibuka, maka buka dengan command
# ufw allow nomor-port-baru
Bila ingin tutup port lama, maka tutup dengan command
# ufw deny 22
Bila ingin menghapus baris yang tidak digunakan, maka hapus baris, semisal
# ufw delete deny 80
atau
# ufw delete allow 80
Tes koneksi SSH dengan nomor port baru.
Keempat, pemanfaatan authentication key. SSH key adalah mekanisme otentikasi yang digunakan dalam protokol SSH, menggantikan kebutuhan akan kata sandi untuk login ke server.
Cukup penting sebelum melakukan implementasi percobaan ini agar anda login ke laman user tenant layanan hosting anda masing-masing dan take snapshot VM yang anda kelola dengan kondisi kontrol akses SSH-nya masih dapat dilakukan tanpa key authentication untuk menambah opsi rencana rescue mode sebagai antisipasi bilamana terjadi insiden semisal konfigurasi PasswordAuthentication tersimpan dengan nilai no dalam kondisi key authentication atau passphrase belum berhasil untuk dijalankan.
Buat SSH Key Authentication
$ ssh-keygen -t nama -C "usermail@mail.com"
Ikuti instruksi, masukkan passphrase jika ingin proteksi ekstra.
Salin public key ke server.
$ ssh-copy-id -i pubkey user@ip
Verifikasi bahwa Pubkey yang telah disalin ke server memenuhi ketentuan berikut: per Pubkey di server hanya satu baris utuh tanpa spasi/enter tambahan (sama persis seperti Pubkey yang di-generate pada client host).
Konfigurasi lain yang mungkin perlu dilakukan pada /etc/ssh/sshd_config
...
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
#PasswordAuthentication no
...
Kemudian restart SSH
# systemctl restart ssh
Konfigurasi permission access dan ownership yang mungkin diperlukan
# chown -R user:user /home/user
# chmod 700 /home/user
# chmod 700 /home/user/.ssh
# chmod 600 /home/user/.ssh/authorized_keys
Dalam praktiknya konfigurasi pada VM nyata terkadang tidak semudah praktik virtualisasi. Bisa jadi ada kendala-kendala konfigurasi. Untuk itu cukup perlu untuk mengenal mekanisme tracing atau IT forensik yang diperlukan untuk melihat suatu log proses tertentu.
Dari sisi client-host, opsi -vvv bisa jadi membantu sys-admin atau chatbot dalam menganalisis permasalahan, contoh format command
$ ssh -vvv -i privatekey user@ip
Probabilitas tinggi baris log yang diperlukan untuk ditelaah yakni baris log yang berhubungan dengan proses authentication.
Dari sisi server-host, command berikut dapat digunakan untuk melihat log yang ada setelah dilakukan percobaan SSH login.
# journalctl -u ssh | tail -n 30
atau
$ cat /var/log/auth.log | tail -n 30
Bilamana semua konfigurasi key authentication yang diperlukan telah diimplementasi, telah diuji, telah dipastikan berhasil (sistem dapat login tanpa password, atau dapat login dengan passphrase tanpa meminta password lagi), maka anda dapat mencoba mengaktifkan baris konfigurasi PasswordAuthentication no pada /etc/ssh/sshd_config. Kemudian restart SSH.
15. .htaccess
Storage merupakan satu jalan raya bagi para cracker atau hacker untuk meletakkan malware. Oleh sebab itu pada sistem yang besar, penanganan file memiliki serangkaian panjang standarisasi dan strategi hanya untuk penanganan file, entah menggunakan file server khusus, mekanisme bucket, pemanfaatan cloud storage (cloud services), dsb. Namun aplikasi daerah memiliki karakter yang berbeda dengan aplikasi besar atau aplikasi nasional, yang mana scope area-nya kecil dan cakupan user-nya sendiri sedikit dengan pertumbuhan data yang kecil. Sehingga menyebabkan sejumlah aplikasi daerah tidak memiliki tuntutan untuk penerapan strategi storage yang kompleks. Artinya pada aplikasi dengan karakteristik sebagaimana dimaksud, tidak bermasalah jika storage ditempatkan pada server yang sama dengan aplikasi web. Sebab memang penerapan storage pada tempat yang sama atau berbeda dengan server aplikasi, tidak membawa perbedaan signifikan dari sisi traffic untuk coverage area dan target user sebagaimana aplikasi daerah.
Hal tersebut menjadikan cracker atau hacker menjadi lebih mudah lagi dalam melancarkan serangan atau aksinya. Kendatipun demikian, ada sedikit konfigurasi sederhana yang dapat dilakukan masing-masing pengelola teknis aplikasi yang memungkinkan semua ekstensi file maupun malware dapat ditampung/dikoleksi pada storage, namun dapat diminimalisir dampak negatifnya, yakni dengan konfigurasi .htaccess sebagai berikut (/public/storage/.htaccess).
<FilesMatch "\.(php|js|sh|py|html|htm|hta|xhtml|svg|exe|bat|pl|cgi|rb|jar|conf|env|ini|sql|log|json|xml)$">
deny from all
</FilesMatch>
Implementasi pengaturan ini mungkin akan menonaktifkan semua fungsi ekstensi sebagaimana tertera, sehingga bagi sistem yang kurang optimal dalam secure development pada strategi resource melalui CDN/konteks CSP (content security policy), mungkin perlu melakukan strategi dan konfigurasi ulang agar resource dengan ekstensi terkait dapat diakses melalui sumber yang relevan, semisal resource provider untuk keperluan CDN, dst. Untuk penanggulangan sementara atas CSP yang kurang optimal dapat juga mengeliminasi ekstensi yang mana file tersebut sedang diperlukan dan mengembalikannya jika aplikasi telah selesai digunakan.
Konfigurasi .htaccess sebagaimana tertera tidak berlaku secara rekursif jika berdiri secara tunggal, sehingga jika ingin menggeneralisir hingga pada kedalaman sub direktori, diperlukan pengaturan (override) dari sisi konfigurasi web server, semisal dengan pola berikut (*.conf).
...
<Directory /path/to/storage>
Options -Indexes # prevent directory listing
AllowOverride All # override konfigurasi
</Directory>
...
Dalam kondisi pencegahan malware sampai pada tingkat paranoid, pencontekan gaya honeypot di atas bisa jadi kurang optimal. Untuk optimalisasi dapat cegah masuknya malware melalui validate logic dari sisi pemrograman (lumrahnya pada class di controller), semisal mime dsb. Konsekuensinya, pihak keamanan yang terkait dengan aplikasi tidak mendapatkan artefak malware apapun untuk dipelajari, sebab tidak tertampung pada storage.
Pada akhirnya, selama masih pada cakupan dunia, tidak ada kondisi “aman hakiki”. Untuk mengukur, kita hanya dapat membayangkan gradasi grafik serta angka katakanlah satu sampai seratus. Hal-hal legal yang dapat dilakukan untuk mendekati seratus, adalah benefit untuk dikerjakan. Bilamana ada hal yang dapat dilakukan untuk menambah skor keamanan sebanyak 0,001, maka itu lebih baik daripada 0. Skor 100 untuk pengukuran kita, bisa jadi tidak lebih dari skor 50 untuk entitas dengan resource dan kapasitas SDM tingkatan lain yang lebih tinggi. Skor 101 hari ini, bila tidak ada pembaharuan, tidak ada adaptasi atau tidak ada peningkatan, bisa jadi tidak lebih dari 50 di tahun depan.
Demikian artikel terkait Keamanan Aplikasi – Pencegahan Risiko Malware. Semoga dapat membantu dalam pengembangan dan perawatan sistem elektronik lebih aman serta membantu memilih lingkungan operasi sistem elektronik yang relevan dengan beban risiko siber sistem elektronik anda.