SPF, DKIM, DMARC.com

“Gönderen doğrulama” süreci, meşru bir gönderen ile kimliğini taklit eden bir saldırganı ayırt etmemizi ve olası bir Sahte posta saldırısını önlememizi sağlar.

Bu makalede, üç gönderen doğrulama standardını (SPF, DKIM, DMARC) ve ayrıca Exchange ve Exchange Online tabanlı ortamda uygulanabilen iki gönderen doğrulama yöntemini ayrıntılı olarak inceleyeceğiz.

Beş kahramanın SPF, DKIM DMARC, Exchange ve Exchange Online koruması

SPF, DKIM ve DMARC, gönderenin kimliğini doğrulamak amacıyla oluşturulan genel posta standardıdır.

Bizim için mevcut olan ek seçenekler:

Düşman öğenin, Exchange tarafından barındırılan kuruluş kullanıcılarına saldırmak için kuruluş kimliğini kullandığı bir olayı tanımlayacak Exchange sunucusu kuralını kullanma.
Phish filtresinin Exchange Online koruma seçeneğini kullanma.

SPF standardı bizi Sahte E-posta senaryosundan nasıl korur?

SPF standardı, "posta sunucusu" hakkındaki bilgileri doğrulayarak gönderen hakkında bir sonuca vardığımız bir kavrama dayanmaktadır.

Doğru olmak istiyorsak, SPF kullanırken E-posta adresinin “doğru kısmı” yani alan adı ile ilişki kurarız.

Göndereni temsil eden posta sunucusu, belirli bir alan adı (yaratıcının E-posta adresinde görünen alan adı) için “yetkili posta sunucusu” olarak değerlendirilmelidir.

Hedef posta sunucusunun (hedef alıcıyı temsil eden posta sunucusu) uyguladığı gönderen doğrulama işlemi, gönderen posta sunucusunun “bütünlüğünün” doğrulanmasıyla gerçekleştirilir.

"Göndereni" temsil eden posta sunucusu, belirli bir alan adı için "yetkili posta sunucusu" olarak değerlendirilmelidir.

SPF kaydında (bir TXT kaydı) yayınlanan, alan adı adına E-posta gönderebilen yetkili posta sunucusuna ilişkin, E-posta göndermeye yetkili posta sunucusunun IP adresi veya ana bilgisayar adlarının bir listesini içeren bilgiler etki alanı adına.

Gönderen kimliği "mağazası"

SPF kullanırken, kontrol edilen gönderenin kimliği, posta zarfında MAIL FROM alanında görünen E-posta adresidir.

SPF gönderen doğrulama süreçleri akışı

SPF gönderen doğrulama protokolü, gönderenin kimliğini doğrulamak için aşağıdaki mekanizmayı kullanır:

E-posta mesajı hedef posta sunucusuna ulaştığında, posta sunucusu, gönderenin E-posta adresine ilişkin bilgileri posta zarfından (MAIL FROM alanı) “getirir”.

Hedef posta sunucusu, E-posta adresinin alan adı (E-posta adresinin sağ kısmı) ile ilgilidir.

Özel örneğimizde, gönderenin alan adı o365info.com 'dur.

Posta sunucusu, o365info.com alan adını barındıran DNS sunucusuna adres verir ve "altında" barındırılan SPF kaydı hakkında bilgi arar. o365info.com alan adı.

SPF kaydı, o365info.com alanı adına e-posta göndermeye yetkili posta sunucusu hakkında ilgili bilgileri içeren bir TXT kaydı olarak uygulanır.

Özel örneğimizde posta sunucusu, “kaynak posta sunucusunun” (göndereni temsil eden posta sunucusu) IP adresinin SPF kaydında görünüp görünmediğini doğrular.

Durum 1 - kaynak posta sunucusunun IP adresinin SPF kaydında listelendiği gibi görünmesi durumunda, SPF doğrulama testi sonucu - “Geçer” anlamına gelir; gönderen meşru bir göndericidir çünkü posta sunucusu meşru bir posta sunucusu olarak kabul edilir.
Durum 2 - kaynak posta sunucusunun IP adresinin SPF kaydında listelendiği gibi görünmemesi durumunda, SPF doğrulama testi sonucu - “Başarısız” olur Anlam; gönderen meşru bir gönderen değil çünkü posta sunucusu geçerli bir posta sunucusu değil.

