Bezpieczeństwo serwera SMTP: 10 konfiguracji [2024]

Twój serwer SMTP może być najsłabszym ogniwem całej infrastruktury IT — i często jest, bo administratorzy skupiają się na hardeningu serwerów webowych, a pocztowe zostawiają z domyślnymi ustawieniami. Efekt? Otwarte przekaźniki, bruteforce na port 25, wycieki danych i lądowanie na czarnych listach RBL. Ten artykuł to lista 10 konkretnych konfiguracji bezpieczeństwa serwera SMTP, które możesz wdrożyć jeszcze dziś — z wyjaśnieniem, dlaczego każda z nich ma znaczenie.

1. Zablokuj open relay SMTP — priorytet absolutny

Open relay to serwer SMTP, który przyjmuje i przekazuje wiadomości od dowolnego nadawcy do dowolnego odbiorcy, bez uwierzytelniania. Spamerzy aktywnie skanują internet w poszukiwaniu takich serwerów — znaleziony open relay trafia na listy RBL (np. Spamhaus ZEN) w ciągu minut.

W Postfixie wystarczy poprawna konfiguracja dyrektywy smtpd_relay_restrictions. Minimalna bezpieczna konfiguracja wygląda tak:

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Przetestuj swój serwer narzędziem MXToolbox Open Relay Test lub telnetem — wyślij wiadomość testową bez uwierzytelnienia do zewnętrznej domeny. Jeśli serwer ją przyjął, masz problem do natychmiastowego rozwiązania.

2. Wymuś uwierzytelnianie SMTP (SMTP AUTH) z silnymi mechanizmami

Uwierzytelnianie SMTP to podstawa — bez niego każdy, kto ma dostęp do portu, może nadawać w imieniu Twojej domeny. Włącz SASL (Simple Authentication and Security Layer) i ogranicz dostępne mechanizmy wyłącznie do bezpiecznych.

Mechanizmy, które należy wyłączyć

• PLAIN i LOGIN bez TLS — przesyłają hasło w base64, które trivialnie zdekodować
• CRAM-MD5 — podatny na ataki słownikowe offline
• NTLM — przestarzały, liczne znane podatności

Co włączyć zamiast tego

• PLAIN/LOGIN wyłącznie po zestawieniu TLS (dyrektywa smtpd_tls_auth_only = yes w Postfixie)
• SCRAM-SHA-256 — jeśli Twój serwer i klienci go obsługują (Dovecot od wersji 2.3)

Pamiętaj: mechanizm uwierzytelniania jest tyle wart, ile siła hasła. Wymuś politykę haseł minimum 12 znaków z cyframi i znakami specjalnymi.

3. Wdróż TLS 1.2/1.3 i wyłącz przestarzałe protokoły

Szyfrowanie w tranzycie to nie opcja — to wymóg. RODO (art. 32 rozporządzenia 2016/679) nakazuje stosowanie odpowiednich środków technicznych ochrony danych, a szyfrowanie komunikacji pocztowej jest wprost wymieniane w wytycznych ENISA jako środek baseline.

Co wyłączyć natychmiast

W Postfixie ustaw: smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 oraz smtpd_tls_mandatory_protocols = TLSv1.2, TLSv1.3. Certyfikat SSL pobierz z Let's Encrypt (certbot) lub od komercyjnego CA.

4. Skonfiguruj SPF, DKIM i DMARC

Trio SPF/DKIM/DMARC to standard uwierzytelniania e-mail na poziomie DNS — bez nich każdy może podszyć się pod Twoją domenę. Od lutego 2024 roku Google i Yahoo wymagają ich obecności od nadawców wysyłających ponad 5 000 wiadomości dziennie, ale warto wdrożyć je niezależnie od wolumenu.

SPF (Sender Policy Framework)

Rekord TXT w DNS definiuje, które serwery IP mają prawo wysyłać pocztę z Twojej domeny. Przykład: v=spf1 ip4:203.0.113.10 include:_spf.mailerPRO.pl ~all. Użyj -all (hard fail) zamiast ~all (soft fail) gdy masz pewność co do wszystkich źródeł wysyłki.

DKIM (DomainKeys Identified Mail)

