[ SPF ]

SPF ip4 i ip6: dokładna autoryzacja adresów i zakresów

Autoryzuj rzeczywiste adresy wychodzące bez przypadkowego udzielania całej sieci większych uprawnień, niż jest to potrzebne.

Przez zespół badawczy EmailAuth · 4 minuty czytania

[Kluczowe punkty]

  • Używaj obserwowanych adresów wychodzących i uzasadnionego zasięgu sieci.
  • Sprawdź zarówno rodziny adresów, jak i trasy przełączania awaryjnego.
  • Porównaj dokładny zestaw uprawnień przed i po zmianie.
Na tej stronie

IP4 i ip6 SPF mechanizmy porównują adres łączący z adresem opublikowanym lub CIDR sieć. Są one proste, jeśli kontrolujesz stabilne serwery wychodzące, ale mały błąd prefiksu może udzielić pozwolenia na znacznie większą infrastrukturę niż zamierzono.

Użyj adresu, który faktycznie widzi odbiorca. Adres prywatnego interfejsu serwera, adres strony internetowej i ogólny zasięg sieci konta w chmurze nie zastępują wychodzącego źródła SMTP .

Wybierz najwęższy uzasadniony zakres

ip4:192.0.2.70 identyfikuje jeden adres IPv4 , ponieważ pominięty prefiks ma wartość domyślną /32. ip6:2001:db8::70 podobnie domyślnie jest to /128. Prefiks /24 IPv4 reprezentuje 256 adresów, podczas gdy prefiks /64 IPv6 obejmuje ogromną przestrzeń adresową. Rozmiar sieci nie jest powodem do autoryzacji; kontrola i potrzeby operacyjne są.

RFC 7208 sekcja 5.6 definiuje reguły dopasowywania i przedrostków. Używaj pełnych adresów i właściwej notacji CIDR. Skrócona wartość, taka jak 192.0.2. nie jest prawidłowym zamiennikiem 192.0.2.0/24 .

Sprawdzony przykład: testy graniczne wyłapują szerokie dotacje

Rozważmy politykę syntetyczną v=spf1 ip4:192.0.2.64/28 ip6:2001:db8:1::/64 -all. Zakres protokołu IPv4 obejmuje adresy od 192.0.2.64 do 192.0.2.79 . Adres łączący zgodny z 192.0.2.70 ; 192.0.2.80 nie ma i osiąga -all , jeśli nic innego nie pasuje.

Adres IPv6 2001:db8:1::25 pasuje do /64. Adres 2001:db8:2::25 nie. Te zastrzeżone adresy dokumentacji służą do uzasadnienia zasad, a nie do aktywnych nadawców.

Dla rzeczywiście proponowanego zakresu utwórz te same testy graniczne i listę osób kontrolujących każdy uwzględniony segment. Jeśli jedynym zatwierdzonym nadawcą jest jeden host, przed zatwierdzeniem szerszego prefiksu porównaj zestaw uprawnień z mechanizmem pojedynczego adresu.

Sprawdź zarówno rodziny sieci, jak i ścieżki wyjściowe

Natywne źródło IPv6 wymaga pozwolenia IPv6 . RFC 7208 RFC 7208 §5 osobno wymaga, aby adresy IPv6 mapowane na IPv4 były sprawdzane jako IPv4 ; nie oznacza to, że zakres IP4 obejmuje natywny IPv6 . System, który zaczyna korzystać z IPv6 może nagle osiągnąć koniec polityki, mimo że jego komunikaty IPv4 nadal są przesyłane. Uzyskaj dowody otrzymanych wiadomości lub zapisy infrastruktury wychodzącej dla obu rodzin, z których faktycznie korzystano.

Uwzględnij także NAT, bramy awaryjne, przekaźniki regionalne i zaplanowane zadania. Test z pojedynczego aktywnego węzła może pominąć trasę rezerwową. Nie rozwiązuj niepewności, autoryzując całego dostawcę usług hostingowych. Zamiast tego ustal obsługiwany zestaw wyjściowy i własność.

