Alan Adı Sahteciliği Gerçekte Nasıl Çalışır ve DMARC Neyi Durduramaz

Birisi şirketinizden geliyormuş gibi görünen phishing e-postaları gönderiyor. Müşterileriniz onları alıyor. Her şeyi doğru yaptınız — SPF, DKIM, p=reject'te DMARC, tüm aparat — ve e-postalar yine de geliyor.

Bu, e-posta güvenliğindeki en cesaret kırıcı anlardan biridir, çünkü standart tavsiye zaten uygulanmış ve işe yaramamıştır. Bunun nedeni bir şeyi yanlış yapılandırmanız değildir. DMARC'ın çoğu açıklaması sessizce neyi kapsamadığını atlar, ve boşluk insanların beklediğinden çok daha geniştir.

İşte sahteciliğin gerçekte nasıl çalıştığı, savunmalarınızın gerçekte neyi durdurduğu, ve hiçbir zaman neye dokunması amaçlanmadığı.

SMTP onur sistemi üzerine inşa edildi

Sahteciliğin mümkün olmasının nedeni 1982'den kalma bir tasarım kararına dayanır. E-postayı taşıyan protokol SMTP'nin, kim olduğunuzu kanıtlamak için yerleşik bir kavramı yoktur. Bir posta sunucusuna bağlanırsınız ve kim olduğunuzu beyan edersiniz. Sunucu sözünüzü kabul eder.

Daha kötüsü — iki ayrı "kimden" alanı vardır, ve birbirleriyle hiçbir ilgileri yoktur.

Zarf gönderen. Bu, SMTP konuşmasının kendisinin bir parçasıdır, MAIL FROM komutunda gönderilir. Geri dönüş işleme için kullanılır — hataların döndüğü yer. Alıcı bunu asla görmez.

Başlık From. Bu, mesaj içeriğinin içindeki bir satırdır, ve posta istemcisinin görüntülediği şey budur. Kullanıcılarınızın gerçekte baktığı şey budur.

Bu iki alan bağımsız olarak ayarlanır, ve protokolde eşleşmelerini gerektiren hiçbir şey yoktur. Bu bir hata değildir — meşru hizmetler sürekli olarak buna güvenir. Bülten sağlayıcınız zarf gönderenini kendi geri dönüş işleme adresine ayarlarken başlık From markanızı gösterir. Posta listeleri de aynısını yapar. Normaldir.

Ama aynı zamanda şu anlama gelir: herkes başlık From'a herhangi bir şey koyabilir. Yazın ve gönderin. Protokol umursamaz. Bunun hepsi bu. Alan adı sahteciliği bir istismar veya güvenlik açığı değildir — bu, tasarlandığı gibi çalışan SMTP'dir.

SPF hakkındaki rahatsız edici gerçek

İşte çoğu anlayışın çöktüğü yer burasıdır.

SPF zarf gönderenini kontrol eder. Başlık From'u değil.

Bunu tekrar okuyun, çünkü insanların gerçekten şaşırtıcı bulduğu bir sonucu var: bir saldırgan size mükemmel geçen bir SPF sonucu ve tamamen sahte bir görünen From adresi olan bir mesaj gönderebilir. Sadece zarf gönderenini meşru olarak sahip olduğu, geçerli bir SPF kaydına sahip bir alan adına ayarlar, ve başlık From'u sizinkine ayarlar.

SPF geçer. Yalan söylemiyor — mesaj gerçekten zarf alan adı için yetkilendirilmiş bir sunucudan geldi. SPF sorulan soruya doğru cevap verdi. Sadece önemli olan soru bu değildi.

SPF tek başına, görünür alan adı sahteciliğine karşı esasen hiçbir koruma sağlamaz. Kusursuz bir SPF kaydına ve DMARC'a sahip olmayan bir alan adı tamamen açıktır. "SPF'imiz var" ifadesinin "birisi bizi taklit edebilir mi" sorusuna bir cevap olmamasının nedeni budur.

