SMTP Authentication (SASL) — jak chronić serwer przed spamem

Wyobraź sobie, że zostawiasz klucz do biura pod wycieraczką z kartką „Wejdź i skorzystaj z telefonu". Dokładnie tak wygląda serwer pocztowy bez włączonej SMTP authentication — każdy może się podłączyć i wysłać wiadomości w Twoim imieniu. W tym artykule wyjaśnisz sobie, czym jest SASL SMTP, dlaczego brak autoryzacji to prosta droga do blacklisty i jak w kilku krokach zabezpieczyć serwer oparty na Postfixie.

Czym jest SMTP Authentication i skąd pochodzi SASL?

Protokół SMTP (Simple Mail Transfer Protocol) w swojej pierwotnej specyfikacji z 1982 roku (RFC 821) nie przewidywał żadnego mechanizmu uwierzytelniania. Zakładano, że z poczty korzystają zaufane instytucje akademickie i rządowe. Internet wyglądał wtedy zupełnie inaczej niż dziś.

SMTP Authentication to rozszerzenie protokołu opisane w RFC 4954, które wymaga od klienta pocztowego podania loginu i hasła przed wysłaniem wiadomości. Mechanizm ten opiera się na SASL (Simple Authentication and Security Layer) — warstwie abstrakcji zdefiniowanej w RFC 4422, która pozwala protokołom aplikacyjnym korzystać z wymiennych metod uwierzytelniania bez zmiany samego protokołu.

Jak działa wymiana SASL podczas sesji SMTP?

Kiedy klient łączy się z serwerem, negocjacja przebiega w kilku krokach:

1. Klient wysyła EHLO — serwer odpowiada listą obsługiwanych rozszerzeń, w tym AUTH LOGIN PLAIN CRAM-MD5.
2. Klient wybiera metodę, np. AUTH LOGIN, i przesyła zakodowane w Base64 dane uwierzytelniające.
3. Serwer weryfikuje dane przez wewnętrzną bazę użytkowników lub zewnętrzny mechanizm (np. Cyrus SASL, Dovecot SASL).
4. Po pozytywnej weryfikacji serwer zwraca 235 2.7.0 Authentication successful i pozwala na wysyłkę.

Cała ta wymiana powinna odbywać się wyłącznie po nawiązaniu szyfrowanego połączenia TLS — inaczej login i hasło wędrują siecią w postaci łatwej do przechwycenia.

Open Relay SMTP — co to znaczy i dlaczego to katastrofa?

Open relay SMTP to serwer, który przyjmuje i przekazuje wiadomości od dowolnego nadawcy do dowolnego odbiorcy — bez żadnego uwierzytelnienia. W latach 90. większość serwerów działała właśnie w ten sposób. Dziś open relay to synonim serwera spamerskiego.

Jak spamerzy wykrywają otwarte serwery?

Narzędzia do skanowania portów (np. Shodan, massscan) potrafią w ciągu kilku godzin przeskanować całą przestrzeń adresową IPv4 w poszukiwaniu otwartego portu 25. Gdy znajdą odpowiedź 220 bez wymagania AUTH, automatycznie wpisują serwer na listę kandydatów do nadużycia. Szacuje się, że niezabezpieczony serwer trafia na taką listę w ciągu 24–72 godzin od uruchomienia.

Konsekwencje działania jako open relay

• Blacklisty IP — organizacje takie jak Spamhaus, SORBS czy Barracuda automatycznie blokują adresy IP serwerów-relayów. Usunięcie z listy potrwa od kilku dni do kilku tygodni.
• Zablokowanie przez dostawców — Gmail, Outlook i inni giganci odrzucają pocztę z oznaczonych adresów IP, często bez powiadomienia nadawcy.
• Przeciążenie serwera — masowa wysyłka spamu przez Twój serwer może całkowicie wyczerpać zasoby CPU i przepustowość łącza.
• Odpowiedzialność prawna — rozsyłanie niechcianych wiadomości handlowych narusza art. 10 ustawy o świadczeniu usług drogą elektroniczną oraz przepisy RODO dotyczące przetwarzania danych osobowych (art. 5 ust. 1 lit. f — integralność i poufność).

