Domain Spoofing Nedir, Alan Adı Taklidinden Nasıl Korunulur

Muhasebe departmanına genel müdürün adresinden bir e-posta düşüyor, acil bir ödeme isteniyor ve IBAN değişmiş. Adres doğru görünüyor, imza doğru görünüyor, üslup bile tanıdık. Gönderen adresinin taklit edilmesi ya da bir harfi değiştirilmiş ikiz bir alan adı kullanılması, kurumsal dolandırıcılığın en yaygın girişidir. Domain spoofing nedir, hangi biçimlerde karşınıza çıkar ve alan adınızı bu tür kötüye kullanımlara karşı nasıl kapatırsınız, bu yazıda sırasıyla anlatıyoruz.

Domain spoofing nedir ve saldırganın işine nasıl yarar?

Domain spoofing nedir sorusunun teknik karşılığı şudur: bir iletinin ya da adresin, size ait olmayan bir alan adından geliyormuş gibi sunulmasıdır. Kurbanın gördüğü isim gerçektir; arkasındaki kaynak değildir.

Saldırganın kazancı güvendir. Bilmediği bir adresten gelen ödeme talebine kimse itibar etmez, ama on yıldır çalıştığı tedarikçinin adresinden gelen bir fatura düzeltmesine itibar eder. Alan adı burada bir kimlik belgesidir ve e-posta protokolü, o belgeyi kendiliğinden doğrulamaz. SMTP tasarlandığında gönderen adresinin doğruluğunu denetleyen bir mekanizma yoktu; bugün kullandığımız SPF, DKIM ve DMARC kayıtları sonradan eklenen yamalardır.

Alan adı taklidinin üç biçimi

Savunmayı doğru kurmak için hangi biçimle karşı karşıya olduğunuzu ayırt etmek gerekir, çünkü üçü farklı yerlerden durdurulur. Aşağıdaki tablo, saldırı türünü, ne üzerine kurulduğunu ve karşılığında hangi savunmanın işe yaradığını özetliyor.

İlk satır dışındaki hiçbir saldırı biçimi sizin alan adınızı kullanmaz. Bu ayrım önemlidir: e-posta kimlik doğrulama kayıtlarınız kusursuz olsa bile, bir harfi değiştirilmiş başka bir alan adından çıkan iletiyi sizin kayıtlarınız durduramaz. O tarafın savunması izleme ve farkındalıktır.

SPF, DKIM ve DMARC neyi engeller?

Üç kayıt birbirinin yerine geçmez, birbirini tamamlar. SPF, alan adınız adına e-posta göndermeye yetkili sunucuların listesidir; alıcı sunucu, iletinin bu listedeki bir adresten çıkıp çıkmadığına bakar. DKIM, giden iletiye sunucunuzun özel anahtarıyla imza ekler; alıcı, DNS’te yayınladığınız açık anahtarla imzayı doğrular ve iletinin yolda değiştirilmediğini görür.

DMARC ise üstte durur ve iki soruyu sorar: SPF ya da DKIM geçti mi, ve geçen kayıt iletide görünen gönderen adresiyle aynı alan adına mı ait? İkisi de olumluysa ileti kabul edilir. Değilse, alıcı sunucuya ne yapması gerektiğini yine sizin yayınladığınız DMARC politikası söyler. Kayıtların söz dizimi ve alan tanımları için dmarc.org genel bakış sayfası ve RFC 7489 metni birincil kaynaktır.

DMARC politikası kademeli nasıl sıkılaştırılır?

DMARC politikasını doğrudan reject ile başlatmak, farkında olmadığınız meşru gönderim kaynaklarını bir gecede susturur. Fatura sistemi, bülten servisi, CRM, işe alım yazılımı ve destek paneli sizin alan adınız adına e-posta gönderiyor olabilir. Doğru sıra şudur.

none aşaması. Politika hiçbir iletiyi engellemez, yalnızca rapor toplar. Bu aşamada amaç, alan adınız adına gerçekte kimlerin gönderim yaptığını eksiksiz çıkarmaktır. İki ile dört hafta arası yeterli olur; aylık fatura döngüsünü kapsaması için en az bir tam ay önerilir.

quarantine aşaması. Doğrulamayı geçemeyen iletiler spam klasörüne düşer. Önce yüzde on gibi küçük bir oranla başlanır, raporlarda meşru bir kaynağın takılıp takılmadığı izlenir, sorun çıkmazsa oran kademeli yükseltilir. Bu aşamada eksik kalan sistemlerin SPF ve DKIM kayıtları tamamlanır.

reject aşaması. Doğrulamayı geçemeyen ileti alıcı sunucuda teslim edilmeden reddedilir. Alan adınızın gönderen olarak taklidi bu noktada pratikte biter. Buraya ancak raporlarda meşru kaynak kaynaklı hata kalmadığında geçilir.

DMARC raporları nasıl okunur?

Raporlar iki türlüdür. Toplu raporlar günlük olarak gelir ve alan adınız adına gönderim yapan IP adreslerini, ileti sayısını, SPF ile DKIM sonuçlarını özetler. Hata raporları ise tek tek başarısız iletiler için gönderilir ve kişisel veri taşıdığı için çoğu sağlayıcı bunları kısıtlı gönderir.

