Najpierw opublikuj MTA-STS i TLS-RPT w trybie testing

SPF, DKIM i DMARC chronią przed podszywaniem się pod Twoją domenę (możesz sprawdzić rekord DMARC), ale żaden z nich nie powstrzyma serwera nadawcy przed dostarczeniem poczty do Ciebie jawnym tekstem. MTA-STS pozwala opublikować politykę informującą, że Twoje serwery pocztowe obsługują uwierzytelniony TLS, a TLS-RPT informuje Cię, kiedy nadawcy nie mogli go uzyskać. Oba mechanizmy wdrożysz za pomocą dwóch rekordów DNS i jednego pliku tekstowego, a możesz zacząć w trybie przeznaczonym do miękkiego wdrożenia.

Co pozostawia otwarte STARTTLS

Szyfrowanie poczty między serwerami opiera się na rozszerzeniu STARTTLS i ma charakter oportunistyczny. RFC 8461 opisuje słaby punkt: atakujący, który potrafi usunąć odpowiedź "250 STARTTLS" z sesji SMTP albo przekierować ruch, nadpisując rozwiązany rekord MX, może wymusić downgrade lub przejąć sesję.

Drugim rozwiązaniem jest DANE, zdefiniowane w RFC 7672, ale wymaga ono DNSSEC. MTA-STS opiera się natomiast na urzędach certyfikacji i nie wymaga DNSSEC, „kosztem ryzyka złośliwych downgrade'ów", jak ujmuje to sam RFC. Jeśli już korzystasz z DANE, oba mechanizmy nie kolidują ze sobą: nadawcy implementujący MTA-STS nie mogą pozwolić, by nadpisał on nieudaną walidację DANE.

Wytyczne NCSC dotyczące bezpieczeństwa poczty mówią, że Twoja usługa powinna umieć wysyłać i odbierać pocztę z użyciem TLS oraz że należy chronić wszystkie domeny, także te hostowane u dostawców chmurowych, takich jak Google G Suite i Microsoft O365.

Krok pierwszy: polityka w trybie testing

MTA-STS składa się z dwóch części. Rekord TXT w _mta-sts.example.com zapowiada, że polityka istnieje, i podaje jej wersję:

_mta-sts.example.com. IN TXT "v=STSv1; id=20250101000000Z;"

Pole id składa się z liter i cyfr, ma do 32 znaków i musi jednoznacznie identyfikować daną wersję polityki. Nie ma tu domyślnej kolejności, więc znacznik czasu to raczej nawyk niż wymóg. Opublikuj dokładnie jeden taki rekord: nadawcy odrzucają rekordy niezaczynające się od v=STSv1;, a jeśli po tym liczba rekordów nie wynosi jeden, uznają, że nie masz polityki.

Samą politykę nadawcy pobierają przez HTTPS ze stałego adresu, który powstaje przez dopisanie mta-sts przed nazwą Twojej domeny:

https://mta-sts.example.com/.well-known/mta-sts.txt

Serwuj ją jako text/plain, ponieważ nadawcy mają sprawdzać typ medium. Plik wygląda tak:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

Każda linia mx: jest osobnym wpisem: pełną nazwą hosta albo wildcardem w postaci sufiksu, np. *.example.net. Wypisz wszystkie hosty z aktywnych rekordów MX, także te należące do dostawcy chmurowego.

Dostępne tryby to enforce, testing i none. RFC opisuje testing jako tryb opcjonalny, który umożliwia miękkie wdrożenia i wykrywanie błędów polityki, dlatego właśnie od niego warto zacząć.

Wartość max_age podaje się w sekundach, maksymalnie 31557600, a 604800 (tydzień) to przykład z samego RFC. RFC zakłada, że w produkcji będą to zwykle wartości rzędu tygodni lub dłuższe. Moja rada: na czas testów ustaw tydzień lub mniej, aby poprawiona polityka szybko trafiała do nadawców, a zwiększ wartość, gdy enforce będzie działać stabilnie.

Krok drugi: włącz TLS-RPT

Wykrywanie działa tylko wtedy, gdy nadawcy informują Cię o tym, co zaobserwowali. Publikujesz rekord TXT w _smtp._tls.example.com:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"

Pole rua może też być adresem URI https, wtedy nadawcy wysyłają raport metodą POST, dozwolona jest również lista oddzielona przecinkami. Podobnie jak w przypadku rekordu MTA-STS, dokładnie jeden rekord TXT musi zaczynać się od v=TLSRPTv1;, w przeciwnym razie nadawcy uznają, że nie wdrażasz tego mechanizmu.

