Forefront TMG 2010 - część 19 - Publikacja serwerów poczty elektronicznej - komunikacja SMTP

Autor: Jacek Światowiak

Opublikowano: 2012-05-15

Wprowadzenie

W poprzedniej części cyklu omówiono zagadnienie przepływu poświadczeń pomiędzy klientem, serwerem TMG, weryfikatorem a serwerem docelowym. W niniejszej części omówione zostaną zagadnienia publikacji serwerów poczty elektronicznej (komunikacja SMTP).

 

Wstęp

Omawiając zagadnienia publikacji serwerów pocztowych należy określić, jaki typ ruchu sieciowego planujemy przepuszczać przez serwer TMG 2010:

• komunikację SERWER – SERWER (Protokół SMTP),
• komunikacją KLIENT – SERWER (Protokół SMTP),
• komunikację KLIENT – SERWER (inne niż SMTP kanały wymiany poczty elektronicznej).

Jeżeli wykorzystywanym środowiskiem poczty elektronicznej jest serwer EXCHANGE 2007 lub 2010 należy też określić, czy rola Edge serwera Exchange będzie wykorzystywana, jeżeli tak to, czy będzie ona integrowana z serwerem TMG, czy nie.

Omawiając bezpieczeństwo poczty elektronicznej należy również odpowiedzieć na pytanie, czy będziemy korzystali z produktu Forefront Protection 2010 for Exchange, czy planujemy go zainstalować na roli EDGE i czy planujemy połączyć te trzy komponenty na jednym serwerze (czyli TMG 2010 + Exchange EDGE + Forefront Protection 2010 for Exchange).

Serwer TMG 2010 został przygotowany do połączenia wszystkich trzech funkcjonalności razem, tworząc unikalną, centralnie zarządzaną bramkę bezpieczeństwa dla obsługi poczty elektronicznej.

W tej części artykułu zajmiemy się wyłącznie komunikacją SERWER – SERWER (Protokół SMTP).

Scenariusz 1.

W najprostszym przypadku nie będziemy instalować na serwerze TMG 2010 żadnych komponentów dodatkowych. Zakładamy, iż organizacja dysponuje wewnątrz sieci LAN dowolnym serwerem pocztowym. Przy tego typu konfiguracji należy zatem zapewnić przezroczyste przepuszczanie protokołu SMTP pomiędzy Internetem a siecią LAN, tak jak przedstawiono to na Rys. 1.

W scenariuszu tym należy utworzyć regułę dostępu (Access Rule) dla protokołu SMTP, gdzie adresem źródłowym jest serwer poczty elektronicznej w sieci LAN lub DMZ, a adresem docelowym jest zakres EVERYWHERE (cały Internet), gdyż nie wiemy dokąd serwer będzie wysyłał pocztę elektroniczną.

Dla komunikacji w drugą stronę należy utworzyć zwykłą regułę publikacji serwera typu Non Web (de facto będzie to zwykłe przekierowanie portów) dla protokołu SMTP, przekierowując ruch dla protokołu TCP port 25 (protokół SMTP) z publicznego adresu IP serwera TMG 2010 na adres IP serwera pocztowego, znajdującego się w sieci LAN lub DMZ również na port 25 (protokół TCP).

Oba mechanizmy tworzenia reguł zostały w artykule już omówione i dlatego nie będą dodatkowo prezentowane.

Rys. 1. Rysunek prezentujący działanie Scenariusza 1.

Scenariusz 2.

Organizacja dysponuje serwerem Exchange i planuje zintegrować rolę Exchange EDGE z serwerem TMG 2010. Zatem, scenariusz ulegnie modyfikacji, tak jak zostało to przedstawione na Rys. 2.

Rys. 2. Rysunek prezentujący działanie Scenariusza 2.

Zakładamy, iż serwer Exchange (rola EDGE) został doinstalowany na serwerze TMG.

Uwaga informacyjna

Dokumentacja produktowa Exchange zaleca instalację roli serwera EDGE w grupie roboczej, ale w przypadku integracji z TMG, wygodniejszym rozwiązaniem jest instalacja w środowisku domenowym.

Należy zwrócić uwagę, iż dla wdrożenia tzw. E-mail Policy należy zainstalować na serwerze TMG 2010:

• Exchange 2007/2010 rola EDGE,
• Forefront Protection 2010 for Exchange.