SPF | E-posta iletisinin Sahte E-posta olarak sınıflandırıldığı senaryo

Aşağıdaki diyagramda Spoof mail senaryosuna ilişkin SPF doğrulama işleminin mantığını görebiliriz:

E-posta mesajını gönderen adına gönderen posta sunucusu IP adresinin belirli bir alan adına ait SPF kaydında görünmemesi durumunda, E-posta mesajının bir e-posta olduğu sonucuna varılır. Sahte posta (sahte gönderen).

SPF standardının dezavantajı

SPF yönteminin, SPF doğrulama sürecinde doğrulanan posta alanıyla ilgili önemli bir dezavantajı vardır.

SPF doğrulama işlemi, MAIL FROM dosyasındaki posta zarfında görünen E-posta adresini "getirir".
SPF doğrulama işlemi, FROM bölümündeki posta başlığında görünen E-posta adresini ilişkilendirmez veya kontrol etmez.

Bu yöntem, iki farklı kimlik sağlayarak SPF doğrulama mekanizmasını atlayabilen düşman unsurlar tarafından kolaylıkla istismar edilebilir.

MAIL FROM alanındaki kimlik meşru bir kimlik olacaktır.
FROM alanındaki kimlik sahte bir kimlik olacaktır.

SPF standart işlemi, yalnızca MAIL FROM alanında saklanan gönderen bilgilerini doğrulamak için yapılandırılmıştır. Başka bir deyişle, SPF gönderen doğrulama işlemi, FROM alanında saklanan gönderen bilgileriyle ilgili olmayacaktır. Bu, düşman unsurlar tarafından istismar edilebilecek yerleşik bir zayıflıktır. Bu güvenlik açığı hakkında daha fazla bilgi edinmek isterseniz şu makaleleri okuyabilirsiniz:

Düşman unsur Sahte E-posta saldırısını nasıl gerçekleştirebilir ve mevcut SPF uygulamasını nasıl atlayabilir? | giriş | 1#2
Sahte E-posta saldırısı nasıl simüle edilir ve SPF gönderen doğrulaması nasıl atlanır? | 2#2

DKIM standardı bizi Sahte posta senaryosundan nasıl koruyor?

Postayı gönderenin kimliğinin meşruluğunu doğrulamaya yönelik DKIM yöntemi, gönderenden gönderilen E-posta mesajını "yetkili bir kuruluşun" dijital olarak imzaladığı bir yöntemle uygulanır.

Mevcut PKI'ya (ortak anahtar anahtarı altyapısı) dayanan Dijital imza.

- Dijital imza seçeneğinin kullanılması, “diğer tarafın” (senaryomuzda hedef alıcıyı temsil eden posta sunucusunun) güvenilir bir yetkilinin bilgileri (E-posta iletisi) gönderdiğinden emin olmasını sağlar.

E-posta güvenilir bir yetkili (posta sunucusu, göndereni temsil eder) tarafından gönderildiğinden, hedef posta sunucusu gönderenin meşru bir gönderen olduğundan emin olabilir (gönderen, iddia ettiği kişidir).

Gönderenin E-posta mesajını dijital olarak imzalayan "yetki", genellikle E-postayı gönderen adına teslim eden posta sunucusudur.

DKIM altyapısında, E-posta mesajını imzalayan varlık DKIM seçici olarak tanımlanır.

DKIM seçici tarafından imzalanan bilgiler birkaç posta alanı içerir. Konumuz bağlamında bilmemiz gereken en önemli şey, gönderenin kimliğini (gönderenin E-posta adresi) içeren FROM adlı posta alanının dijital olarak imzalanmış olmasıdır.

DKIM standardı ve DKIM'in Office 365 tabanlı ortamda uygulanması hakkında daha detaylı bilgi almak isterseniz DKIM - Etki Alanı Anahtarları Tanımlanmış Posta | Temel giriş | Bölüm 1#10.

DKIM gönderen doğrulama işlemleri akışı.

