Soru DNSSEC'i ne tür güvenlik açıkları ortaya koyuyor?


DNS bölgemi DNSSEC ile imzalamayı planlıyorum. Bölgem, kayıt şirketi ve DNS sunucum (BIND9) hepsi DNSSEC'yi destekliyor. DNSSEC'yi desteklemeyen tek kişi ikincil ad sunucusu sağlayıcım ( buddyns.com).

Kendi web sitesindebunu DNSSEC ile ilgili olarak belirtiyorlar:

BuddyNS, DNSSEC'yi desteklemiyor çünkü bazılarına gösteriyor   yüksek hacimli DNS hizmetine uygun olmayan güvenlik açıkları.

Eh, çoğu çözümleyicinin kayıtların doğru şekilde imzalanıp imzalanmadığını kontrol etmediğinden DNSSEC kullanımının bir şekilde şüpheli olduğunu düşündüm. Bilmediğim şey - açıklamalarına göre - bunun bir tür güvenlik açıklarını açığa çıkarmasını sağlamak gibi görünüyor.

Bu "savunmasızlıklar" nedir?


27
2017-07-23 21:37


Menşei


Daha dikkatli bir DNS sağlayıcısı bulun - onların mazeretleri yanlıştır. - Alnitak


Cevaplar:


DNSSEC'in bazı riskleri vardır, ancak bunlar doğrudan yansıma veya büyütme ile ilgili değildir. EDNS0 mesaj boyutu genişleme bu durumda kırmızı bir ringa balığıdır. Açıklamama izin ver.

Önceki bir kimlik kanıtına bağlı olmayan herhangi bir paket değişimi, kimliği doğrulanmamış paket değişimini bir yansıtıcı olarak ve belki de bir amplifikatör olarak kullanabilen DDoS saldırganlarının tacizine maruz kalır. Örneğin, ICMP ("ping" in arkasındaki protokol) bu şekilde kötüye kullanılabilir. SYN-ACK paketlerini istemeyen bir kurbandan gelmek için SYN'ye takılmış olsa bile, 40 SYN-ACK paketine kadar istekte bulunan TCP SYN paketi gibi. Ve tabii ki, UDP hizmetleri, NTP, SSDP, uPNP dahil olmak üzere bu saldırıya karşı savunmasızdır ve burada DNS de dahil olmak üzere diğer yanıtlarda belirtildiği gibi.

En saldırı tespit, izinsiz giriş önleme ve yük dengeleyici aletleri, "hat hızı" trafiğine ayak uyduramayan darboğazlardır. Ayrıca birçok yönlendirici hat hızında ve bazı anahtarlarda çalışamaz. Bu darboğazlar, "yolda" en küçük şey olarak ve bağlantıların kendisinden daha küçük olan, tıkanıklık tabanlı DDoS saldırılarının asıl hedefi. Birisinin güvenlik duvarını saldırı trafiği ile meşgul tutabiliyorsanız, bağlantılar dolu olmasa bile iyi trafik geçmez. Ve bir güvenlik duvarını yavaşlatan şey, saniyedeki toplam bit sayısıdır (daha büyük mesajlar kullanılarak artırılabilir ve EDNS0 ve DNSSEC yapacaklardır), bunun yerine saniyede toplam paket sayısıdır.

DNSSEC'in DNSSEC'in daha büyük mesaj boyutu nedeniyle DDoS'yi nasıl daha kötü hale getirdiği konusunda bir sürü şehir efsanesi var ve bu sezgisel anlamda ve “kulağa hoş geliyor” iken, bu sadece yanlıştır. Fakat eğer bu efsaneye bir parça gerçek varsa, gerçek cevap başka bir yerde olabilirdi - [çünkü DNSSEC her zaman EDNS0 kullanıyor, ancak EDNS0 DNSSEC olmadan kullanılabilir] ve DNSSEC olmayan birçok normal DNSSEC kadar büyük. cevap olurdu. SPF politikalarını veya DKIM anahtarlarını temsil etmek için kullanılan TXT kayıtlarını düşünün. Ya da sadece herhangi bir büyük adres veya MX kaydı. Kısacası, hiçbir saldırı DNSSEC gerektirmez ve bu nedenle DNSSEC riskine karşı herhangi bir odak noktası hatalı enerji demektir.