Kryptograficzny podpis nagłówka wiadomości — odbiorca weryfikuje go kluczem publicznym w DNS. Używaj kluczy RSA 2048-bit lub Ed25519. Rotuj klucze przynajmniej raz na 6 miesięcy.

DMARC (Domain-based Message Authentication)

Polityka definiująca, co zrobić z wiadomościami, które nie przejdą SPF lub DKIM. Zacznij od p=none (monitorowanie), po analizie raportów przejdź do p=quarantine, docelowo p=reject. Raporty agregowane (tag rua) wysyłaj na dedykowaną skrzynkę lub narzędzie analityczne.

5. Firewall — ogranicz dostęp do portów SMTP

Konfiguracja bezpiecznego SMTP wymaga przemyślanej polityki firewall. Port 25 (SMTP między serwerami) powinien być dostępny tylko dla zaufanych serwerów MX i Twojej infrastruktury — nie dla klientów końcowych.

Rekomendowana mapa portów

W iptables lub nftables zastosuj domyślną politykę DROP i otwieraj tylko wymienione porty. Dla portu 25 rozważ dodatkowe ograniczenie do znanych zakresów IP operatorów hostingowych i ISP — znacząco redukuje to ruch spamowy jeszcze przed dotarciem do aplikacji.

6. Wdróż fail2ban dla ochrony przed bruteforce

Ataki bruteforce na uwierzytelnianie SMTP to codzienność — skanery automatycznie próbują tysięcy kombinacji login/hasło na minutę. Fail2ban monitoruje logi i automatycznie banuje adresy IP po zdefiniowanej liczbie nieudanych prób.

Konfiguracja jail dla Postfix

W pliku /etc/fail2ban/jail.local dodaj sekcję:

[postfix-sasl]
enabled = true
port = smtp,465,587
filter = postfix-sasl
logpath = /var/log/mail.log
maxretry = 5
findtime = 300
bantime = 3600

Oznacza to: 5 nieudanych prób w ciągu 5 minut = ban na 1 godzinę. Dla podwyższonego bezpieczeństwa ustaw bantime = -1 (permanentny ban) z białą listą własnych IP. Monitoruj statystyki: fail2ban-client status postfix-sasl — zdrowy serwer blokuje dziesiątki IP dziennie.

Fail2ban a IPv6

Pamiętaj o włączeniu obsługi IPv6 — coraz więcej ataków pochodzi z adresów v6. Ustaw allowipv6 = auto w sekcji [DEFAULT] i upewnij się, że backend iptables obsługuje ip6tables.

7. Ogranicz limity połączeń i szybkość wysyłki (rate limiting)

Nawet po uwierzytelnieniu użytkownik może być źródłem problemu — przejęte konto wysyła spam z prawidłowymi danymi logowania. Rate limiting pozwala wykryć i ograniczyć takie sytuacje zanim wyrządzą szkodę.

Parametry do skonfigurowania w Postfixie

• smtpd_client_connection_rate_limit = 30 — max 30 połączeń na minutę z jednego IP
• smtpd_client_message_rate_limit = 100 — max 100 wiadomości na minutę od jednego klienta
• smtpd_client_recipient_rate_limit = 50 — max 50 odbiorców na minutę
• anvil_rate_time_unit = 60s — okno czasowe dla powyższych limitów

Dostosuj wartości do swojego profilu wysyłki — zbyt restrykcyjne limity mogą blokować legalne kampanie mailingowe. Jeśli wysyłasz duże wolumeny przez MailerPRO lub podobne narzędzie, skonsultuj limity z dostawcą SMTP i ustaw je z 20% marginesem powyżej typowego szczytu.

8. Skonfiguruj DANE i MTA-STS dla szyfrowania w tranzycie

TLS na serwerze to dopiero połowa sukcesu — musisz też zadbać o to, żeby inne serwery łączyły się z Tobą przez TLS, a nie fallback do plain text. Tu wchodzą dwa mechanizmy:

MTA-STS (Mail Transfer Agent Strict Transport Security)

Publikujesz plik polityki pod adresem https://mta-sts.twojadomena.pl/.well-known/mta-sts.txt oraz rekord DNS _mta-sts.twojadomena.pl TXT. Polityka informuje inne serwery, że Twój MX wymaga TLS i jak postępować przy błędach certyfikatu. Tryb enforce odrzuca połączenia bez TLS; zacznij od testing.

