DNS Sahtekarlığı ve Önbellek Zehirlenmesini Önleme

Bir web sitesine yapılan her ziyaret, her e-posta teslimatı ve API çağrılarının çoğu bir DNS sorgusuyla başlar. Bir saldırgan bu sorgunun yanlış adres döndürmesini sağlayabilirse kullanıcı, adres çubuğunda hâlâ doğru alan adı görünürken yanlış sunucuyla konuşmaya başlar. DNS sahteciliğinin (spoofing) özü budur ve en zarar verici biçimi olan önbellek zehirlenmesi aynı anda binlerce kullanıcıyı etkileyebilir. Bu rehberde bu saldırıların kavramsal düzeyde nasıl işlediğini, 2008’deki bir keşfin çözümleyicilerin tasarımını neden değiştirdiğini ve alan adı sahipleriyle ağ işletmecilerinin bugün hangi savunmaları kurmuş olması gerektiğini anlatıyoruz. Odak tamamen savunmadır: zayıflığı kapatacak kadar iyi anlamak.

DNS sahteciliği ve önbellek zehirlenmesi aslında ne demek?

DNS sahteciliği, bir istemcinin meşru kaynaktan gelmeyen bir DNS yanıtı aldığı her durum için kullanılan geniş bir terimdir. Ele geçirilmiş bir Wi-Fi ağında, yerel hosts dosyasını değiştiren bir kötü amaçlı yazılımla ya da kötü niyetli bir yönlendiricinin dağıttığı sahte bir DNS sunucusu aracılığıyla gerçekleşebilir.

Önbellek zehirlenmesi bunun özel ve daha ciddi bir türüdür. İnternet sağlayıcılarının, şirketlerin ve genel DNS hizmetlerinin işlettiği özyinelemeli çözümleyiciler zaman kazanmak için yanıtları önbelleğe alır. Bir saldırgan çözümleyiciyi sahte bir kaydı kabul edip önbelleğe almaya ikna ederse, çözümleyici bu sahte kaydı yaşam süresi (TTL) dolana kadar o adı soran her istemciye sunar. Böylece tek bir başarılı enjeksiyon, kullanıcıların hiçbir cihazına dokunmadan büyük bir kitleyi yönlendirebilir.

Bunun temel nedeni tarihseldir. Klasik DNS çoğunlukla bağlantısız bir protokol olan UDP üzerinden çalışır ve özgün tasarım ağın makul ölçüde güvenilir olduğunu varsayıyordu. Bir çözümleyici, bekleyen sorusuyla eşleşen ilk makul yanıtı kabul ederdi. Bir yanıtın nereden geldiğini kanıtlamanın yerleşik bir yolu yoktu.

Bir çözümleyici bir yanıta güvenmeye nasıl karar verir?

Bir çözümleyici yetkili bir sunucuya sorgu gönderdiğinde, daha sonra bir yanıt alır ve bu yanıtın sorduğu soruya ait olup olmadığına karar vermek zorundadır. Geleneksel olarak birkaç alanı kontrol eder:

• Soru bölümü, sorulan ad ve türle eşleşmelidir.
• 16 bitlik bir sayı olan işlem kimliği (transaction ID), sorguda kullanılan kimlikle eşleşmelidir.
• Yanıt, sorgunun gönderildiği IP adresi ve porttan gelmeli ve çözümleyicinin kullandığı kaynak porta ulaşmalıdır.

Bunların hepsi eşleşirse yanıt kabul edilir. Gerçek trafiği göremeyen, yol dışındaki (off-path) bir saldırganın bu değerleri tahmin etmesi gerekir. 2008’den önce birçok çözümleyici sabit ya da tahmin edilebilir bir kaynak port kullanıyordu; geriye yalnızca 16 bitlik işlem kimliği, yani sadece 65.536 olasılık kalıyordu. Hızla çok sayıda paket gönderebilen kararlı bir saldırgan için bu küçük bir arama alanıdır.

2008 Kaminsky saldırısı ve önemi

