Apa jenis kerentanan keamanan yang disediakan DNSSEC?


28

Saya berencana untuk menandatangani zona DNS saya dengan DNSSEC. Zona saya, pendaftar dan server DNS saya (BIND9) semuanya mendukung DNSSEC. Satu-satunya yang tidak mendukung DNSSEC adalah penyedia server nama sekunder saya (yaitu buddyns.com ).

Di situs web mereka, mereka menyatakan ini tentang DNSSEC:

BuddyNS tidak mendukung DNSSEC karena mengekspos ke beberapa kerentanan yang tidak cocok untuk layanan DNS volume tinggi.

Yah, saya pikir penggunaan DNSSEC saat ini entah bagaimana dipertanyakan karena sebagian besar resolver tidak memeriksa apakah catatan ditandatangani dengan benar. Apa yang saya tidak tahu adalah bahwa - menurut pernyataan mereka - sepertinya menyediakannya akan memaparkan beberapa jenis kerentanan keamanan.

Apa itu "kerentanan"?


8
temukan penyedia DNS yang lebih peka - alasan mereka palsu.
Alnitak

Jawaban:


103

DNSSEC memiliki beberapa risiko, tetapi tidak secara langsung terkait dengan refleksi atau amplifikasi. Perluasan ukuran pesan EDNS0 adalah herring merah dalam kasus ini. Biarkan saya jelaskan.

Setiap pertukaran paket yang tidak bergantung pada bukti identitas sebelumnya dapat disalahgunakan oleh penyerang DDoS yang dapat menggunakan pertukaran paket yang tidak terauthentikasi sebagai reflektor, dan mungkin juga sebagai penguat. Misalnya, ICMP (protokol di balik "ping") dapat disalahgunakan dengan cara ini. Seperti halnya paket TCP SYN, yang mengumpulkan hingga 40 paket SYN-ACK bahkan jika SYN itu dipalsukan berasal dari beberapa korban yang tidak menginginkan paket SYN-ACK tersebut. Dan tentu saja, semua layanan UDP rentan terhadap serangan ini, termasuk NTP, SSDP, uPNP, dan sebagaimana dicatat oleh tanggapan lain di sini, juga termasuk DNS.

Sebagian besar deteksi intrusi, pencegahan intrusi, dan peralatan penyeimbang beban adalah kemacetan, tidak dapat mengikuti lalu lintas "line rate". Juga banyak router tidak dapat berjalan pada kecepatan garis, dan beberapa switch. Kemacetan ini, dengan menjadi hal terkecil "di jalur", dan lebih kecil dari tautan itu sendiri, adalah target aktual serangan DDoS berbasis kemacetan. Jika Anda dapat membuat firewall seseorang sibuk dengan lalu lintas serangan, lalu lintas yang baik tidak akan dapat melewatinya, bahkan jika tautannya tidak penuh. Dan apa yang memperlambat firewall bukanlah jumlah total bit per detik (yang dapat ditingkatkan dengan menggunakan pesan yang lebih besar, dan EDNS0 dan DNSSEC akan melakukannya), melainkan jumlah total paket per detik.

Ada banyak legenda urban di luar sana tentang bagaimana DNSSEC membuat DDoS lebih buruk karena ukuran pesan DNSSEC yang lebih besar, dan sementara ini membuat akal intuitif dan "terdengar bagus", itu hanya salah. Tetapi jika ada sedikit kebenaran pada legenda ini, jawaban sebenarnya masih ada di tempat lain - [karena DNSSEC selalu menggunakan EDNS0, tetapi EDNS0 dapat digunakan tanpa DNSSEC], dan banyak respons non-DNSSEC normal sebesar DNSSEC tanggapan akan. Pertimbangkan catatan TXT yang digunakan untuk mewakili kebijakan SPF atau kunci DKIM. Atau sembarang kumpulan alamat atau catatan MX besar. Singkatnya, tidak ada serangan yang memerlukan DNSSEC, dan karenanya setiap fokus pada DNSSEC sebagai risiko DDoS adalah energi yang salah sasaran.

