Превосходное оружие против фишинга и атак с подменой имен

В пакете обновлений Exchange Server 2003 Service Pack 2 (SP2) появилось два новых средства для борьбы со спамом: Sender ID и Intelligent Message Filter (IMF). Оба компонента реализованы в рамках программы Coordinated Spam Reduction Initiative, о которой Microsoft объявила более года назад.

Sender ID — еще один вид оружия для борьбы со спамом в арсенале Exchange Server 2003. Само по себе использование Sender ID не прекратит поток спама, но, безусловно, усложнит жизнь авторам непрошеных посланий. Экономика спама способствует успеху злоумышленников (малые затраты, высокая доходность, анонимность), поэтому полезны любые приемы, с помощью которых можно сделать их задачу более трудной. Посмотрим, каким образом использование Sender ID в компании способствует достижению этой цели. Но прежде необходимо понять роль Sender ID в общей защите Exchange 2003 SP2 от спама и принципы работы Sender ID.

Общая структура защиты

Exchange 2003 располагает инфраструктурой, многие компоненты которой предназначены для снижения объема спама. В SP2 инфраструктура расширена для борьбы и с другими злоупотреблениями электронной почтой, такими как спуфинг и фишинг. В сущности, инфраструктура представляет собой набор фильтров, которые можно настроить на разные части сообщений (например, IP-адреса отправителей, получателей, контент), поступающих в почтовую организацию Exchange. Например, фильтры соединений можно использовать для сравнения IP-адреса подключающегося клиента со списками блокировки в реальном времени, а фильтры отправителей — для защиты против спуфинга (подмены имен). Фильтры получателей препятствуют сбору действующих адресов электронной почты; с их помощью можно запретить пользователям получать почтовые сообщения извне. Фильтры контента позволяют оценить вероятность того, что данное почтовое сообщение может оказаться опасным.

Обычно фильтры активизируются на виртуальном сервере SMTP, настроенном для обработки входящей почты сразу после ее поступления в Exchange. Большинство фильтров применяется только к анонимным SMTP-соединениям, так как предполагается, что сообщения от аутентифицированных пользователей не опасны. SMTP-соединения между серверами Exchange внутри организации всегда аутентифицированы, поэтому фильтрация не проводится, когда почтовые сообщения пересылаются через организацию в пункт назначения. Более подробные сведения об общей инфраструктуре можно найти в Web-журнале по адресу http://blogs.technet.com/exchange/archive/2005/07/18/407838.aspx.

Sender ID — новый фильтр в инфраструктуре. Sender ID обеспечивает фундамент для надежного использования доменных имен в аккредитованных, конфиденциальных системах и безопасных списках. Он защищает имена доменов, проверяя, действительно ли почтовое сообщение, в качестве исходного пункта которого указан определенный домен, было послано сервером, зарегистрированным в этом домене. Такой подход очень эффективен для предотвращения атак с подменой имен и фишинга.

Как действует Sender ID

Вступая в SMTP-обмен для получения почтового сообщения, виртуальный SMTP-сервер Exchange с активным фильтром Sender ID извлекает заявленное доменное имя и IP-адрес отправителя. Виртуальный SMTP-сервер Exchange сравнивает этот IP-адрес со списком авторизованных узлов, опубликованных администратором домена. В результате подтверждается истинность адреса и предотвращаются попытки подлога. По итогам проверки можно предпринять соответствующие действия.

Для проверки фильтру Sender ID необходимы три элемента данных: домен электронной почты, IP-адрес и список авторизованных узлов для домена электронной почты. Собрав необходимую информацию, Sender ID выполняет заранее заданное действие.

Определение домена электронной почты. На экране 1 показаны необработанные данные SMTP-диалога, который содержит оболочку и контент SMTP-сообщения, полученного виртуальным сервером Exchange. Оболочка (все элементы, предшествующие команде DATA) содержит информацию, необходимую для пересылки и доставки сообщения. Контент (все элементы после команды DATA) указывает объект, который должен быть доставлен получателю. Контент состоит из полей заголовка, за которыми следует тело сообщения.

Экран 1. Пример SMTP-диалога

На экране 1 можно увидеть много имен доменов — один в поле оболочки и несколько — в полях заголовка контента. Нужное имя домена определяется фильтром Sender ID из PRA (Purported Responsible Address — предположительный ответственный адрес). Алгоритм PRA идентифицирует лицо, которое, по всей видимости, отправило сообщение. Эти сведения не обязательно точно соответствуют части MAIL FROM входящего сообщения. Из-за применения таких инструментов, как трансляторы почтовых сообщений и списки рассылки, сервер-отправитель в любом SMTP-диалоге не обязательно ассоциирован с тем же доменом, что и исходный сервер-отправитель.

