Traktuj kontrolę DNS jako część zaufania do poczty e-mail
Przejmowanie DNS to nieautoryzowana zmiana informacji lub ścieżki rozwiązywania problemów, której ufa klient. Dla zespołu poczty elektronicznej ważnym pytaniem nie jest tylko to, czy witryna domeny została przeniesiona. Określ, którego organu, konta lub mechanizmu rozpoznawania nazw dotyczyły zmiany, które nazwy związane z pocztą uległy zmianie i co odbiorcy mogli zaobserwować w okresie objętym usterką. Czysta odpowiedź nie oznacza, że wcześniejsze decyzje dotyczące dostawy opierały się na tych samych danych.
Trzymaj autorytatywne przejęcie oddzielnie od zatruwania pamięci podręcznej i lokalnego przekierowania mechanizmu rozpoznawania nazw. Mogą powodować podobne objawy, ale wymagają różnych właścicieli. Konto rejestratora może mieć wpływ na delegowanie; autorytatywne konto hostingowe może zmieniać zawartość strefy; zaatakowany punkt końcowy może użyć nieoczekiwanego mechanizmu rozpoznawania nazw. NIST Przewodnik wdrażania DNS rozróżnia zagrożenia dla usług autorytatywnych, rekursywnych i pośredniczących. To rozróżnienie jest punktem wyjścia dla przydatnej mapy zdarzeń.
Zidentyfikuj granicę zaufania, która została przesunięta
Porównaj znaną linię bazową rejestracji i delegowania z obecną wiarygodną usługą. Zapisz, kto zarządza rejestratorem, hostingiem DNS , infrastrukturą podpisywania i kontaktami w zakresie odzyskiwania. Sprawdź, czy zmiana została autoryzowana, zanim nazwiesz ją złośliwą: planowane migracje, delegowane subdomeny i podzielone poglądy mogą powodować uzasadnione różnice. Zachowaj niepewność, gdy zapisy lub logi konta są niedostępne.
Autorytatywna hierarchia ma znaczenie, ponieważ wiarygodnie wyglądający eksport strefy od poprzedniego dostawcy może już nie opisywać delegacji publicznej. RFC 1034 sekcja 4.2 wyjaśnia granice stref i delegację. Dowód incydentu powinien identyfikować serwer i ścieżkę używaną dla każdej obserwacji, a nie tylko odtwarzać tekst odpowiedzi. Zrzut ekranu bez żądanej nazwy, typu rekordu i sygnatury czasowej jest słabym dowodem na to, co się zmieniło.
Skorzystaj z ustalonych procedur dotyczących incydentów, aby chronić konta, których to dotyczy, zachować odpowiednie dzienniki i koordynować przywracanie. Działania te wymagają autoryzacji organizacji; ten artykuł nie dotyczy zmian w działającej usłudze. Unikaj niszczenia przydatnych dowodów, usuwając konta, zastępując wszystkie rekordy lub czyszcząc każdą pamięć podręczną, zanim właściciel zdarzenia uchwyci stan, którego dotyczy problem.
Śledź różne konsekwencje dla poczty przychodzącej i wychodzącej
Nieautoryzowana zmiana MX może przekierować próby dostarczenia poczty przychodzącej. To, czy dany nadawca faktycznie doręczy przesyłkę, zależy od wybranej przez niego trasy, zabezpieczeń transportu i powstałego połączenia. Nie należy wnioskować, że zawartość skrzynki pocztowej została odczytana wyłącznie na podstawie różnicy MX . Ustal odstęp czasowy, którego to dotyczy i sprawdź dowody dostawy przed złożeniem wniosku o narażenie.
Wychodzące kontrole tożsamości mają różne zależności. SPF ocenia, czy adres łączący jest autoryzowany dla ocenianej domeny, korzystając z polityki DNS w ramach RFC 7208. Jeśli przeciwnik kontroluje tę politykę, przepustka SPF może odzwierciedlać nieautoryzowaną politykę, a nie uzasadnioną autoryzację biznesową. Zastąpienie A DKIM klucz publiczny może mieć wpływ na weryfikację, ale opublikowanie klucza nie zmienia podpisów starych wiadomości ani nie ujawnia poprzedniego klucza prywatnego. Proces wyszukiwania i weryfikacji klucza opisano w RFC 6376 sekcje 3.6 i 6.1.2.
DMARC opiera się na uwierzytelnionym identyfikatorze zgodnym z domeną autora. Nie jest to niezależny rejestr zatwierdzonych pracowników ani dostawców. Materiał uwierzytelniający przejętej domeny może podważyć założenia leżące u podstaw pozytywnego wyniku. Polityka domeny informuje również o obsłudze odbiorcy, zamiast gwarantować uniwersalny wynik, jak wyjaśniono w RFC 9989 sekcje 4.4 i 5.4.
Dowiedz się, które zabezpieczenia dotyczą danego ryzyka
DNSSEC zapewnia uwierzytelnianie pochodzenia i integralność danych DNS , gdy walidacja ma użyteczny łańcuch zaufania. Nie zaświadcza, że zmiana dokonana za pośrednictwem autoryzowanego systemu podpisu odzwierciedla intencję właściciela. Złośliwa edycja zaakceptowana i podpisana przez zhakowaną autorytatywną ścieżkę administracyjną może nadal zostać zweryfikowana. RFC 4033 sekcja 3 określa usługi świadczone DNSSEC ; Kontrola ochrony konta i zatwierdzania dotyczy innej warstwy.
Polityka transportowa również wymaga własnej analizy. Istniejący MTA-STS Zasady mogą ograniczać dozwolone hosty MX i weryfikację TLS w przypadku nadawców wdrażających, ale początkowe wykrywanie i buforowanie zasad mają ograniczenia. DANE SMTP zależy od informacji uwierzytelnionych przez DNSSEC i jest odpowiedni TLSA dokumentacja. Żadnego mechanizmu nie należy opisywać jako uniwersalnego antidotum na przejmowanie domen administracyjnych. Konsultować RFC 8461 sekcja 10 I RFC 7672 sekcja 2 dla ich odrębnych modeli zaufania.
Fikcyjny działający przykład kwestionowanej zmiany rekordu MX
W fikcyjnej organizacji Przykładowe warsztaty pojawia się alert informujący, że example.com ma teraz inny cel MX . Stary panel DNS administratora poczty nadal wyświetla oczekiwaną wartość. Proponowane dochodzenie obejmowałoby porównanie delegacji, aktualnych wiarygodnych odpowiedzi i zapisów dotyczących zmian rejestratorów przed podjęciem decyzji, czy panel po prostu nie jest już autorytatywny.
Załóżmy, że później w rekordzie zdarzenia zostanie stwierdzona nieautoryzowana zmiana delegacji. Właściciel odpowiedzi koordynowałby przywrócenie zatwierdzonego organu i oceniał okno czasowe na podstawie dzienników nadawcy i dowodów dotyczących polityki transportowej. Przejście uwierzytelnienia niepowiązanej wiadomości wychodzącej nie zamknie pytania dotyczącego ekspozycji przychodzącej. Ten scenariusz został wymyślony i nie obejmuje zaobserwowanych incydentów, dostępu do konta dostawcy ani testowanego przywracania.
Zdefiniuj odzyskiwanie poza przywracaniem jednej odpowiedzi
Zachowaj zatwierdzoną różnicę rekordów, mapę zależności i przywróć materiał, a następnie zweryfikuj przywróconą autorytatywną ścieżkę i wybrane widoki rekurencyjne. Przejrzyj wszystkie klucze, dane uwierzytelniające lub punkty końcowe zasad powiązane z rzeczywistym naruszeniem, nie zakładając, że ujawniono każdy sekret. Przypisz własność monitorowania powtarzalności i nierozwiązanych pytań dotyczących narażenia.
Zamykaj incydent tylko według wyraźnych kryteriów: administracja jest kontrolowana, doręczane są zamierzone zapisy, weryfikowane są zależne usługi i zrozumiany jest okres dowodowy. Odpowiedzi zapisane w pamięci podręcznej i poczta oczekująca w kolejce mogą przetrwać widoczną naprawę. Brakuje tutaj pierwotnego zatwierdzenia i dowodów wyszukiwania po zmianie, więc to edukacyjne wyjaśnienie nie stanowi pełnej oceny przejęcia ani deklaracji, że jakakolwiek domena jest bezpieczna.