DKIM gönderen doğrulama protokolü, gönderenin kimliğini doğrulamak için aşağıdaki mekanizmayı kullanır:

Kaynak posta sunucusundan gönderilen E-posta içerir.

Gönderenin E-posta adresini içeren verilerin dijital imzası.
E-postayı imzalayan posta sunucusunun DKIM seçici anlamına gelen adı (FQDN) hakkında bilgi.

E-posta mesajı hedef posta sunucusuna ulaştığında, posta sunucusu posta başlığından (FROM alanı) gönderenin E-posta adresine ilişkin bilgileri “getirir”.

E-posta mesajını dijital olarak imzalayan “yetkili” hakkında bilgi alabilmek için hedef posta sunucusu, E-posta adresinin alan adına (E-posta adresinin sağ kısmı) ilişkindir.

Özel örneğimizde, gönderenin alan adı o365info.com 'dur.

Posta sunucusu, E-posta mesajını imzalayan DKIM seçicinin ana bilgisayar adını, posta başlığından "getirir".

Hedef posta sunucusu, belirli alan adını barındıran bir DNS sunucusuna adres verir ve o365info.com alan adı "altında" barındırılan DKIM kaydı hakkında bilgi arar.
DKIM seçicinin ana bilgisayar adı hakkında ilgili bilgileri içeren, TXT kaydı olarak uygulanan DKIM kaydı.

Bir DKIM senaryosunda posta sunucusu, DKIM seçicinin ana bilgisayar adı hakkında bilgi arayacaktır.

DKIM kaydının,
E-posta mesajında görünen DKIM seçicinin ana bilgisayar adını içermesi durumunda, posta sunucusu kendisinin yetkili otorite olduğunu ve kendisine güvenilebileceğini "bilir".

Şimdi hedef posta sunucusuna geçerek, E-posta mesajında görünen Dijital imzayı doğrulaması gereken bir sonraki aşamaya geçin.

Dijital imza doğrulama işlemi oldukça karmaşık bir süreçle gerçekleştirilir. Hedef posta sunucusu, posta alanının HASH değerini (gönderenin E-posta adresini içeren FROM posta alanı dahil) kendisi hesaplar ve elde ettiği HASH değerini HASH değeriyle karşılaştırır. E-postada görünen.

Durum 1 - HASH değerinin aynı olması durumunda, verinin hiçbir şekilde değiştirilmediği anlamına gelir ve bu durumda gönderenin meşru bir gönderen olduğundan emin olabiliriz.
Durum 2 - HASH değerinin aynı olmaması durumunda, bunun anlamı verinin değiştirildiğidir ve bu nedenle gönderenin meşru olduğundan emin olamayız gönderen.

DKIM | E-posta mesajının Sahte E-posta olarak sınıflandırıldığı senaryo.

DKIM süreci açısından bakıldığında, doğrulama testi başarıyla tamamlanması gereken iki "test" içerir.

Test 1 - E-posta mesajında görünen DKIM seçicinin, gönderenin alan adı altında barındırılan DKIM kaydında görünmemesi durumunda, doğrulama işlemi başarısız olarak kabul edilir, yani E -mail Sahte posta olarak kabul edilir.

Test 2 - Dijital imzanın HASH değerinin geçerli olmaması (aynı olmaması) durumunda, doğrulama işlemi başarısız olarak değerlendirilir, yani E-posta, Sahte posta olarak kabul edilir.

Exchange bizi Sahte E-posta senaryosundan nasıl korur?

Bir bildirimle başlayalım - varsayılan olarak; Exchange bizi sahte posta (sahtekar gönderen) senaryosuna karşı "koruyacak" şekilde yapılandırılmamıştır.

Hatta Exchange sunucusunun Spoof E-mail saldırılarına veya gönderenin kimliğine karşı “kayıtsız” kaldığını bile söyleyebiliriz.