Например, предположим, что kevin.laahs@hp.com посылает сообщение для donald.livengood@compaq.com, а адрес ретрансляции последнего установлен на kieran.mccorry@digital.com. В этой ситуации для доставки сообщения должны быть организованы два SMTP-диалога. В каждом фрагмент MAIL FROM содержит адрес kevin.laahs@hp.com. Однако на получающем сервере в digital.com не имеет смысла проверять, был ли IP-адрес подключающегося сервера авторизован для передачи почтовых сообщений из hp.com, так как этот сервер принадлежит compaq.com.

Таким образом, при определении PRA нельзя полагаться исключительно на элемент сообщения MAIL FROM. Принимающий SMTP-сервер должен принять все сообщение, прежде чем удастся выполнить проверку Sender ID, потому что посредники в процессе доставки отмечают свое участие в заголовках контента. В данном примере должен быть заголовок Resent-From, в котором в качестве посредника указан donald.livengood@compaq.com. Однако вполне возможно, что PRA не удастся получить из контента сообщения, так как нет гарантии, что необходимые заголовки контента присутствуют или имеют подходящий формат, из которого можно извлечь имя домена. Некоторые SMTP-шлюзы и фильтры даже отбрасывают часть исходных SMTP-заголовков, чтобы скрыть имена серверов-источников.

Лучше определить PRA на уровне протокола (до команды DATA), чтобы не принимать контент, который будет немедленно отвергнут. В настоящее время этого сделать нельзя, но в дальнейшем такая возможность должна появиться.

Получение IP-адреса. При корректном PRA проверка продолжается, и Sender ID пытается получить IP-адрес. На первый взгляд может показаться, что фильтру Sender ID нужно просто проверить IP-адрес подключающегося сервера. Но в действительности и эта задача оказывается сложнее. Многие организации не подключают серверы Exchange напрямую к Internet. Почтовые сообщения из Internet принимают другие серверы в демилитаризованной зоне (DMZ), а затем передают их в шлюзовые серверы Exchange, расположенные внутри периметра. Поэтому подключающийся сервер — доверенный, и Sender ID должен проверять не его, а IP-адрес сервера, первоначально установившего соединение с доверенным сервером в DMZ. Чтобы отыскать этот сервер, Sender ID анализирует заголовки контента.

Получение списка санкционированных узлов. На данном этапе Sender ID располагает именем домена, объявленного в качестве источника данного сообщения, и IP-адресом системы, которая предположительно находится в этом домене. Sender ID должен проверить, имеет ли данная система право пересылать почтовые сообщения для конкретного домена. Для этого Sender ID использует записи Sender Policy Framework (SPF) и DNS.

