Forefront TMG Beta3: отчет о 3-х месячном тестировании

Дмитрий Дурасов,
MCP, консультант по ИБ, системный администратор Windows-based IT.
www.itsecurityconsult.com

В июле 2009 года в одном из новостных бюллетеней Microsoft я прочел о выходе третьей бета-версии нового продукта, призванного заменить MS ISA Server 2006 – Forefront  Treat Management Gateway – или сокращенно TMG.

Что мне сразу привлекло в этом продукте – это  встроенная в TMG возможность балансировки нагрузки и обеспечение отказоустойчивости  Интернет-соединения. Мне кажется, что эту функцию следовало реализовать давно, ибо тема периодически поднимается на форумах и обеспечение отказоустойчивости и балансировки нагрузки для Интернет-соединения является весьма востребованной,  но, к сожалению, ISA этого функционала не предоставляет.

Сразу обратили на себя внимание значительно возросшие, по сравнению с предшественником, системные требования – TMG требует минимум 2 GB RAM и работает только на 64-битной ОС Windows Server 2008. Для современного сервера это, конечно, невысокие требования, но на старом оборудовании, где вполне успешно работал ISA Server 2006, новый TMG работать уже не будет.

Для целей тестирования TMG было решено  установить на виртуальную машину, на сервер  под управлением Windows Server 2008 Hyper-V.  Предварительно были  сконфигурированы сетевые адаптеры. Схема топологии сети:

Некоторые пояснения по топологии

Эта топология 3-Leg Perimeter, «ног» у нее, конечно, больше, но сути это не меняет.

Отдельно выделена гостевая сеть, подключение к которой возможно по Wi-Fi, она создана для мобильных пользователей и гостей. Во внутреннюю сеть доступа она не имеет, ограничиваясь корпоративным порталом, OWA и доступом в Интернет.
Внутренняя сеть сегментирована на сеть Datacenter Network, где располагаются сервера, и сеть Internal Network, к которой подключены компьютеры пользователей.

В сети Perimeter Network расположены Web сервера, которые публикуются в Интернет.

Внешние сети дополнительно защищены с помощью простых Packet-filtering межсетевых экранов, они обычно встроены в большинство точек доступа и DSL модемов. Это дополнительно ограждает сеть от различного сетевого мусора, и так же прячет сам TMG за NAT.

Не вижу смысла приводить снимки экрана при установке, следует заметить лишь то, что она прошла без проблем и не сильно отличалась от процедуры установки той же ISA.

Мои основные клиенты относятся к сегменту small and medium business, поэтому тестирование проводилось относительно применения TMG именно в этом сегменте, для этого был выбран TMG Standard Edition, который обычно в небольших компаниях устанавливается в одном экземпляре. 

Тестовая конфигурация виртуальной машины:

Windows Server 2008 Ent. 64-bit SP2, TMG Standard Edition, 2 GB RAM. Данный сервер в домен вводить не планировалось, TMG был установлен в workgroup mode.

Есть различные доводы за и против расположения TMG в составе домена или как standalone сервера, в данном случае сервер в домен не входит и весь функционал, который TMG может получить, работая в домене, использован не был. Если следовать принципу “Least privileges”, то наличие TMG в домене увеличивает площадь атаки. Но в любом случае, оптимальная защита – это баланс между функциональностью и безопасностью, и как поступать решать Вам. Единственная проблема, с которой я столкнулся – это корректная публикация OWA. ISA может корректно публиковать OWA в workgroup mode, этот процесс детально описывается в литературе (в частности, я, в качестве настольной книге использую “Microsoft ISA Server 2006 Unleashed” Michael Noel).  Пытаясь делать по аналогии, с TMG желаемого результата я не добился. Собственно, долгие танцы с бубном не планировались, поэтому данную задачу я решил в тестовой среде с помощью обычной публикации сервера через HTTPS. Я уверен, что будь TMG в домене,OWA был бы опубликован корректно.  Я не исключаю, что, возможно, что-то делалось неправильно, но отсутствие документации и более-менее вменяемых рекомендаций в Интернете делают некоторые, вроде бы простые вещи, трудноосуществимыми. В Интернете вообще мало информации по TMG и на TechNet можно часто встретить  описания, подобные этому:

