Pięć najlepszych zalecanych procedur dotyczących bezpieczeństwa w programie Exchange Server 2007

Opublikowano: 10 marca 2008

Nie ma wątpliwości, że program Microsoft Exchange Server 2007 jest jak wygrana na loterii dla administratora komunikacji wyczulonego na kwestie bezpieczeństwa. Program Exchange Server 2007 zawiera wiele fabrycznie zainstalowanych funkcji i zmian w konfiguracji, w dużym stopniu zmniejszających zakres problemów z bezpieczeństwem. Obejmuje to nową, modułową architekturę działającą w oparciu o role, uproszczony i szczegółowy model delegowania administracyjnego oraz domyślne zastosowanie szyfrowania na wysokim poziomie dla każdego połączenia pomiędzy serwerami Exchange w organizacji.

Wiele nowych funkcji ma za zadanie ułatwienie dostępu użytkowników do skrzynek pocztowych i danych serwera Exchange, niezależnie od miejsca pobytu – przy biurku, w podróży z laptopem lub za pomocą urządzeń przenośnych, takich jak urządzenia typu Pocket PC lub telefony smartphone z zainstalowanym systemem Windows Mobile. Podczas testowania i wdrażania programu Exchange Server 2007 w organizacji można się przekonać, że bezpiecznie zarządzanie tego typu „dostępem z dowolnego miejsca” jeszcze nigdy nie było takie proste.

Niezależnie od tego, jak dobrze Exchange Server 2007 jest domyślnie skonfigurowany, jest to tylko oprogramowanie; żadne oprogramowanie nie będzie nigdy całkowicie bezpieczne, jeżeli praca przy nim ograniczy się tylko do jego zainstalowania. Aby bezpiecznie korzystać z programu Exchange Server 2007, należy stosować pięć sprawdzonych procedur.

Zawartość strony

	Używanie portu Client Submission Port
	Wyłączenie połączeń HTTP
	Nie używać domyślnych certyfikatów w rolach serwera połączonych z Internetem
	Zastosowanie kreatora konfiguracji zabezpieczeń
	Właściwe rozmieszczenie serwerów Exchange

Używanie portu Client Submission Port

Podczas projektowania serwerów transportu programu Exchange Server 2007 (role serwera Transport centralny oraz Transport graniczny) zespół ds. produktu Exchange Server podjął bardzo ważną decyzję, która jeszcze bardziej upraszcza szybkie i bezpieczne konfigurowanie połączeń protokołu Simple Mail Transfer Protocol (SMTP): oddzielona została funkcjonalność odbierania (rola serwera SMTP) od funkcjonalności wysyłania (rola klienta SMTP). W wyniku tej decyzji mamy teraz do dyspozycji łączniki Receive oraz Send, umożliwiające łatwiejsze rozdzielanie ruchu protokołu SMTP pomiędzy rolą serwera a rolą klienta, jak pokazano na rys. 1

Rys. 1: Rozpoczęcie sesji SMTP klient-serwer

To rozdzielenie sprawia, że możliwe jest udostępnienie fabrycznych opcji programu Exchange Server 2007 obsługujących port Client Submission Port bedący de facto standardem internetowym. Wielu usługodawców ISP oraz sieci blokuje wychodzące połączenia TCP 25 w celu zmniejszenia ilości spamu pochodzącego z ich sieci i wymuszenia filtrowania wiadomości wychodzących. To może stanowić duży problem dla użytkowników, którzy łączą się z wieloma sieciami; może zajść konieczność zresetowania przez nich konfiguracji aplikacji w zależności od sieci, z którą są aktualnie połączeni.

Standard Client Submission Port stanowi rozwiązanie tego problemu dzięki wykorzystaniu dwóch oddzielnych portów serwera SMTP: domyślnego portu TCP 25 oraz dodatkowego portu TCP 587. W programie Exchange Server 2007 są one wdrożone jako dwa łączniki Receive na serwerach Transportu centralnego:

• Domyślny łącznik Receive na porcie TCP 25 (standardowy port protokołu SMTP) ma za zadanie odbieranie ruchu od innych serwerów SMTP, co jest konieczne, aby możliwe było ogólne odbieranie internetowej poczty e-mail. Chociaż rekordy DNS MX umożliwiają określanie, które serwery mają odbierać pocztę przychodzącą z niezaufanych źródeł, nie ma możliwości wyznaczenia alternatywnego numeru portu TCP – wszystkie połączenia przechodzą przez port TCP 25.
• Kliencki łącznik Receive na porcie TCP 587 jest przeznaczony do obsługi klientów poczty SMTP, takich jak Windows Live Mail Desktop, Office Outlook Express lub innych aplikacji wdrożonych na komputerach użytkowników. Ponieważ przesyłanie jest inicjowane przez użytkowników, te połączenia powinny być uwierzytelniane, tak aby wiadomości mogły być traktowane z wyższym poziomem zaufania.