DKIM'in ayna görüntüsü bir boşluğu vardır: bir mesajın bir alan adı tarafından imzalandığını ve değiştirilmediğini kanıtlar, ama attacker-domain.example'dan sizin olduğunu iddia eden bir mesaj üzerindeki geçerli bir imza hâlâ geçerli bir imzadır.

DMARC, her iki boşluğu da kapatan parçadır, hizalama gerektirerek: SPF veya DKIM'i geçen alan adı, görünen From'daki alan adıyla eşleşmelidir. Gerçek koruma budur. SPF ve DKIM girdilerdir; hizalama mekanizmadır.

Alan adınızın şu anda nerede durduğundan emin değilseniz, yayınlanan SPF, DKIM ve DMARC kayıtlarını kontrol etmek iki dakikalık bir egzersizdir, ve yaygın bulgu, SPF'si olan ama DMARC politikası olmayan, korunmuş hissettiren ama olmayan bir alan adıdır.

DMARC p=reject'te gerçekte neyi durdurur

Hakkını verelim. p=reject ve çalışan hizalama ile, tam alan adı sahteciliğini kapattınız. Kimse görünen From'da @yourdomain.com ile posta gönderip DMARC'a uyan herhangi bir alıcı tarafından kabul edilmesini sağlayamaz. Bu gerçek ve önemli bir kazançtır, ve mevcut en yüksek değerli tek e-posta güvenliği kontrolüdür.

Ayrıca size görünürlük verir. Toplu raporlar size sizin adınıza göndermeye çalışan her kaynağı gösterir.

Şimdi yeterince söylenmeyen kısım.

DMARC'ın hiçbir şey yapmadığı şeyler

Görünen ad sahteciliği. Bu büyük olandır, ve DMARC'ı tamamen bozar.

Bir e-postanın From satırının iki kısmı vardır: bir görünen ad ve bir adres. Posta istemcileri görünen adı belirgin bir şekilde gösterir ve sıklıkla adresi tamamen gizler — özellikle ekran alanının kıt olduğu mobilde.

Yani saldırgan şunu gönderir:

From: Ramil Mastiyev <billing@totally-unrelated-domain.example>

Alıcınız "Ramil Mastiyev" görür. Hepsi bu. Ekranda olan budur.

Peki DMARC? DMARC totally-unrelated-domain.example'ı değerlendirir — gerçek From alan adı. Saldırgan ona sahiptir, SPF ve DKIM'i düzgün yapılandırmıştır, ve DMARC geçer. Temiz bir şekilde. Politikanız alakasızdır, çünkü alan adınız From alanında hiç yoktur. DMARC'ın bakmadığı ve kullanıcıların okumayı durduramadığı bir metin etiketindedir.

p=reject politikanız burada başarısız olmadı. Sadece dahil edilmedi. Bu, en yaygın işletme e-postası ele geçirme biçimidir, ve dünyadaki her DMARC yapılandırması buna karşı kördür.

Benzer alan adları. Saldırgan rnarinadns.io'yu (bu r-n, m değil) veya yourdomain.co'yu, veya your-domain.com'u kaydeder. Sonra SPF, DKIM ve DMARC'ı üzerinde yapılandırır — doğru bir şekilde, çünkü phishing'inin kimlik doğrulamasını istiyor. Her şey geçer, onun alan adı için, ki bu standartların tam olarak amaçladığı şeydir.

DMARC bir alan adını korur. Sadece ona benzeyen alan adları hakkında hiçbir şey söylemez. "Bu birinin başkasına benziyor" için bir mekanizma yoktur, çünkü olamazdı.

Ele geçirilmiş meşru hesaplar. Bir saldırganın alan adınızda gerçek bir posta kutusu için geçerli kimlik bilgileri varsa, gönderdiği her şey mükemmel şekilde kimlik doğrulanır. Gerçekten sizden gelir. Her kontrol geçer, çünkü her kontrol geçmelidir. E-posta kimlik doğrulaması "bu yetkili bir gönderenden mi geldi" sorusuna cevap verir — ve ele geçirilmiş bir hesap yetkili bir gönderendir.

