Panduan utama untuk mencegah serangan DDoS berbasis DNS

Ketika berbicara tentang DNS, Cricket Liu benar-benar menulis buku itu. Dia telah ikut menulis kelima edisi buku "DNS and BIND" O'Reilly, yang secara umum dianggap sebagai panduan definitif tentang semua hal yang berkaitan dengan Sistem Nama Domain. Cricket saat ini adalah kepala petugas infrastruktur di Infoblox.

DNS jelas merupakan komponen penting dari jaringan komputer, tetapi ada kalanya alat ini dapat digunakan untuk penyimpangan. Dalam Forum Teknologi Baru minggu ini, Cricket membahas masalah yang berkembang dari serangan DDoS berbasis DNS dan cara menanganinya. - Paul Venezia

Serangan DDoS berbasis DNS: Bagaimana cara kerjanya dan cara menghentikannya

DDoS berbasis DNS (serangan penolakan layanan terdistribusi) telah menjadi salah satu serangan destruktif yang paling umum di Internet. Tapi bagaimana cara kerjanya? Dan apa yang dapat kita lakukan untuk bertahan melawan mereka?

Dalam artikel ini, saya akan menjelaskan bagaimana DDoS menyerang baik mengeksploitasi dan menargetkan infrastruktur DNS. Saya juga akan menunjukkan kepada Anda apa yang dapat Anda lakukan untuk melindungi diri sendiri dan orang lain.

Spoof besar

Menghasilkan serangan DDoS menggunakan infrastruktur DNS sangat sederhana: Penyerang mengirim kueri ke server nama di Internet, dan server nama tersebut mengembalikan respons. Alih-alih mengirim kueri dari alamat IP mereka sendiri, penyerang memalsukan alamat target mereka - yang bisa berupa server Web, router, server nama lain, atau hampir semua node di Internet.

Spoofing DNS queries sangat mudah karena biasanya dibawa melalui UDP (User Datagram Protocol). Mengirim kueri DNS dari alamat IP arbitrer sama mudahnya dan memiliki efek yang kurang lebih sama seperti menulis alamat pengirim orang lain di kartu pos.

Pertanyaan spoofing tidak cukup untuk melumpuhkan target. Jika tanggapan atas kueri tersebut tidak lebih besar dari kueri itu sendiri, penyerang juga akan membanjiri target dengan kueri palsu. Tidak, untuk memaksimalkan kerusakan pada target, setiap kueri harus mengembalikan respons yang sangat besar. Ternyata itu sangat mudah dilakukan.

Sejak munculnya EDNS0, satu set ekstensi ke DNS yang diperkenalkan pada tahun 1999, pesan DNS berbasis UDP telah mampu membawa banyak data. Respons bisa sebesar 4.096 byte. Sebaliknya, sebagian besar kueri berukuran kurang dari 100 byte.

Dahulu kala, relatif sulit untuk menemukan respons sebesar itu di namespace Internet. Tetapi sekarang organisasi telah mulai menerapkan DNSSEC, Ekstensi Keamanan DNS, itu jauh lebih mudah. DNSSEC menyimpan kunci kriptografi dan tanda tangan digital dalam catatan di namespace. Ini sangat besar.

Anda dapat melihat contoh respon dari zona isc.org yang berisi data DNSSEC di blog saya. Ukuran responsnya adalah 4.077 byte, dibandingkan dengan kueri yang hanya 44 byte.

Sekarang, penyerang gambar dari seluruh Internet mengirimkan kueri palsu itu dari alamat IP server Web Anda ke server nama isc.org. Untuk setiap kueri 44-byte, server Web Anda menerima respons 4.077-byte, untuk faktor amplifikasi hampir 93 kali.

Mari kita lakukan penghitungan cepat untuk mengetahui seberapa buruk hal ini. Katakanlah setiap penyerang memiliki koneksi internet 1Mbps yang relatif sederhana. Dia dapat mengirim sekitar 2.840 kueri 44-byte melalui tautan itu per detik. Aliran kueri ini akan menghasilkan hampir 93Mbps balasan yang mencapai server Web Anda. Setiap 11 penyerang mewakili 1Gbps.

