Güvenlik Avantajları

Giriş: DNS güvenlik tehditleri ve hafifletme işlemleri

Alan Adı Sistemi'nin açık ve dağıtılmış tasarımı ve Kullanıcı Datagram Protokolü (UDP) kullanımı nedeniyle DNS, çeşitli saldırı biçimlerine karşı savunmasızdır. Genel veya "açık" yinelenen DNS çözümleyicileri, gelen paketleri izin verilen bir kaynak IP adresi grubuyla kısıtlamadıkları için özellikle risk altındadır. En çok endişe ettiğimiz iki saldırı türü vardır:

  • DNS önbellek zehirlenmesine yol açan adres sahteciliği saldırıları. Kullanıcıları uygun sitelerden kötü amaçlı web sitelerine yönlendirmeyi amaçlayan çeşitli DNS adres sahteciliği ve sahtekarlık türleri kullanılır. Saldırganlar, DNS bölgesinin tamamının yetkili kontrolüne sahip olduğu Kaminsky saldırıları olarak adlandırılır.
  • Hizmet reddi (DoS) saldırıları. Saldırganlar, çözücülere yönelik saldırı saldırıları gerçekleştirebilir veya diğer sistemlere DoS saldırıları başlatmak için çözücüleri ele geçirebilir. Büyük DNS kaydı/yanıt boyutundan yararlanarak diğer sistemlere DoS saldırıları başlatmak için DNS sunucularını kullanan saldırılar, yükseltme saldırıları olarak bilinir.

Aşağıda, her saldırı sınıfı daha ayrıntılı olarak ele alınmaktadır.

Zehirlenme saldırılarının önbelleği

DNS adres sahteciliği saldırılarının, önbellek zehirlenmesine yol açabilecek birkaç varyantı vardır, ancak genel senaryo şu şekildedir:

  1. Saldırgan, sunucunun yetkili olmadığını bildiği ve büyük olasılıkla sunucunun önbelleğinde yer almadığı bir alan adı için hedef DNS çözümleyiciye birden fazla sorgu gönderir.
  2. Çözücü, istekleri diğer alan adı sunucularına gönderir (saldırının IP adresleri de tahmin edebilir).
  3. Bu esnada, saldırıya uğrayan kuruluş kurbanı, yetki verilmiş alan adı sunucusundan geliyormuş gibi gösteren sahte yanıtlarla doldurur. Yanıtlar, istenen alanı saldırgan tarafından kontrol edilen IP adreslerine çözümleyen kayıtları içerir. Sonlandırılan adla ilgili yanıt kayıtları içerebilir veya daha da kötüsü, saldırganın sahip olduğu bir alan adı sunucusuna daha fazla yetki verebilirler. Böylece tüm bölgenin kontrolü sizde olur.
  4. Sahte yanıtlardan biri çözümleyicinin isteğiyle eşleşirse (örneğin, sorgu adı, türü, kimliği ve çözümleyici kaynak bağlantı noktasıyla) ve gerçek alan adı sunucusundan bir yanıt alınmadan öncelenirse, çözümleyici sahte yanıtı kabul edip önbelleğe alır ve orijinal yanıtı siler.
  5. Güvenliği ihlal edilen alan veya alt bölge için gelecekte yapılacak sorgular, önbellekten yapılan sahte DNS çözümlemeleriyle yanıtlanır. Saldırgan, sahte yanıt üzerinde çok uzun bir bekleme süresi belirlediyse sahte kayıtlar yenilemeden önce önbellekte mümkün olduğunca uzun süre tutulur.

Kaminsky saldırılarına mükemmel bir giriş için Kiminsky DNS Güvenlik Açığı Çizimi Kılavuzu'nu inceleyin.

DoS ve etkiyi artırma saldırıları