Zrozum kompromis w zakresie konserwacji

Pod RFC 7208 §4.6.4, ip4 i ip6 nie zużywają budżetu dziesięciu terminów powodujących zapytania DNS podczas oceny mechanizmu. Odbiorca nadal musi uzyskać Rekord SPF, a rozmiar i poprawność polityki nadal mają znaczenie. Rekord z setkami skopiowanych zakresów nie jest automatycznie utrzymywalny tylko dlatego, że te warunki nie wliczają się do tego limitu.

Gdy dostawca zaleca dołączenie, zastąpienie go migawką adresów IP powoduje, że jesteś odpowiedzialny za przyszłe zmiany. Zapisz, w jaki sposób zmiany zostaną wykryte, kto je zatwierdzi i w jaki sposób zostaną usunięte nieaktualne adresy. Nieaktualne uprawnienia mogą zarówno zakłócić działanie legalnej poczty, jak i zachować dostęp do infrastruktury, której już nie używasz.

Publikuj z różnicą uprawnień

Zachowaj stary zapis i wyjaśnij dokładnie, które zakresy są dodawane i usuwane. Sprawdź poprawność całego proponowanego rekordu SPF , przetestuj znane adresy nadawców i pobliskie nieautoryzowane adresy oraz zweryfikuj opublikowaną odpowiedź TXT . Następnie wysyłaj reprezentatywne wiadomości ścieżkami normalnymi i awaryjnymi.

Jeśli adres nieoczekiwanie znajdzie się poza zatwierdzonym zakresem, sprawdź trasę przed jej poszerzeniem. Nieoczekiwany wyjście może ujawnić błąd konfiguracji lub niezatwierdzonego nadawcę, a nie brakujące uprawnienia.

Praktyczne dania na wynos

Mechanizm adresowania jest jawny tylko wtedy, gdy jego własność i granice są wyraźne. Wykorzystaj zaobserwowane wyjścia, krawędzie zakresu testowego i traktuj przyszłe zmiany adresów jako część cyklu życia autoryzacji.

Zapisz decyzję i jej ograniczenia

Dla urządzenia /28 zapisz 192.0.2.63 jako zewnętrzne, .64 i .79 jako wewnętrzne i .80 jako zewnętrzne. Dopasowanie prefiksu SPF obejmuje wszystkie adresy w bloku, a nie tylko konwencjonalny podzbiór adresów hosta. Jeśli uzasadnione jest tylko .70, porównaj /32 z /28: ten ostatni przyznaje 16 adresów, a nie jeden. Są to obliczone przykłady członkostwa, a nie wykonane testy SPF .

[Na wynos]

Używaj obserwowanych adresów wychodzących i uzasadnionego zasięgu sieci. Sprawdź zarówno rodziny adresów, jak i trasy przełączania awaryjnego. Porównaj dokładny zestaw uprawnień przed i po zmianie.

[ Według roli ]

Co to oznacza dla Ciebie

Wybierz swoją rolę, aby uzyskać praktyczne dalsze kroki.

Administrator IT / poczty

Przetestuj adresy, które widzą odbiorcy.

Konfiguracja interfejsu lokalnego nie zawsze ujawnia rzeczywisty ruch wychodzący SMTP .

Kolejne kroki

  1. Przechwytuj ścieżki NAT i przekaźników.
  2. Przetestuj granice CIDR.
  3. Sprawdź jawnie IPv6 .

CISO / SecOps

Sprawdź wielkość każdej dotacji.

Szeroka sieć może obejmować systemy o różnych właścicielach lub poziomach zaufania.

Kolejne kroki

  1. Wymagaj dowodu posiadania zasięgu.
  2. Preferuj uzasadnione wąskie dotacje.
  3. Sprawdź wycofane uprawnienia do adresu.

Założyciel / Nietechniczny

Własność adresu funduszu, a nie jednorazowe zmiany DNS .

