analiza łańcucha Received

Analiza łańcucha Received to badanie kolejnych nagłówków Received w wiadomości, obrazujących trasę jej przesyłania między serwerami.

Analiza łańcucha Received jako odczytywanie drogi wiadomości

Analiza łańcucha Received polega na uporządkowanym odczytaniu nagłówków dopisywanych do wiadomości podczas jej przekazywania. Każdy taki wpis opisuje kolejny etap obsługi poczty, zwykle wskazując system, który przyjął wiadomość, system przekazujący ją dalej, znacznik czasu oraz sposób połączenia. Nagłówki są układane od dołu do góry, ponieważ najniższy wpis zazwyczaj powstaje najbliżej pierwotnego nadawcy, a następne są dodawane wyżej przez kolejne elementy infrastruktury pocztowej. Taki zapis można porównać do śladu pozostawianego na kolejnych punktach przekazywania przesyłki, z tą różnicą, że jego wiarygodność zależy od tego, które elementy ścieżki zostały zapisane przez zaufane systemy.

W praktyce łańcuch Received nie powinien być traktowany jak prosty, samodzielny dowód pochodzenia wiadomości. Treść tych pól może zostać przygotowana przez nadawcę jeszcze przed wysłaniem, dlatego wpis znajdujący się najniżej nie zawsze zasługuje na zaufanie. Większą wartość dowodową mają informacje dopisane przez systemy znajdujące się po stronie odbiorcy lub przez znane, kontrolowane punkty przekazywania. Analiza wymaga więc rozdzielenia danych pochodzących z zewnątrz od danych zapisanych przez własną infrastrukturę pocztową.

Łańcuch Received a chronologia i wiarygodność nagłówków

Podstawowym zadaniem jest odtworzenie kolejności zdarzeń. Dla każdego pola Received warto wypisać osobno nazwę hosta, adres IP, czas, oznaczenie użytego protokołu oraz identyfikatory techniczne, jeżeli występują. Następnie porównuje się czasy zapisane w poszczególnych wpisach. Prawidłowa trasa powinna tworzyć logiczny ciąg: późniejszy etap nie powinien mieć czasu wcześniejszego niż etap, który miał nastąpić po nim. Różnice mogą wynikać z niezsynchronizowanych zegarów, stref czasowych, opóźnień w kolejce lub ponownego przetwarzania wiadomości, dlatego sama niezgodność czasu nie przesądza jeszcze o fałszerstwie.

Ważne jest również rozpoznanie, które nazwy i adresy są zgodne z rzeczywistą konfiguracją pocztową. Nazwa hosta może zostać przedstawiona w kilku wariantach, a jeden system może mieć nazwę lokalną, nazwę publiczną i adres wynikający z odwrotnego rozpoznawania DNS. Trzeba sprawdzić, czy te elementy wzajemnie do siebie pasują. Jeżeli nazwa wskazuje na jedną domenę, a adres prowadzi do zupełnie innego zakresu lub nie ma spójnego odwrotnego wpisu DNS, jest to sygnał do dalszej weryfikacji, nie zaś automatyczna podstawa do odrzucenia wiadomości.

Analiza powinna uwzględniać także przerwy czasowe między poszczególnymi etapami. Krótka różnica może oznaczać zwykłe przekazanie wiadomości, natomiast dłuższy odstęp bywa związany z kolejką, ponawianiem dostarczenia, skanowaniem treści albo chwilową niedostępnością odbiorcy. W zestawieniu z kodami odpowiedzi i pozostałymi nagłówkami można ustalić, czy wiadomość była opóźniona, przekazywana wielokrotnie albo obsługiwana przez kilka niezależnych punktów.

Problemy wykrywane przez analizę łańcucha Received

Jednym z typowych zastosowań jest rozpoznawanie podejrzanej trasy wiadomości. Niespójne nazwy hostów, niepasujące adresy, nietypowe odstępy czasowe oraz brak zgodności z deklarowaną domeną nadawcy mogą wskazywać na podszywanie się, nieprawidłową konfigurację albo przekazanie wiadomości przez nieoczekiwany system. Analiza może pomóc ustalić, czy wiadomość rzeczywiście przeszła przez deklarowany punkt pośredni, czy też część danych została dopisana jedynie po to, aby stworzyć pozór wiarygodnej historii.

Łańcuch Received bywa również pomocny przy badaniu opóźnień. Jeżeli kolejne wpisy wskazują na szybkie przyjęcie wiadomości, a między dwoma następnymi etapami występuje długa przerwa, przyczyny można szukać w kolejce przekazującej, ograniczeniach przepustowości, błędach rozpoznawania nazwy lub czasowym odrzucaniu połączenia. Jeżeli opóźnienie pojawia się dopiero po przyjęciu wiadomości przez system odbiorcy, trzeba sprawdzić reguły filtrowania, skanowanie antyspamowe i sposób dostarczania do skrzynki.