DNS çözümleyiciler, ağ bağlantılı herhangi bir sisteme zarar veren olağan DoS tehditlerine tabidir. Bununla birlikte, DNS çözümlemeleri, çözücülerden yararlanan saldırganlar için cazip hedefler olduğundan korsan saldırıların konusu özellikle önemsenmektedir. Ek olarak, daha fazla ücretsiz bant genişliği kazanmak için saldırganların isteklerine yanıt verme oranı büyük oranda artırılır. EDNS0'ı (DNS için Uzantı Mekanizması) destekleyen çözümleyiciler, özellikle döndürebilecekleri çok daha büyük paket boyutları nedeniyle savunmasızdır.

Yükseltici senaryoda, saldırı aşağıdaki şekilde devam eder:

  1. Saldırgan, sahte kaynak IP adresi kullanarak kurbanın DNS sunucusu sorgularını gönderir. Sorgular, sahte bir IP adresi kullanılarak tek bir sistemden veya bir sistem ağından gönderilebilir. Sorgular, saldırganın çok daha fazla sayıda sonuç döndüreceğini bildiği kayıtlara odaklanır. Bu sayı, orijinal sorguların boyutundan birkaç kat daha fazladır1.
  2. Kurban sunucusu büyük isteklerde sahte isteklerde iletilen kaynak IP adresine yanıt vererek sistemi bunaltıyor ve DoS durumuna neden oluyor.

Hafifletmeler

DNS güvenlik açıklarına yönelik standart sistem genel çözümü DNSSEC'dir. Ancak, evrensel olarak uygulanıncaya kadar, açık DNS çözümleyicilerinin bilinen tehditlere karşı korunmak için bazı önlemleri bağımsız olarak alması gerekir. Çoğu teknik önerilmiştir; çoğunun genel bir bakışı için IETF RFC 5452: DNS'yi sahte yanıtlara karşı daha dayanıklı hale getirecek önlemler konusuna bakın. Google Açık DNS'te aşağıdaki yaklaşımları uygular ve öneririz:

  • Kodunuzu, özellikle DNS mesajlarını ayrıştırma ve serileştirmeden sorumlu kod olan arabellek taşmalarına karşı güvenli hale getirme.
  • Çözümleyicilerin kendilerine yapılan doğrudan DoS saldırılarına karşı koruma sağlamak için makine kaynaklarının aşırı temel hazırlığının yapılması. IP adreslerinin saldırganlar tarafından taklit edilmesi kolay olmadığından, IP adresine veya alt ağına dayalı olarak sorguları engellemek imkansızdır. Bu tür saldırıları ele almanın tek etkili yolu yükü emmektir.
  • Basit önbellek zehirlenmesine karşı koruma sağlamak için yanıt paketlerinin ve alan adı sunucusu güvenilirliğinin temel geçerlilik kontrolünü uygulama. Bunlar, standartlara uygun önbelleğe alma çözümleyicisinin gerçekleştirmesi gereken standart mekanizmalar ve sağlık kontrolleridir.
  • Kaminsky saldırıları gibi daha karmaşık adres sahteciliği/önbellek zehirleme saldırılarının gerçekleşme olasılığını azaltmak için mesajları istemek için entropi ekleme. Entropi eklemek için önerilen birçok teknik vardır. Aşağıda, bu tekniklerin her biriyle ilgili avantajlara, sınırlamalara ve zorluklara genel bir bakış ve bunları Google Açık DNS'te nasıl uyguladığımız hakkında konuşacağız.
  • "Doğum günü saldırısı" olasılığını azaltmak için yinelenen sorguları kaldırma.
  • DoS ve etkiyi artırma saldırılarını önlemek için sınırlama istekleri.
  • En yüksek bant genişliğini kullanan ve en yüksek istek-cevap boyutu oranına sahip istemci IP'leri için hizmeti izleme.

DNSSEC

Alan Adı Güvenlik Uzantıları (DNSSEC) standardı, birkaç IETF RFC'sinde belirtilir: 4033, 4034, 4035 ve 5155.

