Przejdź do treści 
Pokażę ci, jak Serwer pocztowy TLS w Postfix i wybrać silne zestawy szyfrów, aby połączenia SMTP były konsekwentnie chronione. W oparciu o wypróbowane i przetestowane parametry dla TLS 1.2/1.3, DANE, MTA-STS i nowoczesnych par kluczy, poprowadzę Cię krok po kroku przez konfigurację, testowanie i strojenie, tak aby Twoje bezpieczeństwo poczty czysto chwyta.
Punkty centralne
- Postfix Bezpieczna konfiguracja: Aktywuj TLS, ogranicz protokoły, ustaw logowanie.
- Szyfr priorytety: ECDHE + GCM/CHACHA20, egzekwowanie PFS, blokowanie starszych danych.
- Certyfikaty zachowaj czystość: RSA+ECDSA, kompletny łańcuch, mocne zakrzywienia.
- DANE/MTA-STS wykorzystać: Wytyczne dotyczące zakotwiczenia i zmniejszenie ryzyka obniżenia ratingu.
- Testy i monitorowanie: Regularnie sprawdzaj OpenSSL, skaner TLS, logi MTA.
SMTP przez TLS: co jest naprawdę zabezpieczone?
Zabezpieczam SMTP za pomocą STARTTLS, aby transport wiadomości e-mail nie odbywał się w postaci zwykłego tekstu. Opportunistyczny TLS poprzez smtpd_tls_security_level = may zapewnia, że połączenia przychodzące korzystają z szyfrowania, gdy tylko stacja zdalna je zaoferuje. Dla połączeń wychodzących używam smtp_tls_security_level = dane Kontrole zasad obsługiwane przez DNSSEC, aby utrudnić ataki typu downgrade. Bez TLS wiadomości e-mail mogą być odczytywane i manipulowane podczas przesyłania, co jest szczególnie niebezpieczne w przypadku formularzy, zamówień lub danych konta. Dzięki aktywnemu TLS znacznie zmniejszam ryzyko podsłuchiwania i MITM, a także osiągam lepsze wskaźniki dostarczania, ponieważ duzi dostawcy korzystnie oceniają bezpieczne połączenia.
Klucze, certyfikaty i protokoły w Postfix
Mam przygotowane dwa certyfikaty: jeden RSA-certyfikat i certyfikat ECDSA, aby stare i nowe MTA były optymalnie połączone. Ścieżki w Postfixie ustawiam jasno, na przykład smtpd_tls_cert_file dla RSA i smtpd_tls_eccert_file dla ECDSA, każdy z pasującym kluczem. W przypadku czystego uwierzytelniania zwracam uwagę na kompletny łańcuch, CN/SAN, który dokładnie pasuje do hosta i krzywą taką jak secp384r1 dla klucza ECDSA. Ściśle dezaktywuję starsze protokoły, tj. SSLv2 i SSLv3, aby zapobiec wymuszonym aktualizacjom. Jeśli zastanawiasz się nad typem certyfikatu, spójrz na stronę DV, OV lub EV, aby wybrać odpowiedni poziom zaufania.
Wybór szyfru: Priorytety dla TLS 1.2/1.3
Priorytetem są zestawy szyfrów z PFS, tj. ECDHE przed DHE i używać GCM lub CHACHA20-POLY1305. Zgodnie z TLS 1.3, stos uwalnia cię od wielu starszych problemów, podczas gdy TLS 1.2 nadal wymaga jasnej listy. Niezabezpieczone lub słabe pakiety, takie jak RC4, Usuwam 3DES, CAMELLIA, aNULL, eNULL. Dla Postfix używam smtpd_tls_ciphers = high i restrykcyjny tls_high_cipherlist, aby nie prześlizgnęły się żadne przestarzałe algorytmy. Jeśli zagłębić się bardziej, to Przewodnik po pakietach szyfrujących łatwa do zrozumienia kategoryzacja bez balastu.
| Wersja TLS | Ulubione zestawy szyfrów | Status | Wskazówka |
|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 | aktywny | Wybór mocno osadzony w protokole, koniec ze starszymi problemami. |
| TLS 1.2 | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 | aktywny | Priorytet PFS, preferowane GCM/CHACHA. |
| Przestarzałe | RC4, 3DES, CAMELLIA, AES128-SHA, aNULL/eNULL | zablokowany | Całkowicie dezaktywować ze względów bezpieczeństwa. |
Postfix: konkretne parametry dla main.cf
Ustawiam przejrzystą konfigurację, aby MTA bezpiecznie rozmawiał zarówno przychodząco, jak i wychodząco. Dla efemerycznego ECDH, używam smtpd_tls_eecdh_grade Ustawiam jakość krzywej i wyłączam kompresję, aby uniknąć ataków podobnych do CRIME. Silny plik DH z 4096 bitami zapobiega słabym negocjacjom DHE. Nakładam twarde ograniczenia na protokoły i wymuszam wysoką jakość szyfrów, faworyzując TLS 1.3. Na początku umiarkowany poziom dziennika pomaga mi sprawdzać uściski dłoni bez zalewania dziennika.
Aktywacja i polityka #
smtpd_tls_security_level = may
smtp_tls_security_level = dane
Certyfikaty # (przykładowe ścieżki)
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.de.cer
smtpd_tls_key_file = /etc/ssl/private/mail.example.de.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.example.de_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.example.de_ecc.key
Protokoły i szyfry #
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = high
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra
Parametry DH #
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem
# DNSSEC/DANE (jeśli dostępne)
smtp_dns_support_level = dnssec
# Logowanie
smtpd_tls_loglevel = 1
Utrzymuję kompletny łańcuch certyfikatów, zwracam uwagę na prawidłowe uprawnienia dla prywatny pliki kluczy i sprawdzić logi po przeładowaniu. Jeśli TLS 1.2 jest wymagany dla starszych partnerów, trzymam się ściśle GCM/CHACHA i blokuję wszystko inne. W przypadku TLS 1.3 polegam na standardach stosu i unikam specjalnych ścieżek, które utrudniają konserwację. Zszywanie OCSP odgrywa rolę w SMTP tylko wtedy, gdy zapewnia je serwer proxy, więc sprawdzam to tylko dla odpowiednich konfiguracji. Po każdej zmianie sprawdzam poprawność za pomocą OpenSSL, aby wcześnie rozpoznać efekty uboczne i upewnić się, że Szyfrowanie wiadomości e-mail konsekwentnie.
Autentyczność transportu z DANE, MTA-STS, SPF, DKIM i DMARC
Łączę TLS z DANE, publikując podpisane rekordy TLSA w ramach DNSSEC. Ponadto ustawiam MTA-STS, aby zdalne urządzenia równorzędne wiedziały, że mój host wymaga TLS i którego MX powinny przestrzegać. W celu powiązania tożsamości podpisuję wychodzące wiadomości e-mail za pomocą DKIM i bezpieczne dostarczanie domen za pomocą reguł SPF. Wreszcie, DMARC definiuje, w jaki sposób odbiorcy powinni radzić sobie z odchyleniami, co znacznie utrudnia spoofing. Komponenty te współpracują ze sobą: TLS chroni transport, podczas gdy uwierzytelnianie wzmacnia nadawcę i zauważalnie zwiększa szybkość dostarczania.
Jeśli wydajność jest wąskim gardłem, optymalizuję wznawianie sesji, funkcje sprzętowe i sam handshake. Możesz zacząć od praktycznych sztuczek z Szybszy uścisk dłoni TLS, aby zmniejszyć opóźnienie podczas nawiązywania połączenia. Ważne: wybór szyfru i wznawianie połączenia powinny być zrównoważone, ponieważ słabe kompromisy nie opłacają się pod względem bezpieczeństwa. Szybkie negocjacje TLS przynoszą znaczne oszczędności, zwłaszcza przy dużej ilości poczty. W ten sposób Przepustowość i bezpieczeństwo w równowadze.
Testowanie, monitorowanie i audyty
Sprawdzam uściski dłoni lokalnie za pomocą openssl i sprawdzić wersję protokołu, szyfr i łańcuch certyfikatów. Polecenie openssl s_client -connect mail.example.de:25 -starttls smtp pokazuje mi na żywo, co negocjuje zdalny serwer. Po zmianach konfiguracji używam sprawdzenie postfix i przyjrzeć się w szczególności smtpd_tls_loglevel, aby wyizolować wzorce błędów. Zewnętrzne skanery TLS pomagają kategoryzować widoczność publiczną, zwłaszcza po zmianach certyfikatów. Regularny cykl audytu chroni przed pełzającym pogorszeniem, na przykład jeśli zmiana biblioteki wpływa na priorytety szyfrów.
Częste błędne konfiguracje i szybkie poprawki
Często widzę przestarzałe szyfry, takie jak AES128-SHA, które są nadal aktywne i zapobiegają PFS. Ścisły łańcuch szyfrujący i wyraźne blokowanie LOW/MD5/RC4/3DES pomaga tutaj. Drugi wzorzec: brakujące certyfikaty pośrednie, które uniemożliwiają stacjom zdalnym weryfikację łańcucha; dodaję plik bundle i testuję ponownie. Na urządzeniach takich jak Synology ustawiam profil TLS na nowoczesny i usuwam starsze opcje, aby serwer SMTP mówił nowocześnie. W przypadku Microsoft Exchange sprawdzam w szczególności zasady TLS 1.2/1.3, przypisanie certyfikatu na złącze i wszelkie nadpisania szyfrów w konfiguracji hosta, aby serwer SMTP działał w trybie nowoczesnym. Uścisk dłoni-wybór jest właściwy.
Podgląd: TLS 1.3, 0-RTT i Post-Quantum
Wolę TLS 1.3, ponieważ uścisk dłoni jest krótszy, a stare opcje są pomijane, co zmniejsza powierzchnie ataku. Wybór opcji szyfr Nie używam 0-RTT w kontekście SMTP, ponieważ ataki typu replay niosą ze sobą niepotrzebne ryzyko. W przyszłości mam oko na hybrydowe procedury post-kwantowe, które mogą znaleźć drogę do środowiska pocztowego, gdy tylko standaryzacja i wsparcie dojrzeją. Ważne jest, aby skonfigurować zasady i monitorowanie w taki sposób, aby nowe procedury można było później zintegrować bez zakłóceń.
Wydajność i szybkość dostawy w skrócie
Mierzę Opóźnienie uścisku dłoni TLS i zoptymalizować pamięci podręczne, aby umożliwić ich ponowne wykorzystanie. Wznawianie sesji (bilety/identyfikatory) zmniejsza obciążenie obliczeniowe i przyspiesza powtarzające się połączenia między MTA. W przypadku odwoływania certyfikatów polegam na informacjach o stosie w proxy upstream, jeśli są dostępne, aby zaoszczędzić dodatkowych dostępów. Duzi odbiorcy korzystnie oceniają bezpieczne transporty, co zwiększa szybkość dostarczania, podczas gdy niezabezpieczone ścieżki zwiększają ryzyko spamu i odrzucenia. Dzięki jasnej polityce TLS, solidnym wpisom DNS i czystemu łańcuchowi podpisów tworzę niezawodną podstawę dla Dostarczalność.
Mój harmonogram konfiguracji
Zaczynam od uzyskania certyfikatu od godnego zaufania CA, generuję ECDSA i RSA i przechowuję oba czysto na hoście. Następnie dostosowuję main.cf z parametrami TLS, ustawić silne szyfry i dezaktywować stare protokoły. Dodawany jest nowy plik DH z 4096 bitami, po czym następuje przeładowanie i pierwsze testy OpenSSL. Następnie konfiguruję DANE, dodaję MTA-STS i sprawdzam ważność SPF/DKIM/DMARC. Na koniec uruchamiam testy z zewnętrznymi celami, sprawdzam dzienniki podczas pracy i planuję regularne audyty, tak aby Konfiguracja pozostaje bezpieczny w dłuższej perspektywie.
Brakujące moduły: Submission, SMTPS i SNI
Zabezpieczam nie tylko port 25, ale także przesyłanie (587) i opcjonalnie SMTPS (465). W przypadku przesyłania wymuszam szyfrowanie i uwierzytelnianie, aby hasła użytkowników nigdy nie były wysyłane w postaci zwykłego tekstu. W master.cf Aktywuję usługi i ustawiam określone nadpisania:
Przesyłanie # (port 587) z STARTTLS i obowiązkiem autoryzacji
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
# SMTPS (port 465) jako tryb wrapper, jeśli jest wymagany
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
Jeśli obsługuję kilka domen pocztowych na jednym hoście z własnymi certyfikatami, używam SNI. Używam mapy SNI, aby przypisać odpowiednią ścieżkę certyfikatu dla każdego hosta docelowego i upewnić się, że klienci MUA również widzą prawidłowy certyfikat. W ten sposób zapewniam separację klientów ze spójną tożsamością TLS.
Zasady dla poszczególnych domen: precyzyjna kontrola
Oprócz polityki globalnej zarządzam również smtp_tls_policy_maps Wyjątki i zaostrzenia dla poszczególnych domen odbiorców. Pozwala mi to na stopniową migrację starszych partnerów lub egzekwowanie szczególnie surowych wymagań dla wrażliwych celów.
# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy (przykładowe wpisy)
example.org tylko dane
legacy.example.net may
secure.example.com secure
tylko dane wymusza ochronę DANE bez zależności od CA, bezpieczny wymaga ważnego łańcucha CA i odmawia dostarczenia zwykłego tekstu, może pozostaje oportunistyczna. Po zmianach buduję mapę za pomocą postmapa i przeładować Postfix.
DANE i MTA-STS: konkretne wdrożenie
Dla DANE Publikuję rekordy TLSA w DNSSEC. Wolę używać DANE-EE (3 1 1), ponieważ umożliwia przypięcie do klucza publicznego i ułatwia zmianę certyfikatu za pomocą tego samego klucza. Przykładowy rekord TLSA pod _25._tcp.mail.example.de wygląda następująco:
_25._tcp.mail.example.de. IN TLSA 3 1 1
Generuję skrót z certyfikatu ECDSA lub RSA i upewniam się, że obrócę go przed wygaśnięciem. Ważne jest, aby strefa DNS była podpisana, a łańcuch delegacji został zweryfikowany bez luk.
Dla MTA-STS Hostuję plik zasad przez HTTPS i dodaję wpis TXT DNS. W ten sposób określam, że zdalne urządzenia równorzędne korzystają z protokołu TLS i są akceptowane tylko ze zdefiniowanym MX. Minimalistyczny plik zasad:
wersja: STSv1
mode: enforce
mx: mail.example.de
max_age: 604800
Wpis TXT jest dodawany w DNS w sekcji _mta-sts.example.de z aktualną wersją. Opcjonalnie ustawiam TLS-RPT przez TXT pod _smtp._tls.example.de aby otrzymywać raporty o naruszeniach zasad. Ta telemetria pomaga mi rozpoznawać awarie, obniżenia i wadliwe certyfikaty na wczesnym etapie.
Zaostrzenie protokołów, określenie szyfru
Zaostrzam limity protokołów i wymuszam preferencje serwerów. TLS 1.0/1.1 są dziś zbędne; zezwalam tylko na TLS 1.2 i 1.3 w głębi i na zasadzie wychodzącej. Dla TLS 1.2 definiuję wyraźną listę pozytywną, aby wykluczyć mieszane zasoby starych szyfrów:
# Dodatkowe zabezpieczenia (main.cf)
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# Jawna lista szyfrów TLS 1.2 (tylko PFS + AEAD)
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!aNULL:!eNULL:!MD5:!RC4:!3DES:!CAMELLIA
# Użyj preferencji serwera
tls_preempt_cipherlist = yes
Upewniam się, że ECDHE jest faworyzowane, a DHE jest tylko rozwiązaniem awaryjnym. Aktualizuję mój plik DH; w TLS 1.3 nie odgrywa on żadnej roli, ale nadal jest przydatny w przypadku rzadkich działań DHE.
Wznawianie sesji i pamięć podręczna
Aby przyspieszyć działanie, aktywuję pamięć podręczną sesji dla klienta i serwera, aby ponowne połączenia były bardziej korzystne. Obciążenie procesora i opóźnienia są zauważalnie zmniejszone, szczególnie przy wysokiej przepustowości poczty:
Pamięć podręczna sesji # (main.cf)
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_connection_reuse = yes
Monitoruję współczynnik trafień w logach i upewniam się, że żaden z nich nie jest zbyt krótki. ticket_lifetimes w bibliotece TLS, aby spowolnić wznawianie. Ważne: wznowienie nie może osłabiać polityki; trzymam się tych samych wymagań dotyczących szyfrów.
Certyfikowana firma: Rotacja i konserwacja łańcucha
Automatyzuję odnawianie i przeładowywanie MTA, aby żadne wygasłe certyfikaty nie działały. Po każdym odnowieniu sprawdzam, czy certyfikaty liścia i pośrednie są w całości w pakiecie. W przypadku podwójnych operacji ECDSA/RSA upewniam się, że obie pary obracają się, zanim masowa zmiana spowoduje problemy dla klientów. Osobno testuję ścieżkę SNI i przesyłanie, ponieważ MUA mogą wykazywać inne wzorce błędów niż MTA.
Pogłębione rejestrowanie i diagnostyka
Tymczasowo zwiększam głębokość dziennika, gdy pojawia się problem i używam narzędzi pokładowych do kontroli krzyżowych:
# ukierunkowane logowanie (main.cf)
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
Z posttls-finger target.example.com Sprawdzam, jakich zasad oczekuje zdalny MTA i jakie szyfry/protokoły są negocjowane. Używam postconf -n | grep tls, aby zobaczyć tylko jawnie ustawione parametry TLS; w ten sposób mogę szybciej znaleźć odchylenia od wartości domyślnych. W logach wyszukuję takie terminy jak brak współdzielonego szyfru, weryfikacja certyfikatu nie powiodła się lub wersja protokołu, które bezpośrednio wskazują na niedopasowanie szyfru, problemy z łańcuchem lub zbyt surowe/zbyt luźne limity protokołu.
Zarządzanie kompatybilnością bez poświęcania bezpieczeństwa
Świadomie planuję przejścia: jestem na bieżąco z może, aby uniknąć utraty poczty ze starszych serwerów, ale rejestruję dostawy zwykłego tekstu. Wychodzące pozostaję ścisłe (DANE/MTA-STS/secure) i używam smtp_tls_policy_maps dla indywidualnych przypadków. Jeśli poszczególni partnerzy mogą zarządzać tylko TLS 1.2 z AES-GCM, jest to akceptowalne; zarządzam wszystkim poniżej tego poziomu poprzez uzgodnione wyjątki z ograniczonym czasem działania, dokumentuję je i uwzględniam w planowaniu migracji. Utrzymuje to ogólny poziom na wysokim poziomie bez blokowania operacji biznesowych.
Domyślne ustawienia TLS systemu w skrócie
Należy pamiętać, że Postfix korzysta z systemowej biblioteki TLS. Aktualizacje OpenSSL/LibreSSL mogą zmienić priorytety szyfrów i zachowanie TLS 1.3. Dlatego po aktualizacjach systemu losowo sprawdzam uściski dłoni i porównuję dane wyjściowe postconf -n z moimi wartościami docelowymi. Zestaw compatibility_level w Postfixie pomaga utrzymać stabilne ustawienia domyślne, ale nie polegam na nim ślepo i dokumentuję wyraźne odchylenia w main.cf/master.cf.
Krótkie podsumowanie dla administratorów
Chciałbym podkreślić, że silne szyfry z PFS, czyste certyfikaty i jasne zasady są niezbędne dla SMTP kluczowe. TLS 1.3 uwalnia od starszych problemów, podczas gdy TLS 1.2 wymaga zdyscyplinowanej listy szyfrów. DANE i MTA-STS wzmacniają ścieżkę transportową, SPF/DKIM/DMARC zabezpieczają tożsamość i raportowanie. Regularne testy i analizy dzienników pokazują wcześnie, czy zmiana ma niepożądane skutki uboczne. Dzięki temu przewodnikowi możesz skonfigurować swój serwer pocztowy tak, aby był bezpieczny, wydajny i przyszłościowy - bez zbędnych kosztów. Ryzyko.