Her ne kadar Exchange sunucusu varsayılan olarak gönderenin kimliğinin meşruiyetine karşı "kayıtsız" olsa da, meşru gönderenleri tanımlamamıza yardımcı olacak güçlü bir Exchange seçeneğini kullanabiliriz. Exchange kuruluşu tarafından barındırılan alan adını (Exchange'in yetkili kabul ettiği belirli alan adı) kullanan gönderenin kimliğini doğrulamak istediğimiz belirli bir senaryoda.

“Değişim doğrulama testi” “iki parçanın” birleşimi kullanılarak uygulanır:

E-posta mesajı başlığına kaydedilen bilgiler.
Değişim kuralı.

Bir Exchange kuralı kullanarak, sahte bir gönderenin (sahte posta) senaryosunu tanımlamamızı sağlayacak mantıksal bir koşul tanımlayabiliriz.

"Sahte posta" terimini kullandığımızda, belirli bir senaryo anlamına gelir; düşman unsurun "kullanıcı kimliğimizi" kullandığı ve kuruluşumuzun kullanıcılarından birine saldırmaya çalıştığı bir senaryo.

Aşağıdaki mantığa göre tanımladığımız Exchange kuralı koşulu:

Kurumsal kimliğimizi (alan adımızı içeren E-posta adresi) kullanan her varlığın, Exchange sunucumuz tarafından barındırılan meşru bir varlık olması gerekir.

Exchange sunucusuna hitap eden her meşru varlığın kullanıcı kimlik bilgilerini sağlaması gerekir; böylece Exchange sunucusu, bunun meşru ve güvenilir bir varlık olduğunu bilebilir.

Örneğin, Outlook'umuzu açıp posta kutumuzda saklanan verilere eriştiğimizde, kullanıcı kimlik bilgilerimiz arka planda Exchange sunucusuna "aktarılır".

"Varlıkların" kullanıcı kimlik bilgilerini sağlayıp sağlamadığı bilgisi, posta başlığının bir parçası olarak kaydedilir.

Varlığın kullanıcı kimlik bilgilerini sağlaması durumunda varlık kimlik doğrulama durumu - dahili olur.
Varlığın kullanıcı kimlik bilgilerini sağlamaması durumunda varlık kimlik doğrulama durumu - Anonim olur.

Kullanabileceğimiz "hile", gönderenlerin kimlik doğrulama durumu hakkındaki bilgileri, E-posta mesajlarının alan adımızı içerdiğini "aldığımız" bir prosedüre dayanmaktadır.

Örneğin - bizim özel örneğimizde, düşman unsur kendisini gösteren E-posta adresini - John@o365info.com (sahte kimlik) kullanıyor.

John, Exchange posta kutusu vb. olan "gerçek" bir Exchange alıcısıdır.

-o365info.com alan adını yetkili olarak kabul eden Exchange posta sunucusu, gönderenin kullanıcı kimlik bilgilerini sağlamasını beklemektedir. Bu, meşru bir alıcının Exchange posta kutusunda saklanan özel verilerine erişmek için kullandığı "doğru" yoldur.

Senaryomuzda öğe, John'un kimlik bilgilerine sahip olmayan (kullanıcı adı + şifre) düşmanca bir öğedir.

Bu nedenle kimlik doğrulama durumu - Anonimdir ancak aynı zamanda “John” E-posta adresini kullanır.

Bu, bunun sahte bir gönderen (Sahte posta) olduğuna dair işaretimizdir.

Exchange sunucusuna, gönderenin kimlik doğrulama durumunun anonim olduğu ve gönderenin E-posta adresinin alan adımızı içerdiği Sahte posta olaylarını tanımlamak istediğimizi "söyleyebilmek"; bu tür olayları izleyecek ve böyle bir olayı tanımladığında “bir şeyler yapacak” bir Exchange kuralı oluşturabiliriz.

Bu seçeneğin yalnızca Exchange posta altyapısını kullanan kuruluşlar için mevcut olduğunu ve bunun resmi veya genel bir standart olmadığını vurgulamak önemlidir. Bunun yerine, Spoof posta kesinti mekanizması olarak veya SPF gibi mevcut posta gönderen doğrulama standardının uygulanması için ek bir katman olarak lehimize kullanabileceğimiz bir "hile".

Değişim kuralı | E-posta iletisinin Sahte E-posta olarak sınıflandırıldığı senaryo

"Sahte posta" olayı, aynı anda gerçekleşmesi gereken iki koşulun birleşimiyle açıklanacak.

Gönderenin, kuruluşun etki alanı adını içeren ve anonim gönderen (kullanıcı kimlik bilgilerini sağlamayan gönderen) olarak kabul edilen bir E-posta adresi kullanması gerekir.

Exchange Online bizi Sahte E-posta senaryosundan nasıl koruyor?

Kimlik Avı Filtresi (ve Kimlik Avı Filtresi Politikası) özelliği, Office 365 müşterileri anlamına gelen Exchange Online müşterileri için kullanılabilen nispeten yeni bir özelliktir.

Kimlik Avı Filtresi seçeneği bir EOP (Exchange Çevrimiçi Koruma) özelliğidir. Office 365 tabanlı ortamda EOP, “posta güvenlik ağ geçidi” görevi görür.

Kimlik Avı Filtresinin amacı, Office 365 müşterilerinin, saldırganın iki farklı kimlik (MAIL FROM alanında görünen gönderen kimliği) sağladığı tipik bir Sahte posta senaryosunu algılamasını sağlamaktır. posta zarfı) + FROM alanında (posta başlığı) görüntülenen gönderenin kimliği.

