DNS Spoofing ve Cache Poisoning Nedir?

Tarayıcınıza bankam.com yazdığınızda arka planda görünmez ama kritik bir işlem gerçekleşir: bilgisayarınız bu alan adını bir IP adresine çevirmesi için DNS'e sorar ve dönen cevaba hiç sorgusuz sualsiz güvenir. İşte tam bu güven, saldırganların en çok istismar ettiği zaafın kaynağıdır. Eğer bir saldırgan bu sorgunun cevabını taklit edebilir ve size gerçek sunucudan önce sahte bir yanıt ulaştırabilirse, siz doğru adresi yazmış olmanıza rağmen tamamen başka bir sunucuya, çoğu zaman gerçeğinin birebir kopyası görünümündeki bir tuzak siteye yönlenirsiniz.

Bu saldırı ailesinin genel adı DNS spoofing (DNS sahteciliği), en yaygın uygulama biçimlerinden biri ise DNS cache poisoning (önbellek zehirlenmesi) olarak bilinir. Adres çubuğunda hâlâ doğru alan adı yazıyor olması ve hatta bazen kilit simgesinin görünmesi, kurbanın hiçbir şeyin ters gittiğini fark etmemesine yol açar; bu da saldırıyı özellikle tehlikeli kılar. Bu rehberde DNS spoofing'in tam olarak ne olduğunu, cache poisoning'in teknik olarak nasıl işlediğini, man-in-the-middle saldırılarıyla ilişkisini, gerçek bir saldırının adım adım anatomisini ve DNSSEC, DoH/DoT ile güvenilir çözümleyici kullanarak bu tehditlerden nasıl korunacağınızı bir sistem yöneticisinin gözünden ele alacağız.

DNS Spoofing Tam Olarak Nedir?#

DNS spoofing, bir DNS sorgusuna sahte bir cevap sokularak kullanıcının kastettiği sunucu yerine saldırganın kontrolündeki bir sunucuya yönlendirilmesidir. Klasik DNS'in temel tasarım açığı burada devreye girer: DNS, internetin ilk günlerinde hız ve basitlik düşünülerek tasarlandı ve gelen cevabın gerçekten yetkili sunucudan mı geldiğini doğrulayacak hiçbir kimlik doğrulama mekanizması içermiyordu. Sorgular çoğunlukla UDP üzerinden gönderilir; bir çözümleyici (resolver), doğru soruya makul görünen bir cevap aldığında onu koşulsuz kabul eder. DNS'in genel çalışma mantığını hatırlamak isterseniz DNS nedir yazısı iyi bir başlangıç noktasıdır.

Spoofing'in tehlikesi, saldırının kullanıcı tarafında neredeyse hiç iz bırakmamasıdır. Adres çubuğunda doğru alan adı görünür, sayfa gerçeğine benzer, hatta saldırgan geçerli bir sertifika almışsa HTTPS kilidi bile yeşil olabilir. Kurban, kimlik bilgilerini, banka şifresini veya ödeme kartı numarasını gönül rahatlığıyla girer. Bu yüzden DNS spoofing, kimlik avı (phishing) ile birleştiğinde son derece etkili bir dolandırıcılık aracına dönüşür. Saldırgan, kullanıcıyı kandırmak için sahte bir e-posta bağlantısına bile ihtiyaç duymaz; kullanıcının kendi eliyle yazdığı doğru adresi ele geçirir.

Cache Poisoning Nasıl Çalışır?#

Cache poisoning, DNS spoofing'i tek bir kullanıcıyla sınırlı kalmaktan çıkarıp binlerce kişiyi etkileyebilen bir saldırıya dönüştüren mekanizmadır. Hedef, bireysel kullanıcı değil, bir özyinelemeli çözümleyicinin (recursive resolver) önbelleğidir. Bir resolver, çözdüğü her kaydı TTL süresi boyunca önbelleğinde tutar ki aynı soru tekrar geldiğinde yeniden sormak zorunda kalmasın. Saldırgan bu önbelleğe sahte bir kayıt yerleştirmeyi başarırsa, o resolver'ı kullanan herkes TTL süresince sahte adrese yönlendirilir.