А обзоры TMG в Интернете – это обычно набор снимков экрана при установке плюс несколько снимков консоли управления. Они не блещут информативностью, а прочитать то, что написано под кнопкой я могу и сам. Ожидать большего, конечно, на данном этапе странно, ибо функционал меняется от одной бета-версии  к другой, но, тем не менее, есть довольно интересные блоги, где люди всерьез тестируют TMG. Например, вот: http://www.carbonwind.net/blog/

Итак, какие основные задачи ставились при тестировании.

1. Проверить, как работает ISP Redundancy.
2. Посмотреть, что нового.

Начну по порядку.

ISP Redundancy.  TMG умеет обеспечивать отказоустойчивое соединение с Интернетом, используя резервные каналы связи. При этом он поддерживает два режима использования:

1. Балансировка нагрузки между каналами.
2. Обход основного соединения в случае аварии и переход на резервный канал.

Плюсы и минусы вариантов. Первый вариант, когда трафик балансируется между двумя каналами имеет смысл применять при наличии нескольких каналов с определенной полосой пропускания. Если каналы имеют разную полосу пропускания, то можно задать нагрузку для каждого из них. Это позволяет сделать из двух узких один широкий канал, при этом авария у одного из провайдеров не повлечет за собой глобальной приостановки доступа в Интернет, но, скорее всего, сделает работу пользователей некомфортной.

Второй вариант хорош тем, что можно подключить один широкий канал с гарантированной купленной полосой пропускания (например, оптоволокно), а в качестве резервного использовать канал с оплатой по трафику (например, используя технологию DSL). Это позволит гарантированно обеспечить доступ в Интернет на требуемой скорости, при этом не надо платить за гарантированную полосу пропускания два раза.

При планировании отказоустойчивости учтите, что она функционирует только для организации доступа через NAT.

Я тестировал как первый, так и второй вариант. Следует заметить, что балансировка нагрузки, как мне показалось, работает по довольно странному алгоритму. Например, в тестовой среде были использованы два соединения от разных провайдеров, одно – 1024 Kbit, второе 128 Kbit. Утилизация каналов была распределена как 80% трафика идет через мегабитный канал, 20% - через 128 килобитный канал. Так вот. Пользователи в основном используют мегабитный канал.  Но, после определенного времени использования, иногда мегабитный канал начинает практически простаивать и весь трафик идет через узкий, 128 килобитный канал, что вызывает, естественно, торможение.

Примечание: собственно говоря, подтверждение моим словам я нашел на блоге разработчиков TMG, когда готовил эту статью к публикации.

“Because of the specifics of the load balancing algorithm explained above, it is possible that a bandwidth-consuming session will be assigned to the “slower” ISP connection and will lead to an incorrect load balancing ratio.” – записьот 5 октября 2009 годаJ
Рекомендую подписаться на их RSS ленту: http://blogs.technet.com/isablog/rss.xml

Непосредственно отказоустойчивость соединения с Интернетом. Отказоустойчивость работает нормально. Правда, TMG немного задумчив, и на определение того, что канал умер уходит где-то 1-2 минуты. То есть полностью seamless эту процедуру не назовешь.

Можно сказать, что функция отказоустойчивости есть, она работает, и стоит надеяться, что ее работа будет отшлифована и представлена во всей красе в финальном релизе.

Следующая интересная новая функция – это Malware Inspection.

TMG самостоятельно обновляет сигнатуры с сайта Microsoft и сканирует весь входящий контент на наличие вирусов и spyware. При серфинге это происходит незаметно для пользователя, однако, если необходимо скачать файл, то он будет сначала получен и проверен TMG, а уж потом только его дадут скачать пользователю. Со стороны пользователя это выглядит вот так:

Соответственно, если вирус будет найден, то пользователь увидит предупреждение.

Следует учесть, что вирус все же скачать можно. По умолчанию TMG не сканирует HTTPS трафик, и вирус может быть скачан, если доступ осуществляется по протоколу HTTPS.

Вот тому пример – через HTTPS соединение вирус успешно скачался и был сразу же обнаружен Windows Defender'ом.

Но, это не проблема – все предусмотрено. Включаем инспекцию HTTPS и генерируем сертификат для TMG.

Т.к. сеанс теперь контролирует TMG, то пользователь сразу увидит предупреждение

При включенном режиме HTTPS инспекции TMG успешно сканирует зашифрованный трафик.

Естественно, пользователям нужно установить сертификаты CA TMG на компьютер, чтобы не видеть сообщений об ошибке сертификата в дальнейшем.

Но, тогда возникает вопрос – а как же пользователь будет знать, что  сертификат сайта действителен? Не будет ли это компрометировать одно из предназначений сертификата – идентифицировать владельца ресурса? Нет.

TMG будет проверять и блокировать сайты с неправильными сертификатами. Если же пользователю все равно будет нужен доступ к этому сайту, его можно добавить в список исключении. Следует заметить, что при блокировке пользователь получает совсем неинформативное окно следующего содержания:

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

Я заметил некорректную работу режима HTTPS фильтрации с некоторыми HTTPS сайтами, в частности с Live.com и еще с некоторыми сайтами.  Если такое происходит, то администратор может добавить требуемые сайты в раздел сайтов, исключенных из инспекции HTTPS. Опять же, не стоит забывать что это бета-версия и TMG будет дорабатываться и исправляться.

Далее. Новая опция – фильтрация URL.  Сейчас Microsoft создает и будет поддерживать в актуальном состоянии базу URL адресов сайтов по различным категориям. Всего предлагается порядка 70 различных категорий, доступ к которым может быть разрешен или запрещен. Например, можно ограничить доступ к поисковым машинам и Web-email, или наоборот, разрешить доступ к категории Dating/Personals, к которой относится сайт odnoklassniki.ru, скажем, в обеденное время и после окончания рабочего дня. Все в ваших руках. Следует заметить, что многие сайты не категоризированы и  если вы планируете внедрить жесткую политику категорий, то необходимо будет запретить доступ ко всему, кроме разрешенных категорий.

На бета-стадии продукта Microsoft предупреждает, что категории еще далеки от совершенства, но впоследствии они будут улучшаться и добавляться. Например, ресурс porno.com не относится ни к одной из категорий J и успешно показывается, несмотря на запрет демонстрации сайтов такого характера. Забавно. По умолчанию TMG блокирует доступ к ресурсам порнографического, рекламного и прочего сомнительного характера.

Естественно, все это гибко настраивается. В случае, если пользователь пытается зайти на запрещенный ресурс, по умолчанию он получает следующее:

Для анализа, куда доступ пользователям следует разрешать,  а куда нет, можно уточнить, к какой категории относится тот или иной сайт. В частности, как мы видим, securitylab.ru отнесен к категории сайтов «Technical Information».

Новая функция TMG – E-mail Protection.
Как следует из названия, она призвана защищать электронную почту. Но не все так гладко. E-mail Protection будет работать только при двух условиях:

1. Установленный Microsoft Forefront Security for Exchange.
2. Установленный Exchange Edge Transport Role.

Это не сильно радует. Я считаю, что интеллектуальный межсетевой экран должен быть межсетевым экраном, и установка дополнительного ПО потенциально делает его более уязвимым. Возможно, в рамках большой организации, специально выделенные TMG сервера, которые будет защищать только SMTP, вполне неплохое решение, но если TMG сервер единственный (или array из двух серверов для обеспечения отказоустойчивости) – это вряд ли хорошее решение. Мне непонятно, зачем устанавливать дополнительное ПО, если в TMG уже реализовано сканирование трафика на вирусы и инспекция SMTP соединений для предотвращения низкоуровневых атак на уровне протокола. Что мешает так же сканировать SMTP трафик на вирусы и блокировать спам непосредственно силами TMG, включив этот функционал в межсетевой экран? Я думаю, что это больше маркетинговый ход – фактически не добавляя функционала, добавить лишь управляющую оснастку и разрекламировать как новая возможность защиты электронной почты.

В общем, E-mail protection я не тестировал. Дополнительно устанавливать несколько серверов Exchange и старую Beta2 Forefront Security for Exchange у меня желания не было. Тем более, что уже вышла версия FSE RC, которую TMG Beta3 не поддерживает.
Интереса ради я включил опцию E-mail protection, на что TMG сразу же отреагировал:

Более подробно механизм работы E-mail Protection описан здесь: http://technet.microsoft.com/en-us/library/ee338733.aspx

Защита от вторжений.  Не может не радовать появление полноценного функционала IDS/IPS. Конечно, возможность защиты от вторжений на низком уровне присутствует в ISA Server 2006, но в TMG мы видим гораздо более серьезную реализацию и фундаментальный подход.

Network Inspection System. Защищает сеть, проверяя трафик на содержание определенных сигнатур.

Следует заметить, что сигнатуры Network Inspection System появляются гораздо быстрее, чем последующие за ними обновления линейки подверженных новым  выявленным уязвимостям, продуктов. В частности,  сигнатура нашумевшей уязвимости в реализации протокола SMB 2, которой подвержены Windows Server 2008 / Vista, была выпущена через несколько часов  в день обнаружения.

Хочется верить, что базы будут обновляться с такой же оперативностью и дальше.

Так же мы видим новую вкладку Behavioral Intrusion Detection. Там находится управление функциями,  аналогичными в ISA 2006 Server – низкоуровневая инспекция трафика.

Самое интересное – Behavioral IPS  - к сожалению не работает. Документация напрочь отсутствует.

Насколько я понимаю, реализация Behavioral Intrusion Prevention System осуществляется в интеграции с новым продуктом Forefront codename Stirling. Я не тестировал и не устанавливал Stirling, но, вообще меня это заинтриговало.

Естественно, мне было интересно, как себя ведет TMG при сканировании на уязвимости, а так же как утилизируется канал при проведении сканирования. Я не менял настройки по умолчанию, которые заданы в TMG Flood Mitigation Settings. С помощью более тонкой настройки можно существенно снизить утилизацию канала при сканировании, но тут главное, чтобы эти настройки не затронули нормальную работу пользователей. В оснастке Flood Mitigation появилась новая закладка SIP Quotas, которая, как следует из названия, призвана решить проблемы, могущие возникнуть при транзите голосового трафика через TMG.

Для сканирования я воспользовался внешним Интернет-сервисом от Qualys. Если Вам интересно, Вы тоже можете протестировать свой IP адрес. Тестирование занимает около 15 минут. Один адрес тестируется бесплатно. Провести тестирование своего IP можно по ссылке: http://www.qualys.com/forms/trials/qualysguard_free_scan/

Я не уделял много времени тонкой настройке TMG. В основном, все было сконфигурировано, как говориться, по умолчанию. Как видно из схемы топологии сети, TMG находится за низкоуровневыми packet-filtering межсетевыми экранами. Это рекомендуемое решение, позволяет отрубать большую часть мусорного трафика и скрывает непосредственно TMG за NAT. С PF Firewalls на TMG проброшены следующие порты: 25 (SMTP), 80 (HTTP), 443 (HTTPS), 3389 (RDP). Все остальные порты закрыты. Собственно, проводя это тестирование, я не рассчитывал, что будут обнаружены какие-либо уязвимости, но мне было интересно, как себя будет вести TMG, как будет срабатывать механизм NIS и скажется ли это на производительности сервера.

