Как обеспечить пользователям
организации возможность надежного и безопасного обмена сообщениями,
учитывая, что Интернет переполнен нежелательной информацией и другим
вредоносным содержимым? Один из способов, который я начал описывать
в прошлом месяце в первой части этой серии, заключается в
развертывании
пограничных транспортных
серверов Exchange Server 2007 и приложения Forefront Security для
Exchange Server в демилитаризованной зоне (пограничной сети),
отделяющей Интернет и рабочую среду.
Во второй, завершительной части статьи, я
расскажу, как выполняется анализ агентов пограничных транспортных
серверов с помощью стандартных функций Exchange Server 2007,
трассировки и записи агентов в журнал. Также я остановлюсь на
пользовательском методе записи всех объектов событий из
транспортного конвейера в файлы на основе XML. Далее я
проиллюстрирую применение настроек защиты от нежелательной почты в
лаборатории тестирования пограничного транспортного сервера в
соответствии с конфигурацией, которую использует Microsoft в
собственной корпоративной рабочей среде. И, наконец, в завершение
темы я приведу несколько реалистичных и интересных тестовых
сценариев, которые показывают, как агенты пограничных транспортных
серверов действуют в различных ситуациях при получении нежелательной
почты.
Дополнительную информацию по установке
лаборатории тестирования пограничных транспортных серверов и их
общей архитектуре можно найти в первой статье этой серии в
октябрьском выпуске журнала TechNet Magazine за 2007 г.,
который доступен на веб-узле technetmagazine.com/issues/2007/10/Edge.
Я активно использовал сценарии и пакетные файлы
для автоматизации наиболее важных задач настройки. Вы можете найти
их в загружаемом приложении к этой статье (для этого зайдите на
страницу technetmagazine.com/code07.aspx).
Для более полного ознакомления с настройкой IT агентов пограничных
транспортных серверов Майкрософт рекомендую техническое описание
«Microsoft® Exchange Server 2007 Edge
Transport and Messaging Protection» для Microsoft IT Showcase. Это
описание можно загрузить на странице microsoft.com/technet/itshowcase/content/edgetransport.mspx.
Ведение журнала и
трассировка
Exchange Server 2007 включает ряд функций ведения
журнала и трассировки, в том числе журнал протокола, журнал агентов
и трассировку конвейера. Эти функции упрощают диагностику и решение
проблем с транспортными агентами. В этой статье я не буду подробно
останавливаться на устранении неполадок с транспортными агентами, но
приведенной здесь информации о ведении журнала и трассировке вполне
достаточно для понимания принципов работы этих агентов.
Если вы хотите отслеживать информацию об
операциях отправки и получения SMTP, необходимо активировать ведение
журнала протокола для соединителей отправки и получения. С помощью
тестовой среды, установка которой описана в первой части этой статьи
(см. рис. 1), я активировал ведение
журнала протокола посредством следующих настроек командлетов
New-SendConnector и New-ReceiveConnector:
Рис. 1 Тестовая среда
–ProtocolLoggingLevel: Verbose
Полученные файлы журнала SMTP
по умолчанию сохраняются во вложенных папках, путь к которым
выглядит следующим образом: %ProgramFiles%\Microsoft\Exchange
Server\TransportRoles\Logs\ProtocolLog.
Ведение журнала протокола очень удобно для
анализа диалогов по протоколу SMTP, хотя агенты защиты от
нежелательной почты не всегда влияют на SMTP-сеансы. Например, агент
фильтра содержимого может помечать только входящие сообщения,
устанавливая значение уровня вероятности нежелательной почты (SCL).
Если уровень SCL ниже установленного порогового значения (по
умолчанию оно равно 7), агент фильтра содержимого не активирует
процесс отклонения сообщения пограничным транспортным сервером. Вот
почему диалог по протоколу SMTP продолжается без каких-либо
изменений.
Чтобы проанализировать действия, которые агенты
защиты от нежелательной почты (агенты фильтра подключений, фильтра
содержимого, правил пограничного сервера, фильтра получателей,
фильтра отправителей и идентификатора отправителей) выполняют над
сообщениями, проходящими через транспортный конвейер, вам
понадобится просмотреть не журнал протокола, а журнал агентов.
Ведение журнала агентов обычно активировано в соответствии с
параметром AgentLogEnabled в файле EdgeTransport.exe.config. Журналы
агентов по умолчанию сохраняются в папке
%ProgramFiles%\Microsoft\Exchange
Server\TransportRoles\Logs\ProtocolLog. Открыть файлы журнала можно
в Блокноте, хотя командлет Get-AgentLog отображает информацию из
журнала на командной консоли Exchange более наглядно.
Трассировка конвейера — это еще одна полезная
функция, которая позволяет делать моментальные снимки сообщений
конкретного отправителя в процессе передачи этих сообщений по
транспортному конвейеру. Идея относительно проста: процесс
пограничного транспортного сервера создает моментальный снимок
каждого сообщения до и после вызова агентов получения и
маршрутизации SMTP, зарегистрированных для событий OnEndOfHeaders,
OnEndofData, OnSubmittedMessage и OnRoutedMessage. Сравнивая эти
снимки, вы можете увидеть, как различные агенты изменяют каждое
сообщение. Конечно, сначала необходимо активировать эту
замечательную функцию в среде тестирования.
Следующая последовательность действий с
командлетом Set-TransportServer активирует трассировку конвейера для
тестового пользователя. Параметр PipelineTracingEnable,
установленный на значение $true, как вы уже, наверное, догадались,
активирует трассировку конвейера. Адрес электронной почты тестового
пользователя указывается в параметре
PipelineTracingSenderAddress:
Set-TransportServer –Identity EDGE01
–PipelineTracingEnabled $true
-PipelineTracingSenderAddress Contoso.User@contoso.com
Когда трассировка конвейера включена, файлы
моментальных снимков всех сообщений указанного отправителя (в данном
случае это Contoso.User@contoso.com) сохраняются в папке
%ProgramFiles%\Microsoft\Exchange
Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots. Это
папка по умолчанию. Файлы моментальных снимков каждого сообщения
сохраняются в отдельном подкаталоге, названном в соответствии с
идентификатором GUID, который присвоен данному сообщению. Обратите
внимание, что исходное сообщение находится в файле Original.eml, а
копии сообщения — в файлах EML, имя которых начинается на
«SmtpReceive» или «Routing» в зависимости от имевших место событий и
установленных агентов. Чтобы проанализировать обработку агентов
защиты от нежелательной почты, зарегистрированных для событий
получения SMTP OnEndofData и OnEndOfHeaders, просмотрите файлы
SmtpReceive*.eml. Чтобы проанализировать обработку антивирусных и
других агентов, зарегистрированных для событий маршрутизации
OnSubmittedMessage и OnRoutedMessage, просмотрите файлы
Routing*.eml.
Настройка
записи данных конвейера
Стандартные функции ведения журнала и трассировки
в Exchange Server 2007 удовлетворяют всем требованиям по поиску и
устранению неисправностей, несмотря на то, что фактически
стандартные функции не охватывают весь спектр событий, связанных с
транспортом. Например, функция трассировки конвейера не может
получить информацию о событиях OnConnectEvent, OnEhloCommand,
OnMailCommand, OnRcptCommand, OnDataCommand и аналогичных событиях,
поскольку узел отправки еще не передал никаких сообщений, которые
могли бы быть записаны в папку %ProgramFiles%\Microsoft\Exchange
Server\TransportRoles\Logs\PipelineTracing. Если вы хотите получить
подробную информацию об этих событиях, создайте пользовательский
агент для записи сведений об этих событиях в файлы файловой
системы.
В предыдущей статье мы уже выяснили, что создание
пользовательских агентов не представляет никаких трудностей, поэтому
вы легко сможете создать агент получения SMTP и агент маршрутизации
для записи всех объектов событий с транспортного конвейера в
XML-файлы. Соответствующий проект Microsoft Visual Studio® 2005 под названием PipelineXMLDump можно
найти в загружаемом приложении к этой статье. Наибольшую важность
представляют два файла: DumpAgents.cs, который создает агенты и
фабрики агентов, и XMLDump.cs, который создает вспомогательный класс
для записи полей источников событий и объектов аргументов событий в
XML-файлы с помощью методов System.Re- flection. Скомпилировав
исходный код и скопировав полученный файл PipelineXMLDump.dll в
папку C:\PipelineXMLDump на тестовом пограничном транспортном
сервере, вы получите возможность регистрировать и активировать
пользовательские агенты с помощью сценариев
RegisterPipelineXMLDump.ps1 и EnableDumpAgents.ps1. Эти сценарии
включены в папку проекта PipelineXMLDump в загружаемом приложении.
Приведенные мною пользовательские агенты годятся, конечно же, только
для иллюстративных целей. Они не были должным образом
протестированы, и их не следует устанавливать на производственном
сервере. Используя эти агенты, вы действуете на свой страх и
риск.
В файле DumpAgents.cs содержатся сведения о том,
как создавать обработчики событий маршрутизации и получения SMTP,
которые поддерживает транспортный конвейер. Эти сведения станут
хорошей отправной точкой при создании собственных пользовательских
агентов. Мои агенты записи записывают файлы XML во вложенные папки
по адресу %ProgramFiles%\Microsoft\Exchange
Server\TransportRoles\Logs\PipelineXMLDump, который соответствует
идентификатору сеанса SMTP (агент получения SMTP) либо
идентификатору сообщения (агент маршрутизации). На рис. 2 показан пример передачи информации об
аргументе события агенту получения SMTP в обработчике
OnConnectEvent. В этом примере показана локальная конечная точка IP
(IP-адрес и порт), которая принимает входящий запрос на
подключение.
Рис.
2 Информация об аргументе
записывается во время события OnConnect
Подготовка тестовых запусков
Немного теории о ведении журналов, трассировке и
записи. Итак, давайте сделаем несколько тестовых запусков, чтобы
посмотреть на агенты защиты от нежелательной почты в действии. Ниже
приведено краткое описание, отражающее настройку Microsoft IT так
точно, насколько это возможно в среде тестирования. Как уже было
сказано, дополнительную информацию можно найти в техническом
описании «Microsoft Exchange Server 2007 Edge Transport and
Messaging Protection».
Для начала следует деактивировать входящий агент
перезаписи адресов, агент фильтрации вложений и исходящий агент
перезаписи адресов путем выполнения сценария
EDGE01_disable_agents.ps1 из загружаемого приложения. Перезапись
адресов нам не нужна, поскольку получатели используют одни и те же
электронные адреса внутри сервера и вне его. Я не использовал агент
фильтрации вложений, поскольку в Forefront Security предусмотрены
возможности фильтрации вложений с заменой.
Среда тестирования не подключается к Интернету.
Это затрудняет тестирование агента фильтрации подключений. Для
решения этой проблемы можно создать на Интернет-узле список
заблокированных IP-адресов посредством запуска файла
INTERNET01_create_IP_block_list.bat. Проверьте, установлены ли на
вашем компьютере средства поддержки Windows®: это необходимо, так как они включают
средство командной строки DNS (dnscmd.exe). В противном случае вам
придется потратить много времени, вручную создавая DNS-записи с
помощью консоли DNS.
Теперь можно настроить агент фильтрации
подключений путем выполнения сценария
EDGE01_add_block_list_provider.ps1. Этот сценарий добавляет
поставщика списка заблокированных IP-адресов для
ip-bl.consolidatedmessenger.com. Это список заблокированных
IP-адресов Consolidated Messenger, уже созданный в среде
тестирования путем запуска файла INTERNET01_create_IP_block_list.bat
на Интернет-узле по описанной выше процедуре. Microsoft IT
использует также локальный список заблокированных IP-адресов и
список разрешенных IP-адресов, но эти функции, однако, не требуют
настройки вручную. Важно отметить, что Microsoft IT не использует
поставщики списков разрешенных IP-адресов.
Далее нужно настроить агент фильтра получателей:
для этого выполняется сценарий EDGE01_recipient_filter.ps1, который
блокирует сообщения, адресованные несуществующим получателям, а
также сообщения для почтовых ящиков и списков глобальной рассылки,
предназначенных только для внутреннего или внешнего
использования.
Агент фильтра отправителей также нуждается в
обновлении настроек. Microsoft IT использует фильтры отправителей
как контрмеру против засорения почты огромным количеством сообщений,
отправляемых с определенных адресов, а также для блокирования
конкретных серверов рассылки и аналогичных источников, не имеющих
отношения к бизнесу. Кроме того, Microsoft IT использует фильтры
получателей для блокирования сообщений с неверной либо отсутствующей
информацией об отправителе. Давайте попробуем применить эту
настройку в среде тестирования; для этого мы должны выполнить
сценарий EDGE01_sender_filter.ps1 на пограничном транспортном
сервере.
Если вы хотите отразить конфигурацию Microsoft
IT, вам понадобится также настроить записи инфраструктуры политик
отправителя (SPF) в DNS. Для создания записи SPF, подтверждающей
полномочия пограничного транспортного сервера относительно сообщений
из вашего домена adventure-works.com, можно использовать мастер
записи SPF системы кода отправителя Microsoft, доступный на странице
microsoft.com/mscorp/safety/content/technologies/senderid/wizard.
Попробуйте указать имя существующего домена в Интернете. В среде
тестирования файл INTERNET01_create_SPF_record.bat можно запустить
на Интернет-узле.
Вот и все! Больше никакие параметры настраивать
не требуется, поскольку большинство агентов имеют вполне приемлемые
настройки по умолчанию. Для быстрой проверки наиболее важных
настроек по умолчанию для агентов правил пограничного сервера,
идентификатора отправителя, анализа протокола и фильтра содержимого
выполните сценарий EDGE01_check_defaults.ps1 на пограничном
транспортном сервере.
Агенты пограничного транспортного сервера в
действии
А теперь давайте посмотрим, как работают агенты
пограничного транспортного сервера в некоторых реалистичных
сценариях обмена сообщениями. Для отправки тестовых сообщений на
пограничный транспортный сервер я использовал SMTP и службу POP3,
исполняющую в Windows Server 2003 и Outlook® Express роль клиента обмена сообщениями.
Изменять настройки по умолчанию почти не пришлось; я только
проверил, активировано ли ведение журнала.
Однако прежде всего обратите внимание на
следующее: не выполняйте никакие инструкции и не запускайте
сценарии, описанные в этом разделе, если ваша среда тестирования
подключена к каким-либо рабочим системам или Интернету. Выполняя
тестирование, вы действуете на свой страх и риск.
Итак, для начала я протестирую агент фильтра
подключений. Он удостоился чести быть первым, поскольку это самый
«работящий» агент на пограничном транспортном сервере. В Майкрософт
агент фильтра подключений блокирует около 88 процентов всех
отправляемых в Интернете сообщений. За обычный рабочий день
предпринимается порядка 13 миллионов попыток отправки сообщений, из
них только 1,5 миллиона — от надежных отправителей.
Давайте попробуем отправить сообщение от имени
Fabrikam.User@Fabrikam.com по адресу
Administrator@adventure-works.com. Если все работает нормально,
указанный адресат не получит наше сообщение. А пользователь
Fabrikam.User получит уведомление о состоянии доставки (DSN), в
котором будет сказано, что при доставке сообщения получателю
произошла ошибка. Пользователь Fabri- kam.User проверяет адрес
получателя, убеждается, что он введен верно, и заново отправляет
сообщение. Но ему опять приходит то же самое уведомление DNS. Он
звонит в службу поддержки и объясняет ситуацию. Оказывается, он не
первый, кто столкнулся с такой проблемой. Фактически теперь никто из
Fabrikam не сможет взаимодействовать с Adventure Works. Что-то явно
изменилось. И эта проблема требует немедленного решения. Желая
поскорее разобраться, в чем тут дело, вы проверяете журналы SMTP в
папке %systemroot%\system32\Logfiles\SMTPSVC1 на INTERNET01, и сразу
же обнаруживаете причину всех своих бед: она показана красным
шрифтом на рис. 3.
Рис. 3 Журнал SMTP отражает суть проблемы
... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu,
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by
ip-bl.consolidatedmessenger.com. Please visit
http://www.consolidatedmessenger.com/ip-bl for more information.
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel
Из сообщения об ошибке 550 вы узнаете, что
Consolidated Messenger поместил IP-адрес вашего Интернет-узла в
список заблокированных IP-адресов. Теперь все понятно. Вы
связываетесь с Consolidated Messenger, чтобы удалить свой адрес из
этого списка. Очень скоро вы узнаете, что попасть в список
заблокированных адресов Consolidated Messenger намного проще, чем
быть удаленным из него. Для этого вам потребуется несколько дней,
если не недель.
В стремлении как можно быстрее разрешить
возникшую ситуацию вы обращаетесь в Adventure Works по адресу
cmipbl@adventure-works.com. В отправленном с адреса
Fabrikam.Admin@Fabrikam.com сообщении вы описываете ситуацию и
просите разблокировать IP-адрес вашего узла (в данном случае
192.168.1.100). После установления вашей личности Adventure Works
разблокирует адрес с помощью приведенной ниже команды,
предоставляющей временное исключение, срок действия которого
истекает через 30 дней.
Add-IPAllowListEntry -IPAddress 192.168.1.100
-ExpirationTime (get-date).AddDays(30)
Тридцати дней вам вполне хватит на выяснение
отношений с Consolidated Messenger, чтобы Adventure Works не
приходилось каждый раз вручную поддерживать это исключение.
Предоставляя исключения с автоматическим истечением срока действия,
Adventure Works максимально снижает административные издержки,
связанные с поддержкой списков разрешенных IP-адресов.
Надежные отправители
А теперь давайте протестируем функцию
осведомленности о надежных отправителях при фильтрации содержимого.
Это новое и интересное средство, позволяющее повысить точность
фильтрации нежелательной почты. Служба EdgeSync распространяет
информацию о надежном отправителе из внутренней среды на пограничные
транспортные серверы в хэшированной и зашифрованной форме. Эта
информация помогает агенту фильтра содержимого принимать правильные
решения в процессе фильтрации. От вас требуется только ввести
информацию о надежном отправителе (список надежных отправителей,
список надежных получателей, список запрещенных отправителей и
внешние контакты) в службу каталогов Active Directory® с помощью командлета Update-SafeList, а затем
продублировать эту информацию на пограничном транспортном сервере,
воспользовавшись командлетом Start-EdgeSynchronization. Microsoft IT
регулярно запускает командлет Update-SafeList в нерабочее время. В
нашей тестовой среде достаточно будет вручную запустить
соответствующий сценарий (HUB-MBX-01_update_safelist.ps1).
Первым делом следует выполнить очистку среды
тестирования, запустив сценарий EDGE01_clean_up.ps1 на пограничном
транспортном сервере для удаления созданных ранее записей в списке
разрешенных IP-адресов. Это необходимо сделать, так как агент
фильтра содержимого не работает с сообщениями из источников,
входящих в этот список. Затем необходимо удалить из списка
заблокированных адресов Consolidated Messenger запись для
100.1.168.192.ip-bl.consolidatedmessenger.com путем запуска файла
INTERNET01_clean_up.bat на Интернет-узле. Если этого не сделать,
моделируемый Интернет-узел не сможет отправлять сообщения, как было
показано ранее.
И, наконец, нужно отправить сообщение, которое
агент фильтра содержимого почти наверняка примет за нежелательную
почту. Это довольно сложная задача, поскольку агент фильтра
содержимого использует в качестве порогового значения для отклонения
сообщения уровень вероятности нежелательной почты (SCL) по
умолчанию, что позволяет доставлять большинство сообщений
пользователям с минимальным количеством ошибочных срабатываний.
Методом проб и ошибок мне удалось найти такое сообщение, в котором
уровень SCL достигает порога отклонения. Чтобы отправить такое
сообщение с адреса Contoso.User@Contoso.com, запустите сценарий
INTERNET01_contoso_msg.vbs на Интернет-узле.
Мои сценарии используют для отправки сообщения в
службу SMTP на INTERNET01 анонимное SMTP-подключение. Для этого
нужно настроить службу SMTP на ретрансляцию сообщений анонимным
пользователям. В диспетчере служб IIS откройте свойства виртуального
сервера SMTP по умолчанию. На вкладке «Доступ» нажмите кнопку
«Ретрансляция», а затем выберите вариант «Все, кроме
нижеперечисленных». Чуть позже я объясню, чем обусловлен выбор этого
параметра.
После запуска сценария для отправки этого
сообщения пользователь Contoso.User должен получить уведомление DNS
об ошибке при доставке сообщения с указанием кода диагностики:
smtp;550 5.7.1 Сообщение отклонено в связи с ограничениями по
содержимому. Эту запись можно также найти в журнале SMTP на
Интернет-узле, а если вы выполните команду Get-AgentLog |
Select-Object -Last 1 на пограничном транспортном сервере для
отображения последней записи из журнала агентов, вы увидите, что
сообщение было отклонено из-за того, что его уровень SCL равен 7,
как показано на рис. 4.
Рис.
4 Сообщение заблокировано в связи
с ограничениями по содержимому.
Отныне пользователь Contoso.User больше не
является отправителем нежелательной почты. К сожалению, в этот раз
сообщение не было отправлено, однако пользователь Contoso.User
обычно имеет возможность связываться с получателями в Adventure
Works. Итак, Contoso.User информирует администратора в другом
сообщении о том, что его исходное сообщение было по ошибке
заблокировано. Администратор знает пользователя Contoso.User и
потому добавляет его в список надежных отправителей, чтобы сообщения
этого пользователя больше не блокировались фильтрами нежелательной
почты. В программе Office Outlook 2007 для этого нужно щелкнуть
правой кнопкой полученное от пользователя Contoso.User сообщение,
выбрать пункт «Нежелательная почта», а затем «Добавить отправителя в
список надежных отправителей».
Командлет Update-SafeList запускается через
определенные промежутки времени в целях обновления данных списка
надежных отправителей в службе Active Directory, и после очередной
синхронизации пограничного сервера Contoso.User сможет
беспрепятственно общаться с администратором без ложных срабатываний.
Для моделирования этой процедуры запустите сценарий
HUB-MBX-01_update_safelist.ps1.
Теперь запустите сценарий
INTERNET01_contoso_msg.vbs для повторной отправки сообщения
пользователя Contoso.User. После этого проверьте журнал агентов на
пограничном транспортном сервере, используя команду Get-AgentLog |
Select-Object -Last 1, и в разделе ReasonData вы увидите, что
фильтрация содержимого в этом случае не выполнялась. Отныне никаких
ложных срабатываний для пользователя Contoso.User!
Нежелательная почта:
атака
В завершение наших тестовых запусков давайте
попробуем провести испытания в условиях, максимально приближенных к
реальным. Как вы, конечно же, заметили, в ходе предыдущего
тестирования я настроил Интернет-узел как открытый ретранслятор,
превратив его тем самым в настоящую находку для отправителей
нежелательной почты. Давайте посмотрим, что случится, если некий
злоумышленник Spam.Sender@cohovineyards.com обнаружит это слабое
место и использует его для своих неблаговидных целей — то есть для
отправки тысяч нежелательных сообщений в Adventure Works. Сценарий
INTERNET01_spam_msg.vbs отправляет всего одно нежелательное
сообщение, но его можно отредактировать таким образом, чтобы он
отправлял намного больше сообщений. Для этого нужно изменить
значение max_loop.
Для моделирования атаки я отправил 1000 сообщений
на свой взломанный узел для ретрансляции на пограничный транспортный
сервер. Служба SMTP ограничивает количество сообщений на одно
исходящее подключение числом 20, поэтому от начала ретрансляции
нежелательных сообщений до активации агента анализа протокола может
пройти некоторое время.
Агент анализа протокола помогает агенту фильтра
подключений, автоматически обрабатывая записи в списке
заблокированных IP-адресов на основе анализа протокола SMTP и
обновлений службы репутации IP-адресов из центра обновлений
Microsoft. В данном случае анализ протокола SMTP «отловил»
нежелательные сообщения. Агент анализа протокола отслеживает уровень
SCL каждого сообщения, чтобы вычислить среднее значение SCL, которое
используется для определения уровня репутации отправителя (SRL). По
мере поступления все большего и большего количества нежелательных
сообщений уровень SRL Интернет-узла увеличивается до тех пор, пока
не превысит порог блокировки. Тогда узел на 24 часа помещается в
список заблокированных IP-адресов. Больше никакой нежелательной
почты с этого адреса! Это действие выполняется автоматически.
Участие администратора не требуется.
На рис. 5 показана конечная запись в списке
заблокированных адресов и соответствующие изменения в обработке
сообщений. Прежде чем блокировать узел, пограничный транспортный
сервер отклоняет каждое нежелательное сообщение в течение события
OnEndOfData, поскольку именно агент фильтра содержимого обрабатывает
каждое сообщение на основании порогового значения SCL (см. рис. 4). Сообщение, хотя и не успешно, было
отправлено. После блокировки узла подключение было отклонено агентом
фильтра подключений в ходе события OnMailCommand. Теперь отправка
сообщений невозможна. Это позволяет освободить полосу пропускания
сети и ресурсы обработки благодаря отключению отправителей
нежелательной почты до отправки сообщений.
Рис.
5 Блокирование нежелательного
Интернет-узла
Дополнительное тестирование
Помимо уже перечисленных, существует, разумеется,
еще множество других сценариев и функций агентов, которые можно
протестировать. Например, вы можете протестировать фильтрацию
отправителей. Для этого нужно отправить сообщения с адреса
Blocked.User@Contoso.com или Blocked.User@Fabrikam.com. Также вы
можете протестировать фильтрацию получателей. Для этого отправьте
сообщения на адрес Blocked.User@adventure-works.com. Кроме того, вы
можете воспользоваться средством Telnet для моделирования атаки с
целью сбора существующих адресов с различными интервалами
искусственной задержки ответов. Microsoft IT использует интервал по
умолчанию, равный 5 сек, для ответа SMTP с кодом 5YZ соединителю
получения с выходом в Интернет. Этого вполне достаточно для того,
чтобы атака по сбору существующих адресов стала нецелесообразной для
отправителей нежелательной почты. Однако с помощью командлета
Set-ReceiveConnector вы можете использовать другие значения, как
показано в сценарии EDGE01_tarpitting.ps1.
Кроме того, вы можете пойти еще дальше и
проверить файлы моментальных снимков, которые создаются при
трассировке конвейера и отображают сообщения от пользователя
Contoso.User@Contoso.com. Проверьте метки антивирусных средств,
X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0,
которые Forefront Security использует для маркировки сообщений как
проверенных. Когда Forefront Security на транспортном
сервере-концентраторе находит эту метку с информацией о последней
версии, проверять сообщение второй раз уже не требуется. При попытке
обмануть средство Forefront Security путем вставки в сообщения
ложных меток вы получите возможность увидеть брандмауэр заголовков в
действии: он удалит эти метки сразу же после события OnDataCommand,
задолго до того, как активируется событие OnSubmittedMessage,
вызывающее агент маршрутизации Forefront Security.
Просматривая заголовки сообщений в файлах
моментальных снимков, вы, возможно, захотите создать тестовую запись
инфраструктуры политик отправителя (SPF) для Contoso.com,
идентифицирующую неверный IP-адрес как надежного отправителя. Одним
из способов выполнения этого действия является запуск файла
INTERNET01_wrong_SPF_record.bat на Интернет-узле. Затем следует
отправить пробное сообщение с адреса Contoso.User@Contoso.com и
посмотреть на заголовки X-MS-Exchange-Organization-SenderIdResult и
Received-SPF:
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)
Заключение
Как вы уже поняли из этой и предыдущей статей,
пограничные транспортные серверы Exchange Server 2007 включают
полный комплект транспортных агентов для реализации надежных и
высокоточных возможностей борьбы с нежелательной почтой, включая
фильтр подключений, анализ протокола и фильтр содержимого.
Транспортная архитектура является расширяемой и поддерживает
создание других агентов для выполнения дополнительных функций. Агент
маршрутизации Forefront Security служит отличным примером такого
дополнительного агента, интегрирующего Forefront Security для
Exchange Server в транспортную архитектуру.
В совокупности с дополнительными функциями,
такими как подключения искусственных задержек ответов, брандмауэр
заголовков, TLS- шифрование и проверка подлинности, пограничные
транспортные серверы обеспечивают все необходимые средства для
достижения высокого уровня защиты обмена сообщениями на нескольких
уровнях без единых точек отказа. Развертывание пограничных
транспортных серверов и средства Forefront Security в
демилитаризованной зоне, четко отделенной от внутренней организации
Exchange Server позволит вам защитить среду обмена сообщениями от
многочисленных атак отправителей нежелательной почты и в то же время
обеспечит доставку сообщений от надежных отправителей с очень низким
уровнем ложных срабатываний.