Peki saldırgan sahte cevabı gerçeğinden nasıl önce ulaştırır? DNS cevaplarının doğruluğu tarihsel olarak yalnızca iki bilgiye dayanıyordu: 16 bitlik sorgu kimliği (Query ID) ve cevabın doğru kaynak porttan gelmesi. Saldırgan, resolver'ı hedef alan adı için bir sorgu yapmaya tetikler ve ardından yetkili sunucudan gelecek gerçek cevaptan önce, tahmin ettiği Query ID'yi taşıyan sahte cevapları hızla enjekte etmeye çalışır. Bu bir yarış koşuludur: sahte cevap gerçeğinden önce ve doğru Query ID ile ulaşırsa, resolver onu kabul eder ve önbelleğine yazar.

2008'de güvenlik araştırmacısı Dan Kaminsky, bu yarışın sanıldığından çok daha kolay kazanılabileceğini gösterdi. Saldırgan var olmayan alt alan adlarını (rastgele1.bankam.com, rastgele2.bankam.com...) sorgulatarak resolver'ı sürekli yeni sorgular yapmaya zorlar; her sorgu, Query ID'yi tahmin etmek için yeni bir şans demektir. Doğru tahmin tutunca, saldırgan cevabın "authority" bölümüne hedef alan adının tamamı için sahte bir nameserver yazabilir. Bu keşiften sonra tüm resolver yazılımları, tahmin edilebilirliği düşürmek için kaynak port rastgeleleştirmesi (source port randomization) eklendi ve entropi 16 bitten yaklaşık 32 bite çıktı. Bu, saldırıyı zorlaştırdı ama matematiksel olarak imkânsız kılmadı — asıl kalıcı çözüm kriptografik doğrulamadır.

Aşağıdaki basitleştirilmiş şema, meşru ve zehirlenmiş bir çözümlemenin farkını özetler:

; Meşru çözümleme
kullanici → resolver → yetkili sunucu → bankam.com A 203.0.113.10  (gerçek)

; Zehirlenmiş çözümleme
kullanici → resolver → [saldirgan sahte cevabi enjekte eder]
                       bankam.com A 198.51.100.66  (saldirganin sunucusu)

Saldırı Türleri ve MITM ile İlişkisi#

DNS spoofing tek bir teknikten ibaret değildir; saldırganın ağdaki konumuna ve eriştiği noktaya göre farklı biçimler alır. Bunları ayırt etmek, hangi savunmanın hangi tehdide karşı işe yaradığını anlamak için önemlidir.

Man-in-the-middle (MITM) saldırıları, DNS spoofing ile en yakından ilişkili senaryodur. Halka açık bir Wi-Fi ağında, kafede veya ele geçirilmiş bir yönlendiricide, kullanıcı ile resolver arasındaki trafiği izleyebilen bir saldırgan, gerçek cevabın Query ID ve portunu doğrudan görebilir. Bu durumda tahmine bile gerek kalmaz; saldırgan gerçek cevabı birebir taklit eden sahte bir yanıtı anında üretebilir. Bu yüzden güvenilmeyen ağlarda DNS trafiğinin şifrelenmesi (DoH/DoT) hayati önem taşır.

Rogue DNS server senaryosunda ise saldırgan, kurbanı en baştan kendi kötü niyetli resolver'ına yönlendirir. Bu genellikle ev/ofis yönlendiricilerinin varsayılan parolalarının değiştirilmemesinden veya bir zararlı yazılımın cihazın DNS ayarlarını değiştirmesinden kaynaklanır. Cihaz artık her sorgusunu saldırganın sunucusuna sorduğu için, saldırganın hiçbir kaydı zehirlemesine bile gerek kalmaz; istediği alan adı için istediği cevabı döndürebilir. Yerel hosts dosyası zehirlenmesi ise en sade biçimdir: cihaza bulaşan zararlı yazılım, işletim sisteminin DNS'ten önce baktığı hosts dosyasına doğrudan sahte bir kayıt ekler.

