Пограничные транспортные серверы Exchange в корпорации Майкрософт
В течение среднего рабочего дня в корпорации Майкрософт совершается приблизительно 13 миллионов попыток передачи сообщений из Интернета — из них более 10,5 миллионов блокируются как ненадежные. В критических ситуациях, например во время атак нежелательной почты или вирусной эпидемии в Интернете, эта цифра может резко вырасти, превысив 90 миллионов. Безусловно, эти данные относятся к корпорации Майкрософт, но аферы, распространение нежелательной почты, фишинг, вирусы, разносимые электронной почтой, сбор информации о каталогах, распределенные атаки типа «отказ в обслуживании» (DDoS) и другие проблемы подобного свойства возникают не только в Майкрософт. Каким способом при столкновении с этими проблемами обеспечить доставку пользователям всех надежных сообщений, не допуская проникновения в среду обмена сообщениями потока ненадежного и вредоносного содержимого?
Один из способов обеспечения надежной защиты среды обмена сообщениями состоит в развертывании пограничных транспортных серверов Exchange Server 2007 и приложения Forefront Security для Exchange Server в пограничной сети, находящейся между Интернетом и рабочей средой. При этом в пограничной сети размещается организованная группа, включающая в себя более 10 агентов пограничного транспортного сервера, обеспечивающая защиту рабочих систем и пользователей. Очевидна значимость блокировки нежелательного содержимого на самых ранних, по возможности, этапах. В идеале, учитывая ту нагрузку, которая в противном случае ложится на вашу среду обмена сообщениями во время устранения критической ситуации, такую блокировку следует выполнять даже до момента доставки содержимого на ваши серверы. Однако задача защиты среды обмена сообщениями не сводится к простой блокировке сообщений.
Данная статья является первой частью работы, посвященной обсуждению архитектуры и важнейших функций агентов, имеющихся в среде Exchange Server 2007 и приложении Forefront Security для Exchange Server, обеспечивающих защиту от нежелательной почты и вирусов. Чтобы сделать это обсуждение реалистичным и практичным, в первой статье будет показано, как создать лабораторию тестирования, полностью воспроизводящую проект по защите среды обмена сообщениями, используемый Майкрософт в своей корпоративной рабочей среде. Затем архитектура пограничного транспортного сервера среды Exchange Server 2007 будет рассмотрена более подробно.
На протяжении этой статьи будут активно использоваться сценарии и пакетные файлы, предназначенные для автоматизации наиболее важных задач настройки. В эти файлы включены комментарии с объяснениями конкретных выполняемых действий. Сценарии находятся в файлах для загрузки, размещенных на веб-узле журнала TechNet Magazine по адресу technetmagazine.com/code07.aspx.
Топология пограничных транспортных серверов
На рис. 1 показана структура пограничного транспортного сервера, реализованная в корпоративной рабочей среде отделом ИТ корпорации Майкрософт. Прежде чем начать рассмотрение архитектуры пограничного транспортного сервера, хочется обратить ваше внимание на некоторые крайне интересные особенности его структуры. Тем, кого интересуют все детали реализации, рекомендую ознакомиться с документом «Выставка ИТ», ссылка на который имеется на боковой панели «Материалы по Exchange».
Рис. 1 Топология пограничных транспортных серверов в корпорации Майкрософт
Анализируя рис. 1, обратите внимание на то, что в корпорации Майкрософт топология пограничных транспортных серверов в полном объеме обеспечена резервированием. Нет ни одного места, где существовала бы хотя бы одна точка отказа. Для балансировки нагрузки отдел ИТ Майкрософт использует циклический перебор DNS извне и соединители обмена сообщениями с несколькими плацдармами — внутри. Также стоит отметить тот факт, что на всех транспортных серверах (транспортный сервер-концентратор и пограничный транспортный сервер) с целью поиска вирусов выполняется приложение Forefront Security для Exchange Server. Это позволяет отделу ИТ Майкрософт проверять все входящие, исходящие и внутренние сообщения, как только они достигают транспортного сервера в топологии маршрутизации сообщений.
Еще одной важной особенностью проекта, относящейся к безопасности, является то, что пограничные транспортные серверы не являются частью корпоративной среды Active Directory®. Фактически, нет необходимости развертывать пограничные транспортные серверы в каком-либо из лесов Active Directory. Однако для поддержания согласованности инфраструктуры управления, применения общего набора политик и поддержки режима единого входа отдел ИТ Майкрософт развертывает все пограничные транспортные серверы в лесе наружной сети, отделенной от рабочей среды.
В конечном счете, ясно видно, что все сообщения из Интернета достигают корпорации Майкрософт через пограничные транспортные серверы, установленные в Северной Америке. Пограничные транспортные серверы, находящиеся в Дублине и Сингапуре, обрабатывают только исходящие сообщения. Преимущество концентрирования всего входящего трафика на пограничных транспортных серверах в Северной Америке заключается в централизации средств управления безопасностью и борьбы с нежелательной почтой и одновременном избавлении от передачи исходящих сообщений из больших региональных центров данных по внутренней магистрали системы обмена сообщениями.
Топологию пограничных транспортных серверов разработал Омеш Десаи (Omesh Desai), специалист отдела ИТ Майкрософт. На мой вопрос о наиболее важных особенностях проекта Омеш ответил следующее. «Встроенные в Exchange возможности борьбы с нежелательной почтой и вирусами успешно используются в нашем проекте пограничных транспортных серверов для защиты системы обмена сообщениями на нескольких уровнях магистрали обмена сообщениями. Безопасность внешней границы системы обмена сообщениями является первоочередной задачей, но для нас важна также простая модель администрирования и управления. Пограничный транспортный сервер позволяет повысить безопасность за счет более надежных конфигураций брандмауэров при одновременном увеличении точности фильтрации нежелательной почты с помощью служб репутации IP, автоматических обновлений фильтров содержимого, объединения списков надежных отправителей и проверки почтовой марки сообщения электронной почты. По умолчанию выполняется шифрование всех операций взаимодействия серверов, и, по возможности, шифруются также операции взаимодействия с внешними адресатами.
«На наших пограничных транспортных серверах используются два двухъядерных 64-разрядных процессора и восемь гигабайт памяти. При наличии шести таких серверов, нагрузка которых балансируется для двух центров данных, у нас достаточно ресурсов для противостояния даже большим всплескам поступления сообщений, например во время вирусной эпидемии в Интернете».
Установка лаборатории тестирования
Поскольку наилучшей методикой является использование несуществующих имен доменов и частных IP-адресов, я использую AdventureWorks.com и IP-адреса из диапазонов 192.168.xxx.0-24. Резервные системы или массивы брандмауэров отсутствуют, потому что не проводится тестирование балансировки нагрузки или отказоустойчивости. (И, безусловно, реальные системы брандмауэров, используемые отделом ИТ корпорации Майкрософт, не обсуждаются по соображениям безопасности.) В любом случае, такие подробности не имеют значения для данной среды тестирования.
В моей среде тестирования используется среда ISA Server 2006, поскольку она, вероятно, одна из наиболее распространенных систем брандмауэров, используемых совместно с Exchange Server 2007. Запуская ISA Server 2006 как на внутреннем, так и на внешнем брандмауэре, можно поддерживать сложность среды тестирования на среднем уровне, но для рабочих систем я все-таки рекомендую использовать разные системы брандмауэров, являющихся внешними и внутренними, чтобы повысить безопасность. Не разворачиваются политики безопасности IP (IPsec), а также не выполняется подготовка среды для протокола TLS (Transport Layer Security), поскольку эти темы выходят за рамки данной статьи.
Однако используются виртуальные компьютеры и 32-разрядное пробное программное обеспечение, которое можно загрузить с веб-узла Майкрософт. Майкрософт не поддерживает 32-разрядную версию Exchange Server 2007 в рабочих средах, но это не мешает использовать его в среде тестирования.
Везде, где это возможно, моя лаборатория тестирования опирается на настройки по умолчанию. До момента запуска установки Exchange Server 2007 и подписки пограничного транспортного сервера на рабочую среду особое внимание необходимо уделить только настройке IP, брандмауэров и зон DNS. Подробные сведения о настройке IP находятся в файле лаборатории тестирования — IP Configuration.xls, входящем в прилагаемые файлы для загрузки. Если использовать одинаковые назначения IP-адресов, можно быстро настроить внешний брандмауэр, названный ISA01, запустив сценарий ISA01_Firewall_Policies.vbs непосредственно на компьютере ISA01, а для внутреннего брандмауэра (ISA02) использовать сценарий ISA02_Firewall_Policies.vbs. В прилагаемые файлы для загрузки включены также пакетные файлы для настройки серверов DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat и AD02_DNS_Config.bat). Поскольку в этих пакетных файлах используется средство командной строки для DNS (dnscmd.exe), потребуется установить средства поддержки Windows; в противном случае придется вручную создавать записи DNS с помощью консоли DNS.
Для устранения какого-либо влияния со стороны существующих сред моя лаборатория тестирования не подключена к Интернету. Такая изоляция является разумной предосторожностью. Это приводит к тому, что все загрузки обновлений сигнатур, репутаций IP и обновлений фильтра содержимого завершаются аварийно, но для целей тестирования это не так важно. Чтобы устранить сообщения об ошибках, перейдите в консоли администратора Forefront Server Security в режим «Scanner Updates» (обновления системы проверки), установите однократное обновление для всех механизмов проверки и укажите прошедшую дату.
Лаборатория тестирования пограничного транспортного сервера
Разумным подходом к изучению этих функций в рабочем режиме является создание среды тестирования — здравый смысл подсказывает, что в целях тестирования никогда нельзя использовать рабочую систему. Для выполнения ролей сервера почтовых ящиков, клиентского доступа и транспортного сервера-концентратора потребуется как минимум один сервер, на котором работает Exchange Server 2007. Для роли пограничного транспортного сервера понадобится второй сервер Exchange. Если все агенты транспорта разворачиваются на сервере с несколькими ролями посредством запуска сценария Install-AntispamAgents.ps1 (он находится на транспортных серверах-концентраторах в папке %ProgramFiles%\Microsoft\Exchange Server\Scripts), установку пограничного транспортного сервера можно пропустить. Но такой подход вряд ли будет напоминать развертывание, выполненное отделом ИТ в Майкрософт. Для получения реалистичной лаборатории тестирования необходимо включить еще несколько серверов. На рис. 2 показана среда тестирования, которую я использовал при работе над этой статьей. Более подробная схема входит в прилагаемые файлы для загрузки. Дополнительные сведения о настройке лаборатории приведены на боковой панели «Установка лаборатории тестирования».
Во время подписки пограничного транспортного сервера и настройки соответствующих соединителей отдел ИТ Майкрософт удаляет все соединители по умолчанию, после чего переходит к созданию четырех соединителей отправки для эффективного взаимодействия с узлами SMTP разных типов и внутренними транспортными серверами-концентраторами. Первый соединитель отправки представляет собой подключатель к Интернету для всех адресов назначения, не удовлетворяющих специальным определениям пространства адресов.
Второй соединитель отправки является подключателем к Интернету с подробными определениями пространства адресов для известных адресов назначения, не поддерживающих протокол Extended SMTP (домены HELO). Устанавливая значение $true для параметра ForceHELO данного соединителя, отдел ИТ Майкрософт при установлении подключений SMTP избавляется от ненужной последовательности EHLO, Failure Response 500, HELO.
Третий соединитель отправки является подключателем к Интернету с подробными определениями пространства адресов для партнеров и других удаленных доменов, поддерживающих TLS, для безопасного взаимодействия через шифрованные подключения (домены TLS). Для параметра RequireTLS данного соединителя установлено значение $true.
Четвертый соединитель отправки является соединителем приема, предназначенным для передачи полученных из Интернета сообщений на транспортные серверы-концентраторы корпоративной среды. Более подробные сведения, относящиеся к настройке пограничного транспортного сервера, также приведены в документе «Выставка ИТ», ссылка на который находится на боковой панели «Материалы по Exchange» в конце этой статьи.
Применяя для лаборатории тестирования топологию соединителей в стиле отдела ИТ Майкрософт, я основывался на процедуре, использующей сценарии, созданные Омешем для внутреннего использования в отделе. По соображениям безопасности я радикально изменил и укоротил отдельные команды, но результирующая топология соединителей все еще соответствует топологии, используемой в отделе ИТ Майкрософт. Процедура состоит из следующих этапов.
1...На многоролевом сервере Exchange (HUB-MBX-01) и пограничном транспортном сервере (EDGE01) удаляются соединители по умолчанию. 2...На HUB-MBX-01 создается новый соединитель в результате выполнения сценария HUB-MBX-01_recv_connector.ps1, который находится в файлах загрузки, сопровождающих эту статью. 3...На EDGE01 в результате выполнения сценария EDGE01_recv_connector.ps1 создаются два новых соединителя, обеспечивающие связь для обмена сообщениями с внутренней и внешней средой. 4...На EDGE01 создается файл подписки в результате выполнения следующей команды.
Затем полученный файл подписки копируется в корневую папку (c:\subscriptionfile.xml) транспортного сервера-концентратора.
5. Необходимо убедиться в том, что c:\subscriptionfile.xml — путь к файлу подписки на HUB-MBX-01, после чего запустить сценарий HUB-MBX-01_complete_subscription.ps1. В этом сценарии выполняется импорт файла подписки для синхронизации пограничных серверов без автоматического создания соединителя отправки, создаются соединители отправки для Интернета и внутренней связи, и результирующая настройка реплицируется на пограничный транспортный сервер посредством синхронизации пограничных серверов.
6. Проверка настройки осуществляется посредством отправки из узла Интернета тестовых сообщений с адресов Contoso.User@contoso.com и Fabrikam.User@fabrikam.com по адресу Administrator@adventureworks.com и ответа на полученные сообщения для проверки работы передачи входящих и исходящих сообщений.
Рекомендуется открыть конкретные файлы сценариев в приложении «Блокнот» и проанализировать командлеты и параметры, используемые этими сценариями для выполнения настройки. Подробные сведения об этих командлетах и параметрах имеется в Интернете в документации по программному продукту для Exchange Server 2007.
Архитектура пограничного транспортного сервера
Перейдем теперь к агентам пограничного транспортного сервера, ожидающим возможности сказать кому-нибудь HELO или EHLO с того момента, как была установлена роль пограничного транспортного сервера. Если на пограничном транспортном сервере выполняется командлет Get-TransportAgent, должны отобразиться 11 записей, перечисленных на рис. 3. По умолчанию все агенты активированы посредством определенных параметров для обеспечения защиты системы обмена сообщениями.
Рис. 3 Агенты транспорта
В командлете Get-TransportAgent и на рис. 3 агенты перечислены в порядке их приоритетов, но это не тот порядок, в котором данные агенты выполняют свою работу. Последовательность, в которой они работают, зависит главным образом от последовательности событий приема SMTP и маршрутизации событий, для которых данные агенты зарегистрированы. Чтобы понять, как агенты и события сопоставляются друг другу, рассмотрим схему, показанную на рис. 4, которая поясняет, каким образом агенты транспорта включаются в архитектуру пограничного транспортного сервера.
Рис. 4 Агенты транспорта в архитектуре пограничного транспортного сервера
Транспортные события создаются на различных этапах обработки сообщений с целью вызова дополнительных модулей для фильтрации нежелательной почты, поиска вирусов и выполнения других задач. В такой слабосвязанной и расширяемой структуре роль источника событий берет на себя процесс пограничного транспортного сервера (EdgeTransport.exe). Обработчики событий, или, другими словами, агенты транспорта, управляются объектами-делегатами на базе Microsoft® .NET Framework 2.0 и зарегистрированы вместе с источником события для приема уведомлений обратного вызова.
На рис. 5 показаны регистрации всех агентов, установленных на пограничном транспортном сервере с приложением Forefront Security. Возможно, с этими регистрациями довольно трудно разобраться из-за большого числа регистраций агентов, но отчаиваться не следует. Выполнив на пограничном транспортном сервере команду Get-TransportPipeline | Format-List, можно в более удобном виде проанализировать регистрации для каждого отдельного транспортного события. Достаточно убедиться в том, что работает транспортная служба Microsoft Exchange (MSExchangeTransport.exe) и что с момента последнего перезапуска службы по крайней мере одно сообщение было отправлено через пограничный транспортный сервер. В результате выясняется, что для события одного типа можно зарегистрировать несколько агентов и что для одного агента можно зарегистрировать несколько событий. Регистрации событий зависят от требований обработки, предъявляемым соответствующим агентом.
Рис. 5 Регистрации событий для агентов транспорта
Одним из наиболее важных событий является событие маршрутизации OnSubmittedMessage, возникающее при достижении сообщением очереди передачи. Все сообщения должны пройти через эту очередь независимо от пути их поступления — через SMTP, файловую систему или любой другой механизм. Классификатор является основным компонентом архитектуры пограничного транспортного сервера, отвечающим за разрешение получателей, разветвление сообщений и создание уведомлений о состоянии доставки (DSN). Событие OnSubmittedMessage, таким образом, является идеальным вариантом для регистрации агентов, которые должны обрабатывать все принимаемые сообщения. Агент маршрутизации FSE является компонентом приложения Forefront Security, зарегистрированным для события OnSubmittedMessage с целью передачи всех принимаемых сообщений обработчикам, выполняющим поиск вирусов. Поскольку агент маршрутизации FSE зарегистрирован для события OnSubmittedMessage, ни одно сообщение не минует процедуру поиска вирусов.
Почему же в таком случае не зарегистрировать все агенты для события OnSubmittedMessage и не считать задачу выполненной? По той причине, что нежелательные сообщения требуется блокировать на как можно более раннем этапе — до того, как сервер подтвердит успешную доставку. В противном случае вашим серверам, возможно, придется обрабатывать 90 миллионов нежелательных сообщений, поступающих во время атак нежелательной почты или вирусных атак, и создавать 90 миллионов отчетов о невыполнении доставки (NDR), что, в свою очередь, может создать серьезную угрозу для безобидных наблюдателей. Атаки нежелательной почты и вирусные атаки почти всегда используют подложные данные об отправителе. Отправка миллионов отчетов NDR получателям, не создававшим исходных сообщений, является не только бесполезной тратой ваших ресурсов и ресурсов предприятий получателей — таким образом пользователям-злоумышленникам предоставляется возможность запускать атаки с отправкой огромного числа почтовых сообщений и атаки DDoS. Важно вовремя остановить злоумышленников-отправителей, чтобы защитить себя и других.
Для эффективной блокировки сообщений агент транспорта должен прервать диалог по протоколу SMTP до того, как ваш сервер подтвердит успешное получение данных посредством кода состояния 250. В соответствии с принципом хранения и пересылки протокола SMTP ваш сервер может безопасно отбросить любые полученные данные, не создавая отчеты NDR, если доставка сообщения не была подтверждена. Эту задачу могут выполнить агенты приема SMTP. Они взаимодействуют с сеансом SMTP, поскольку транспортный конвейер вызывает эти агенты на основе событий приема SMTP, когда удаленный узел соединяется с сервером; устанавливает сеанс SMTP; передает глаголы SMTP; отправляет сообщения и завершает соединение. (События приема SMTP, связанные с каждым их этапов, перечислены на рис. 6.) Вследствие способности отклонять сообщения до момента доставки и отключения удаленных узлов SMTP все агенты Exchange Server 2007, противостоящие нежелательной почте, реализуются в качестве агентов приема SMTP.
Рис. 6 События сеансов SMTP
Важно осознавать разницу между агентами приема SMTP и агентами маршрутизации в том, что касается их контекстов обработки. В то время как агенты маршрутизации имеют полный доступ к свойствам сообщений, агенты приема SMTP более чувствительны к контексту, поскольку эти агенты взаимодействуют с сеансом SMTP. Например, фильтр нежелательной почты не может действовать в соответствии со свойствами сообщения до тех пор, пока удаленный узел действительно не передал сообщение. Следовательно, регистрация агента важна для правильного события приема SMTP. Более глубокие пояснения приведены на боковой панели «Разработка агента транспорта».
Ждите продолжения…
Сделаем перерыв перед тем как углубиться в архитектуру транспорта и тестовые ситуации. Было рассмотрено множество вопросов, начиная от развертывания пограничных транспортных серверов в стиле отдела ИТ Майкрософт и до внутренних событий, запускаемых в транспортном конвейере во время обработки сообщений. В следующем выпуске этой серии из двух частей будет продолжен анализ поведения агентов пограничного транспортного сервера в нескольких любопытных тестовых ситуациях.
Тем временем я рекомендую загрузить 90-дневную пробную версию Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043) и поступить в соответствии с рекомендациями Стива, относящимися к компиляции и установке примеров агентов в вашей среде тестирования. Даже не являясь разработчиком, вы согласитесь с тем, что эти задачи выполняются крайне просто. Учитывая то, насколько удобно в среде Exchange Server 2007 разрабатывать такие компоненты с помощью Visual Studio 2005, меня не удивит рост числа бизнес-приложений, основывающихся на пользовательских агентах.
