SPF +all to najniebezpieczniejsze ustawienie poczty: oto dlaczego

Jeśli Twój rekord SPF kończy się na +all, powiedziałeś każdemu serwerowi pocztowemu na świecie, że dowolny adres IP jest uprawniony do wysyłania poczty z Twojej domeny. To nie jest luka ani przypadek brzegowy. To jawna, opublikowana instrukcja, która zamienia SPF z obrony przed podszywaniem w zaproszenie do podszywania. Ze wszystkich sposobów na błędne skonfigurowanie uwierzytelniania poczty, +all jest najbardziej szkodliwym, bo robi dokładnie odwrotność tego, do czego SPF został stworzony.

Poniżej znajdziesz dokładne wyjaśnienie, czym steruje mechanizm "all", dlaczego +all jest w praktyce tak niebezpieczny oraz jak bezpiecznie przejść z rekordu zbyt pobłażliwego na twarde odrzucenie, nie blokując przy tym własnej prawidłowej poczty.

Co naprawdę robi mechanizm "all"

Rekord SPF to lista mechanizmów, które serwer odbiorczy ocenia od lewej do prawej względem adresu IP, który się z nim połączył. Każdy mechanizm może nieść ze sobą kwalifikator, który decyduje o wyniku w razie dopasowania. Mechanizm all stoi na końcu i zawsze pasuje, więc jest werdyktem obejmującym wszystkich nadawców, którzy nie dopasowali się do wcześniejszej reguły, takiej jak ip4, include, a czy mx.

W RFC 7208 zdefiniowano cztery kwalifikatory:

• + Pass. Nadawca jest uprawniony.
• - Fail, zwane też hardfail. Nadawca nie jest uprawniony, a wiadomość powinna zostać odrzucona.
• ~ SoftFail. Nadawca prawdopodobnie nie jest uprawniony, przyjmij, ale oznacz.
• ? Neutral. Brak deklaracji, traktuj tak, jakby polityki nie było.

Kwalifikator jest opcjonalny i przy pominięciu domyślnie przyjmuje wartość +, dlatego +all i samo all znaczą to samo. Ponieważ all pasuje do każdego pozostałego IP, kwalifikator, który do niego dołączysz, decyduje o losie każdego nadawcy, którego nie wymieniłeś wprost. +all mówi "przepuść wszystkich".

Dlaczego +all w praktyce zaprasza każdego do podszywania się pod Ciebie

Odczytaj +all tak, jak czyta go serwer pocztowy odbiorcy. Przychodzi wiadomość podająca się za billing@twojadomena.com. Serwer pobiera Twój rekord SPF, przechodzi przez mechanizmy, nie znajduje dopasowania dla wysyłającego IP, po czym dociera do all z kwalifikatorem + i zwraca wynik SPF Pass. Sfałszowana wiadomość przechodzi SPF. Przyszła z serwera atakującego w centrum danych, o którym nigdy nie słyszałeś, a Twój własny DNS właśnie za nią poręczył.

Oto rekord, który tak działa:

v=spf1 include:_spf.google.com +all

Fragment include:_spf.google.com wygląda uspokajająco, ale +all po nim czyni ten include bezużytecznym. Każde IP, które nie należy do Google, i tak dostaje Pass. Opublikowałeś politykę, która autoryzuje cały internet.

Ma to znaczenie wykraczające poza sam SPF, ze względu na sposób działania DMARC. DMARC (RFC 7489) przechodzi, gdy przejdzie SPF lub DKIM i wynik jest zgodny z widoczną domeną w polu From. Przy +all SPF przejdzie dla sfałszowanej wiadomości na zgodnej domenie, co może dać phisherowi zaliczenie DMARC, na które nigdy nie powinien zasłużyć. Stos uwierzytelniania, który ma powstrzymywać podszywanie się pod domenę, zamiast tego je poświadcza. Jeśli chcesz pełniejszego obrazu tego, jak te trzy rekordy współdziałają, zobacz SPF, DKIM i DMARC wyjaśnione.

