TINJAUAN TENTANG BUFFER OVERFLOW DAN DENIAL OF SERVICE ATTACK Tugas Akhir Perkuliahan Keamanan Jaringan Informasi (EI-7010) Dosen : Dr. Budi Rahardjo Oleh: BANJAR SADONO NIM : 23202118 MAGISTER TEKNIK ELEKTRO BIDANG KHUSUS TEKNOLOGI INFORMASI PROGRAM PASCA SARJANA INSTITUT TEKNOLOGI BANDUNG 2003 TINJAUAN TENTANG BUFFER OVERFLOW DAN DENIAL OF SERVICE ATTACK I. Abstrak II. Pendahuluan III. Tinjauan Buffer Overflow Dan Denial Of Service 1. Eksploitasi Buffer Overflow a. Deskripsi Buffer Overflow a.1 Manajemen memori pada proses a.2 Stack b. Bahaya Buffer Overflow c. Contoh Eksploitasi Buffer Overflow d. Cara Penanggulangan d.1 Memvalidasi Data d.2 Buffer Non-Executable d.3 Array Bounds Checking d.4 Code Pointer Integrity Checking d.5 Memeriksa Indeks 2. Denial Of Service Attack a. Deskripsi b. Target dan Bahaya Denial of Service Attack b.1 Penggunaan Sumber daya Langka b.1.1 Jaringan Terhubung b.1.2 Menggunakan resource sendiri Untuk Menyerang Diri Sendiri b.1.3 Merusak Bandwidth b.2. Perusakan atau Mengubah Konfigurasi Informasi b.3 Penghancuran Secara fisik atau Perusakan Komponen Jaringan c. Pencegahan dan Penanggulangan d. Target dan bahaya Denial of Service pada Linux d.1 Ruang Swap d.2 Bandwidth d.3 Tabel Kernel d.4 RAM (Random Access Memory) d.5 Inetd e. Cara Penanggulangan III. PENUTUP DAFTAR PUSTAKA LAMPRAN-LAMPIRAN Lampiran 1 CERT® Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks Lampiran 2 CERT® Advisory CA-1996-01 UDP Port Denial-of-Service Attack Lampiran 3 Email Bombing and Spamming Lampiran 4 Anonymous FTP Configuration Guidelines Lampiran 5 CERT® Advisory CA-1996-26 Denial-of-Service Attack via ping Lampiran 6 CERT® Coordination Center UNIX Configuration Guidelines Lampiran 7 List of Security Tools I. Abstrak Ketika sebuah komputer terhubung ke dalam sebuah jaringan komputer baik secara lokal maupun internet, maka salah satu yang harus diperhatikan adalah keamanan dari komputer server. Selain itu komputer yang terhubung dengan server juga harus menjadi perhatian kita. Pertanyaannya apa yang menjadi gangguan tersebut? Banyak yang menjawabnya Hacker lah yang mengganggu sistem jaringan kita. Padahal mungkin karena hanya ketidak sengajaan pegawai atau bug pada sistem operasi dan aplikasi, dapat menjadi bencana bagi jaringan komputer kita. Semakin meningkatnya penggunaan jaringan komputer dewasa ini, semakin meningkat pula serangan terhadap komputer. Beberapa diantaranya dikenal sebagai Buffer Overflow dan Denial of Servis Attack. Buffer overflow memiliki arti suatu keadaan di mana data yang diisikan ke suatu buffer mempunyai ukuran yang lebih besar dibandingkan ukuran buffer itu sendiri. Bahaya yang ditimbulkannya antara lain memori menjadi penuh yang akhirnya berhenti seketika, program yang dijalankan menjadi tidak normal, kadang-kadang justru data-data menjadi hilang karena memori menjadi penuh Denial-of-service merupakan serangan dengan ditandai oleh suatu usaha yang eksplisit dari penyerang untuk mencegah para pemakai yang sah menggunakan jasa pelayanan jaringan. Serangan Denial-Of-Service utamanya bertujuan melumpuhkan komputer atau jaringan. I. Pendahuluan Indonesia ternyata tidak hanya dikategorikan sebagai salah satu negara terkorup di dunia. Dalam soal kejahatan dunia maya (cyber crime), Indonesia juga menempati peringkat teratas. Ironisnya, dari segi penetrasi internet, Indonesia termasuk kategori terendah. Berdasarkan laporan Federal Bureau of Investigation (FBI)- organisasi intelijen resmi Amerika Serikat, Indonesia hanya kalah dari Ukraina dalam soal kejahatan dunia maya. Ada dua modus kejahatan dunia maya yang paling sering dilakukan adalah carding atau memalsukan nomor kartu kredit orang lain untuk mendatangkan berbagai produk komersial yang diperjual belikan lewat internet. Modus ke dua adalah cracking atau merusak/mengacaukan jaringan komputer pihak lain. Menurut Pusat Koordinasi CERT® yang mulai beroperasi tahun 1988, jumlah peristiwa keamanan yang dilaporkan telah meningkat secara dramatis. Tahun 1988 trerjadi serangan kurang dari 100, tetapi meningkat hampir 2,500 insiden di tahun 1995. Peningkatan serangan sepanjang tahun 1994 sejalan dengan pertumbuhan internet selama kurun waktu tersebut. Pada Gambar 1 menunjukkan grafik hubungan pertumbuhan Internet dan peningkatan laporan insidenn keamanan internet. Data untuk tahun 1995 dan data parsial tahun 1996 menunjukkan melambatnya tingkat insiden yang dilaporkan ke CERT/CC, hal ini dimungkinkan adanya usaha meningkatkan keamanan pada situs-situs atau peningkatan secara signifikan dari response team untuk menangani insiden-insiden yang terjadi. Namun demikian, banyaknya insiden yang terjadi terus meningkat khususnya peristiwa-peristiwa serius, seperti root compromises, service outages dan packet sniffers. Gambar 1 Grafik pertumbuhan Serangan Keamanan Selama akhir tahun 1980 dan awal tahun 1990, gangguan yang terjadi umumnya secara terang-terangan. Pengganggu paling sering memanfaatkan kelemahan yang relatif sederhana, seperti lemahnya sistem password dan kesalahan sistem konfigurasi, sehingga terjadi akses yang lebih besar terhadap sistem secara tidak disengaja. Sekali penyusup dapat mengeksploitasi kelemahan suatu sistem, maka akan dengan mudah mereka menggunakan sistem tersebut sesuai keinginannya. Pembuat software biasanya memasarkan produknya dengan setting yang mudah ditembus atau di susup keamanannya. Mengamankan sistem bukanlah suatu hal yang sederhana, dan kebanyakan administrator sistem tidak banyak memiliki waktu, keahlian dan alat-alat bantu untuk memonitor sistem mereka secara baik dari serangan-serangan atau penyusupan. Selama delapan tahun terakhir, penyusup menggunakan teknik dan pengetahuan yang semakin meningkat untuk melakukan penyusupan, mengeskploitasi kelemahan sistem dan membuat perangkat lunak guna menyerang sistem secara otomatis. Pada waktu yang sama, penyusup yang memiliki kemampuan yang rendah akan leluasa dan makin efektif melakukan penyusupan, disebabkan penyusup yang berpengalaman membagikan pengetahuannya kepada penyusup dengan pengetahuan yang rendah. Data/ informasi di era informasi seperti sekarang ini, sudah menjadi suatu aset yang sangat berharga. Bahkan bisa dikatakan sangat fital sehingga kebocoran, kehilangan ataupun kerusakan terhadap data/informasi dari suatu organisasi dapat mengancam kelangsungan hidup orgabisasi yang bersangkutan. Mengingat begitu berharganya suatu data/informasi maka tidaklah heran jika bermunculan beberapa pihak yang tidak bertanggung jawab yang berusaha mencuri maupun mengubah dan merusak data/informasi dari sistem komputer milik suatu organisasi tertentu. Ketika sebuah komputer terhubung ke dalam sebuah jaringan komputer baik secara lokal ataupun ke dunia melewati internet, maka yang harus diperhatikan adalah keamanan dari komputer server tersebut. Selain komputer server tersebut tidak boleh luput dari perhatian keamanan dari komputer-komputer lain yang juga terhubung dengan komputer server tadi. Namun yang akan dibahas disini adalah gangguan apa saja yang dapat terjadi pada sebuah komputer server apabila terhubung dalam sebuah jaringan atau internet, Kebanyakan orang berfikir bahwa gangguan keamanan yang mungkin terjadi adalah disebabkan oleh hacker dari luar. Dalam bahasan tentang keamanan sistem perlu diperhatikan semua sebab yang mungkin menjadi faktor gangguan keamanan itu terjadi. Sebagai contoh adalah seorang penyusup yang mempunyai dendam, ketidak sengajaan seorang pegawai, bug pada sistem operasi dan aplikasi di dalamnya atau kesalahan dalam konfigurasi. Berikut ini akan dipaparkan gangguan keamanan yang berpengaruh bagi keamanan pada komputer server. II. Tinjauan Buffer Overflow Dan Denial Of Service 1. Eksploitasi Buffer Overflow Dari sekian banyak penyebab masalah keamanan pada komputer, baik yang bersifat lokal maupun jaringan, buffer overflow termasuk salah satu penyebab yang paling banyak dilakukan. Menurut laporan CERT/CC, buffer overflow merupakan penyebab dari 50% semua bug keamanan yang dilaporkan dan dijadikan advisori oleh CERT/CC. Lebih jauh lagi, riset yang dilakukan oleh Crispin Cowan dan kawan-kawan, menganggap buffer overflow sebagai vulnerability of the Decade. Buffer overflow merupakan sebuah kelemahan yang mudah untuk ditemukan dan dimanfaatkan oleh penyerang dalam sebuah sistem. Aplikasi dan Operating System (OS) menyimpan untuk sementara perintah yang mereka dapat di memori tertentu yang biasa disebut buffer memory. Kalau OS atau program tidak bisa dikode secara sempurna maka penyerang bisa membuat komputer korban jadi terganggu dengan mengirimkan perintah yang dibuat khusus, membuat gangguan jadi berlangsung lebih lama. Windows 95 paling rentan kalau sudah berhadapan dengan serangan seperti “buffer overflow” yang banyak dilancarkan lewat internet ini. Saat ini serangan serupa sudah jarang dilancarkan pada sebuah komputer. Namun terkadang penyerang masih sering melakukannya untuk memperlambat kinerja sebuah situs. a. Deskripsi Buffer Overflow Untuk mengetahui apakah sebenarnya buffer overflow dan bagaimana cara kerja untuk mengekploitasinya, maka diperlukan pemahaman tentang cara kerja sistem processor di level bawah, seperti pemrograman assembly, manajemen memory text, stack, data dan sebagainya. Selain itu bagi pengguna sistem operasi Linux, pengalaman program debug gdb akan sangat membantu. Berikut ini istilah-istilah dasar untuk memahami penjelasan berikut mengenai buffer overflow. a.1 Manajemen memori pada proses Sebuah proses jika dilihat dari sudut manajemen memori, dapat dibedakan menjadi tiga bagian . • Text, memuat instruksi kode program. Bagian ini biasanya hanya bisa dibaca dan setiap usaha untuk menuliskan data ke bagian ini akan menyebabkan kesalahan segmentation violation. • Data, memuat data, baik yang telah diinisialisasikan maupun yang belum. Selain dapat dibaca, biasanya bagian ini juga dimanipulasi suatu instruksi untuk melakukan penulisan padanya. • Stack, yang dapat dialokasikansecara dinamis, biasanya dimanfaatkan untuk menyimpan variabel lokal maupun untuk melewatkan parameter fungsi. Pengaksesan data kebagian ini menggunakan metode yang disebut LIFO (Last In First Out) seperti yang nanti akan diterangkan secara lebih rinci. Jenis data yang juga patut diketahui adalah sebagai buffer yang pada bahasa C diimplementasikan sebagai array. Array dapat dibedakan ke dalam dua jenis berdasarkan metode pengalokasiannya, yaitu array statis dan array dinamis. Array statis dialokasikan dibagian data saat program dimuat ke memory, sedangkan array dinamis dialokasikan di dalam stacj saat run time. a.2 Stack Stack dapat dibayangkan sebagai sebuah blok dan memori yang dapat memuat data secara dinamis. Beberapa hal yang patut diketahui pada processor Intel sehubungan dengan stack adalah sebagai berikut.  Penggunaan metode Big Endian dalam mengorganisasikan sistem memori. Disini MSB (Most Significant Bit) terletak pada alamat memori yang lebih kecil dibandingkan LSB (Low Significant Bit).  Penambahan besar stack dilakukan ke arah alamat memori yang lebih kecil. Disini posisi bawah dari stack mempunyai alamat yang tetap. Posisi atas stack yang alamat memorinya lebih kecil dari posisi bawah selalu berubah.  Register stack pointer (SP) selalu menunjuk keposisi atas dari stack.  Untuk memindahkan data ke stack digunakan instruksi PUSH yang secara otomatis akan menurunkan nilai SP sebesar 4 byte. Sedangkan untuk mengambil data dari stack digunakan instruksi POP yang secara otomatis juga akan menaikkan nilai SP sebesar 4 byte. Gambar 2 di bawah memperlihatkan diagram dari sebuah stack pada prosessor Intel. Gambar 2 Stack Pada Memori Blok memori dari stack ini biasanya dibagi lagi menjadi apa yang disebut dengan register stack frame. Setiap register stack frame berisi data yang berhubungan dengan pemanggilan suatu fungsi. Biasanya posisi awal dari frame ini ditunjukkan oleh frame pointer (FT). Dengan bantuan FP ini, maka pengaksesan ke variabel lokal maupun parameter fungsi dapat dilakukan menggunakan sistem pengalamatanm relatif. Pada CPU Intel, register EBP berfungsi sebagai frame pointer. Setelah bahasan di atas, sekarang akan dijelaskan pengertian buffer overflow. Buffer overflow memiliki arti suatu keadaan di mana data yang diisikan ke suatu buffer mempunyai ukuran yang lebih besar dari dibandingkan ukuran buffer itu sendiri. Untuk lebih memahami buffer overflow, mungkin dapat kita temukan padanannya dalam kehidupan sehari-hari, yaitu saat ember diisi dengan air, sehingga air yang dituangkan sampai meluap ( overflow). Sedangkan pada eksploitasi buffer overflow, secara prinsip ada dua hal penting yang harus dilakukan dalam proses eksploitasi buffer overflow, yaitu sebagai berikut. 1. Pertama harus membuat instruksi yang kita kehendaki agar dijalankan setelah buffer ter overflow. Instruksi ini biasanya berupa kode assembly ini harus dikonversi ke data heksadesimal. 2. Kedua, harus memperhitungkan alamat posisi RET dalam stack dan alamat kode instruksi tersebut. Kemudian alamat kode instruksi ini harus dimasukkan ke dalam nilai RET, sehingga jika buffer ter overflow instruksi tersebut dijalankan . e. Bahaya Buffer Overflow Dari deskripsi di atas dapat disimpulkan bahaya yang bisa ditimbulkan oleh eksploitasi buffer overflow adalah sebagai berikut. b.1 Pemanipulasian dan pengrusakan data stack dimemori sehingga suatu program yang memerlukan data tersebut akan mengalami gangguan dalam prosesnya. b.2 apabila suatu program atau aplikasi dijalankan maka instruksi-insruksi dari program tersebut akan disimpan dalam memori. Dengan memanfaatkan eksploitasi buffer overflow seorang pengganggu dapat memanipulasi instruksi-instruksi pada memori dengan instruksi yang diinginkannya. c. Contoh Eksploitasi Buffer Overflow Berikut adalah contoh program yang ditulis dengan bahasa C yang mengandung buffer overflow. Program di atas apabila dikompilasi dan dijalankan pada sistem operasi Linux akan didapatkan pesan segmentation violation. Hal ini disebabkan pada fungsi fungsi() bariabel array buffer didefinisikan hanya berukuran 4 byte, sedangkan data yang disalinkan kepadanya berukuran 17 byte. Contoh lain dapat dilihat pada program di bawah ini. Program di atas merupakan program kecil untuk memodifikasi nilai RET (return address) sehingga instruksi yang seharusnya dikerjakan setelah pemanggilan suatu fungsi akan dilompati. Seharusnya karena nilai a terakhir di isi dengan nilai 2, tapi pada program di atas instruksi a=2 yang seharusnya dikerjakan setelah kembali dari fungsi akan dilompati. Sehingga nilai dari a yang dikeluarkan pada layar adalah 1. d. Cara Penanggulangan Berikut adalah tindakan yang bisa dilakukan untuk menghindari terjadinya eksploitasi buffer overflow. Dari sisi seorang pemrogram. d.1 Memvalidasi Data Sebuah program yang berjalan dengan privilge tinggi, mengharuskan untuk melindungi semua data dan harus menganggap semua data yang masuk patut dicurigai. Perhatikan contoh potongan program berikut. Kode di atas berbahaya karena array nama tidak dibatasi besarnya. Solusi yang lebih baik adalah sebagai berikut. Yang membatasi string nama yang dimaksukkan sebesar 255 karakter. Selain memeriksa ukuran input yang dimasukkan, program juga harus memeriksa bahwa data yang dimasukkan adalah data yang valid. Misalnya, jika program meminta input berupa tipe data interger, maka program harus memastikan bahwa input yang diberikan oleh user benar-benar bertipe integer, bukan tipe lainnya. d.2 Buffer Non-Executable Konsepnya adalah membuat segment data sebuah program tidak dapat dieksekusi. Dengan menjadikannya tidak dapat dieksekusi, maka tidaklah mungkin bagi penyerang untuk mengeksekusi kode yang mereka masukkan ke buffer input program korban. Cara ini digunakan pada sistem operasi komputer lama, tetapi pada sistem operasi UNIX dan MS Windowsteknik ini tidak digunakan, karena keduanya tergantung pada kemampuan memasukkan kode dinamis ke dalam segment data program untuk mendukung berbagai optimisasi kinerja. d.3 Array Bounds Checking Meskipun memasukkan kode adalah sebuah tindakan pilihan bagi serangan buffer overflow, pengkorupsian aliran kendali merupakan hal yang penting. Dengan menggunakan metode array bound checking akan menghentikan vunerability dan serangan buffer overflow.Jika sebuah array tidak dapat di-overflow, maka array tidak dapat digunakan untuk mengkorupsi program yang terletak di alamat memori berikutnya. Untuk mengimplementasikan metode ini, semua pembacaan dan penulisan ke array yang harus diperiksa untuk memastikan bahwa mereka tidak melampaui batasan array. d.4 Code Pointer Integrity Checking Tujuan dar metode ini agak berbeda dengan bounds cheking. Alih-alih berusaha mencegah korupsi kode pointer, ia berusaha mendeteksi bahwa sebuah kode pointer telah terkorupsi sebelum ia dideferensikan. Jadi meskipun penyerang sukses dalam mengkorupsi kode pointer, kode pointer yang terkorupsi tidak akan digunakan karena korupsi terdeteksi setiap saat sebelum digunakan. d.5 Memeriksa Index Indeks yang digunakan untuk memanipulasi sebuah array harus diperiksa dengan teliti. Perhatikan contoh kode di bawah ini. 2. Denial Of Service Attack . Sumber daya jaringan yang sangat berharga antara lain komputer, database dan layanan-layanan lain yang disediakan oleh jasa jaringan. Jaringan ini sangat dibutuhkan oleh user dikarenakan layanan-layanan tersebut memudahkan pekerjaan sehingga pekerjaan tersebut lebih efisien. Bila layanan ini rusak atau tidak dapat bekerja, maka akan menyebabkan hilangnya produktifitas. Hal-hal yang menyebabkan jaringan tidak bekerja dapat berupa apa saja termasuk worm yang seringkali melumpuhkan sejumlah besar komputer di dunia. Penyebab denial of service diantaranya adalah sebagai berikut.  Kemungkinan jaringan menjadi tidak befungsi disebabkan kebanjiran jalur lalu lintas.  Kemungkinan jaringan dipartisi dengan cara membuat komponen jaringan seperti router ang menjadi penghubung jaringan tidak berfungsi.  Kemungkinan ada virus yang menyebar dan menyebabkan sistem komputer menjadi lambat atau bahkan lumpuh.  Kemungkinan device yang melindungi jaringan dirusakkan. Penggunaan sumber daya yang illegal dapat pula mengakibatkan denial of service . Sebagai contoh, suatu penyerang dapat menggunakan wilayah ftp area tak bertuan sebagai tempat untuk menyimpan salinan yang tidak sah suatu perangkat lunak komersil, memanfaatkan ruang disk dan memadatkan lalu lintas jaringan. a. Deskripsi Denial of Service Attack lebih dikenal dengan istilah DoS attack. Serangan ini dilakukan untuk tujuan mematikan salah satu atau semua layanan yang ada pada suatu sistem tanpa permisi dari penguasa sistem. Denial-of-service attack merupakan sebuah upaya serangan dengan jalan menurunkan kinerja sebuah web site dengan terus menerus mengulang request ke server dari banyak sumber secara simultan. Tujuan serangan seperti ini berakibat server korban jadi kewalahan melayani request yang terkirim dan berakhir dengan menghentikan aktivitas atau berhenti dengan sendirinya karena tak mampu melayani request. Kadang serangan yang dilakukan dengan cara ini dapat merusak atau mematikan sistem secara keseluruhan. Denial-of-service merupakan serangan dengan ditandai oleh suatu usaha yang eksplisit dari penyerang untuk mencegah para pemakai yang sah menggunakan jasa pelayanan jaringan. Contohnya meliputi :  mencoba untuk membanjiri suatu jaringan, dengan demikian menghambat lalu lintas jaringan yang ada,  mencoba untuk mengganggu koneksi antar komputer, sehingga jasa pelayanan menjadi terhambat,  mencoba untuk mencegah individu tertentu untuk mengakses suatu layanan,  mencoba untuk mengganggu pelayanan seseorang atau suatu sistem yang spesifik. Jenis serangan lainnya dapat meliputi denial of service sebagai komponen, tetapi denial of service dapat berupa bagian dari serangan yang lebih besar. Penggunaan sumber daya yang illegal dapat pula mengakibatkan denial of service . Sebagai contoh, suatu penyerang dapat menggunakan wilayah ftp area tak bertuan sebagai tempat untuk menyimpan mencuri data suatu perangkat lunak komersil, memanfaatkan ruang disk dan memadatkan lalu lintas jaringan. b. Target dan Bahaya Denial of Service Attack Serangan Denial-Of-Service utamanya bertujuan melumpuhkan komputer atau jaringan. Tergantung pada sifat alami perusahaan, hal ini yang secara efektif melumpuhkan organisasi.. Beberapa serangan denial-of-service dapat dieksekusi dengan sumber daya terbatas melawan terhadap suatu situsbesar yang canggih . Serangan jenis ini kadang-kadang disebut/dipanggil suatu " serangan tidak simetris (asymmetric attack)." Sebagai contoh, suatu penyerang dengan sebuah PC tua dan sebuah modem yang lambat mungkin mampu melumpuhkan banyak jaringan atau mesin yang lebih canggih dan lebih cepat. Serangan Denial-Of-Service terdiri dari berbagai bentuk dan jenis layanan. Ada tiga jenis dasar serangan yaitu :  penggunaan hal yang langka, terbatas, atau sumber daya tidak dapat diperbarui,  perusakan atau perubahan konfigurasi informasi,  perusakan secara fisik atau perubahan komponen-komponen jaringan. b.1 Penggunaan Sumber daya Langka Komputer Dan Jaringan memerlukan berbagai hal tertentu untuk beroperasi: bandwith jaringan, memori dan ruang penyimpan, CPU time, struktur data, mengakses ke komputer dan jaringan lainnya, dan sumber daya lingkungan tertentu seperti power, pendingin udara, atau bahkan air. b.1.1 Jaringan Terhubung Serangan Denial-Of-Service yang paling sering dilakukan yaitu menyerang hubungan komunikasi antara server dan client. Tujuannya adalah untuk mencegah host atau jaringan saling berkomunikasi. Suatu contoh serangan jenis ini adalah " SYN Flood" membanjiri dengan request. Untuk lebih jelasnya dapat dilihat pada situs berikut. {terdapat juga pada Lampiran 1) http://www.cert.org/advisories/CA-1996-21.html Pada serangan jenis ini, penyerang memulainya dengan proses menetapkan suatu koneksi kepada mesin korban. Meskipun demikian maksud penyerang sebenarnya akan menghambat komputer korban berkomunikasi dengan komputer lain. .Pada saat komputer korban memesan sejumlah struktur data yang diperlukan. Setelah proses permintaan selesai, komputer korban menyudahi koneksi. Hasilnya adalah bahwa koneksi yang sah ditolak pada saat komputer korban sedang menanti untuk melengkapi koneksi. Perlu dicatat bahwa serangan jenis ini tidak tergantung pada penyerang tersebut memakai besarnya bandwidth jaringan. Dalam hal ini, pengganggu sedang menggunakan kernel struktur data dengan melibatkan suatu koneksi jaringan. Akibatnya adalah bahwa pengganggu dapat melaksanakan penyerangan dari suatu dial-up koneksi menyerang suatu mesin jaringan sdengan sangat cepat. ( Ini adalah suatu contoh yang baik dari suatu serangan asymetric.) b.1.2 Menggunakan resource sendiri Untuk Menyerang Diri Sendiri Pengganggu dapat juga menggunakan sumber daya milik kita melawan kita sendiri dengan cara yang tak diduga. Satu contoh diuraikan pada web berikut ini. (Dapat pula dilihat pada Lampiran 2). http://www.cert.org/advisories/CA-1996-01.html Penyerang menggunakan paket UDP untuk menghubungkan getaran pelayanan pada suatu mesin ke mesin lain. Hasilnya adalah dua penguna yang mengkonsumsi semua bandwidth yang tersedia. Sehingga koneksitas jaringan untuk semua komputer pada jaringan yang sama akan saling mempengaruhi utamanya pada komputer target. b.1.3 Merusak Bandwidth Seorang penyerang dapat memakan semua bandwidth yang tersedia pada jaringan dengan mengirimkan sejumlah besar paket yang langsung diarahkan pada jaringan tersebut. Secara khusus, paket ini adalah paket ICMP ECHO, tetapi pada prinsipnya mereka dapat berupa apapun. Lebih lanjut, pengganggu tidak perlu beroperasi dari sebuah komputer; bisa jadi ia bekerja dari beberapa komputer yang beroperasi dijaringan yang berbeda dengan efek yang sama b.1.4. Konsumsi Resource Yang Lain Penyerang dapat pula memnfaatkan sumber daya lain dalam jaringan untuk menyerang. Sebagai contoh, dalam beberapa sistem, terdapat struktur data berupa proses informasi seperti proses identifikasi, proses masukan data dan sebagainya.Seorang penyerang dengan menggunakan hanya beberapa perintah singkat dapat menyalin catatatan-catatan tersebu berulang-ulangt. Banyak sistem operasi modern mempunyai fasilitas kuota untuk melindungi dari masalah ini, tetapi tidak semua dilakukan. Penyerang dapat pula untuk menggunakan ruang disk dengan cara-cara lain, seperti.  Meningkatkan jumlah pesan mail secara berlebihan (email Bombing). Untuk informasi lebih jauh dapat dilihat.pada site berikut. (dapat pula dilihat pada Lampiran 3). http://www.cert.org/tech_tips/email_bombing_spamming.html  dengan sengaja meningkatkan kesalahan yang harus dicatatm  menempatkan file pada wilayah ftp tanpa nama dalam jaringan atau pada jaringan bersama, Untuk informasi bentuk wujud ftp tanpa nama, dapat dilihat pada site berikut atau pada Lampiran 4. http://www.cert.org/tech_tips/anonymous_ftp_config.html Secara umum, apapun yang mengijinkan data untuk ditulis ke disk dapat digunakan untuk melaksanakan suatu serangan denial-of-service jika tidak ada batas berapa jumlah data yang dapat ditulis. Juga, banyak situs merancang menempatkan "lockout" suatu account setelah sejumlah login gagal dicoba. Suatu kunci dapat dipasang 3 sampai 5 kali login, jika gagal user tidak diperkenankan lagi bekerja. Seorang penyerang mungkin mampu menggunakan rancangan ini untuk mencegah para pemakai yang sah untuk masuk. Dalam beberapa kasusl, bahkan account yang diistimewakan, seperti administrator, dapat dijadikan subyek serangan jenis ini. Pastikan kita mempunyai suatu metoda untuk memperoleh akses ke sistem bila terjadi keadaan darurat. Konsultasikan pada penjual sistem operasi atau baca manual sistem operasi secara cermat untuk fasilitas larangan bekerja dan masukan dalam keadaan darurat. Seorangpenyerang dapat) menyebabkan sistem hancur atau menjadi tidak stabil dengan pengiriman data tak diduga (tas jaringan]. Sebagai contoh tentang serangan seperti diuraikan diatas dapat dilihat pada web berikut (dapat dilihat pula pada Lampiran 5).. http://www.cert.org/advisories/CA-1996-26.html Jika sistem yang sedang berjalan mengalami kerusakan dengan tidak ada penyebabnya yang jelas, bisa jadi itu adalah hasil serangan jenis ini . Ada berbagai hal lain yang mungkin peka terhadap denial of service, meliputi :  alat pencetak,  peralatan tape,  network connections,  Resources yang penting dalam operasi organisasi. b.2. Perusakan atau Mengubah Konfigurasi Informasi Sebuah komputer yang kurang bak untuk dioperasikan sebaiknya tidak dioperasikan sama sekali. Seorangpenyerang dapat mengubah atau menghancurkan konfigurasi informasi dan menghambat dari penggunaan jaringan atau komputer. Sebagai contoh, jika perusak dapat merubah informasi routing pada router, jaringan menjadi lumpuh (disabled). Jika penyerang dapat memodifikasi registry pada komputer Windows NT, berakibat fungsi tertentu menjadi hilang (unvailable). Untuk informasi tentang configurasi UNIX dapat dilihat pada web berikut atau pada Lampiran 6 : http://www.cert.org/tech_tips/unix_configuration_guidelines.html Untuk informasi tentang configurasi Microsoft Windows NT dapat dilihat pada: http://www.microsoft.com/security/ b.3 Penghancuran Secara fisik atau Perusakan Komponen Jaringan Perhatian yang utama dengan jenis serangan ini adalah keamanan secara fisik. Perlu menjaga komputer dari akses yang tidak bertanggung jawab seperti, router, wiring closet, jaringan backbone, power dan stasiun pendingin, dan komponen lain yang peka pada jaringan. Keamanan secara fisik merupakan suatu komponen yang penting untuk dijaga dari jenis serangan denial of service. Untuk informasi keamanan terhadap komponen fisik ini, disarankan untuk berkonsultasi terhadap perusahaan keamanan jaringan. c. Pencegahan dan Penanggulangan Serangan denial of service dapat mengakibatkan hilangnya waktu berharga dan biaya suatu organisasi. Serangan ini dapat dipertimbangkan untuk ditanggulangi bila tidak ingin menghadapi resiko yang lebih besar. Beberapa pertimbangn berikut dapat diikuti sebagai saran mengatasi serangan denial of service.  Menerapkan router filters untuk mengurangi ekspose denial-of-service.  Instal program guard untuk menjaga dari membanjirnya e-mail yang tidak dikehendaki. Pada hakekatnya cara ini dapat mengurangi serangan denial of service.  Buang beberapa servis jaringan yang tidak diperlukan atau tak terpakai. Hal ini dapat membatasi kemampuan penyerang untuk mengambil keuntungan dari semua servis itu guna melaksanakan suatu serangan denial-of-service.  Buatlah sistem kuota pada sistem operasi jika layanan tersebut tersedia. Sebagai contoh, jika sistem operasi mendukung kuota penyimpanan, memungkinkan untuk mengijinkan pemakaian jaringan, khususnya account yang diijiinkan mengoperasikan jaringan. Sebagai tambahan, jika sistem operasi mendukung partisi atau volume ( yaitu., sistem file secara terpisah dengan atribut mandiri) dapat dipertimbangkan mempartisi sistem file supaya dipisahkan antara fungsi yang peka dari aktivitas lainnya.  Amati terus kegiatan sistem dan tetapkan batas-batas untuk aktivitas biasa. Gunakan batasan untuk mengukur tingkatan aktivitas disk yang tidak lazim, pemakaian CPU, atau lalu lintas jaringan.  Secara rutin menguji keamanan fisik komputer berkenaan dengan kebutuhan saat ini. Pertimbangkan server, router, terminal tanpa kendali, jaringan acces point, wire closet, sistem lingkungan seperti udara dan power, dan komponen lain dari sistem.  Gunakan Tripwire atau suatu alat serupa untuk mendeteksi perubahan konfigurasi informasi atau file lainnya. Untuk informasi lebih lanjut , lihat pd web berikut atau Lampiran 7 http://www.cert.org/tech_tips/security_tools.html  Menyiapkan modal untuk penggantian perangkat dan pemeliharaan mesin yang dapat dioperasikan sewaktu-waktu bila ada komputer yang mengalami serangan.  Secara reguler ditetapkan jadual pemeliharaan dan backup data terutama informasi-informasi yang penting.  Tentukan kebijakan pembaharuan kata sandi yang sesuai dan memperbaiki sandi secara reguler terutama bagi account yang khusus seperti administrator. d. Target dan bahaya Denial of Service pada Linux Pada sistem operasi Linux banyak target yang bisa digunakan untuk tujuan mematikan service pada sistem atau sistem secara keseluruhan. Berikut adalah target yang dapat digunakan sasaran serangan. d.1 Ruang Swap Ruang swap pada sistem operasi Linux biasanya digunakan sebagai Ivirtual memory. Ruang ini akan menyimpan file-file sementara yang biasa digunakan pada saat suatu program dijalankan. Dengan cara menghabiskan ruang kosong pada swap akan ada program-program yang tidak dapat dijalankan karena tidak adanya ruang untuk menampung file-file sementara dari aplikasi tersebut. Selain hal tersebut gangguan yang lain adalah matinya service-service yang ada pada sistemdan tidak dapat dipenuhinya request dari user karena penuhnya ruang swap ini. d.2 Bandwidth Target lain dari serangan DoS adalah dengan cara memenuhi bandwidth yang tersedia hingga komunikasi pada jaringan menjadi berat atau mati. d.3 Tabel Kernel Alokasi memory pada kernel merupakan salah satu target yang dapat digunakan sasaran serangn. Kernel mempunyai batas pada kernel map, jika sistem telah mencapai batasnya dan tidak bisa memakai memori kernel lagi maka yang harus dilakukan adalah me-reboot sistem. Memori kernel tidak hanya digunakan oleh RAM dan CPU saja , tapi juga digunakan oleh proses biasa. Sehingga dengan pemakaian proses yang terlalu banyak akan menyebabkan sistem harus di reboot. d.4 RAM (Random Access Memory) Penggunaan sejumlah besar RAM akan menyebabkan masalah pada sistem. Penggunaan RAM yang berlebihan pada sistem tentnya akan menyebabkan sistem bekerja berat dan untuk menguranginya, sistem dengan sendirinya akan mematikan layanan atau aplikasi yang tidakdiprioritaskan. d.5 Inetd Inetd adalah daemon pada sistem operasi Linux yang gunanya untuk menghidupkan service-service lain seperti telnetd, ftp atau service untuk mail server. Dengan mematikan inetd tentunya akan banyak service yang akan mati. e. Cara Penanggulangan Untuk menghindari sistem dari keadaan di atas yang bisa dilakukan adalah sebagai berikut.  Melakukan aturan quota pada user-user yang ada pada sistem seningga ada pembatasan jumlah file dan besar ruang yang dimiliki oleh user-user tersebut.  Melakukan pembatasan banyaknya proses yang bisa dibuat oleh uses sehingga file-file temporry (sementara) yang dibuat oleh proses tersebut akan terbatas juga. IV. PENUTUP Data/Informasi sangat penting artinya bagi suatu organisasi dewasa ini. Kadang kala Informasi merupakan aset yang sangat fital, sehingga kerusakan, kehilangan dan kebocoran suatu informasi merupakan malapetaka bagi suatu organisasi. Mengingat data/informasi berlalu lalang di jaringan komputer, maka sangat dimungkinkan informasi tersebut disadap, didengar bahkan dicuri orang-orang yang tidak bertanggung jawab. Kadang-kadang tanpa sengaja informasi menjadi hilang atau bahkan diberikan kepada orang yang tidak berhak. Dari tahun ke tahun pemakaian jaringan komputer semakin meningkat, sehingga semakin banyak serangan terhadap jaringan komputer. Hal demikian mengakibatkan keamanan jaringan merupakan salah satu perhatian yang tidak dapat dihindari lagi. Terdapat berbagai macam serangan terhadap jaringan komputer, diantaranya adalah Buffer Overflow dan Denial of Service. Buffer overflow memiliki arti suatu keadaan di mana data yang diisikan ke suatu buffer mempunyai ukuran yang lebih besar dari dibandingkan ukuran buffer itu sendiri. Buffer overflow merupakan penyebab dari 50% semua bug keamanan yang dilaporkan dan dijadikan advisori oleh CERT/CC. Buffer overflow merupakan sebuah kelemahan yang mudah untuk ditemukan dan dimanfaatkan oleh penyerang dalam sebuah sistem. Denial of Service Attack lebih dikenal dengan istilah DoS attack, merupakan serangan ini dilakukan untuk tujuan mematikan salah satu atau semua layanan yang ada pada suatu sistem tanpa permisi dari penguasa sistem. Sistem yang diserang dapat berakibat fatal yaitu menurunnya kinerja sebuah web, sehingga server korban akan kuwalahan melayani request yang datang berulang-ulang, yang berakhir dengan terhentinya server tersebut. Beberapa langkah mengatasi serangan buffer overflow adalah sebagai berikut.  Memvalidasi Data.  Buffer Non-Executable.  Array Bounds Checking.  Code Pointer Integrity Checking.  Memeriksa Index. Adapun cara pencegahan dari serangan Denial Of Service adalah sebagai berikut.  Melakukan aturan quota pada user-user yang ada pada sistem seningga ada pembatasan jumlah file dan besar ruang yang dimiliki oleh user-user tersebut.  Melakukan pembatasan banyaknya proses yang bisa dibuat oleh uses sehingga file-file temporry (sementara) yang dibuat oleh proses tersebut akan terbatas juga Daftar Pustaka [1] Faisal, Reza , M, “Studi dan Konfigurasi Keamanan Internet Pada Server Berbasis Linux”, Skripsi 2002 [2] Majalah linux Edisi No. 09/I/2001 [3] Gerhard Mourani “Securing and Optimizing Linux: RedHat Edition”, Open Network Architecture and OpenDocs Publishing, 2000 [4] Crispian Cowan, Ph.D, “The immunix Bastion Server Appliance for Security Application”. WireX Communications, Inc, Oregon, 2000 [5] Crispian Cowan, Perry Wagle, Calton Pu, Steave Beattie, and Jonathan Walpole, “Buffer Overflows : Attacks and Deffence for the Vulnerability of the Decade”, WireX Communications, Inc, Oregon, 2000 [6] Crispian Cowan, Calton Pu, Dave Maier, Heather Hinton, Jonathan Walpole, Peat Bakke, Steave Beattie, Aaron Grier, Perry Wagle and Qiang Zhang : “StackGuard: Automatic Adaftive Detection and Prevention of Buffer Overflow Attacks”, WireX Communications, Inc, Oregon, 2000 [7] Jason T. Murphy:”Security under Linux : the Buffer Overflow problem”. http://www.ecst.csuchico.edu/-jtmurphy, 1998 [8] Ono, W, Purbo, “Keamanan Jaringan Internet”, Elex Media Komputindo, Jakarta, 2001 [9] No Name, “Denial of Service Attacks”, http://www.cert.org/, Oktober 2003 [10] Wood, D, Anthony, Stankovic, A, John, “Denial of Service in Sensor Networks”, http://www.cs.virginia.edu/~adw5p/pubs/computer02-dos.pdf, Oktober 2003 LAMPIRAN-LAMPIRAN Lampiran 1 CERT® Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks Original issue date: September 19, 1996 Last revised: November 29, 2000 Updated vendor information for the Linux kernel. A complete revision history is at the end of this file. This advisory supersedes the IP spoofing portion of CA-95.01. Two "underground magazines" have recently published code to conduct denial-of-service attacks by creating TCP "half-open" connections. This code is actively being used to attack sites connected to the Internet. There is, as yet, no complete solution for this problem, but there are steps that can be taken to lessen its impact. Although discovering the origin of the attack is difficult, it is possible to do; we have received reports of attack origins being identified. Any system connected to the Internet and providing TCP-based network services (such as a Web server, FTP server, or mail server) is potentially subject to this attack. Note that in addition to attacks launched at specific hosts, these attacks could also be launched against your routers or other network server systems if these hosts enable (or turn on) other TCP services (e.g., echo). The consequences of the attack may vary depending on the system; however, the attack itself is fundamental to the TCP protocol used by all systems. If you are an Internet service provider, please pay particular attention to Section III and Appendix A, which describes step we urge you to take to lessen the effects of these attacks. If you are the customer of an Internet service provider, please encourage your provider to take these steps. This advisory provides a brief outline of the problem and a partial solution. We will update this advisory as we receive new information. If the change in information warrants, we may post an updated advisory on comp.security.announce and redistribute an update to our cert-advisory mailing list. As always, the latest information is available at the URLs listed at the end of this advisory. ________________________________________ I. Description When a system (called the client) attempts to establish a TCP connection to a system providing a service (the server), the client and server exchange a set sequence of messages. This connection technique applies to all TCP connections--telnet, Web, email, etc. The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then open, and the service-specific data can be exchanged between the client and the server. Here is a view of this message flow: Client Server ------ ------ SYN--------------------> <--------------------SYN-ACK ACK--------------------> Client and server can now send service-specific data The potential for abuse arises at the point where the server system has sent an acknowledgment (SYN-ACK) back to client but has not yet received the ACK message. This is what we mean by half-open connection. The server has built in its system memory a data structure describing all pending connections. This data structure is of finite size, and it can be made to overflow by intentionally creating too many partially-open connections. Creating half-open connections is easily accomplished with IP spoofing. The attacking system sends SYN messages to the victim server system; these appear to be legitimate but in fact reference a client system that is unable to respond to the SYN-ACK messages. This means that the final ACK message will never be sent to the victim server system. The half-open connections data structure on the victim server system will eventually fill; then the system will be unable to accept any new incoming connections until the table is emptied out. Normally there is a timeout associated with a pending connection, so the half-open connections will eventually expire and the victim server system will recover. However, the attacking system can simply continue sending IP-spoofed packets requesting new connections faster than the victim system can expire the pending connections. In most cases, the victim of such an attack will have difficulty in accepting any new incoming network connection. In these cases, the attack does not affect existing incoming connections nor the ability to originate outgoing network connections. However, in some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative. The location of the attacking system is obscured because the source addresses in the SYN packets are often implausible. When the packet arrives at the victim server system, there is no way to determine its true source. Since the network forwards packets based on destination address, the only way to validate the source of a packet is to use input source filtering (see Appendix A). II. Impact Systems providing TCP-based services to the Internet community may be unable to provide those services while under attack and for some time after the attack ceases. The service itself is not harmed by the attack; usually only the ability to provide the service is impaired. In some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative. III. Solution There is, as yet, no generally accepted solution to this problem with the current IP protocol technology. However, proper router configuration can reduce the likelihood that your site will be the source of one of these attacks. Appendix A contains details about how to filter packets to reduce the number of IP-spoofed packets entering and exiting your network. It also contains a list of vendors that have reported support for this type of filtering. NOTE to Internet Service Providers: We STRONGLY urge you to install these filters in your routers to protect your customers against this type of an attack. Although these filters do not directly protect your customers from attack, the filters do prevent attacks from originating at the sites of any of your customers. We are aware of the ramifications of these filters on some current Mobile IP schemes and are seeking a position statement from the appropriate organizations. NOTE to customers of Internet service providers: We STRONGLY recommend that you contact your service provider to verify that the necessary filters are in place to protect your network. Many networking experts are working together to devise improvements to existing IP implementations to "harden" kernels to this type of attack. When these improvements become available, we suggest that you install them on all your systems as soon as possible. This advisory will be updated to reflect changes made by the vendor IV. Detecting an Attack Users of the attacked server system may notice nothing unusual since the IP-spoofed connection requests may not load the system noticeably. The system is still able to establish outgoing connections. The problem will most likely be noticed by client systems attempting to access one of the services on the victim system. To verify that this attack is occurring, check the state of the server system's network traffic. For example, on SunOS this may be done by the command: netstat -a -f inet Note that use of the above command depends on the OS version, for example for a FreeBSD system use netstat -s |grep "listenqueue overflows" Too many connections in the state "SYN_RECEIVED" could indicate that the system is being attacked. ________________________________________ Appendix A - Reducing IP Spoofed Packets 1. Filtering Information With the current IP protocol technology, it is impossible to eliminate IP-spoofed packets. However, you can take steps to reduce the number of IP-spoofed packets entering and exiting your network. Currently, the best method is to install a filtering router that restricts the input to your external interface (known as an input filter) by not allowing a packet through if it has a source address from your internal network. In addition, you should filter outgoing packets that have a source address different from your internal network to prevent a source IP spoofing attack from originating from your site. The combination of these two filters would prevent outside attackers from sending you packets pretending to be from your internal network. It would also prevent packets originating within your network from pretending to be from outside your network. These filters will *not* stop all TCP SYN attacks, since outside attackers can spoof packets from *any* outside network, and internal attackers can still send attacks spoofing internal addresses. We STRONGLY urge Internet service providers to install these filters in your routers. In addition, we STRONGLY recommend customers of Internet service providers to contact your service provider to verify that the necessary filters are in place to protect your network. 2. Vendor Information The following vendor(s) have reported support for the type of filtering we recommend and provided pointers to additional information that describes how to configure your router. If we hear from other vendors, we will add their information to the "Updates" section at the end of this advisory. If you need more information about your router or about firewalls, please contact your vendor directly. Cisco Refer to the section entitled "ISP Security Advisory" on http://www.cisco.com for an up-to-date explanation of how to address TCP SYN flooding on a Cisco router. NOTE to vendors: If you are a router vendor who has information on router capabilities and configuration examples and you are not represented in this list, please contact the CERT Coordination Center at the addresses given in the Contact Information section below. We will update the advisory after we hear from you. 3. Alternative for routers that do not support filtering on the inbound side If your vendor's router does not support filtering on the inbound side of the interface or if there will be a delay in incorporating the feature into your system, you may filter the spoofed IP packets by using a second router between your external interface and your outside connection. Configure this router to block, on the outgoing interface connected to your original router, all packets that have a source address in your internal network. For this purpose, you can use a filtering router or a UNIX system with two interfaces that supports packet filtering. Note: Disabling source routing at the router does not protect you from this attack, but it is still good security practice to follow. On the input to your external interface, that is coming from the Internet to your network, you should block packets with the following addresses: • Broadcast Networks: The addresses to block here are network 0 (the all zeros broadcast address) and network 255.255.255.255 (the all ones broadcast network). • Your local network(s): These are your network addresses • Reserved private network numbers: The following networks are defined as reserved private networks, and no traffic should ever be received from or transmitted to these networks through a router: 10.0.0.0 - 10.255.255.255 10/8 (reserved) 127.0.0.0 - 127.255.255.255 127/8 (loopback) 172.16.0.0 - 172.31.255.255 172.16/12 (reserved) 192.168.0.0 - 192.168.255.255 192.168/16 (reserved) ________________________________________ The CERT Coordination Center staff thanks the team members of NASIRC for contributing much of the text for this advisory and thanks the many experts who are devoting time to addressing the problem and who provided input to this advisory. ________________________________________ UPDATES 3COM Please refer to the "Network Security Advisory" for a thorough discussion of how to address TCP SYN flooding attacks on a 3Com router: http://www.3com.com/ Berkeley Software Design, Inc. BSDI has patches available. PATCH K210-021 (ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/K210-021) md5 checksum: c386e72f41d0e409d91b493631e364dd K210-021 This patch adds two networking features that can help defeat and detect some types of denial of service attacks. This patch requires U210-025 which provides new copies of sysctl(8) and netstat(1) for configuration and monitoring of these new features. PATCH K210-022 (ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/K210-22) md5 checksum: 9ec62b5e9cc424b9b42089504256d926 K210-022 This patch adds a TCP SYN cache which reduces and/or eliminates the effects of SYN-type denial of service attacks such as those discussed in CERT advisory CA 96.21. PATCH U210-025 (ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-025) md5 checksum: d2ee01238ab6040e9b7a1bd2c3bf1016 U210-025 This patch should be installed in conjunction with IP source address check and IP fragmentation queue limit patch (K210-021) and SYN flooding patch (K210-022). Additional details about these patches are available from http://www.bsdi.com/ ftp://ftp.bsdi.com/ Hewlett-Packard Company HPSBUX9704-060 Description: SYN Flooding Security Vulnerability in HP-UX HEWLETT-PACKARD SECURITY BULLETIN: #00060 Security Bulletins are available from the HP Electronic Support Center via electronic mail. User your browser to get to the HP Electronic Support Center page at: http://us-support.external.hp.com/ (for US, Canada, Asia-Pacific, & Latin-America) http://europe-support.external.hp.com/ (for Europe) IBM Corporation Any system that is connected to a TCP/IP-based network (Internet or intranet) and offers TCP-based services is vulnerable to the SYN flood attack. The attack does not distinguish between operating systems, software version levels, or hardware platforms; all systems are vulnerable. IBM has released AIX operating system fixes for the SYN flood vulnerability. NOTE: If you are using the IBM Internet Connection Secured Network Gateway (SNG) firewall software, you must also apply the fixes listed in the next section. The following Automated Program Analysis Reports (APARs) for IBM AIX are now available to address the SYN flood attack: AIX 3.2.5 No APAR available; upgrade to AIX 4.x recommended AIX 4.1.x APAR - IX62476 AIX 4.2.x APAR - IX62428 Fixes for IBM SNG Firewall The following Automated Program Analysis Reports (APARs) for the IBM Internet Connection Secured Network Gateway firewall product are now available to address the SYN flood and "Ping o' Death" attacks: NOTE: The fixes in this section should ONLY be applied to systems running the IBM Internet Connection Secured Network Gateway (SNG) firewall software. They should be applied IN ADDITION TO the IBM AIX fixes listed in the previous section. IBM SNG V2.1 APAR - IR33376 PTF UR46673 IBM SNG V2.2 APAR - IR33484 PTF UR46641 Obtaining Fixes IBM AIX APARs may be ordered using Electronic Fix Distribution (via the FixDist program), or from the IBM Support Center. For more information on FixDist, and to obtain fixes via the Internet, please reference http://service.software.ibm.com/aixsupport/ or send electronic mail to "aixserv@austin.ibm.com " with the word "FixDist" in the "Subject:" line. Linux A patch for version 2.0.29 of the linux kernel source is available from: http://www.kernel.org/pub/linux/kernel/v2.0/patch-2.0.30.gz The patch allows tcp/ip processing to continue as normal, until the queue gets close to full. Then, instead of just sending the synack back, it sends a syn cookie back, and waits for a response to IT before sending the synack. When it sends the cookie, it clears the syn from the queue, so while under attack, the queue will never fill up. Cookies expire shortly after they are sent. Basically this prevents people from filling up the queue completely. No one flooding from a spoof will be able to reply to the cookie, so nothing can be overloaded. And if they aren't flooding from a spoof, they would be getting a cookie they would have to respond to, and would have a hard time responding to all the cookies and continuing the flood. Livingston Enterprises, Inc. Refer to the following Applications Note for more information on configuring a Livingston IRX or PortMaster to help block outgoing SYN attacks from an ISP's users: ftp://ftp.livingston.com/pub/le/doc/notes/filters.syn-attack Silicon Graphics, Inc. Updated Silicon Graphics information concerning SYN attacks can be found in SGI Security Advisory, "IRIX IP Spoofing/TCP Sequence Attack Update," 19961202-01-PX, issued on August 6, 1998. Patches are available via anonymous FTP and your service/support provider. The SGI anonymous FTP site is sgigate.sgi.com (204.94.209.1) or its mirror, ftp.sgi.com. Security information and patches can be found in the ~ftp/security and ~ftp/patches directories, respectfully. For subscribing to the wiretap mailing list and other SGI security related information, please refer to the Silicon Graphics Security Headquarters website located at: http://www.sgi.com/Support/security Sun Microsystems, Inc. Sun published a bulletin on October 9, 1996--Sun security bulletin number 00136. Sun Security Bulletins are available via the security-alert@sun.com alias and on SunSolve. Note: Advisories from vendors listed in this section can also be found at ftp://ftp.cert.org/pub/vendors/ ________________________________________ This document is available from: http://www.cert.org/advisories/CA-1996-21.html ________________________________________ CERT/CC Contact Information Email: cert@cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo@cert.org. Please include in the body of your messagesubscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. Lampiran 2 CERT® Advisory CA-1996-01 UDP Port Denial-of-Service Attack Original issue date: February 8, 1996 Last revised: September 24, 1997 Updated copyright statement A complete revision history is at the end of this file. The CERT Coordination Center has received reports of programs that launch denial-of-service attacks by creating a "UDP packet storm" either on a system or between two systems. An attack on one host causes that host to perform poorly. An attack between two hnosts can cause extreme network congestion in addition to adversely affecting host performance. The CERT staff recommends disabling unneeded UDP services on each host, in particular the chargen and echo services, and filtering these services at the firewall or Internet gateway. Because the UDP port denial-of-service attacks typically involve IP spoofing, we encourage you to follow the recommendations in advisory CA-96.21. We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site ________________________________________ I. Description When a connection is established between two UDP services, each of which produces output, these two services can produce a very high number of packets that can lead to a denial of service on the machine(s) where the services are offered. Anyone with network connectivity can launch an attack; no account access is needed. For example, by connecting a host's chargen service to the echo service on the same or another machine, all affected machines may be effectively taken out of service because of the excessively high number of packets produced. In addition, if two or more hosts are so connected, the intervening network may also become congested and deny service to all hosts whose traffic traverses that network. II. Impact Anyone with network connectivity can cause a denial of service. This attack does not enable them to gain additional access. III. Solution We recommend taking all the steps described below. 1. Disable and filter chargen and echo services. This attack is most readily exploited using the chargen or echo services, neither of which is generally needed as far as we are aware. We recommend that you disable both services on the host and filter them at the firewall or Internet gateway. To disable these services on a host, it is necessary to edit the inetd configuration file and cause inetd to begin using the new configuration. Exactly how to do this is system dependent so you should check your vendor's documentation for inetd(8); but on many UNIX systems the steps will be as follows: 1. Edit the inetd configuration file (e.g. /etc/inetd.conf). 2. Comment out the echo, chargen, and other UDP services not used. 3. Cause the inetd process to reread the configuration file (e.g., by sending it a HUP signal). 2. Disable and filter other unused UDP services. To protect against similar attacks against other services, we recommend: - disabling all unused UDP services on hosts and - blocking at firewalls all UDP ports less than 900 with the exception of specific services you require, such as DNS (port 53). 3. If you must provide external access to some UDP services, consider using a proxy mechanism to protect that service from misuse. Techniques to do this are discussed in Chapter 8, "Configuring Internet Services," in _Building Internet Firewalls_ by Chapman and Zwicky (see Section IV below). 4. Monitor your network. If you do provide external UDP services, we recommend monitoring your network to learn which systems are using these services and to monitor for signs of misuse. Tools for doing so include Argus, tcpdump, and netlog. Argus is available from ftp://ftp.net.cmu.edu/pub/argus-1.5/ MD5 (argus-1.5.tar.gz) = 9c7052fb1742f9f6232a890267c03f3c Note that Argus requires the TCP wrappers to install: ftp://ftp.cert.org/pub/tools/tcp_wrappers/ MD5 (tcp_wrappers_7.2.tar.Z) = 883d00cbd2dedd9bfc783b7065740e74 tcpdump is available from ftp://ftp.ee.lbl.gov/tcpdump-3.0.2.tar.Z MD5 (tcpdump-3.0.2.tar.Z) = c757608d5823aa68e4061ebd4753e591 Note that tcpdump requires libpcap, available at ftp://ftp.ee.lbl.gov/libpcap-0.0.6.tar.Z MD5 (libpcap-0.0.6.tar.Z) = cda0980f786932a7e2eebfb2641aa7a0 netlog is available from ftp://net.tamu.edu/pub/security/TAMU/netlog-1.2.tar.gz MD5 (netlog-1.2.tar.gz) = 1dd62e7e96192456e8c75047c38e994b 5. Take steps against IP spoofing. Because IP spoofing is typically involved in UDP port denial-of-service attacks, we encourage you to follow the guidance in advisory CA-95:01, available from http://www.cert.org/advisories/CA-95.01.IP.spoofing.attacks.and.hijacked.terminal.connections.html IV. Sources of further information about packet filtering For a general packet-filtering recommendations, see ftp://ftp.cert.org/pub/tech_tips/packet_filtering For in-depth discussions of how to configure your firewall, see Firewalls and Internet Security: Repelling the Wily Hacker William R. Cheswick and Steven M. Bellovin Addison-Wesley Publishing Company, 1994 ISBN 0-201-63357 Building Internet Firewalls Brent Chapman and Elizabeth D. Zwicky O'Reilly & Associates, Inc., 1995 ISBN 1-56592-124-0 ________________________________________ The CERT Coordination Center staff thanks Peter D. Skopp of Columbia University for reporting the vulnerability and Steve Bellovin of AT&T Bell Labs for his support in responding to this problem. ________________________________________ UPDATES Cisco Cisco Alert Summary: http://www.cisco.com/warp/public/146/917_security.html Cisco Security Guide http://www.cisco.com/univercd/data/doc/cintrnet/ics/icssecur.htm Silicon Graphics Inc. SGI acknowledges CERT Advisory CA-96.01 and is currently investigating. No further information is available at this time. ________________________________________ This document is available from: http://www.cert.org/advisories/CA-1996-01.html ________________________________________ CERT/CC Contact Information Email: cert@cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryptionWe strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo@cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. Lampiran 3 Email Bombing and Spamming ________________________________________ This document provides a general overview of problems associated with electronic mail bombing and email spamming. It includes information that will help you respond to and recover from this activity. Introduction I. Description II. Technical Issues III. What You Can Do A. Detection B. Reaction C. Prevention IV. Additional Security Measures That You Can Take ________________________________________ I. Description Email bombing is characterized by abusers repeatedly sending an email message to a particular address at a specific victim site. In many instances, the messages will be large and constructed from meaningless data in an effort to consume additional system and network resources. Multiple accounts at the target site may be abused, increasing the denial of service impact. Email spamming is a variant of bombing; it refers to sending email to hundreds or thousands of users (or to lists that expand to that many users). Email spamming can be made worse if recipients reply to the email, causing all the original addressees to receive the reply. It may also occur innocently, as a result of sending a message to mailing lists and not realizing that the list explodes to thousands of users, or as a result of a responder message (such as vacation(1)) that is setup incorrectly. Email bombing/spamming may be combined with email spoofing (which alters the identity of the account sending the email), making it more difficult to determine who actually sent the email. For more details on email spoofing, see http://www.cert.org/tech_tips/email_spoofing.html II. Technical Issues • If you provide email services to your user community, your users are vulnerable to email bombing and spamming. • Email spamming is almost impossible to prevent because a user with a valid email address can spam any other valid email address, newsgroup, or bulletin-board service. • When large amounts of email are directed to or through a single site, the site may suffer a denial of service through loss of network connectivity, system crashes, or failure of a service because of o overloading network connections o using all available system resources o filling the disk as a result of multiple postings and resulting syslog entries III. What You Can Do A. Detection If your system suddenly becomes sluggish (email is slow or doesn't appear to be sent or received), the reason may be that your mailer is trying to process a large number of messages. B. Reaction 1. Identify the source of the email bomb/spam and configure your router (or have your Network Service Provider configure the router) to prevent incoming packets from that address. Review email headers to determine the true origin of the email. Review the information related to the email bomb/spam following relevant policies and procedures of your organization. 2. Follow up with the site(s) you identified in your review to alert them to the activity. Contact them to alert them to the activity. NOTE: When contacting these sites, keep in mind that the abuser may be trying to hide their identity. We would appreciate it if you sent a copy of your message to cert@cert.org; this facilitates our work on incidents and helps us relate ongoing intruder activities. If you have a CERT reference number (e.g., CERT#XXXXX) for this incident, please include it in the subject line of all messages related to this incident. (NOTE: The CERT/CC assigns this reference number, so if you do not have one, one will be assigned once we receive the incident report.) To find site contact information, please refer to http://www.cert.org/tech_tips/finding_site_contacts.html 3. Ensure you are up to date with the most current version of your email delivery software (sendmail, for example) and increase logging capabilities as necessary to detect or alert you to such activity. C. Prevention Unfortunately, at this time, there is no way to prevent email bombing or spamming (other than disconnecting from the Internet), and it is impossible to predict the origin of the next attack. It is trivial to obtain access to large mailing lists or information resources that contain large volumes of email addresses that will provide destination email addresses for the spam. 1. Develop in-house tools to help you recognize and respond to the email bombing/spamming and so minimize the impact of such activity. The tools should increase the logging capabilities as well as check for and alert you to incoming/outgoing messages that originate from the same user or same site in a very short span of time. Once you identify the activity, you can use other in-house tools to discard the messages from the offending users or sites. 2. If your site uses a small number of email servers, you may want to configure your firewall to ensure that SMTP connections from outside your firewall can be made only to your central email hubs and to none of your other systems. Although this will not prevent an attack, it minimizes the number of machines available to an intruder for an SMTP-based attack (whether that attack is a email spam or an attempt to break into a host). It also means that should you wish to control incoming SMTP in a particular way (through filtering or another means), you have only a small number of systems--the main email hub and any backup email hubs--to configure. More information on filtering is available from http://www.cert.org/tech_tips/packet_filtering.html 3. Consider configuring your mail handling system(s) to deliver email into filesystems that have per-user quotas enabled. Doing this can minimize the impact of an email bombing attack by limiting the damage to only the targeted accounts and not the entire system. 4. Educate your users to call you about email bombing and spamming. 5. Do not propagate the problem by forwarding (or replying to) spammed email. IV. Additional Security Measures That You Can Take A. If you have questions concerning legal issues, we encourage you to work with your legal counsel. U.S. sites interested in an investigation of this activity can contact the Federal Bureau of Investigation (FBI). Information about how the FBI investigates computer crimes can be found here http://www.cert.org/tech_tips/FBI_investigates_crime.html For information on finding and contacting your local FBI field office, see http://www.fbi.gov/contact/fo/fo.htm Non-U.S. sites may want to discuss the activity with their local law enforcement agency to determine the appropriate steps for pursuing an investigation. B. For general security information, please see http://www.cert.org/ C. To report an incident, please complete and return http://www.cert.org/reporting/incident_form.txt Or use the web-based Incident Reporting Form at https://irf.cc.cert.org/ ________________________________________ This document is available from: http://www.cert.org/tech_tips/email_bombing_spamming.html ________________________________________ CERT/CC Contact Information Email: cert@cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo@cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office Lampiraran 4 Anonymous FTP Configuration Guidelines ________________________________________ Introduction I. Configuring anonymous FTP A. FTP daemon B. Setting up the anonymous FTP directories C. Using proper password and group files II. Providing writable directories in your anonymous FTP configuration A. Modified FTP daemon B. Using protected directories C. Using a single disk drive III. Related CERT Advisories ________________________________________ Anonymous FTP can be a valuable service if correctly configured and administered. The first section of this document provides general guidance in initial configuration of an anonymous FTP area. The second section addresses the issues and challenges involved when a site wants to provide writable directories within their anonymous FTP areas. The third section provides information about previous CERT advisories related to FTP services. The following guidelines are a set of suggested recommendations that have been beneficial to many sites. We recognize that there will be sites that have unique requirements and needs, and that these sites may choose to implement different configurations. I. Configuring anonymous FTP A. FTP daemon Sites should ensure that they are using the most recent version of their FTP daemon. B. Setting up the anonymous FTP directories The anonymous FTP root directory (~ftp) and its subdirectories should not be owned by the ftp account or be in the same group as the ftp account. This is a common configuration problem. If any of these directories are owned by ftp or are in the same group as the ftp account and are not write protected, an intruder will be able to add files (such as a .rhosts file) or modify other files. Many sites find it acceptable to use the root account. Making the ftp root directory and its subdirectories owned by root, part of the system group, and protected so that only root has write permission will help to keep your anonymous FTP service secure. Here is an example of an anonymous FTP directory setup: drwxr-xr-x 7 root system 512 Mar 1 15:17 ./ drwxr-xr-x 25 root system 512 Jan 4 11:30 ../ drwxr-xr-x 2 root system 512 Dec 20 15:43 bin/ drwxr-xr-x 2 root system 512 Mar 12 16:23 etc/ drwxr-xr-x 10 root system 512 Jun 5 10:54 pub/ Files and libraries, especially those used by the FTP daemon and those in ~ftp/bin and ~ftp/etc, should have the same protections as these directories. They should not be owned by ftp or be in the same group as the ftp account; and they should be write protected. C. Using proper password and group files We strongly advise that sites not use the system's /etc/passwd file as the password file or the system's /etc/group as the group file in the ~ftp/etc directory. Placing these system files in the ~ftp/etc directory will permit intruders to get a copy of these files. These files are optional and are not used for access control. We recommend that you use a dummy version of both the ~ftp/etc/passwd and ~ftp/etc/group files. These files should be owned by root. The dir command uses these dummy versions to show owner and group names of the files and directories instead of displaying arbitrary numbers. Sites should make sure that the ~/ftp/etc/passwd file contains no account names that are the same as those in the system's /etc/passwd file. These files should include only those entries that are relevant to the FTP hierarchy or needed to show owner and group names. In addition, ensure that the password field has been cleared. The examples below show the use of asterisks (*) to clear the password field. Below is an example of a passwd file from the anonymous FTP area on cert.org: ssphwg:*:3144:20:Site Specific Policy Handbook Working Group:: cops:*:3271:20:COPS Distribution:: cert:*:9920:20:CERT:: tools:*:9921:20:CERT Tools:: ftp:*:9922:90:Anonymous FTP:: nist:*:9923:90:NIST Files:: Here is an example group file from the anonymous FTP area on cert.org: cert:*:20: ftp:*:90: II. Providing writable directories in your anonymous FTP configuration There is a risk to operating an anonymous FTP service that permits users to store files. We strongly recommend that sites do not automatically create a "drop off" directory unless thought has been given to the possible risks of having such a service. The CERT incident response staff has received many reports where these directories have been used as "drop off" directories to distribute bootlegged versions of copyrighted software or to trade information on compromised accounts and password files. The CERT staff has also received reports of file systems being maliciously filled causing denial of service problems. This section discusses three ways to address these problems. The first is to use a modified FTP daemon. The second method is to provide restricted write capability through the use of special directories. The third method involves the use of a separate directory. A. Modified FTP daemon If your site is planning to offer a "drop off" service, we suggest using a modified FTP daemon that will control access to the "drop off" directory. This is the best way to prevent unwanted use of writable areas. Some suggested modifications are: 1. Implement a policy where any file dropped off cannot be accessed until the system manager examines the file and moves it to a public directory. 2. Limit the amount of data transferred in one session. 3. Limit the overall amount of data transferred based on available disk space. 4. Increase logging to enable earlier detection of abuses. For those interested in modifying the FTP daemon, source code is usually available from your vendor. Public domain sources are available from: wuarchive.wustl.edu ~ftp/packages/wuarchive-ftpd ftp.uu.net ~ftp/systems/unix/bsd-sources/libexec/ftpd gatekeeper.dec.com ~ftp/pub/DEC/gwtools/ftpd.tar.Z The CERT Coordination Center has not formally reviewed, evaluated, or endorsed the FTP daemons described. The decision to use the FTP daemons described is the responsibility of each user or organization, and we encourage each organization to thoroughly evaluate these programs before installation or use. B. Using protected directories If your site is planning to offer a "drop off" service and is unable to modify the FTP daemon, it is possible to control access by using a maze of protected directories. This method requires prior coordination and cannot guarantee protection from unwanted use of the writable FTP area, but has been used effectively by many sites. Protect the top level directory (~ftp/incoming) giving only execute permission to the anonymous user (chmod 751 ~ftp/incoming). This will permit the anonymous user to change directory (cd), but will not allow the user to view the contents of the directory. drwxr-x--x 4 root system 512 Jun 11 13:29 incoming/ Create subdirectories in the ~ftp/incoming using names known only between your local users and the anonymous users that you want to have "drop off" permission. The same care used in selecting passwords should be taken in selecting these subdirectory names because the object is to choose names that cannot be easily guessed. Please do not use our example directory names of jAjwUth2 and MhaLL-iF. drwxr-x-wx 10 root system 512 Jun 11 13:4 jAjwUth2/ drwxr-x-wx 10 root system 512 Jun 11 13:54 MhaLL-iF/ This will prevent the casual anonymous FTP user from writing files in your anonymous FTP file system. It is important to realize that this method does not protect a site against the result of intentional or accidental disclosure of the directory names. Once a directory name becomes public knowledge, this method provides no protection at all from unwanted use of the area. Should a name become public, a site may choose to either remove or rename the writable directory. C. sing a single disk drive If your site is planning to offer a "drop off" service and is unable to modify the FTP daemon, it may be desirable to limit the amount of data transferred to a single file system mounted as ~ftp/incoming. If possible, dedicate a disk drive and mount it as ~ftp/incoming. The system administrator should monitor this directory (~ftp/incoming) on a continuing basis to ensure that it is not being misused. III. Related CERT Advisories The following CERT Advisories directly relate to FTP daemons or impact on providing FTP service: CA-95:16.wu-ftpd.vul CA-93:06.wuarchive.ftpd.vulnerability CA-92:09.AIX.anonymous.ftp.vulnerability CA-88:01.ftpd.hole A complete list of advisories can be found at www.cert.org/advisories/index.html. Copyright 1995 Carnegie Mellon University Disclaimers and copyright information CERT and CERT Coordination Center are registered in the U.S. Patent & Trademark Office Revision history: May 4, 2001: converted to HTML; updated URLs Lampiran 5 CERT® Advisory CA-1996-26 Denial-of-Service Attack via ping Original issue date: December 18, 1996 Last revised: December 5, 1997 Updated information for NCR Corporation. A complete revision history is at the end of this file. The CERT Coordination Center has received reports of a denial-of-service attack using large ICMP datagrams. Exploitation details involving this vulnerability have been widely distributed. The CERT/CC team recommends installing vendor patches as they become available. We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site. ________________________________________ I. Description The TCP/IP specification (the basis for many protocols used on the Internet) allows for a maximum packet size of up to 65536 octets (1 octet = 8 bits of data), containing a minimum of 20 octets of IP header information and 0 or more octets of optional information, with the rest of the packet being data. It is known that some systems will react in an unpredictable fashion when receiving oversized IP packets. Reports indicate a range of reactions including crashing, freezing, and rebooting. In particular, the reports received by the CERT Coordination Center indicate that Internet Control Message Protocol (ICMP) packets issued via the "ping" command have been used to trigger this behavior. ICMP is a subset of the TCP/IP suite of protocols that transmits error and control messages between systems. Two specific instances of the ICMP are the ICMP ECHO_REQUEST and ICMP ECHO_RESPONSE datagrams. These two instances can be used by a local host to determine whether a remote system is reachable via the network; this is commonly achieved using the "ping" command. Discussion in public forums has centered around the use of the "ping" command to construct oversized ICMP datagrams (which are encapsulated within an IP packet). Many ping implementations by default send ICMP datagrams consisting only of the 8 octets of ICMP header information but allow the user to specify a larger packet size if desired. You can read more information about this vulnerability on Mike Bremford's Web page. (Note that this is not a CERT/CC maintained page. We provide the URL here for your convenience.) http://www.sophist.demon.co.uk/ping/index.html II. Impact Systems receiving oversized ICMP datagrams may crash, freeze, or reboot, resulting in denial of service. III. Solution First, since crashing a router or firewall may be part of a larger, multistage attack scenario, we encourage you to inspect the running configuration of any such systems that have crashed to ensure that the configuration information is what you expect it to be. Then install a patch from your vendor. Below is a list of vendors who have provided information about patches for this problem. Details are in Appendix A of this advisory; we will update the appendix as we receive more information. If your vendor's name is not on this list, please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) Computer Associates, Intl. (products for NCR) Cray Research Digital Equipment Corporation Free BSD, Inc. Hewlett-Packard Company IBM Corporation Linux Systems NCR Corporation NEC Corporation Open Software Foundation (OSF) The Santa Cruz Operation, Inc. (SCO) Sun Microsystems, Inc. ________________________________________ Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) BSD/OS 2.1 is not vulnerable to this problem. It correctly handles large packets without any problems. Computer Associates, Intl. (products for NCR) Not vulnerable. Cray Research Attempts to send oversized ICMP datagrams are rejected with appropriate error messages. We believe that oversized ICMP datagrams sent to Unicos systems will also be rejected without crashing. Data General Corporation Due to the way DG/UX processes tcp packets, DG/UX is not vulnerable to this attack. Digital Equipment Corporation MSG ID: SSRT0429 From DSNlink/DIA Database The following is important information concerning a potential denial of service issue which affects Digital UNIX Operating System, Digital UNIX MLS+, Firewall implementations, and Digital TCP/IP Services for OpenVMS AXP & VAX COMPONENT: System Security / Potential Denial of Service DIGITAL UNIX Version: 3.0, 3.0b, 3.2, 3.2c, 3.2de1, 3.2de2, 3.2f, 3.2g, 4.0, 4.0a DIGITAL UNIX MLS+ Version 3.1a DIGITAL TCP/IP Services for OpenVMS AXP & VAX Versions - 4.0, 4.1 DIGITAL ULTRIX Versions 4.3, 4.3a, 4.4, 4.5 DIGITAL Firewall for UNIX DIGITAL AltaVista Firewall for UNIX DIGITAL VAX/ELN For more information check the DSNlink/DIA Articles (keyword PING), or the URL http://www.service.digital.com/html/whats-new.html for the latest information. ADVISORY INFORMATION: Digital recently discovered a potential denial of service issue that may occur by remote systems exploiting a recently published problem while executing the 'ping' command. Solutions and initial communications began appearing in DSNlink/DIA FLASH/articles in late October, 1996. SEVERITY LEVEL: High. SOLUTION: Digital has reacted promptly to this reported problem and a complete set of patch kits are being prepared for all currently supported platforms. The Digital patches may be obtained from your local Digital support channel or from the URL listed above. Please refer to the applicable README notes information prior to the installation of patch kits on your system. DIGITAL EQUIPMENT CORPORATION Copyright (c) Digital Equipment Corporation, 1996, All Rights Reserved. Unpublished Rights Reserved Under The Copyright Laws Of The United States. Free BSD, Inc. We have fixed the problem in 2.1.6 and -current. Hewlett-Packard Company For HP9000 Series 700 and 800 systems, apply the appropriate patch. See Hewlett-Packard Security Bulletin #000040 (HPSBUX9610-040) for further details. The bulletin is available from the HP SupportLine and ftp://ftp.cert.org/pub/vendors/hp/ Patch Name(Platform/OS) | Notes --------------------------+---------------------------------- PHNE_9027 (s700 9.01) : PHNE_7704 must first be installed PHNE_9028 (s700 9.03/5/7) : PHNE_7252 must first be installed PHNE_9030 (s700 10.00) : No patch dependencies PHNE_9032 (s700 10.01) : PHNE_8168 must first be installed PHNE_9034 (s700 10.10) : PHNE_8063 must first be installed PHNE_9036 (s700 10.20) : No patch dependencies --------------------------+---------------------------------- PHNE_8672 (s800 9.00) : PHNE_7197 must first be installed PHNE_9029 (s800 9.04) : PHNE_7317 must first be installed PHNE_9031 (s800 10.00) : No patch dependencies PHNE_9033 (s800 10.01) : PHNE_8169 must first be installed PHNE_9035 (s800 10.10) : PHNE_8064 must first be installed PHNE_9037 (s800 10.20) : No patch dependencies --------------------------+---------------------------------- For our MPE operating system, patches are in process. Watch for the issuance of our MPE security bulletin. IBM Corporation See the appropriate release below to determine your action. AIX 3.2 Apply the following fix to your system: APAR - IX59644 (PTF - U444227 U444232) To determine if you have this PTF on your system, run the following command: lslpp -lB U444227 U444232 AIX 4.1 Apply the following fix to your system: APAR - IX59453 To determine if you have this APAR on your system, run the following command: instfix -ik IX59453 Or run the following command: lslpp -h bos.net.tcp.client Your version of bos.net.tcp.client should be 4.1.4.16 or later. AIX 4.2 Apply the following fix to your system: APAR - IX61858 To determine if you have this APAR on your system, run the following command: instfix -ik IX61858 Or run the following command: lslpp -h bos.net.tcp.client Your version of bos.net.tcp.client should be 4.2.0.6 or later. IBM SNG Firewall NOTE: The fixes in this section should ONLY be applied to systems running the IBM Internet Connection Secured Network Gateway (SNG) firewall software. They should be applied IN ADDITION TO the IBM AIX fixes listed in the previous section. IBM SNG V2.1 APAR - IR33376 PTF UR46673 IBM SNG V2.2 APAR - IR33484 PTF UR46641 To Order APARs may be ordered using Electronic Fix Distribution (via FixDist) or from the IBM Support Center. For more information on FixDist, reference URL: http://service.software.ibm.com/aixsupport/ or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist". IBM and AIX are registered trademarks of International Business Machines Linux Systems We recommend that you upgrade your Linux 1.3.x and 2.0.x kernels to Linux 2.0.27. This is available from all the main archive sites such as ftp://ftp.cs.helsinki.fi/pub/Software/Linux Users wishing to remain with an earlier kernel version may download a patch from http://www.uk.linux.org/big-ping-patch. This patch will work with 2.0.x kernel revisions but is untested with 1.3.x kernel revisions. Red Hat Linux has chosen to issue a 2.0.18 based release with the fix. Red Hat users should obtain this from ftp://ftp.redhat.com/pub/redhat/redhat-4.0/updates/i386/kernel-2.0.18-6.i386.rpm > NCR Corporation For MP-RAS 3.00 and above, using TCP/IP as package name "inet", not vulnerable. NEC Corporation - -------------------------------------------------------------------------- OS Version Status - ------------------ ------------ ------------------------------------- EWS-UX/V(Rel4.0) R1.x - R6.x not vulnerable EWS-UX/V(Rel4.2) R7.x - R10.x not vulnerable EWS-UX/V(Rel4.2MP) R10.x not vulnerable UP-UX/V R1.x - R4.x not vulnerable UP-UX/V(Rel4.2MP) R5.x - R7.x not vulnerable UX/4800 R11.x not vulnerable - -------------------------------------------------------------------------- NCR see Computer Associates, Intl. Open Software Foundation (OSF) OSF's OSF/1 R1.3.3 maintenance release includes a solution for this problem. The Santa Cruz Operation, Inc. (SCO) The following SCO products are known to be vulnerable: SCO OpenServer 5.0.0, 5.0.2 SCO Internet FastStart 1.0.0, 1.1.0 SCO Open Desktop 3.0 SCO TCP/IP 1.2.1 on SCO Unix System V/386 Release 3.2 Version 4.2 The symptoms encountered vary greatly and seem to be related to the type of network interface device being used. Support Level Supplement (SLS) OSS449 addresses this problem for the following releases: SCO OpenServer 5.0.0, 5.0.2 SCO Internet FastStart 1.0.0, 1.1.0. This Supplement is available at the following URLs: ftp://ftp.sco.COM/SLS/oss449a.ltr (cover letter) ftp://ftp.sco.COM/SLS/oss449a.Z (image) The checksums are as follows: sum -r ------ oss449a.ltr: 28877 42 oss449a.Z: 54558 1762 MD5 --- MD5 (oss449a.Z) = e8fc8a29dd59683ce5107f3b9b8d1169 MD5 (oss449a.ltr) = d51ee1caf33edb86f4dbeb1733c99d86 If this SLS is ever updated, it will be noted at: ftp://ftp.sco.COM/SLS/README Should more information become available for either SCO's OpenServer or UnixWare products, SCO will provide updated information for this advisory. If you need further assistance, SCO's Web page is at http://www.sco.com/. Support requests from supported customers may be addressed to support@sco.COM , or you may contact SCO as follows: USA/Canada: 6am-5pm Pacific Standard Time (PST) 1-408-425-4726 (voice) 1-408-427-5443 (fax) Pacific Rim, Asia, and Latin American customers: 6am-5pm Pacific Standard Time (PST) 1-408-425-4726 (voice) 1-408-427-5443 (fax) Europe, Middle East, Africa: 9am-5:00pm Greenwich Mean Time (GMT) +44 1923 816344 (voice) +44 1923 817781 (fax) Sun Microsystems, Inc. Sun Microsystems has provided the following list of patches in response to this advisory: 103630-09 5.5.1 103631-09 5.5.1_x86 103169-12 5.5 103170-12 5.5_x86 101945-51 5.4 101946-45 5.4_x86 ________________________________________ The CERT Coordination Center staff thanks AUSCERT, the Australian Computer Emergency Response Team, and DFN-CERT, the German team, for their contributions to this advisory, and we thank Mike Bremford for permission to cite the information he has made available to the community. ________________________________________ ________________________________________ This document is available from: http://www.cert.org/advisories/CA-1996-26.html ________________________________________ CERT/CC Contact Information Email: cert@cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo@cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. ________________________________________ NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. ________________________________________ Conditions for use, disclaimers, and sponsorship information Copyright 1996 Carnegie Mellon University. ________________________________________ Revision History Dec. 5, 1997 Appendix A - Updated information for NCR Corporation. Sep. 24,1997 Updated copyright statement Aug. 7, 1997 Changed vendor information for Sun Microsystems to remove incorrect patch reference. July 28, 1997 Added vendor information for Sun Microsystems. Jan. 20, 1997 Appendix A - added information from Data General Corporation. Jan. 14, 1997 Appendix A - modified SCO entry to include updated patch information. Lampiran 6 UNIX Configuration Guidelines ________________________________________ Introduction A. Commonly Exploited Configuration Problems 1. Weak Passwords 2. Accounts with default passwords 3. Resuable passwords 4. Use of TFTP (Trivial File Transfer Protocol) to obtain password files 5. Vulnerabilities in sendmail 6. Misconfigured anonymous FTP 7. Inapropriate network configuration file entries 8. Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab 9. Inappropriate entries in /etc/aliases (or /usr/lib/aliases) 10. Inappropriate file and directory protections 11. Old versions of system software 12. Use of setuid shell scripts 13. Inappropriate export settings 14. Vulnerable protocols and services B. Other Suggestions Revision History ________________________________________ This document describes commonly exploited UNIX system configuration problems and recommends practices that can be used to help deter several types of break-ins. We encourage system administrators to review all sections of this document and modify their systems to fix potential weaknesses. In addition to the information in this document, we provide three companion documents that may help you. • http://www.cert.org/tech_tips/intruder_detection_checklist.html contains suggestions for determining if your system may have been compromised • http://www.cert.org/tech_tips/win-UNIX-system_compromise.html contains suggested steps for recovering from a root compromise on a UNIX and Windows NT systems • http://www.cert.org/tech_tips/security_tools.html contains descriptions of tools that can be used to help secure a system and deter break-ins Also, please see our CERT advisory page, our CERT incident notes page, and our CERT vulnerability notes page which contain brief descriptions of all past CERT advisories, incident notes, and vulnerability notes. These files are available from • http://www.cert.org/advisories/ • http://www.cert.org/incident_notes/ • http://www.cert.org/vul_notes/ We encourage you to review the documents that pertain to your system(s), and to consider taking the suggested steps to protect your system(s) from attack. We also encourage you to check with your vendor(s) regularly for any software updates or new software patches that relate to your systems. ________________________________________ A. Commonly Exploited Configuration Problems 1. Poor Password Security The basic form of authentication used to control access to a UNIX host is a username and password combination. Intruders have established mechanisms and tools to compromise password information by leveraging a variety of common problems. i. Weak passwords Encourage your users to choose passwords that are difficult to guess (for example, words that are not in any dictionary of any language; no proper nouns, including names of "famous" real or fictitious characters; no acronyms that are commonly used by computer professionals; no simple variations of first or last names.) Furthermore, inform your users not to leave any cleartext username/password information in files on any system. A good heuristic for choosing a password is to choose an easy-to-remember phrase, such as "By The Dawn's Early Light", and use the first letters to form a password. Add some punctuation or mix case letters as well. For the phrase above, one example password might be: bt}DeL{. (DO NOT use this sample phrase for your password.) If intruders can get a password file, they usually move or copy it to another machine and run password-guessing programs on it. These programs involve large dictionary searches, and they run quickly even on slow machines. Most systems that do not put any controls of the type of passwords used probably have at least one password that can be easily guessed. CERT Incident Note IN-98.03 describes intruder activity that is based on a stolen password file. http://www.cert.org/incident_notes/IN-98.03.html If you believe that your password file may have been taken, change all the passwords on the system. At the very least, you should change all system passwords because an intruder may concentrate on those and may be able to guess even a reasonably "good" password. Intruders often use compromised accounts to attempt to gain privelaged access on vulnerable systems, so we encourage you to follow the steps in  http://www.cert.org/tech_tips/intruder_detection_checklist.html  http://www.cert.org/tech_tips/win-UNIX-system_compromise.html For further information about protecting your system from password-based attacks, see  http://www.cert.org/tech_tips/passwd_file_protection.html ii. Accounts with default passwords Intruders exploit system default passwords that have not been changed since installation, including accounts with vendor-supplied default passwords. In some cases, accounts do not have a password assigned by default. CERT Incident Note IN-98.01 describes intruder activity that is based on exploitations of accounts without passwords. http://www.cert.org/incident_notes/IN-98.01.irix.html Be sure to change all default passwords on computer systems and networking equipment prior to deployment. Also, be aware that product upgrades can quietly change account passowrds to a new default. It is best to change the passwords of default accounts after applying updates. Scan your password file for extra UID 0 accounts, accounts with no password, or new entries in the password file. Do not allow any accounts without passwords. Remove entries for unused accounts from the password file. To disable an account, change the password field in the /etc/passwd file to an asterisk '*' and change the login shell to /bin/false to ensure that an intruder cannot login to the account from a trusted system on the network. iii. Reusable and shared passwords Even excellent passwords are not safe. They can be captured by programs such as packet sniffers if the passwords are sent across networks in cleartext (whether on a subnet, a local network, or the Internet). It is common for intruders to use packet sniffers on compromised systems to harvest passwords. CERT Incident Note IN-99-06 describes widespread intruder activity involving distributed sniffers used to harvest username and password information from a network. http://www.cert.org/incident_notes/IN-99-06.html At the very least, a single password should not be used to protect multiple accounts. If an intruder is able to compromise a shared password just once, all of the accounts sharing the password are compromised. Each account, or resource, protected by a password should have it's own unique password. To overcome the threat posed by packet sniffers, we recommend using one-time passwords, especially for authenticated access from external networks and for access to sensitive resources like name servers and routers. For more information, see Appendix B of the following advisory: http://www.cert.org/advisories/CA-94.01.ongoing.network.monitoring.attacks.html Another approach is to use a strong authentication mechanisms such as secure shell, SSL, or kerberos. Secure shell, or ssh, is widely available for many different platforms. For more information about secure shell, see  http://www.ssh.com/index.html  http://www.openssh.com/ 2. Use of TFTP (Trivial File Transfer Protocol) to obtain password files To test your system for this vulnerability, connect to your system using tftp and try get /etc/motd If you can do this, anyone else on the network can probably get your password file. To avoid the problem, disable tftpd. If you must have tftpd, ensure that it is configured with restricted access. For further information, see http://www.cert.org/advisories/CA-91.18.Active.Internet.tftp.Attacks.html As mentioned in Section 1 above, if you believe your password file may have been taken, the safest course is to change all passwords in the system. 3. Vulnerabilities in sendmail There have been a number of vulnerabilities identified over the years in sendmail(8). To the best of our knowledge, the current version of sendmail addresses those known vulnerabilities. To determine which version of sendmail is running, use telnet to connect to the SMTP port (25) on your system: telnet 25 We encourage you to keep up to date with the latest version of sendmail from your vendor, and ensure that it is up to date with security patches or workarounds detailed in CERT advisories advisories and bulletins. In addition, we encourage you to use the following tools, both of which are distributed with the latest versions of sendmail: a. smrsh, the sendmail restricted shell, controls the way o that incoming mail messages can interact with your operating system. For instance, when configured correctly, smrsh can prevent an intruder from using pipes to execute arbitrary commands on your system. b. mail.local can be used to control the way in which the /bin/mail program is used on your system. This tool is described in CERT advisory CA-95:02. http://www.cert.org/advisories/CA-1995-02.html If you are not running a recent version of sendmail, the above tools may also be obtained individually from o http://www.cert.org/tech_tips/security_tools.html Warning: If you are running such an old version of sendmail that you must install these tools separately, intruders will continue to be able to exploit vulnerabilities that were fixed in later versions of sendmail. We urge you to upgrade to the current version of sendmail mail and then run the tools, which are included with the distribution. 4. Misconfigured anonymous FTP In addition to making sure that you are running the most recent version of ftpd, check your anonymous FTP configuration. It is important to follow the instructions provided with the operating system to properly configure the files and directories available through anonymous FTP (for example, file and directory permissions, ownership and group). Note that you should not use your system's standard password file or group file as the password file or group file for FTP. The anonymous FTP root directory and its two subdirectories, etc and bin, should not be owned by ftp. For more information about configuring anonymous FTP, see http://www.cert.org/tech_tips/anonymous_ftp_config.html 5. Inappropriate network configuration file entries Several vendors supply /etc/hosts.equiv files with a '+' (plus sign) entry. The '+' entry should be removed from this file because it means that your system will trust all other systems. Other files that should not contain a '+' entry include all .rhosts files on the system. These files should not be world-writable. If your /usr/lib/X11/xdm/Xsession file includes an 'xhost' command with a '+' entry, such as /usr/bin/X11/xhost + remove that line. (Note that the 'xhost' command may be in a different directory tree on your system.) If such a line remains intact, anyone on the network can talk to the X server and potentially insert commands into windows or read console keystrokes. 6. Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab Check the file /etc/ttys or /etc/ttytab (depending on the release of UNIX being used). The ONLY terminal that should be set to 'secure' should be the console. 7. Inappropriate entries in /etc/aliases (or /usr/lib/aliases) Examine the /etc/aliases (or /usr/lib/aliases) mail alias file for inappropriate entries. Some alias files include an alias named 'uudecode' or just 'decode.' If this alias exists on your system and you are not explicitly using it, then you should remove it. 8. Inappropriate file and directory protections Check your system documentation to establish the correct file and directory protections and ownership for system files and directories. In particular, check the '/' (root) and '/etc' directories, and all system and network configuration files. Examine file and directory protections before and after installing software or running verification utilities. These procedures can cause file and directory protections to change. 9. Old versions of system software Older versions of operating systems often have security vulnerabilities that are well known to intruders. To minimize your vulnerability to attacks, keep the version of your operating system up to date and apply security patches appropriate to your system(s) as soon as they become available. 10. Use of setuid shell scripts Setuid shell scripts (especially setuid root) can pose potential security problems, a fact that has been well documented in many UNIX system administration texts. Do not create or allow setuid shell scripts, especially setuid root. 11. Inappropriate export settings Use the showmount(8) utility to check that the configuration of the /etc/exports files on your hosts are correct. o Wherever possible, file systems should be exported read-only. o Do not self-reference an NFS server in its own exports file. That is, the exports file should not export an NFS server to itself nor to any netgroups that include the NFS server. o Do not allow the exports file to contain a "localhost" entry. o Export file systems only to hosts that require them. o Export only to fully qualified hostnames. o Ensure that export lists do not exceed 256 characters (after the aliases have been expanded) or that all security patches relating to this problem have been applied. The CERT Coordination Center is aware that intruders are using tools that exploit a number of NFS vulnerabilities. This can result in a root compromise, depending on the vulnerability being exploited. We encourage you to limit your exposure to these attacks by implementing the security measures outlined in CERT advisory CA-94:15. For this and other information about the NFS vulnerability, see http://www.cert.org/advisories/CA-1994-15.html 12. Vulnerable protocols and services You may want to consider filtering certain TCP/IP services at your firewall or router. For some related suggestions, please refer to "Packet Filtering For Firewall Systems," available from http://www.cert.org/tech_tips/packet_filtering.html For a list of some recommended books and articles on computer security topics, see the CERT(sm) Coordination Center FAQ, available from • http://www.cert.org/cert.faqintro.html • http://www.cert.org/faq/cert_faq.html ________________________________________ This document is available from: http://www.cert.org/tech_tips/unix_configuration_guidelines.html ________________________________________ CERT/CC Contact Information Email: cert@cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo@cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. Lampiran 7 List of Security Tools ________________________________________ Introduction Notes • Network Monitoring Tools 1. Argus 2. swatch • Authentication/Password Tools 1. Crack 2. Shadow passwords • Service-Filtering Tools 1. TCP/IP wrapper program • Tools to Scan Hosts for Known Vulnerabilities 1. ISS (Internet Security Scanner) 2. SATAN (Security Administrator Tool for Analyzing Networks) • Multi-Purpose Tools 1. COPS (Computer Oracle and Password System) • Integrity-Checking Tools 1. MD5 2. Tripwire • Encryption Tools 1. PGP (Pretty Good Privacy) 2. GnuPG (Gnu Privacy Guard) • Other Tools 1. lsof 2. ifstatus 3. smrsh 4. mail.local • Other Reading About Security Tools Revision History ________________________________________ This document describes tools that can be used to help secure a system and deter break-ins. In addition to the information in this document, we provide three companion documents that may help you: • http://www.cert.org/tech_tips/unix_configuration_guidelines.html contains suggestions for avoiding common UNIX system configuration problems that have been exploited • http://www.cert.org/tech_tips/intruder_detection_checklist.html contains suggestions for determining if your system has been compromised • http://www.cert.org/tech_tips/root_compromise.html contains suggested steps for recovering from a root compromise on a UNIX system Also, please see our CERT advisory page, our CERT incident notes page, and our CERT vulnerability notes page which contain brief descriptions of all past CERT advisories, incident notes, and vulnerability notes. These files are available from • http://www.cert.org/advisories/ • http://www.cert.org/incident_notes/ • http://www.cert.org/vul_notes/ We encourage you to get all advisories that pertain to your system(s), and to install the patches or workarounds described in the advisories. We also encourage you to check with your vendor(s) regularly for any updates or new patches that relate to your systems. ________________________________________ Notes When installing and using any security tool, read and follow all available directions. Ensure that use of the tool conforms to your organization's policies and procedures. Keep sensitive files, such as MD5 checksums and log files, off-line or on read-only media. The CERT Coordination Center does not formally review, evaluate, or endorse the tools and techniques described. The decision to use the tools and techniques described is the responsibility of each user or organization, and we encourage each organization to thoroughly evaluate new tools and techniques before installing or using them. ________________________________________ • Network Monitoring Tools 1. Argus Argus is a network monitoring tool that uses a client-server model to capture data and associate it into "transactions." The tool provides network-level auditing; it can verify compliance to a router configuration file, and information can be easily adapted to protocol analysis, intrusion detections, and other security needs. Argus is available from many sites, including ftp://ftp.andrew.cmu.edu/pub/argus/ 2. swatch Swatch, the Simple WATCHer program, is an easily configurable log file filter/monitor. Swatch monitors log files and acts to filter out unwanted data and take one or more user-specified actions based on patterns in the log. Swatch is available from ftp://ftp.stanford.edu/general/security-tools/swatch/ • Authentication/Password Tools 1. Crack Crack is a freely available program designed to identify, by standard guessing techniques, UNIX DES encrypted passwords that can be found in widely available dictionaries. The guessing techniques are outlined in the Crack documentation. Many system administrators run Crack as a regular system administration procedure and notify account owners who have "crackable" passwords. Crack is available from ftp://coast.cs.purdue.edu/pub/tools/unix/pwdutils/crack/ 2. Shadow passwords If your UNIX system has a shadow password capability, you should use it. Under a shadow password system, the /etc/passwd file does not have encrypted passwords in the password field. Instead, the encrypted passwords are held in a shadow file that is not world readable. Consult your system manuals to determine whether a shadow password capability is available on your system and to get details of how to set up and manage it. • Service-Filtering Tools 1. TCP/IP wrapper program The TCP/IP wrapper program provides additional network logging information and gives a system administrator the ability to deny or allow access from certain systems or domains to the host on which the program is installed. Installation of this software does not require any modification to existing network software. This program is available from ftp://ftp.porcupine.org/pub/security/ • Tools to Scan Hosts for Known Vulnerabilities 1. ISS (Internet Security Scanner) ISS is a program that will interrogate all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. ISS is available from many sites, including ftp://coast.cs.purdue.edu/pub/tools/unix/scanners/iss/ For further information about ISS, see http://www.cert.org/advisories/CA-1993-14.html 2. SATAN (Security Administrator Tool for Analyzing Networks) SATAN is a testing and reporting tool that collects a variety of information about networked hosts. SATAN is available from many sites, including ftp://ftp.porcupine.org/pub/security/ For further information about SATAN, see  http://www.cert.org/advisories/CA-1995-06.html  http://www.cert.org/advisories/CA-1995-07.html • Multi-Purpose Tools 1. COPS (Computer Oracle and Password System) COPS is a publicly available collection of programs that attempt to identify security problems in a UNIX system. COPS does not attempt to correct any discrepancies found; it simply produces a report of its findings. COPS is available from ftp://coast.cs.purdue.edu/pub/tools/unix/scanners/cops/ • Integrity-Checking Tools 1. MD5 MD5 is a cryptographic checksum program. MD5 takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is thought to be computationally infeasible to produce two messages having the same message digest or to produce any message having a given pre-specified target message digest. MD5 is found in RFC 1321. See ftp://coast.cs.purdue.edu/pub/tools/unix/crypto/md5/ 2. Tripwire Tripwire checks file and directory integrity; it is a utility that compares a designated set of files and directories to information stored in a previously generated database. Any differences are flagged and logged, including added or deleted entries. When run against system files on a regular basis, Tripwire enables you to spot changes in critical system files and to immediately take appropriate damage control measures. Tripwire is available from many sites, including ftp://coast.cs.purdue.edu/pub/tools/unix/ids/tripwire/ • Encryption Tools 1. PGP (Pretty Good Privacy) Pretty Good Privacy (PGP) is a utility that provides strong encryption and digital signature capabilities based on public key algorithms. It is free for non-commercial use. General information about PGP, including some free software implementations can be found at http://www.pgpi.org/ The commercial version of PGP, from PGP Security, Inc. can be found at http://www.pgp.com/ 2. GnuPG (Gnu Privacy Guard) Gnu Privacy Guard (GnuPG) is an alternate free substitute for PGP. It can be found at the Gnu Privacy Guard web site http://www.gnupg.org/ • Other Tools 1. lsof lsof lists open files and what UNIX processes have them open. lsof is available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/ 2. ifstatus The ifstatus program can be run on UNIX systems to identify network interfaces that are in debug or promiscuous mode. Network interfaces in these modes may be a sign that an intruder is monitoring the network to steal passwords and other traffic (see CERT Advisory CA-1994-01). The program does not print any output (unless -v is given) unless it finds interfaces in "bad" modes. So, it's easy to run ifstatus from cron once an hour or so. If you have a modern cron that mails the output of cron jobs to their owner, use a line like this: 00 * * * * /usr/local/etc/ifstatus If you have a version of cron that doesn't do this, use the "run-ifstatus" shell script instead (edit the script to use the right path to the command): 00 * * * * /usr/local/etc/run-ifstatus ifstatus is available from many sites, including ftp://coast.cs.purdue.edu/pub/tools/unix/sysutils/ifstatus/ 3. smrsh With all versions of sendmail, we recommend that you use the sendmail restricted shell program, smrsh, by Eric Allman (the original author of sendmail). When configured correctly, the smrsh program can help protect against a vulnerability that can allow unauthorized remote or local users to execute programs as any system user other than root. For example, smrsh can prevent an intruder from using pipes (|) to execute arbitrary commands on your system. We encourage you to use smrsh regardless of whether you use the vendor's supplied sendmail or install sendmail yourself, and regardless of patches that have been installed. Beginning with sendmail version 8.7.1, smrsh is included in the sendmail distribution, in the subdirectory smrsh. See the RELEASE_NOTES file for a description of how to integrate smrsh into your sendmail configuration file. smrsh and sendmail are available from many sites, including http://www.sendmail.org/ Warning: If you are running such an old version of sendmail that you must install smrsh separately, intruders will continue to be able to exploit vulnerabilities that were fixed in later versions of sendmail. We urge you to upgrade to the current version of sendmail mail and then run the tools, which are included with the distribution. Refer to the following files for further information about smrsh and sendmail: o http://www.cert.org/advisories/CA-1996-20.html o http://www.cert.org/advisories/CA-1996-24.html o http://www.cert.org/advisories/CA-1996-25.html 4. mail.local Some versions of /bin/mail based on BSD 4.3 UNIX are vulnerable because of timing windows in the way /bin/mail uses publicly writable directories. If you cannot install a patch from your vendor, replace /bin/mail with mail.local. Beginning with sendmail version 8.7.1, mail.local is included in the sendmail distribution, in the subdirectory mail.local. The program is also available from http://www.sendmail.org/ For further information about mail.local, see http://www.cert.org/advisories/CA-1995-02.html • Other Reading About Security Tools For a list of additional security tools, see Appendix B of the "UNIX Computer Security Checklist" developed by the Australian Computer Emergency Response Team (AUSCERT). A copy of the AUSCERT checklist can be found in ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist ________________________________________ This document is available from: http://www.cert.org/tech_tips/security_tools.html ________________________________________ CERT/CC Contact Information Email: cert@cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo@cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office