Kurumsal DNS Filtreleme: Koruyucu DNS Mimarisi ve Atlatma Önleme

Kimlik avı bağlantısına tıklayan kullanıcı, komuta sunucusuna bağlanmaya çalışan bir zararlı yazılım, yeni kaydedilmiş bir alan adından dosya çeken bir betik. Üçü de aynı yerden başlar: bir DNS sorgusu. DNS filtreleme bu sorguyu yanıtlamadan önce değerlendirir ve zararlı alan adını çözmez. Ucuzdur, geniş kapsar, doğru kurulmazsa da kolayca atlatılır. Aşağıda mimari seçenekleri, RPZ yaklaşımını, atlatma yollarını kapatmayı ve DNS loglarının olay incelemede kullanımını uygulamalı olarak anlatıyoruz.

DNS filtreleme hangi tehditleri durdurur

DNS filtreleme bağlantı kurulmadan önce devreye girdiği için protokolden bağımsızdır: HTTP, HTTPS, SMTP veya özel bir komuta-kontrol protokolü fark etmez. Alan adı çözülmezse bağlantı da kurulmaz. Etkili olduğu alanlar:

• Bilinen kimlik avı ve zararlı yazılım dağıtım alan adları
• Komuta-kontrol (C2) altyapısı ve alan adı üretme algoritmalarıyla (DGA) üretilmiş adlar
• Yeni kaydedilmiş veya kısa süre önce ilk kez görülen alan adları (sağlayıcının bu kategoriyi desteklemesi gerekir)
• Kurum politikasına aykırı kategoriler: kumar, anonimleştirme servisleri, kişisel dosya paylaşımı vb.

Sınırları da nettir. Doğrudan IP adresiyle kurulan bağlantıları, ele geçirilmiş meşru bir sitedeki zararlı içeriği ve DNS’i hiç kullanmayan iletişimi durduramaz. DNS tünelleme gibi teknikler ancak sorgu desenleri izlenirse fark edilir. Bu yüzden DNS filtreleme web filtreleme, e-posta güvenliği ve EDR’ın yerine geçmez; onların önünde çalışan bir katmandır. Kimlik avına karşı katmanlı yaklaşım için kurumsal e-postada phishing riskini azaltma yazısı tamamlayıcıdır.

Mimari seçenekler: çözümleyici, forwarder, uç nokta ajanı

Çoğu kurumda istemciler Active Directory DNS sunucularını kullanır, bu sunucular da dış sorguları bir yere iletir. Filtreyi nereye koyduğunuz hem kapsamı hem de olay anında elinizde olacak görünürlüğü belirler.

Seçenek	Nasıl çalışır	Avantaj	Sınırlama
Filtreleyen forwarder (bulut veya NGFW)	AD DNS dış sorguları filtreleyen hizmete iletir	Kolay kurulum, istemci değişikliği yok	Filtre tarafında kaynak IP olarak yalnız AD DNS sunucuları görünür
Kendi çözümleyicinizde RPZ	BIND, Unbound veya ticari DNS’te politika bölgesi	Tam kontrol, yerel log	Tehdit beslemesi ve bakım sorumluluğu sizde
Uç nokta ajanı / istemci	Cihaz üzerinde DNS’i yakalar ve filtreler	Ofis dışındaki cihazlar da korunur, kullanıcı bazlı log	Ajan dağıtımı ve yönetilmeyen cihazlarda kapsam yok
NGFW üzerinde DNS denetimi	Firewall geçen DNS trafiğini inceler	Mevcut cihaz, merkezi politika	Şifreli DNS’i göremez; yalnız firewall’dan geçen trafik

Görünürlük sorunu sahada en sık atlanan noktadır. AD DNS sunucuları filtreleyen bir forwarder’a iletiyorsa, engellenen sorgunun hangi istemciden geldiğini filtre loglarında göremezsiniz; orada yalnız DNS sunucusunun IP’si vardır. Olay anında “hangi makine?” sorusunun cevabı yoksa log da işe yaramaz. Çözüm, AD DNS sunucularında analitik/debug loglamayı açmak veya istemci IP’sini taşıyan bir mimari seçmektir. Pratikte yaygın model: ofis içinde filtreleyen forwarder veya RPZ, ofis dışındaki dizüstüler için uç nokta ajanı. DNS altyapısının mühendislik tarafı, yani split-horizon ve çözümleyici tasarımı, network sitesindeki kurumsal DNS mimarisi rehberinde anlatılıyor.

Response Policy Zone (RPZ) yaklaşımı