Организации публикуют IP-адреса своих истинных почтовых серверов с использованием записей SPF и DNS. Записи SPF могут содержать просто список IP-адресов или конкретные детали, например, об отсутствии в организации выходных почтовых серверов. На домашней странице Sender ID (http://www.microsoft.com/senderid) имеется мастер, который поможет сгенерировать запись SPF для домена и проверить наличие SPF-записей для других доменов. Благодаря регистрации SPF-записей другие организации могут обнаружить случаи подмены имени домена, и репутация компании будет спасена.

С помощью команды Nslookup не составляет труда выяснить, опубликованы ли SPF-записи конкретной организации. Например, команда

nslookup -q=TXT gmail.com

выдает список SPF-записей для gmail.com.

Адекватные действия. После того как Sender ID получит имя домена, IP-адрес и список санкционированных узлов, фильтр выполняет преобразование DNS, анализирует результаты и предпринимает соответствующие запланированные действия. Очень важно подчеркнуть, что запланированное действие будет выполнено, только если Sender ID успешно выполнил общую проверку и может достоверно определить, что IP-адрес действителен или недействителен. В противном случае сообщение будет принято как обычное, но дополнено информацией о причинах, по которым не удалось удовлетворительно выполнить проверку. Общая проверка может считаться неудачной по многим причинам, от неполадок DNS до неверно настроенных или отсутствующих SPF-записей. Web-журнал, в котором описаны возможные результаты проверки и методы представления результатов в Outlook для следственного анализа, можно найти по адресу http://blogs.technet.com/exchange/archive/2005/10/13/412487.aspx.

Если сообщение не проходит проверку Sender ID (не удается определить домен, IP-адрес либо IP-адрес недействителен), то Sender ID предпринимает соответствующее действие. Выбор действия зависит от заданного администратором режима Sender ID — отвергнуть, удалить или принять сообщение. Отвергнутое сообщение не принимается, и клиенту посылается отчет о невозможности доставки (NDR). В режиме удаления сообщение принимается, но затем уничтожается, и отправитель не получает отчета NDR. В режиме приема результаты проверки Sender ID вносятся в сообщение, а затем сообщение поступает в следующий фильтр инфраструктуры. Таким образом, в последующих фильтрах можно предпринять действия, основанные на результатах проверки.

Например, на уровень вероятности спама (Spam Confidence Level, SCL) сообщения влияют результаты проверки Sender ID, если фильтрация активизирована через IMF. Уровням SCL сообщений, не прошедших проверку, присваиваются более высокие значения, так как эти сообщения гораздо чаще оказываются ложными. От SCL зависит, останутся ли сообщения во входном ящике пользователя, будут автоматически переведены в папку Junk Mail или удалены. Как и результаты проверки Sender ID, уровни SCL могут быть показаны в Outlook. Дополнительные сведения о показе уровней SCL приведены в Web-журнале по адресу http://blogs.technet.com/exchange/archive/2004/05/26/142607.aspx.

Настройка фильтра Sender ID

Как и у всех фильтров в инфраструктуре, действие фильтра Sender ID сначала настраивается на глобальном уровне, а затем фильтры применяются к соответствующим виртуальным SMTP-серверам. Все фильтры настраиваются с использованием свойств объекта Global Settings/Message Delivery в Exchange System Manager (ESM).

Чтобы настроить фильтр на глобальном уровне, следует открыть ESM, щелкнуть правой кнопкой мыши на Message Delivery в разделе Global Settings, а затем выбрать пункт Properties. Появится диалоговое окно Message Delivery Properties, в котором нужно настроить параметры на вкладках Sender ID Filtering и General. На вкладке Sender ID Filtering следует просто указать желательный режим (отвергнуть, удалить или принять) для сообщений, не прошедших проверку. На вкладке General (экран 2) необходимо настроить список Perimeter IP List и параметры Internal IP Range Configuration. Эти параметры влияют на метод определения подключающегося IP-адреса. По щелчку на кнопке Add на экране появляется диалоговое окно, в котором необходимо указать все IP-адреса доверенных серверов в организации. Эти серверы будут подключаться к любым серверам Exchange с активным фильтром Sender ID. Обязательно указывается IP-адрес SMTP-узла ретрансляции любого типа, имеющегося в организации, в частности систем проверки контента на базе SMTP. Любые IP-адреса, перечисленные в этом окне, отбрасываются, когда фильтры пытаются определить первоначальный подключающийся IP-адрес с помощью заголовков контента сообщения.

Экран 2. Настройка фильтра Sender ID на глобальном уровне

После настройки глобальных параметров можно определить конфигурацию фильтра Sender ID на соответствующем виртуальном SMTP-сервере внутри организации. Этот параметр тщательно спрятан. Для доступа к нему следует щелкнуть правой кнопкой мыши на нужном виртуальном SMTP-сервере в ESM, выбрать пункт Properties, щелкнуть на кнопке Advanced, а затем на кнопке Edit. Появляется диалоговое окно Identification, в котором необходимо установить флажок Apply Sender ID Filter (экран 3). Дополнительные сведения о настройке глобальных и серверных параметров Sender ID приведены в статье Microsoft «New Weapons In The Fight Against Spam» по адресу http://www.microsoft.com/technet/technetmag/issues/ 2006/01/newweapons/default.aspx.

Экран 3. Настройка фильтра Sender на уровне сервера

Для мониторинга работы Sender ID можно использовать объект производительности с именем MSExchange Sender ID. С помощью этого объекта легко выяснить число выполненных преобразований DNS, число сообщений, обработанных фильтром Sender ID, и результаты различных проверок Sender ID. Следует отметить, что этот объект производительности может появиться лишь после того, как будет настроен фильтр и отправлено первое сообщение.

Усложним жизнь спамеру

Инициатива Coordinated Spam Reduction Initiative компании Microsoft начала приносить плоды. В настоящее время для борьбы со спамом можно использовать фильтры Sender ID и IMF. Sender ID не предотвращает спама, но, несомненно, полезен для обнаружения фишинга и попыток подмены имен. Кроме того, благодаря этому фильтру ремесло спамера становится более трудным. Призываю всех администраторов регистрировать свои SPF-записи!

Кевин Лаахс - Главный консультант группы HP Services Advanced Technology Group. Соавтор книги Microsoft SharePoint Technologies: Planning, Design, and Implementation (издательство Digital Press). kevin.laahs@hp.com