Starsze serwery Exchange oraz serwery transportu Exchange Server 2007 w organizacji wykorzystują port 25 do komunikacji protokołu SMTP między sobą. Jeżeli serwer Transportu centralnego ma za zadanie odbieranie wiadomości przychodzących z Internetu, jego domyślny łącznik Receive powinien zezwalać na anonimowe połączenia. Domyślnie te łączniki wymagają uwierzytelnienia; Serwer Exchange zakłada, że w organizacji używany jest serwer Transportu granicznego jako brama zewnętrzna.

Kliencki łącznik Receive stanowi alternatywę względem wymogu uwierzytelnionego protokołu SMTP na głównej zewnętrznej bramie poczty, w szczególności gdy ta brama jest urządzeniem innej firmy. Używanie tego portu daje użytkownikom możliwość przesyłania wiadomości na serwery organizacji nawet wtedy, gdy są oni w podróży, bez potrzeby dokonywania zmian w konfiguracji.

Jeżeli użytkownicy używają programu Outlook Anywhere z oprogramowaniem Office Outlook 2007, wywołania RPC przez protokół HTTPS w programie Outlook 2003 lub połączenia WebDAV z programem Microsoft Entourage 2004 lub 2008, problem ten nie występuje. Podobnie, jak w przypadku urządzeń wykorzystujących protokół Exchange ActiveSync (EAS).

 Do początku strony

Wyłączenie połączeń HTTP

Ta rada może wydawać się sprzeczna z założeniami „dostępu z dowolnego miejsca”. W końcu większość protokołów umożliwiających użytkownikom dostęp z dowolnego miejsca do danych znajdujących się w skrzynce pocztowej serwera Exchange opiera się na protokole HyperText Transfer Protocol (HTTP):

• Program Outlook Anywhere w Outlook 2007, znany wcześniej jako wywołanie RPC przez protokół HTTPS, wykorzystuje wywołania MAPI RPC przez protokół HTTP.
• Urządzenia z systemem Windows Mobile wykorzystują EAS, protokół synchronizacji skrzynki pocztowej sieci Web oparty na protokole HTTP. Licencję na EAS posiada coraz więcej urządzeń, które nie mają zainstalowanego systemu Windows Mobile.
• Komputery Mac z programem Microsoft Entourage używają protokołu Web Document Authoring and Versioning (WebDAV), który także działa w oparciu o protokół HTTP.

Oczywiście nie należy wyłączać wszystkich połączeń opartych na protokole HTTP. Podstawowy protokół HTTP stwarza jednak zagrożenie dla bezpieczeństwa, ponieważ przesyła wszystkie dane jako zwykły tekst; każdy, kto śledzi połączenie, może odebrać każdy bajt danych i zrekonstruować wiadomości użytkowników. Dlatego też podczas każdego wdrażania protokołów działających w oparciu o HTTP należy włączyć szyfrowanie za pomocą protokołu SSL (lub jego następcy – protokołu TLS). To pomaga chronić użytkowników podczas połączenia, w szczególności podczas używania uwierzytelniania podstawowego (często spotykanego w wielu urządzeniach przenośnych).

Zaskakujące jest, jak wiele osób wie, że konieczne jest używanie protokołu SSL i włącza go, a następnie publikuje zarówno bezpieczne, jak i niebezpieczne wersje protokołu dla zewnętrznych odbiorców. Jedną z najczęstszych przyczyn takiego stanu rzeczy jest rozwiązywanie problemów: jest ono o wiele prostsze w przypadku niezaszyfrowanych połączeń. Jednak po przeprowadzeniu początkowych testów i sprawdzeniu konfiguracji publikowania należy wyłączyć zwykły protokół HTTP.

 Do początku strony

Nie używać domyślnych certyfikatów w rolach serwera połączonych z Internetem

Jednym z największych źródeł zastrzeżeń odnośnie do stosowania protokołów SSL oraz TLS jest wymóg dotyczący certyfikatów cyfrowych X.509. Najczęstsze zastrzeżenia to:

• „Kupowanie certyfikatów komercyjnych jest zbyt drogie.”
• „Wdrożenie certyfikatu PKI jest zbyt skomplikowane.”
• „Certyfikaty utrudniają rozwiązywanie problemów.”