Alan adı sunucularından alınan yanıtların gerçekliğini doğrulayarak DNSSEC karşı önbellek zehirleme saldırıları uygulayan çözümler. Her DNS alt bölgesinde bir dizi özel/ortak anahtar çifti bulunur ve her DNS kaydı için özel anahtar kullanılarak benzersiz bir dijital imza oluşturulur ve şifrelenir. Daha sonra ilgili ortak anahtar, üst bölgelere ait anahtarlarla bir güven zinciri aracılığıyla kimliği doğrulanır. DNSSEC uyumlu çözümleyiciler, doğru imzaları içermeyen yanıtları reddeder. DNSSEC, özel anahtarlara erişim olmadan imzaların taklit edilmesi neredeyse imkansız olduğundan yanıtların izinsiz şekilde değiştirilmesini etkili bir şekilde önler.

Ocak 2013 itibarıyla, Google Açık DNS, DNSSEC'yi tam olarak desteklemektedir. DNSSEC biçimindeki iletileri kabul edip yönlendirir ve doğru kimlik doğrulama için yanıtları doğrularız. Diğer sorun gidericilerin de aynısını yapmasını öneririz.

NSEC yanıtlarını, IETF RFC 8198: DNSSEC Tarafından Doğrulanan Önbelleğin Agresif Kullanımı'nda belirtildiği gibi önbelleğe alırız. Bu, DNSX'i uygulayan ve negatif yanıtlar için NSEC kullanan alan adı sunucularına NXDOMAIN sorgularını azaltabilir.

İstemci tarafında şifrelenmiş aktarımlar

Google Açık DNS, şifrelenmiş aktarım protokolleri, HTTPS üzerinden DNS ve TLS üzerinden DNS için destek sunar. Bu protokoller, istemci ile Google Açık DNS arasında gizlilik ve güvenliği önemli ölçüde geliştirerek izinsiz olarak değiştirilmesini, dinleme veya adres sahteciliğini önler. Bunlar, uçtan uca kimliği doğrulanmış DNS aramaları sağlamak için DNSSEC'yi tamamlar.

Temel geçerlilik kontrolünü uygulama

Bazı DNS önbelleği bozulması, istekler ile yanıtlar arasındaki kasıtlı olmayan ve kötü amaçlı olmayan uyuşmazlıklardan (ör.yanlış yapılandırılmış bir alan adı sunucusu, DNS yazılımındaki bir hata vb.) kaynaklanabilir. DNS çözümleyiciler, en azından alan adı sunucularının güvenilirliğini ve alaka düzeyini doğrulamak için kontroller gerçekleştirmelidir. Aşağıdaki savunmaların tümünü yapmanızı (ve uygulamayı) öneririz:

  • Giden isteklerde yinelenen biti ayarlamayın ve her zaman yetkilendirme zincirlerini açıkça uygulayın. Yinelenmiş bitin devre dışı bırakılması, çözümleyicinizin "yineleme" modunda çalışmasını sağlar. Böylece başka bir alan adı sunucusunun sizin adınıza bu sorguları gerçekleştirmesine izin vermek yerine, yetkilendirme zincirindeki her bir alan adı sunucusunu açık bir şekilde sorgulamanız gerekir.
  • Şüpheli yanıt mesajlarını reddedin. "Şüpheli" olarak kabul ettiğimiz unsurlarla ilgili ayrıntılar için aşağıya bakın.
  • Önceki taleplerden önbelleğe alınan birleştirici kayıtları temel alarak müşterilere A kayıtları döndürmeyin. Örneğin, ns1.example.com için bir istemci sorgusu alırsanız .com TLD alan adı sunucusundan döndürülen önbelleğe alınmış birleştirici kayıtlara dayalı bir A kaydı göndermek yerine adresi yeniden çözümlemeniz gerekir.

Gerekli ölçütleri karşılamayan yanıtları reddetme