DNSSEC'in riskleri var! Kullanımı zor ve doğru kullanımı zor. Çoğu zaman bölge verileri değişiklikleri, kayıt yönetimi, yeni sunucu örneklerinin yüklenmesi için yeni bir iş akışı gerektirir. Bunların hepsi test edilmeli ve belgelendirilmeli ve DNS ile ilgili bir arıza olduğunda, DNSSEC teknolojisi olası bir neden olarak araştırılmalıdır. Ve sonuç olarak her şey doğru yaparsanız, bir bölge imzalayan olarak kendi çevrimiçi içeriğiniz ve sistemleriniz müşterileriniz için daha kırılgan olacaktır. Uzak uç sunucu operatörü olarak sonuç, herkesin içeriği ve sistemlerinin sizin için daha kırılgan olacağıdır. Bu risklerin çoğu zaman faydalardan daha ağır basmaktadır. Çünkü tek avantaj, DNS verilerini uçuş modifikasyonundan veya ikamesinden korumaktır. Bu saldırı tüm bu çabaya değmeyecek kadar nadirdir. Hepimizin sağlayacağı yeni uygulamalardan dolayı DNSSEC'in bir gün her yerde bulunmasını ümit ediyoruz. Fakat gerçek şu ki, DNSSEC bugün tüm maliyet, fayda ve yüksek riskler.

Yani DNSSEC kullanmak istemiyorsanız, bu sizin ayrıcalığınızdır, ancak kimsenin size DNSSEC'in probleminin bir DDoS amplifikatörü olarak rolünün olduğunu karıştırmasına izin vermeyin. DNSSEC'in DDoS amplifikatörü olarak gerekli rolü yoktur; DNS'yi DDoS amplifikatörü olarak kullanmanın diğer daha ucuz daha iyi yolları vardır. DNSSEC'yi kullanmak istemiyorsanız, bunun Kool Yardımı'nı henüz sarhoş etmediğinizden ve bir son hareket ettirici (sonradan) olmak istemediğiniz için izin verin (şimdi).

DNS içerik sunucuları, bazen "yetki sunucuları" olarak adlandırılır, DNS yansıtıcı amplifikatörler olarak istismar edilmemelidir, çünkü DNS UDP kullanır ve UDP taklit kaynak paketler tarafından kullanılamaz. DNS içerik sunucunuzu bu tür bir kötüye kullanıma karşı korumanın yolu, UDP'yi engellememek ve TCP'yi (TC = 1 hile kullanarak), ANY sorgusunu engellememek veya DNSSEC'yi devre dışı bırakmak değildir. Bu şeylerin hiçbiri sana yardım etmeyecek. İhtiyacın var DNS Yanıt Oranı Sınırlaması (DNS RRL), şu anda BIND, Knot ve NSD dahil olmak üzere birçok açık kaynaklı ad sunucusunda bulunan tamamen ücretsiz bir teknoloji. DNS yansıma sorununu güvenlik duvarınızla düzeltebilirsiniz, çünkü DNS sunucusunun kendisi gibi (RRL eklendiğinde) yalnızca içeriğe duyarlı bir middlebox, saldırının ne olduğunu ve neyin doğru olmadığını tahmin edebilmek için istek hakkında yeterli bilgiye sahiptir. Tekrar vurgulamak istiyorum: DNS RRL ücretsizdir ve her yetkili sunucu onu çalıştırmalıdır.

Kapanışta önyargılarımı açığa çıkarmak istiyorum. BIND8'in çoğunu yazdım, EDNS0'ı icat ettim ve DNS RRL'yi birlikte icat ettim. 1988'den beri 20'den beri bir şey olarak DNS üzerinde çalışıyorum ve şimdi yanlış anlaşılan sorunlara yarım-fırınlanmış çözümler için daha az sabrına sahip, şimdi 50 yaşında bir şeyim var. Bu mesajın "merhaba çocuklar, çimim olsun!" Gibi geliyorsa özür dilerim.


101
2018-01-06 20:42



Bunun gerçek Paul olduğunu doğrulamak. - Andrew B
@AndrewB gerçek Paul olamaz, onun yazı büyük harfler var! ;-) - Alnitak
@kasperd, şu anda IETF üzerinden ilerleyen "taslak-ietf-dnsop-çerezleri" konusuna bakın. - Alnitak
kasperd: [Hız sınırlama yapan bir DNS sunucusu, DDoS saldırıları için daha kolay bir hedef haline gelecektir.] Biliyorum, ben bir aptalım, ama bu kadar aptalı değilim. dns rrl, sizi hiçbir şekilde daha az güvenli kılar. bilinen tüm saldırılara karşı bir savunma değil, yeni saldırıların yaratıcısı. - Paul Vixie
Yüklenen tabanın @kasperd olması her zaman bir problemdir - uyumlu olmayan sistemlerde bile çalışacak, uyumlu olmayan sistemlerde bile çalışacak bir çözüm yoktur. İyi haber, EDNS cookie desteğinin BIND 9.11 için kod tabanında olduğunu ve varsayılan olarak (AIUI) açılacak olmasıdır. - Alnitak


İki belirli güvenlik açığını biliyorum. Håkan tarafından belirtilen yansıma / büyütme var. Ve bölge sayımı olasılığı var.

Yansıma / büyütme

