Bezpieczna komunikacja SMTP - Exchange Server

Autor: Jacek Kochan

Opublikowano: 22 stycznia 2008

Zawartość strony

	Wstęp
	Open-relay
	Rozdzielenie ruchu SMTP
	Podsumowanie

Wstęp

Podstawą komunikacji systemów pocztowych jest protokół SMTP. Administrator każdego serwera pocztowego powinien zatroszczyć się o to, aby zarówno klienci serwera pocztowego, jak i inne serwery pocztowe poprawnie mogły się z nim skomunikować, zachowując przy tym maksymalny poziom bezpieczeństwa serwera. Poprawna i jednocześnie bezpieczna konfiguracja usługi SMTP dla serwera Exchange zarówno w wersji 2003, jak i 2007, podpiętych bezpośrednio do Internetu często sprawiają początkującym administratorom sporo problemów. Postaram się wyjaśnić kilka wątpliwości dotyczących konfiguracji serwera Exchange 2003, w drugiej części artykułu pokażę, jak podejść do konfiguracji Exchange 2007.

 Do początku strony

Open-relay

Z open-relayem mamy do czynienia w przypadku, gdy anonimowy użytkownik bądź zdalny serwer, bez uwierzytelnienia przesyła na nasz serwer pocztowy wiadomość, która jest adresowana do użytkownika spoza naszej domeny, a nasz serwer przesyła ją dalej. Serwer open-relay pozwala zatem na przesyłanie poczty do dowolnej domeny z wykorzystaniem niezweryfikowanego adresu pocztowego, co prowadzi do wielu niepożądanych sytuacji.

Z open-relayem nie ma nic wspólnego sytuacja, gdy serwer pozwala na przesyłanie poczty bez uwierzytelnienia w obrębie swojej własnej domeny.

W Microsoft Exchange 2003 domyślne ustawienia nie pozwalają na przesyłanie maili do zewnętrznych serwerów pocztowych bez uwierzytelnienia użytkowników wysyłających przesyłkę. Tak więc problem z open-relayem moglibyśmy nawet uznać za załatwiony. Niestety, w wielu przypadkach problem jest troszeczkę bardziej skomplikowany (usługi sieciowe wysyłające pocztę, użytkownicy POP3/IMA4, automatyczne raportowanie problemów), co oznacza konieczność zmiany domyślnych ustawień. Nieprawidłowa modyfikacja ustawień domyślnych prowadzi często właśnie do zmiany naszego Exchange’a w open-relaya, co z kolei prowadzi do wpisania naszego serwera na listę spamerów. Postaram się pokazać jak tego uniknąć.

Na rysunku 1. przedstawiono domyślne ustawienia uwierzytelnienia wirtualnego serwera SMTP w Exchange 2003. Domyślnie serwer SMTP ma włączony dostęp anonimowy jak i uwierzytelniony.

Rys. 1. Domyślne ustawienia uwierzytelnienia wirtualnego serwera SMTP w Exchange 2003.

Takie natomiast są ustawienia restrykcji na relay poczty są takie ja przedstawiono na rys. 2. (opcja Relay restrictions w zakładce Access serwera SMTP). Domyślnie prawo do przesyłania poczty mają uwierzytelnione komputery.

Rys. 2. Opcja Relay restrictions w zakładce Access serwera SMTP.

Jeżeli do tej listy dodamy adres IP innego serwera SMTP, to będzie miał on prawo do przesyłania poczty poprzez nasz serwer do domen zewnętrznych bez uwierzytelnienia.

Możemy również ograniczyć listę uwierzytelnionych użytkowników, którzy mają prawo do przesyłania poczty. W tym celu musimy odznaczyć opcję: Allow all computers which successfully authenticate to relay, regardless of the list above. Następnie modyfikujemy listę użytkowników przyciskiem Users.

Na początek musimy wyjaśnić sobie kwestię uwierzytelniania na serwerach SMTP. Ze względu na funkcjonalność serwera SMTP możemy rozróżnić jego możliwości konfiguracji:

1. Dostęp anonimowy (anonymous access) służy do komunikacji z obcymi serwerami pocztowymi poprzez Internet. Maile są przesyłane do naszego serwera i wysyłane z naszego serwera w świat właśnie poprzez dostęp anonimowy. To właśnie wykorzystują spamerzy, którzy przesyłają niechcianą pocztę w całym Internecie. Natomiast jeżeli zabronimy takiego dostępu na naszym serwerze SMTP, wtedy w ogóle przestaniemy otrzymywać maile wysyłane z Internetu, gdyż obce serwery nie będą mogły dostarczać przesyłek na nasz serwer. Dlatego dostęp taki jest wymagany na zewnętrznym serwerze SMTP.
2. Dostęp uwierzytelniony (Basic, Integrated authentication) służy do przesyłania poczty za pośrednictwem naszego serwera Exchange. Wykorzystujemy go w sytuacjach, gdy nasz serwer nie jest serwerem docelowym, a jedynie służy do wysyłania poczty dalej (relaying). Są to sytuacje, gdy użytkownik za pośrednictwem swojego klienta pocztowego chce wysłać wiadomość, bądź gdy inny serwer pocztowy chce przesłać wiadomość za pośrednictwem naszego serwera. Uwierzytelnienie dostępu jest również ważne, gdy użytkownik łączy się innym klientem pocztowym niż Outlook i musimy zweryfikować tożsamość osoby, wykorzystującej konto pocztowe z naszej domeny.

Gdy zechcemy wysłać wiadomość do obcej domeny bez uwierzytelniania, wtedy serwer Exchange nam na to nie pozwoli.

Przykład próby wysłania wiadomości za pomocą programu telnet:

220 vm1.exch.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at

  Thu, 29 Nov 2007 12:25:33 +0100

helo

250 vm1.exch.local Hello [192.168.146.1]

mail from: pracownik@exch.local

250 2.1.0 pracownik@exch.local....Sender OK

rcpt to: info@acme.com

550 5.7.1 Unable to relay for info@acme.com

Serwer Exchange jednakże pozwala na wysyłanie maili w obrębie obsługiwanych przez niego domen bez autoryzacji.

Oznacza to, że możemy podszyć się pod inną osobę w danej organizacji i wysłać wiadomość na adres innej osoby w tej samej organizacji!

Przykład wiadomości wysłanej za pomocą programu telnet:

220 vm1.exch.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at

  Thu, 29 Nov 2007 12:17:45 +0100

helo

250 vm1.exch.local Hello [192.168.146.1]

mail from: dyrektor@exch.local

250 2.1.0 dyrektor@exch.local....Sender OK

rcpt to: pracownik@exch.local

250 2.1.5 pracownik@exch.local

data

354 Start mail input; end with <CRLF>.<CRLF>

Jestes zwolniony! Pakuj manatki!

.

250 2.6.0 <VM1d7rUslXg7wPBTyJy00000002@vm1.exch.local> Queued mail for delivery

quit

221 2.0.0 vm1.exch.local Service closing transmission channel

Jak widać serwer w wypadku wysłania wiadomości w obrębie własnej domeny nie wymaga żadnych poświadczeń od klienta.

 Do początku strony

Rozdzielenie ruchu SMTP

Skuteczną metodą, pozwalająca zapowiedz wspomnianym wcześniej problemom jest takie skonfigurowanie serwera SMTP, aby nie zezwalał na anonimowy dostęp. Jednakże wówczas serwer nie będzie przyjmował wiadomości z zewnętrznych serwerów pocztowych, kierowanych do użytkowników naszego serwera. Co więc możemy zrobić?

Najprostszym rozwiązaniem na oddzielenie ruchu anonimowego, jest stworzenie drugiego wirtualnego serwera SMTP, który będzie nam służył wyłącznie do przyjmowania wiadomości z zewnątrz.

Dodajemy adres IP w konfiguracji TCP/IP interfejsu sieciowego. Na domyślnym serwerze SMTP ustawiamy pierwszy adres IP. Następnie tworzymy drugi serwer SMTP i wpisujemy nazwę. Nadajemy wcześniej dodany adres IP dla nowego serwera SMTP. Klikamy Zakończ i restartujemy usługę SMTP.

Rys. 3. Dodajemy adres IP w konfiguracji TCP/IP interfejsu sieciowego.

Rys. 4. Na domyślnym serwerze SMTP ustawiamy pierwszy adres IP.

Rys. 5. Tworzymy drugi serwer SMTP.

Rys. 6. Wpisujemy nazwę.

Rys. 7. Klikamy Zakończ i restartujemy usługę SMTP.

Następnie wchodzimy we właściwości SMTP External, na zakładce Access klikamy na Authentication. Odznaczamy wszystkie uwierzytelnienia oprócz Anonymous access. Zatwierdzamy OK.

Rys. 8. Zatwierdzamy OK.

Musimy teraz uniemożliwić korzystanie z tego serwera smtp przez nadawców z naszych domen lokalnych. Możemy to zrobić poprzez zaaplikowanie Sender Filtering na tym serwerze SMTP.

Wchodzimy w Global Settings -> Message Delivery i wybieramy właściwości. Wchodzimy na zakładkę Sender Filtering. Klikamy na przycisk Add i dodajemy nadawcę z lokalnej domeny, w tym przypadku:

*@exch.local.

Rys. 9. Klikamy na przycisk Add i dodajemy nadawcę.

Zatwierdzamy OK. Otrzymamy komunikat, że filtry należy również manualnie włączyć na serwerze SMTP, co też czynimy. Wchodzimy we właściwości SMTP External i klikamy na przycisk Advanced po prawej stronie adresu IP.

Rys. 10. Klikamy Advanced po prawej stronie adresu IP.

W okienku Advanced wybieramy Edit.

Rys. 11. Wybieramy Edit.

Zaznaczamy Apply Sender Filter i potwierdzamy OK trzy razy.

Rys. 12. Zaznaczamy Apply Sender Filter.

Wchodzimy we właściwości pierwszego serwera: Default SMTP Virtual Server. Na zakładce Access klikamy na Authentication. Odznaczamy Anonymous Access i zatwierdzamy przyciskiem OK.

Rys. 13. Zatwierdzamy OK.

Co się stanie, gdy spróbujemy skorzystać z serwera SMTP External w nieupoważniony sposób? Oto przykład:

220 vm1.exch.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at

  Thu, 29 Nov 2007 13:17:44 +0100

helo

250 vm1.exch.local Hello [192.168.135.1]

mail from: dyrektor@exch.local

554 5.1.0 Sender Denied





Połączenie z hostem przerwane.

Nasza sesja zostanie odrzucona tuż po wprowadzeniu adresu z naszej lokalnej domeny. Oczywiście filtr nie będzie blokował wiadomości od obcych nadawców, co pozwoli na przyjmowanie poczty z Internetu:

220 vm1.exch.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at

  Thu, 29 Nov 2007 13:20:14 +0100

helo

250 vm1.exch.local Hello [192.168.135.1]

mail from: klient@acme.com

250 2.1.0 klient@acme.com....Sender OK

rcpt to: dyrektor@exch.local

250 2.1.5 dyrektor@exch.local

data

354 Start mail input; end with <CRLF>.<CRLF>

Witam Panie Dyrektorze...

.

250 2.6.0 <VM1tQa9yTONDzQiQFWx00000002@vm1.exch.local> Queued mail for delivery

quit

221 2.0.0 vm1.exch.local Service closing transmission channel

Natomiast użytkownicy wewnętrzni będą korzystać z serwera Default SMTP Virtual Server, na którym będą mieli obowiązek uwierzytelniania się. Najlepszym rozwiązaniem jest pozbycie się serwera SMTP do użytku wewnętrznego, jeżeli użytkownicy korzystają wyłącznie z klienta Microsoft Outlook (Outlook w połączeniu MAPI do serwera Exchange nie wykorzystuje protokołu SMTP).

Zaprezentowana powyżej metoda ma jedną wadę. Filtr Sender filtering normalnie służy do filtrowania niechcianej poczty za pomocą adresów nadawców. Niestety istnieje możliwość utworzenia tylko jednego filtra dla całej organizacji Exchange. Ponieważ w tym scenariuszu filtr ten jest wykorzystany do blokowania anonimowego wysyłania poczty w obrębie domen serwera Exchange, więc nie możemy wykorzystać go w pierwotnym celu, czyli filtrowania zewnętrznej poczty po adresach nadawcy.

 Do początku strony

Podsumowanie

Zezwolenie na anonimowy relaying poczty przez nasz serwer oznaczałoby, po pierwsze, znaczne obciążenie łącza internetowego oraz serwera pocztowego, a po drugie nasz serwer znalazłby się na internetowych blacklistach, rejestrujących serwery open-relay.

Na szczęście domyślne ustawienia wirtualnego serwera SMTP Exchange 2003 wystarczają na to, by nasz serwer był w znacznym stopniu bezpieczny z zewnątrz i nie pozwalał na open-relay. Jednakże warto zastanowić się nad implementacją zmian opisanych powyżej, aby zabezpieczyć również wewnętrzną komunikację poczty.

Jacek Kochan Absolwent Wydziału Matematyki i Informatyki Uniwersytetu Adama Mickiewicza w Poznaniu. Obecnie pracuje w poznańskiej firmie softwarowo-consultingowej DomData. Autor artykułów do poradników dla administratorów wyd. "Wiedza i Praktyka". Wdrożył też m.in. pierwsze środowisko hostingowe, oparte na Exchange 2007, w Polsce. Specjalizuje się w systemach Windows Server, Exchange oraz ISA. Interesuje się też fizyką i kryptografią kwantową. Posiada certyfikaty MCSE+S, MCSE+M.

Do początku strony