Bir Saldırının Adım Adım Anatomisi#

Soyut kalmaması için tipik bir off-path cache poisoning saldırısını sıralı adımlarla inceleyelim. Amaç, bankam.com için bir resolver'ın önbelleğine saldırganın IP'sini yazdırmaktır.

1. Tetikleme. Saldırgan, hedef resolver'ı bankam.com (veya var olmayan bir alt alan adını) çözmeye zorlar — örneğin resolver'a erişimi olan bir cihazdan sorgu yaptırarak.
2. Yarış. Resolver yetkili sunucuya sorusunu sorar sormaz, saldırgan tahmin ettiği Query ID ve porttan sahte cevapları sel gibi göndermeye başlar.
3. Tutturma. Sahte cevaplardan biri doğru Query ID/port ve gerçek cevaptan önce ulaşırsa, resolver onu geçerli kabul eder.
4. Yazma. Resolver, sahte kaydı TTL süresi boyunca önbelleğine yazar. Kaminsky varyantında saldırgan tüm alan adı için sahte bir NS kaydı yazdırarak etkiyi kalıcılaştırabilir.
5. Hasat. Artık o resolver'ı kullanan tüm kurbanlar TTL boyunca saldırganın sunucusuna yönlenir; kimlik bilgileri toplanır.

Bir yönetici olarak bu zincirin en can alıcı noktasını görmek gerekir: saldırının başarısı, cevabın doğrulanmıyor olmasına dayanır. Zincirin hiçbir adımında resolver "bu cevap gerçekten yetkili sunucudan mı geldi?" sorusunu soramaz. İşte bu boşluğu kapatan tek kalıcı yanıt, cevapları kriptografik olarak imzalamaktır — yani DNSSEC.

DNSSEC ile Kalıcı Koruma#

DNS spoofing ve cache poisoning'in kök nedeni doğrulama eksikliği olduğuna göre, kalıcı çözüm de doğrulama getirmektir. DNSSEC (DNS Security Extensions) tam olarak bunu yapar: her DNS kaydını yetkili sunucunun özel anahtarıyla kriptografik olarak imzalar. Resolver, cevapla birlikte gelen imzayı (RRSIG) ilgili açık anahtarla (DNSKEY) doğrular; imza tutmuyorsa cevabı reddeder. Böylece saldırgan doğru Query ID'yi tahmin etse bile, geçerli bir imza üretemeyeceği için sahte cevabı hiçbir işe yaramaz.

DNSSEC bir güven zinciri üzerine kuruludur: kök bölge (.) TLD'yi (örneğin .com veya .tr) imzalar, TLD alan adınızı imzalar. Zincirin her halkası bir üst halka tarafından onaylanır ve en tepede tüm resolver'lara gömülü olan kök anahtarı bulunur. Alan adınızın anahtarını üst bölgeye bağlayan kayda DS (Delegation Signer) kaydı denir. DNSSEC'i etkinleştirmenin kısa özeti şudur: DNS sağlayıcınızda bölgeyi imzalatın, ardından ürettiği DS kaydını alan adınızın registrar panelinde ilan edin.

Etkinleştirdikten sonra çalıştığını dig ile doğrulayabilirsiniz. Doğrulama yapan bir resolver'a +dnssec bayrağıyla sorduğunuzda cevapta RRSIG kayıtlarını ve başlıkta AD (Authenticated Data) bayrağını görmeniz gerekir:

# İmzalarla birlikte sorgula ve doğrulamayı gözlemle
dig @1.1.1.1 bankam.com A +dnssec

# Basari gostergesi: baslik flags bolumunde "ad" ibaresi
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
bankam.com.   3600  IN  A      203.0.113.10
bankam.com.   3600  IN  RRSIG  A 13 2 3600 20260801000000 (...)

Buradaki ad bayrağı, resolver'ın imzayı başarıyla doğruladığını kanıtlar. Yanlış yapılandırılmış bir DNSSEC'in siteyi erişilemez yapabileceğini ve güven zincirinin nasıl kurulup doğrulanacağını daha ayrıntılı görmek isterseniz DNSSEC nedir yazımızda tüm adımları örneklerle bulabilirsiniz. Kritik nokta şudur: DNSSEC, spoofing'e karşı bugün elimizdeki en güçlü ve en kesin savunmadır; çünkü sahte cevabı istatistiksel olarak değil, matematiksel olarak imkânsız kılar.

DoH, DoT ve Güvenilir Çözümleyici Kullanımı#

DNSSEC cevabın gerçekliğini doğrular ama trafiği şifrelemez; kimin hangi siteyi sorduğu yolda hâlâ görünür ve MITM konumundaki bir saldırgan sorguları izleyebilir. İşte bu boşluğu DNS-over-HTTPS (DoH) ve DNS-over-TLS (DoT) kapatır. Bu protokoller, sizinle çözümleyici arasındaki DNS trafiğini şifreleyerek hem gizliliği sağlar hem de yoldaki bir saldırganın cevabı görüp taklit etmesini engeller. DNSSEC ile DoH/DoT birbirinin alternatifi değildir; biri cevabın doğruluğunu (bütünlük), diğeri iletişimin gizliliğini korur ve en sağlam kurulum ikisini bir arada kullanır.

Uygulamada birçok modern tarayıcı ve işletim sistemi DoH'yi destekler. İşletim sistemi genelinde şifreli DNS istiyorsanız, systemd-resolved gibi bir çözümleyici üzerinde DoT'yi etkinleştirebilirsiniz:

# /etc/systemd/resolved.conf — DoT ile guvenilir resolver
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=yes

Bunun bir katman daha ötesi, kendi ağınızda merkezi bir şifreli çözümleyici çalıştırmaktır. Küçük bir VPS üzerinde bir DoH sunucusu çalıştırıp, önüne bir ters vekil koyarak tüm cihazlarınızı bu güvenli uç noktaya yönlendirebilirsiniz:

# DoH uc noktasini TLS ile yayinlayan ters vekil ornegi
server {
    listen 443 ssl http2;
    server_name dns.ornekdomain.com;

    ssl_certificate     /etc/ssl/certs/dns.crt;
    ssl_certificate_key /etc/ssl/private/dns.key;

    location /dns-query {
        proxy_pass http://127.0.0.1:8053;  # yereldeki DoH cozumleyici
    }
}

Şifreli protokol kadar önemli olan bir diğer nokta, güvenilir bir çözümleyici seçmektir. Cloudflare (1.1.1.1), Google (8.8.8.8) ve Quad9 (9.9.9.9) gibi büyük genel resolver'lar hem varsayılan olarak DNSSEC doğrulaması yapar hem de altyapılarını cache poisoning'e karşı sıkılaştırmıştır. İnternet servis sağlayıcınızın veya rastgele bir ağın atadığı bilinmeyen bir resolver yerine bunlardan birini kullanmak, saldırı yüzeyini tek başına ciddi ölçüde daraltır. Halka açık Wi-Fi ağlarında ise şifreli DNS (DoH/DoT) neredeyse zorunludur, çünkü bu ortamlar MITM saldırıları için biçilmiş kaftandır.

Sunucu ve Site Yöneticileri İçin Önlemler#

Şimdiye kadar çoğunlukla kullanıcı ve resolver tarafına baktık; ancak bir alan adı veya sunucu sahibiyseniz, kendi kullanıcılarınızı korumak için atmanız gereken adımlar da vardır. Bir saldırgan sizin alan adınızı taklit ederek müşterilerinizi zehirlerse, itibar kaybı doğrudan size yansır.

İlk ve en önemli adım, kendi alan adlarınızda DNSSEC'i etkinleştirmektir. Bu, doğrulama yapan resolver'lar için alan adınızın taklit edilmesini imkânsız kılar. İkinci olarak, kendi özyinelemeli çözümleyicinizi işletiyorsanız yazılımını güncel tutun ve kaynak port rastgeleleştirmesinin açık olduğundan emin olun. Modern BIND, Unbound gibi yazılımlarda bu varsayılan olarak etkindir, ancak eski veya yanlış yapılandırılmış kurulumlarda kapatılmış olabilir:

# Unbound — sikilastirma ornegi
server:
  harden-dnssec-stripped: yes   # imza cikarma saldirilarina karsi
  harden-referral-path: yes
  use-caps-for-id: yes          # 0x20 karisik buyuk/kucuk harf entropisi
  qname-minimisation: yes       # sorguda minimum bilgi sizdirir
  do-not-query-localhost: yes

Üçüncü olarak, alan adı yönetim panelinize erişimi sıkılaştırın: registrar hesabınızda iki adımlı doğrulama açın ve mümkünse registry lock hizmetini kullanın; çünkü bir saldırgan panelinize girip nameserver'larınızı değiştirebilirse DNSSEC bile onu durduramaz. DNS altyapısını basit tutmak, izlemek ve tek elden yönetmek için alan adı ve barındırma hizmetlerinizi aynı çatı altında toplamak işleri kolaylaştırır; alan adı ve hosting hizmetlerimiz DNSSEC ve DS kaydı yönetimini tek panelden sunar. Sunucu tarafında ek bir güvenlik katmanı isteyen ekipler için sunucu yönetimi ve saldırı trafiğini süzen WAF çözümleri de bu resmi tamamlar.

Sıkça Sorulan Sorular#

DNS spoofing ile phishing arasındaki fark nedir?#

Phishing genellikle kullanıcıyı sahte bir bağlantıya tıklatmaya veya yanlış bir adres yazmaya kandırmaya dayanır; kurban bir şekilde ikna edilir. DNS spoofing ise daha sinsidir, çünkü kullanıcı doğru alan adını kendi eliyle yazsa bile yanlış sunucuya yönlendirilir. Adres çubuğunda doğru adres göründüğü için kurbanın şüphelenmesi çok daha zordur. Uygulamada saldırganlar sıklıkla ikisini birleştirir: DNS spoofing ile kullanıcıyı sahte siteye taşır, phishing teknikleriyle de kimlik bilgilerini toplar.

Antivirüs yazılımı DNS spoofing'i engeller mi?#

Kısmen. Antivirüs yazılımları, cihazınızın hosts dosyasını değiştiren veya DNS ayarlarını kaçıran yerel zararlı yazılımları tespit edebilir; bu yönüyle faydalıdır. Ancak resolver önbelleğinin uzaktan zehirlenmesi veya güvenilmeyen bir ağdaki MITM saldırısı gibi cihaz dışındaki tehditlere karşı antivirüs tek başına yeterli değildir. Bu ağ katmanı saldırılarına karşı asıl korumayı DNSSEC ve şifreli DNS (DoH/DoT) sağlar.

HTTPS kullanmak DNS spoofing'i durdurur mu?#

Doğrudan durdurmaz, ama etkisini önemli ölçüde azaltır. HTTPS, kullanıcıyı yanlış sunucuya yönlendirmeyi engellemez; DNS çözümlemesi zaten spoofing sırasında bozulmuştur. Ancak saldırganın gerçek siteyi taklit edebilmesi için geçerli bir TLS sertifikasına da ihtiyacı vardır. Sertifika uyuşmazsa tarayıcı uyarı verir ve dikkatli bir kullanıcı durur. Yine de sertifika otoritelerini kandıran saldırılar mümkün olduğundan, HTTPS'i DNSSEC ile birlikte katmanlı bir savunma olarak düşünmek gerekir.