Di mana penyerang antisosial menemukan 10 teman untuk membantu mereka melakukan serangan? Sebenarnya, mereka tidak membutuhkannya. Mereka akan menggunakan botnet dari ribuan komputer.

Efek akhirnya sangat menghancurkan. Dalam Laporan Serangan DDoS global triwulanan mereka, Prolexic (perusahaan mitigasi DDoS) melaporkan serangan berbasis DNS baru-baru ini terhadap pelanggan yang mencapai 167Gbps. Prolexic selanjutnya melaporkan bahwa rata-rata bandwidth serangan DDoS naik 718 persen menjadi 48Gbps dalam satu kuartal .

Tapi tunggu! Tidak bisakah server nama isc.org dimodifikasi untuk mengenali bahwa mereka sedang ditanyai berulang kali untuk data yang sama, dari alamat IP yang sama? Tidak bisakah mereka menghentikan serangan itu?

Mereka pasti bisa. Tetapi server nama isc.org bukan satu-satunya yang dapat digunakan penyerang untuk meningkatkan lalu lintasnya. Tentu, ada server nama otoritatif lain yang dapat digunakan penyerang, tetapi yang lebih buruk lagi adalah server nama rekursif terbuka.

Server nama rekursif terbuka hanyalah server nama yang akan memproses kueri rekursif dari alamat IP mana pun. Saya dapat mengirimkan kueri itu untuk data isc.org dan itu akan membalas saya, dan Anda dapat melakukan hal yang sama.

Seharusnya tidak ada banyak server nama rekursif terbuka di Internet. Fungsi server nama rekursif adalah untuk mencari data di namespace Internet atas nama klien DNS, seperti yang ada di laptop atau ponsel cerdas Anda. Administrator jaringan yang menyiapkan server nama rekursif (seperti departemen TI Anda) biasanya menginginkannya untuk digunakan oleh komunitas tertentu (misalnya, Anda dan sesama karyawan). Kecuali jika mereka menjalankan layanan seperti OpenDNS atau Google Public DNS, mereka tidak bermaksud menggunakannya oleh warga Moldova. Jadi, administrator yang berjiwa publik, berpikiran keamanan, dan paling kompeten mengonfigurasi kontrol akses pada server nama rekursif mereka untuk membatasi penggunaannya pada sistem resmi.

Mengingat itu, seberapa besar masalah bisa membuka server nama rekursif? Cukup besar. Proyek Penyelesai Terbuka telah mengumpulkan daftar 33 juta server nama rekursif terbuka. Peretas dapat menjalankan kueri palsu sebanyak yang mereka suka untuk memuntahkan data isc.org di server Web, server nama, atau router perbatasan Anda hingga tersedak.

Begitulah cara kerja serangan DDoS berbasis DNS. Untungnya, kami memiliki beberapa cara untuk memerangi mereka.

Bagaimana mengatasi badai

Urutan pertama bisnis adalah melengkapi infrastruktur DNS Anda, sehingga Anda akan tahu saat Anda diserang. Terlalu banyak organisasi yang tidak tahu apa yang memuat kueri mereka, jadi mereka tidak akan pernah tahu jika mereka diserang sejak awal.

Menentukan pemuatan kueri Anda bisa sesederhana menggunakan dukungan statistik bawaan BIND. Server nama BIND akan membuang data ke file statistiknya saat Anda menjalankan statistik rndc,misalnya, atau pada interval statistik yang dapat dikonfigurasi. Anda dapat memeriksa statistik untuk tingkat kueri, kesalahan soket, dan indikasi serangan lainnya. Jangan khawatir jika Anda belum yakin seperti apa serangan itu - bagian dari tujuan pemantauan DNS adalah untuk membuat garis dasar, sehingga Anda dapat mengidentifikasi apa yang tidak normal.

Selanjutnya, lihat infrastruktur Anda yang menghadap ke Internet. Jangan membatasi diri Anda pada server nama otoritatif eksternal Anda; periksa infrastruktur switch dan router Anda, firewall Anda, dan koneksi Anda ke Internet. Identifikasi titik kegagalan apa pun. Tentukan apakah Anda dapat dengan mudah (dan hemat biaya) menghilangkannya.

