DNS Tünelleme Saldırıları Nasıl Tespit Edilir?

Yayın: 26 Ekim 2026 · Son güncelleme: 26 Ekim 2026

DNS tünelleme, saldırganın DNS sorgu ve yanıtlarını veri taşıyan gizli bir kanal olarak kullanıp güvenlik duvarı ve proxy kontrollerini atlatmasıdır. Çalınan veri alt alan adlarına kodlanarak dışarı gönderilir, komutlar ise DNS yanıtlarının içinde geri gelir. 26 Ekim 2026 itibarıyla MITRE ATT&CK bu tekniği T1071.004 koduyla izliyor; en güvenilir tespit yolu sorgu uzunluğu, entropi, hacim ve kayıt türünün birlikte izlenmesidir.

İlgili Rehberler

SIEM Nedir?
Log toplama, korelasyon ve alarm yönetiminin temelleri.

Log Kayıtları ile SIEM
Hangi logların toplanacağı ve SIEM’e nasıl aktarılacağı.

SIEM Güvenlik Testi
Tespit kurallarının saldırı simülasyonuyla doğrulanması.

DNS Tünelleme Nedir ve Neden Tehlikelidir?

DNS tünelleme, DNS protokolünün alan adı çözümleme dışında bir amaçla, yani veri sızdırmak, komuta-kontrol (C2) iletişimi kurmak ya da ağ kısıtlamalarını aşmak için kullanılmasıdır. Neredeyse her ağda DNS trafiğine izin verildiği ve bu trafik HTTP kadar ayrıntılı incelenmediği için saldırganlar DNS’i sessiz bir çıkış kapısı olarak görür.

Sorgular dışarıya zararlı yazılımın yüklü olduğu bilgisayardan değil, kurumun kendi DNS çözücüsünden çıkar. Güvenlik duvarı logunda görünen şey, meşru bir sunucunun her gün yaptığı DNS trafiğidir. DNS’i tamamen kapatmak da ağı durduracağı için savunma, engellemeden çok bu trafiğin içindeki tuhaflıkları yakalamaya dayanır. Üstelik aynı kanal hem veri çıkarmak hem de komut almak için kullanılabilir.

DNS aynı zamanda başka saldırıların da yardımcı kanalıdır. Log4j teknik analizi yazımızda anlatıldığı gibi, Log4Shell taramalarında açığın varlığı çoğu zaman DNS geri aramalarıyla doğrulandı.

DNS Tünelleme Teknik Olarak Nasıl Çalışır?

Saldırgan, kontrol ettiği bir alan adı için kendi yetkili DNS sunucusunu (authoritative nameserver) kurar. Kurban ağdaki zararlı yazılım veriyi bu alan adının alt alan adlarına kodlayarak sorgu gönderir. Kurumun çözücüsü sorguyu normal trafik gibi saldırganın sunucusuna iletir, yanıt da komutları geri taşır.

1. Altyapı: Saldırgan t.ornek-saldirgan.com gibi bir alan adı kaydeder ve kendi sunucusunu bu alan adının yetkili sunucusu yapar.
2. Kodlama: Sızdırılacak veri Base32, Base64 veya hex ile kodlanır ve parçalara bölünür. Bir etiket en fazla 63, tam alan adı en fazla 253 karakter olabilir (RFC 1035).
3. Sorgu: Zararlı yazılım her parça için parca.t.ornek-saldirgan.com biçiminde bir sorgu gönderir.
4. Çözümleme: Kurumun çözücüsü yanıtı önbellekte bulamaz ve sorguyu yetkili sunucuya kadar iletir.
5. Veri alımı: Saldırganın sunucusu alt alan adını çözer ve parçaları birleştirir.
6. Geri kanal: Komutlar A, AAAA, TXT, CNAME veya NULL kayıtlarına kodlanarak yanıtla geri gönderilir.

Saldırganlar Hangi Araçları Kullanır?

DNS tünelleme araçlarının çoğu açık kaynaklıdır ve sızma testlerinde meşru olarak da kullanılır. Araçlar taşıdıkları trafik, kodlama yöntemi ve kullandıkları kayıt türüyle birbirinden ayrılır. Hangi aracın hangi izi bıraktığını bilmek, tespit kurallarını yazarken neyin aranacağını belirler. Aşağıdaki tablo bilinen dört aracı bu açıdan karşılaştırıyor.

Bu araçları kontrollü bir ortamda çalıştırmak, tespit kurallarının gerçekten alarm üretip üretmediğini görmenin en doğrudan yoludur. SIEM güvenlik testi yazımız bu tür simülasyonların nasıl planlandığını anlatır.

DNS Tünelleme Hangi Senaryolarda Kullanılır?

DNS tünelleme üç ana amaçla karşımıza çıkar: veri sızdırma, komuta-kontrol ve ağ kısıtlamalarını aşma. Her senaryo farklı bir trafik deseni üretir. Veri sızdırma kısa sürede yüksek hacim yaratırken C2 kanalı günlerce düşük ve düzenli bir iz bırakır; bu yüzden tek bir eşik ikisini birden yakalayamaz.

Veri sızdırmada dosyalar küçük parçalara bölünür ve binlerce sorguyla dışarı çıkarılır; loglarda kısa sürede tek bir alan adı altında yüzlerce benzersiz alt alan adı belirir. Komuta-kontrol kanalında ise zararlı yazılım birkaç dakikada bir sorgu atıp komut bekler, hacim düşüktür ama zamanlama şaşmaz. Misafir Wi-Fi veya captive portal arkasında Iodine ile internete çıkmaya çalışan biri ise en fazla trafiği üretir ve genellikle en kolay fark edilen senaryo budur.

Gerçek saldırılarda kayıt türü her zaman TXT değildir. Unit 42’nin 2019’da yayımladığı analize göre İran bağlantılı OilRig (APT34) grubunun Helminth, ISMAgent, ALMA Communicator, BONDUPDATER ve QUADAGENT araçları ağırlıklı olarak A ve AAAA kayıtlarını kullandı; veri hex veya Base64 ile alt alan adlarına kodlandı, komutlar IPv4 ve IPv6 adreslerinin içinde geri geldi. Yalnızca TXT sorgularını izleyen bir kural bu araçları kaçırır.

DNS Tünelleme Nasıl Tespit Edilir?

DNS tünelleme tespiti, sorguların istatistiksel özelliklerinin kurumun normal DNS profilinden ne kadar saptığına bakılarak yapılır. Uzunluk, entropi, hacim, benzersiz alt alan adı sayısı ve kayıt türü birlikte değerlendirildiğinde yanlış alarm azalır. Eşikler başka bir kurumdan kopyalanmamalı, en az birkaç haftalık kendi trafiğinizle belirlenmelidir.

1. Etiket ve sorgu uzunluğu: Salat, Davis ve Khan’ın 2023 çalışmasında Iodine’in veri sızdıran sorgusu 122 karakterdi; aynı ortamda ortalama alt alan adı uzunluğu 46 karakterdi.
2. Shannon entropisi: Kodlanmış veri rastgele görünür ve entropisi yüksektir. Aynı çalışma 4’ün üzerindeki değerleri şüpheli kabul etti.
3. Benzersiz alt alan adı sayısı: Tek bir alan adı altında kısa sürede yüzlerce farklı alt alan adı sorgulanması.
4. Kayıt türü dağılımı: NULL ve TXT oranındaki ani artış; ama A ve AAAA tabanlı araçlar da hesaba katılmalı.
5. Düzenlilik: Sabit aralıklarla gelen sorgular (beaconing), insan kaynaklı trafikte nadiren görülür.
6. Yanıt boyutu ve süresi: Büyük TXT yanıtları ve yetkili sunucuya kadar giden, önbellekten dönmeyen sorgular.

Entropi eşiği nereye uygulanmalı? Kendi ölçümümüz

Entropi eşiğini tam alan adına uygulamak yanıltıcı olabilir. Aşağıdaki değerleri Shannon entropisi formülüyle kendimiz hesapladık. Tamamen meşru iki adres, sık önerilen 3,5 eşiğini zaten aşıyor; asıl ayrım, kodlanmış etiketlerde 4’ün üzerine çıkıldığında belirginleşiyor.

Bu yüzden entropi, kayıtlı alan adı (ör. ornek-saldirgan.com) çıkarıldıktan sonra kalan alt alan adı etiketine uygulanmalı ve uzunluk koşuluyla birlikte kullanılmalıdır.

Tespit için en yaygın kaynaklar şunlardır: Zeek dns.log ile pasif DNS kaydı, çözücü sorgu logları ve bilinen kötü alan adlarını engelleyen Response Policy Zones (RPZ). Makine öğrenmesi modelleri imzası olmayan yeni araçları yakalamada işe yarar, ancak yine iyi etiketlenmiş bir normal trafik verisine ihtiyaç duyar.

SIEM ile DNS Tünelleme Korelasyonu Nasıl Yapılır?

SIEM, DNS loglarını güvenlik duvarı, EDR ve proxy loglarıyla ilişkilendirerek tek bir şüpheli sorgu yerine bir olay zinciri arar. Böylece analist her uzun alan adı için değil, aynı uç noktada şüpheli bir süreçle birlikte görülen DNS anomalisi için uyarılır. Kural mantığının temelleri SIEM nedir rehberimizde yer alıyor.

Tablodaki sayılar başlangıç noktasıdır. CDN, antivirüs ve telemetri servisleri de uzun ve rastgele görünen alt alan adları üretir; bu servisler beyaz listeye alınmadan kurallar devreye alınırsa analist ekibi kısa sürede alarm yorgunluğu yaşar.

# Zeek dns.log üzerinde uzun sorguları listeleme (zeek-cut ile)
cat dns.log | zeek-cut ts id.orig_h query qtype_name \
  | awk 'length($3) > 50' | sort -k3 | head -50

Log tarafında BIND için querylog, Unbound için log-queries: yes ve Windows DNS Server için analitik olay günlüğü açılmalıdır. Logların SIEM’e gerçek zamanlıya yakın aktarılmasını, geriye dönük inceleme yapabilmek için de en az 90 gün saklanmasını öneriyoruz; düşük hacimli bir C2 kanalı haftalarca fark edilmeden çalışabilir. Toplama mimarisinin ayrıntıları log kayıtları ile SIEM yazımızda anlatılıyor.

DNS Tünellemeye Karşı 7 Adımlı Savunma Planı

DNS tünellemeye karşı tek bir ürün yeterli olmaz; çıkış kontrolü, loglama, filtreleme ve test birlikte çalışmalıdır. Aşağıdaki yedi adım, en az maliyetliden en kapsamlıya doğru sıralanmıştır. İlk iki adım atılmadan sonraki adımların etkisi sınırlı kalır, çünkü görülmeyen trafik analiz de edilemez.

1. Merkezi çözücüyü zorunlu kılın: İstemcilerin yalnızca kurum çözücüsünü kullanmasını sağlayın; dışarıya doğrudan 53 (DNS) ve 853 (DoT) çıkışını güvenlik duvarında kapatın.
2. Sorgu loglamayı açın: Çözücü loglarını SIEM’e aktarın ve en az 90 gün saklayın.
3. Koruyucu DNS ve RPZ kullanın: Bilinen kötü ve yeni kaydedilmiş alan adlarını çözücü seviyesinde engelleyin.
4. Anomali kurallarını kalibre edin: Birkaç haftalık normal trafikle eşikleri belirleyin, CDN ve telemetri alan adlarını istisnaya alın.
5. Bulut ortamını ayrıca ele alın: Bulut sunucuları sağlayıcının kendi çözücüsünü kullanır. 2023 çalışmasında Google Cloud’da tüm giden trafik kapatıldığı halde Iodine tüneli metadata sunucusu üzerinden çalıştı; bu yüzden bulut DNS sorgu logları (ör. Route 53 Resolver veya Cloud DNS logları) da SIEM’e alınmalı.
6. DoH ve DoT politikası belirleyin: Harici DoH sağlayıcılarına erişimi engelleyin; şifreli DNS gerekiyorsa kurum çözücüsü üzerinden sunun.
7. Düzenli test edin: Iodine ve dnscat2’yi yetkili bir sızma testi kapsamında çalıştırıp kuralların alarm üretip üretmediğini doğrulayın.

DNS-over-HTTPS Tünellemeyi Nasıl Etkiler?

DNS-over-HTTPS (DoH, RFC 8484), DNS sorgularını HTTPS içinde şifreleyerek gizlilik sağlar. İstemci kurum çözücüsünü atlayıp doğrudan harici bir DoH sağlayıcısına bağlanırsa sorgular kurum loglarında hiç görünmez. Bu durumda yukarıdaki tüm tespit kuralları veri alamaz ve tünel 443 numaralı portta normal web trafiğinin arasına karışır.

• Tarayıcı ve işletim sistemi politikalarıyla harici DoH’yi kapatın; Firefox için use-application-dns.net kanarya alan adı ve kurumsal ilkeler kullanılabilir.
• Bilinen DoH sağlayıcılarının adreslerini proxy veya güvenlik duvarında engelleyin.
• Şifreli DNS isteniyorsa kurum çözücüsünü DoH veya DoT destekli yapılandırın; böylece hem gizlilik korunur hem de loglar kurumda kalır.

Sıkça Sorulan Sorular

Bu bölümde DNS tünelleme hakkında güvenlik ekiplerinden en çok gelen dört soru yer alıyor: tamamen engellenip engellenemeyeceği, hangi SIEM kurallarının işe yaradığı, VPN’den farkı ve DNSSEC’in rolü. Yanıtlar yukarıdaki tespit ve savunma bölümlerine dayanır; kural örnekleri ve eşik değerleri için SIEM bölümüne dönebilirsiniz.

Yazar: Afra Görgen

Kaynaklar

• Salat, L., Davis, M., Khan, N. — DNS Tunnelling, Exfiltration and Detection over Cloud Environments, Sensors 23(5), 2760 (2023)
• Unit 42 — DNS Tunneling in the Wild: Overview of OilRig’s DNS Tunneling (2019)
• MITRE ATT&CK — T1071.004 Application Layer Protocol: DNS
• IETF RFC 1035 — Domain Names: Implementation and Specification (1987)
• IETF RFC 8484 — DNS Queries over HTTPS (DoH) (2018)
• Zeek Documentation — dns.log
• ISC — BIND 9 Administrator Reference Manual
• Iodine — proje deposu (GitHub)
• dnscat2 — proje deposu (GitHub)

Erişim tarihi (tüm kaynaklar): 26 Ekim 2026. Güncelleme tarihçesi: 26 Ekim 2026 — ilk yayın.