Stabilny spis nadawców ogranicza zakłócenia w przypadku zmian infrastruktury.

Kolejne kroki

  1. Nazwij właścicieli tras wychodzących.
  2. Uwzględnij przełączanie awaryjne w kontrolach gotowości.
  3. Wycofaj przestarzałe uprawnienia dotyczące infrastruktury.

[ Często zadawane pytania ]

Często zadawane pytania

Jaki jest domyślny prefiks IP4?

Pominięty prefiks oznacza /32, pojedynczy adres IPv4 .

RFC 7208 §5.6

Jaki jest domyślny prefiks IP6?

Pominięty prefiks oznacza /128, pojedynczy adres IPv6 .

RFC 7208 §5.6

Czy protokół IP4 obejmuje serwer korzystający z IPv6 ?

Nie dla natywnego źródła IPv6 . Adresy IPv6 są sprawdzane jako IPv4 zgodnie z RFC 7208 ; autoryzuj oddzielnie zatwierdzony natywny ruch wychodzący IPv6 .

RFC 7208 §5

Czy IP4 i IP6 zużywają limit dziesięciu terminów?

W ramach tego limitu nie są to terminy powodujące zapytania DNS. Pobieranie DNS , rozmiar rekordu i inne ograniczenia nadal obowiązują.

RFC 7208 §4.6.4

Czy powinienem autoryzować prywatny adres mojego serwera?

W przypadku dostawy internetowej użyj adresu połączenia zaobserwowanego przez odbiorcę, którym może być adres NAT lub adres przekaźnikowy. SPF ocenia adres IP połączenia, a nie domniemany adres interfejsu lokalnego.

RFC 7208 §4.1

Czy /24 jest bezpieczniejszy, ponieważ obejmuje przełączanie awaryjne?

Tylko jeśli każdy podany adres jest uzasadniony. Zweryfikuj rzeczywisty ruch awaryjny zamiast spekulacyjnie przyznawać szeroki zakres.

Czy mogę jednorazowo skopiować wszystkie zakresy dostawców?

Stwarza to obowiązek alimentacyjny. Zmiany dostawcy mogą sprawić, że kopia będzie nieaktualna lub zbyt obszerna.

Co powinien zawierać test zasięgu?

Przetestuj autoryzowane hosty, pierwszy i ostatni adres w zamierzonym zakresie, adresy tuż poza nim oraz odpowiadające im ścieżki IPv6 .

[ Źródła ]

Źródła

  1. RFC 7208

    Sekcje §4.1 · §4.6.4 · §5 · §5.6 · §2.4

[ Słowniczek ]

Słowniczek

SPF
Ocena łączącego adresu IP pod kątem polityki odpowiedniej tożsamości SMTP .

RFC 7208 §4.1

Przedrostek CIDR
Liczba bitów adresu wyższego rzędu porównana dla mechanizmu IP4 lub IP6; pominięte długości oznaczają odpowiednio /32 i /128.

RFC 7208 §5.6

Pochodzenie przedsiębiorstwa

Dlaczego najlepsze instytucje finansowe i rządy wycofali swoje panele bezpieczeństwa poczty e-mail.

Tradycyjne platformy uwierzytelniania poczty e-mail oferują pulpit nawigacyjny i proszą inżynierów o wykonanie pracy. W środowiskach o dużej stawce ręczny nadzór oznacza opóźnione egzekwowanie, zmianę konfiguracji i niemonitorowane domeny-cienie.

EmailAuth to platforma agentowego pochodzenia wiadomości e-mail. Nasi agenci egzekwują p=reject, dostosuj zewnętrznych nadawców i przenieś swoje domeny do pełnych adresów RFC 9989 zgodność, nowy standard DMARC , z możliwością kontroli przez człowieka.

Rządy Duże przedsiębiorstwa Instytucje finansowe poziomu 1

SaaS · Dedykowany najem · Lokalne rozwiązanie typu air-gapped · Szyfrowanie BYOK

Baza wiedzy