Toplu raporlar XML biçimindedir ve elle okunması zahmetlidir; küçük bir ekipte bile bir rapor işleme aracı kullanmak zaman kazandırır. Bakılacak iki şey vardır: tanımadığınız bir IP adresinden çıkan ve doğrulamayı geçemeyen yüksek hacim, ve tanıdığınız bir servisin sürekli takılması. Birincisi taklit denemesine, ikincisi sizin eksik kalan kaydınıza işaret eder.

Benzer alan adlarını savunma amaçlı kaydetmek

Bütün varyantları satın almak mümkün değildir; bir markanın karıştırılabilir yazımı yüzlerce olabilir. Makul yaklaşım, riski en yüksek olan dar bir kümeyle sınırlanmaktır: en çok kullandığınız uzantının komşuları, marka adındaki bitişik harflerin yer değiştirmiş hâli, tireli ve tiresiz yazım, ve çoğul ya da tekil biçim.

Kaydettiğiniz savunma alan adlarını boş bırakmayın. Hepsini ana alan adınıza yönlendirin, üzerlerinde e-posta gönderimini kapatan bir SPF kaydı ve reject politikalı bir DMARC kaydı bırakın. Böylece o alan adları başkasının eline geçmediği gibi, sizin adınıza gönderim aracı olarak da kullanılamaz. Kayıt yenileme tarihlerini de ana alan adınızla aynı takvime alın; unutulup düşen bir savunma alan adı, tam da korumak istediğiniz kişinin eline geçer.

Alıcı tarafını güçlendirmek

Teknik kayıtlar gönderen tarafını korur. Kurumunuza gelen taklit iletilere karşı ise alıcı tarafında üç ayar işe yarar. Birincisi, dışarıdan gelen iletilere görünür bir uyarı etiketi eklemek. İkincisi, gönderen adı kurum içindeki bir yöneticiyle eşleşip adresi dışarıdan olan iletileri karantinaya almak. Üçüncüsü, kurumsal e-posta altyapısını ortak bir yönetim altında toplamak; dağınık kişisel hesaplarla çalışan bir yapıda bu kuralların hiçbiri uygulanamaz.

Şirket e-postasını kurumsal bir alan adı üzerinde toplamadıysanız başlangıç noktası orasıdır; şirket e-postası oluşturma yazımız kurulum sırasını anlatıyor. Web tarafında ise sahte giriş sayfalarını ayırt etmenin en pratik yolu sertifika kontrolüdür; SSL sertifikası nedir yazımızda doğrulama seviyeleri arasındaki farkı açıkladık.

Çalışan farkındalığı ve süreç savunması

Domain spoofing nedir sorusunun en can sıkıcı tarafı, teknik savunmanın bittiği yerde işin insana kalmasıdır. Para transferi, banka hesabı değişikliği, maaş bordrosu yönlendirmesi ve tedarikçi bilgisi güncellemesi gibi talepler için tek kural yeterlidir: talep hangi kanaldan gelirse gelsin, kayıtlı telefon numarası üzerinden ikinci kez doğrulanmadan uygulanmaz. Bu kural yazılı olmalı, istisnası bulunmamalı ve aciliyet baskısı altında delinmemelidir.

Farkındalık eğitiminde soyut anlatım yerine kendi alan adınızın varyantlarını gösterin. Çalışanın ekranda gördüğü şey marka adının bir harfi eksik hâliyse, o örneği bir kez görmüş olmak uzun bir sunumdan daha çok iş görür.

Taklit saldırısına uğradıysanız ne yapmalı?

Müşterileriniz sizin adınıza gelen sahte e-postalardan şikâyet etmeye başladıysa sıra şudur. Önce kendi kayıtlarınızı doğrulayın; taklit sizin alan adınız üzerinden yapılıyorsa DMARC politikanızı sıkılaştırmak saldırıyı doğrudan keser. Taklit benzer bir alan adından yapılıyorsa o alan adının WHOIS kaydını ve barındırıldığı sağlayıcıyı çıkarın, kötüye kullanım bildirimini sağlayıcıya ve alan adı kayıt kuruluşuna iletin.

Eş zamanlı olarak müşterilerinize ve tedarikçilerinize kendi resmî kanalınızdan uyarı gönderin; gerçek alan adınızı ve ödeme bilgilerinizin değişmediğini açıkça yazın. İç tarafta, saldırı süresince gelen tüm ödeme taleplerini geriye dönük gözden geçirin. Son olarak sahte alan adını kendi e-posta filtrelerinize engelli olarak ekleyin ve izlemeye alın; aynı kişi genelde benzer bir varyantla geri döner.

• Alan adınız için SPF kaydını tek satır hâlinde yayınlayın, yetkili tüm gönderim kaynaklarını içine alın.
• Kurumsal e-posta sunucunuzda DKIM imzalamayı açın ve açık anahtarı DNS’e ekleyin.
• DMARC kaydını none politikasıyla başlatın, rapor adresini tanımlayın ve en az bir ay veri toplayın.
• Raporlarda görünen meşru gönderim kaynaklarının eksik kayıtlarını tamamlayın.
• quarantine aşamasını düşük oranla açın, sorun çıkmazsa kademeli yükseltip reject’e geçin.
• Marka adınızın en çok karıştırılan üç dört varyantını kaydedin, gönderime kapalı DNS kayıtlarıyla park edin.
• Gelen e-postada dış gönderen etiketini ve görünen ad uyarısını etkinleştirin.
• Ödeme ve hesap bilgisi değişikliği taleplerinde ikinci kanaldan doğrulamayı yazılı kural hâline getirin.