Skutki w prawdziwym świecie

Szkody nie są teoretyczne. Gdy Twoja domena przechodzi uwierzytelnianie dla każdego, atakujący wykorzystują ją do wysyłania oszustw na fałszywe faktury, phishingu poświadczeń i wiadomości przekierowujących wypłaty, które prześlizgują się przez filtry, bo uwierzytelniają się bez zarzutu. Twoi klienci i pracownicy widzą prawdziwą domenę z zielonym znacznikiem uwierzytelnienia.

Koszt reputacyjny spada na Ciebie. Dostawcy skrzynek wiążą reputację nadawcy z uwierzytelnioną domeną. Kampania podszywania się, która uwierzytelnia się jako Ty, generuje skargi na spam, wpisy na listy blokujące i pogorszenie dostarczalności wobec Twojej domeny, a nie domeny atakującego. Naprawianie tego po fakcie jest znacznie droższe niż niepublikowanie +all w pierwszej kolejności. To jeden z cichszych powodów, dla których prawidłowa poczta zaczyna lądować w spamie, co omawiamy w artykule dlaczego e-maile trafiają do spamu.

-all vs ~all vs ?all: koniec z pomyłkami

Tutaj psuje się większość rekordów SPF, zwykle z ostrożności, a nie z niedbalstwa. Ludzie boją się, że rygorystyczny rekord odbije ich własną pocztę, więc łagodzą zakończenie. Oto co naprawdę oznacza każdy wybór po stronie odbiorcy.

-all (hardfail): właściwa odpowiedź dla większości domen

-all mówi odbiorcom, aby odrzucali pocztę z każdego IP, którego nie autoryzowałeś. To ustawienie, którym SPF miał się kończyć zgodnie z założeniem. Jest jednoznaczne, daje DMARC coś realnego do egzekwowania i jest tym, czego chcesz, gdy masz pewność, że Twój rekord wymienia każde prawidłowe źródło.

v=spf1 include:_spf.google.com include:sendgrid.net -all

~all (softfail): stan przejściowy, a nie cel

~all mówi odbiorcom, że nadawca prawdopodobnie nie jest uprawniony, ale mimo to należy przyjąć wiadomość, zwykle kierując ją do spamu lub oznaczając. Softfail istnieje w jednym uczciwym celu: jako okres przejściowy, w którym potwierdzasz, że nie pominąłeś żadnego źródła wysyłki. Można bezpiecznie pozostać w softfail przez kilka tygodni. Błędem jest zostawić w nim domenę na zawsze, bo softfail nadal pozwala dostarczać sfałszowaną pocztę.

?all (neutral): niemal nigdy nie jest tym, czego chcesz

?all nie zawiera żadnej deklaracji. Funkcjonalnie jest bliskie brakowi polityki dla niedopasowanych nadawców. Jest bardzo mało powodów, by publikować je celowo. Jeśli je zobaczysz, potraktuj to jako niedokończony rekord.

+all (pass): nigdy, na żadnej prawdziwej domenie

Nie istnieje żadna uzasadniona konfiguracja, w której chcesz, by obcy przechodzili SPF jako Ty. Jedyny raz, gdy +all pojawia się celowo, to domena świadomie otwarta do testów, ale i wtedy jest to zły nawyk. Na domenie produkcyjnej to usterka do naprawienia jeszcze dziś.

Bezpieczne przejście z softfail na hardfail

Celem jest -all bez zepsucia własnej poczty. Pośpieszne przejście prosto do hardfail, zanim zinwentaryzujesz swoich nadawców, to właśnie powód, dla którego ludzie ze strachu uciekali do +all. Zrób to po kolei.