Jeśli wybierzesz mailto, użyj dedykowanej skrzynki. Nadawcy dostarczają te raporty także wtedy, gdy TLS zawodzi, więc raport może dotrzeć niezaszyfrowany. Raporty wysyłane e-mailem muszą mieć prawidłowy podpis DKIM domeny raportującej, a RFC wymaga, by odbiorcy ignorowali te bez podpisu. Odrzucaj niepodpisane raporty zamiast się nimi sugerować.

Sprawdź, co widzą nadawcy

Odpytaj oba rekordy i pobierz plik polityki spoza swojej sieci:

dig TXT _mta-sts.example.com
dig TXT _smtp._tls.example.com
curl -si https://mta-sts.example.com/.well-known/mta-sts.txt

Wynik dig powinien pokazać po jednym rekordzie, z prefiksem v= na początku. Wynik curl powinien zawierać kod 200, nagłówek Content-Type: text/plain i treść polityki, więc sprawdź, czy mode i każda linia mx: są zgodne z zamierzeniem. Wszelkie błędy certyfikatu zgłaszane przez curl napraw, zanim opublikujesz rekord TXT.

Czytanie raportów

Raporty to pliki JSON obejmujące określony przedział czasu, z podsumowaniem dostarczeń zawierającym liczbę sukcesów i porażek. RFC dzieli błędy na negocjacji, polityki, ogólne i przejściowe. Raporty mogą przychodzić skompresowane (RFC definiuje application/tlsrpt+gzip), więc najpierw rozpakuj plik:

gzip -dc report.json.gz | jq .

Nazwy pól są zdefiniowane w sekcji 4.4 RFC 8460. Najpierw przeczytaj liczby z podsumowania, potem wpisy o błędach.

Raport z wysoką liczbą sukcesów i bez błędów to dokładnie to, co chcesz zobaczyć. RFC zauważa, że raport może pełnić rolę heartbeatu pokazującego, że TLS jest negocjowany zgodnie z oczekiwaniami, a stała seria czystych raportów to Twój dowód, że można iść dalej. Błędy wskazujące na jeden z Twoich hostów MX oznaczają certyfikat lub wzorzec mx, który trzeba poprawić. Jeden nadawca z wadliwym stosem to już jego problem.

Skok liczby błędów STARTTLS, którego nie możesz powiązać z żadną zmianą, zgłoś osobie odpowiedzialnej za incydenty albo naszemu zespołowi reagowania na incydenty, jeśli nikogo takiego nie masz.

Przejście na enforce

Poczekaj, aż raporty będą czyste dla całego typowego ruchu pocztowego, w tym dla rzadkich nadawców, takich jak miesięczne systemy fakturujące. Następnie zmień mode: testing na mode: enforce i zmień id w rekordzie TXT, ponieważ nadawcy porównują go ze swoją kopią w pamięci podręcznej, by dowiedzieć się, że coś się zmieniło.

Nadawcy mogą przechowywać politykę w cache przez okres do max_age od ostatniego pobrania, więc błąd może się utrzymywać. Usunięcie rekordu TXT także nie usuwa polityki z cache, na co zwraca uwagę RFC. Usuwanie opisuje sekcja 8.3 RFC 8461, którą warto przeczytać, zanim będzie potrzebna.

Od czego zacząć

1. Wypisz aktywne hosty MX, także te należące do dostawcy chmurowego, i upewnij się, że każdy przedstawia prawidłowy certyfikat zgodny z jego nazwą.
2. Skonfiguruj host mta-sts przez HTTPS i serwuj plik polityki jako text/plain z mode: testing.
3. Opublikuj pojedynczy rekord TXT _mta-sts ze świeżym id, a następnie wykonaj powyższe kontrole dig i curl.
4. Opublikuj rekord TXT _smtp._tls wskazujący na dedykowaną skrzynkę lub endpoint HTTPS i sprawdź całość konfiguracji za pomocą naszego narzędzia do sprawdzania bezpieczeństwa poczty.
5. Przeglądaj raporty przez co najmniej jeden pełny cykl biznesowy, wraz z procesami na koniec miesiąca (w większości organizacji to miesiąc). Napraw każdy błąd leżący po Twojej stronie, następnie przełącz na enforce i zmień id.