RPZ, bir DNS çözümleyicinin yanıtlarını özel hazırlanmış bir bölge dosyasına göre değiştirmesini sağlar. BIND, Unbound, PowerDNS Recursor ve birçok ticari DNS ürünü RPZ’yi destekler. Windows Server DNS ise RPZ’yi doğrudan desteklemez; Windows ortamlarında RPZ genellikle AD DNS’in sorguları ilettiği bir ara çözümleyicide uygulanır. Windows Server 2016 ve sonrasındaki DNS politikaları (Add-DnsServerQueryResolutionPolicy) tek tek alan adlarını engellemek için kullanılabilir, ama RPZ biçimindeki tehdit beslemelerini tüketmez ve büyük listelerde yönetimi hızla zorlaşır. Tehdit istihbaratı sağlayıcıları RPZ beslemelerini bölge aktarımıyla dağıtabilir.

BIND üzerinde yerel bir RPZ örneği:

// named.conf
options {
    response-policy { zone "rpz.kurum.local"; };
};

zone "rpz.kurum.local" {
    type master;
    file "/etc/bind/db.rpz.kurum.local";
    allow-query { none; };
};

logging {
    channel rpz_log {
        file "/var/log/named/rpz.log" versions 5 size 50m;
        print-time yes;
    };
    category rpz { rpz_log; };
};

; /etc/bind/db.rpz.kurum.local
$TTL 300
@   IN SOA localhost. hostmaster.localhost. (2026111001 3600 600 86400 300)
    IN NS  localhost.

; NXDOMAIN dondur
zararli-ornek.example        CNAME .
*.zararli-ornek.example      CNAME .
; Engelleme sayfasina yonlendir
kumar-ornek.example          CNAME engel.kurum.local.
; Istisna: degerlendirmeden gecir
guvenli-ornek.example        CNAME rpz-passthru.

CNAME . NXDOMAIN, CNAME *. NODATA yanıtı üretir; rpz-passthru. ise alan adını sonraki politikalardan muaf tutar. Değişiklikten sonra named-checkzone rpz.kurum.local /etc/bind/db.rpz.kurum.local ile bölge dosyasını doğrulayın ve rndc reload rpz.kurum.local ile yükleyin. SOA seri numarasını artırmayı unutmak, ikincil sunucuların değişikliği hiç almamasıyla sonuçlanan klasik bir hatadır. Engelleme sayfasına yönlendirme kullanıcıya açıklama sunar; ancak HTTPS sitelerinde tarayıcı sertifika hatası gösterir. Bu yüzden çoğu kurum NXDOMAIN’i tercih eder, kullanıcı bilgilendirmesini log ve yardım masası süreciyle yapar.

DoH, DoT ve doğrudan DNS ile atlatmayı önleme

DNS filtreleme, istemcilerin kurumsal çözümleyiciyi kullandığı varsayımına dayanır. Bu varsayımı bozan üç yol var; her birinin ayrı önlemi gerekir:

1. Doğrudan DNS (UDP/TCP 53): İstemci veya zararlı yazılım doğrudan bir genel çözümleyiciye sorgu gönderir. Önlem: Firewall’da 53 numaralı porta çıkış yalnız kurumsal çözümleyicilere ve onların forwarder hedeflerine izinli; geri kalan herkes için engelli ve loglu.
2. DNS over TLS (TCP 853, RFC 7858): Ayrı port kullandığı için engellemesi kolaydır; 853 çıkışı kurumsal çözümleyiciler dışında kapatılır.
3. DNS over HTTPS (TCP 443, RFC 8484): Normal HTTPS trafiğinin içinde taşındığı için port bazlı engellenemez. Önlemler katmanlıdır: tarayıcı ve işletim sistemi politikalarıyla DoH’u kapatmak veya kurumsal çözümleyiciye yönlendirmek; NGFW veya web filtresinde bilinen DoH sağlayıcılarının kategorisini veya uygulama imzasını engellemek; Firefox için use-application-dns.net kanarya alan adına NXDOMAIN döndürmek.

Kanarya alan adı yalnız Firefox’un varsayılan olarak açtığı DoH’u kapatır; kullanıcı DoH’u elle etkinleştirmişse işe yaramaz. Yönetilen cihazlarda tarayıcı politikalarını (Chrome ve Edge için DnsOverHttpsMode, Firefox için kurumsal politika) merkezi olarak dağıtın. Örnek firewall çıkış mantığı:

Kural 10: Kaynak=DNS_SUNUCULARI  Hedef=FORWARDER_HEDEFLERI  Servis=DNS(53/udp,53/tcp)  Eylem=izin, log
Kural 11: Kaynak=any_ic          Hedef=any                  Servis=DNS(53), DoT(853/tcp) Eylem=engelle, log
Kural 12: Kaynak=any_ic          Hedef=DoH_SAGLAYICI_KATEGORI  Servis=HTTPS          Eylem=engelle, log