Zespół ds. produktu Exchange Server, któremu od lat znane były te (i inne) zastrzeżenia, zajął się nimi w programie Exchange Server 2007. Podczas instalacji każdego serwera z programem Exchange Server 2007, instalator wygeneruje certyfikat z podpisem własnym, który zostanie zastosowany przez serwer do zabezpieczenia komunikacji z innymi serwerami z programem Exchange Server 2007 oraz klientami Office Outlook 2007. Jeżeli na komputerze istnieje już certyfikat (być może wdrożona została infrastruktura PKI, taka jak usługi Windows Certificate Services), można wybrać ten certyfikat podczas instalacji. Program Exchange Server 2007 bez problemu go zastosuje.

Certyfikaty z podpisem własnym stanowią wielki krok naprzód dla organizacji, które nie mają wdrożonej żadnej infrastruktury; dzięki samemu uaktualnieniu mogą one korzystać z komunikacji bezpiecznego transportu bez potrzeby wykonywania dodatkowych czynności. Certyfikaty te będą jako tako działać także podczas publikowania usług w Internecie; klienty programu Office Outlook będą wydawać ostrzeżenia o certyfikacie, które będą kłopotliwe i denerwujące dla użytkowników, a inne klienty (w tym urządzenia z systemem Windows Mobile) nie będą w stanie używać tych certyfikatów z podpisem własnym.

Dlatego też należy się chociaż w minimalny sposób zabezpieczyć. Mam na myśli to, że jeżeli w organizacji używane są certyfikaty z podpisem własnym, należy zakupić od uznanego urzędu certyfikacji certyfikaty komercyjne do stosowania z serwerami SMTP oraz HTTP – czyli każdym hostem (klientem lub serwerem), który będzie inicjował lub odbierał połączenia z Internetu. Oto kilka kwestii, na które trzeba zwrócić uwagę:

• Może zajść potrzeba opublikowania różnych nazw hostów, takich jak OWA, usługi wykrywania automatycznego oraz granicznych bram poczty. Zazwyczaj w przypadku protokołu SSL oznacza to jeden certyfikat na nazwę hosta, co bardzo szybko może stać się kosztowne. W celu zmniejszenia kosztów i złożoności konfiguracji można zastosować certyfikat typu wildcard. Należy pamiętać, że urządzenia przenośne z zainstalowanym systemem Windows Mobile 5.0 oraz wersjami starszymi nie obsługują certyfikatów wildcard. Kompatybilność wymaga, aby użytkownicy korzystali z systemu Windows Mobile 6 lub nowszej wersji.
• Kolejną nową opcją jest możliwość określania wielu nazw hostów na jednym certyfikacie. Ten typ certyfikatu wykorzystuje pole Subject Alternate Name (SAN) X.509 i jest powszechnie znany jako certyfikat SAN. Te certyfikaty są zazwyczaj droższe i trudniejsze do wdrożenia. Mogą także powodować dodatkowe komplikacje, jeżeli w organizacji używany jest program ISA Server do publikacji usług. Program ISA Server 2004 nie obsługuje certyfikatów SAN; konieczne będzie uaktualnienie do wersji ISA Server 2006.
• Konieczne jest przetestowanie konfiguracji urządzeń przenośnych i komputerów z certyfikatami udostępnionymi przez komercyjny urząd certyfikacji. Nie wszystkie urządzenia mają załadowane konieczne certyfikaty główne. Jest to także problem podczas wdrażania certyfikatów z wewnętrznej infrastruktury PKI. Proces publikowania certyfikatów głównych dla wszystkich użytkowników może być bardziej skomplikowany, niż można się spodziewać, zwłaszcza jeżeli obsługa urządzeń nie zostanie ograniczona do urządzeń zatwierdzonych.

Więcej informacji na temat wdrażania certyfikatów komercyjnych znajduje się w oficjalnym dokumencie Exchange 2007 Autodiscover Service (j.ang.) oraz dokumentacji Managing SSL for a Client Access Server (j.ang.).

 Do początku strony

Zastosowanie kreatora konfiguracji zabezpieczeń

Słyszeliśmy mantrę o „kompleksowej ochronie” tak często, że dotarła wreszcie do naszej świadomości. Wszyscy wiemy, że solidna strategia obronna oznacza nie tylko używanie bezpiecznych funkcji i technologii, ale także wykorzystanie zapory w celu ograniczenia dostępu w relacji serwery i hosty w sieci organizacji, a serwery i hosty w innych sieciach. Jako ostatni poziom ochrony konieczne jest także wzmocnienie serwerów Exchange; to oznacza wyłączenie niepotrzebnych usług i zmniejszenie potencjalnych wektorów, które mogłyby zostać skutecznie wykorzystane przez osoby atakujące, nawet gdy przejdą przez pozostałe poziomy ochrony. Na przykład serwery Exchange w wielu sytuacjach nie muszą funkcjonować jako serwery plików, więc nie ma potrzeby utrzymywać aktywnych powiązań usług Windows File and Print Services w interfejsach sieciowych.

