Exchange 2007 - bezpieczna komunikacja smtp, cz. II     Microsoft Exchange Server

Exchange 2007 - bezpieczna komunikacja smtp, cz.III Udostępnij na: Facebook

Autor: Jacek Kochan

Opublikowano: 10 maja 2008

Scenariusz Exchange 2007 z serwerem Edge

W tym scenariuszu rozpatrzymy następujący schemat organizacji:

  • serwer Mailbox i Hub Transport w strefie back-end
  • serwer Client Access i Hub Transport w strefie front-end z dostępem do kontrolerów Active Directory
  • serwer Edge w strefie DMZ

Rys.1 Scenariusz Exchange 2007 z serwerem Edge

Rys.1. Scenariusz Exchange 2007 z serwerem Edge.

Komunikacja SMTP z serwerami będzie odbywała się przez serwer Edge. Komputer z rolą Edge, który nie jest podłączony do domeny, nie powinien obsługiwać klientów pocztowych, gdyż nie będzie w stanie ich uwierzytelniać. Dlatego też obsługą użytkowników powinien zająć się w pełni osobny serwer w strefie Front-end. W tym przypadku będzie to serwer, który obsługuje również rolę Client-Access. Na tym serwerze musi być więc zainstalowana również rola Hub-Transport.

Nie będziemy tworzyć Send connectora, tak jak w poprzednim scenariuszu, gdyż utworzy się on automatycznie podczas subskrybowania serwera Edge. Subskrypcję wykonujemy w dwóch krokach.

  1. Tworzymy plik subskrypcji na serwerze Edge poleceniem shellowym: New-EdgeSubscription –file "C:\edgesubscription.xml"
  2. Kopiujemy powstały plik na jeden z serwerów z rolą Hub Transport i wykonujemy na nim polecenie: new-edgesubscription -filename "c:\edgesubscription.xml" -site "Default-First-Site-Name"

Można to wykonać również przez konsolę, wykonując akcję w gałęzi Organization configuration - Hub Transport.

W wyniku powstaną dwa konektory służące do wymiany poczty w obie strony, identyczne w organizacji Exchange oraz na serwerze Edge.

Rys.2 Konektory służące do wymiany poczty w obie strony

Rys.2. Konektory służące do wymiany poczty w obie strony.

Zmiany konfiguracji na tych konektorach możemy wykonywać tylko w organizacji.

Zostaną one zreplikowane na serwer Edge. Replikacja danych pomiędzy organizacją a serwerami Edge odbywa się automatycznie, ale można ją też wymusić poleceniem Start-EdgeSynchronization. Powinniśmy je wykonać po subskrypcji, aby sprawdzić, czy komunikacja między serwerem Hub Transport a Edge jest prawidłowa. Należy również zadbać o to, by serwer transportowy „widział” serwer Edge, czyli by potrafił rozpoznać jego nazwę dns. Najlepiej po prostu dodać rekordy A do serwera dns Active Directory.

Tak więc komunikację ze światem mamy praktycznie załatwioną. Pozostają użytkownicy zewnętrzni oraz wewnętrzni. Tutaj postępujemy analogicznie, jak w pierwszym scenariuszu. Wybieramy rozwiązanie komunikacji zgodne z RFC i wymuszamy łączenie się klientów po porcie 587, bądź też pozwalamy im na przesyłanie poczty na porcie 25. Domyślne ustawienia serwerów Hub Transport są jak najbardziej w porządku, gdyż jest możliwa komunikacja jedynie po uwierzytelnieniu.

Pozostaje jeszcze zabezpieczenie serwera Edge, aby nikt z naszych użytkowników nie próbował wysyłać za jego pomocą nieuwierzytelnioną pocztę. W tym celu możemy wykorzystać sposób opisany w pierwszym scenariuszu i utworzyć regułę transportową, ale możemy również posłużyć się filtrem antyspamowym. Jest to w tym momencie możliwe, gdyż nie potrzebujemy, aby poczta z adresami nadawcy z naszych domen były przez przesyłane przez serwer Edge.
Konfigurację możemy przeprowadzić z konsoli, wchodząc na serwerze Edge w zakładce Anti-Spam na Sender Filtering. W zakładce Blocked Senders umieszczamy nasze domeny.

Rys.3 Zakładka Blocked Senders

Rys.3. Zakładka Blocked Senders.

Warto również zaznaczyć opcję blokowania poczty od pustych nadawców.

Gdy któraś z domen ma ustawiony MX na inny serwer pocztowy niż nasz, wtedy poczta, która nie znalazła odbiorców na tamtym serwerze, przesyłana jest do naszego. W wypadku, gdy smart-hostem dla takiej poczty jest serwer Edge, wówczas musielibyśmy wykasować tą domenę z zablokowanych nadawców. Najlepiej więc utworzyć dodatkowy Receive Connector na zewnętrznym serwerze Hub Transport właśnie do takich celów.


Jacek Kochan 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 Do początku strony

Exchange 2007 - bezpieczna komunikacja smtp, cz. II     Microsoft Exchange Server