« poprzedni punkt  następny punkt »


4. Protokoły pocztowe a bezpieczeństwo

Zagrożenia związane z protokołem SMTP

Protokół SMTP nie jest bezpieczny, ponieważ nawet mało doświadczonemu użytkownikowi umożliwia bezpośrednią negocjację z otrzymującym i przekazującym pocztę dalej serwerem SMTP i oszukanie odbiorcy tak, by wierzył, iż przesyłka przyszła od kogoś innego.

Największym zagrożeniem związanym z SMTP jest fakt, iż przesyłki przekazywane przy pomocy tego protokołu nie są w żaden sposób szyfrowane. W polu danych protokołów warstw niższych jest przekazywany nie zabezpieczony przed utratą poufności tekst przesyłki. Jeśli zagrożenia dla poufności informacji nie są likwidowane poprzez niższe warstwy stosu protokołów, to przesyłka będzie mocno narażona na utratę poufności.

Nie stosuje się autoryzacji nadawcy przy wysyłaniu poczty, ani też żadnej kontroli spójności przesyłki na poziomie transportowym. Dlaczego? Ponieważ serwer SMTP nie rozróżnia, czy przesyłka zostaje właśnie nadana, czy została nadana w innym miejscu, a jego zadaniem jest tylko przekazanie poczty dalej. Gdyby stosowano autoryzację nadawcy, nadawca musiałby być użytkownikiem zarejestrowanym w systemie, więc nie byłoby możliwości przekazywania poczty dalej. Przecież serwer, który by ją otrzymał także sprawdziłby, czy nadawca jest zarejestrowany w systemie, a prawdopodobnie nie jest. Różne rozszerzenia protokołu SMTP oraz opcje konfiguracji zapewniające autoryzację w warstwie transportowej starają się zwiększyć poziom bezpieczeństwa w stosunku do sytuacji opisanej powyżej, jednak mechanizmy polegające na bezpieczeństwie systemu transportowego są słabsze niż mechanizmy zabezpieczające przesyłkę już podczas tworzenia wiadomości, jak stosowanie podpisów cyfrowych i szyfrowania. Wysiłki skierowane na to, by utrudnić użytkownikom ustawienie adresu powrotnego wiadomości lub nagłówka "From:" na prawidłowy adres inny niż ich własny, mylą aplikacje pocztowe, które udostępniają możliwość wysłania przesyłki przez jednego użytkownika w imieniu innego, lub gdy odpowiedzi bądź błędne odpowiedzi powinny móc zostać skierowane na pewien szczególny adres.

Adresy, które nie pojawiają się w nagłówkach wiadomości mogą pojawić się w komendzie RCPT wydanej serwerowi SMTP z różnych przyczyn, spośród których dwie najważniejsze to stosowanie adresów- aliasów, których odebranie przez serwer SMTP powoduje zamianę tego adresu na listę adresów oraz stosowanie tzw. "ślepych kopii". Serwer SMTP nie powinien kopiować całego zestawu nagłówków RCPT do każdej wiadomości, jednak często się tak dzieje, a wskazania tego nie da się wymusić na implementacjach, gdyż z innych powodów możliwość użycia wielu nagłówków RCPT musi być obsługiwana.

Polecenia VRFY i EXPN także są potencjalnym zagrożeniem. Poprzez te polecenia można uzyskać adresy e-mail użytkowników danego systemu bądź sprawdzić czy istnieje w systemie użytkownik o określonym identyfikatorze. Zablokowanie tych usług w nieodpowiedni sposób może tylko zwiększyć zagrożenie. Dla przykładu, spowodowanie, by program obsługujący pocztę na komendę VRFY odpowiadał zawsze twierdząco, może wprowadzić w błąd inny program, który daną przesyłkę usiłuje wysłać. Natomiast nadużycie komendy EXPN może spowodować napływ niechcianej poczty.

Kolejny problem stwarza udostępnianie nazwy i wersji serwera pocztowego po otrzymaniu komendy HELP. Z jednej strony ułatwia to rozwiązywanie problemów oraz proces "odpluskwiania" programu, z drugiej strony udostępnia potencjalnemu napastnikowi informacje, które może wykorzystać do planowanego ataku na dany system. Zwycięża pogląd, iż należy raczej dobrze zabezpieczyć serwer pocztowy, niż liczyć na to, że ukrycie w prosty sposób nazwy i wersji serwera pocztowego zniechęci potencjalnego napastnika do dokonania ataku.

Pewne zagrożenie niosą ze sobą niektóre informacje zawarte w nagłówkach, takie jak nagłówek Recieved, w którym to są zawarte informacje o adresach IP komputerów pośredniczących w przekazaniu poczty. Jest to zagrożenie dla prywatności nadawcy, szczególnie wtedy, gdy pragnie on zachować anonimowość.

Zagrożenia związane z protokołem POP3

Tak jak w przypadku protokołu SMTP, największą wadą POP3 jest fakt, iż cała komunikacja pomiędzy klientem i serwerem POP3 odbywa się przy pomocy jawnego tekstu. Zagrożenie jednak w przypadku POP3 jest większe, gdyż w przeciwieństwie do SMTP, POP3 zawiera mechanizmy autoryzacji, więc pomiędzy klientem i serwerem są przesyłane tekstem niezaszyfrowanym informacje autoryzujące użytkownika w systemie. Poufność tych danych jest krytyczna dla systemu. Protokół ten nie zapewnia także żadnych mechanizmów kontroli spójności przesyłki.

W celu częściowej poprawy sytuacji, to znaczy ochrony chociażby hasła, można skorzystać z udostępnianej przez POP3 komendy APOP, która zamiast hasła podaje ciąg znaków, który jest ciągiem powstałym przez użycie funkcji skrótu, takiej jak MD5, na innym ciągu znaków, który zmienia się w czasie i jego część jest znana tylko klientowi i serwerowi POP3. Przykład użycia komendy APOP:

Zagrożenia związanie z protokołem IMAP4

Pod względem bezpieczeństwa protokół ten jest opracowany o wiele lepiej niż SMTP i POP3. Co prawda umożliwia przesyłanie całej komunikacji jawnym tekstem, jednak umożliwia także szyfrowanie wiadomości poprzez zastosowanie komendy AUTHENTICATE i podanie mechanizmu zabezpieczenia transakcji. Przykładowo, może to być realizowane w oparciu o system Kerberos.


« poprzedni punkt  następny punkt »