Bu, halka açık DNS çözümleyicilerini güvence altına almanın kanonik bir sorudur

Açık DNS sunucuları, bulundukları yere bakmaksızın şirketimizde tutarlı bir şekilde kullanabileceğimiz IP adresleri sağladıklarından oldukça temiz ve rahat görünmektedir. Google ve OpenDNS bu işlevi sağlar, ancak bu şirketlerin DNS sorgularımıza erişmesini istediğimden emin değilim.

Şirketimiz tarafından kullanılmak üzere böyle bir şey kurmak istiyorum, ancak bunun tehlikeli bir uygulama olduğu (özellikle de amplifikasyon saldırıları konusunda ) hakkında çok şey duyuyorum ve bunu doğru yaptığımızdan emin olmak istiyorum. Bu tür ortamları oluştururken akılda tutulması gereken şeyler nelerdir?

Bu işe girerken anlamanız gereken birkaç şey var:

Bu bir ağ mühendisliği problemidir.

Bu tür bir ortam kurmak isteyenlerin çoğu sistem yöneticileridir. Bu harika, ben de bir sistem yöneticisiyim! İşin bir kısmı, sorumluluklarınızın nerede bittiğini ve bir başkasının başladığını anlamak ve bana inanıyorum ki bu, sistem yöneticilerinin kendi başlarına çözebilecekleri bir sorun değil. İşte nedeni:

• UDP, vatansız bir protokoldür. Müşteri anlaşması yok.
• Bir DNS sunucusuna karşı sorgular kimliği doğrulanmamış iki adımlı bir işlemdir (sorgu, cevap). Sunucunun, kaynak IP'nin yanıtlamadan önce taklit edilip edilmediğini bilmesi mümkün değildir.
• Bir sorgu sunucuya ulaştığında, sahte bir UDP paketini önlemek için zaten çok geç. Biriktirme işlemi yalnızca , BCP 38 ve BCP 84 belgelerinde yer alan bir konu olan giriş filtreleme olarak bilinen bir uygulama ile önlenebilir . Bunlar, DNS sunucunuzun önünde oturan ağ aygıtları tarafından uygulanır.
• Veri merkezinizi baştan sona nasıl kuracağınız ya da bu en iyi uygulamaları nasıl uygulayacağınız konusunda size bir yol veremeyiz. Bu şeyler kendi ihtiyaçlarınıza göre çok özeldir. Sorular ve Cevaplar formatı bunun için işe yaramaz ve bu site, profesyonel insanları işe almak için işe koymanın yerine geçmez.
• Milyar doların başarısız olamayacak kadar büyük şirketinizin giriş filtrelemesini doğru şekilde uyguladığını varsaymayın.

Bu en iyi uygulama değil. En iyi uygulama, bunu yapmamaktır.

DNS çözümleyicisine bakan bir internet kurmak çok kolaydır. Birini kurmak, bununla ilgili riskleri anlamaktan daha az araştırma gerektirir. Bu, iyi niyetlerin yanlışlıkla başkalarının aldatmalarına (ve acılarına) izin verdiği durumlardan biridir.

• DNS sunucunuz gördüğü herhangi bir kaynak IP adresine cevap verirse, açık bir çözümleyici kullanıyorsunuzdur. Bunlar, masum partilere karşı yapılan amplifikasyon saldırılarında sürekli olarak kullanılıyor . Yeni sistem yöneticileri her gün açık çözücülere ayak uydurarak kötü niyetli kişilerin sürekli olarak onları taramasını sağlar. Açık çözücünüzün bir saldırıda kullanılıp kullanılmayacağı gerçekten bir soru değil: 2015 itibariyle, hemen hemen verilen bir şey. Hemen olmayabilir, ama kesin olacağı kesin.
• DNS yazılımınızı (örn. BIND) kullanarak bir ACL uygulasanız bile, tüm bunlar sunucunuzun yanıtlayacağı sahte DNS paketlerini sınırlar. DNS altyapınızın yalnızca ACL'deki cihazlara saldırmak için değil, DNS sunucunuz ve yanıtlayacağı cihazlar arasındaki herhangi bir ağ cihazı için de kullanılabileceğini anlamak önemlidir. Eğer veri merkezinin sahibi değilseniz, bu sadece sizden daha fazlası için bir problemdir.

Google ve OpenDNS bunu yapıyor, peki neden yapamıyorum?

Bazen gerçeğe karşı coşku tartmak gerekir. İşte kendine sorman gereken zor sorular:

• Bu bir heves kurmak istediğiniz bir şey mi, yoksa doğru yapmak için yatırım yapmak için birkaç milyon dolarınız var mı?

• Özel bir güvenlik ekibiniz var mı? Özel suistimal ekibi? Her ikisinde de, yeni altyapınızın kötüye kullanımı ve dış taraflardan alacağınız şikayetler ile ilgili döngüleri var mı?

• Eğer bir var mı yasal takımı?

• Tüm bunlar söylendiğinde ve yapıldığında, bu çabanın tamamı kendisi için uzaktan ödeme yapmaya, şirket için bir kâr elde etmeye veya sizi bu yöne götüren rahatsızlıklarla başa çıkmanın parasal değerini aşmaya başlayacak mı?

Kapanışta, bu konunun Q&A olduğunu biliyorum, buna bağlı olan çoğunuz için bir hayal kırıklığı. Serverfault cevaplar vermek için burada ve "bu kötü bir fikir, yapmayın" cevabı genellikle çok yararlı olarak algılanmıyor. Bazı problemler başlangıçta göründüğünden çok daha karmaşık ve bu da onlardan biri.