Jika memungkinkan, pertimbangkan distribusi geografis yang luas dari server nama otoritatif eksternal Anda. Ini membantu menghindari satu titik kegagalan, tentu saja, tetapi juga membantu saat Anda tidak sedang diserang. Server nama rekursif yang menyelesaikan nama domain di salah satu zona Anda akan mencoba menanyakan server nama otoritatif yang paling dekat dengannya, sehingga distribusi geografis akan cenderung memberikan kinerja yang lebih baik kepada pelanggan dan koresponden Anda. Jika pelanggan Anda berkerumun di wilayah geografis tertentu, coba letakkan server nama resmi di dekat mereka untuk memberikan tanggapan tercepat.

Mungkin cara paling dasar untuk memerangi serangan DoS adalah dengan menyediakan infrastruktur Anda secara berlebihan. Kabar baiknya adalah bahwa penyediaan server nama Anda secara berlebihan belum tentu mahal; server nama yang mampu menangani puluhan atau bahkan ratusan ribu kueri per detik. Tidak yakin dengan kapasitas server nama Anda? Anda dapat menggunakan alat kueri seperti dnsperf untuk menguji kinerja server nama Anda - sebaiknya menggunakan platform pengujian yang mirip dengan server nama produksi Anda di lab daripada server produksi itu sendiri.

Memutuskan berapa banyak untuk menyediakan server nama Anda secara berlebihan adalah subjektif: Berapa nilai kehadiran online Anda? Apakah ada komponen lain dari infrastruktur yang berhubungan dengan Internet Anda yang akan gagal sebelum server nama? Jelas, sangat bodoh mengeluarkan uang untuk membangun infrastruktur DNS kelas satu di belakang router perbatasan atau firewall yang akan gagal dengan baik bahkan sebelum server nama Anda berkeringat.

Jika uang bukanlah masalah, mungkin berguna untuk mengetahui bahwa serangan DDoS yang canggih terhadap infrastruktur DNS dapat melebihi 100Gbps.

Menggunakan Anycast juga dapat membantu menahan serangan DDoS. Anycast adalah teknik yang memungkinkan beberapa server berbagi satu alamat IP, dan ini bekerja sangat baik dengan DNS. Faktanya, server nama akar Internet telah menggunakan Anycast selama bertahun-tahun untuk menyediakan data zona akar di seluruh dunia sambil tetap mengizinkan daftar akar untuk dimasukkan ke dalam satu pesan DNS berbasis UDP.

Untuk menerapkan Anycast, host yang mendukung server nama Anda perlu menjalankan protokol perutean dinamis, seperti OSPF atau BGP. Proses perutean akan mengiklankan ke router tetangganya sebuah rute ke alamat IP virtual baru yang didengarkan oleh server nama Anda. Proses perutean juga harus cukup pintar untuk berhenti mengiklankan rute itu jika server nama lokal berhenti merespons. Anda dapat merekatkan daemon perutean Anda ke kesehatan server nama Anda menggunakan kode konstruksi Anda sendiri - atau Anda dapat membeli produk yang menangani itu untuk Anda. NIOS Infoblox, tidak secara kebetulan, menyertakan dukungan Anycast.

Bagaimana Anycast bertahan dari serangan DDoS? Nah, katakanlah Anda memiliki enam server nama eksternal dalam dua grup Anycast (yaitu, tiga berbagi satu alamat IP Anycast dan tiga berbagi alamat IP lainnya). Setiap grup berisi satu anggota di Amerika Serikat, satu di Eropa, dan satu di Asia. Sebuah host memasang serangan DDoS terhadap Anda hanya dapat mengirim lalu lintas ke - dan karenanya hanya menyerang - satu anggota dari salah satu grup dari titik mana pun di Internet pada satu waktu. Kecuali penyerang dapat memperoleh lalu lintas yang cukup dari Amerika Utara, Eropa, dan Asia secara bersamaan untuk membanjiri infrastruktur Anda, mereka tidak akan berhasil.