DNSSEC memang memiliki risiko! Sulit untuk digunakan, dan lebih sulit untuk digunakan dengan benar. Seringkali itu membutuhkan alur kerja baru untuk perubahan data zona, manajemen pendaftar, pemasangan instance server baru. Semua itu harus diuji dan didokumentasikan, dan setiap kali ada sesuatu yang berhubungan dengan DNS, teknologi DNSSEC harus diselidiki sebagai kemungkinan penyebabnya. Dan hasil akhirnya jika Anda melakukan segalanya dengan benar adalah, sebagai penanda zona, konten dan sistem daring Anda sendiri akan lebih rapuh bagi pelanggan Anda. Sebagai operator server yang jauh, hasilnya adalah, bahwa konten dan sistem orang lain akan lebih rapuh bagi Anda. Risiko-risiko ini sering terlihat lebih besar daripada manfaatnya, karena satu-satunya manfaat adalah melindungi data DNS dari modifikasi atau substitusi dalam penerbangan. Serangan itu sangat langka sehingga tidak sebanding dengan semua upaya ini. Kita semua berharap DNSSEC suatu hari ada di mana-mana, karena aplikasi baru itu akan memungkinkan. Tetapi kenyataannya adalah bahwa hari ini, DNSSEC adalah semua biaya, tanpa manfaat, dan dengan risiko tinggi.

Jadi, jika Anda tidak ingin menggunakan DNSSEC, itu hak prerogatif Anda, tetapi jangan biarkan orang membingungkan Anda bahwa masalah DNSSEC adalah perannya sebagai penguat DDoS. DNSSEC tidak memiliki peran yang diperlukan sebagai penguat DDoS; ada cara lain yang lebih murah dan lebih baik untuk menggunakan DNS sebagai penguat DDoS. Jika Anda tidak ingin menggunakan DNSSEC, biarkan karena Anda belum meminum Kool Aid dan Anda ingin menjadi penggerak terakhir (nanti) bukan penggerak pertama (sekarang).

Server konten DNS, kadang-kadang disebut "server otoritas", harus dicegah agar tidak disalahgunakan sebagai penguat yang mencerminkan DNS, karena DNS menggunakan UDP, dan karena UDP dapat disalahgunakan oleh paket sumber palsu. Cara untuk mengamankan server konten DNS Anda dari penyalahgunaan semacam ini adalah tidak untuk memblokir UDP, atau untuk memaksa TCP (menggunakan trik TC = 1), atau untuk memblokir permintaan APA PUN, atau untuk memilih keluar dari DNSSEC. Tak satu pun dari hal-hal itu akan membantu Anda. Anda perlu Membatasi Tingkat Respons DNS(DNS RRL), teknologi gratis yang sekarang hadir di beberapa server nama sumber terbuka termasuk BIND, Knot, dan NSD. Anda tidak dapat memperbaiki masalah refleksi DNS dengan firewall Anda, karena hanya middlebox yang sadar-konten seperti server DNS itu sendiri (dengan RRL ditambahkan) yang cukup tahu tentang permintaan untuk dapat secara akurat menebak serangan dan apa yang tidak. Saya ingin menekankan, lagi: DNS RRL gratis, dan setiap server otoritas harus menjalankannya.

Sebagai penutup, saya ingin mengekspos bias saya. Saya menulis sebagian besar BIND8, saya menemukan EDNS0, dan saya turut menciptakan DNS RRL. Saya telah bekerja pada DNS sejak tahun 1988 sebagai 20-sesuatu, dan saya sekarang 50-an pemarah, dengan semakin sedikit kesabaran untuk solusi setengah matang untuk masalah disalahpahami. Tolong terimalah permintaan maaf saya jika pesan ini kedengarannya seperti "hai anak-anak, pergi dari halaman saya!"


7
Mengonfirmasi bahwa ini adalah Real Paul ™.
Andrew B

1
@AndrewB yang bukan Real Paul ™, ada huruf kapital di posnya! ;-)
Alnitak

6
@kasperd lihat "draft-ietf-dnsop-cookies", saat ini berkembang melalui IETF.
Alnitak

4
kasperd: [Server DNS yang membatasi tingkat itu sendiri akan menjadi target yang lebih mudah untuk serangan DDoS.] Saya tahu saya idiot, tapi saya bukan idiot itu. dns rrl membuat Anda kurang aman sama sekali. itu bukan pertahanan terhadap semua serangan yang diketahui, tetapi itu adalah pencipta dari tidak ada serangan baru.
Paul Vixie

2
@kasperd basis terinstal selalu menjadi masalah - tidak ada solusi yang akan bekerja bahkan pada basis terinstal yang sesuai, apalagi sistem yang tidak patuh di luar sana. Berita baiknya adalah bahwa dukungan cookie EDNS sudah ada dalam basis kode untuk BIND 9.11 dan (AIUI) akan diaktifkan secara default.
Alnitak

7

Saya tahu dua kerentanan khusus. Ada refleksi / amplifikasi yang disebutkan oleh Håkan. Dan ada kemungkinan enumerasi zona.

Refleksi / penguatan

