1 Bab IV Konfigurasi Ossim dalam Deteksi Malware 4.1 Sistem Deteksi Statis Snort Deteksi Malware dalam Jaringan Internal Dalam paket instalernya, Snor...
Deteksi Malware dalam Jaringan Internal Dalam paket instalernya , Snort tidak dilengkapi dengan rules untuk mendeteksi para penyusup yang mencoba masuk ke dalam jaringan internal. Oleh karena itu, administrator musti melengkapi Snort dengan rules secara manual, dengan cara mendownload rules yang tersedia di situs resmi mau pun tidak resmi pengembang program Snort. Di situs-situs tersebut, telah tersedia juga rules guna mendeteksi malware (signature virus.rules). Akan tetapi rules tersebut masih sangat mendasar dan masih sangat fokus pada nama-nama file/virus serta masih sangat fokus pada signature untuk malware non-biner atau non-spesifik. Hal ini membuat para pembuat malware lebih mudah mengatasi signature tersebut dengan cara mengubah nama file atau virus sehingga dengan mudah malware buatannya masuk masuk ke dalam jaringan internal untuk menyerang semua personal komputer. Hal ini sudah dilakukan oleh pembuat worm W32/Netsky.p dan W32/Bagle.az, seperti yang dapat dilihat dari sekian banyak varian dengan nama file yang berbeda-beda[8].
4.1.1.1 Konfigurasi Deteksi Malware dengan SNORT
Ambil suatu malware sebagai sampel, kemudian buka file malware tersebut ke dalam editor heksa jika sampel malware tersebut menggunakan pengkodean biner atau buka dalam editor teks jika sampel tersebut masih dalam bentuk MIME pada email. Langkah berikutnya memeriksa entrails dan menganalisa pendekatan apa yang dapat diaplikasikan sebagai pattern yang akan digunakan untuk proses pendeteksian.
34
Jika malware merupakan polymhorphic atau menggunakan pads pada dirinya sendiri dengan random garbage instruction untuk mengakali MD5 hashes atau dienkripsi (seperti pasword yang memproteksi file zip), hanya dibutuhkan satu signature untuk mendeteksinya. Jika malware yang diperiksa menggunakan vector lain untuk penyebarannya, seperti email atau peer-to-peer (P2P), beberapa signature mungkin diperlukan untuk mendeteksinya. Oleh karena itu seorang administrator musti dapat menulis dan memodifikasi rule atau signature untuk mendeteksi malware sesuai dengan kebutuhannya.
Melihat isi Malware Sebagai sampel dari jenis modern multi-vector worm, W32/Netsky.p@MM yang dapat menyebar melalui email dan Peer to peer (P2P). Langkah-langkah membuat signature untuk mendeteksi worm tersebut, yang pertama adalah dengan memeriksa malware tersebut, apakah malware tersebut statik dengan menggunakan algoritma hashings seperti MD5 atau SHA1. Diperlukan juga untuk mentranslasikan attachment jika mereka diterima dalam bentuk MIME via email.
Langkah yang sama juga dilakukan pada attachment yang sudah ditranslasikan. Jika attachment dalam bentuk file zip, file tersebut perlu diekstrak dan mengulangi langkah-langkah translasi lagi. Seperti pemikiran boneka kayu rusia, di dalam boneka terdapat boneka yang lebih kecil, di dalam boneka kecil tersebut masih ada boneka yang lebih kecil lagi, begitu seterusnya sampai tidak bisa dibuka lagi. Karena dalam beberapa kasus malware, seperti keluarga Bagle menggunakan teknik seperti diatas untuk mengakali pemeriksaan oleh anti-virus.
Malware dengan Pengkodean MIME Dalam kasus ini, W32/Netsky.p, malware tersebut merupakan image biner yang statik dan MIME yang menstranlasikan image biner juga statis.
Langkah selanjutnya adalah melihat source code virus dalam editor heksa atau teks, kemudian memilih string MIME yang sesuai untuk mendeteksi virus berkodekan
35
MIME yang penyebarannya melalui email. String yang cocok sebaiknya dapat menampilkan setidak-tidaknya 30 baris pertama dari attachment dengan pengkodean MIME pada email. Akan tetapi untuk meminimalisasikan kemungkinan terjadinya falsepositive atau false-negative dalam pengimplementasikan suatu sigaature, sebaiknya digunakan minimal satu baris penuh terdiri dari 72 karakter.
Kemudian signature dapat ditampilkan sebagai berikut:
Berikut ini akan dijelaskan bagian-bagian komponen dari signature di atas.
Bagian pertama ini memerintahkan Snort untuk membangkitkan sebuah alert ketika ditemukan kecocokan signature dengan skrip yang terdapat pada paket TCP yang diperiksa. Signature diatas digunakan untuk mendeteksi malware [email protected]. Selain paket TCP, Snort juga dapat mendeteksi paket UDP dan ICMP akan tetapi perlu tambahan protokol dalam aplikasi rule-nya.
Argumen diatas memberi perintah untuk hanya mengaplikasikan rules pada datadata pada paket yang berasal dari luar jaringan [$EXTERNAL_NET] masuk menuju ke dalam jaringan internal [$HOME_NET].
Rule ini hanya untuk mengawasi trafik yang datang dari jaringan eksternal atau internet menuju jaringan internal tanpa memperhatikan trafik yang berada di dalam jaringan sendiri atau dari jaringan internal menuju ke jaringan luar.
$EXTERNAL_NET dan $HOME_NET merupakan variabel yang dapat didefinisikan oleh administrator Snort. Keyword ‘any’ mendefinisikan bahwa asal paket dari luar jaringan sendiri dan jaringan sendiri, boleh dalam port berapa saja.
36
Ketika suatu isi dari paket data ditemukan kode yang sesuai dengan signature pada pengkodean MIME maka snort akan mengirimkan pesan teks W32.NetSky.p@mm MIME ke konsol, log atau database, tergantung dari konfigurasi yang telah diatur oleh administrator. Alert juga dapat diatur untuk secara otomatis menjalankan program lain, seperti pager tool atau menggunakan fungsi pesan dalam jaringan untuk memberikan alert ke administrator secepatnya.
Jika skrip atau kode di atas ditemukan dalam suatu paket data maka, alert akan dibangkitkan.
Bagian ini mendeskripsikan di kelas mana log akan disimpan. Berdasarkan rule diatas, log akan disimpan dalam kelas ‘misc-activity’. Tipe kelas tersebut dapat diset dengan nama kelas yang lain, seperti ‘malware’,’worm-traffic’ dan lainnya tergantung dari keperluan administrator.
Bagian terakhir dari rule adalah argumen ‘rev’, stetmen ini bertujuan untuk memonitor revisi daripada rule itu sendiri agar jelas ‘riwayat’ nya. Sehingga seorang administrator dapat mengetahui berapa kali rule telah dimodifikasi.
Malware dengan Pengkodean Biner Setelah dijelaskan secara gamblang bagaimana membuat rules malware dalam kode MIME yang menyebar melalui email, berikutnya akan dijelaskan bagaimana membuat signature dengan virus yang datang dengan biner, seperti worm share-crawling.
Tidaklah mengherankan apabila dilakukan langkah-langkah yang sama dengan di atas ketika administrator mencoba untuk membuat signature heksa pada virus biner. Dalam kasus ini, diperlukan editor heksa untuk melihat source code dari virus sehingga 37
dapat ditentukan string signatures heksa yang cocok dengan virus biner yang menyebar melalui P2P.
Dengan editor heksa dapat dibuat rules sebagai berikut.
Suatu signature minimal terdiri dari 32 karakter heksa yang dipisahkan dengan spasi di tiap-tiap karakternya.
Perbedaan utama isi dari signature antara malware
berkode MIME dengan HEX, signature heksa diawali dan ditutup dengan simbol ‘ | ’ (broken pipe) didalam simbol ‘ ” ’ (double quotes) sedangkan signature MIME hanya diawali dan ditutup oleh simbol ‘ ” ’ (double quotes) saja.
Teknik Reversal
Rule untuk W32/netsky.p yang telah dibahas sejauh ini, hanya mendeteksi ketika virus tersebut datang dari jaringan eksternal (internet) ke jaringan internal. Snort juga dapat memeriksa isi data pada paket yang berjalan dua arah pada waktu yang bersamaan, dengan mengubah bagian dari rule sebelumnya :
Rule dapat diubah menjadi seperti di bawah ini apabila administrator ingin Snort memeriksa paket yang keluar dari jaringan internal menuju jaringan eksternal.
Atau menjadi seperti berikut ini jika ingin memeriksa paket secara dua arah pada waktu yang bersamaan.
38
Keyword yang berguna lainnya adalah ‘flow’. Argumen tersebut dapat digunakan untuk membatasi rules hanya kepada trafik klien dan server seperti di bawah ini:
Rule di atas hanya diaplikasikan jika sebuah klien telah membentuk koneksi dengan server (dalam hal ini POP3 server) dan paket data yang diperiksa hanya paket data yang diterima dari server. Contoh diatas merupakan salah satu rules orisinil Snort pada ‘virus.rules’. Cara di atas, sangat ideal untuk menghadapi malware yang dapat meng-update dirinya sendiri, seperti keluarga worm Bagle [8].
Snort dengan PERL Compatible Reguler Expression (PCRE)
Seperti yang telah ditulis di atas, dalam menghadapi serangan malware dibutuhkan lebih dari satu pendekatan dalam membuat signature. Jika dalam contohcontoh di atas dibahas mengenai virus dengan pengkodean MIME atau biner, selanjutnya akan dibahas pendekatan melalui struktur dari sebuah header pada email.
Dalam sampel ini, digunakan keluarga dari MyDoom dan Bagle. Keluarga ini memiliki struktur header yang cukup unik. Sehingga administrator dapat mendeteksi keluarga worm tersebut cukup dengan melihat struktur header tanpa perlu melihat signature yang terdapat pada attachment email-nya.
Rules diatas digunakan untuk mendeteksi kontruksi email yang terinfeksi MyDoom, walaupun file tersebut sudah rusak dan tidak bisa dibuka. Sampai saat ini, pembuat MyDoom belum mencoba untuk mengganti header email.
39
Dari rule di atas dapat dilihat bahwa pada setiap string PCRE harus diawali dan diakhiri dengan simbol ‘ / ‘.
Rule diatas memerintahkan Snort untuk memeriksa string ‘X-MIMEOLE: Produced By Microsoft MimeOLE V6.002600.000’. Simbol ‘ \ ‘ digunakan untuk memberitahu mesin PCRE bahwa karakter selanjutnya dibaca sebagai karakter bukan sebagai perintah.
Baris di atas meminta Snort menggunakan fungsi PCRE untuk mencari string yang mengandung ‘boundary=’ ; memiliki minimal 4 simbol ‘ – ‘ ; ‘=_NextPart_000_’ ; 4 digit ‘\d{4}’ dengan simbol ‘ _ ‘ ; 8 karakter apa saja ; simbol ‘ .’ ; 8 karakter apa saja. Urutan pada rule tersebut sangat berpengaruh.
Rules di atas memerintahkan Snort menggunakan fungsi PCRE untuk menemukan baris kode yang mengandung string ‘filename=’ ; simbol ‘ “ ‘; karakter apa pun kecuali spasi ; karakter apapun minimal terdiri dari 1 karakter tanpa batas maksimum karakter; simbol ‘ . ‘; dan file dengan ekstensi sesuai dengan yang disebutkan pada rule.
Setelah dijelaskan sedikit pengenalan tentang PCRE, berikutnya akan dibahas rule yang digunakan untuk mendeteksi worm Bagle.
Rule di atas dipercaya sangat ampuh dalam mendeteksi kontruksi email Bagle dan MyDoom. Walaupun terhadap varian terbaru dari keluarga mereka.
Administrator juga dapat menggunakan teknik tersebut untuk mendeteksi attachment pada email dengan rule sebagai berikut:
40
Rule diatas tidak menge-blok semua jenis ‘bad extensions’ , hanya sebagian kecilnya saja. Tetapi administrator dapat menambahkan jenis-jenis lainnya sesuai dengan keperluan.
Akan tetapi, penggunaan banyak perintah PCRE akan menambah kebutuhan sumber daya prosesor secara signifikan daripada menggunakan rule yang sederhana.
Snort juga dapat membangkitkan alert apabila pada trafik web ditemukan suatu signature. Di bawah ini adalah contoh rule untuk trafik web.
Rule tersebut hanya akan memicu alert apabila konten dalam web mengandung skrip ‘/readme.eml’ dalam ukuran huruf apa pun (huruf besar, kecil atau campurannya). Rules ini merupakan solusi yang ideal untuk mengahadapi malware yang dapat mendownload dan meng-update komponen secara otomatis dari web untuk melakukan “tugas”nya secara sempurna, seperti W32/Bagle.az@MM atau Downloader-PU [8].
Berikut ini akan dijelaskan beberapa argumen pada rule diatas:
Nocase Memerintahkan Snort untuk mengacuhkan ukuran huruf yang terdapat di dalam konten web, bisa berupa huruf besar, kecil maupun campurannya. Hal ini untuk meminimalisasi terjadinya false-negative.
Uricontent Argumen ini memerintahkan Snort hanya memeriksa pada field URL yang telah dinormalisasikan. Sehingga hanya memeriksa string teks yang simpel pada URL. Karakter yang tidak sesuasi dengan standar akan diacuhkan, seperti ‘%c0’ dan lainnya. 41
Reference Argumen ini memperbolehkan administrator untuk memasukkan sebuah link ke sebuah halaman web untuk memperoleh informasi tambahan mengenai malware.
Flags Argumen ini memerintahkan Snort untuk hanya memeriksa paket data yang pada headernya terdapat bit flag TCP yang aktif.
Dsize Argumen ini digunakan untuk memeriksa ukuran payload dari paket. Hal ini sangat berguna untuk memantau paket yang berlebihan ukurannya seperti pada serangan Buffer overflow.
Keyword ‘sid’ digunakan untuk mengidentifikasikan signature yang spesifik. Akan tetapi, sebelum menomori signature sendiri, ada beberapa hal yang musti diketahui.
Pendekatan melalui Header Email Beberapa contoh malware biasanya menyebar dalam suatu kumpulan atau menggunakan proses polymorphism yang halus, seperti menambah teks random lain ke dalam file untuk mengakali MD5 atau fungsi hash yang lainnya [9].
Sampel terenkripsi, dalam konteks paper ini, merupakan file zip yang diproteksi dengan pasword sebagaimana sering dilihat pada varian Bagle. Pada varian Bagle, biasanya menggunakan pasword text plain pada badan email dan juga menggunakan trik pasword gambar untuk mencoba memperlambat atau menghentikan scanner anti virus dari proses men-scan file yang dienkripsi dengan menggunakan proteksi pasword pada file zip [8,10]. 42
Untuk
itu, sebaiknya administrator mengubah cara mendeteksi worm. Tidak
hanya dengan memeriksa bagian attachment tetapi juga dengan memeriksa pembuatan header email.
Worm dalam Jaringan Snort sangat berguna untuk mendeteksi, melakukan aktivitas trace, dan mengeblok worm yang menyebar melalui jaringan yang belakangan ini menjadi noise pada internet.
Walaupun pengembang Snort tidak lagi menyuplai signature-signature ‘virus.rules’ pada paket bundel produk mereka, mereka masih menawarkan signature yang dapat digunakan untuk mengidentifikasi worm yang dapat berjalan sendiri ketika dilihat melalui Outlook atau masuk ke dalam sistem komputer melalui DCOM, LSASS, atau GDI. Contoh rule seperti di bawah ini:
Blocking dengan IDS Pada bagian awal dari paper ini, telah dibahas tentang perintah ‘alert’, yang akan mengirimkan alert ke log Snort, Syslog, database atau tempat penyimpanan lain sesuai dengan konfigurasi administrator jika menemukan sebuah signature cocok.
Terdapat beberapa pilihan ketika administrator menggunakan ‘flexresp’ [Flexible Response] ketika signature yang cocok ditemukan, seperti kemampuan untuk menutup suatu sesi, juga pada originator, tujuan dari suatu koneksi maupun keduanya pada saat yang bersamaan. Keuntungan dari kemampuan ini adalah administrator dapat menghentikan proses infeksi secara langsung.
43
Rule diatas akan memutuskan hubungan antara sumber dan tujuan dari IP address ketika signature yang cocok ditemukan. Kemampuan tersebut musti diimplementasikan dengan hati-hati karena dapat menimbulkan masalah pada beberapa aplikasi, terutama jika terjadi masalah false-positive dengan signature itu sendiri. Akan tetapi, menggunakan fitur tersebut akan menjalankan Snort menjadi Intrusion Prevention System (IPS) dari pada IDS.
Kekurangan Snort Bagian ini akan menjelaskan beberapa kemungkinan terjadinya masalah saat menjalankan Snort. Kesalahan ini bukan terletak pada pengembang dalam memproduksi snort, akan tetapi kesalahan ini terjadi karena signature atau rules yang bermasalah dalam proses pengimplementasiannya. Kesalahan pada Snort, dibagi menjadi 2 katagori yaitu : False Positive dan False Negatif.
False Positive False-positive terjadi ketika alert dibangkitkan oleh file yang bukan merupakan suatu yang aktivitas mencurigakan tetapi dianggap oleh Snort merupakan sesuatu yang mencurigakan. Dengan kata lain, Snort menganggap ada sesuatu yang tidak ada. Kesalahan jenis ini bukan lah masalah yang besar. Karena yang dirugikan oleh kesalahan ini hanya administrator yang disibukkan dengan alarm-alarm palsu. Tetapi hal tersebut tetap saja mengganggu.
Untuk meminimalisasi terjadi nya false positive, hal-hal berikut musti dihindari dalam proses implementasi sebuah rule: •
Binary signatures kurang dari 20 karakter.
•
Signature yang digunakan dimulai dari awal kode MIME atau file biner.
•
Tidak melakukan ujicoba pada sampel dan file dengan struktur yang sama.
•
Satu perintah PCRE dengan beberapa pola teks.
•
Menggunakan nama file atau attachment sebagai signature.
Dan berikut ini beberapa hal yang dapat mengurangi masalah false-alarm: 44
•
Buat signature yang cukup panjang untuk MIME atau file biner, minimal 32 karakter untuk biner dan 72 karakter untuk kode MIME.
•
Selalu menguji coba dengan file yang terinfeksi malware juga dengan file yang tidak terinfeksi.
•
Jika memungkinkan menggunakan konten yang cukup banyak, gunakan statement atau perintah lain untuk membatasi pemeriksaan.
•
Jika administrator menggunakan signature berbasis PCRE, dibutuhkan semakin banyak uji coba terhadap file yang terinfeksi maupun yang tidak.
False Negatives False negative terjadi dalam keadaan dimana alert tidak dibangkitkan ketika ada file yang mencurigakan dan dapat di koreksi dengan snort signature yang sudah ada. Snort menganggap tidak ada sesuatu yang sebenarnya ada.
Kesalahan ini merupakan masalah yang serius, karena dapat diartikan beberapa signature kurang bagus dan tidak dapat menangkap file yang terinfeksi yang mustinya dapat teridentifikasi. Dalam beberapa kasus, hal ini cukut sulit untuk dipecahkan terutama apabila malware diproteksi dengan enkripsi dan sangat kompleks. Untuk memecahkan masalah seperti ini, biasanya digunakan pendekatan yang berbeda dalam membuat signature dari yang sebelumnya, seperti menggunakan informasi pada header dari pada dengan badan MIME.
4.1.1.2 Implementasi Snort Dalam deteksi malware secara statis, plugin snort tersebut memegang peranan yang sangat penting. Snort terbagi menjadi 2 mode dasar, yaitu mode packet sniffer dan mode Network Intrusion Detection System (NIDS). Dalam Ossim, snort berjalan dalam mode NIDS. Pada mode NIDS ini, snort tidak mencatat log setiap paket yang ditangkap sebagaimana snort jika berjalan dalam mode sniffer. Dalam mode NIDS ini snort mengaplikasikan semua rule pada semua paket yang ditangkap. Jika payload suatu paket
45
cocok dengan suatu rule, maka payload paket tersebut dicatat pada log dan alert akan dibangkitkan. Akan tetapi jika payload suatu paket tidak cocok dengan satu pun rule yang tersedia, maka paket akan didrop dan tidak dilakukan pencatatan pada log. Konfigurasi pada mode NIDS pada snort berupa command line. Konfigurasi yang mengatur settingan snort disimpan dalam file snort.eth1.conf pada /etc/snort.
Untuk memastikan apakah snort berjalan dengan mode NIDS atau tidak, seorang administrator dapat membuat rule test yang berisi sebagai berikut:
Rule tersebut akan membangkitkan alert setiap terdapat paket TCP yang lewat dalam jaringan dimana sensor snort terpasang. Dalam keadaan normal suatu jaringan, tentu saja akan banyak alert yang dibangkitkan karena banyaknya paket TCP yang mengalir dalam jaringan.
Rules tersebut dibuat dan disimpan dalam path /etc/snort/rules dalam file test.rules. Kemudian file tersebut dimasukkan dalam file konfigurasi utama dari snort, yaitu snort.eth1.conf. Dalam source code tersebut, file test.rules dimasukkan pada bagian konfigurasi rules seperti berikut:
Include $RULE_PATH/test.rules
Setelah file tersebut disimpan. Langkah selanjutnya adalah me-restart mesin snort agar snort dapat mengaplikasikan rule test yang telah dikonfigurasi sebelumnya dengan /etc/init.d/snort restart
Setelah snort berjalan kembali, maka snort akan menghasilkan alert untuk setiap paket yang diperiksa. Alert dari hasil penerapan rule di atas dapat dilihat dalam file /var/log/snort/alerts.
46
Dari file di atas dapat dilihat begitu banyaknya alert yang dihasilkan oleh pengaplikasian rule test. Dengan adanya alert tersebut, dapat dibuktikan bahwa snort telah berjalan dalam mode NIDS.
Setelah snort dipastikan telah berjalan, test.rule dinonaktifkan dan rules yang telah dibahas pada bab sebelumnya, dapat dijalankan pada snort.
Alert dan payload paket yang cocok dengan rule snort selain dicatat dalam log, juga disimpan dalam database event milik Ossim. Berikut ini adalah source code pada snort.xml.
Dari source code xml di atas, dapat diketahui bahwa plugin id untuk snort adalah 1001 sebagai mana telah dibahas pada bahasan tentang korelasi. Snort merupakan sensor tipe detektor, yang berfungsi mengirimkan alert dalam jika ditemukan suatu serangan. Sedangkan ‘fast’ merupakan mode cepat dari pencatatan suatu event yang hanya menyertakan informasi sebagai berikut: •
Timestamp
•
Pesan dari Alert
•
Alamat IP asal dan tujuan paket 47
•
Port asal dan tujuan paket
Dengan menggunakan mode cepat ini, overhead pada sistem dapat dikurangi karena hanya memproses sedikit data.
Sedangkan argumen “&interface” mereferensikan pada interface yang digunakan oleh sensor snort dalam hal ini interface yang digunakan pada agen adalah eth1. Dan argumen “&sensor” mereferensikan sensor agen Ossim yaitu sensor 167.205.65.107.
Semua alert yang dihasilkan oleh snort akan dinormalisasikan pada event database untuk kemudian akan dikorelasikan.
48
4.2
Sistem Deteksi Dinamis
4.2.1
Osiris Dalam Ossim, tools yang digunakan sebagai Host Intrusion Detections System
(HIDS) adalah Osiris. Osirim merupakan program file-integrity terpusat berbasis arsitektur klien dan server yang berfungsi memantau perubahan pada sistem komputer. Server pusat memantau integritas file database dan konfigurasi untuk setiap komputer klien dan pada suatu interval waktu tertentu, osiris mengirimkan hasil pemantauannya ke database untuk diperiksa apakah ada perubahan. Administrator jaringan dapat menerima pemberitahuan mengenai adanya perubahan melalui email. Komunikasi antara klien dan server osiris dilakukan pada kanal komunikasi yang telah terenkripsi. Osiris menggunakan SSL untuk berkomunikasi. Osiris memiliki fitur-fitur sebagai berikut: •
Akses log pada syslog
•
Pemberitahuan melalui email
•
Penyaringan alert
•
Deteksi aktivitas akun
•
Pemantauan modul kernel
•
Konfigurasi file
•
Scan secara manual
•
Scan secara periodik
Server sentral musti dijaga keamanannya dan akses ke server tersebut musti dibatasi sebatas administrator jaringan yang mengatur osiris dan komputer klien yang berkomunikasi dengan server. Secara default, konsol manajemen hanya dapat diakses oleh localhost (127.0.0.1) dan untuk host lain perlu dikonfigurasi secara manual. Konsol manajemen dapat dapat diakses secara langsung melalui komputer server atau diakses dari jarak jauh (remote) melalui commandline.
49
Jika server sentral tetap aman dan komputer klien diserang dan penyusup tersebut menghapus atau menghentikan program pada klien, itu tidak menjadi masalah. Server sentral menyimpan konfigurasi file dan database. Sehingga administrator jaringan dapat menginstal ulang osiris pada komputer klien yang diserang, kemudian menjalankan scan config file dan mengirimkan hasil scan pada server. Hasil scan akan dibandingkan dengan konfigurasi file system sebelum adanya serangan. Dari hasil perbandingan tersebut, dapat diketahui apa saja yang dilakukan penyusup pada komputer korban.
4.2.1.1 Konfigurasi Osiris Osiris merupakan sistem monitoring integritas suatu host yang digunakan untuk mengamati perubahan pada sistem suatu host dan mengirimkan informasi tersebut kepada administrator jaringan. Selain memantau sistem file, osiris juga memantau daftar user, group dan modul kernel. Osiris melakukan pengecekan sistem file secara berkala dan menyimpan hasil pengecekan tersebut pada database. Database tersebut terintegrasi dengan event database ossim pada server ossim. Ketika ditemukan adanya perubahan pada sistem, maka Osiris akan mengirimkan alert pada server.
Osiris terdiri dari tiga komponen utama, yaitu: •
Management console (osirismd)
•
Scan agent (osirisd)
•
Management Application (osiris)
Management console dipasang pada server Ossim. Di console tersebut, semua informasi tentang host yang dipantau, file konfigurasi dan database disimpan. Scan agent bertanggung jawab dalam memantau perubahan pada local system dan mengirim data tersebut keepada management console. Sedangkan management application digunakan oleh administrator jaringan untuk mengatur secara spesifik host yang dipantau.
50
Management Console Secara default, management console menyimpan log, file konfigurasi dan file lainnya pada /usr/local/osiris. Akan tetapi pada konfigurasi setting, seorang administrator jaringan dapat mengubah path tempat penyimpanan log. Pengubahan dengan mengubah – with-root-dir=DIR. Dalam server digunakan path /var/lib/osirismd sebagai tempat penyimpanan semua log dan file konfigurasi.
Dalam management console osiris yang menjadi plugin Ossim, letak konfigurasi file ada pada path /var/lib/osirismd/osirismd.conf. Pada file tersebut terdapat:
•
Argumen syslog facilty menunjukkan management console mengumpulkan semua log. Log termasuk status dari management daemon, komunikasi ke agen dan log perbandingan hasil scan pada komputer yang dipantau.
•
Argumen control port menunjukkan bahwa management console membangun komunikasi dengan CLI.
•
Argumen http control port menunjukkan bahwa management console menunggu pada web based untuk setiap adanya konfirmasi perubahan. Ketika ditemukannya adanya perubahan dan argumen tersebut aktif, maka peringatan melalui email akan
mengandung
URL
yang
mengijinkan
bahwa
administrator
telah
mengkonfirmasi adanya perubahan. •
Argumen notify email menunjukkan alamat email yang dituju apabila ada perubahan dan argumen email notification diaktifkan.
•
Argumen notification smtp host menunjukkan alamat smtp server yang digunakan console untuk mengirimkan mail.
51
•
Argumen notification smtp port menunjukkan port yang port yang digunakan smtp server untuk mengirimkan mail.
Scan Agents Scan agent yang berada pada host yang dipantau, bertanggung jawab untuk: •
Melakukan scan pada sistem file host
•
Mengirimkan hasil scan dalam bentuk database kepada management console untuk kemudian dibandingkan.dengan database dalam keadaan normal.
Jika ditemukan adanya perbedaan maka, maka perbedaan tersebut akan dicatat dalam log file.
4.2.2
Ntop Dalam pambahasan ini akan dijelaskan bagaimana skenario ntop dalam jaringan
diimplementasikan dan menunjukkan parameter trafik dinamik yang telah dikumpulkan oleh sensor. Dalam implementasinya, ntop diinstal pada switch yang memiliki kecepatan tinggi. Hal ini dilakukan untuk meningkatkan kemampuan dalam mengukur semua parameter trafik yang berguna untuk mendeteksi anomali dan menyimpan informasi tersebut dalam event database untuk dianalisa secara statis. Ntop bertanggung jawab untuk menangkap dan menganalisa paket yang mengalir dalam jaringan. Sebagian besar informasi disimpan dalam memori dengan cache yang terbatas dalam disk.
Ketika sensor menerima informasi bahwa suatu batas treshhold telah terlampaui maka sensor akan terus mengamati host yang menjadi sumber masalah tersebut, mengeluarkan alarm dan paket yang menyebabkan masalah tersebut disimpan dalam disk agar selanjutnya dapat dilakukan analisis secara mendalam.
Alarm yang dihasilkan oleh ntop disimpan dalam database dan dikirimkan ke administrator dengan cara SNMP traps, GSM SMSs, dan instant messenger. Akan tetapi
52
dalam framework Ossim, alarm ditujukan pada server Ossim untuk selanjutnya dikorelasikan oleh Ossim.
Gambar 4. 1 Subsistem Alarm
Subsistem alarm dibagi menjadi dua komponen ,yaitu penyimpanan data-data trafik dan analisa trafik. Penyimpanan trafik bertanggung jawab mengumpulkan secara periodik
informasi
yang
berhubungan
dengan
trafik
melalui
HTTP
yang
direpresentasikan dengan ASCII atau menggunakan high level language seperti XML.
4.2.2.1 Konfigurasi Ntop Analisa trafik merupakan komponen yang ditulis dalam bahasa Perl dan bertanggung jawab untuk menganalisa dan mengkorelasikan data yang disimpan dalam RRD dan menghasilkan Alarm. Rule korelasi yang digunakan untuk analisa trafik disimpan di dalam database SQL yang sama dengan database dimana alaram disimpan. Format tabel yang memuat rule di dalamnya seperti di bawah ini: