Главная Exchange/UC, Новое Forefront Protection 2010 для Exchange Server (Часть 1)
  • Forefront Protection 2010 для Exchange Server (Часть 1)

    1297937239_spam_kazaxstan_obem_rassylkaКаждый раз, когда приходится браться за внедрение реального Exchange сервера встает вопрос защиты. Вопрос состоит из двух подзадач, а именно из защиты от вирусов и защиты от спама. Решений на данную тему масса, но лично меня интересуют следующие вещи:  возможность работать через привычную мне систему (и здесь все Linux решения для меня  отваливаются),  приемлемая стоимость,  эффективность и производительность. Даже используя Edge сервер (либо активируя агентов на Hub) мы  всего лишь получаем минимальный антиспам, эффективность которого весьма сомнительна, но самое главное штатно в системе нет антивируса. В свое время предыдущая версия Forefront для  Exchange 2007 оставила весьма неприятный осадок, но время идет и компания я надеюсь поработала над ошибками. Документация по Forefront Protection 2010 для Exchange Server представлена несколькими разрозненными документами, один из которых по антиспаму попал мне в руки. (White Paper: Implementing Antispam technologies in Forefront Protection 2010 for Exchange Server) По мере чтения я русифицировал его, оставляя свои комментарии.

    Forefront Protection 2010 для Exchange Server осуществляет защиту от спама на четырех уровнях:

    1. Source Analysis (Анализ источника)
    2. Protocol Analysis  (Анализ протокола)
    3. Content Analysis (Анализ содержимого)
    4. Client Analysis (Анализ клиента)

    FF-Pic1

    Forefront  осуществляет поочередную проверку электронной почты на каждом из этих уровней и именно совместная работа нескольких механизмов и дает нужный эффект. Но вы должны понимать, что  инструменты каждого уровня работают независимо друг от друга и могут использоваться по-отдельности.

    Source Analysis (Анализ источника)

    В идеале спам должен быть остановлен еще на подступах в демилитаризованной зоне до получения сообщения. При анализе источника сообщений используется три проверки:

    1. IP Allow/IP Block Lists
    2. DNSBL (DNS Block List или просто RBL)
    3. SenderID Framework

    FF-Pic2

    Важно понимать, что проверки при анализе источника осуществляются на разных этапах SMTP сессии, но тем не менее, все они основаны на оценке IP-адресов с которых устанавливаются SMTP  соединения.

    IP Allow и IP Block списки собственно не являются средством борьбы со спамом. Они необходимы для  тюнинга антиспама и позволяют явно запретить или явно разрешить прием почты с конкретных IP адресов или подсетей. Поскольку агенты IP Allow и IP Block срабатывают первыми то при “засвете”  в  этом списке сервера отправителя письмо либо гарантированно провалится в почтовый ящик назначения (IP Allow List ), либо гарантированно будет отбито сразу с  кодом и ошибкой 550 5.7.1 External client with IP address 95.220.75.230 does not have permissions to submit to this server.

    FF-Pic3

    При добавлении IP-адрес в разрешенный или запрещенный список, Forefront администратор может выбрать продолжительность нахождения адреса в списке.  Кроме того, можно импортировать список с другого FPE сервера или наоборот экспортировать ваш набор адресов  на другой FPE  сервер.

    DNS Block List штука давно известная. Какой то провайдер собирает информацию о IP адресах и подсетях с которых рассылают спам и держит базу таких адресов. Почтовая система выступает клиентом и при принятии SMTP сессии отправляет запрос хранителю базы “черных IP”.  Имя  DNS Block List появилось от того, что общение между клиентом и сервисом происходит  по средством DNS запросов, да и сами базы реализованы как DNS сервера. Настройка на стороне Forefront данной фичи очень проста и ограничена одним параметром включения. Вы не можете выбирать провайдеров, список провайдеров и баз остается на совести компании Microsoft. Если верить документации, то общение между сервером и Forefront хэшируется и имеет защиту от подмены ответа. Если сервер пытающийся доставить вам почту засветился в базах Microsoft, то ему гарантирован отлуп с кодом:

    550 5.7.1. Mail Submission  Rejected by {blocklist_provider_name}.  Mail From IP Banned.  To request removal from the list please  forward this message to delist.forefront@messaging.microsoft.com

    SenderID Framework как технология давно известна и используется многими почтовыми системами, но к сожалению не является антиспамом по сути. SenderID это защита от спуфинга усложняющая рассылку почты от имени чужого домена. Сама технология протокола SMTP никак не мешает устроить рассылку с адреса bgates@microsoft.com. А поэтому если почтовый администратор не лопух, то добавит во внешнюю DNS зону специальную запись SPF, указывающую на сервера которые имею право рассылать почту от имени его домена. Именно такие записи и проверяет  механизм SenderID.

    FF-Pic4

    FF-Pic5

    Все что в вашей власти это указать как поведет себя Forefront если проверка будет провалена. Среди доступных действий: Отклонение сообщения (Reject), Удаление сообщения (Delete), Пометка сообщение и перекидывание дальше (Stamp).

    Важно понимать, что Forefront удаляет или отклоняет сообщения, только если вскрылся обман, а это для тех кто в теме означает результат проверки ”Hard Fail”. Пример Администратор Василий настроил потовую систему на использование проверки SenderID. В его систему с IP адреса 80.80.111.254 приходят письмо от отправителя boss@rbc.ru.

    При проверке SPF записи rbc.ru появляются подробности:

    "v=spf1 ip4:80.68.240.0/20 a:relay.rbc.ru a:mail.rbc.ru a:hermes.hw.ru a:shix.rbc.ru a:york.smtp.ru -all"

    А именно админ rbc.ru  по средством SPF  говорит  о том, что указанный IP не может рассылать почту от имени его домена. Строка завершается «-all» — указанием того, что сообщения, не прошедшие верификацию с использованием механизма, следует отвергать. При результате SoftFail, это когда запись не разрешает отправку с определенного хоста, но на конце ее «~all»  (письмо, не прошедшее верификацию, не должно быть отклонено, но может быть изучено более тщательно) фильтр  Forefront не удаляет сообщение, а штампует с соответствующим заголовков и пускает дальше.

    Protocol Analysis (Анализ протокола)

    Защита на уровне анализа протокола сочетает в себе основные проверки через опции самого транспорта SMTP и технологии от Forefront Server Protection. Для эффективной защиты понадобится сочетание следующих методов.

    1. SMTP Tarpitting (через SMTP стек)
    2. Message submission rate (per IP)
    3. Sender Filtering (Фильтрация отправителя)
    4. Recipient Filtering (Фильтрация получателя)
    5. Backscatter Filtering
    6. Outbound Spam Filtering
    7. Safelists Enforcement
    8. Hybrid Model Filtering

    FF-Pic6

    SMTP Tarpitting. Для успешной доставки сообщения спамерам как минимум нужно знать адрес получателя. Для этих целей покупаются базы адресов, строятся всевозможные роботы сбора адресов, а иногда просто используется перебор по словарю. Валидация каждого получателя на присутствие его в каталоге штатная возможность, которая активирована в Forefront. Одна незадача каждый раз когда спамер попадает в “молоко” ему возвращается отрицательный ответ.

    FF-Pic7

    Так вот проблема в том, что за короткий промежуток времени спамер может постараться перебрать Oxford English Dictionary чем с одной стороны составить список  “живых” адресов, а с другой просто замедлить работу вашего транспорта. Для решения этой проблемы предлагается поставить задержку, которая будет производиться каждый раз когда спамер промахнётся, чем значительно снизит эффективность его деятельности. Самое смешное, что эта задержка будет производиться при любой некорректно введенной команде.

    Set-ReceiveConnector -Identity <ReceiveConnectorIdParameter> -TarpitInterval 00:00:10

    Переключения параметра TarpitInterval  в положение 00:00:00 полностью отключает данную возможность. В дополнение к TarpitInterval  в документации предлагается отрегулировать параметр MaxProtocolErrors. Так же на уровне коннектора приема он указывает максимально количество ошибок которое допустимо в рамках одной сессии. (по-умолчанию 5)

    Set-ReceiveConnector -Identity <ReceiveConnectorIdParameter> — MaxProtocolErrors 2

    Мне стало непонятно как в контексте Directory Harvesting Attacks это поможет. TarpitInterval  дает задержку и при некорректной команде и при некорректном адресе получателя, а MaxProtocolErrors только при некорректной команде, что в свою очередь никак не мешает спамеру перебирать получателей. Но если ситуация не прояснится, оставлю этот момент на совести создателей документации.

     

    Продолжение следует…

    MCT/MVP Илья Рудь

    • Рубрика: Exchange/UC,Новое
    • Автор: Илья Рудь
    • Дата: Воскресенье 15 Апр 2012