Refleksi berarti serangan di mana permintaan dengan IP sumber palsu dikirim ke server DNS. Tuan rumah yang dipalsukan adalah korban utama serangan itu. Server DNS tanpa sadar akan mengirim balasan ke host yang tidak pernah memintanya.

Amplifikasi mengacu pada serangan refleksi di mana respons yang direfleksikan terdiri dari lebih banyak byte atau lebih banyak paket daripada permintaan awal. Sebelum amplifikasi DNSSEC + EDNS0 dengan cara ini hanya akan memungkinkan pengiriman hingga 512 byte. Dengan DNSSEC + EDNS0 dimungkinkan untuk dikirim 4096 byte, yang biasanya mencakup 3-4 paket.

Ada kemungkinan mitigasi untuk serangan ini, tapi saya tidak tahu ada server DNS yang menerapkannya.

Ketika IP klien belum dikonfirmasi, server DNS dapat mengirim respons terpotong untuk memaksa klien untuk beralih ke TCP. Respons terpotong dapat sesingkat permintaan (atau lebih pendek jika klien menggunakan EDNS0 dan respons tidak) yang menghilangkan amplifikasi.

IP klien apa pun yang menyelesaikan jabat tangan TCP dan mengirim permintaan DNS pada koneksi dapat sementara masuk daftar putih. Setelah masuk daftar putih IP dapat mengirim permintaan UDP dan menerima tanggapan UDP hingga 512 byte (4096 byte jika menggunakan EDNS0). Jika respons UDP memicu pesan kesalahan ICMP, IP akan dihapus dari daftar putih lagi.

Metode ini juga dapat dibalik menggunakan daftar hitam, yang hanya berarti bahwa IP klien diizinkan untuk melakukan permintaan lebih dari UDP secara default tetapi setiap pesan kesalahan ICMP menyebabkan IP menjadi daftar hitam yang memerlukan kueri TCP untuk keluar dari daftar hitam.

Bitmap yang mencakup semua alamat IPv4 yang relevan dapat disimpan dalam memori 444MB. Alamat IPv6 harus disimpan dengan cara lain.

Enumerasi zona

Apakah enumerasi zona adalah kerentanan di tempat pertama adalah subyek perdebatan. Tetapi jika Anda tidak ingin semua nama di zona Anda menjadi pengetahuan publik, Anda mungkin akan menganggapnya sebagai kerentanan. Enumerasi zona sebagian besar dapat dikurangi melalui penggunaan catatan NSEC3.

Masalah yang masih ada bahkan ketika menggunakan NSEC3 adalah bahwa penyerang dapat menemukan hash dari masing-masing label hanya dengan menanyakan nama acak. Setelah penyerang memiliki semua hash, serangan brute force off-line dapat dilakukan pada hash tersebut.

Pertahanan yang tepat terhadap penghitungan zona akan membutuhkan penyerang untuk melakukan kueri ke server otoritatif untuk setiap tebakan. Namun tidak ada pertahanan seperti itu di DNSSEC.


2
Namun, pencacahan zona tampaknya bukan masalah bagi penyedia layanan? (Agak kekhawatiran yang mungkin untuk "pemilik" zona, tergantung pada pandangan dan preferensi mereka.)
Håkan Lindqvist

@ HåkanLindqvist Benar. Mungkin pertanyaan saya lebih spesifik daripada yang saya inginkan. Saya menemukan informasi ini sangat menarik.
Johann Bauer

Gagasan membolehkan klien yang mencoba TCP telah dipertimbangkan, tetapi tampaknya dipatenkan.
Alnitak

4

Hal yang terlintas dalam pikiran sebenarnya bukan DNSSEC spesifik tetapi tentang ekstensi EDNS0, yang diandalkan DNSSEC.

EDNS0 memungkinkan muatan UDP yang lebih besar dan muatan UDP yang lebih besar dapat memungkinkan serangan refleksi / amplifikasi lalu lintas yang lebih buruk.


Saya tidak tahu berapa persentase resolvers yang divalidasi, tetapi perangkat lunak nameserver populer tampaknya dikirimkan dengan validasi secara default dan seseorang akan dengan mudah menemukan beberapa penyedia layanan terkenal yang terbuka tentang mereka yang melakukan validasi, seperti Comcast dan resolver publik Google.

Berdasarkan ini, saya akan berpikir bahwa persentase memvalidasi resolver mungkin dalam kondisi yang jauh lebih baik daripada persentase zona yang ditandatangani.


Ya, saya berpikir bahwa daging sapi mungkin juga dengan EDNS. Sangat aneh untuk memilih tulang dengan DNSSEC bukan itu sekalipun.
Andrew B
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.