Jeżeli kryteria te nie zostaną spełnione, można spodziewać się błędu w logach TMG, pokazanego na Rys. 3., natomiast Policy, mimo utworzenia w konsoli TMG 2010, nie zostaną przeniesione na konfigurację Exchange EDGE.

Rys. 3. Komunikat informacyjny o niespełnieniu wymagań odnośnie możliwości wykorzystywania E-mail Policy.

Na wstępie przyjrzyjmy się konsoli TMG 2010 na poziomie E-mail Policy – Rys. 4. To tutaj wykonywane są wszystkie czynności konfiguracyjne związane z ochroną poczty elektronicznej. Na początku, należy skonfigurować polisę e-mail – Configure E-mail Policy - z zakładki Tasks.

Rys. 4. Konsola TMG 2010 poziom E-mail Policy.

Celem polisy e-mail jest utworzenie konfiguracji zapewniającej przesyłanie strumienia SMTP oraz jego skanowanie, dla wykrycia i usunięcia spamu czy szkodliwego oprogramowania. Polisa tworzy w konfiguracji Exchange EDGE odpowiednio skonfigurowane konektory nadawcze i odbiorcze oraz dodaje nazwę domeny akceptowanej. Okno wstępne kreatora przedstawione zostało na Rys. 5.

Rys. 5. Kreator konfiguracji E-mail Policy - okno wstępne.

W oknie Internal Mail Server Configuration, zaprezentowanym na Rys. 6., definiujemy adres IP (oraz nazwę) serwera Exchange, pełniącego rolę Hub Transport (lub adres IP sprzętowego Load Balancera, jeżeli tego typu urządzenie jest stosowane). Określamy również, jakie domeny obsługuje nasza organizacja Exchange.

Rys. 6. Kreator konfiguracji E-mail Policy, okno Internal Mail Server Configuration.

Okna dodawania serwera Exchange oraz definiowania domen akceptowalnych przedstawione zostało na Rys. 7.

Rys. 7. Okna dodawania serwera Exchange oraz definiowania domen akceptowalnych.*

W oknie Internal E-Mail Listener Configuration, zaprezentowanym na Rys. 8., określamy, z jakiej sieci typu Internal (wewnętrznej) oczekujemy komunikacji SMTP. Można precyzyjnie określić nie tylko interfejs, ale również adres IP.

Rys. 8. Kreator konfiguracji E-mail Policy, okno Internal E-Mail Listener Configuration.

W oknie External E-Mail Listener Configuration, przedstawionym na Rys. 9., analogicznie określamy, z jakiej sieci typu External (zewnętrznej /publicznej) oczekujemy komunikacji SMTP. Można precyzyjnie określić również adres IP.

Ten konektor odbiorczy przedstawia się zdalnym serwerom SMTP określoną nazwą. Nazwę tą podaje się w polu FQDN or IP address.

Należy zwrócić uwagę, iż przy komunikacji szyfrowanej TLS/SSL nazwa ta musi zgadzać się z nazwą wykorzystywaną w certyfikacie.

Rys. 9. Kreator konfiguracji E-mail Policy, okno External E-Mail Listener Configuration.

W kolejnym oknie E-mail Policy Configuration, zaprezentowanym na Rys. 10., określamy, jakie dodatkowe, poza routingiem SMTP, komponenty polisy mają być włączone:

• filtrowanie spamu,
• ochrona przed szkodliwym oprogramowaniem,
• synchronizacja EDGE z organizacją Exchange.

Rys. 10. Kreator konfiguracji E-mail Policy, okno E-mail Policy Configuration.

Na Rys. 11. zaprezentowano okno podsumowania utworzenia polisy oraz okno informujące o konieczności dokonania zmian w regułach systemowych. Zmiany te wynikają z faktu, iż policy e-mail nie są wyświetlane jako normalne reguły zapory, lecz jako reguły systemowe.

Rys. 11. Kreator konfiguracji E-mail Policy, okna podsumowującego konfigurację.**

 

Właściwości reguły dla ruchu External_Mail_Servers

Przyjrzyjmy się utworzonym regułom routingu STMP. Po zakończeniu kreatora polisy utworzone zostają dwa wpisy typu SMTP Routes, tak jak przedstawiono to na Rys. 12.:

• Extenal_Mail_Servers,
• Internal_Mail_Servers.

Rys. 12. Właściwości reguły dla ruchu wychodzącego.

Te nazwy reguł routingu nie odzwierciedlają dokładnie działania całej polisy:

• reguła External_Mail_Servers – powoduje utworzenie dwóch konektorów (jednego nadawczego i jednego odbiorczego) o takiej właśnie nazwie. Reguła ta definiuje obsługę ruchu z sieci zewnętrznej (Internet) do serwera TMG 2010,
• reguła Internal_Mail_Servers – również tworzy dwa konektory i odpowiada za ruch wewnętrzny od serwera TMG do serwera Exchange, pełniącego rolę Hub Transport.

Właściwości trasy External_Mail_Servers przedstawione zostały na Rys. 13, 14, 15. Nazwy reguł można zmienić w zakładce General. W zakładce tej można dodać opcjonalny opis – pole Description. Regułę można chwilowo włączyć/wyłączyć – pole Enable. Dodatkowo, definiujemy tutaj maksymalną wielkość, przesyłanej przez konektory, poczty - pole Maximum message size (KB).

Na zakładce Routing określamy, czy definiowana komunikacja dotyczy ruchu z/do wewnętrznych serwerów SMTP (opcja Internal mail servers), czy też zewnętrznych serwerów SMTP (opcja External mail servers).

Dla ruchu wychodzącego (konektor wysyłający) określamy, w jaki sposób będą określane docelowe serwery SMTP (a dokładniej ich rekordy MX): dzięki bezpośrednim zapytaniom DNS, czy też dzięki  przesyłaniu poczty do dodatkowego smarthosta.

Rys. 13. Właściwości reguły dla ruchu wychodzącego, zakładki General i Routing.**

Na Rys. 14. zaprezentowano zaawansowane opcje konfiguracyjne konektora wysyłającego. Poczta wysyłana domyślnie jest bez uwierzytelniania, stąd sekcja Authentication jest wyszarzana. Jedyna opcja, to możliwość określenia źródłowego adresu IP. Zakładka Domains dla ruchu wychodzącego jest również wyszarzana.

Rys. 14. Właściwości reguły dla ruchu wychodzącego, zaawansowane ustawienia zakładki Routing i zakładka Domains.

Na zakładce Listener, przedstawionej na Rys. 15., określamy skąd nasłuchujemy ruchu i jaką nazwą serwer SMTP ma się przedstawiać. W oknie Advanced określamy dodatkowe opcje związane z możliwością dodatkowego włączenia uwierzytelniania. Wszystkie mechanizmy zostają domyślnie wyłączone.

****Rys. 15.****Właściwości reguły dla ruchu wychodzącego, zakładka Listener, jej zaawansowane ustawienia.**

Właściwości reguły dla ruchu Internal_Mail_Servers

Analogiczne właściwości posiada trasa Internal_Mail_Servers (Rys. 16, 17, 18.). Na zakładce Routing definiujemy trasę typu Internal do określonego adresu IP (np. serwera Exchange, pełniącego rolę Hub Transport).

Rys. 16. Właściwości reguły dla ruchu wchodzącego, zakładki General i Routing.

Tutaj również ruch przesyłany jest jako nieuwierzytelniany. Na zakładce Domains określamy nazwy obsługiwanych domen pocztowych.

Rys. 17. Właściwości reguły dla wchodzącego, zaawansowane ustawienia zakładki Routing i zakładka Domains.

Właściwości zakładki Listener są identyczne jak w poprzedniej trasie. Nie zostaje zdefiniowana nazwa serwera SMTP, którą się on przedstawia, ale dla ruchu wewnętrznego nie ma to znaczenia. Jeżeli pole to nie zostanie wypełnione, to serwer będzie przedstawiał się nazwą serwera TMG. W części ustawień poświęconych bezpieczeństwu zaznaczona jest opcja Externally secured – oznacza to, iż konektor zakłada spełnienie wymagań bezpieczeństwa komunikacji innymi metodami (np. za pomocą protokołu IPSEC). Do zagadnienia tego wrócimy w dalszej części.

Rys. 18. Właściwości reguły dla ruchu wchodzącego, zakładka Listener, jej zaawansowane ustawienia.

Konfiguracja Exchange EDGE przed integracją

Przyjrzyjmy się konfiguracji Exchange EDGE przed skonfigurowaniem E-mail Policy (Rys. 19, 20, 21.). Tworzony jest domyślnie jeden konektor odbiorczy o nazwie Default internal receive connector. Brak jest zdefiniowanych konektorów nadawczych i nie są zdefiniowane żadne domeny akceptowane.

Rys. 19. Konsola Exchange 2010 Edge – zakładka konektory odbiorcze.

Rys. 20. Konsola Exchange 2010 EDGE – zakładka konektory nadawcze.