İşlem kimliklerindeki zayıflıklar 2008’den çok önce biliniyordu, ancak savunmacılar önbelleğin kendisinden bir ölçüde güç alıyordu: bir çözümleyici geçerli bir yanıtı önbelleğe aldıktan sonra saldırganın yeniden denemek için TTL’nin dolmasını beklemesi gerekiyordu. 2008’de güvenlik araştırmacısı Dan Kaminsky bu rahatlığın yersiz olduğunu gösterdi.

Burada yalnızca genel hatlarıyla aktardığımız fikri şuydu: saldırganın ele geçirmek istediği tam ad için çözümleyiciyle yarışmasına gerek yoktu. Var olmayan birçok farklı alt alan adı için sorgu tetikleyerek her seferinde yeni bir yarış başlatabilir, sahte bir yanıt da tüm alan adını saldırganın kontrolündeki ad sunucularına yönlendiren ek kayıtlar taşıyabilirdi. Uzun TTL koruması ortadan kalkıyor ve tahmin edilebilir bir çözümleyici kısa sürede zehirlenebiliyordu.

Bu açıklama, Temmuz 2008’de alışılmadık derecede koordineli, çok üreticili bir yama yayımına yol açtı. Her yere dağıtılan düzeltme DNS’in yeniden tasarımı değil, tahmini çok daha zor hâle getiren bir yöntemdi: kaynak port rastgeleleştirme. Kaminsky ve diğerleri bunun bir hafifletme önlemi olduğunu ve uzun vadeli çözümün DNSSEC ile kriptografik doğrulama olduğunu açıkça belirtti.

Çözümleyici içindeki katmanlı önlemler

Modern çözümleyiciler, her biri sorguya öngörülemezlik katan birkaç tekniği birleştirir; böylece yol dışındaki bir saldırganın tahmin etmesi gereken çok daha fazla şey olur.

Kaynak port rastgeleleştirme

Çözümleyici her sorguyu aynı UDP portundan göndermek yerine her sorgu için geniş bir aralıktan rastgele bir kaynak port seçer. Rastgele 16 bitlik işlem kimliğiyle birleştiğinde bu, saldırganın tahmin etmesi gereken değer sayısını on binlerce kat artırır. Pratik bir saldırıyı çok daha pahalı bir saldırıya dönüştürdü; 2008’de standart yanıt hâline gelmesinin nedeni budur. Bazı NAT cihazlarının ve güvenlik duvarlarının kaynak portları tahmin edilebilir biçimde yeniden yazdığını ve bu korumayı sessizce boşa çıkarabildiğini unutmayın; ağ sınırındaki davranışı kontrol etmeye değer.

0x20 kodlaması (büyük-küçük harf rastgeleleştirme)

DNS adları büyük-küçük harfe duyarsızdır, ancak yetkili sunucuların çoğu soruyu yanıtlarına alındığı gibi kopyalar. Adını ASCII büyük ve küçük harfleri arasında farklılık gösteren bitten alan 0x20 kodlaması tekniği, sorgu adının büyük-küçük harf düzenini rastgeleleştirir, örneğin wWw.ExAmPlE.cOm. Çözümleyici ardından yanıtın aynı düzeni koruduğunu kontrol eder. Her harf yaklaşık bir bitlik entropi ekler. Kısa adlarda daha az etkilidir ve harf düzenini korumayan sunuculara tolerans göstermesi gerekir; bu yüzden çözümleyiciler genellikle yedek mekanizmalarla uygular.

Diğer çözümleyici kontrolleri

• Bailiwick kontrolü: yanıttaki, sunucunun yetkili olduğu bölgenin dışında kalan kayıtları atmak.
• Sıkılaştırılmış glue işleme: ek bölümdeki kayıtların güvenilir önbellek verisinin üzerine yazmasına izin vermemek.
• Hız sınırlama ve istenmeyen yanıt eşikleri: eşleşmeyen yanıt sellerini fark edip tepki vermek, örneğin TCP üzerinden yeniden denemek.
• QNAME minimizasyonu (RFC 7816, sonra RFC 9156): her sunucuya adın yalnızca gerekli kısmını göndermek; bu da veri sızıntısını azaltır.

Aşağıdaki tablo her kontrolün neyi koruduğunu ve sınırlarının nerede olduğunu özetliyor.