Metody uwierzytelniania SASL — porównanie

Nie każda metoda SASL oferuje ten sam poziom bezpieczeństwa. Poniższa tabela pokazuje najczęściej spotykane mechanizmy i ich charakterystykę:

W praktyce dla małych i średnich firm najczęściej stosuje się PLAIN lub LOGIN wyłącznie po TLS albo coraz popularniejszy SCRAM-SHA-256 obsługiwany przez nowsze wersje Dovecota i Postfixa.

Konfiguracja SASL w Postfixie — krok po kroku

Postfix nie implementuje SASL samodzielnie — deleguje uwierzytelnianie do zewnętrznej biblioteki. Najpopularniejsze opcje to Cyrus SASL (libsasl2) oraz Dovecot SASL. Poniżej opisujemy konfigurację z Dovecot SASL, która jest prostsza w utrzymaniu i lepiej integruje się z serwerem IMAP.

Krok 1 — Włącz SASL w Dovecot

Upewnij się, że plik /etc/dovecot/conf.d/10-master.conf zawiera blok udostępniający gniazdo UNIX dla Postfixa:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

Następnie w pliku /etc/dovecot/conf.d/10-auth.conf ustaw obsługiwane mechanizmy:

auth_mechanisms = plain login scram-sha-256

Krok 2 — Skonfiguruj Postfix

W pliku /etc/postfix/main.cf dodaj lub zmodyfikuj następujące dyrektywy:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes

Dyrektywa smtpd_sasl_security_options = noanonymous blokuje logowanie bez podania danych. broken_sasl_auth_clients = yes zapewnia kompatybilność ze starszymi klientami pocztowymi (np. Outlook 2003), które wysyłają nagłówek AUTH w niestandardowej formie.

Krok 3 — Wymuś TLS przed uwierzytelnieniem

Nigdy nie pozwalaj na przesyłanie danych logowania niezaszyfrowanym kanałem. W main.cf dodaj:

smtpd_tls_security_level = may
smtpd_tls_auth_only = yes

Dyrektywa smtpd_tls_auth_only = yes to kluczowe zabezpieczenie — Postfix odmówi przyjęcia komend AUTH dopóki klient nie nawiąże sesji TLS przez STARTTLS.

Krok 4 — Ogranicz przekazywanie poczty tylko dla uwierzytelnionych

Dodaj do smtpd_relay_restrictions (lub smtpd_recipient_restrictions w starszych wersjach):

smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination

Ta trójka reguł oznacza: zezwól serwerom z zaufanej sieci, zezwól zalogowanym użytkownikom, odrzuć wszystkich pozostałych próbujących przekazać pocztę do zewnętrznych domen. To jest dokładne przeciwieństwo open relay.

Krok 5 — Zrestartuj usługi i przetestuj

Po zapisaniu zmian zrestartuj Dovecota i Postfixa:

systemctl restart dovecot postfix

Następnie przetestuj konfigurację narzędziem telnet lub openssl s_client:

openssl s_client -starttls smtp -connect twojadomena.pl:587

Po nawiązaniu sesji TLS wpisz EHLO test — w odpowiedzi powinieneś zobaczyć linię 250-AUTH PLAIN LOGIN SCRAM-SHA-256. Możesz też skorzystać z serwisu mail-tester.com lub mxtoolbox.com → SMTP Test, które sprawdzą, czy serwer nie działa jako open relay.

Najczęstsze błędy konfiguracyjne i jak ich unikać

Błąd 1 — AUTH dostępne bez TLS

Jeśli pominiesz smtpd_tls_auth_only = yes, klient może przesłać login i hasło w Base64 przez niezaszyfrowane połączenie. Base64 to kodowanie, nie szyfrowanie — każdy sniffujący ruch w sieci odczyta dane w ciągu sekund. Zawsze wymuszaj STARTTLS lub używaj portu 465 z natywnym TLS (SMTPS).

Błąd 2 — Zbyt liberalne smtpd_relay_restrictions

