Ważne ostrzeżenie: Google i Yahoo będą wymagać DMARC od kwietnia 2024 r.
Czytaj więcej

Przewodnik wdrażania MTA-STS i TLS-RPT

Witamy w szczegółowym podręczniku na temat MTA-STS i TLS-RPT, aby uzyskać praktyczną wiedzę na temat protokołów i ich funkcjonalności.

Skontaktuj się z nami Zarezerwuj demo

Spis treści

  1. Co to jest Mail Transfer Agent-Strict Transport Security (MTA-STS)?
  2. W jaki sposób MTA-STS zapewnia szyfrowanie wiadomości w tranzycie?
  3. Rozkład anatomii ataku MITM
  4. W jaki sposób MTA-STS zapewnia szyfrowanie TLS?
  5. Co to jest MTA-STS Policy File?
  6. Jak opublikować MTA-STS Policy File?
  7. Czym jest rekord DNS MTA-STS?
  8. Jak wdrożyć MTA-STS?
  9. Jakie są cyzwania napotykane podczas ręcznego wdrażania MTA-STS?
  10. Usługi MTA-STS świadczone przez PowerDMARC
  11. Co to jest raportowanie TLS SMTP (TLS-RPT)?
  12. Jak włączyć TLS-RPT dla swojej domeny?
  13. Najczęściej zadawane pytania
szyfrowanie tls

Agent transferu poczty - ścisłe bezpieczeństwo transportu (MTA-STS)

MTA-STS, jak sama nazwa wskazuje, jest protokołem umożliwiającym szyfrowany transport wiadomości pomiędzy dwoma serwerami pocztowymi SMTP. MTA-STS określa serwerom wysyłającym, że wiadomości powinny być wysyłane tylko przez połączenie szyfrowane TLS, a nie powinny być w ogóle dostarczane w przypadku, gdy bezpieczne połączenie nie zostanie nawiązane za pomocą komendy STARTTLS. Zwiększając bezpieczeństwo poczty w tranzycie, MTA-STS pomaga w łagodzeniu ataków typu Man-In-The-Middle (MITM), takich jak ataki SMTP downgrade oraz ataki DNS spoofing.

Czytaj więcej

Jak MTA-STS zapewnia szyfrowanie wiadomości w tranzycie?

Weźmy prosty przykład, aby zrozumieć jak wiadomości są szyfrowane podczas przepływu emaili. Jeśli MTA wysyła email do [email protected]MTA wykonuje zapytanie DNS, aby dowiedzieć się, do którego MTA ma zostać wysłany email. Zapytanie DNS jest wysyłane w celu pobrania rekordów MX dla powerdmarc.com. Wysyłający MTA następnie łączy się z odbierającym MTA znalezionym w wyniku zapytania DNS, pytając czy ten serwer odbierający obsługuje szyfrowanie TLS. Jeśli tak, email jest wysyłany przez szyfrowane połączenie, jeśli jednak nie, wysyłające MTA nie udaje się wynegocjować bezpiecznego połączenia i wysyła email w postaci zwykłego tekstu.

Wysyłanie maili niezaszyfrowaną ścieżką toruje drogę do wszechobecnych ataków monitorujących, takich jak MITM czy SMTP downgrade. Dowiedzmy się jak:

Analiza anatomii ataku MITM

Zasadniczo, atak MITM ma miejsce, gdy osoba atakująca zastępuje lub usuwa komendę STARTTLS, aby zabezpieczone połączenie powróciło do niezabezpieczonego, bez szyfrowania TLS. Jest to określane jako atak typu downgrade. Po pomyślnym przeprowadzeniu ataku downgrade, atakujący może bez przeszkód uzyskać dostęp i przeglądać zawartość wiadomości e-mail.

Atakujący MITM może również podmienić rekordy MX w odpowiedzi na zapytanie DNS na serwer pocztowy, do którego ma dostęp i nad którym sprawuje kontrolę. W takim przypadku agent pocztowy dostarcza wiadomość e-mail na serwer atakującego, umożliwiając mu dostęp do treści wiadomości i manipulowanie nią. Następnie e-mail może zostać przekierowany na serwer odbiorcy bez wykrycia. Jest to tak zwany atak DNS spoofing.

Najczęściej zadawane pytania

Panel kontrolny PowerDMARC pozwala automatycznie skonfigurować MTA-STS i TLS-RPT dla Twojej domeny poprzez opublikowanie tylko trzech rekordów CNAME w DNS domeny. Od hostingu plików polityki MTAS-STS i certyfikatów do utrzymania serwera WWW, dbamy o to wszystko w tle, bez konieczności dokonywania jakichkolwiek zmian w DNS. Wdrożenie MTA-STS z Twojej strony z PowerDMARC jest zredukowane do zaledwie kilku kliknięć.

Możesz wdrożyć i zarządzać MTA-STS dla wszystkich swoich domen z konta PowerDMARC, za pomocą jednej szyby. W przypadku, gdy któraś z tych domen korzysta z serwerów pocztowych, które nie obsługują STARTTLS, będzie to widoczne w raportach TLS, pod warunkiem, że masz włączony TLS-RPT dla tych domen.

Zawsze zaleca się ustawienie trybu polityki MTA-STS na testowanie podczas początkowych faz wdrożenia, tak aby można było monitorować aktywność i uzyskać wgląd w swój ekosystem emailowy przed przejściem na bardziej agresywną politykę typu enforce. W ten sposób, nawet jeśli emaile nie są wysyłane przez szyfrowane połączenie TLS, nadal będą wysyłane w postaci plaintext. Upewnij się jednak, że włączyłeś TLS-RPT, aby otrzymywać powiadomienia, jeśli tak się stanie.

TLS-RPT to rozbudowany mechanizm raportowania, który pozwala na otrzymanie powiadomienia w przypadku, gdy nie udało się nawiązać bezpiecznego połączenia i wiadomość e-mail nie została dostarczona do użytkownika. Pomaga to wykryć problemy w dostarczaniu wiadomości e-mail lub wiadomości dostarczonych przez niezabezpieczone połączenie, dzięki czemu można je szybko złagodzić i rozwiązać.

Musisz zauważyć, że podczas gdy MTA-STS zapewnia, że e-maile są przesyłane przez szyfrowane połączenie TLS, w przypadku gdy bezpieczne połączenie nie zostanie wynegocjowane, e-mail może w ogóle nie zostać dostarczony. Jest to jednak konieczne, ponieważ zapewnia, że email nie jest dostarczany przez niezaszyfrowaną ścieżkę. Aby uniknąć takich problemów, zaleca się skonfigurowanie polityki MTA-STS w trybie testowym i włączenie TLS-RPT dla domeny na początku, przed przejściem do trybu egzekwowania MTA-STS. 

Możesz łatwo zmienić tryb MTA-STS z pulpitu nawigacyjnego PowerMTA-STS, wybierając żądany tryb polityki i zapisując zmiany bez konieczności dokonywania jakichkolwiek zmian w DNS.

Możesz wyłączyć MTA-STS dla swojej domeny albo ustawiając tryb polityki na none, określając w ten sposób MTA, że twoja domena nie obsługuje protokołu, albo usuwając rekord TXT MTA-STS DNS. 

Rekordy MX dla pliku polityki MTA-STS powinny zawierać wpisy dla wszystkich serwerów poczty odbiorczej wykorzystywanych przez domenę.