Ten sam materiał może ujawnić błędne ustawienie strefy czasowej, brak synchronizacji zegara lub nieprawidłową nazwę lokalną. W sieciach firmowych część adresów może być prywatna i niewidoczna z Internetu, co jest normalne, jeśli opisuje wewnętrzny etap przekazywania. Nie należy więc uznawać każdego adresu prywatnego za dowód zagrożenia. Znaczenie konkretnego wpisu ocenia się dopiero w połączeniu z miejscem jego dodania, rolą danego systemu i pozostałą dokumentacją dostarczenia.

Wiadomość może zawierać również powtarzające się pola, niepełne nazwy lub dodatkowe oznaczenia wprowadzone przez filtry. Ich obecność nie musi oznaczać manipulacji. Czasem wynika z ponownego przekazania przez bramę pocztową, przekierowania na inną skrzynkę albo zastosowania narzędzia do archiwizacji. Najbezpieczniej zachować pełny oryginał wiadomości, zamiast analizować jedynie fragment skopiowany z programu pocztowego.

Interpretacja analizy łańcucha Received krok po kroku

Pracę warto rozpocząć od zapisania wszystkich nagłówków w niezmienionej postaci. Następnie należy podzielić je na osobne rekordy i odczytywać od dołu do góry. Przy każdym wpisie można zanotować: poprzedni punkt przekazania, punkt przyjmujący, adresy, czas, metodę połączenia, identyfikator wiadomości oraz dodatkowe informacje o uwierzytelnieniu. Takie uporządkowanie ogranicza ryzyko pominięcia wpisu i ułatwia porównanie kilku wiadomości wysłanych w podobnym czasie.

• Najpierw rozpoznaje się wpisy dodane przez znane i zaufane systemy odbiorcze.
• Następnie porównuje się chronologię oraz różnice czasu pomiędzy kolejnymi etapami.
• Później sprawdza się zgodność nazw hostów, adresów i domen z oczekiwaną trasą.
• Na końcu zestawia się wynik z oznaczeniami uwierzytelnienia, wynikiem filtrowania oraz treścią komunikatu.

Warto odróżnić analizę samego łańcucha od analizy całej wiadomości. Nagłówki Received pokazują przede wszystkim drogę przekazywania, natomiast nie rozstrzygają samodzielnie, czy treść jest prawdziwa, czy nadawca jest godny zaufania i czy załącznik jest bezpieczny. Do pełniejszej oceny przydają się między innymi pola dotyczące SPF, DKIM i DMARC, identyfikator wiadomości, adresy użyte w polach From, Reply-To i Return-Path oraz wynik kontroli reputacyjnej. Każdy z tych elementów opisuje inną właściwość, dlatego nie powinien być zastępowany pojedynczym wnioskiem z jednego nagłówka.

Kiedy zgłosić analizę łańcucha Received do serwisu

Pomoc techniczna jest zasadna, gdy wiadomość zawiera sprzeczne czasy, niezrozumiałą trasę, nieznane punkty przekazywania lub podejrzenie podszycia się pod nadawcę. Warto zgłosić problem również wtedy, gdy dostarczanie regularnie się opóźnia, wiadomości trafiają do nieprawidłowych folderów albo po zmianie ustawień poczty pojawiają się błędy połączenia. Do analizy najlepiej przekazać oryginalną wiadomość wraz z pełnymi nagłówkami oraz krótki opis sytuacji: kiedy wiadomość została wysłana, kiedy dotarła i jakie zachowanie uznano za nieprawidłowe.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się pomocą przy problemach z laptopami i komputerami PC, w tym przy trudnościach z konfiguracją poczty oraz odczytem informacji diagnostycznych. Przekazanie pełnych danych pozwala sprawdzić, czy problem dotyczy programu pocztowego, ustawień konta, połączenia sieciowego czy samego przebiegu dostarczenia. Nie należy usuwać nagłówków, przeklejać wyłącznie widocznej treści ani zmieniać kolejności pól, ponieważ takie działania mogą pozbawić analizę istotnego kontekstu.

Jeżeli wiadomość może zawierać dane poufne, przed przekazaniem należy rozważyć usunięcie treści korespondencji i pozostawienie samych nagłówków, o ile pozwala na to charakter sprawy. Trzeba jednak zachować adresy, czasy, identyfikatory oraz informacje o systemach przekazujących, ponieważ właśnie one są podstawą rekonstrukcji trasy. W przypadku podejrzenia oszustwa warto także zabezpieczyć kopię oryginalnego pliku wiadomości i nie odpowiadać na nią do czasu wyjaśnienia pochodzenia.