Cache poisoning'e uğradığımı nasıl anlarım?#

En pratik yöntem, aynı alan adını birden fazla güvenilir çözümleyiciden sorgulayıp cevapları karşılaştırmaktır. Örneğin dig @1.1.1.1 alanadi.com ve dig @9.9.9.9 alanadi.com komutları farklı IP'ler döndürüyorsa ve biri beklenmedikse şüphelenin. Ayrıca alan adının yetkili sunucusundan aldığınız cevabı dig alanadi.com @yetkili-ns ile kontrol edin. DNSSEC etkinse, doğrulama yapan bir resolver zaten sahte cevabı reddedeceği için zehirlenme büyük ölçüde imkânsız hale gelir; bu da erken tespit yerine önleme sağlar.

Halka açık Wi-Fi'de DNS spoofing riski daha mı yüksek?#

Evet, belirgin biçimde. Halka açık ağlar, saldırganın kullanıcı ile resolver arasındaki trafiği izleyebildiği man-in-the-middle senaryoları için ideal ortamdır; saldırgan gerçek cevabın Query ID ve portunu görebildiği için sahte yanıt üretmesi çok kolaylaşır. Bu ortamlarda korunmanın en etkili yolu, tüm DNS trafiğini şifreleyen DoH veya DoT kullanmak ve mümkünse güvenilir bir VPN üzerinden bağlanmaktır. Böylece yoldaki saldırgan ne sorgunuzu görebilir ne de cevabı taklit edebilir.

DNSSEC her türlü DNS saldırısını engeller mi?#

Hayır, DNSSEC her şeyi çözmez ama en yaygın ve en tehlikeli türü, yani cache poisoning ile spoofing'i etkili biçimde durdurur; çünkü sahte cevabın geçerli bir imza taşıması matematiksel olarak imkânsızdır. Ancak DNSSEC trafiği şifrelemediği için gizlilik sağlamaz (bunun için DoH/DoT gerekir) ve registrar hesabınızın ele geçirilmesi ya da yetkili sunucunun kendisinin tehlikeye girmesi gibi durumlara karşı koruma sunmaz. Bu yüzden DNSSEC'i tek başına değil, şifreli DNS ve hesap güvenliğiyle birlikte katmanlı bir savunmanın parçası olarak düşünmek gerekir.

Kapanış#

DNS spoofing ve cache poisoning, internetin en temel ama en az korunan katmanlarından birindeki bir güven açığını istismar eder: klasik DNS, gelen cevabın gerçekliğini doğrulamaz. Bu boşluk, kullanıcının doğru adresi yazmasına rağmen sahte bir sunucuya yönlendirilmesine ve fark etmeden kimlik bilgilerini teslim etmesine yol açabilir. Neyse ki savunma bugün oldukça olgun: cevapları kriptografik olarak imzalayan DNSSEC, trafiği şifreleyen DoH/DoT ve DNSSEC doğrulaması yapan güvenilir çözümleyiciler bir arada kullanıldığında bu saldırılar pratikte etkisiz hale gelir.

Bir site veya sunucu sahibi olarak yapmanız gereken en değerli hamle, kendi alan adlarınızda DNSSEC'i etkinleştirmek ve DNS altyapınızı güvenilir, tek panelden yönetilebilen bir sağlayıcıya taşımaktır. Clou.TR'nin alan adı ve hosting hizmetleriyle DNSSEC ve DS kaydı yönetimini kolayca yapabilir, SSL sertifikası ve WAF gibi katmanlarla korumanızı uçtan uca tamamlayabilirsiniz. Güvenlik, tek bir üründe değil, doğru katmanların bir araya gelmesinde saklıdır.