Serangan tercermin tercermin pada server DNS


11

Istilah Amplified reflected attackini baru bagi saya, dan saya punya beberapa pertanyaan tentangnya.

Saya pernah mendengar itu kebanyakan terjadi dengan server DNS - apakah itu benar?
Bagaimana Anda melindunginya?
Bagaimana Anda tahu jika server Anda dapat digunakan dalam serangan seperti itu - Apakah ini masalah konfigurasi?

Jawaban:


22

Pertama, jenis serangan ini bukan (terutama) menargetkan DNS itu sendiri seperti judul Anda sarankan. Tentu saja akan membuat beberapa beban tambahan pada server DNS tetapi tujuan utamanya adalah untuk DDoS orang lain. Konfigurasi server yang buruk mungkin memperburuknya tetapi pada akhirnya masalah ini melekat dalam desain DNS dan UDP dan, pada kenyataannya, protokol komunikasi stateless.

Ini pada dasarnya bekerja seperti ini: Seorang penyerang mengirimkan permintaan (DNS) biasa ke server (DNS). Kueri tersebut dipalsukan agar seolah-olah berasal dari sistem target. Server DNS sekarang menjawab query, mengirimkan jawaban kembali ke nya diduga asal - korban. Inilah sebabnya mengapa disebut serangan refleksi .

Ini dimungkinkan karena Anda dapat memverifikasi sumber komunikasi stateless (seperti DNS melalui UDP) dan Anda dapat mempercayai alamat pengirim pada kartu pos. Server tidak memiliki cara untuk memutuskan apakah permintaan itu sah atau bagian dari serangan semacam itu. DNS hanyalah protokol paling populer di sini karena ada banyak dan banyak server untuk itu dan Anda tidak perlu banyak wawasan teknis atau peralatan khusus untuk (salah) menggunakannya.

Untuk membuat segalanya lebih buruk (dan sama sekali efisien dari serangan), lihat bagian amplifikasi . Tidak akan terlalu berbahaya jika traffic penyerang sama besar dengan traffic yang dihasilkan. Satu-satunya manfaat bagi penyerang adalah bahwa alamatnya disembunyikan di balik server DNS. Dia bisa memalsukan alamat pengirim secara langsung, sama sekali tidak perlu melakukan rute ulang melalui DNS. Tetapi DNS menjawab, dan itulah poin lain mengapa DNS sangat populer di sini, bisa jauh lebih besar dari pertanyaan. Anda dapat menemukan angka yang bervariasi pada ini tergantung pada permintaan yang tepat digunakan, tetapi bisa naik hingga 1:60 jika server cukup ramah untuk melakukan permintaan rekursifuntukmu. Jadi penyerang tidak membutuhkan banyak mesin di bawah kendalinya untuk menghasilkan banyak lalu lintas berbahaya.

Karena Anda dapat dengan mudah menemukan ratusan dan ribuan server DNS "terbuka" di internet publik, Anda dapat melakukan perhitungan cepat seberapa sedikit pekerjaan yang harus dilakukan penyerang jika setiap server DNS terbuka yang ia tahu akan mencerminkan kueri yang dikuatkan enam kali lipat ke target. Seperti yang saya katakan di awal, tidak ada cara yang benar-benar baik untuk mengatasi ini. Secara alami banyak server DNS terbuka untuk semua orang, padahal seharusnya tidak, karena kesalahan konfigurasi. Tetapi ada banyak server terbuka yang harus dibuka, karena itulah tujuan mereka.

Meskipun Anda tidak dapat mengetahui apakah permintaan merupakan bagian dari serangan atau bukan, satu-satunya pilihan Anda adalah tidak menjalankan server lagi. Anda bisa bermain-main dengan batasan tarif dan mainan lain tetapi Anda tidak bisa sepenuhnya menyingkirkan ini. Jika Anda menyediakan DNS untuk bersenang-senang, Anda dapat memasukkan daftar hitam sumber IP permintaan. Tetapi jika Anda berada dalam skala yang lebih besar ini akan lebih merusak korban. Ingat, yang bisa Anda lihat di server DNS adalah alamat korban. Bayangkan perusahaan Anda sedang diserang melalui DNS penyedia Anda dan penyedia Anda memutuskan untuk memotong layanan DNS untuk perusahaan Anda. Penyerang bisa mencetak ini sebagai poin bonus trilyun tentang penolakan layanan .

Bagaimanapun, serangan itu terjadi sepanjang hari dan malam dan mereka dianggap sebagai "suara latar" dari internet. Jika Anda menyiapkan server DNS publik (rekursif), tidak akan lama sebelum Anda berpartisipasi dalam serangan acak. Tentu saja kadang-kadang keadaan menjadi sangat buruk ketika infrastruktur besar (seperti bahkan server root dns) disalahgunakan untuk memperbesar tetapi dalam kasus-kasus tersebut tindakan proaktif diambil oleh personell sampai serangan turun ke level "normal".


Sejauh ini dalam pengajaran. Untuk menjawab pertanyaan Anda, akhirnya:

Anda tahu server Anda rentan jika menjawab pertanyaan tanpa batasan. Titik. Jika Anda melayani permintaan rekursif, server Anda dapat menghasilkan rasio 1:60 yang disebutkan untuk penyerang. Jika hanya melayani un-rekursif itu tidak seburuk, tapi masih ...

Begitu...

  • pastikan Anda benar-benar perlu menjalankan server DNS publik
  • jika Anda harus, lihat BIND allow-recursiondan allow-queryarahan
  • jika server DNS Anda akan memiliki otorisasi untuk zona Anda sendiri , sama sekali tidak perlu untuk rekursi, setel allow-recursionke "tidak ada;"
  • jika Anda ingin menjalankan resolver untuk domain lain , batasi pengguna yang diizinkan untuk kueri dan kueri rekursif. Anda dapat menentukan alamat IP, jaringan atau daftar akses dalam arahan yang disebutkan
  • pikirkan tentang pembatasan lalu lintas DNS tingkat tidak hanya di BIND tetapi juga pada tingkat sistem. Sebagai contoh yang sangat sederhana, aturan iptables ini tidak akan mengizinkan lebih dari 10 kueri per menit dari setiap alamat IP:

.

iptables -A INPUT -p udp --dport 53 --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP

Sekarang, dengan poin-poin ini dalam pikiran Anda harus baik untuk pergi. Mungkin masih ada lalu lintas jahat di server Anda sekarang dan kemudian tetapi tidak dalam jumlah yang membuat Anda tidur nyenyak.


3
Ini jawaban yang sangat bagus. Terima kasih telah meluangkan waktu untuk menulisnya.
jamieb

1
@mikejanson serverfault.com/questions/450099 - lihat pertanyaan ini untuk melihat opsi apa yang mungkin Anda miliki (terutama patch BIND oleh Vixie & Schryver )
the-wabbit

RRL sekarang menjadi fitur standar dari bind dan nameserver lainnya: kb.isc.org/article/AA-01000/189/…
Patrick Mevzek

Secara umum salah memiliki server yang sama otoritatif dan rekursif. Praktik terbaik menyarankan untuk memecahnya menjadi dua proses terpisah.
Patrick Mevzek
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.