Bu kuralların politikadaki yeri ve bakımı periyodik gözden geçirmenin parçası olmalıdır; firewall kural temizliği rehberindeki sahiplik ve gözden geçirme yaklaşımı burada da geçerli.

Kategori ve istisna politikası tasarımı

Kullanıcının DNS filtrelemeyi kabul edip etmeyeceğini politika tasarımı belirler. Kötü tasarlanmış bir politika, ilk hafta yüzlerce istisna talebi ve “filtreyi kapatın” baskısı demektir. Önerdiğimiz yaklaşım:

• Güvenlik kategorileri herkese zorunlu: Zararlı yazılım, kimlik avı, C2 ve kripto madenciliği kategorileri istisnasız engellenir.
• Yeni kaydedilmiş alan adları: Önce izleme modunda başlatılır; iş akışlarını kırmadığı görüldükten sonra engellemeye alınır.
• Politika kategorileri gruba göre: Sosyal medya veya video gibi kategoriler İK ve yönetimle birlikte belirlenir; güvenlik ekibinin tek başına karar vereceği bir konu değildir.
• İstisna süreci: Yanlış sınıflandırılan bir alan adı için kullanıcının başvurabileceği, güvenlik ekibinin kısa sürede değerlendirdiği ve her istisnanın gerekçesiyle kaydedildiği bir süreç. İstisnalar alan adı bazında olur, kategori bazında olmaz.
• Sunucu ağları: Sunucuların internete yönelik DNS çözümlemesi yalnız ihtiyaç duydukları alan adlarıyla sınırlanabilir. Bu, varsayılan reddet yaklaşımının DNS’teki karşılığıdır.

DNS loglarının tespit ve olay incelemede kullanımı

DNS logları, olay incelemede “hangi cihaz, ne zaman, hangi alan adını sordu” sorusunu cevaplayan en ucuz veri kaynaklarından biridir. İşe yaraması için üç koşul var: Log istemci IP’sini (tercihen kullanıcı veya cihaz adını) içermeli, DHCP loglarıyla ilişkilendirilebilmeli ve olay incelemenin ihtiyaç duyacağı süre boyunca saklanmalı. Saklanmayan log yoktur.

SIEM’de DNS loglarıyla kurulabilecek tespitler:

• RPZ veya filtrenin engellediği sorgular: Aynı istemciden tekrarlayan engellemeler, cihazda çalışan bir zararlı yazılımın işareti olabilir.
• Yüksek entropili veya çok uzun alt alan adları içeren sorgu dizileri: DNS tünelleme ve DGA göstergesi.
• Bir istemcinin kısa sürede çok sayıda NXDOMAIN alması.
• Tehdit istihbaratında yeni yayımlanan bir alan adının geriye dönük aranması: Saklanan loglar sayesinde “bu alan adını daha önce kim sordu?” sorusu cevaplanabilir.

Firewall ve DNS loglarının birlikte değerlendirildiği tespit senaryoları firewall loglarından tehdit tespiti yazısında ayrıntılı anlatılıyor. DNS filtrelemenin segmentasyon ve çıkış politikasıyla birlikte tasarlanması ağ güvenliği ve segmentasyon, çıkış kurallarının uygulanması ise firewall kural yönetimi kapsamında ele alınabilir.

Sık sorulan sorular

DNS filtreleme web filtrelemenin yerini tutar mı?

Hayır. DNS filtreleme alan adı düzeyinde çalışır; URL yolunu, sayfa içeriğini ve doğrudan IP bağlantılarını göremez. Geniş kapsamlı ve düşük maliyetli bir ilk katmandır; web filtreleme ve EDR ile birlikte kullanılmalıdır.

Windows Server DNS üzerinde RPZ kullanılabilir mi?

Windows Server DNS RPZ’yi doğrudan desteklemez. Yaygın yaklaşım, AD DNS sunucularının dış sorguları RPZ destekleyen bir çözümleyiciye veya filtreleyen bir DNS hizmetine iletmesidir. Bu durumda istemci görünürlüğü için AD DNS tarafında loglama ayrıca planlanmalıdır.

DoH’u tamamen engellemek mümkün mü?

Port bazlı engellenemez, çünkü DoH normal HTTPS trafiği içinde taşınır. Tarayıcı ve işletim sistemi politikaları, bilinen DoH sağlayıcılarının firewall veya web filtresinde engellenmesi ve Firefox kanarya alan adı birlikte kullanıldığında atlatma riski ciddi ölçüde azalır.

Ofis dışındaki dizüstü bilgisayarlar nasıl korunur?

Ofis içi forwarder veya RPZ, cihaz kurum ağından çıktığında devre dışı kalır. Bu cihazlar için uç nokta ajanı tabanlı DNS koruması ya da tüm trafiği kurumsal kontrol noktasından geçiren bir uzak erişim mimarisi gerekir.