Renomowana domena lub współdzielona usługa wysyłania mogą stać się częścią ścieżki wiadomości stanowiącej nadużycie. Przydatnym pytaniem nie jest to, czy infrastruktura jest ogólnie godna zaufania. Chodzi o to, czy ta konkretna wiadomość została upoważniona do użycia uwierzytelnionej tożsamości. Uwierzytelnianie i autoryzacja biznesowa odpowiadają na różne pytania.
Zdefiniuj uprawnienia, które będą ponownie wykorzystywane
Zaatakowana skrzynka pocztowa może wysyłać zwykłą uwierzytelnioną trasą. Zbyt szeroka autoryzacja sieciowa może pozwolić na niezamierzone źródło. Przekaźnik może podpisać wiadomość po jej przyjęciu zgodnie z niedostatecznie sprecyzowaną regułą przyjęcia. Mechanizmy te mają różnych właścicieli i środki zaradcze. Nie należy łączyć ich w jedno niewyjaśnione twierdzenie o przejęciu reputacji.
Oryginalne badanie BreakSPF bada permisywność SPF konfiguracji i współdzielonej infrastruktury. Jego model zagrożeń sprawia, że dostęp do sieci źródłowej jest warunkiem centralnym. Jest to granica wdrożenia, a nie dowód na to, że osoba atakująca może ją sfałszować Podpis DKIM. Dokument BreakSPF, Sekcja III. Traktuj pomiary zawarte w artykule jako badania historyczne, a nie obecny wykaz wrażliwych usług.
Zbuduj precyzyjny model zagrożenia
Zapisz oddzielnie chronioną domenę, uwierzytelniony identyfikator, dozwolony zestaw źródeł, możliwości atakującego i decyzję odbiorcy. W ograniczonym scenariuszu brand.test autoryzuje 192.0.2.0/24 dla SPF . Zatwierdzona aplikacja używa 192.0.2.10 , podczas gdy hipotetyczny niezamierzony dzierżawca może pochodzić z 192.0.2.99 . Obydwa adresy mieszczą się w opublikowanym zakresie. To, czy taki dostęp najemcy istnieje w rzeczywistej usłudze, wymaga odrębnego dowodu.
SPF sprawdza autoryzację źródła pod kątem ocenianej tożsamości. Nie identyfikuje człowieka stojącego za wspólnym adresem IP. Jeśli przekazywana tożsamość SPF jest również zgodna z domeną autora, ścieżka ta może spełnić wymagania DMARC bez DKIM. RFC 7208 I RFC 9989. Pomyślna ocena może zatem ujawnić, że przyznano zbyt duże uprawnienia, a nie zignorowanie przez odbiorcę reguły pozytywnej.
Porównaj trzy przypadki pisemnego upoważnienia
Załóżmy, że widoczny z alerts@brand.test , niepusty POCZTA OD bounce@brand.test , brak podpisu DKIM i kwalifikująca się ocena DMARC w inny sposób. Porównaj hipotetycznie Rekordy SPF v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- Zatwierdzone źródło 192.0.2.10 : uwzględnione w obu prefiksach sieciowych; SPF przechodzi pomyślnie i jest zgodny z brand.test, więc ilustracyjny komunikat przechodzi w obu przypadkach DMARC .
- Niezamierzone źródło 192.0.2.99 : uwzględnione w /24, ale nie w /32; SPF przechodzi tylko pod szerokim rekordem. W przypadku braku podpisu DKIM przewidywanym wynikiem DMARC jest wynik pozytywny poniżej /24 i niepowodzenie poniżej /32.
- Źródło zewnętrzne 198.51.100.10 : nie zawiera żadnego przedrostka; -all daje SPF niepowodzenie w obu przypadkach. Bez podpisu DKIM przewidywany wynik DMARC jest niepowodzeniem w obu przypadkach.
Są to zapisane członkostwo przedrostkowe i wyrównanie dedukcje, a nie działający parser SPF , obserwacja DNS lub reprodukcja BreakSPF. Zakłada się kontrolę źródła, a nie demonstruje. Nie testowano żadnych wiadomości zewnętrznych ani usług na żywo. Opisana w artykule technika stosowania różnych protokołów wykracza poza ten przykład nauczania.
Dopasowany mechanizm z pojedynczym przejściem może spełnić warunek przekazania wiadomości DMARC . Nie oznacza to, że wdrożenie wyłącznie SPF jest odpowiednie: sekcja 7.4 RFC9989 wymaga prawidłowego DKIM do publikowania domen p=reject, a sekcja 8 dotyczy pełnego uczestnictwa. Są to oddzielne obowiązki wdrożeniowe, a nie dodatkowa bramka przepustowa dla poszczególnych wiadomości.
Napraw granicę odpowiedzialną
Przed zawężeniem prawdziwego rekordu SPF przeprowadź inwentaryzację każdego legalnego nadawcy i postępuj zgodnie z konfiguracją obsługiwaną przez dostawcę. Dedykowane źródło jest przydatne tylko wtedy, gdy jest rzeczywiście ekskluzywne i utrzymywane. Potwierdź, że usługa wysyłania wiąże klientów z ich dozwoloną tożsamością; sprawdź konfigurację DKIM i usuń przestarzałe uprawnienia poprzez kontrolę zmian.
Monitoruj awarie specyficzne dla trasy po zmianie, zachowaj plan odzyskiwania i dokumentuj nieznanych nadawców. Nie zastępuj szerokiego rekordu listą zgadniętych adresów IP z tego przykładu. Lekcja jest taka, aby pogodzić autoryzację z faktyczną własnością usługi, a nie kopiować demonstracyjny DNS do środowiska produkcyjnego.