Google Açık DNS, aşağıdakilerin tümünü reddeder:

  • Ayrıştırılamayan veya yanlış biçimlendirilmiş yanıtlar.
  • Anahtar alanlarının istekteki karşılık gelen alanlarla eşleşmediği yanıtlar. Buna sorgu kimliği, kaynak IP, kaynak bağlantı noktası, hedef IP veya sorgu adı dahildir. DNS adres sahteciliği davranışının tam açıklaması için RFC 5452, Bölüm 3'e bakın.
  • İstekle ilgili olmayan kayıtlar.
  • CNAME zincirini yeniden oluşturamadığımız yanıt kayıtları.
  • İlgili alan adı sunucusunun güvenilir olmadığı kayıtlarda (yanıt, yetki veya ek bölümlerdeki) kayıtlar. Bir ad sunucusunun "güvenilirliğini" belirli bir alan için yetki zincirindeki yerine göre belirleriz. Google Açık DNS'si, yetki zinciri bilgilerini önbelleğe alır. Belirli bir isteğe yanıt vermenin güvenilirliğini belirlemek için, gelen her yanıtı önbelleğe alınan bilgilerle karşılaştırarak doğrularız.

İsteklere entropi ekleme

Çözümleyici bir temel güvenlik kontrolü uyguladıktan sonra, meşru ad sunucusu tarafından sorgu kimliği, UDP bağlantı noktası (isteğin), IP adresi (yanıtın) ve orijinal isteğin sorgu adını eşleştirmek için bir saldırganın yanıtlarla kurbanın katılımını sağlaması gerekir.

Benzersiz bir şekilde tanımlayıcı alan olan sorgu kimliği yalnızca 16 bit uzunluğunda olduğundan (yani, doğru olmasını sağlamak için 1/65.536 şans) bunu sağlamak maalesef zordur. Diğer alanlar da aralıkla sınırlıdır. Bu nedenle, benzersiz kombinasyonların toplam sayısı nispeten düşük bir sayıdır. İlgili kombinatörlerin hesaplanması için RFC 5452, Bölüm 7'ye bakın.

Bu nedenle, saldırganların istek aralığı içinde geçerli bir alan kombinasyonu ile eşleşmelerini zorlaştırmak için DNS mesajın standart biçimine izin vererek mümkün olduğunca fazla entropi eklemenin zorluğu da buna dahildir. Aşağıdaki bölümlerde açıklanan tüm teknikleri uygulamanızı öneririz.

Temmuz 2022'de DNS OARC 38 konferansında, burada bahsedilen tekniklerin güncellenmiş bir incelemesini sunmuştuk. Sunu, alan adı sunucusu operatörleri için de öneriler içerir.

Kaynak bağlantı noktalarını rastgele hale getirme

Temel adım olarak, giden istek paketlerinin hiçbir zaman varsayılan UDP bağlantı noktasını 53'ü veya birden fazla bağlantı noktası atamak için öngörülebilir bir algoritma kullanmasına (ör. basit artış) izin vermeyin. Sisteminizde 1024 ile 65535 arasında mümkün olduğunca geniş bağlantı noktası aralığı kullanın ve bağlantı noktalarını atamak için güvenilir bir rastgele sayı oluşturucu kullanın. Örneğin Google Açık DNS'si yaklaşık 32.000 farklı bağlantı noktası numarası sağlamak için yaklaşık 15 bit kullanır.

Sunucularınız güvenlik duvarı, yük dengeleyici veya ağ adresi çevirisi (NAT) yapan diğer cihazların arkasında dağıtılmışsa bu cihazların, giden paketlerdeki bağlantı noktalarının rastgele tercihini kaldırabileceğini unutmayın. NAT cihazlarını, bağlantı de rastgele oluşturma özelliğini devre dışı bırakacak şekilde yapılandırdığınızdan emin olun.

Alan adı sunucularının seçiminde rastgele seçim