Düşman unsurların SPF gibi mevcut gönderen doğrulama mekanizmalarını atlamak için kullandığı bu yöntem hakkında daha fazla bilgi almak istiyorsanız, düşman unsur Sahte E-posta saldırısını nasıl gerçekleştirebilir ve mevcut SPF uygulamasını nasıl atlayabilir? başlıklı makaleyi okuyabilirsiniz. | giriş | 1#2.

Kimlik Avı Filtresi, çok basit bir doğrulama testine dayanarak bir Sahte posta olayını algılar:

Bir gönderen, Exchange Online posta sunucusuna (daha doğru olmak istiyorsak, Exchange Online Koruması) hitap ettiğinde ve iki grup gönderen kimliği kullandığında, Exchange çevrimiçi Kimlik Avı Filtresi Politikası, gönderen bilgilerinin dosyasında olup olmadığını doğrular. MAIL FROM alanı, FROM posta dosyasındaki gönderenin kimliğiyle aynıdır.

Kimliklerin farklı olması durumunda bu, ilgili E-posta mesajında bir şeylerin "yanlış" olduğunun işaretidir.

Exchange Çevrimiçi Kimlik Avı Filtresi Politikası | E-posta iletisinin Sahte E-posta olarak sınıflandırıldığı senaryo

"Sahte posta" olayı şu şekilde tanımlanacaktır: MAIL FROM alanında geciken E-posta adresinin "hizalanmamış" olduğu, yani gönderilen E-posta adresinden farklı olduğu bir sahne. FROM alanında görünür.

Bu durumda E-posta Yüksek Riskli E-posta mesajı olarak değerlendirilecek ve orijinal E-posta mesajına bir uyarı bildirimi eklenecektir.

DMARC bizi Sahte E-posta senaryosundan nasıl korur?

DMARC standardı özel bir standarttır çünkü gönderen doğrulamasını uygulamaya yönelik bir "Bağımsız mekanizma" veya protokol içermez, bunun yerine başka bir gönderen kimlik doğrulama protokolüne (SPF ve DKIM) dayanır.

DMARC standardının gönderen doğrulama sürecine ilişkin “işi”

Belirli bir E-posta mesajının gönderen doğrulama standartlarından biri olan SPF veya DKIM tarafından doğrulanıp doğrulanmadığını kontrol etmek için.
Doğrulama testi sonucunun başarılı veya başarısız olup olmadığını kontrol etmek için.
Hizalama olarak tanımlanan ek bir gönderen doğrulama katmanını uygulamak.

Bu gönderen kimlik doğrulama protokollerinden birini kullanmamız durumunda DKIM, bu protokollerin her biri tarafından uygulanan doğrulama sürecini "genişletir".

Başka bir deyişle DMARC, gönderen doğrulama standardı olan SPF veya DKIM'ye kıyasla daha "daha sıkı gönderen doğrulama testleri" gerçekleştiriyor.

DMARC tarafından gönderen doğrulamasının "ek katmanını" tanımlamak için kullanılan ve hizalama olarak tanımlanan teknik terim.