1. Zinwentaryzuj każdego prawidłowego nadawcę. Twoją platformę pocztową (Google Workspace, Microsoft 365), wszelkie narzędzia marketingowe, CRM, helpdesk, fakturowanie oraz serwery aplikacji. Każdy z nich potrzebuje mechanizmu include, ip4 lub a w Twoim rekordzie.

2. Opublikuj najpierw z ~all. Zbuduj kompletny rekord kończący się softfail, aby nic się nie odbijało, gdy weryfikujesz. Wypatruj każdego prawidłowego źródła, które nie jest jeszcze objęte.

3. Potwierdź liczbę zapytań DNS. SPF jest ograniczony do 10 mechanizmów rozwiązujących DNS zgodnie z RFC 7208. Przekroczenie tego powoduje PermError, który może unieważnić cały rekord, więc konsoliduj, jeśli jesteś blisko limitu. Zobacz jak naprawić zbyt wiele zapytań DNS w SPF, jeśli na to trafisz.

4. Przełącz na -all. Gdy poobserwujesz softfail przez tydzień lub dwa bez niespodzianek, zmień zakończenie na hardfail. Twój finalny rekord powinien wyglądać tak:

v=spf1 include:_spf.google.com include:sendgrid.net -all

1. Zweryfikuj, że zmiana jest aktywna. Przepuść swoją domenę przez

powyżej, aby potwierdzić, że rekord się rozwiązuje, liczba zapytań jest poniżej 10, a kwalifikator to hardfail. Połącz to z polityką DMARC, żeby zgodność była faktycznie egzekwowana, co przechodzimy krok po kroku w artykule jak skonfigurować DMARC.

Pamiętaj, że sam SPF nie powstrzymuje całego podszywania i psuje się przy przekierowaniach poczty, dlatego właśnie DMARC opiera się także na DKIM. Jeśli jeszcze nie skonfigurowałeś DKIM, jak skonfigurować DKIM to kolejny krok po uporządkowaniu rekordu SPF.

Najczęściej zadawane pytania

Czy +all to to samo, co brak rekordu SPF?

Jest gorsze. Brak rekordu SPF oznacza, że odbiorcy nie mają żadnej deklaracji, na której mogliby działać, więc polityka DMARC wraca do zgodności DKIM. Rekord +all składa aktywną, pozytywną deklarację, że nieautoryzowani nadawcy powinni dostać Pass, co może wywołać fałszywe zaliczenie SPF, a przy zgodności także zaliczenie DMARC dla sfałszowanej poczty. Brak rekordu jest neutralny. +all jest jednoznacznie szkodliwe.

Powinienem użyć -all czy ~all na mojej domenie?

Użyj -all, gdy masz pewność, że Twój rekord wymienia każde prawidłowe źródło wysyłki. Użyj ~all tylko jako krótkiego przejścia, gdy weryfikujesz, a następnie przejdź na hardfail. Pozostawienie domeny na softfail na stałe oznacza, że sfałszowana poczta nadal jest dostarczana, co przekreśla większość sensu.

Czy -all spowoduje odbicie moich prawdziwych e-maili?

Tylko jeśli w rekordzie brakuje prawidłowego nadawcy. Dlatego właśnie inwentaryzujesz każde źródło i najpierw siedzisz w ~all. Gdy każda platforma, z której wysyłasz, jest objęta mechanizmem include, ip4, a lub mx, -all odrzuca wyłącznie pocztę, której nigdy nie autoryzowałeś.

Czy DKIM chroni mnie nawet jeśli mój SPF to +all?

DKIM pomaga, ale nie znosi ryzyka. Prawidłowy podpis DKIM sam w sobie może pozwolić wiadomości przejść DMARC, co jest dobre. Problem w tym, że +all niezależnie rozdaje zaliczenia SPF, a każdy odbiorca oceniający SPF w izolacji lub każdy system ufający wynikom SPF zostaje wprowadzony w błąd. Napraw rekord SPF niezależnie od konfiguracji DKIM.