Legenda “ping of death”
Di milis ada yang nanya,
permisi teman numapng nanya
misalnya kita mempunya gateway 192.168.10.1 dan client dengan ip 192.168.10.2. bagaimana caranya agar pada saat client melakukan ping -t 192.168.10.1 jumlah reply cuma hanya sampai 4x saja seperti ping biasanya??
pertanyaan menurut saya ini rada ngak nyambung dengan judul emailnya yaitu:
(ask) limit icmp dengan iptables???? Options
nah dari judul email, berarti yang nanya udah tau dong harus ngapain? dia udah tau bahwa dia ingin me-limit icmp dengan menggunakan iptables.
kemudian ada anggota milis mereply dengan memberikan command iptables untuk melimit rate incoming icmp request. yaitu “iptables -A INPUT -p icmp -m limit –limit 1/second -j ACCEPT”
sayangnya bukan ini yang dia inginkan. yang dia mau adalah si server cuman mereply 4 kali, trus abis itu request icmp-nya dicuekin. aneh…
saya pun mereply:
Pertanyaannya, setelah di reply 4 kali, trus mau di reply pake icmp-type yang mana lagi?
Icmp kan nama protokol om, dimana oleh standardnya dibagi lagi menjadi beberapa type. kalo sampean ngeping juga berarti menggunakan salah satu dari icmp-type.
lagian om, saya juga bingung emangnya mau buat apaan?
penjelasan saya:
icmp itu adalah protokol untuk kontrol/maintenance jadi memang secara default feature icmp memang diaktifkan. contoh penggunaan icmp:
- untuk mengecek sebuah server itu hidup atau enggak
- untuk ngasi tau kondisi destination (mis: destination unreachable)
- untuk ngasi tau status ttl
- dll yang mungkinsaya lupa
dari pengalaman saya kerja di telco, ada mesin khusus yang bertugas untuk monitoring, yang terus-menerus ngeping host yang lain. gunanya ya untuk mengecek host sekaligus status jalur tersebut. ntar kalo hasilnya time out, maka ada command untuk failover link itu. nah kalo icmp dimatikan, bukannya justru kita yang rugi yah?
kemudian ada yang reply,
mungkin maksudnya, untuk menghindari client ping secara kontinyu ke server. ya walaupun cuma sebatas ping,, tapi kan juga mengabiskan resources memori..
jadi jika ada client yang ping kontinyu ke server,, akan langsung di drop gitu..
membaca reply ini, saya tersenyum. ooh, mungkin yang dimaksudkan adalah “ping of death” yang dulu sangat melegenda itu. ok saya akan coba bahas sepengahuan saya.
mulai dari socket programming
kalo kita buat socket programming (dengan bahasa c tentu saja), biasanya kita menyediakan buffer untuk menerima paket yang masuk toh? gunanya buffer ini ya seperti ember yang menampung air sampai pada level yang cukup baru kemudian di lempar ke tempat lain. prinsip buffer juga mirip, terutama untuk menghandle paket-paket yang terfragmentasi. jadi paket2 tsb akan di re-assemble di buffer ini sebelum di kirim ke layer diatasnya. umumnya pada ngeset buffer sesuai dengan standar RFC791 yaitu 65kB.
sedangkan besar MTU ethernet adalah 1.5 kB. jadi kalo ngirim paket lebih besar dari MTU ini, otomatis akan dipecah dan informasi ini dimasukkan kedalam field offset di layer 3.
ketika ngirim ping
tahukah anda berapa besar sih paket ping itu? cuman 32 bytes! sehingga tidak masuk diakal jika acara ping-mengeping ini sebagai kambing hitam habisnya resource memory. sebesar-besarnya ping, maka tidak akan melebihi RFC971.
trus ping of death (POD) itu gimana?
nah POD itu bekerja dengan cara memainkan field offset pada header layer 3. dan si penyerang akan terus menerus mengirim paket yang terfragmentasi. dari sisi server, karena paket icmp tersebut terdeteksi sebagai fragment, maka akan ditaruh di buffer untuk di reassembly. C programming tidak seperti java yang memproteksi memory sehingga suatu program tidak dapat seenaknya menulis di halaman memory program lain. Lagipula, waktu jaman POD lagi rame (sekitar pertengahan tahun 90-an) C programming tidak seketat sekarang yang sudah punya proteksi memory. kembali ke proses re-assembly, ternyata server akan terus-menerus me-reassembly paket yang datang. lama-kelamaan buffer yang dipakai habis dan server membuffer paket yang datang di alamat memory lainnnya, dimana bisa jadi alamat ini adalah milik program yang lain. sehingga begitu page memorynya ditulis, program lain akan menjadi error dan sang server akan menderita hang yang akut. teknik ini sekarang sering dikenal sebagai buffer overflow.
trus mitigasinya gimana?
dari proses POD, terlihat jelas ini adalah masalah algoritma programming. dimana bagian kernel yang mengurusi icmp reply tidak mengecek secara tegas icmp request yang masuk. solusinya, ya checkingnya diperkuat terutama ketika mengecek field offset layer 3. Pada akhir 1990an, kernel-kernel unix (solaris, bsd, linux, etc) dan OS lainnya sudah diperbaiki sehingga boleh dikatakan epidemi ini sudah punah dan sekarang hanya menjadi legenda.
paling juga yang menjadi masalah sekarang adalah ping flooding yaitu membanjiri trafik dengan icmp yang banyak sekali (ingat ping flooding, bukan POD). karena banyak trafik icmp tersebut, maka client jadi susah mengakses website kita. kalo sudah begini, meskipun kita mendisable icmp-reply di server, tetap aja ngak ngaruh karena bukan disitu masalahnya. untuk mengatasi masalah ini, kita bisa minta isp kita atau yang lain untuk memblokir ip address yang mengirim floodding tadi sehingga trafik website kita menjadi normal kembali.
sekian artikelnya, mudah2an berguna bagi pembaca. silahkan masukannya.
URL pendek: http://soc.li/IePNaqc