Bazı çözücüler, kök, TLD veya diğer alan adı sunucularına istek gönderirken en kısa mesafeye (gecikme) göre alan adı sunucusu IP adresini seçer. Giden isteklere entropi eklemek için hedef IP adreslerini rastgele hale getirmenizi öneririz. Google Açık DNS'de her alt bölge için yapılandırılmış alan adı sunucuları arasından rastgele bir alan adı sunucusu seçer, böylece hızlı ve güvenilir alan adı sunucularını tercih ederiz.

Gecikmeyle ilgili endişeleriniz varsa belirli bir gecikme eşiğinin (ör. 30 ms, 300 ms vb.) altındaki bir adres aralığında rastgele hale getirme işlemini içeren gidiş dönüş süresi (RTT) bant genişliğini kullanabilirsiniz.

DNS çerezleri

RFC 7873, DNS mesajlarına 64 bit çerezleri eklemek için bir EDNS0 seçeneği tanımlar. Bir DNS çerezi destek istemcisi, rastgele bir 64 bit çerez ve isteğe bağlı olarak (isteniyorsa) bir sunucu çerezi içerir. Destekleyici bir sunucu, çerez seçeneğinin bir istekte geçerli olduğunu bulursa yanıtta istemci çerezini ve doğru sunucu çerezini yansıtır. Daha sonra, destekleyen istemci, yanıttaki istemci çerezini doğrulayarak yanıtın beklenen sunucudan geldiğini doğrulayabilir.

Bir ad sunucusu DNS çerezlerini desteklemiyorsa entropi eklemek için aşağıdaki iki seçenek kullanılabilir.

Sorgu adlarında rastgele büyük/küçük harf kullanımı

DNS standartları, alan adı sunucularının büyük/küçük harfe duyarlı olmayan adlarla ilgilenmesini gerektirir. Örneğin, example.com ve EXAMPLE.COM adları aynı IP adresine2 çözümlenmelidir. Ayrıca, alan adı sunucularının küçük bir kısmı hariç tümü, istekte görünen yanıtta adı orijinal vakayı koruyarak yeniden hatırlatır.

Bu nedenle, isteklere entropi eklemenin bir başka yolu, sorgulanan alan adlarındaki harflerin büyük/küçük harf kullanımını rastgele değiştirmektir. "0x20" olarak da bilinen bu teknik, US-ASCII harflerinin durumunu ayarlamak için 0x20 bitin kullanıldığından ilk olarak IETF internet taslağında önerilmiştir. İşlem Kimliği'ni iyileştirmek için DNS Etiketlerinde Bit 0x20'nin Kullanımı. Bu teknikte, alan adı sunucusu yanıtı sadece sorgu adıyla değil, ad dizesindeki her kelimenin büyük/küçük harf kullanımıyla eşleşmelidir; örneğin, wWw.eXaMpLe.CoM veya WwW.ExamPLe.COm. Bu, üst düzey ve kök alan adlarındaki sorgulara yönelik entropiyi neredeyse hiç eklemeyebilir ancak çoğu ana makine adı için etkilidir.

Bu tekniği uygularken karşılaştığımız önemli bir zorluk, bazı alan adı sunucularının beklenen yanıt davranışına uymamasıdır:

  • Bazı alan adı sunucuları, büyük/küçük harfe duyarlı değildir: İstekte bulunmalarından bağımsız olarak aynı sonuçları doğru şekilde döndürürler ancak yanıt, istekteki adla bire bir eşleşmez.
  • Diğer alan adı sunucuları, büyük/küçük harfe duyarlıdır (DNS standartlarını ihlal ederek): İstekteki büyük/küçük harfe bağlı olarak, eşdeğer adları farklı şekilde işler veya hiç yanıt vermezler ya da istekteki adla bire bir eşleşen yanlış NXDOMAIN yanıtları döndürürler.
  • arpa bölgesindeki PTR sorguları hariç bazı alan adı sunucuları doğru şekilde çalışır.

