В первых двух частях этой серии статей мы рассмотрели некоторые функцию борьбы против вредоносного ПО, функции веб прокси и кэширования, включенные в Beta 1 версию Forefront TMG. В этой заключительной части мы рассмотрим абсолютно новую функцию, включенную в TMG ‘ мастера создания политики веб доступа.
Итак, давайте перейдем собственно к теме, которой является мастер создания политики веб доступа. Мастер создания политики веб доступа является новым мастером, который не был включен в предыдущие версии брандмауэров ISA. Вы можете использовать этого мастера для создания всех правил исходящего доступа HTTP и HTTPS. Затем мастер создаст группу политики веб доступа, которая автоматически размещается в политику брандмауэра. Хотя мне нравится идея создания группы, мы увидим, что есть определенные ограничения такого способа создания правил доступа. Надеюсь, что проблема, с которой мы столкнемся в конце этой статьи, будет исправлена, когда TMG выйдет в RTM версии.
Нажмите по ссылке Настроить политику веб доступа во вкладке Задачи на панели задач. У вас откроется приветственная страница мастера Welcome to the Web Access Policy Wizard. Нажмите Далее.
Рисунок 1
На странице Веб защита у вас есть две опции:
Обратите внимание, что раньше мы видели возможность включения этой опции путем перехода по ссылке Настройка осмотра на вредоносное ПО во вкладке Задачи ветви Политика веб доступа. Однако мастер пытается немного все упростить, предоставляя вам эти опции здесь.
Обратите внимание, что страница гласит, что осмотр на вредоносное ПО работает без лицензии на протяжении 90 дней. Я не уверен, применимо ли это только в Beta 1 версии. Я также не знаю, будет ли работать эта функция без лицензии. Нажмите Далее.
Рисунок 2
На странице Тип политики веб доступа у вас есть две опции:
В этом примере мы выберем опцию Создать выборочные политики веб доступа для пользователей, групп и компьютеров, чтобы посмотреть, какие варианты здесь возможны. Нажмите Далее.
Рисунок 3
На странице Группы политики доступа у вас есть три варианта:
В этом примере мы выберем опцию Все из вышеперечисленных, поскольку она кажется самой сложной опцией, дающей наибольшее количество вариантов выбора.
Рисунок 4
На странице Политика веб доступа по умолчанию вы решаете, что будет делать брандмауэр TMG, если запрос на подключение не соответствует ни одному из правил в группе правил веб доступа. В большинстве случаев нужно выбирать опцию Отвергать веб запрос, поскольку это будет «правило чистки» ваших HTTP запросов подключений. Однако при тестировании вы, возможно, выберете менее строгий подход, поскольку не уверены в том, что TMG вообще работает во время вашего первого тестирования. Всегда есть время для использования более строгих правил позже.
В этом примере мы выберем опцию Разрешить веб запрос и нажмем Далее.
Рисунок 5
На странице Политики анонимного веб доступа вы определяете политики, которые будут применяться к анонимным соединениям на брандмауэре TMG. Для создания политики нажимаете кнопку Добавить. Это вызывает диалоговое окно Добавить политику доступа.
В диалоговом окне Добавить политику доступа вы сначала добавляете источник запроса в рамке Группы доступа. Мне сначала это показалось немного запутанным, поскольку не совсем ясно, что то, что вы вводите в этом разделе является тем же, что вы вводите в поле Источник во время создания обычного правила доступа. Вы используете кнопку Добавить, чтобы добавлять один или несколько нижеследующих элементов:
Причина, по которой доступны только эти опции, заключается в том, что каждый из этих элементов включает только IP адрес. Они не включают пользователей или группы, для которых требуется аутентифицированное подключение.
После того, как вы решили, какой источник используется для политики, вы решаете то, какой будет адрес назначения. Здесь все более понятно на интуитивном уровне, и больше соответствует стандартной настройке правила доступа, поскольку для адреса назначения не используется название ‘группа серверов’ или нечто подобное. К тому же, вам нужно определить, нужно ли разрешить или запретить подключение при использовании этих источников и адресов назначения.
В этом примере я создал политику доступа, которая запрещает доступ со всех хостов на стандартной внутренней сети к адресу назначения, коим является набор URL, который я назвал Запрещенные веб сайты. Я также создал правило, разрешающее доступ всем IP адресам на стандартной внутренней сети ко всем сайтам сети. Затем переместил запрещающее правило выше разрешающего правила, используя стрелки на странице Политики анонимного веб доступа.
После создания ваших политик анонимного доступа нажмите Далее.
Рисунок 6
На странице Политики аутентифицированного веб доступа вы создаете политики доступа, которые применяются к пользователям, имеющим возможность аутентифицироваться. В этом случае это будут пользователи, настроенные в качестве веб прокси или клиентов брандмауэра. Когда вы нажимаете кнопку Добавить на странице Политики аутентифицированного веб доступа у вас открывается диалоговое окно Добавить политику доступа.
Когда вы нажимаете кнопку Добавить, чтобы добавить Группы доступа на этой странице, у вас открывается список групп пользователей. В этом примере источник более продуман, нежели группа. Обратите внимание, что это будет работать только в том случае, если брандмауэр TMG является частью домена Active Directory. Если вы выберете использование RADIUS, вам позже придется настроить брандмауэр TMG на использование RADIUS сервера, а затем настраивать правила на использование сервера RADIUS вручную.
В примере ниже видно, что я создал политику доступа, которая применяется к группе Администраторы, и она позволяет этой группе подключаться к набору URL Запрещенные веб сайты. Целью этой политики является разрешение пользователям, принадлежащим к группе администраторов, доступа к группе запрещенных веб сайтов, что является исключением анонимного правила, которое я создал ранее. Конечно, чтобы это работало, мне нужно будет разместить это правило над запрещающим анонимным правилом, но мы можем сделать это позже.
(Даже когда пользователи могут аутентифицироваться, правило анонимного доступа будет применяться ко «всем пользователям», независимо от того, могут ли они аутентифицироваться или нет ‘ вот почему нам нужно переместить правило аутентифицированного доступа выше над правилом анонимного доступа в этом примере).
Нажмите Далее.
Рисунок 7
На странице Параметры осмотра на вредоносное ПО у вас есть следующие опции:
Мы выберем опцию осмотра и частичную доставку файлов. Однако не уверен, как это отразится на нашей конфигурации, которая разрешает просмотр строки прогресса. Нажмите Далее.
Рисунок 8
На странице Конфигурация веб кэша у вас есть возможность настроить брандмауэр TMG на выполнение веб кэширования. Эта функция не включена по умолчанию, поэтому если хотите включить веб кэширование, вам потребуется настроить накопитель веб КЭШа. На самом деле, даже если вы не создадите накопитель веб кэширования сейчас, вы сможете сделать это, перейдя по ссылке Настройка веб кэширования во вкладке Задачи панели задач.
Чтобы включить кэширование, поставьте флажок напротив строки Включить веб кэширование. Затем нажмите кнопку Диски КЭШа. Кэш хранится в едином файле на диске или дисках, которые вы выбрали. Максимальный размер КЭШа на том составляет 64 GB. Считается лучшей практикой располагать файл КЭШа не на системном диске, и не на том диске, на котором расположены программные файлы TMG. Приблизительные оценки варьируются для оптимального размера кэша, но я считаю, что размер 5-10MB на пользователя будет вполне достаточным. Однако если у вас есть небольшое количество пользователей (менее 100), вы можете увеличить это значение. Вам лишь нужно убедиться в том, что размер КЭШа не слишком большой. Существует вероятность того, что время, необходимое для поиска слишком большого файла КЭШа, будет больше чем время, которое требуется для получения содержимого непосредственно с веб сервера.
Рисунок 9
После создания диска КЭШа нажмите Далее.
Рисунок 10
Вот и все! Проверьте свои параметры на странице Завершение создания политики веб доступа и нажмите Закончить.
Рисунок 11
Теперь давайте рассмотрим Политику веб доступа. Здесь видно, что Стандартное правило веб доступа расположено внизу, поскольку это то правило, которое срабатывает, если ни одно из созданных правил не соответствует запросу подключения.
Обратите внимание, что мастер автоматически разместил анонимные правила перед правилами аутентифицированного доступа. В общем, это хорошая политика, поскольку если вы разместите правила аутентифицированного доступа перед анонимными правилами, анонимные правила никогда не будут работать, так как клиент не может аутентифицироваться. Когда это происходит, подключение прерывается. Размещая правила анонимного доступа перед правилами аутентифицированного доступа, вы тем самым делаете так, что подключения, которые вы хотите разрешить анонимным пользователям, не будут прерываться правилами аутентифицированного доступа.
Однако в этом случае порядок следования правил не такой, какой нам нужен. Нам нужно разместить правило Политика аутентифицированного веб доступа: разрешить запрещенные в самом верху. Почему? Потому что мы хотим предоставить доступ администраторам к запрещенным сайтам, и в то же время запретить этот доступ остальным пользователям. Если вы не поместите это правило в самом верху списка, Политика анонимного веб доступа: отвергать запрещенные будет срабатывать переда разрешающим правилом для администраторов, и, таким образом, администраторам будет отказано в доступе.
Рисунок 12
Однако, прежде чем какое-либо правило сработает, вам нужно нажать кнопку Применить. Нажав кнопку Применить, вы увидите диалоговое окно Предупреждение Forefront TMG. Здесь у вас есть возможность Сохранить изменения, но не перезапускать службы и Сохранить изменения и перезапустить службы. Мы хотим Сохранить изменения и перезапустить службы, чтобы диск КЭШа был включен. Вам не нужно перезапускать службу брандмауэра Microsoft Firewall только для того, чтобы правила вошли в силу.
Рисунок 13
Когда мы дважды нажимаем на одном из правил политики веб доступа, чтобы посмотреть его свойства, мы видим, что оно выглядит как типичное правило доступа. Однако если нажать на вкладке Осмотр на вредоносное ПО, вы увидите, что опция Проверять содержимое, загруженное с веб сервера на клиента включена. Это не будет работать для всех правил связанных с не-HTTP подключениями.
Также обратите внимание, что политика веб доступа расположена в группе, где ее можно развернуть и свернуть при просмотре в панели Вся политика брандмауэра.
Рисунок 14
Итак, последнее, что нам осталось сделать ‘ переместить политику аутентифицированного доступа для запрещенных сайтов в самый верх списка, чтобы администраторы могли иметь доступ к запрещенным сайтам. Существует два способа перемещения типичного правила доступа: правой клавишей нажмите на правиле и выберите команду «Переместить вверх», или нажмите кнопку «переместить вверх» в нижней части окна.
На рисунке ниже видны опции, доступные при нажатии правой клавишей на правиле. Ой! Там нет команды «переместить вверх». Возможно, они зыбли добавить ее в Beta 1 версии продукта. Давайте посмотрим на панель кнопок и попытаемся найти кнопку «Переместить вверх» там.
Рисунок 15
Да что такое? Здесь тоже нет кнопки «Переместить вверх»! Итак, на этот раз, кажется, вы не можете изменить порядок правил после создания политики веб доступа. Это может стать серьезной проблемой в примере, который мы использовали здесь, и в котором нам нужно дать группе аутентифицированных пользователей доступ к сайтам, запрещенным для всех остальных пользователей. Полагаю, что эта ошибка будет присутствовать только в бета версии. Однако если таков замысел разработчиков, то решением этой проблемы будет удаление правила Политика аутентифицированного веб доступа: разрешить запрещенные и повторное создание этого правила с помощью мастера создания правил доступа. Затем нужно поместить это правило над запрещающим правилом.
Рисунок 16
В этой серии статей из трех частей о вкладке политики веб доступа в первой бета версии Forefront Threat Management Gateway (TMG), мы рассмотрели набор функций защиты от вредоносного ПО, новую коллекцию инструментов веб прокси и веб кэширования во вкладке Задачи панели задач политики веб доступа, и закончили рассмотрением нового мастера создания политики веб доступа.
Как я делаю во всех статьях о Beta 1 версии Forefront TMG, я хочу напомнить вам, что брандмауэр TMG еще очень далек от законченной версии. Я знаю, что многие из вас, читающие обзоры TMG, считают, что компания Microsoft не слушала ваших просьб о создании новых функций и возможностей, которые вы считаете крайне необходимыми в будущих версиях ISA Firewall (Forefront TMG – это следующая версия ISA Firewall). Будьте терпеливыми и ожидайте следующих бета версий, поскольку я уверен, что к моменту выхода TMG в версии RTM, вы будете очень довольны тем, что увидите. Спасибо!