Na przestrzeni lat wiele osób i firm, w tym Microsoft, stworzyło rozszerzone listy kontrolne i procedury wzmacniania dla każdej wersji programu Exchange Server. Jednakże w przypadku programu Exchange Server 2007 firma Microsoft znacznie ułatwia wzmacnianie serwerów za pomocą Kreatora konfiguracji zabezpieczeń (j.ang.) (SCW). Kreator SCW jest opcjonalnym składnikiem wprowadzonym po raz pierwszy w programie Windows Server 2003 Service Pack 1, wykorzystuje bibliotekę plików XML w celu określenia, które usługi, ustawienia oraz porty mogą zostać bezpiecznie wyłączone, tak aby nie miało to wpływu na aplikacje uruchomione na serwerze.

Po zainstalowaniu składnika kreatora SCW (j.ang.) należy poinformować go o istnieniu programu Exchange Server 2007; domyślnie wie on tylko o istnieniu programu Exchange Server 2003. W tym celu należy zarejestrować rozszerzenia kreatora SCW dla Exchange 2007 (j.ang.), będące dwoma plikami XML zawierającymi informacje potrzebne kreatorowi SCW do pomyślnego wzmocnienia serwerów z programem Exchange Server 2007. Te pliki znajdują się w programie Exchange Server 2007; to, które zostaną użyte, jest określone przez role serwera zainstalowane na serwerze, jak pokazano w Tabeli 1.

Po zainstalowaniu rozszerzeń można zastosować kreatora SCW w celu wzmocnienia serwerów z programem Exchange Server 2007, jak pokazano na Rys.2.

Rys. 2: Wzmacnianie serwera skrzynki pocztowej z programem Exchange Server 2007 za pomocą kreatora SCW

 Do początku strony

Właściwe rozmieszczenie serwerów Exchange

W przypadku programu Exchange Server 2003 oraz starszych wersji konieczne było rozważenie wielu kwestii związanych z zaprojektowaniem sieci podczas zabezpieczania wdrażania Exchange. Kwestią najbardziej sporną jest rozmieszczenie serwerów front-end oraz zewnętrznych serwerów czołowych. Dwie główne opcje – wewnętrznie chroniona sieć lub sieć obwodowa – były obsługiwane przez firmę Microsoft, ale obie miały swoje wady:

• Umieszczenie tych serwerów w sieci wewnętrznej to opcja zalecana, ale wiele osób jest jej przeciwnych, ponieważ wiąże się ona z ryzykiem przepuszczania połączeń z Internetu przez warstwy ochronne bez żadnego filtrowania. W tym sposobie wdrożenia najlepszą procedurą było zastosowanie serwera proxy, takiego jak Microsoft Internet Security and Acceleration (ISA) Server, w celu filtrowania połączeń i wykonywania wstępnego uwierzytelniania.
• Z drugiej strony umieszczenie tych serwerów w sieci obwodowej osłabia wartość sieci obwodowej. Serwery Exchange muszą należeć do usługi Active Directory, więc ich umieszczenie w sieci obwodowej obejmuje otwarcie dużej liczby portów i połączeń z krytyczną infrastrukturą serwerów. Ta opcja była zalecana przed wprowadzeniem programu ISA Server.

Dzięki architekturze wielu ról programu Exchange Server 2007 wybór opcji zostaje uproszczony, jak pokazano na Rys. 3. Jedyną rolą programu Exchange Server 2007 obsługiwaną w sieci obwodowej jest Transport graniczny; pozostałe cztery role są obsługiwane wyłącznie w wewnętrznej chronionej sieci.

Rys. 3: Umieszczenie ról programu Exchange Server 2007 w sieci

Ta zmiana wydaje się być najtrudniejszą do wprowadzenia zmianą pojęciową dla wielu doświadczonych administratorów Serwera Exchange. Wiele osób uważa, że serwery Dostępu klienta oraz serwery Transportu centralnego należy wdrażać w sieci obwodowej. Takie wdrożenie zmniejsza wartość wielu fabrycznych zabezpieczeń programu Exchange Server 2007, drastycznie komplikuje konfiguracje zapory i naraża kontrolery domeny usługi katalogowej Active Directory na potencjalne ataki. W razie konieczności ograniczenia lub filtrowania połączeń przychodzących z niezaufanych źródeł należy zastosować odpowiedni do tego serwer proxy aplikacji, taki jak ISA Server, wdrożony w sieci obwodowej. Administratorzy zapory internetowej z pewnością to docenią.

Do początku strony