Bu tür alan adı sunucularının her ikisi için de sorgu adının büyük/küçük harf kullanımını değiştirmek istenmeyen sonuçlar doğurur: İlk grup için yanıt sahte bir yanıttan ayırt edilemez, ikinci grup içinse yanıt (varsa) tamamen yanlış olabilir.

Bu sorun için halihazırda bir çözüm, büyük/küçük harf kullanımını yalnızca standartların doğru şekilde uygulandığını bildiğimiz alan adı sunucuları için kullanmaktır. Ayrıca, günlüklerimizin analizini temel alarak her biri için uygun istisna alt alanlarını da listeleriz. Bu sunuculardan geliyormuş gibi görünen bir yanıt doğru durumu içermiyorsa yanıtı reddederiz. Giden trafiğimizin% 70'inden fazlası, etkinleştirilmiş alan adı sunucuları tarafından işlenir.

Sorgu adlarına ilişkin tek seferlik etiketler bekleniyor

Çözümleyici bir adı doğrudan önbellekten çözümleyemezse veya yetkili bir alan adı sunucusunu doğrudan sorgulayamazsa bir kök veya TLD alan adı sunucusundan gelen yönlendirmeleri izlemelidir. Çoğu durumda, kök veya TLD alan adı sunucularına yapılan istekler, adı IP adresine çözümleme girişimi yerine başka bir alan adı sunucusuna yönlendirmeyle sonuçlanır. Bu nedenle, bu tür istekler için isteğin entropisini artırmak üzere bir sorgu adına rastgele etiket eklemek güvenli olmalıdır. Ancak bu şekilde var olmayan bir adın çözümlenmesi başarısız olamaz. Yani bir ad alan sunucusuna, ön eki entriih-f10r3.www.google.com gibi bir ad olan bir ad için gönderilen istek, www.google.com isteğiyle aynı sonucu döndürmelidir.

Pratikte bu tür istekler giden isteklerin% 3'ünden azını oluştursa da normal trafiğin (çoğu sorgu doğrudan önbellekten veya tek bir sorgu tarafından yanıtlanabileceği için) bir saldırganın çözümlemeye zorlayacağı istek türleridir. Dolayısıyla bu teknik, Kaminsky tarzı kötüye kullanımların önlenmesinde son derece etkili olabilir.

Bu tekniğin uygulanması, yalnızca yönlendirmeyle sonuçlanacağı garanti edilen istekler (yani yanıt bölümünde kayıt içermeyen yanıtlar) için tek seferlik etiketlerin kullanılmasını gerektirir. Bununla birlikte, bu tür istekleri tanımlamaya çalışırken çeşitli sorunlarla karşılaştık:

  • Bazı ülke kodu TLD (ccTLD) alan adı sunucuları, diğer ikinci düzey TLD'ler (2LD) için aslında yetkilidir. İki etiketi olsa da 2LD'ler TLD'ler gibi davranır ve bu nedenle genellikle ccTLD alan adı sunucuları tarafından işlenir. Örneğin, .uk alan adı sunucuları, mod.uk ve nic.uk alt bölgeleri ve bu nedenle, bu alt bölgelerde bulunan www.nic.uk, www.mod.uk gibi ana makine adları için de yetkilidir. Diğer bir deyişle, bu tür ana makine adlarının çözümlenmesi için ccTLD alan adı sunucularına yapılan istekler yönlendirmelere değil, yetkili yanıtlara yol açar. Bu tür ana makine adlarına tek seferlik olmayan etiketler eklemek, adların çözümlenememesine neden olur.
  • Bazen genel TLD (gTLD) alan adı sunucuları, alan adı sunucuları için yetkili olmayan yanıtlar döndürür. Yani alan adı alt bölgesi yerine bir gTLD bölgesinde yaşayan bazı alan adı sunucusu ana makine adları vardır. Bir gTLD, ana makine adında, bir yönlendirme göndermek yerine kendi veritabanı kaydında bulunan birleştirici kaydı kullanarak bu ana makine adları için güvenilir olmayan bir yanıt döndürür. Örneğin, ns3.indexonlineserver.com alan adı sunucusu eskiden indexonlineserver.com alt bölgesi yerine .COM gTLD alt bölgesindedir. n3.indexonlineserver.com için bir gTLD sunucusuna istek gönderdiğinde, bunun yerine bir yönlendirme yerine IP adresi aldık. Ancak başına bir etiket eklenmediği için indexonlineserver.com adresine yönlendirme aldık. Bu da ana makine adını çözümleyemedi. Bu nedenle, gTLD sunucusundan çözüm gerektiren alan adı sunucuları için tek seferlik etiketler ekleyemiyoruz.
  • Alt bölgeler ve ana makine adları için yetkiler zamanla değişir. Bu durum, yetkilendirme zincirinin değişmesi durumunda, önceden çözülemeyen, ana makine adı olmayan bir ana makine adının çözümlemesinin ortadan kalkmasına neden olabilir.

