brak uwierzytelnienia SMTP

Brak uwierzytelnienia SMTP to luka bezpieczeństwa dopuszczająca wysyłkę poczty bez weryfikacji tożsamości nadawcy.

Na czym polega brak uwierzytelnienia SMTP

Brak uwierzytelnienia SMTP oznacza sytuację, w której serwer pocztowy przyjmuje wiadomości od klienta bez sprawdzenia jego tożsamości. W standardowym przebiegu sesji klient nawiązuje połączenie, przedstawia się poleceniem EHLO lub HELO, a następnie może użyć rozszerzenia AUTH. Mechanizm uwierzytelniania SMTP jest opisany w dokumencie RFC 4954. Jeżeli serwer nie wymaga potwierdzenia uprawnień przed przyjęciem wiadomości, dowolny klient może próbować przekazać pocztę bez podania poprawnego loginu i hasła.

Samo dopuszczenie połączenia bez logowania nie zawsze oznacza błąd konfiguracji. Serwer może świadomie przyjmować pocztę na porcie 25 od innych serwerów pocztowych, ponieważ komunikacja między serwerami SMTP nie jest zwykle oparta na logowaniu użytkownika. Problem pojawia się wtedy, gdy nieautoryzowany klient może wysyłać wiadomości przez serwer do obcych domen albo korzystać z niego poza określoną siecią zaufaną. W takim przypadku brak uwierzytelnienia może prowadzić do działania serwera jako otwartego przekaźnika, czyli open relay.

Różnica między odbiorem poczty a wysyłką przez relay

SMTP rozdziela kilka operacji, które często są mylone podczas analizy konfiguracji. Serwer może przyjmować wiadomości adresowane do własnych domen bez uwierzytelnienia, ponieważ pełni funkcję serwera odbiorczego. Nie powinien jednak automatycznie przekazywać poczty od nieznanego klienta do dowolnej domeny internetowej. O tym, czy wiadomość może zostać wysłana dalej, decydują reguły relay, lista lokalnych domen, adres źródłowy połączenia oraz stan uwierzytelnienia.

Do praktycznego sprawdzenia przepływu używa się między innymi odpowiedzi serwera na polecenia MAIL FROM i RCPT TO. Przy próbie przekazania wiadomości do obcej domeny poprawnie ograniczony serwer powinien odmówić przyjęcia odbiorcy albo wymagać wcześniejszego uwierzytelnienia. Samo podanie dowolnego adresu w polu MAIL FROM nie potwierdza tożsamości nadawcy. Ten adres należy do koperty SMTP i może zostać zmieniony przez klienta, podobnie jak nagłówki widoczne dla odbiorcy.

Skutki konfiguracji bez wymagania AUTH

Najpoważniejszym skutkiem jest możliwość wykorzystania serwera do masowej wysyłki spamu, wiadomości phishingowych albo komunikatów z fałszywym adresem nadawcy. Serwer może wtedy trafić na listy blokad, a wiadomości wysyłane przez uprawnionych użytkowników mogą częściej otrzymywać status spamu. Ryzyko dotyczy także obciążenia procesora, pamięci, kolejki pocztowej i łącza sieciowego. W skrajnym przypadku duża liczba zadań oczekujących w kolejce może utrudnić dostarczanie prawidłowej korespondencji.

Brak uwierzytelnienia nie jest tym samym co brak szyfrowania. Uwierzytelnienie odpowiada za sprawdzenie, kto może korzystać z funkcji wysyłania, natomiast TLS chroni transmisję przed odczytem lub modyfikacją podczas przesyłania. Rozszerzenie STARTTLS opisuje RFC 3207, a zalecenia dotyczące szyfrowanego przesyłania poczty na porcie 465 zawiera RFC 8314. Konfiguracja może więc wymagać logowania, ale jednocześnie przesyłać dane bez odpowiednio wymuszonego szyfrowania, albo używać szyfrowania bez właściwego ograniczenia relay. Są to odrębne elementy kontroli bezpieczeństwa.

Sprawdzenie reguł dostępu i przywrócenie prawidłowego działania

Diagnostyka powinna rozpocząć się od ustalenia, z jakiego portu i z jakiej sieci korzysta klient. Port 25 służy przede wszystkim do komunikacji SMTP między serwerami, natomiast port 587 jest przeznaczony do składania wiadomości przez klienta pocztowego, czyli submission. W tym drugim przypadku serwer powinien jednoznacznie określać, kiedy wymagane jest AUTH, jakie mechanizmy logowania są dozwolone i czy przed uwierzytelnieniem musi zostać ustanowiony kanał TLS. Należy także sprawdzić, czy konto po zalogowaniu może wysyłać wyłącznie w ramach przyznanych uprawnień.

Weryfikacja obejmuje konfigurację dozwolonych nadawców i odbiorców, reguły relay, wyjątki dla adresów IP, limity wiadomości oraz logi sesji SMTP. Test powinien obejmować zarówno poprawne logowanie, jak i próbę wysyłki bez polecenia AUTH do własnej oraz obcej domeny. Po zmianie ustawień trzeba potwierdzić, że lokalny odbiór nadal działa, autoryzowani użytkownicy mogą wysyłać pocztę, a nieautoryzowany klient otrzymuje odmowę. Takie rozróżnienie pozwala usunąć rzeczywistą lukę bez wyłączenia legalnej komunikacji między serwerami pocztowymi.