Rys. 21. Konsola Exchange 2010 EDGE – zakładka domeny akceptowane.

 

Po wdrożeniu E-mail Policy

Po wdrożeniu E-mail Policy, utworzone polisy w konsoli TMG 2010 przekładają się na konektory odbiorcze i nadawcze w konsoli Exchange EDGE. Struktura konektorów odpowiada dokładnie konfiguracji z Rys. 2.Rys. 22. prezentuje utworzone konektory odbiorcze.

Rys. 22. Konsola Exchange EDGE - konektory odbiorcze.

Na Rys. 23. przedstawiono listę konektorów odbiorczych, wyświetlanych za pomocą PowerShella.

Rys. 23. Konsola Exchange EDGE - konektory odbiorcze (PowerShell).

Rys. 24. prezentuje utworzone konektory nadawcze.

Rys. 24. Konsola Exchange EDGE - konektory nadawcze.

Na Rys. 25. przedstawiono listę konektorów nadawczych, wyświetlanych za pomocą PowerShella.

Rys. 25. Konsola Exchange EDGE - konektory nadawcze (PowerShell).

Ostatecznie, na Rys. 26. przedstawiamy wygląd listy domen akceptowanych.

Rys. 26. Konsola Exchange EDGE - domeny akceptowane.

Właściwości konektorów widziane od strony konsoli Exchange EDGE

Nie wszystkie informacje z konsoli Exchange EDGE są wyświetlane w konsoli TMG - poziom E-mail Policy. Właściwości konektora odbiorczego External przedstawione zostały zbiorczo na Rys. 27. Na zakładce General można włączać logowanie ruchu SMTP – czego nie da się zrobić od strony konsoli TMG.

Rys. 27. Właściwości konektora odbiorczego External.**

Właściwości konektora nadawczego External i Internal przedstawione zostały zbiorczo Rys. 28. Jedyna różnica wynika z faktu, iż poczta wysyłana jest do Internetu bezpośrednio, zaś do wnętrza sieci LAN serwer Exchange Edge traktuje serwer Exchange, pełniący rolę Hub Transport jako SmartHosta (zaprezentowano to rysunku, w drugim wierszu po prawej stronie).

Rys. 28. Właściwości konektora nadawczego External oraz Internal.**

 

Pełna integracja EDGE z organizacją Exchange

Rola EDGE serwera Exchange pełni w scenariuszu rolę tzw. smart hosta, czyli dodatkowego serwera SMTP, przez który przechodzi ruch wchodzący/wychodzący. Pełna integracja z serwerem TMG 2010 pozwoli na wygodniejsze zarządzanie tym właśnie komponentem. Pełnej integracji roli EDGE z pozostałymi komponentami organizacji Exchange dokonuje się przez tzw. subskrypcję. Plik subskrypcji generuje się od strony serwera Exchange EDGE. Jeżeli integrujemy TMG z EDGE, plik subskrypcji generuje się z poziomu konsoli TMG 2010. W celu wygenerowania pliku subskrypcji należy, w konsoli przedstawionej na Rys. 29., najpierw włączyć opcje reguł systemowych serwera TMG (zapewnia komunikację pomiędzy TMG a Exchange) za pomocą opcji Enable Connectivity for EdgeSync Traffic, a potem wygenerować plik subskrypcji.

Rys. 29. TMG 2010 poziom E-mail Policy.

Okno informujące o modyfikacji reguł systemowych (dla obsługi ruchu synchronizacji EDGE z pozostałymi komponentami organizacji Exchange) zaprezentowano na Rys. 30.

Rys. 30. Okno informujące o modyfikacji reguł systemowych.

Następie, z zakładki Task należy kliknąć w Generate Edge Subscription Files, jak zaprezentowano to na Rys. 31. Okno informujące o wygenerowaniu pliku subskrypcji zostało zaprezentowane po prawej stronie na Rys. 31.

Rys. 31. Okno generacji pliku subskrypcji.

Import pliku subskrypcji od strony organizacji Exchange

Ten plik subskrypcji należy przenieść na dowolny serwer organizacji Exchange, po czym, (albo za pomocą polecenia w PowerShellu lub za pomocą konsoli graficznej) należy go dodać do konfiguracji organizacji Exchange. Okno dodawania pliku subskrypcji przedstawiono na Rys. 32. Plik dodaje się na poziomie konfiguracji organizacji - serwer Hub Transport zakładka Edge Subscriptions.