Bu zorlukların üstesinden gelmek için ana makine adlarına ilişkin, nonce etiketleri ekleyemediğimiz istisnaları yapılandırdık. Bunlar, sunucu günlüklerimize göre TLD alan sunucularının yönlendirme olmayan yanıtları döndürdüğü ana makine adlarıdır. Zaman içinde geçerli olmaya devam ettiğinden emin olmak için istisna listesini sürekli gözden geçiririz.

Yinelenen sorguları kaldırma

DNS çözümleyiciler, "doğum günü saldırıları"na karşı savunmasızdır. Bu durum, matematiksel "doğum günü paradoksu"nu kötüye kullanmalarına neden olur. Bu durumda, eşleşme olasılığı yüksek sayıda giriş gerektirmez. Doğum günü saldırıları, mağdur sunucuya yalnızca sahte yanıtlarla değil, aynı zamanda ilk sorgularla sular da vurur ve tek bir ad çözümlemesi için birden çok istekte bulunacak şekilde çözücüye güvenir. Gönderilen giden isteklerin sayısı arttıkça, saldırganın bu isteklerden birini sahte bir yanıtla eşleştirme olasılığı da o kadar yüksek olur: Bir saldırganın, %50'lik bir yakalama yanıtıyla başarılı olmak için yalnızca 300 devam eden istek sırasına, %700'e yakını ise %100'e yakın bir başarı sayısına ulaşması gerekir.

Bu saldırı stratejisine karşı kendinizi korumak için giden sıradan tüm yinelenen sorguları silmeniz gerekir. Örneğin Google Açık DNS, aynı sorgu adı, sorgu türü ve hedef IP adresi için hiçbir zaman tek bir bekleyen isteğe izin vermez.

Hız sınırlaması sorguları

Hizmet reddi saldırılarının önlenmesi, açık yinelenmiş DNS çözümleyicileri için çeşitli zorluklara yol açar:

  • Açık yinelemeli çözücüler, ses yükseltme saldırılarının cazip hedefidir. Bunlar yüksek kapasiteli, yüksek güvenilirliğe sahip sunuculardır ve özellikle bir saldırgan, önbelleklerine büyük bir yanıt ekleyebiliyorlarsa tipik bir yetkili alan adı sunucusundan daha büyük yanıtlar üretebilirler. Açık DNS hizmetinin tüm geliştiricilerinin, sunucularının diğer sistemlere karşı saldırı başlatmak için kullanılmasını önlemekle yükümlüdür.
  • Ses yükseltme saldırılarının algılanması zor olabilir. Saldırganlar, binlerce açık çözümleyici aracılığıyla bir saldırı başlatabilir, böylece her çözme aracı genel sorgu hacminin yalnızca küçük bir bölümünü görür ve güvenliğinin ihlal edildiğine dair net bir işaret çıkarmaz.
  • Kötü amaçlı trafik, DNS hizmeti kesintiye uğramadan veya normal kullanıcılara uygulanmadan engellenmelidir. DNS temel bir ağ hizmetidir. Bu nedenle, bir saldırıyı ortadan kaldırmak için sunucuların kapatılmasını seçmek veya herhangi bir istemci IP'sine hizmeti uzun süre boyunca reddetmek bir seçenek değildir. Çözümleyiciler, bir saldırıyı başlar başlamaz engelleyebilir ve saldırının gerçekleştiği anda tam operasyonel hizmeti geri yükleyebilmelidir.