Как я и ожидал, тестирование уязвимостей не выявило. Вы можете видеть, что в отчете отражено то, что SSL сертификат является самодельным (это действительно так), а так же потенциальную уязвимость протокола SSL 2 и рекомендацию применять протокол SSL третьей версии. Это все.

 NIS отработала как положено, выдав кучу алертов.

Утилизация процессора во время сканирования практически незаметна.

Чего не скажешь о трафике. Во время проведения сканирования посылается великое множество HTTP запросов, которые обрабатываются TMG и на маленький запрос от сканера TMG отправляет сгенерированную страница следующего вида:

Это утилизирует канал. Я не нашел, где можно заменить эту страницу на что-то более легкое. Конечно же, для эффективного взаимодействия следует более жестко ограничить количество сессий с одного внешнего IP адреса и допустимое количество обрабатываемых HTTP запросов (по умолчанию стоит 600 IP и 600 HTTP запросов в минуту с одного IP адреса).

График утилизации канала приведен ниже. Красная линия – входящий трафик, зеленая – исходящий. Масштаб по оси Y – 400 Kbit/s в верхней точке снимка экрана.  Фрагмент графика показывает сканирование HTTP. При сканировании SMTP утилизация канала практически отсутствует. График снимался непосредственно с порта, к которому подсоединен TMG.

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

Остальные новшества. Я рассмотрел основные особенности и нововведения, которые представляют наибольший интерес и которые тестировались мною лично. Я не ставил перед собой целью найти в консоли 10 отличий между ISA 2006 и TMG. Они есть, их интересно потыкать мышкой и поэкспериментировать. Если Вы работали с ISA, то переход к TMG не вызовет никаких трудностей.

Резюме 

E-mail Protection. Фактически, эта опция является лишь оснасткой, интегрированной в консоль управления TMG сервера. Да, это удобно, облегчает конфигурирование и мониторинг, сводя все в одно место, но непосредственно функции защиты почты реализуются с помощью установки дополнительного ПО.

Фильтрация URL. Бесспорно, полезная функция, пока еще работающая весьма условно из-за далеко не полной базы URL. Разработчики настоятельно просят, если вы используете TMG Beta3, установить пакет телеметрии, который будет помогать им формировать эту базу. Скачать пакет можно по ссылке:
http://www.microsoft.com/downloads/details.aspx?FamilyID=f7e5907d-60ae-4f39-8660-9a959db5a6e6
Forefront TMG RC уже будет содержать его сразу.

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

Network Inspection System и Malware Inspection. Так же не может не радовать. Существенно уменьшает поверхность атак, успешная  реализация этих функций напрямую зависит от скорости обновления сигнатур. Учитывая то, что Microsoft всерьез нацелился на рынок антивирусного ПО, можно наедятся, что они будут обновляться оперативно. 

Как видно, Forefront Threat Management Gateway значительно отличается от MS ISA 2006, это уже не отдельный продукт, а тесно интегрированное в среду Forefront решение, призванное обеспечить Edge Security Предприятия. Полностью свои возможности он раскрывает только во взаимодействии с остальными продуктами линейки Forefront .

Я рассматривал TMG Beta3, но 1 октября уже был анонсирован выход  TMG Release Candidate, который скоро должен стать доступен для скачивания и тестирования. После выхода RC, следует обновить TMG, т.к. RC содержит обновленный движок NIS и сигнатуры NIS для Beta3 обновляться не будут.

Вообще, не смотря на Beta версию, продукт работает достаточно стабильно. За период 3-х месячного 24х7 тестирования, сервис межсетевого экрана у меня зависал 1 раз. Это, конечно, не есть хороший показатель, но все же надо учитывать то, что это Beta.  Да, пока еще выскакивают иногда ошибки и некоторые настройки работают не так, как надо. Но в целом мне нравятся те возможности, которые предоставляет Forefront TMG, и я думаю, что его выход серьезно потеснит производителей других аппаратных и программных межсетевых экранов.