Jako organizacja platformy Microsoft 365 ze skrzynkami pocztowymi w Exchange Online lub autonomiczną organizacją Exchange Online Protection (EOP) bez Exchange Online skrzynek pocztowych ochrona integralności wiadomości e-mail od nadawców w domenach jest ważna. Adresaci powinni mieć pewność, że wiadomości od nadawców w domenie rzeczywiście pochodzą od nadawców w domenie.
uwierzytelnianie Email (nazywane również weryfikacją poczty e-mail) to grupa standardów umożliwiających identyfikowanie i zapobieganie dostarczaniu wiadomości e-mail od podrobionych nadawców (nazywanych również fałszowaniem). Sfałszowane nadawcy są często używane w przypadku naruszenia zabezpieczeń poczty e-mail (BEC), wyłudzania informacji i innych ataków e-mail. Te standardy obejmują:
Struktura zasad nadawcy (SPF): określa źródłowe serwery poczty e-mail, które są autoryzowane do wysyłania wiadomości e-mail dla domeny.
DomainKeys Identified Mail (DKIM): używa domeny do cyfrowego podpisywania ważnych elementów wiadomości, aby upewnić się, że wiadomość nie została zmieniona podczas przesyłania.
Uwierzytelnianie komunikatów oparte na domenie, Raportowanie i zgodność (DMARC): określa akcję dla komunikatów, które nie sprawdzają nadawców SPF lub DKIM w domenie, i określa, gdzie wysłać wyniki DMARC (raportowanie).
Uwierzytelniony łańcuch odebranych odebranych (ARC) : zachowuje oryginalne informacje uwierzytelniania poczty e-mail przez znane usługi, które modyfikują komunikaty podczas przesyłania. Docelowy serwer poczty e-mail może używać tych informacji do uwierzytelniania komunikatów, które w przeciwnym razie mogłyby zakończyć się niepowodzeniem DMARC.
Należy pamiętać, że standardy te są współzależnością bloków konstrukcyjnych , które współpracują ze sobą , aby zapewnić najlepszą możliwą ochronę poczty e-mail przed fałszowaniem i wyłudzaniem informacji.
Wszystko mniej niż wszystkie metody uwierzytelniania poczty e-mail powoduje ochronę niestandardową.
Aby skonfigurować uwierzytelnianie poczty e-mail dla poczty wysyłanej z organizacji platformy Microsoft 365 przy użyciu skrzynek pocztowych w Exchange Online lub autonomicznych organizacjach Exchange Online Protection (EOP) bez Exchange Online skrzynek pocztowych, zobacz następujące artykuły:
Aby zapobiec niepowodzeniom uwierzytelniania poczty e-mail z powodu usług modyfikujących pocztę przychodzącą wysyłaną do organizacji platformy Microsoft 365, zobacz Konfigurowanie zaufanych uszczelniaczy ARC.
Dlaczego internetowa poczta e-mail wymaga uwierzytelniania
Zgodnie z projektem poczta e-mail protokołu SMTP (Simple Mail Transfer Protocol) w Internecie nie podejmuje żadnych wysiłków, aby sprawdzić, czy nadawca wiadomości jest tym, za kogo się podaje.
Standardowa wiadomość e-mail SMTP składa się z koperty wiadomości i zawartości wiadomości:
Koperta wiadomości zawiera informacje dotyczące przesyłania i odbierania komunikatu między serwerami SMTP. Koperta wiadomości została opisana w dokumencie RFC 5321. Adresaci nigdy nie widzą koperty wiadomości, ponieważ jest ona generowana podczas procesu transmisji komunikatów.
Zawartość wiadomości zawiera pola nagłówka wiadomości (łącznie nazywane nagłówkiem komunikatu) i treść komunikatu. Nagłówek komunikatu jest opisany w dokumencie RFC 5322.
W związku z tym projektem komunikat ma wiele wartości nadawcy:
Adres MAIL FROM (znany również jako 5321.MailFrom adres, nadawca P1 lub nadawca koperty) to adres e-mail używany do przesyłania wiadomości między serwerami poczty e-mail SMTP. Ten adres jest zwykle rejestrowany w polu nagłówek Return-Path w nagłówku wiadomości (chociaż źródłowy serwer poczty e-mail może wyznaczyć inny adres e-mail ze ścieżką powrotną ). Ten adres e-mail jest używany w raportach o braku dostawy (nazywanych również serwerami NDR lub wiadomościami odrzuceń).
Adres Od (znany również jako 5322.From adres lub nadawca P2) jest adresem e-mail w polu Od nagłówka i jest adresem e-mail nadawcy wyświetlanym w klientach poczty e-mail.
Poniższy przykład przedstawia uproszczoną transkrypcję prawidłowej transmisji komunikatów między dwoma serwerami poczty e-mail SMTP:
S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .
W tym przykładzie:
Źródłowy serwer poczty e-mail identyfikuje się jako woodgrovebank.com do docelowego serwera poczty e-mail tailspintoys.com w poleceniu HELO.
Adresatem wiadomości jest astobes@tailspintoys.com.
Adres MAIL FROM w kopercie wiadomości (używany do przesyłania wiadomości między serwerami poczty e-mail SMTP) to dubious@proseware.com.
Adres Od wyświetlany na kliencie poczty e-mail adresata to security@woodgrovebank.com.
Mimo że ta wiadomość jest prawidłowa zgodnie z protokołem SMTP, domena adresu MAIL FROM (proseware.com) nie jest zgodna z domeną w polu Adres od (woodgrovebank.com). Ta wiadomość jest klasycznym przykładem fałszowania, w którym intencja może oszukać odbiorcę, maskując prawdziwe źródło wiadomości do użycia podczas ataku wyłudzania informacji.
Oczywiście wiadomość e-mail SMTP wymaga pomocy w sprawdzeniu, czy nadawcy wiadomości są osobami, które twierdzą, że są!
Jak SPF, DKIM i DMARC współpracują ze sobą w celu uwierzytelniania nadawców wiadomości e-mail
W tej sekcji opisano, dlaczego potrzebujesz SPF, DKIM i DMARC dla domen w Internecie.
SPF: Jak wyjaśniono w artykule Konfigurowanie SPF do identyfikowania prawidłowych źródeł poczty e-mail dla domeny usługi Microsoft 365, SPF używa rekordu TXT w systemie DNS do identyfikowania prawidłowych źródeł poczty z domeny MAIL FROM i co zrobić, jeśli docelowy serwer poczty e-mail odbiera wiadomość e-mail z niezdefiniowanego źródła ("trudne niepowodzenie" odrzucenia wiadomości; "Nietrwałe niepowodzenie" w celu zaakceptowania i oznaczenia komunikatu).
Problemy z filtrem SPF:
SPF weryfikuje źródła dla nadawców tylko w domenie MAIL FROM. SPF nie uwzględnia domeny w domenie Adres od lub wyrównanie między domenami MAIL FROM i From:
Osoba atakująca może wysłać wiadomość e-mail, która przekazuje uwierzytelnianie SPF (fałszywie ujemne), wykonując następujące kroki:
Zarejestruj domenę (na przykład proseware.com) i skonfiguruj SPF dla domeny.
Wyślij wiadomość e-mail z prawidłowego źródła dla zarejestrowanej domeny z adresami e-mail z innej domeny (na przykład woodgrovebank.com).
Legalna usługa poczty e-mail, która wysyła wiadomość e-mail w imieniu innych domen, może kontrolować adres MAIL FROM. Inne domeny i domena MAIL FROM nie są zgodne, więc komunikaty nie mogą przekazać uwierzytelniania SPF (wynik fałszywie dodatni).
SPF przerywa działanie po napotkaniu komunikatów opartych na serwerze przekazywania wiadomości e-mail, które przekierowuje lub przekazuje komunikaty .
Przekazywanie wiadomości e-mail na podstawie serwera powoduje zmianę źródła wiadomości z oryginalnego serwera na serwer przesyłania dalej.
Serwer przesyłania dalej nie jest autoryzowany do wysyłania wiadomości e-mail z oryginalnej domeny MAIL FROM, więc wiadomość nie może przekazać uwierzytelniania SPF (wynik fałszywie dodatni).
Każda domena i wszystkie poddomeny wymagają własnych indywidualnych rekordów SPF. Domeny podrzędne nie dziedziczą rekordu SPF domeny nadrzędnej. Takie zachowanie staje się problematyczne, jeśli chcesz zezwolić na pocztę e-mail ze zdefiniowanych i używanych poddomen, ale zapobiegaj niezdefiniowanym i nieużywanym domenom podrzędnym poczty e-mail.
Jak program DKIM pomaga SPF: DKIM może weryfikować komunikaty, które nie spełniają SPF. Przykład:
Wiadomości z usługi hostingu poczty e-mail, w której ten sam adres MAIL FROM jest używany do obsługi poczty z innych domen.
Komunikaty, które napotykają przekazywanie wiadomości e-mail na podstawie serwera.
Ponieważ sygnatura DKIM w nagłówku komunikatu nie ma wpływu ani nie zmienia się w tych scenariuszach, te komunikaty mogą przekazywać moduł DKIM.
Problemy z modułem DKIM: domena używana przez program DKIM do podpisywania komunikatu nie musi być zgodna z domeną w polu Adres od wyświetlanym na klientach poczty e-mail.
Podobnie jak SPF, osoba atakująca może wysłać wiadomość e-mail, która przekazuje uwierzytelnianie DKIM (fałszywie ujemne), wykonując następujące kroki:
Zarejestruj domenę (na przykład proseware.com) i skonfiguruj program DKIM dla domeny.
Wyślij wiadomość e-mail z adresami e-mail z innej domeny (na przykład woodgrovebank.com).
DMARC: Jak wyjaśniono w artykule Konfigurowanie usługi DMARC w celu zweryfikowania domeny Z adresu dla nadawców w usłudze Microsoft 365, usługa DMARC używa SPF i DKIM do sprawdzania zgodności między domenami w adresach MAIL FROM i From. DMARC określa również akcję, którą docelowy system poczty e-mail powinien podjąć w przypadku komunikatów, które nie spełniają funkcji DMARC, i określa, gdzie wysyłać wyniki DMARC (zarówno przebieg, jak i niepowodzenie).
Jak usługa DMARC pomaga SPF i DKIM: Zgodnie z wcześniejszym opisem, SPF nie podejmuje próby dopasowania domeny w domenie MAIL FROM i adresach z. Program DKIM nie ma znaczenia, czy domena, która podpisała komunikat, jest zgodna z domeną w polu Adres od.
Usługa DMARC rozwiązuje te braki przy użyciu SPF i DKIM, aby potwierdzić, że domeny w adresach MAIL FROM i From są zgodne.
Problemy z usługą DMARC: uzasadnione usługi, które modyfikują komunikaty przesyłane przed przerwą dostarczania SPF, DKIM, a zatem sprawdzają DMARC.
ARC: Jak wyjaśniono w artykule Konfigurowanie zaufanych uszczelniaczy ARC, uzasadnione usługi, które modyfikują komunikaty przesyłane, mogą używać usługi ARC do zachowania oryginalnych informacji uwierzytelniania poczty e-mail zmodyfikowanych komunikatów.
Jak usługa ARC pomaga DMARC: docelowy system poczty e-mail może zidentyfikować usługę jako zaufany uszczelniacz ARC. Usługa ARC może następnie użyć zachowanych informacji uwierzytelniania poczty e-mail do zweryfikowania komunikatu.
Uwierzytelnianie przychodzące poczty e-mail dla poczty wysłanej na platformę Microsoft 365
Ze względu na problemy z wyłudzaniem informacji i mniej niż całkowite wdrożenie silnych zasad uwierzytelniania poczty e-mail przez nadawców poczty e-mail w Internecie, platforma Microsoft 365 używa niejawnego uwierzytelniania poczty e-mail do sprawdzania przychodzącej poczty e-mail. Niejawne uwierzytelnianie poczty e-mail rozszerza regularne kontrole SPF, DKIM i DMARC przy użyciu sygnałów z innych źródeł w celu oceny przychodzącej poczty e-mail. Te źródła obejmują:
Korzystając z tych innych sygnałów, wiadomości, które w przeciwnym razie nie będą sprawdzać tradycyjnego uwierzytelniania poczty e-mail, mogą przekazywać uwierzytelnianie niejawne i być dozwolone na platformie Microsoft 365.
Uwierzytelnianie złożone
Wyniki niejawnych testów uwierzytelniania platformy Microsoft 365 są łączone i przechowywane w pojedynczej wartości o nazwie uwierzytelnianie złożone lub compauth w skrócie. Wartość compauth jest ostemplowana w nagłówku Authentication-Results w nagłówkach wiadomości. Nagłówek Authentication-Results używa następującej składni:
Administratorzy i użytkownicy mogą sprawdzać nagłówki komunikatów, aby dowiedzieć się, w jaki sposób usługa Microsoft 365 zidentyfikowała nadawcę jako podejrzanego, sfałszowanego nadawcę lub zgodnego z prawem.
Napiwek
Ważne jest, aby zrozumieć, że niepowodzenie uwierzytelniania złożonego nie powoduje bezpośrednio zablokowania komunikatu. Nasz system korzysta z całościowej strategii oceny, która uwzględnia ogólny podejrzany charakter komunikatu wraz z wynikami uwierzytelniania złożonego. Ta metoda ma na celu ograniczenie ryzyka nieprawidłowego zablokowania legalnej poczty e-mail z domen, które mogą nie być ściśle zgodne z protokołami uwierzytelniania poczty e-mail. To zrównoważone podejście pomaga odróżnić prawdziwie złośliwe wiadomości e-mail od nadawców wiadomości, które po prostu nie są zgodne ze standardowymi praktykami uwierzytelniania poczty e-mail.
W poniższych przykładach skupiono się tylko na wynikach uwierzytelniania poczty e-mail (wartość i przyczyna compauth ). Inne technologie ochrony platformy Microsoft 365 mogą identyfikować komunikaty, które przekazują uwierzytelnianie poczty e-mail jako sfałszowane, lub identyfikować wiadomości, które nie uwierzytelniania poczty e-mail są uzasadnione.
Scenariusz: Domena w rekordzie SPF lub podpis DKIM nie jest zgodna z domeną w polu Adres od.
Wynik: Komunikat może zakończyć się niepowodzeniem uwierzytelniania złożonego. Pomimo niepowodzenia uwierzytelniania złożonego komunikat może nadal być dozwolony, jeśli inne oceny nie wskazują podejrzanego charakteru:
Authentication-Results: spf=none (sender IP is 192.168.1.8)
smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
(signature was verified) header.d=maliciousdomain.com;
contoso.com; dmarc=none action=none header.from=contoso.com;
compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com
Scenariusz: domena fabrikam.com nie ma rekordów SPF, DKIM ani DMARC.
Wynik: Komunikaty od nadawców w domenie fabrikam.com mogą zakończyć się niepowodzeniem uwierzytelniania złożonego:
Authentication-Results: spf=none (sender IP is 10.2.3.4)
smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
(message not signed) header.d=none; contoso.com; dmarc=none
action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com
Scenariusz: domena fabrikam.com ma rekord SPF i nie ma rekordu DKIM. Domeny w adresach MAIL FROM i From są zgodne.
Wynik: Komunikat może przekazać uwierzytelnianie złożone, ponieważ domena, która przekazała SPF, jest zgodna z domeną w adresie From:
Authentication-Results: spf=pass (sender IP is 10.2.3.4)
smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
(message not signed) header.d=none; contoso.com; dmarc=bestguesspass
action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com
Scenariusz: domena fabrikam.com ma rekord DKIM bez rekordu SPF. Domena podpisana przez program DKIM wiadomość jest zgodna z domeną w polu Adres od.
Wynik: komunikat może przekazać uwierzytelnianie złożone, ponieważ domena w sygnaturze DKIM jest zgodna z domeną w adresie Od:
Authentication-Results: spf=none (sender IP is 10.2.3.4)
smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
(signature was verified) header.d=outbound.fabrikam.com;
contoso.com; dmarc=bestguesspass action=none
header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com
Scenariusz: Domena w rekordzie SPF lub podpis DKIM nie jest zgodna z domeną w polu Adres od.
Wynik: Komunikat może zakończyć się niepowodzeniem uwierzytelniania złożonego:
Authentication-Results: spf=none (sender IP is 192.168.1.8)
smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
(signature was verified) header.d=maliciousdomain.com;
contoso.com; dmarc=none action=none header.from=contoso.com;
compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com
Jak uniknąć błędów uwierzytelniania poczty e-mail podczas wysyłania wiadomości e-mail na platformę Microsoft 365
Napiwek
Klienci platformy Microsoft 365 mogą używać następujących metod, aby zezwalać na komunikaty od nadawców, które są identyfikowane jako błędy fałszowania lub uwierzytelniania:
Skonfiguruj rekordy SPF, DKIM i DMARC dla domen: użyj informacji o konfiguracji dostarczonych przez rejestratora domen lub usługę hostingu DNS. Istnieją również firmy innych firm, które pomagają w konfigurowaniu rekordów uwierzytelniania poczty e-mail.
Wiele firm nie publikuje rekordów SPF, ponieważ nie zna wszystkich źródeł wiadomości e-mail dla wiadomości w swojej domenie.
Rozpocznij od opublikowania rekordu SPF zawierającego wszystkie znane źródła poczty e-mail (zwłaszcza w przypadku lokalizacji ruchu firmowego) i użyj wartości reguły wymuszania "błąd miękki" (~all). Przykład:
fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"
Jeśli utworzysz ten rekord SPF, platforma Microsoft 365 traktuje przychodzącą pocztę e-mail z infrastruktury firmowej jako uwierzytelnioną, ale wiadomości e-mail z niezidentyfikowanych źródeł mogą nadal być oznaczone jako fałszywe, jeśli nie powiedzie się uwierzytelnianie złożone. Jednak to zachowanie jest nadal ulepszeniem od wszystkich wiadomości e-mail od nadawców w domenie oznaczonej jako fałszowanie przez platformę Microsoft 365. Zazwyczaj docelowy system poczty e-mail akceptuje komunikaty od nadawców w domenie z niezidentyfikowanych źródeł, gdy SPF jest skonfigurowany z regułą wymuszania nietrwałego błędu.
Odnajdywanie i dołączanie większej liczby źródeł wiadomości e-mail. Przykład:
Lokalne serwery poczty e-mail.
Email wysyłane od dostawcy oprogramowania jako usługi (SaaS).
Email wysyłane z usługi hostingu w chmurze (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services itp.).
Po zidentyfikowaniu wszystkich źródeł wiadomości e-mail dla domeny możesz zaktualizować rekord SPF, aby użyć wartości reguły wymuszania "hard fail" (-all).
Skonfiguruj infrastrukturę DKIM do cyfrowego podpisywania komunikatów.
Skonfiguruj usługę DMARC, aby sprawdzić, czy domeny w adresach MAIL FROM i From są zgodne, aby określić, co zrobić z komunikatami, które nie sprawdzają DMARC (odrzucają lub poddają kwarantannie) oraz identyfikować usługi raportowania w celu monitorowania wyników DMARC.
Jeśli używasz nadawców zbiorczych do wysyłania wiadomości e-mail w Twoim imieniu, sprawdź, czy domena w adresie Od jest zgodna z domeną, która przekazuje protokół SPF lub DMARC.
Hostujesz adres e-mail domeny lub udostępniasz infrastrukturę hostingu, która może wysyłać wiadomości e-mail:
Upewnij się, że klienci mają dokumentację wyjaśniającą, jak skonfigurować SPF dla swoich domen.
Rozważ podpisanie przez DKIM poczty wychodzącej DKIM, nawet jeśli klient nie jawnie skonfigurował modułu DKIM w swojej domenie (zaloguj się przy użyciu domeny domyślnej). Możesz nawet dwukrotnie podpisać wiadomość e-mail przy użyciu podpisów DKIM (z domeną firmową i domeną klienta, jeśli/kiedy jest dostępna).
Dostarczanie do firmy Microsoft nie jest gwarantowane, nawet jeśli uwierzytelniasz wiadomość e-mail pochodzącą z platformy. Jednak uwierzytelnianie poczty e-mail gwarantuje, że firma Microsoft nie wysyła automatycznie wiadomości e-mail ze swoich domen klientów tylko dlatego, że nie jest uwierzytelniona.
This module examines how Microsoft Defender for Office 365 extends EOP protection through various tools, including Safe Attachments, Safe Links, spoofed intelligence, spam filtering policies, and the Tenant Allow/Block List.
Dowiedz się, jak skonfigurować oparte na domenie uwierzytelnianie komunikatów, raportowanie i zgodność (DMARC) w celu weryfikowania komunikatów wysyłanych z organizacji.
Dowiedz się, jak platforma Microsoft 365 używa funkcji DomainKeys Identified Mail (DKIM) do wylogowywania poczty wychodzącej oraz jak skonfigurować podpisywanie poczty wychodzącej przez program DKIM przy użyciu domen niestandardowych.
Uwierzytelniony łańcuch odebranych (ARC) to metoda uwierzytelniania poczty e-mail, która próbuje zachować wyniki uwierzytelniania na różnych urządzeniach i wszelkie modyfikacje komunikatów, które występują między nadawcą a odbiorcą.
Administratorzy mogą dowiedzieć się więcej o funkcjach ochrony przed fałszowaniem dostępnych w Exchange Online Protection (EOP), które mogą pomóc w wyeliminowaniu ataków phishingowych ze strony sfałszowanych nadawców i domen.