DoS saldırılarıyla mücadele için en iyi yaklaşım hız sınırı veya "sınırlama" mekanizması uygulamaktır. Google Açık DNS, iki tür ücret kontrolü uygular:

  • Diğer alan adı sunucularına yapılan istekleri kontrol edin. Google Açık DNS, diğer DNS alan adı sunucularını, çözümleyici sunucularımızdan başlatılan DoS saldırılarına karşı korumak amacıyla, her bir alan adı sunucusu IP adresi için her bir sunum kümesinden giden isteklerde QPS sınırları uygular.

  • İstemcilere giden yanıtlar için hız kontrolü. Google Public DNS, diğer sistemlerin sesini yükseltmeye ve çözümleyici sunucularımızdan başlatılmış olan geleneksel dağıtılmış DoS (botnet) saldırılarına karşı korumak için istemci sorgularında iki tür hız sınırlaması gerçekleştirir:

    • Geleneksel hacim tabanlı saldırılara karşı koruma sağlamak amacıyla her sunucu, istemci başına IP QPS ve ortalama bant genişliği sınırları uygular.
    • Küçük sorgulara verilen büyük yanıtların kötüye kullanıldığı ambarlama saldırılarına karşı koruma sağlamak amacıyla her sunucu, istemci-IP başına maksimum ortalama ses yükseltme faktörünü uygular. Ortalama genişletme faktörü, sunucu günlüklerimizde gözlemlenen geçmiş trafik kalıplarına göre hesaplanan, yanıt-sorgu boyutunun yapılandırılabilir bir oranıdır.

    Tek kaynak IP adresinden gelen DNS sorguları maksimum QPS oranını aşarsa fazlalık sorguları atlanır. Bir kaynak IP adresinden gelen UDP üzerinden DNS sorguları, sürekli olarak ortalama bant genişliği veya yükseltme sınırını aşarsa (arada büyük bir yanıtın iletilmesi gerekir) sorgular bırakılabilir veya yalnızca küçük bir yanıt gönderilebilir. Küçük yanıtlar, hata yanıtı veya kesme biti ayarlanmış boş bir yanıt olabilir (böylece, çoğu meşru sorgu TCP üzerinden yeniden denenir ve başarılı olur). Tüm sistemler veya programlar TCP aracılığıyla yeniden denemez ve TCP üzerinden DNS, istemci tarafındaki güvenlik duvarları tarafından engellenebilir. Bu nedenle, yanıtlar kısaltıldığında bazı uygulamalar düzgün çalışmayabilir. Yine de kesme işlemi, RFC uyumlu istemcilerin çoğu durumda düzgün çalışmasını sağlar.

  1. Örnekler ve sorunla ilgili genel anlamda iyi bir tartışma için DNS Yükseltici Saldırıları başlıklı makaleye bakın.↩

  2. RFC 1034, Bölüm 3.5'te: ↩

    Alan adlarında büyük ve küçük harf kullanımına izin verilir, ancak büyük/küçük harf kullanımına herhangi bir önem verilmez. Yani, yazımı farklı ancak büyük/küçük harf kullanımı farklı olan iki ad, aynıymış gibi kabul edilecektir.