PENGALIHAN PAKET KE HONEYPOT PADA LINUX VIRTUAL SERVER UNTUK
MENGATASI SERANGAN DDOS
Baskoro Adi Pratomo, Supeno Djalali, Wahyu Suadi
Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember, Email:
Abstrak
Seiring dengan berkembangnya internet, penyedia layanan juga harus mempertimbangkan banyaknya jumlah pengguna yang terus bertambah. Sebuah server pasti memiliki keterbatasan dalam kemampuan menangani pengguna. Salah satu cara untuk mengatasi hal tersebut adalah dengan penambahan jumlah server. Dengan penambahan server, layanan yang sudah ada tetap berjalan ketika proses konfigurasi sedang dilakukan. Sehingga tidak akan sampai mematikan layanan.
Meskipun demikian, penambahan server saja akan cukup merepotkan apabila tidak diatur dengan baik. Penambahan server tentu harus dilakukan dalam waktu yang cepat dan sebisa mungkin tidak diketahui oleh user. Untuk mengatasi hal-hal tersebut, bisa digunakan Linux Virtual Server (LVS).
LVS sebagai salah satu bentuk kumpulan server dapat juga terkena serangan Distributed Denial of Services (DDOS), sebuah serangan yang bertujuan untuk membuat suatu layanan tidak dapat diakses oleh pengguna yang sah. Karena itu, untuk meminimalisir efek dari serangan ini diletakkanlah honeypot diantara beberapa server sesungguhnya.
Honeypot adalah sebuah server “palsu” yang bertindak seperti server yang asli. Tujuannya agar penyerang mengira serangannya berhasil, padahal yang terjadi adalah bisa saja lokasi si penyerang terlacak dengan honeypot. Dari hasil ujicoba, setelah sistem ini diterapkan reply rate dapat naik sebesar 5.91%, packet loss rate turun sebesar 0.97%, waktu respon turun sebesar 17% dan penggunaan CPU hanya 2.5%.
Kata kunci: LVS, Honeypot, DDOS, Pengalihan Paket 1. PENDAHULUAN
Internet sudah menjadi bagian dari kehidupan sehari-hari saat ini. Dimanapun kita bisa mengakses suatu server melalui internet.
Seiring dengan berkembangnya internet, tentu penyedia layanan juga harus mempertimbangkan banyaknya pengguna yang terus bertambah. Sebuah server pasti memiliki keterbatasan dalam kemampuan menangani pengguna. Salah satu cara untuk mengatasi hal tersebut adalah mengganti server dengan yang lebih canggih.
Akan tetapi penggantian server merupakan suatu hal yang cukup merepotkan dan membutuhkan biaya yang banyak. Server baru tersebut harus dikonfigurasi kembali. Hal itu dapat memakan waktu yang lama, sedangkan penggantian server tentunya harus berjalan secepat mungkin tanpa disadari oleh pengguna.
Alternatif lain dari penggantian server adalah penambahan server-server yang tidak terlalu canggih. Dengan penambahan server, layanan yang sudah ada tetap berjalan ketika proses konfigurasi sedang dilakukan. Sehingga tidak akan sampai mematikan layanan.
Meskipun begitu penambahan server saja akan cukup merepotkan apabila tidak diatur dengan baik. Penambahan server tentu harus dilakukan dalam waktu yang cepat dan sebisa mungkin tidak diketahui oleh user. Dengan bertambahnya jumlah server, harus dipikirkan
pula pengaturan saat salah satu server mati.
Tidak mungkin seorang administrator harus mengaturnya secara manual. Untuk mengatasi hal-hal tersebut bisa digunakan Linux Virtual Server (LVS) (Zhang dkk, 2000).
Dengan LVS, beberapa buah server dapat memiliki 1 buah IP. Dan IP itulah yang nantinya akan diakses oleh klien. Ketika klien mengakses salah satu layanan yang ada, misalkan sebuah web, maka akan diatur agar klien itu mendapat layanan dari server yang mana. Apabila ternyata salah satu server ada yang mati, maka layanan yang ada pada server tersebut dapat dipindah ke server yang lain secara otomatis.
Efek lain dari berkembangnya penggunaan internet adalah munculnya gangguan-gangguan yang menyulitkan pengguna. Salah satu diantara gangguan tersebut adalah Denial of Services (DOS). DOS ini adalah sebuah serangan yang menyebabkan satu atau beberapa server tidak dapat melayani pengguna yang sesungguhnya (Peng dkk, 2007).
Beberapa metode sudah diajukan untuk mencegah maupun mengurangi efek dari sebuah serangan DOS, tetapi tidak hanya metode pencegahannya saja yang berkembang. Metode serangan DOS pun juga berkembang. Yang dahulu hanya menggunakan sebuah komputer saja untuk menyerang server, sekarang berkembang menjadi sebuah serangan yang terdistribusi.
Sebuah komputer penyerang menginfeksi beberapa komputer lain yang disebut komputer zombie. Kemudian komputer penyerang akan memerintahkan para zombie tersebut untuk menyerang sebuah target secara bersama-sama.
Sehingga efek yang dihasilkan dan kerumitan pencegahan bisa berkali-kali lipat dibandingkan dengan serangan DOS biasa. Hal itulah yang disebut dengan Distributed Denial of Service (DDOS) (Peng dkk, 2007).
LVS, sebagai salah satu bentuk kumpulan server, tentunya dapat juga terkena serangan DDOS. Untuk meminimalisir efek dari serangan ini, diletakkan honeypot diantara beberapa server sesungguhnya. Honeypot adalah sebuah server “palsu” yang bertindak seperti server yang asli. Sehingga, penyerang akan mengira serangannya berhasil. Padahal yang terjadi adalah bisa saja lokasi si penyerang terlacak oleh honeypot. Diharapkan dengan penggunaan honeypot, paket-paket yang terdeteksi sebagai serangan akan diarahkan oleh LVS Director ke honeypot dan gangguan yang terjadi pada server-server asli dapat diminalisir.
2. LINUX VIRTUAL SERVER
Seperti telah disebutkan diatas, salah satu cara untuk meningkatkan kualitas layanan di internet yaitu dengan menambah jumlah server.
Linux Virtual Server (LVS) adalah salah satu cara untuk mengatur sejumlah server agar dapat memberikan layanan kepada pengguna secara bersama-sama.
LVS mengarahkan koneksi dari klien ke server-server yang berbeda tergantung dari algoritma penjadwalan yang digunakan, dan membuat beberapa layanan yang berjalan paralel tampak sebagai sebuah layanan virtual yang berada pada sebuah alamat IP (Zhang dkk, 2000). Selain itu, LVS juga mengatur penambahan ataupun pengurangan server.
Sebuah LVS terdiri dari satu atau lebih Director/Load Balancer, sejumlah klaster server yang bertugas untuk melayani pengguna, dan server yang digunakan sebagai tempat penyimpanan data bersama. Arsitektur LVS merupakan arsitektur three-tier. Untuk lebih jelasnya dapat dilihat pada Error! Reference source not found. di bawah ini.
Gambar1 Arsitektur LVS
2.1. Kernel Module IP_VS
LVS terdiri dari 2 macam aplikasi. Aplikasi pertama berupa kernel module bernama ip_vs yang bertugas untuk mengarahkan paket, mengatur penjadwalan, dan menyimpan data yang berhubungan. Sedangkan aplikasi kedua digunakan untuk manajemen LVS yang ada.
Aplikasi ini disebut dengan ipvsadm yang merupakan singkatan dari ipvs administration.
Kernel module ip_vs sebetulnya terdiri dari beberapa kernel module lain. Berikut ini adalah daftar kernel module apa saja yang ada dalam sebuah paket ip_vs :
• Kernel module utama:
o ip_vs
• Scheduler:
o ip_vs_rr o ip_vs_wrr o ip_vs_lc o ip_vs_wlc o ip_vs_lblc o ip_vs_lblcr o ip_vs_dh o ip_vs_sh o ip_vs_sed o ip_vs_nq
• Kernel module khusus FTP:
o ip_vs_ftp
Kernel module utama, ip_vs, mempunyai beberapa fungsi diantaranya mengatur daftar service dan realserver yang ada dan menerima perintah dari userspace program ipvsadm. Dan modul ini adalah modul yang harus di-load ke dalam kernel agar LVS dapat berjalan.
Selain kernel module utama, LVS memiliki beberapa kernel module lain yang masing- masing merepresentasikan algoritma penjadwalan yang digunakan. Misalnya saja module ip_vs_rr digunakan apabila algoritma penjadwalan round-robin yang digunakan atau module ip_vs_lc yang akan di-load jika administrator menggunakan algoritma Least- connection.
2.2. IPVSADM
Seperti yang telah disebutkan pada subbab sebelumnya, ipvsadm adalah userspace program yang berfungsi untuk mengatur kernel module ip_vs. Contohnya adalah ketika administrator ingin menambahkan layanan baru, menambah atau mengubah realserver yang ada, menentukan algoritma penjadwalan apa yang akan digunakan, dan melihat daftar layanan serta realserver yang sudah terdaftar apa saja.
Informasi-informasi tersebut nantinya akan dikirim ke dalam kernel dengan menggunakan netlink socket atau sockopt. Kemudian diolah oleh kernel module ip_vs agar bisa berjalan sesuai dengan yang diinginkan. Nantinya, aplikasi ini merupakan salah satu yang dikembangkan agar dapat memberikan tambahan pengarahan paket ke honeypot.
Untuk membuat klaster server dengan menggunakan LVS diperlukan beberapa langkah, yaitu:
1. Menyiapkan konfigurasi jaringan sesuai dengan metode pengarahan paket yang dipilih, karena pada LVS-TUN dan LVS- DR dibutuhkan konfigurasi khusus pada realserver.
2. Menambahkan service ke LVS dengan cara mendaftarkan IP address dan port ke dalam LVS. Selain itu menentukan juga metode penjadwalan yang digunakan.
Berikut ini sintaks untuk menambahkan sebuah service ke LVS:
• ipvsadm –A –t <ip_addr>:<port> -s
<sched_algorithm>
3. Mendaftarkan realserver ke service yang diinginkan. Bila perlu bisa ditambahkan juga beberapa option lainnya seperti weight dari realserver. Selain itu perlu ditentukan juga metode pengarahan paket yang digunakan. Berikut ini adalah sintaks untuk menambahkan realserver ke dalam sebuah service:
• ipvsadm –a –t
<ip_addr_service>:<port_service> -r
<ip_addr_realserver>:<port_realserv er> [-g|-i|-m] [-w weight]
3. SYN Flood
Pada protokol TCP dikenal Three-Way Handshake. Sebelum terjadi koneksi antara kedua belah pihak, maka harus dilakukan pengiriman 3 macam paket untuk menyatakan bahwa koneksi telah terbangun, yaitu SYN, SYN-ACK, dan ACK.
Pada SYN flood attack, penyerang akan mengirim sebuah paket SYN yang alamat IPnya tidak ada atau tidak dapat diakses oleh korban.
Sehingga paket SYN ini akan bertahan di dalam stack pada komputer korban sampai ACK diterima. Pada kenyataannya, ACK tidak akan pernah diterima. Sehingga paket SYN terus memenuhi stack pada korban. Hal ini bisa berakibat paket SYN yang sah tidak dapat diterima oleh korban.
4. METODE PENELITIAN
Pada bab ini akan dijelaskan mengenai metode yang digunakan pada tesis ini. Untuk lebih jelasnya dapat dilihat pada subbab-subbab di bawah ini.
4.1. Metode Pengalihan Paket ke Honeypot Dasar dari metode pengalihan paket ke honeypot ini adalah adanya blacklist terhadap IP tertentu yang dianggap mengirimkan paket- paket yang berupa serangan. Jika ada paket yang datang dari alamat IP yang termasuk dalam blacklist, maka paket itu tidak diarahkan ke realserver, tetapi ke honeypot. Untuk melakukan hal itu, berikut ini adalah langkah- langkah yang dilakukan:
• Membedakan realserver dengan honeypot melalui struktur datanya Sebenarnya, honeypot yang ada pada LVS yang diperbarui ini adalah sebuah realserver. Hanya saja diberi tanda bahwa realserver tersebut bertindak untuk melayani penyerang.
• Mengubah informasi yang dikirimkan ipvsadm ke kernel
Berikutnya yang diubah adalah membuat agar ipvsadm dapat mengirimkan informasi yang mana realserver dan yang mana honeypot. Karena sebelumnya, ipvsadm hanya mengirimkan data-data tentang realserver saja, tanpa menyebutkan apakah itu adalah data realserver atau honeypot.
• Membuat kernel module untuk menyimpan blacklist
Semua IP penyerang ini didapatkan dari detektor serangan (Snort). Masalahnya adalah bagaimana menyimpan IP blacklist ini agar dapat diakses secara cepat setiap kali ada paket yang datang. Untuk mempercepat akses, maka data-data IP yang di-blacklist disimpan juga di dalam kernelspace. Karena itulah dibuat sebuah kernel module tersendiri yang diberi nama ip_vs_honeypot yang bertugas menyimpan IP blacklist dan member informasi pada ip_vs apakah paket yang lewat berasal dari IP yang di-blacklist.
• Mengarahkan paket jahat ke honeypot Bagian ini adalah langkah inti dari
pengarahan paket jahat ke honeypot. Yang perlu dilakukan hanya mengubah module ip_vs_rr. Menambahkan penyeleksian asal paket dan paket yang dianggap serangan akan diberikan ke server yang bertindak sebagai honeypot.
4.2. Sistem Deteksi Serangan
Sistem deteksi serangan/intrusi dibutuhkan untuk mendapatkan penyerang menyerang dari alamat IP mana saja. Selain itu sistem deteksi intrusi yang ada haruslah seringan mungkin dan dapat diimplementasikan oleh siapa saja.
Berdasarkan studi literatur (Roesch, 1999), maka dipilihlah Snort sebagai sistem deteksi intrusi pada tesis ini.
Metode serangan yang akan digunakan untuk uji coba nanti adalah serangan DDOS dengan tipe SYN flooding. Komputer–komputer penyerang akan mengirim paket SYN dengan IP pengirim yang dipalsukan ke LVS. Oleh karena itu perlu dilakukan pemilihan rule untuk Snort yang tepat untuk mendeteksi serangan ini.
Hasil deteksi dari Snort yang berupa alert akan dicatat ke dalam file csv. Alert file ini akan berisi alamat IP asal saja.
Pada Gambar2 ini adalah rule-rule yang digunakan dalam tesis ini.
pass tcp $EXTERNAL_NET any ->
$HTTP_SERVERS 80 (
msg:"DDOS synflood"; \ flow:to_server; \ flags:S; \
sid:1000001; rev: 1 )
rate_filter \
gen_id 1, sig_id 1000001, \
track by_src, count 4000, seconds 1,
\
new_action alert, timeout 0 event_filter \
gen_id 1, sig_id 0, \ type limit, \
track by_src, count 1, seconds 30 Gambar 2 Konfigurasi Rule dengan Rate_filter
Pada rule-rule yang tampak di atas, akan terdeteksi paket SYN yang menuju ke server LVS. Tetapi hanya akan dilewatkan begitu saja secara normalnya. Namun apabila ternyata jumlah paket yang menuju server melebihi 4000 dalam waktu 1 detik, maka akan berlaku aturan baru, yaitu keluarnya alert ke file.
Untuk membatasi jumlah alert yang dikeluarkan, digunakanlah event_filter. Dengan event_filter, seperti terlihat pada rule-rule di atas, alert yang sama hanya akan keluar setelah ada jeda 30 detik. Selama 30 detik itu, jika ada alert yang sama, tidak akan muncul di dalam file.
4.3. Pengiriman Data Blacklist dari Snort Alert File ke Kernel
Pengalihan paket ke honeypot di sisi kernel dan deteksi serangan di sisi user sudah selesai.
Berikutnya adalah bagaimana menghubungkan kedua sisi ini. Untuk itu dibuatlah sebuah aplikasi daemon yang terus berjalan untuk membaca file alert dari Snort dan mengirimkan hasilnya ke kernel melalui file /proc/ip_vs_blacklist.
Program kecil ini akan mulai dengan menghapus isi blacklist yang ada di kernel dengan cara menulis perintah CLEAR 0.0.0.0 ke file /proc/ip_vs_blacklist. Kemudian setiap 30 detik, program ini akan membaca alert file dan mengirimkan hasil pembacaan tersebut ke kernel. Selain itu setiap 300 detik, program ini akan mengirimkan perintah CLEAR 0.0.0.0 ke kernel untuk menghapus blacklist yang ada. Jadi tidak selamanya alamat IP yang sudah masuk blacklist akan terus berada dalam blacklist selamanya.
5. UJI COBA
Pada bab ini akan dibahas mengenai uji coba dan evaluasi dari sistem yang dibangun.
Sistem diuji coba dari segi fungsionalitas dan performa. Pada bab ini juga dibahas mengenai lingkungan uji coba.
5.1. Lingkungan Uji Coba
Lingkungan uji coba pada tesis ini meliputi hardware dan software apa saja yang digunakan
selama uji coba berlangsung. Untuk topologi jaringan yang digunakan pada uji coba ini, sama dengan rancangan arsitektur yang ada pada bab 3. Untuk lebih jelasnya, topologi jaringan yang digunakan pada uji coba dapat dilihat pada
Gambar3.
Real Server (Balawardana)
192.168.1.3 LVS Director
(Kratana) 192.168.1.2
Router (Gandari) 192.168.1.1 192.168.2.1 10.151.36.225
Switch Real Client
(Karna) 192.168.2.6
Attacker
(Ugrasena,Citraksa, Bahwasi, Dredaksatra) 192.168.2.7-10 Switch
Real Server (Somakirti) 192.168.1.4
Honeypot Server (Wrendaraka)
192.168.1.5
Gambar 3 Topologi Jaringan untuk Uji Coba
5.1.1 Spesifikasi Hardware
Ada beberapa macam hardware yang digunakan dalam uji coba ini. Untuk komputer yang digunakan sebagai realserver LVS dan penyerang memiliki spesifikasi yang sama. Jadi ada 5 macam komputer yang digunakan, yaitu klien, penyerang, LVS Director, Realserver/Honeypot, dan router. Berikut ini adalah spesifikasi masing-masing jenis tersebut:
• LVS Director:
▪ Prosesor: Intel Core i3 530 2.93 GHz
▪ Memori: 4GB DDR3 1333 Hz
▪ Harddisk: 250 GB SATA
▪ LAN Card: 100 Mbps LAN Card
▪ Sistem Operasi: Ubuntu Lucid Lynx 10.04 x86-64 Server Edition
▪ IP Address: 192.168.1.2
• Real Server & Honeypot:
◦ Prosesor: Intel Core i3 530 2.93 GHz
◦ Memori: 4GB DDR3 1333 Hz
◦ Harddisk: 250 GB SATA
◦ LAN Card: 100 Mbps LAN Card
◦ Sistem Operasi: Ubuntu Maverick Meerkat 10.10 x86-64 Server Edition
◦ IP Address: 192.168.1.3 (Realserver), 192.168.1.4 (Realserver),
192.168.1.5 (Honeypot)
• Penyerang:
◦ Prosesor: Intel Core i3 530 2.93 GHz
◦ Memori: 4GB DDR3 1333 Hz
◦ Harddisk: 250 GB SATA
◦ LAN Card: 100 Mbps LAN Card
◦ Sistem Operasi: Ubuntu Maverick Meerkat 10.01 x86-64 Server Edition
◦ IP Address: 192.168.2.7- 192.168.2.10
• Klien:
◦ Prosesor: Intel Pentium 4 2.4 GHz
◦ Memori: 1GB DDR-SDRAM
◦ Harddisk: 400 GB IDE
◦ LAN Card: 100 Mbps LAN Card
◦ Sistem Operasi: Debian Lenny
◦ IP Address: 192.168.2.6
• Router
◦ Cisco Router 871
◦ IOS: c870-advipservicesk9-mz.124- 15.T3
◦ IP Address: 192.168.1.1, 192.168.1.2, 10.151.36.226
5.1.2 Spesifikasi Software
Ada beberapa software tambahan yang digunakan dalam proses uji coba. Software ini berguna untuk menguji fungsionalitas dan performa sistem. Ada 5 software yang digunakan, yaitu hping3, httperf, autobench, apache benchmark, sar, dan lynx.
Berikut ini adalah daftar spesifikasi software yang digunakan dalam ujicoba ini:
• Httperf
◦ Versi: 0.9.0
◦ Dikompilasi dengan FD_SETSIZE = 50000
◦ Fungsi: Mendapatkan performa dari web server (reply rate, packet loss rate, response time, dsb)
• Autobench
◦ Versi: 2.1.2
◦ Fungsi: Secara otomatis menjalankan httperf beberapa kali berdasarkan file konfigurasi.
• Sar
◦ Versi: 9.0.6.1
◦ Fungsi: menghitung penggunaan CPU, Memory, I/O, network selama rentang waktu tertentu
Untuk mendukung jumlah koneksi yang besar, maka perlu merubah jumlah maksimum file descriptor. Standarnya sebesar 1028.
Berdasarkan (O'Rourke dkk, 2001), nilai ini diubah menjadi 50000 dengan menggunakan perintah ulimit –n 50000. Selain itu, httperf harus dikompilasi ulang dengan sebelumnya mengubah nilai __FD_SETSIZE yang ada di file /usr/include/linux/posix_types.h menjadi 50000 juga.
Selain aplikasi-aplikasi pembantu untuk melakukan uji coba, aplikasi lain juga memerlukan konfigurasi khusus agar uji coba performa tidak terlalu terpengaruh oleh konfigurasi aplikasi. Aplikasi yang harus
dikonfigurasi pada tesis ini adalah web server Apache.
Apache perlu diubah konfigurasinya karena jumlah request yang diberikan nanti akan sangat banyak. Apabila tidak dikonfigurasi, maka kegagalan yang terjadi bukan disebabkan konfigurasi LVS, tetapi dari sisi aplikasi yang tidak kuat menanggung beban. Berikut ini adalah tambahan konfigurasi (O'Rourke dkk, 2001) yang perlu ada di apache2.conf.
LogLevel crit MinSpareServers 200 MaxSpareServers 200 MaxClients 1500 MaxRequestsPerChild 0
Gambar 4 Konfigurasi tambahan pada Apache2
5.2. Uji Coba Performa
Uji coba performa ini dilakukan untuk mengetahui performa sistem setelah diadakan perubahan seperti yang telah dijelaskan pada bab sebelumnya. Apakah dapat menghasilkan performa yang lebih baik atau tidak. Untuk uji coba performa ini juga dilakukan uji coba ketika sistem belum ada perubahan sama sekali, sehingga dapat dibandingkan.
Untuk melakukan serangan SYN flood, akan digunakan sebuah aplikasi yang bernama hping3. Hping3 dapat mengirimkan raw IP packet dengan flag-flag tertentu. Pada uji coba ini, dengan hping3, setiap penyerang akan mengirimkan paket TCP SYN ke LVS dengan interval 300 ms dan alamat IP asal yang dipalsukan. Kemudian klien yang sesungguhnya dengan menggunakan autobench dan httperf akan mengakses LVS selama beberapa saat.
Berikut ini adalah parameter-parameter uji coba yang diberikan pada httperf, autobench, hping3, dan sar:
• Httperf dan Autobench
◦ Target Host: 192.168.1.6
◦ Target Port: 80
◦ Ukuran file yang diakses: 3016 byte
◦ Minimum Request Rate: 100 request/s
◦ Penambahan Request Rate: 100 request/s
◦ Maximum Request Rate: 2000 request/s
◦ Total Request yang diinginkan:
30000
◦ Timeout: 2 s
• Hping3:
◦ Target Host: 192.168.1.6
◦ Target Port: 80
◦ Interval: 300 ms
◦ Paket yang dikirim: TCP SYN
• Sar
◦ Interval: 30 s
Setelah uji coba dilakukan, baik sebelum ada perubahan maupun sesudah, maka hasilnya tampak pada grafik dan dibuat trendline untuk memudahkan analisa. Hasilnya dapat dilihat pada Gambar 5 untuk total requests, Gambar untuk reply rate, Gambar untuk persentase error,
Gambar untuk waktu respon.
Gambar 5 Grafik Perbandingan Total Request
Gambar 6 Gambar Perbandingan Reply Rate
Gambar 7 Grafik Perbandingan Waktu Respon
Gambar 8 Grafik Perbandingan Presentase Error
Hasil uji coba berikutnya adalah CPU usage. Berapa persen penggunaan CPU selama sistem ini bekerja. Nilai CPU usage diambil setiap 5 detik selama uji coba berlangsung. Dan
hasilnya dalam bentuk grafik dapat dilihat pada
Gambar .
Gambar 9 Grafik Penggunaan CPU
Seperti terlihat pada grafik penggunaan CPU, Pada detik-detik awal terlihat penggunaan CPU tinggi. Hal ini disebabkan karena sistem deteksi intrusi baru mulai berjalan. Oleh karena itu penggunaan CPUnya lebih tinggi. Tetapi setelah itu relatif tidak menghabiskan penggunaan CPU terlalu banyak.
Dari hasil uji coba performa ini tampak bahwa setelah perubahan pengarahan paket jahat ke honeypot dilakukan, ada selisih tipis menuju ke arah yang lebih baik. Dari hasil perhitungan, total request mengalami peningkatan rata-rata sebanyak 3.8%, total reply/reply rate mengalami peningkatan rata- rata sebanyak 5.91%, presentase error atau packet loss rate mengalami penurunan rata-rata sebanyak 0.97%, waktu respon yang lebih singkat rata-rata 17%, dan penggunaan CPU rata-rata yang hanya 2.5%.
6. SIMPULAN
Pada bab ini akan dibahas mengenai kesimpulan yang dapat diambil dari tujuan pembuatan perangkat lunak, serta hasil uji coba yang telah dilakukan. Selain itu terdapat beberapa saran yang untuk pengembangan lebih lanjut.
6.1. Kesimpulan
Dari hasil pengamatan selama perancangan, implementasi, dan proses uji coba perangkat lunak yang dilakukan, dapat diambil kesimpulan bahwa sistem yang dibuat sudah mampu memenuhi kebutuhan untuk mengarahkan paket-paket jahat ke honeypot dan meminimalisir efek dari serangan DDOS, dan dengan menggunakan sistem ini, jumlah respon yang dapat ditangani server mengalami peningkatan rata-rata sebanyak 5.91% packet loss rate mengalami penurunan rata-rata sebanyak 0.97%. Perubahan paling tampak ada pada waktu respon untuk satu buah request yang mengalami peningkatan sebanyak 17%.
6.2. Saran
Berikut merupakan beberapa saran untuk pengembangan sistem di masa yang akan datang, berdasar pada hasil perancangan, implementasi, dan uji coba yang telah dilakukan.
Penambahan realserver dan honeypot mungkin dapat lebih memperbaiki kinerja sistem.Lalu penggunaan metode penjadwalan selain round-robin dapat juga dicoba.
Dengan data yang didapat di honeypot, dapat dibuat suatu sistem deteksi intrusi yang rule-rulenya dapat berubah secara dinamis.
Penambahan fitur failover pada LVS Director agar apabila LVS Director tidak dapat menangani request lagi, tetap ada penggantinya.
DAFTAR PUSTAKA
Kargl. F, Maier. J, Weber, M. (2001),
“Protecting web servers from distributed denial of service attacks”, Proceedings of the 10th international conference on World Wide Web
Kuwatly. I, Sraj. M, Al Masri. Z, Artail. H.
(2004), “A Dynamic Honeypot Design for Intrusion Detection”, Pervasive Services, 2004. ICPS 2004. IEEE/ACS International Conference., pp. 95- 104
Mirkovic. J, Arikan. E, W. Songjie, Fahmy. S, Thomas. R, Reiher. P. (2006), "Benchmarks for DDOS Defense Evaluation," Military Communications Conference, 2006.
MILCOM 2006. IEEE , pp.1-10, 23-25 Oct.
2006
Narendra. A, Suadi. W, (2009),
“Pengoptimalisasian Kinerja Signature- Based Network Intrusion Detection System
Dengan Memanfaatkan Honeypot Dalam Lingkungan Testbed”, Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Surabaya O'Rourke. P, Keefe. M. (2001), “Performance
Evaluation of Linux Virtual Server”, LISA 2001 15th System Administration Conference, pp 79–92
Peng. T., Leckie. C., dan Ramamohanara., K.
(2007), “Survey of Network-Based Defense Mechanisms Countering the DoS and DDoS Problems”, ACM Comp. Surv. 39, 1, Article 3
Roesch, M. (1999), “Snort – Lightweight Intrusion Detection for Networks”, Proceedings of LISA '99: 13th Systems Administration Conference
Roesch, M. (2010), “Snort 2.8.5 Manual”
Sardana. A, Kumar. K, Joshi. R. (2007),
“Detection and Honeypot Based Redirection to Counter DDoS Attacks in ISP Domain”, Information Assurance and Security, 2007.
IAS 2007. Third International Symposium, pp.191-196, 29-31 Aug. 2007
Zhang. W. (2000), “Linux Virtual Server for Scalable Network Services”