Yansıma, sahte bir kaynak IP ile yapılan isteklerin bir DNS sunucusuna gönderildiği saldırıları ifade eder. Saldırıya uğrayan ev sahibi, saldırının birincil kurbanıdır. DNS sunucusu, cevabı bilmeden, hiç bir zaman istemeyen bir ana bilgisayara gönderecektir.

Amplifikasyon, yansıyan yanıtın orijinal talepten daha fazla bayt veya daha fazla paket içerdiği herhangi bir yansıma saldırısına karşılık gelir. Bu şekilde DNSSEC + EDNS0 amplifikasyonu öncesinde sadece 512 bayta kadar izin verilebilir. DNSSEC + EDNS0 ile, genellikle 3-4 paket içeren 4096 bayt gönderilebilir.

Bu saldırılar için olası hafifletmeler var, ancak bunları uygulayan herhangi bir DNS sunucusunu bilmiyorum.

İstemci IP'si doğrulanmadığında, DNS sunucusu istemcinin TCP'ye geçmesini zorlamak için kesilmiş bir yanıt gönderebilir. Kesik yanıt, talebin kadar kısa olabilir (veya istemci EDNS0 kullanıyorsa ve cevap almıyorsa), amplifikasyonu ortadan kaldırabilir.

TCP el sıkışma işlemini tamamlayan ve bağlantıda bir DNS isteği gönderen herhangi bir istemci IP'si geçici olarak beyaz listeye alınabilir. IP, UDP sorguları gönderip 512 bayta UDP yanıtı alır (EDNS0 kullanılıyorsa 4096 bayt). Bir UDP yanıtı bir ICMP hata mesajını tetiklerse, IP tekrar beyaz listeden çıkarılır.

Yöntem, kara listeye göre de tersine çevrilebilir, bu da sadece istemci IP'lerinin varsayılan olarak UDP üzerinden sorgulanmasına izin verdiği anlamına gelir, ancak herhangi bir ICMP hata mesajı IP'nin kara listeden çıkmak için bir TCP sorgusuna ihtiyacı olan kara listeye alınmasına neden olur.

İlgili tüm IPv4 adreslerini kapsayan bir bitmap, 444MB'lık bellekte saklanabilir. IPv6 adresleri başka bir şekilde saklanmalıdır.

Bölge numaralandırması

Bölge numaralandırmanın ilk aşamada bir güvenlik açığı olup olmadığı tartışmaya açıktır. Ancak, bölgenizdeki tüm isimlerin kamusal bilgi olmasını istemiyorsanız, büyük olasılıkla bunu bir güvenlik açığı olarak düşünebilirsiniz. Bölge numaralandırması, çoğunlukla NSEC3 kayıtlarının kullanımıyla azaltılabilir.

NSEC3 kullanırken bile hala devam eden sorun, bir saldırganın her bir etiketin karma değerini sadece rastgele adlar için sorgulayarak bulabilmesidir. Saldırganın tüm karmaları olduğu zaman, bu karmalar üzerinde off-line kaba kuvvet saldırısı gerçekleştirilebilir.

Bölge numaralandırmasına karşı uygun bir savunma, saldırganın her tahmin için yetkili sunucuya bir sorgulama yapmasını gerektirir. Ancak DNSSEC'de böyle bir savunma yoktur.


7
2017-07-24 07:00



Bölge numaralandırma servis sağlayıcı için bir endişe gibi görünmüyor mu? (Görüş ve tercihlerine bağlı olarak "sahip" bölgesi için olası bir endişe.) - Håkan Lindqvist
@ HåkanLindqvist Doğru. Belki de sorum benim istediğimden daha spesifikti. Bu bilgiyi çok ilginç buldum. - Johann Bauer
TCP'yi deneyen bir müşterinin beyaz listeye alınması fikri dikkate alındı, ama görünüşe göre patentli. - Alnitak


Akla gelen şey, DNSSEC'ye özgü değil, DNSSEC'nin dayandığı EDNS0 uzantısı ile ilgili değil.

EDNS0, daha büyük UDP yüklerine ve daha büyük UDP yüklerinin daha kötü trafik yansıması / büyütme saldırılarına izin vermesine izin verir.


Doğrulayıcı çözümleyicilerin yüzdesinin ne olduğunu bilmiyorum, ancak popüler ad sunucusu yazılımları varsayılan olarak doğrulamayla gönderiliyor gibi görünüyor ve Comcast ve Google ortak çözümleyicileri gibi doğrulama yapma konusunda açık olan bazı önemli servis sağlayıcıları kolayca bulabilir.

Buna dayanarak, doğrulayan çözümleyicilerin yüzdesinin muhtemelen imzalı bölgelerin yüzdesinden önemli ölçüde daha iyi durumda olduğunu düşünürdüm.


4
2017-07-23 23:36



Evet, sığır etinin de EDNS ile olabileceğini düşünüyordum. Bunun yerine DNSSEC ile kemiği seçmek çok garip. - Andrew B