Bab IV Konfigurasi Ossim dalam Deteksi Malware

Bab IV Konfigurasi Ossim dalam Deteksi Malware

4.1

Sistem Deteksi Statis

4.1.1

Snort

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: . Sebagai contoh:

“untuk setiap host jika ((#ARP requst) – (#ARP response) > 20) dalam jangka waktu 10 menit maka lakukan trap” jika ditranslasikan dalam tabel SQL maka:

53

“jika host jake mengirimkan lebih dari 5 paket menuju port UDP yang tertutup dalam waktu 15 menit maka lakukan trap” jika ditranslasikan dalam tabel SQL maka:

Analisa trafik menggunakan fasilitas yang disediakan oleh RRD untuk menganalisa arsip dan memvalidasi ekspresi . Walaupun demikian, bukan tindakan yang tepat jika alarm dihasilkan setiap dideteksi bahwa suatu batas treshhold terlampaui. Dalam prakteknya, akan terjadi banyak kejadian seperti data dikirim pada port yang tertutup atau tidak sempurnanya proses three way handshake dalam suatu jaringan. Jika setiap kejadian seperti itu membangkitkan alarm, tentunya akan banyak false alarm dan akan menghabiskan ruang kosong pada database alarm.

Ntop selain berfungsi sebagai monitor jaringan, juga dapat berfungsi sebagai Anomaly Detection Intrusion Detection System (AD-IDS). Ntop memperlajari jaringan dimana dia berjalan. Ntop membentuk model statistik yang selalu diupdate dari waktu ke waktu yang mendeskripsikan topologi, layanan jaringan yang tersedia dan trafik jaringan yang selalu berubah-ubah. Jika ditemukan trafik yang tidak sesuai dengan model yang telah dibentuk, tergantung seberapa besar tingkat pernyimpangannya, maka ntop akan membangkitkan alarmnya.

Ntop didesain sebagai open source, pengukuran trafik dengan web-based, dan pemantauan aplikasi tiap host dalam jaringan. Arsitekturnya adalah sebagai berikut: •

Paket sniffer bertanggung jawab dalam menangkap paket dari interface jaringan.

•

Paket analyser memproses paket yang telah ditangkap, mengkorelasikan paket dalam katagori yang sama (seperti koneksi TCP dan UDP), mempelajari tentang topologi jaringan (seperti membuat daftar router pada jaringan dan DNS server), dan memelihara statistik trafik dalam jaringan.

54

•

Report engine terdiri dari server HTTP sehinggal administrator jaringan dapat melihat trafik melalui web browser.

•

Adanya plugin yang membuat administrator dapat meningkat nilai fungsi dari ntop tanpa memodifikasi ntop core.

Gambar 4. 2 Aliran Data Pada Ntop

Yang membuat ntop NIDS berbeda dengan snort NIDS adalah adanya pengetahuan mengenai jaringan yang dipantau. Ketika ntop mengambil suatu paket, ntop mempelajari topologi jaringan dan host yang berhubungan (seperti routers, DNS, networks) dan menyimpan informasi tersebut pada Network Knowledge Database(NKD). Pengetahuan mengenai topologi jaringan tersebut bersifat dinamis dan tidak didefinisikan pada saat start-up ntop dengan file konfigurasi. Cara ntop mempelajari topologi jaringan, juga suatu host A berhasil merutekan paket untuk host B, maka ntop akan mengasumsikan host A sebagai router bagi host B. Juga jika host C mengirimkan paket dengan alamat IP sumber yang berbeda dan hanya memiliki 1 alamat MAC, maka ntop menganggap C memiliki kemampuan IP Aliasing. Pengetahuan ntop akan topologi jaringan selalu diperbaharui setiap paket dianalisa. Berikut ini informasi-informasi yang digunakan ntop untuk menentukan topologi jaringan: •

Paket ARP digunakan untuk mempelajari IP dan MAC

55

•

Paket IP yang diterima atau dikirim ke alamat luar diidentifikasikan sebagai gateway

•

Adanya respon positif DNS mengidentifikasikan DNS server

•

Banyaknya paket dengan alamat MAC yang sama dan alamat IP yang berbeda diidentifikasikan sebagai aliased interface.

Rules pada ntop didefinisikan dengan menggunakan bahasa sederhana yang didesain agar cukup ekpresif untuk mendeskripsikan hal untuk dideteksi. Rule disimpan dalam file yang didefinisikan dalam command line (dengan flag -R) pada saat startup ntop. Ntop akan menerjemahkan rule, mengecek konsistensinya dan menyimpannya dalam memori. Rule ditulis berdasarkan BNF Rule Language Syntax.

Berikut ini merupakan source code dari plugin agen Ossim:

Berbeda dengan script sebelum-sebelumnya, ntop menggunakan tipe monitor yang mendefinisikan bahwa ntop merupakan tipe yang selalu memberikan informasi secara berkala kepada server.

Semua hasil pemantauan jaringan termasuk alert yang dihasilkan apabila dideteksi adanya anomali pada trafik jaringan disimpan pada /var/log/ntop/access.log. Semua data informasi yang terkumpul pada log tersebut akan digunakan dalam proses korelasi. 56

4.3

Correlation

Metode Korelasi

Ossim menggunakan dua buah metode dalam korelasi. Yaitu, •

Berdasarkan sequences of events Fokus pada serangan yang detectable dan telah dikenal

sebelumnya.

Pendekatan tersebut menggunakan pattern dan behaviors yang telah diimplementasikan pada agent untuk mendeteksi suatu serangan. •

Berdasarkan Algoritma Heuristic Metode ini menggunakan pendekatan yang berlawanan. Ossim menggunakan suatu algoritma dalam upaya mendeteksi situasi yang beresiko tinggi terhadap serangan melalui analisa heuristic. Pendekatan ini dapat mendeteksi suatu serangan tanpa perlu mengetahui detail serangan sebelumnya. Hal ini sangat berguna untuk mendeteksi serangan yang belum teridentifikasi dan berguna untuk memberikan gambaran global dari situasi keamanan suatu jaringan komputer.

Metode1: Berdasarkan Algoritma Heuristic

Pada proses korelasinya, Ossim mengimplementasikan algoritma heuristic sederhana menggunakan akumulasi kejadian dalam rangka mendapatkan indikator dan parameter tentang keadaan keamanan global jaringan komputer.

Dalam prosesnya,

metode korelasi ini akan menggunakan data yang tersedia pada immediate risk dan memberikan nilai tingkat resikonya pada accumulate risk.

57

Hal ini memberikan monitoring high pada control panel yang terlihat seperti sebuah “thermometer” untuk memberikan gambaran mengenai situasi resiko tanpa mengetahui tentang detail karakteristik dari masalah tersebut.

Melanjutkan analogi “thermometer” di atas, termometer memberikan gambaran tentang akumulasi resiko dalam jaringan pada interval waktu tertentu. Indikator pada termometer akan meningkat secara proporsional seiring meningkatnya jumlah kejadiankajadian yang diterima oleh sensor dan akan menurun seiring tidak adanya kejadiankejadian baru yang diterima oleh sensor.

Metode korelasi dengan algoritma Heuristic memiliki dua keuntungan, yaitu: •

Menyediakan gambaran situasi keamanan global jaringan dengan cepat

•

Mendeteksi pattern serangan dimana sistem korelasi lain tidak dapat mendeteksinya karena belun diketahuinya informasi pengetahuan tentang serangan tersebut sebelumnya.

CALM (Compromise and Attack Level Monitor)

CALM merupakan algoritma pengukuran yang menggunakan akumulasi kejadian dengan sistem nyata waktu. CALM memiliki input dengan jumlah kejadian yang sangat banyak dan keluarannya hanya merupakan sebuah indikator dari situasi keamanan global suatu jaringan.

Akumulasi tersebut dijalankan untuk semua subjek pada jaringan, seperti semua mesin, kumpulan mesin-mesin, segmen jaringan, path , dan lain lain. Administrator jaringan dapat menentukan apa saja yang perlu dimonitor.

Akumulasi Kejadian

Akumulasi dikalkulasi secara sederhana dengan menjumlahkan 2 buah variabel yang merepresentasikan resiko dari setiap kejadian. 58

•

“C” (Level of compromise) Merupakan tingkat indikator dimana terdapat adanya kejadian yang berbahaya.

•

“A” (Level of attack) Merupakan tingkat serangan pada suatu sistem atau host, yang diukur berdasarkan potensi resiko yang ditimbulkan akibat serangan tersebut.

Pada proses monitoring digunakan 2 varibel, karena setiap varibel mewakili kondisi yang berbeda. Pada Level of attack, mengindikasikan kemungkinan dimana serangan telah dilakukan, serangan tersebut bisa saja berhasil atau gagal. Sedangkan Level of compromise menyediakan bukti secara langsung bahwa dalam jaringan telah terjadi suatu serangan dan serangan tersebut sukses.

Nilai yang diberikan pada kedua varibel tersebut untuk tiap host dalam jaringan, musti memenuhi kondisi yang diberikan oleh 3 buah rule: 1. Setiap kemungkinan serangan yang dilakukan host 1 pada host 2 akan meningkatkan level “A” pada host 2 dan meningkatkan juga level “C” pada host 1. 2. Ketika terjadi respon terhadap serangan (yang mengindikasikan suksesnya serangan), level “C” akan meningkat pada host 1 dan 2. 3. Jika kejadian masih dalam lingkup internal jaringan, level dari “C” akan meningkat pada host asal serangan.

59

Metode2 : Berdasarkan Sequences of events

The sequences Panel

Ide dasar dari metode deteksi pada sequence of events sangat sederhana, hanya dengan mengimplementasikan rule yang intinya “jika diterima suatu kejadian A, kemudian kejadian B dan kemudian C, maka lakukan tindakan D”.

Di penghujung pada swquence panel, seorang administrator jaringan dapat mendefinisikan daftar rule untuk setiap sequence of events yang ingin didefinisikan.

Kompleksitas dari panel sangat tergantung dari kapasitas rules yang digunakan dan kemampuan server Ossim untuk menganalisa input yang bervariasi.

Panel pada Ossim dapat menjalankan sequences dengan karakteristik seperti berikut: •

Kemampuan untuk mendefinisikan variabel asal dan tujuan

•

Kemampuan untuk mengolah input pattern dari detektor dan input indikator dari monitor.

•

Kemampuan mendefenisikan priotitas dan reliabilitas dari tiap alert.

•

Menggunakan varibel ‘elastic’, atau variabel yang dapat mengukur suatu kejadian untuk menentukan tingkat prioritas dan reliabilitas.

•

Arsitektur rekursiv. Seorang administrator jaringan dapat membuat objek dengan cara mengkorelasikan rule dengan suatu fungsi detektor atau monitor.

Level of Correlation

Dalam Ossim terdapat tiga level hirarki dalam fungsi korelasi seperti yang ditunjukkan pada gambar di bawah ini.

60

Gambar 4. 3 Hierarki dalam Korelasi

Level 2.1 Spesifik Attack

Pada level tersebut, korelasi menggunakan fungsi detektor dan monitor dari Ossim. Ossim berusaha mencocokkan signature dan aktivitas yang berhubungan dengan adanya serangan.

Fungsi utama dari level spesific attack adalah untuk meningkatkan reliabilitas deteksi. Ossim menggunakan signature untuk mendeteksi adanya serangan malware. Dengan menggunakan sistem tersebut dapat diperoleh bukti lebih tentang serangan, baik ketika serangan masih dalam progress atau serangan telah gagal.

Evaluasi tersebut dapat membatasi terjadinya false positif dan memprioritaskan serangan sungguhan dalam sistem deteksi keamanan.

Berikut ini contoh sederhana korelasi antara detektor pattern dan monitor: Dengan menggunakan signature based, IDS pada Ossim mendeteksi adanya kemungkinan serangan denial of service via synflood dan mengirimkan alert yang memerintahkan service monitor (Nagios) mengecek apakah ada host dalam jaringan yang availability-nya menurun dan sampai level berapa. Jika ditemukan penurunan tingkat availability , maka Ossim akan memberikan alert “denial of service via synflood” dengan tingkat reliabilitas yang lebih tinggi.

61

Ossim menggunakan rangkaian yang kompleks dalam mengkorelasikan alert yang dihasilkan oleh adanya signature dengan karakteristik behavior yang spesifik dalam suatu serangan. Berikut ini akan dideteksi signature yang sangat sederhana dari Trojan horse: “connect , active , get info, access, server2client_flow, response, traffic_detect”

Deteksi adanya rangkaian koneksi di atas bukan informasi yang sangat bermanfaat dalam mendeteksi kehadiran Trojan horse, karena dalam prakteknya seharihari, sangat banyak kejadian yang sama dengan rangkaian perintah di atas. Akan tetapi jika ada HIDS dalam jaringan yang melaporkan adanya keanehan dalam host, maka akan diberikan alert ”Trojan Hore detected” dengan tingkat reliabilitas yang tinggi.

Level 1.1 Detection Using Patterns

Dalam level ini, Ossim mengirimkan alert berdasarkan aktivitas pattern detectors.

Attack Response

Berdasarkan pembahasan sebelumnya, dapat dikatakan adanya attack response sangat penting karena hal tersebut memastikan eksistensi sebuah event, yang ekuivalen dengan meningkatnya reliabilitas dari alert yang diterima.

Sistem korelasi didesain untuk memantau attack response secara kontinyu dan memperhatikan initial sign adanya kemungkinan serangan. Dalam contoh trojan horse dapat digambarkan sebagai berikut:

Level 2.2 Detection Using General Activity Deteksi berdasarkan aktivitas umum menggunakan rules yang ditujukan untuk menghadapi serangan yang tak terdeteksi, karena karakter signature atau pattern belum tersedia.

62

Serangan dapat diidentifikasikan melalui aktivitas mencurigakan yang dideteksi oleh monitoring indicator dari aktivitas umum dalam jaringan seperti port atau services, traffic, dan lain lain.

Dalam beberapa kasus, karakter suatu serangan dapat dikenali dengan teknik tersebut. Akan tetapi sistem deteksi dengan pemantauan aktivitas umum tersebut masih kurang akurat dibandingkan dengan deteksi dengan spesific attack. Berikut ini beberapa contoh deteksi dengan pemantauan aktivitas general: •

Deteksi worm baru yang menyebabkan adanya trafik yang abnormal dan banyaknya koneksi pada port yang tidak terpakai.

•

Deteksi adanya akses mencurigakan, seperti user yang

terus berusaha

mengakses port administratif. •

Trafik yang berlebihan dengan penggunaan dan tujuan yang aneh.

Level 3. Attack Behavior

Fungsi utama dari level ketiga ini adalah untuk mengkorelasikan spesific attack atau aktivitas umum yang diidentifikasi pada level pertama.

Arsitektur sistem korelasi bersifat rekursif, sehingga rule

dapat dimasukkan

sebagai objek baru yang berfungsi sebagai detektor untuk mengirimkan peringatan atau sebagai monitor untuk menyediakan data-data. Rules tersebut dapat diambil dari level sebelumnya.

Setiap level mewakili tingkatan-tingkatan hierarki, dan pada level ini ossim berusaha mengidentifikasi behavior pattern yang membantu mengidentifikasi objek, path yang dilalui, dan metode yang digunakan. Berikut ini beberapa contoh dari attack behavior: •

Distributed attack.

•

Akses ke jaringan dari internet.

•

Serangan dari dalam jaringan. 63

Correlation

pada

Ossim

memegang

peranan

sangat

penting

dalam

menginformasikan seberapa besar resiko yang dihadapi atas terjadinya suatu serangan. Perintah pada Ossim menggunakan xml base. Dalam Ossim, konfigurasi tersebut berada pada menu Correlation bagian Directive. Seperti pada gambar di bawah ini.

Gambar 4. 4 Tampilan Directive Correlation Ossim

Selanjutnya akan dibahas mengenai penggunaan pseudo-language yang digunakan dalam membentuk suatu directive. Seperti yang telah dibahas diatas, server Ossim menerima, memproses dan menormalisasi informasi-informasi yang dikumpulkan oleh agen-agen. Agen-agen tersebut antara lain : •

Snort

•

Spade

64

•

Apache

•

IIS

•

Iptable

•

FW-1

Agen juga dapat menganmbil informasi yang disediakan oleh Ntop mengenai host tertentu atau sesi yang terbentuk pada suatu host.

Ossim membedakan antara ’monitor’ dan ’detector’. Input detector secara kontinyu menerima informasi-informasi yang dikirimkan oleh agent dalam bentuk event atau log. Sedangkan masukan untuk monitor, musti melalui permintaan server terlebih dahulu, kemudian agent akan melaporkan event kembali server ketika suatu kondisi terpenuhi.

Perintah minimal terdiri dari tiga buah tag. Tag tersebut berisi, identitas dari perintah berupa desimal yang unik, nama deskripsi dari perintah, dan tingkat prioritas dari perintah secara keseluruhan. Berikut ini contoh perintah dalam Ossim mengenai kemungkinan adanya serangan Worm.

Setiap perintah pada Ossim memiliki starting rule yang memulai untuk mencocokkan perintah dan memulai fungsi event correlation dan mencatat semua kejadian pada antrian log.

65

Tujuan dari rule di atas adalah untuk mendeteksi adanya serangan worm standar pada port. Berikut ini akan dijelaskan tiap-tiap argumen yang digunakan pada rule di atas: •

Type Argumen ini berfungsi untuk menentukan tipe dari proses penyediaan

informasi jaringan. o Detector Rule detector memerintahkan server ossim untuk secara otomatis menerima informasi yang dikirimkan oleh agen-agen. Agen yang dimaksud di sini adalah program seperti snort, spade, apache, dan lain lain.

o Monitor Rule monitor berfungsi untuk memanggil data informasi yang telah dikumpulkan oleh server ntop. •

Name Rule name digunakan dalam event database ketika suatu kondisi cocok dengan

rule tersebut. •

Reliability Setiap rule memiliki tingkat reliabilitas masing-masing. Reliabitility

menentukan tingkat seberapa besar reliabilitas suatu rule dalam rantai serangan keseluruhan. •

Occurence Seorang administrator jaringan dapat menentukan berapa kali server ossim

melakukan pencocokan pada “from,to,port_form,port_to,plugin_id,&plugin_sid” dalam rangka untuk meningkatkan fungsi korelasi. •

Time_out

66

Argumen tersebut menunjukkan seberapa lama rule akan kadaluarsa dan lifetime dari suatu perintah. •

From Argumen tersebut menunjukkan sumber dari alamat IP. Berikut ini akan

dijelaskan beberapa field dalam rule tersebut: o ANY Argumen tersebut menunjukkan bahwa semua alamat IP asal akan cocok dengan rule tersebut.

o Dotted numerical Ipv4 (x.x.x.x) Dalam argumen tersebut, variabel x diganti dengan desimal alamat IP tertentu.

o Comma separated Ipv4 addresses without netmask Seorang administrator jaringan dapan menggunakan lebih dari satu alamat IP yang dipisahkan dengan tanda koma.

o Using a network name Seorang administrator jaringan dapat menggunakan nama network yang didefinisikan via web.

o Relative Argumen tersebut digunakan untuk memberikan referensi alamat IP pada level sebelumnya. Sebagai contoh penggunaan, 1:SRC_IP berfungsi menyatakan referensi bahwa alamat IP asal sama dengan rule sebelumnya 2:DST_IP berfungsi menyatakan referensi bahwa alamat IP tujuan sama dengan dua level rule sebelumnya.

o Negated

67

Seorang administrator jaringan juga dapat menggunakan elemen negasi. Seperti contoh: “!167.205.65.0, INTERNAL_NETWORK” •

To

Argumen tersebut menunjukkan sumber dari alamat IP. Berikut ini akan dijelaskan beberapa field dalam rule tersebut: o ANY Argumen tersebut menunjukkan bahwa semua alamat IP asal akan cocok dengan rule tersebut.

o Dotted numerical Ipv4 (x.x.x.x) Dalam argumen tersebut, variabel x diganti dengan desimal alamat IP tertentu.

o Comma separated Ipv4 addresses without netmask Seorang administrator jaringan dapan menggunakan lebih dari satu alamat IP yang dipisahkan dengan tanda koma.

o Using a network name Seorang administrator jaringan dapat menggunakan nama network yang didefinisikan via web.

o Relative Argumen tersebut digunakan untuk memberikan referensi alamat IP pada level sebelumnya. Sebagai contoh penggunaan, 1:SRC_IP berfungsi menyatakan referensi bahwa alamat IP asal sama dengan rule sebelumnya 2:DST_IP berfungsi menyatakan referensi bahwa alamat IP tujuan sama dengan dua level rule sebelumnya.

68

o Negated Seorang administrator jaringan juga dapat menggunakan elemen negasi. Seperti contoh: “!167.205.65.0, INTERNAL_NETWORK”

Field ‘To’ merupakan field yang digunakan ketika data yang diterima dari monitor tidak dilengkapi dengan informasi IP alamat asal. •

Port_from

Argumen tersebut merupakan nomor port atau kumpulan nomor-nomor port asal yang dipisahkan oleh koma.

1:DST_PORT atau 1:SRC_PORT berfungsi untuk menggunakan referensi 1 tingkat rules sebelumnya untuk asal dan tujuan port. •

Port_to

Argumen tersebut merupakan nomor port atau kumpulan nomor-nomor port tujuan yang dipisahkan oleh koma.

1:DST_PORT atau 1:SRC_PORT berfungsi untuk menggunakan referensi 1 tingkat rules sebelumnya untuk asal dan tujuan port. •

Protocol

Perintah pada ossim memperbolehkan seorang administrator jaringan untuk menentukan protokol seperti TCP, UDP atau ICMP. •

Plugin_id

Identitas numerik diberikan untuk menjelaskan referensi plugin. Berikut ini merupakan tabel numerik plugin id pada lampiran. •

Plugin_sid 69

Setiap plugin yang telah dibahas di atas, memiliki sub-sub id numerik lagi agar lebih spesifik. •

Condition

Parameter tersebut hanya dapat digunakan pada rule dengan tipe ‘monitor’ dan beberapa rule dengan tipe ‘detektor’. Berikut ini beberapa logical condition yang digunakan dalam perintah xml: o Eq – Equal o Ne – Not equal o Lt – Lesser than o Gt – Greater than o Le – Lesser or equal o Ge – Greater of equal •

Interval

Argumen tersebut memiliki funsi yang sama dengan argumen ‘time-out’, akan tetapi argumen ‘interval’ hanya digunakan untuk rule dengan tipe ‘monitor’. •

Absolute

Argumen tersebut digunakan untuk menentukan apakah suatu nilai itu absolut atau relatif. Sebagai contoh, ditentukan nilai 1000 sebagai value, gt sebagai condition dan 60 (detik) sebagai interval,

menggunakan Ntop untuk

HttpSentBytes, berarti: o Absolute true Jika ada host yang mengirimkan lebih dari 1000 byte data http dalam selang waktu 60 detik. Server akan melaporkan apa bila absolute value tercapai. o Absolut false Jika ada host yang mengirimkan kurang dari 1000 byte data http dalam selang waktu 60 detik. Server akan melaporkan apa bila absolute value tercapai. 70

Berikut ini script korelasi dalam mendeteksi worm.

Skrip directive yang telah dituliskan di atas, akan dicantumkan kembali di bawah ini.

Pertama, seorang administrator dalam membuat directive dimulai dengan tag dahulu. Dalam contoh di atas, directive nomor ‘4’ sehingga identitas directive menggunakan numerik “4”. Kemudian directive tersebut menggunakan nama “Possible Worm” dan memiliki tingkat prioritas level “4”.

Rule di atas, bertujuan untuk mendeteksi adanya koneksi anomalous spade melalui port “25, 80, 135, 137, 139, 445, 1433, 1434’. Port-port tersebut merupakan port yang cukup rentan diserang oleh worm.

Tag di atas, menunjukkan bahwa rule setelah tag lebih tinggi 1 level dari rule sebelum tag.

71

Rule di atas merupakan rule level 2 yang berfungsi untuk mendeteksi adanya 15 buah koneksi yang mencurigakan melalui spade (plugin 1104, plugin_sid ANY) dari alamat IP sumber yang fix dan tujuan port yang telah ditentukan pada rule 1 level sebelumnya (port nomor “25, 80, 135, 137, 139, 445, 1433, 1434”). Argumen sticky_different pada rule diatas menunjukkan 15 kejadian musti berbeda satu sama lain.

Logika yang sama berlaku sampai dedeteksi adanya 20000 kejadian atau 43200 detik (12 jam) telah dilalui. Untuk fungsi korelasi di level 5, argumen sticky_different tidak digunakan karena sudah dideteksi 2000 host yang berbeda dan tidak memperberat proses kinerja server dalam mengecek hubungan host yang berjumlah besar. Skrip untuk rule secara keseluruhan dapat dilihat pada lampiran.

72