Powszechnie znanym standardem internetowym, który ułatwia poprawę bezpieczeństwa połączeń między serwerami SMTP (Simple Mail Transfer Protocol) jest SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS). MTA-STS rozwiązuje istniejące problemy w SMTP bezpieczeństwa poczty e-mail poprzez wymuszenie szyfrowania TLS w tranzycie. Szyfrowanie jest opcjonalne w SMTP, co oznacza, że wiadomości e-mail mogą być wysyłane w postaci zwykłego tekstu. MTA-STS umożliwia dostawcom usług pocztowych egzekwowanie Transport Layer Security (TLS) w celu zabezpieczenia połączeń SMTP, a także określenie, czy wysyłające serwery SMTP powinny odmawiać dostarczania wiadomości e-mail do hostów MX, które nie obsługują TLS z wiarygodnym certyfikatem serwera. Udowodniono, że skutecznie łagodzi ataki TLS downgrade i ataki Man-In-The-Middle (MITM).
Kluczowe wnioski
- SMTP początkowo nie posiadał zabezpieczeń, zyskał opcjonalne szyfrowanie poprzez STARTTLS, ale pozostał podatny na ataki MITM i downgrade.
- MTA-STS zwiększa bezpieczeństwo poczty e-mail, narzucając szyfrowanie TLS dla komunikacji serwer-serwer, uniemożliwiając powrót do zwykłego tekstu.
- Wdrożenie obejmuje plik zasad hostowany przez HTTPS i rekord DNS, definiujący reguły i zaufane serwery pocztowe.
- MTA-STS działa w trybach (None, Testing, Enforce) umożliwiających stopniowe wdrażanie i egzekwowanie zasad szyfrowania.
- TLS-RPT uzupełnia MTA-STS, dostarczając raporty diagnostyczne dotyczące awarii połączeń TLS, pomagając w rozwiązywaniu problemów i poprawiając dostarczalność.
Historia i pochodzenie MTA-STS
W roku 1982 po raz pierwszy określono specyfikację SMTP, która nie zawierała żadnego mechanizmu zapewniającego bezpieczeństwo na poziomie transportu w celu zabezpieczenia komunikacji pomiędzy agentami transferu poczty. Jednak w 1999 roku do SMTP dodano polecenie STARTTLS, które z kolei wspierało szyfrowanie wiadomości e-mail pomiędzy serwerami, dając możliwość przekształcenia niezabezpieczonego połączenia w bezpieczne, szyfrowane za pomocą protokołu TLS.
W takim razie musisz się zastanawiać, czy SMTP zaadoptował STARTTLS do zabezpieczania połączeń między serwerami, dlaczego wymagana była zmiana na MTA-STS i co to w ogóle zrobiło. Przejdźmy do tego w kolejnych sekcjach tego bloga!
Uprość bezpieczeństwo z PowerDMARC!
Co to jest MTA-STS? (Mail Transfer Agent Strict Transport Security - Explained)
MTA-STS to skrót od Mail Transfer Agent - Strict Transport Security. Jest to standard bezpieczeństwa, który zapewnia bezpieczną transmisję wiadomości e-mail za pośrednictwem szyfrowanego połączenia SMTP. Skrót MTA oznacza Message Transfer Agent, czyli program do przesyłania wiadomości e-mail między komputerami. Skrót STS oznacza Strict Transport Security, który jest protokołem używanym do implementacji standardu. Agent transferu poczty (MTA) obsługujący MTA-STS lub bezpieczny agent transferu wiadomości (SMTA) działa zgodnie z tą specyfikacją i zapewnia bezpieczny kanał end-to-end do wysyłania wiadomości e-mail przez niezabezpieczone sieci.
Protokół MTA-STS pozwala klientowi SMTP zweryfikować tożsamość serwera i upewnić się, że nie łączy się on z oszustem, wymagając od serwera podania odcisku palca jego certyfikatu w trakcie rozmowy TLS. Klient następnie weryfikuje certyfikat z magazynem zaufania zawierającym certyfikaty znanych serwerów.
Wprowadzenie do MTA-STS Email Security
MTA-STS został wprowadzony w celu wypełnienia luki w zabezpieczeniach podczas komunikacji SMTP. Jako standard bezpieczeństwa, MTA-STS zapewnia bezpieczną transmisję wiadomości e-mail przez szyfrowane połączenie SMTP.
Skrót MTA oznacza Message Transfer Agent, czyli program do przesyłania wiadomości e-mail między komputerami. Skrót STS oznacza Strict Transport Security, który jest protokołem używanym do implementacji standardu. Agent transferu poczty (MTA) lub bezpieczny agent transferu wiadomości (SMTA) obsługujący MTA-STS działa zgodnie z tą specyfikacją i zapewnia bezpieczny kanał end-to-end do wysyłania wiadomości e-mail przez niezabezpieczone sieci.
Protokół MTA-STS pozwala klientowi SMTP zweryfikować tożsamość serwera i upewnić się, że nie łączy się on z oszustem, wymagając od serwera podania odcisku palca jego certyfikatu w trakcie rozmowy TLS. Klient następnie weryfikuje certyfikat z magazynem zaufania zawierającym certyfikaty znanych serwerów.
Potrzeba przejścia na wymuszone szyfrowanie TLS
STARTTLS nie był doskonały i nie rozwiązał dwóch głównych problemów: po pierwsze, jest to środek opcjonalny, dlatego STARTTLS nie zapobiega atakom typu man-in-the-middle (MITM). Wynika to z faktu, że atakujący MITM może łatwo zmodyfikować połączenie i uniemożliwić aktualizację szyfrowania. Drugim problemem jest to, że nawet jeśli STARTTLS jest zaimplementowany, nie ma sposobu na uwierzytelnienie tożsamości serwera wysyłającego, ponieważ SMTP nie weryfikują certyfikatów.
Podczas gdy większość wychodzących wiadomości e-mail jest obecnie zabezpieczona za pomocą Transport Layer Security (TLS) szyfrowanie, standard branżowy przyjęty nawet w konsumenckiej poczcie e-mail, atakujący nadal mogą utrudniać i manipulować pocztą e-mail, nawet zanim zostanie ona zaszyfrowana. Ponieważ bezpieczeństwo musiało zostać zmodernizowane w SMTP, aby zapewnić jego wsteczną kompatybilność poprzez dodanie polecenia STARTTLS w celu zainicjowania szyfrowania TLS, w przypadku gdy klient nie obsługuje TLS, komunikacja powraca do czystego tekstu. W ten sposób wiadomości e-mail w tranzycie mogą paść ofiarą wszechobecnych ataków monitorujących, takich jak MITM, w których cyberprzestępcy mogą podsłuchiwać wiadomości oraz zmieniać i manipulować informacjami, zastępując lub usuwając polecenie szyfrowania (STARTTLS), powodując powrót komunikacji do zwykłego tekstu. Atakujący MITM może po prostu zastąpić STARTTLS bezużytecznym ciągiem znaków, którego klient nie jest w stanie zidentyfikować. Dlatego też klient z łatwością powraca do wysyłania wiadomości e-mail w postaci zwykłego tekstu. Jeśli nie uda się przesłać wiadomości e-mail za pośrednictwem bezpiecznego połączenia, dane mogą zostać naruszone, a nawet zmodyfikowane i zmanipulowane przez cyberprzestępcę.
Tutaj właśnie wkracza MTA-STS i naprawia ten problem, gwarantując bezpieczny tranzyt wiadomości e-mail, a także skutecznie ograniczając ataki MITM. MTA-STS wymusza przesyłanie wiadomości e-mail za pomocą szyfrowanej ścieżki TLS, a w przypadku, gdy nie można nawiązać szyfrowanego połączenia, wiadomość e-mail nie jest w ogóle dostarczana, zamiast być dostarczana w postaci zwykłego tekstu. Co więcej, MTA przechowują pliki polityki MTA-STS, co utrudnia atakującym przeprowadzenie ataku typu ataku DNS spoofing. Głównym celem jest poprawa bezpieczeństwa na poziomie transportu podczas komunikacji SMTP i zapewnienie prywatności ruchu e-mail. Co więcej, szyfrowanie wiadomości przychodzących i wychodzących zwiększa bezpieczeństwo informacji, wykorzystując kryptografię do ochrony informacji elektronicznych.
Konfiguracja MTA-STS za pomocą PowerDMARC!
Jak działa MTA-STS?
Protokół MTA-STS jest wdrażany poprzez posiadanie rekordu DNS, który określa, że serwer pocztowy może pobrać plik polityki z określonej subdomeny. Ten plik zasad jest pobierany przez HTTPS i uwierzytelniany za pomocą certyfikatów, wraz z listą nazw serwerów pocztowych odbiorcy. Wdrożenie MTA-STS jest łatwiejsze po stronie odbiorcy w porównaniu do strony wysyłającej, ponieważ wymaga obsługi przez oprogramowanie serwera pocztowego. Podczas gdy niektóre serwery pocztowe obsługują MTA-STS, takie jak PostFixale nie wszystkie. MTA-STS pozwala serwerom wskazać, że obsługują TLS, co pozwoli im na zamknięcie (tj. niewysłanie wiadomości e-mail), jeśli negocjacja aktualizacji TLS nie zostanie przeprowadzona, uniemożliwiając w ten sposób przeprowadzenie ataku TLS downgrade.
Główni dostawcy usług pocztowych, tacy jak Microsoft, Oath i Google, obsługują MTA-STS. Gmail firmy Google przyjął już zasady MTA-STS w ostatnim czasie. MTA-STS usunął wady w bezpieczeństwie połączeń e-mail, czyniąc proces zabezpieczania połączeń łatwym i dostępnym dla obsługiwanych serwerów pocztowych.
Połączenia od użytkowników do serwerów pocztowych są zazwyczaj chronione i szyfrowane za pomocą protokołu TLS, jednak pomimo tego istniał brak bezpieczeństwa w połączeniach między serwerami pocztowymi przed wdrożeniem MTA-STS. Wraz ze wzrostem świadomości na temat bezpieczeństwa poczty elektronicznej w ostatnim czasie i wsparciem ze strony głównych dostawców poczty na całym świecie, oczekuje się, że większość połączeń między serwerami będzie szyfrowana w najbliższej przyszłości. Co więcej, MTA-STS skutecznie zapewnia, że cyberprzestępcy w sieciach nie są w stanie odczytać treści wiadomości e-mail.
Plik polityki MTA-STS
Plik zasad MTA-STS jest zwykłym plikiem konfiguracyjnym MTA-STS, który jest hostowany na serwerze internetowym domeny pod adresem URL HTTPS: Definiuje on zasady ustanawiania bezpiecznych połączeń między serwerami pocztowymi, wymuszania szyfrowania TLS i określania działań, które należy podjąć, jeśli nie można ustanowić bezpiecznego połączenia.
https://mta-sts.<domain>//.well-known/mta-sts.txt
Struktura pliku polityki MTA-STS
Pola | Opis | Przykład |
wersja | Wersja formatu polityki MTA-STS | STS1 |
tryb | Poziom egzekwowania zasad spośród 3 dostępnych opcji: brak, testowanie i egzekwowanie | testowanie |
mx | Lista prawidłowych serwerów Mail Exchange (MX) domeny | mail.domain.com |
maksymalny wiek | Czas w sekundach, przez jaki polityka powinna być buforowana przez zewnętrzne serwery pocztowe. | 86400 |
Przykład polityki MTA-STS
wersja: STSv1
tryb: wymuszanie
mx: mail.example.com
mx: backupmail.example.com
max_age: 86400
Wymagania wstępne dla wdrożenia MTA-STS
Przed rozpoczęciem konfiguracji MTA-STS należy wykonać następujące czynności:
- Zarejestrowana nazwa domeny
- Ważne certyfikaty TLS
- Certyfikaty TLS muszą być wydawane przez zaufany urząd certyfikacji.
- Certyfikaty muszą być aktualne i nie mogą wygasać.
- Powinien to być co najmniej TLS w wersji 1.2 lub wyższej.
- Rekord DNS TXT dla MTA-STS
- Serwer internetowy HTTPS
- Serwer pocztowy skonfigurowany do korzystania z TLS
- Nazwa hosta serwera pocztowego pasująca do wpisów w polu mx pliku zasad
- Środowisko testowe lub hostowana usługa MTA-STS do monitorowania dzienników i wprowadzania zmian w razie potrzeby.
Kroki konfiguracji MTA-STS dla twojej domeny
Aby skonfigurować MTA-STS dla swojej domeny, możesz wykonać kroki pokazane poniżej:
- Sprawdź, czy Twoja domena ma istniejącą konfigurację MTA-STS. Jeśli korzystasz z Google Workspace dla swoich wiadomości e-mail, możesz to łatwo zrobić za pomocą tego przewodnik.
- Utwórz i opublikuj politykę MTA-STS, skonfigurowaną oddzielnie dla każdej domeny. Plik zasad MTA-STS definiuje serwery poczty e-mail z obsługą MTA-STS używane przez tę domenę.
- Po utworzeniu pliku zasad należy przesłać go na publiczny serwer WWW, do którego zdalne serwery będą miały łatwy dostęp
- Na koniec utwórz i opublikuj rekord DNS MTA-STS (rekord TXT "_mta-sts"), aby poinstruować serwery odbierające, że wiadomości e-mail muszą być szyfrowane TLS, aby można je było uznać za autentyczne, i powinny mieć dostęp do skrzynki odbiorczej odbiorcy tylko wtedy, gdy to pierwsze jest prawdą
Po utworzeniu aktywnego pliku zasad zewnętrzne serwery pocztowe nie będą zezwalać na dostęp do poczty e-mail bez bezpiecznego połączenia.
3 Tryby polityki MTA-STS: Brak, Testowanie i Wymuszanie
Trzy dostępne wartości dla trybów polityki MTA-STS są następujące:
- Brak: Ta zasada unieważnia konfigurację MTA-STS, ponieważ serwery zewnętrzne uznają protokół za nieaktywny dla domeny.
- Testowanie: Podczas korzystania z tej polityki wiadomości e-mail przesyłane przez niezaszyfrowane połączenie nie będą odrzucane, zamiast tego przy włączonej funkcji TLS-RPT nadal będziesz otrzymywać raporty TLS dotyczące ścieżki dostarczania i zachowania wiadomości e-mail.
- Siła: Wreszcie, gdy włączona jest polityka wymuszania, wiadomości e-mail przesyłane przez niezaszyfrowane połączenie SMTP będą odrzucane przez serwer.
MTA-STS zapewnia ochronę przed :
- Ataki na obniżenie ratingu
- Ataki typu Man-In-The-Middle (MITM)
- Rozwiązuje wiele problemów związanych z bezpieczeństwem SMTP, w tym wygasłe certyfikaty TLS, brak wsparcia dla bezpiecznych protokołów i certyfikaty, które nie są wydawane przez wiarygodne strony trzecie.
Raportowanie TLS: Monitorowanie luk w dostarczalności wiadomości e-mail po konfiguracji MTA-STS
TLS-RPT (Transport Layer Security Reporting) to protokół umożliwiający właścicielom domen otrzymywanie szczegółowych raportów dotyczących błędów szyfrowania TLS w komunikacji e-mail. TLS Reporting działa w połączeniu z MTA-STS. Umożliwia raportowanie problemów z łącznością TLS, które są doświadczane przez aplikacje wysyłające wiadomości e-mail i wykrywanie błędnych konfiguracji. Umożliwia raportowanie problemów z dostarczaniem wiadomości e-mail, które mają miejsce, gdy wiadomość e-mail nie jest szyfrowana za pomocą TLS. We wrześniu 2018 r. standard ten został po raz pierwszy udokumentowany w dokumencie RFC 8460.
Kluczowe funkcje obejmują:
- Raportowanie błędów: Zapewnia szczegółowe raporty dotyczące problemów z dostarczaniem lub awarii spowodowanych przez problemy TLS, takie jak wygasłe certyfikaty lub nieaktualne wersje TLS, a także awarie szyfrowania TLS. Po włączeniu TLS-RPT, zgodni agenci transferu poczty zaczną wysyłać raporty diagnostyczne dotyczące problemów z dostarczaniem wiadomości e-mail między komunikującymi się serwerami do wyznaczonej domeny e-mail. Raporty są zazwyczaj wysyłane raz dziennie, obejmując i przekazując zasady MTA-STS obserwowane przez nadawców, statystyki ruchu, a także informacje o awariach lub problemach w dostarczaniu wiadomości e-mail.
- Widoczność: Pomaga monitorować problemy z implementacją MTA-STS i dostarczalnością wiadomości e-mail. TLS-RPT zapewnia lepszą widoczność wszystkich kanałów e-mail, dzięki czemu zyskujesz lepszy wgląd we wszystko, co dzieje się w Twojej domenie, w tym wiadomości, które nie są dostarczane.
- Zwiększone bezpieczeństwo poczty e-mail: Usuwając błędy związane z nieudanymi negocjacjami szyfrowania TLS, można poprawić ogólną skuteczność konfiguracji MTA-STS, a tym samym skuteczniej zapobiegać cyberatakom. Co więcej, zapewnia on dogłębne raporty diagnostyczne, które pozwalają zidentyfikować i dotrzeć do źródła problemu z dostarczaniem wiadomości e-mail oraz naprawić go bez żadnych opóźnień.
Łatwe wdrażanie MTA-STS za pomocą PowerDMARC
MTA-STS wymaga serwera WWW obsługującego protokół HTTPS z ważnym certyfikatem, rekordów DNS i stałej konserwacji. Wdrożenie MTA-STS może być żmudnym zadaniem, które wiąże się ze złożonością podczas adopcji. Od generowania plików polityk i rekordów po utrzymanie serwera WWW i hostowanie certyfikatów, jest to długotrwały proces. PowerDMARC's Analizator DMARC znacznie ułatwia życie, obsługując to wszystko za Ciebie, całkowicie w tle. Gdy pomożemy Ci go skonfigurować, nigdy więcej nie będziesz musiał o nim myśleć.
Z pomocą PowerDMARC można wdrożyć Hosted MTA-STS w swojej organizacji bez kłopotów związanych z obsługą certyfikatów publicznych. Pomagamy:
- Publikuj rekordy DNS CNAME za pomocą kilku kliknięć
- Aktualizuj zasady i optymalizuj swój rekord jednym kliknięciem bez konieczności uzyskiwania dostępu do ustawień DNS.
- Zweryfikuj wersję polityki i walidację certyfikatu
- Wykrywanie błędów aplikacji polityki MTA-STS
- Hostowanie pliku tekstowego zasad MTA-STS
- Przejęcie odpowiedzialności za utrzymanie serwera internetowego polityki i hosting certyfikatów.
- Szybsze wykrywanie awarii połączeń, udanych połączeń i problemów z połączeniami dzięki uproszczonym raportom
- Zapewnienie zgodności z RFC i wsparcie dla najnowszych standardów TLS
PowerDMARC sprawia, że proces wdrażania SMTP TLS Reporting (TLS-RPT) jest łatwy i szybki. Przekształcamy skomplikowane pliki JSON zawierające raporty o problemach z dostarczaniem wiadomości e-mail w proste, czytelne dokumenty (dla każdego wyniku i źródła wysyłania), które można łatwo zrozumieć.
Zarejestruj się już dziś, aby szybko wymusić wysyłanie wiadomości e-mail do Twojej domeny za pośrednictwem połączenia szyfrowanego TLS i zabezpieczyć połączenie przed atakami MITM i innymi cyberatakami.
"`
- Jak utworzyć i opublikować rekord DMARC - 3 marca 2025 r.
- Jak naprawić "Nie znaleziono rekordu SPF" w 2025 roku - 21 stycznia 2025 r.
- Jak czytać raport DMARC - 19 stycznia 2025 r.