Reguła permit_mynetworks zezwala na wysyłkę wszystkim hostom z sieci zdefiniowanej w dyrektywie mynetworks. Jeśli przez pomyłkę wpiszesz tam zbyt szeroki zakres (np. 0.0.0.0/0), de facto tworzysz open relay pomimo włączonego SASL. Sprawdzaj konfigurację poleceniem postconf mynetworks.

Błąd 3 — Brak limitu prób logowania

Włączona autoryzacja SMTP nie chroni automatycznie przed atakami brute-force. Warto uzupełnić konfigurację o fail2ban z filtrem postfix-sasl, który blokuje adresy IP po kilku nieudanych próbach logowania. Standardowa konfiguracja fail2ban śledzi wpisy w /var/log/mail.log zawierające frazy SASL LOGIN authentication failed.

Błąd 4 — Używanie przestarzałych mechanizmów

Mechanizm CRAM-MD5 był popularny w latach 2000., ale MD5 jest dziś kryptograficznie złamany. Jeśli Twój serwer nadal go oferuje, usuń go z listy auth_mechanisms w konfiguracji Dovecota. Preferuj SCRAM-SHA-256 lub przynajmniej PLAIN po TLS.

SMTP Authentication a zgodność z RODO i dobrymi praktykami bezpieczeństwa

Brak uwierzytelniania SMTP może mieć konsekwencje nie tylko techniczne, ale i prawne. Jeśli Twój serwer zostanie przejęty przez spamerów i użyty do wysyłki wiadomości zawierających dane osobowe (np. listy adresów e-mail klientów), możesz odpowiadać za naruszenie art. 32 RODO — obowiązku wdrożenia odpowiednich środków technicznych zapewniających bezpieczeństwo przetwarzania danych. Urząd Ochrony Danych Osobowych nakładał już kary za niewystarczające zabezpieczenia techniczne infrastruktury IT.

Włączona autoryzacja SMTP to również jeden z wymogów wynikających pośrednio z dyrektywy NIS2 (implementowanej w Polsce jako ustawa o krajowym systemie cyberbezpieczeństwa), która nakłada na operatorów usług cyfrowych obowiązek zarządzania ryzykiem i wdrażania środków minimalizujących podatność na ataki.

Jeśli korzystasz z narzędzi do masowej wysyłki, takich jak MailerPRO, pamiętaj, że poprawna konfiguracja SASL na poziomie własnego serwera SMTP to fundament — platforma może dostarczyć zaawansowane funkcje śledzenia i zarządzania kampaniami, ale bezpieczeństwo warstwy transportowej zawsze leży po stronie administratora serwera.

Podsumowanie — checklista zabezpieczenia SMTP

Zanim uznasz serwer pocztowy za bezpieczny, sprawdź każdy punkt z poniższej listy:

• ✅ SASL włączony — dyrektywa smtpd_sasl_auth_enable = yes w Postfixie
• ✅ TLS wymagany przed AUTH — smtpd_tls_auth_only = yes
• ✅ Przekazywanie tylko dla uwierzytelnionych — permit_sasl_authenticated + reject_unauth_destination
• ✅ Brak anonimowego logowania — smtpd_sasl_security_options = noanonymous
• ✅ Nowoczesne mechanizmy SASL — PLAIN/LOGIN po TLS lub SCRAM-SHA-256
• ✅ Ochrona przed brute-force — fail2ban z filtrem postfix-sasl
• ✅ Test open relay — weryfikacja przez mxtoolbox lub mail-tester
• ✅ Certyfikat TLS aktualny — Let's Encrypt z auto-odnowieniem (certbot)

Konfiguracja SMTP Authentication z SASL to nie opcjonalny dodatek — to absolutne minimum dla każdego serwera pocztowego wystawionego na internet. Bez niej ryzykujesz wylądowanie na blacklistach, przeciążenie infrastruktury i potencjalne naruszenie przepisów o ochronie danych. Wdróż opisane kroki, przetestuj konfigurację zewnętrznym narzędziem i ustaw monitoring logów mailowych — Twój serwer (i reputacja domeny) podziękują Ci za to znacznie niższym wskaźnikiem odrzuceń i lepszą dostarczalnością wiadomości.