DANE (DNS-Based Authentication of Named Entities)

DANE publikuje odcisk palca certyfikatu TLS w rekordzie DNS TLSA, zabezpieczonym przez DNSSEC. Wymaga wdrożenia DNSSEC na domenie — bez tego DANE nie działa. Jest to mechanizm bardziej zaawansowany, ale eliminuje ryzyko ataków MITM nawet przy kompromitacji CA.

9. Regularny audyt logów i monitoring anomalii

Żadna konfiguracja nie zastąpi bieżącego monitoringu. Logi serwera SMTP to kopalnia informacji o próbach ataków, błędach konfiguracji i nieprawidłowym zachowaniu kont.

Co monitorować

• Nieudane próby AUTH — wzrost o ponad 50% względem baseline to sygnał ataku
• Bounce rate — nagły wzrost może oznaczać przejęte konto wysyłające spam
• Wolumen wysyłki per konto — odchylenia od normy powyżej 3 odchyleń standardowych
• Nowe adresy IP łączące się przez AUTH — logowanie z nieznanej lokalizacji
• Wpisy na listach RBL — sprawdzaj codziennie (MXToolbox, MultiRBL)

Scentralizuj logi w systemie SIEM (np. Graylog, Elastic Stack) lub przynajmniej skonfiguruj alerty e-mail/SMS dla krytycznych zdarzeń. NIS2 (dyrektywa 2022/2555, implementowana w Polsce jako ustawa o KSC) nakłada na operatorów usług kluczowych i ważnych obowiązek monitorowania incydentów i raportowania ich w ciągu 24 godzin — dobrze skonfigurowany monitoring to nie tylko bezpieczeństwo, ale i compliance.

10. Aktualizacje, hardening systemu operacyjnego i zasada minimalnych uprawnień

Nawet idealnie skonfigurowany Postfix jest bezużyteczny, jeśli system operacyjny ma niezałatane podatności. Hardening serwera pocztowego to proces całościowy — obejmuje zarówno aplikację, jak i OS.

Checklista hardeningu OS pod serwer SMTP

1. Automatyczne aktualizacje bezpieczeństwa — unattended-upgrades na Debianie/Ubuntu, dnf-automatic na RHEL/Rocky
2. Uruchamiaj demona SMTP jako nieprivilegowany użytkownik — Postfix robi to domyślnie (użytkownik postfix), sprawdź konfigurację innych MTA
3. Chroot dla procesów SMTP — Postfix obsługuje chroot per-daemon w master.cf
4. Wyłącz zbędne usługi — serwer pocztowy nie potrzebuje FTP, Telnetu ani innych usług; każda otwarta usługa to potencjalny wektor ataku
5. SSH tylko na kluczach — wyłącz logowanie hasłem (PasswordAuthentication no w sshd_config), zmień port SSH z 22
6. Regularne skanowanie podatności — OpenVAS, Lynis (audyt lokalny), lub zewnętrzny pentest raz na kwartał

Zarządzanie certyfikatami TLS

Certyfikaty Let's Encrypt wygasają po 90 dniach — skonfiguruj automatyczne odnawianie przez certbot renew w cronie lub systemd timer i dodaj hook do przeładowania Postfixa po odnowieniu. Wygasły certyfikat to jeden z najczęstszych powodów problemów z dostarczalnością i bezpieczeństwem jednocześnie.

Podsumowanie: bezpieczeństwo SMTP to proces, nie jednorazowa konfiguracja

Wdrożenie tych 10 konfiguracji znacząco podnosi poziom bezpieczeństwa serwera SMTP — ale pamiętaj, że krajobraz zagrożeń zmienia się stale. Ustaw cykliczny przegląd konfiguracji (minimum raz na kwartał), śledź CVE dla używanego oprogramowania i subskrybuj listy mailingowe projektów takich jak Postfix czy Dovecot. Jeśli zarządzasz wysyłką e-mail dla wielu klientów lub dużych wolumenów, rozważ platformę taką jak MailerPRO, która dostarcza gotową, zahardowaną infrastrukturę SMTP z wbudowanym monitoringiem reputacji — zamiast budować wszystko od zera. Najlepsza konfiguracja to ta, którą faktycznie wdrożysz i będziesz utrzymywać.