Rys. 32. Konsola Exchange we wnętrzu organizacji Exchange – import pliku subskrypcji.

Po kliknięciu New Edge Subscription zostanie wyświetlone okno, pokazane na Rys. 33. W oknie tym określamy Site Active Directory, którego dotyczy subskrypcja, oraz nazwę i lokalizację samego pliku subskrypcji.

Rys. 33. Kreator importu pliku subskrypcji.

Okno podsumowania importu przedstawia Rys. 34.

Rys. 34. Okno podsumowania importu pliku subskrypcji.

Zaimportowany prawidłowo plik subskrypcji zaprezentowany został Rys. 35.

Rys. 35. Zaimportowany prawidłowo plik subskrypcji.

Po imporcie należy zainicjalizować subskrypcję za pomocą polecenia w PowerShellu Start-EdgeSynchronization, jak przedstawiono to na Rys. 36.

Rys. 36. Zainicjalizowana synchronizacja z Edge.

Po zakończeniu synchronizacji wstępnej nastąpi aktualizacja konfiguracji Exchange EDGE - konektorów wysyłających. Zmodyfikowaną konfigurację przedstawia Rys. 37.

Rys. 37. Zmodyfikowane konektory wysyłające.

Od strony TMG 2010 zmiana następuje w konfiguracji routingu SMTP – na Rys. 38., widać wówczas uwagę, iż konfiguracja zarządzana jest przez subskrypcję EDGE.

Rys. 38. Zmodyfikowana konfiguracja routingu SMTP.

Po tej operacji niektóre elementy konfiguracji routingu w konsoli TMG 2010 będą już niedostępne, co przedstawia Rys. 39. Będą to zakładki Routing i Domains.

Rys. 39. Zmodyfikowany wygląd zakładki Routing.

Przechwyconą komunikację z Internetu wnętrza sieci prezentuje Rys. 40.

Rys. 40. Przechwycona komunikacja z Internetu wnętrza sieci.

Po przyjściu przesyłki pocztowej od strony klienta pocztowego można podejrzeć źródło wiadomości. Przykład przesyłki, która weszła do wnętrza przedstawia Rys. 41. Jak widać z rysunku:

• przesyłka została wysłana z klienta Microsoft Windows Live Mail,
• wysłana została z komputera KLIENT o adresie 10.200.254.23,
• przeszła przez serwer SMTP o nazwie DNS (i adresie 10.200.254.24),
• została przesłana na serwer TMG (który zgłosił się jako mail.test.com – 10.200.254.25),
• została wysłana przez drugi interfejs TMG (192.168.0.254) jako tmg.test.local,
• trafiła ostatecznie na serwer docelowy EXCHANGE.test.local (192.168.0.180).

Rys. 41. Źródło wiadomości przesyłki, która weszła do wnętrza sieci LAN z Internetu.

Sytuację odwrotną prezentuje Rys. 42.:

• przesyłka została wysłana lokalnie z SERWERA EXCHANGE (tutaj adres IPv6 lokalny łącza), zapewnie poprzez OWA,
• następnie, została przesłana na serwer TMG.test.local 192.168.0.254. z serwera EXCHANGE z adresu (192.168.0.180),
• została wysłana przez drugi interfejs TMG (10.200.254.25) jako tmg.test.com,
• trafiła ostatecznie na serwer docelowy DNS.

Rys. 42. Źródło wiadomości przesyłki, która wysłana została do serwera docelowego DNS.

Jak widać z przechwyconej komunikacji, protokół SMTP jest bardzo „gadatliwy” i z komunikacji wychodzącej powinniśmy, dla zachowania w sekrecie budowy infrastruktury organizacji pocztowej, wyciąć zbędne elementy nagłówka.

Dodatkowo, w standardowej komunikacji, serwer TMG, a precyzyjniej konektor odbiorczy z Internetu, nie obsługuje komunikacji chronionej TLS/SSL (szyfrowanej). Rekonfiguracja konektorów to zagadnienie na odrębny artykuł i nie będzie w niniejszej publikacji bliżej omawiana.

Podsumowanie

W niniejszej części cyklu omówiono zagadnienie zabezpieczania ruchu SMTP, przechodzącego przez serwer TMG, a wymienianego pomiędzy serwerami SMTP.

W następnej części omówimy zagadnienie komunikacji klienckiej SMTP/POP/IMAP4 z infrastrukturą pocztową organizacji, przy publikacji tych protokołów poprzez serwer TMG.

 

---