Eğer varsa istediğiniz bu işi yapmak için denemek için çözümün bu tür uygulamaya çalışırken, yine yardım için bize sorabilirsiniz. Gerçekleşmesi gereken ana şey, sorunun uygun soru-cevap formatında sunulması için sorunun kendi başına çok büyük olmasıdır . Konuyu araştırmak için önemli miktarda zaman harcamış olmanız ve uygulamanız sırasında karşılaştığınız belirli mantık problemleriyle bize yaklaşmanız gerekiyor. Bu soru-cevap bölümünün amacı size daha büyük resmi daha iyi anlamanız ve neden bu kadar geniş bir soruyu neden cevaplayamadığımızı anlamanıza yardımcı olmaktır .

İnterneti güvende tutmamıza yardımcı olun! :)

Açık DNS alıcısı veya yetkili bir DNS sunucusu çalıştırıyor olsanız da, sorun aynıdır ve olası çözümlerin çoğu da aynıdır.

En iyi çözüm

DNS çerezleri , DNS sunucularına, istemcinin IP adresinin taklit edilmediğini kanıtlamak için istemcilerin bir çerez göndermelerini zorunlu kılma yollarını öneren bir standarttır. Bu, ilk arama için ek bir gidiş dönüş ücretine mal olacak ve bu, herhangi bir çözümün sunabileceği en düşük ek yük.

Eski müşteriler için geri dönüş

DNS çerezleri henüz standartlaştırılmadığından, elbette eski müşterileri şimdi ve gelecek yıllar boyunca desteklemek gerekli olacaktır.

DNS çerez desteği olmadan istemcilerden gelen limit taleplerini değerlendirebilirsiniz. Ancak hız limitleri bir saldırganın DNS sunucunuzu DoS yapmasını kolaylaştırır. Bazı DNS sunucularının yalnızca yetkili DNS sunucuları için tasarlanmış bir hız sınırı özelliği bulunduğuna dikkat edin. Özyinelemeli bir çözümleyici hakkında soru sorduğun için, bu oran sınırlayıcı uygulamalar senin için geçerli olmayabilir. Tasarıma göre hız sınırı, sunucunuz için bir tıkanıklık haline gelecektir ve bu nedenle, bir saldırganın, hız sınırlaması olmasaydı yasal isteklerin düşmesine neden olmak için size daha az trafik göndermesi gerekir.

Hız sınırlamalarının bir avantajı, bir saldırganın DNS sunucunuzu DNS istekleriyle doldurması durumunda, sunucuya ssh göndermenize ve durumu araştırmanıza olanak verecek kapasiteniz kalma olasılığının daha yüksek olmasıdır. Ek olarak, ücret talepleri öncelikle, çok sayıda istek gönderen istemci IP'lerinden gelen istekleri düşürmek üzere tasarlanabilir; bu da sizi DoS'a karşı sahte istemci IP'lerine erişimi olmayan saldırganlardan korumak için yeterli olabilir.

Bu nedenlerden ötürü, gerçek kapasitenizin altındaki bir oran limiti, amplifikasyona karşı gerçekten koruma sağlamamasına rağmen, iyi bir fikir olabilir.

TCP kullanarak

Bir istemciyi, cevabın UDP için çok büyük olduğunu belirten bir hata kodu göndererek TCP kullanmaya zorlamak mümkündür. Bunun birkaç dezavantajı var. İki ek gidiş dönüş ücreti. Bazı hatalı müşteriler de bunu desteklemiyor.

İki ilave gidiş dönüşün maliyeti, bu yaklaşımı kullanan yalnızca ilk istekle sınırlandırılabilir:

İstemci IP'si onaylanmadığında, DNS sunucusu istemciyi TCP'ye geçmesi için kesilmiş bir yanıt gönderebilir. Kesik yanıt, istek kadar kısa olabilir (ya da müşteri EDNS0 kullanıyorsa ve yanıt almazsa kısadır), bu da amplifikasyonu ortadan kaldırır.

Bir TCP anlaşmasını tamamlayan ve bağlantıda bir DNS isteği gönderen herhangi bir istemci IP geçici olarak beyaz listeye alınabilir. Bir kez IP, UDP sorguları göndermek ve 512 bayta (EDNS0 kullanıyorsanız 4096 bayt) kadar UDP yanıtlarını almak için beyaz listeye alındığında. Bir UDP yanıtı bir ICMP hata mesajını tetiklerse, IP beyaz listeden tekrar kaldırılır.

Bu yöntem aynı zamanda bir kara liste kullanılarak da tersine çevrilebilir; bu, yalnızca istemci IP'lerinin varsayılan olarak UDP üzerinden sorgulamaya izin verdiği, ancak herhangi bir ICMP hata iletisinin, IP'nin kara listeden çıkmasını gerektiren bir TCP sorgusuna ihtiyaç duyan kara listeye alınmasına neden olduğu anlamına gelir.

İlgili tüm IPv4 adreslerini kapsayan bir bitmap, 444 MB bellekte saklanabilir. IPv6 adreslerinin başka bir şekilde depolanması gerekir.

Herhangi bir DNS sunucusunun bu yaklaşımı uygulayıp uygulamadığını bilmiyorum.

Amplifikasyon ataklarında bazı TCP yığınlarının kullanılabileceği de bildirildi. Ancak bu, yalnızca DNS için değil, herhangi bir TCP tabanlı hizmet için de geçerlidir. Bu güvenlik açıkları, TCP yığınının bir SYN paketine yanıt olarak birden fazla paket göndermeyecek şekilde düzeltildiği bir çekirdek sürümüne yükseltme yapılarak azaltılmalıdır.