Kapıyı açık bıraktıysanız alt alan adı sahteciliği. DMARC'ın ayrı bir alt alan adı politika etiketi vardır, sp=. p=reject ayarladıysanız ama hiç sp= ayarlamadıysanız, alt alan adları ana politikayı devralır — genellikle sorun değil. Ama sp=none ayarladıysanız (veya bir sağlayıcı şablonu ayarladıysa), o zaman ana alan adı kilitli görünürken invoices.yourdomain.com korumasızdır. Kaydınızın gerçekte ne yayınladığını, ne düşündüğünüzü değil, doğrulamaya değer.

Boşluklar için savunmalar

DMARC yapısal olarak bunları kapsayamadığından, farklı araçlara ihtiyacınız var:

Benzer alan adları için: Certificate Transparency günlüklerini izleyin. Bu, güvenlikte en az kullanılan erken uyarı sistemidir. Herkese açık olarak güvenilen her TLS sertifikası, yayınlandığında herkese açık olarak günlüğe kaydedilir. Phishing operasyonlarının meşru görünmek için HTTPS'e ihtiyacı vardır — bu yüzden bir sertifika alırlar, ve bu, herhangi bir şey göndermeden önce herkese açık bir günlüğe düşer.

Alan adınıza benzeyen isimlere verilen sertifikalar için CT günlüklerini aramak, kurulum sırasında bir benzerini ortaya çıkarır, genellikle kampanya başlamadan günler önce. Herkese açık bir veri kümesinden, ücretsiz olarak, henüz gerçekleşmemiş bir saldırı hakkında önceden uyarı alırsınız. Bunu periyodik olarak yapın — benzerlerini yakalayan az sayıdaki kontrolden biridir.

Görünen ad sahteciliği için: bu çoğunlukla bir istemci ve eğitim sorunudur. Bazı posta sağlayıcıları artık bilinen kişilerle eşleşmeyen görünen adları işaretliyor. Bunun ötesinde, tamamen insanlarınızın etiket yerine gerçek adresi kontrol etmesi gerektiğini bilip bilmediğine bağlıdır — ki bu bir telefonda gerçekten zor bir taleptir.

Ele geçirilmiş hesaplar için: bu kimlik güvenliğidir, e-posta kimlik doğrulaması değil. MFA, kimlik bilgisi izleme, gönderme desenlerinde anomali tespiti. DNS'te hiçbir şey burada size yardımcı olmaz.

Şüpheli gelen posta için: başlıkları okuyun. Sizden (veya bir tedarikçiden, veya bir bankadan) olduğunu iddia eden bir mesaj birine ulaştığında ve bir şey yanlış hissettirdiğinde, ham başlıklar meseleyi çözer. Bir e-posta başlığı analizörü gerçekte neyin kimlik doğrulandığını, hangi alan adı için, ve geçen alan adının görüneniyle eşleşip eşleşmediğini gösterecektir — ki bu, saldırının sizin kontrol etmemenize dayandığı tam ayrımdır.

Dürüst özet

p=reject'te DMARC gereklidir, değerlidir, ve çabaya değer. Phishing'e bir çözüm değildir. Bir belirli deliği kapatır — birinin alan adınızı tam olarak From alanına koyduğu delik — ve o delik kapatılmaya değerdi.

Ama birisi size DMARC ile "sahteciliği çözdüğünü" söylediğinde, gerçekte yaptığı şey saldırganları bunun yerine yukarıdaki dört tekniği kullanmaya zorlamaktır. Ki bu ilerlemedir. Sadece konuşmanın sonu değildir, ve "DMARC devreye alındı" ile "phishing'den korunuyoruz" arasındaki boşluk, şu anda çoğu başarılı saldırının yaşadığı yerdir.