Terakhir, ada cara untuk memanfaatkan distribusi geografis yang luas dan Anycast secara bersamaan, tanpa pengeluaran modal yang signifikan: Gunakan penyedia DNS berbasis cloud. Perusahaan seperti Dyn dan Neustar menjalankan server nama Anycast mereka sendiri di pusat data di seluruh dunia. Anda membayar mereka untuk menghosting zona Anda dan menjawab pertanyaan untuk data Anda. Dan Anda dapat terus mempertahankan kontrol langsung atas data zona Anda dengan meminta penyedia untuk mengonfigurasi server namanya sebagai server kedua untuk zona Anda, memuat data dari server nama master yang Anda tetapkan dan kelola sendiri. Pastikan Anda menjalankan master tersembunyi (yaitu, tanpa catatan NS yang mengarah ke sana), atau Anda berisiko bahwa penyerang akan menargetkannya sebagai satu titik kegagalan.

Satu kata peringatan saat menggunakan penyedia DNS berbasis cloud: Sebagian besar menagih Anda setidaknya sebagian berdasarkan jumlah kueri yang diterima server nama mereka untuk data di zona Anda. Dalam serangan DDoS, kueri tersebut mungkin meningkat secara dramatis (sepenuhnya di luar kendali Anda dan sama sekali tidak menguntungkan Anda), jadi pastikan mereka memiliki ketentuan untuk menangani serangan DDoS tanpa membebankan biaya lalu lintas kepada Anda.

Bagaimana menghindari menjadi kaki tangan dalam serangan DDoS

Sekarang Anda tahu cara mengonfigurasi infrastruktur DNS Anda untuk menahan serangan DDoS. Namun, hampir sama pentingnya untuk memastikan bahwa Anda tidak terlibat dalam serangan DDoS terhadap orang lain.

Ingat uraian tentang bagaimana server DNS dapat memperkuat lalu lintas? Penyerang dapat menggunakan server nama rekursif terbuka dan server nama otoritatif sebagai amplifier, mengirimkan kueri palsu yang menyebabkan server nama mengirim respons lebih dari 100 kali lebih besar dari kueri ke target arbitrer di Internet. Sekarang, tentu saja Anda tidak ingin menjadi sasaran serangan seperti itu, tetapi Anda juga tidak ingin menjadi kaki tangan. Serangan itu menggunakan sumber daya server nama Anda serta bandwidth Anda. Jika target mengambil tindakan untuk memblokir lalu lintas dari server nama Anda ke jaringannya, maka setelah serangan berakhir, target mungkin tidak dapat menyelesaikan nama domain di zona Anda.

Jika Anda menjalankan server nama rekursif terbuka, solusinya sederhana: Jangan. Ada sangat sedikit organisasi yang memiliki justifikasi untuk menjalankan server nama yang terbuka untuk kueri rekursif. Google Public DNS dan OpenDNS adalah dua yang muncul di benak Anda, tetapi jika Anda membaca ini, saya rasa Anda mungkin bukan mereka. Kita semua harus menerapkan kontrol akses ke server nama rekursif kita untuk memastikan hanya querier resmi yang menggunakannya. Itu mungkin berarti membatasi kueri DNS ke alamat IP di jaringan internal kami, yang mudah dilakukan pada implementasi server nama apa pun yang sepadan. (Server DNS Microsoft tidak mendukung kontrol akses berbasis alamat IP pada kueri. Baca apa yang Anda inginkan.)

Tetapi bagaimana jika Anda menjalankan server nama otoritatif? Jelas, Anda tidak dapat membatasi alamat IP dari mana Anda akan menerima kueri - atau tidak terlalu banyak (Anda mungkin menolak permintaan dari alamat IP yang jelas-jelas palsu, seperti alamat RFC 1918). Tetapi Anda dapat membatasi tanggapan.

Dua "topi putih" Internet lama, Paul Vixie dan Vernon Schryver, menyadari serangan DDoS yang menggunakan server nama otoritatif untuk amplifikasi menunjukkan pola kueri tertentu. Secara khusus, penyerang mengirimkan permintaan yang sama kepada server nama dari alamat IP palsu yang sama (atau blok alamat) berulang kali, mencari amplifikasi maksimum. Tidak ada server nama rekursif yang berperilaku baik yang akan melakukan itu. Respons tersebut akan disimpan dalam cache dan tidak diminta lagi sampai waktu untuk menjalankan rekaman dalam respons tersebut telah berlalu.