Комментарии

  1. Добрый день, Илья. Спасибо за статью и за Ваш труд.

    Прочитал с огромным удовольствием!

    По поводу MaxProtocolErrors — может тут имеется в виду — если атака идет с помощью каких-либо программных средств и у злоумышленника будут кривые заголовки в сообщении — я погуглил — вроде как кривые заголовки попадают в категорию ошибок протокола.

    Может у кого еще есть идеи ?

  2. Так вроде все описанное есть на любом exchange edge сервере (на HT включается руками, если надо). В чем здесь отличие базового функционала эксча от forefront protection?

  3. Денис, это только первая часть. О всем что есть в FF я напишу.

  4. Мне не удалось развернуть эту святую троицу трижды, в разных языковых редакциях по всем пошаговым мануалам, описывающим требования к sp и roll-up.

    В итоге всю эту работу теперь делает kaspersky hosted email security, а у меня не болит голова.

    Для слабовладеющих языком противника, здорово сделал, переведя этот труд 🙂 я его читал в оригинале год назад примерно.

  5. До полного перевода еще очень далеко. Дальше поинтересней будет. Это кстати мало на перевод похоже. Данная статья на 70% мой текст. Мануал стандартный как то уныло читается.

  6. А FF и спам фильтры на Edge дополняют друг друга или дублируют?

  7. FF дополняет и частично использует фильтры эджа.

  8. т.е. если я включу фильтрацию по получателям на EDGE то в FF оно включится автоматически?

  9. Konstantin K, именно.

  10. Добрый день)

    последнее время сталкиваюсь с проблемой как Форефронт вырезает опасные вложения. У нас в офисе есть 1 сотрудник которому часто высылают апдейты и некоторые файлы для обновления денежных систем) и когда ему высылают то письма попадают в карантин, или же удаляется содержимое) как ограничить правило для 1го только пользователя? остальным пусть режет и сканит)

  11. Илья спасибо огромное за статьи!!! Очень полезно, пока маюсь с Edge, но без Forefront Protection систему не представляю.

  12. Просто ищите другое решение. FFP больше не будет.

  13. Илья, а продолжение статьи будет?

  14. Нет уже такого продукта Игорь. Статью писать не по чему. Разве что некролог.

Опубликовать

Я не робот.