Örneğin, SPF veya DKIM kullanmamız durumunda, DMARC açısından bakıldığında, SPF veya DKIM doğrulama testinin başarılı olması yeterli değildir, aynı zamanda başarılı bir şekilde uygulanması gereken DMARC "dictate" ek koşulunun da başarılı olması gerekir.

DMARC standardı ve SPF hizalaması

Posta altyapımızın gönderen doğrulamasını uygulamak için SPF standardını kullandığı bir senaryoda, gelen postaların her biri SPF doğrulama testi tarafından başarısız olarak "damgalanacaktır". veya geçti.

Not: Gerçekte, SPF standardı ek durum kodu içerir, ancak şu anda açıklamayı basitleştirmek istiyoruz. Bu nedenle yalnızca başarısız veya geçti durum kodunu ilişkilendireceğiz.

DMARC standardını kullandığımızda, DMARC tarafından gerçekleştirilecek ilk test SPF durumunun başarısız veya geçti olup olmadığını doğrulamaktır. .

SPF durumunun geçti olması durumunda DMARC, DMARC'nin gerekli “SPF hizalamasını doğruladığı bir sonraki teste devam edecektir. ”

SPF hizalama testi, gönderenin MAIL FROM alanında görünen E-posta adresinin (posta zarfında görüntülenen bilgi) gönderilen E-posta adresiyle aynı olup olmadığı kontrol edilerek uygulanır. FROM alanında gösterilir (posta başlığında görünen bilgiler).

Durum 1 - DMARC SPF hizalama testi başarılı

Aşağıdaki şemada E-posta mesajının 2 gönderen kimliğini içerdiği bir örneği görebiliriz. Örneğimizde, MAIL FROM alanında görünen gönderenin kimliği, FROM alanında görüntülenen gönderen kimliğiyle aynıdır.

Bu durumda, SPF hizalama testi başarıyla tamamlandı ve DMARC
E-posta iletisine durum kodunu (dmarc=pass) damgaladı.

Durum 2 - DMARC SPF hizalama testi başarısız

Aşağıdaki şemada, E-posta mesajının 2 gönderen kimliğini içerdiği bir örneği görebiliriz. Örneğimizde, MAIL FROM'da görünen gönderen kimliği, FROM alanında görüntülenen gönderen kimliğinden farklıdır.

Bu durumda, SPF hizalama testi başarıyla tamamlanmadı ve DMARC
E-posta iletisine durum kodunu (dmarc=fail) damgaladı.

DMARC standardı ve DKIM hizalaması

Posta altyapımızın gönderen doğrulamasını uygulamak için DKIM standardını kullandığı bir senaryoda, gelen postaların her biri DKIM doğrulama testi tarafından başarısız olarak "damgalanacaktır" veya geçti.

DMARC standardını kullandığımızda, DMARC tarafından gerçekleştirilecek ilk test, DKIM durumunun başarısız veya geçerli olup olmadığını doğrulamaktır. .

DKIM durumunun geçti olması durumunda DMARC, DMARC'nin gerekli "DKIM hizalamasını" doğruladığı bir sonraki teste devam edecektir.

DKIM hizalama testi, DKIM seçici alan adının, FROM alanında görünen gönderenin alan adıyla aynı olup olmadığı doğrulanarak uygulanır. alanı (posta başlığına kaydedilen bilgiler).

Durum 1 - DMARC DKIM hizalama testi başarılı

Aşağıdaki şemada E-posta mesajını imzalayan DKIM seçici adı hakkındaki bilgilerin bir örneğini görebiliriz. E-postanın bir parçası olarak kaydedilen DKIM seçici ana bilgisayar adı hakkındaki bilgiler.

Senaryomuzda, DKIM seçici adı alan adını içerir - o365info.com

FROM alanında, gönderenin E-posta adresinin aynı zamanda alan adını da kullandığını görebiliriz - o365info.com

Bu durumda, DKIM hizalama testi başarıyla tamamlanmıştır ve DMARC
E-posta iletisine durum kodunu (dmarc=pass) damgalar.

Durum 2 - DMARC DKIM hizalama testi başarısız

Senaryomuzda, DKIM seçici adı alan adını (outlook.com) içerir.