DNSSEC: Bir yanıtın gerçek olduğunu kanıtlamak

Yukarıdaki önlemlerin hepsi sahteciliği zorlaştırır, ama hiçbiri çözümleyicinin bir kaydın özgün olduğunu kanıtlamasını sağlamaz. DNSSEC bunu yapar. Bölge sahibi kayıtlarını özel anahtarlarla imzalar, karşılık gelen açık anahtarları DNSKEY kayıtları olarak yayımlar ve üst bölge, alt bölgenin anahtarına kefil olan bir DS kaydı yayımlar. Doğrulama yapan bir çözümleyici bu güven zincirini kökten aldığı kayda kadar izler. İmza doğrulanmazsa çözümleyici, sahte olabilecek bir yanıt yerine hata (SERVFAIL) döndürür.

Alan adı sahipleri için bu, kendi adlarınızın önbellek zehirlenmesine karşı kişisel olarak atabileceğiniz en etkili adımın bölgenizi imzalamak ve DS kaydının kayıt firmanız aracılığıyla kayıt otoritesinde yayımlandığından emin olmak olduğu anlamına gelir. Kurulumu ve tuzaklarını DNSSEC’in alan adı güvenliği için neden vazgeçilmez olduğu yazımızda ayrıntılı olarak ele alıyoruz. İki pratik uyarı: anahtar değişimleri (rollover) planlanmalıdır ve DNS sağlayıcınızı değiştirirseniz DS kaydını güncellemeli ya da kaldırmalısınız; aksi hâlde doğrulama yapan çözümleyiciler alan adınızı bozuk kabul eder.

Şifreli DNS: DoT ve DoH

DNSSEC veriyi doğrular ama gizlemez; bir dizüstü bilgisayar ya da telefon ile çözümleyicisi arasındaki kısım, özellikle halka açık Wi-Fi ağlarında, yolculuğun çoğu zaman en açık noktasıdır. İki standart bu kısmı şifreler:

• RFC 7858’de tanımlanan DNS over TLS (DoT), DNS’i özel bir port olan 853 üzerinde TLS ile sarar. Ağ işletmecilerinin tanıması ve yönetmesi kolaydır.
• RFC 8484’te tanımlanan DNS over HTTPS (DoH), DNS mesajlarını 443 numaralı port üzerinden HTTPS içinde taşır; böylece sıradan web trafiğine karışır ve tarayıcılar ile işletim sistemleri tarafından geniş çapta desteklenir.

İstemci çözümleyici sertifikasını doğruladığı sürece her ikisi de yol üzerindeki (on-path) bir saldırganın istemci ile çözümleyici arasındaki yanıtları okumasını ya da sessizce değiştirmesini engeller. Hiçbiri DNSSEC’in yerini tutmaz: çözümleyicinin kendisi zehirlenmişse şifreli kanal zehirli yanıtı sadakatle teslim eder. En güçlü duruş, doğrulama yapan bir çözümleyiciye şifreli taşımayla bağlanmaktır.

Kendi çözümleyicilerinizi sıkılaştırmak

Bir ofis, veri merkezi ya da müşteriler için özyinelemeli çözümleyici işletiyorsanız, birkaç yapılandırma tercihi önemli bir fark yaratır:

1. Açık çözümleyici çalıştırmayın. Özyinelemeyi kendi ağlarınızla sınırlayın. Açık çözümleyiciler yükseltme (amplification) saldırılarında kötüye kullanılır ve saldırganlara kolay bir hedef sunar.
2. Yetkili ve özyinelemeli rolleri ayırın. Bölgeleriniz için yanıt veren bir sunucu internet için özyineleme de yapmamalıdır.
3. DNSSEC doğrulamasını etkinleştirin ve kök güven çapasının otomatik olarak güncel tutulmasını sağlayın.
4. Yazılımı güncel tutun. Çözümleyici projeleri önbellekle ilgili zayıflıklar için düzenli olarak düzeltme yayımlar.
5. Önbellek TTL’lerini makul üst sınırlarla kısıtlayın ve istenmeyen yanıtlara karşı korumaları etkinleştirin.

Unbound çözümleyicisi için asgari bir örnek şöyle olabilir:

server:
    interface: 10.0.0.53
    access-control: 10.0.0.0/8 allow
    access-control: 0.0.0.0/0 refuse
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    harden-glue: yes
    harden-dnssec-stripped: yes
    harden-referral-path: yes
    use-caps-for-id: yes
    qname-minimisation: yes
    unwanted-reply-threshold: 10000000
    cache-max-ttl: 86400

BIND’daki karşılığı, özyinelemeyi bir erişim kontrol listesiyle kısıtlar ve doğrulamayı etkinleştirir:

acl internal { 10.0.0.0/8; 127.0.0.1; };
options {
    recursion yes;
    allow-recursion { internal; };
    allow-query-cache { internal; };
    dnssec-validation auto;
};

Katı sıkılaştırma seçenekleri yanlış yapılandırılmış üçüncü taraf bölgeleri açığa çıkarabileceğinden değişiklikleri her zaman bir test ortamında deneyin.

Alan adı sahipleri için izleme ve kontroller

Çoğu kuruluş herkese açık çözümleyici işletmez, ama yanıtları hedef alınabilecek alan adlarına sahiptir. Pratik bir rutin şunları içerir:

• Ad sunucularınızın ve kayıt firması bilgilerinizin beklenmedik biçimde değişmediğini kontrol etmek. TLDix WHOIS ve RDAP aracıyla yapacağınız hızlı bir sorgu, bir alan adının güncel ad sunucularını, durum kodlarını ve DNSSEC işaretini gösterir.
• İmzaları dig +dnssec example.com A ile doğrulamak ve doğrulama yapan bir çözümleyicinin ad bayrağını döndürdüğünü teyit etmek.
• Kayıt firması kilidini ve iki faktörlü kimlik doğrulamayı etkinleştirmek; çünkü bir kayıt firması hesabını ele geçirmek, zehirlemeyle aynı sonucu çok daha az çabayla sağlar.
• Alan adlarının, SSL sertifikalarının ve DNS barındırmanın süresinin dolmasına izin vermemek. Süresi dolmuş bir alan adı başkası tarafından yeniden kaydedilebilir; bu fiilen kalıcı bir sahteciliktir. Yenileme tarihlerini TLDix alan adı panelinizde takip etmek bu riski ortadan kaldırır.

Pratik kontrol: Ağınızın port rastgeleleştirmesini test etmek

Ofis ağınızdaki çözümleyicinin gerçekten rastgele kaynak portlar kullandığından emin olmak isterseniz basit bir yöntem, art arda gönderilen sorguların kaynak portlarını gözlemlemektir. Çözümleyici sunucusunda tcpdump ile dışarıya giden 53 numaralı port trafiğini birkaç dakika kaydedin ve kaynak port değerlerine bakın. Değerler geniş bir aralığa dağılmışsa sorun yoktur; sürekli artan ya da birkaç sabit değerde toplanan portlar görüyorsanız ya çözümleyici yapılandırması ya da aradaki NAT cihazı korumayı zayıflatıyordur. Bazı genel test hizmetleri de çözümleyicinizin port ve kimlik dağılımını raporlayabilir. Bu kontrolü ağ donanımı değiştiğinde ya da güvenlik duvarı kuralları güncellendiğinde tekrarlamak, fark edilmeden oluşan zayıflıkları erken yakalamanızı sağlar.

Toparlarsak

Önbellek zehirlenmesi, klasik DNS’in ilk makul yanıta güvenmesinden yararlanır. Rastgele portlar, işlem kimlikleri ve 0x20 kodlaması tahmini pahalı hâle getirir; çözümleyici sıkılaştırma kolay kestirmeleri ortadan kaldırır; şifreli taşıma istemci bağlantısını korur; DNSSEC ise sonunda çözümleyicilerin verinin gerçek olduğunu doğrulamasını sağlar. Hiçbir kontrol tek başına yeterli değildir, ama birlikte DNS’i çarpıcı biçimde daha güvenli kılarlar. Alan adı sahipleri için kısa liste nettir: bölgelerinizi imzalayın, kayıt firması hesabınızı koruyun, kayıtlarınızı izleyin ve kritik adların süresinin dolmasına asla izin vermeyin.