В этой статье мы рассмотрим влияние конфигурации политики брандмауэра и проверки подлинности на производительность системы.

Введение

Брандмауэр Forefront Threat Management Gateway (TMG) 2010 представляет собой интегрированный пограничный шлюз безопасности, обеспечивающий службы расширенной защиты сетевого и прикладного уровня. Он способен выполнять проверку протоколов низкого уровня, глубокую проверку трафика прикладного уровня, проверку подлинности пользователей, предоставлять контроль доступа на основе репутации, и проверку HTTPS коммуникаций. Эти продвинутые функции потребляют значительный объем ресурсов системы (ЦП, память, дисковый и сетевой I/O), что может повлиять на производительность и вызвать задержки, если система настроена неверно или ресурсы выделены неправильно. В предыдущей статье мы рассматривали в основном службы инфраструктуры и сетевую конфигурацию. В этой статье мы обсудим некоторые дополнительные области, в которых можно улучшить производительность.

Если вы хотите прочитать предыдущую часть этого цикла статей, перейдите по ссылке Оптимизация производительности на Forefront Threat Management Gateway (часть 1).

Политика брандмауэра

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

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

В общем и целом, правила доступа нужно настраивать в следующем порядке:

1. Глобальные запрещающие правила
2. Глобальные разрешающие правила
3. Правила для определенных компьютеров
4. Правила для определенных пользователей, целей (наборов доменных имен или наборов URL адресов), или типов MIME
5. Правила публикации
6. Все остальные разрешающие правила

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

• Располагайте правила, не требующие проверки подлинности, перед любыми правилами, которые применяются к определенным пользователям и/или группам. Проверка подлинности пользователей требует дополнительного времени и потребляет больше системных ресурсов, поэтому расположение правила анонимного доступа во главе списка правил политики брандмауэра позволяет избежать ненужных запросов проверки подлинности и снижает потребление ресурсов.
• По возможности используйте IP адреса. IP адреса могут быстро оцениваться брандмауэром TMG без необходимости выполнения операции по разрешению имен. А это также снижает нагрузку на DNS серверы.
• Используйте полные доменные имена (FQDN) в наборах доменных имен и URL адресов.
• По возможности не используйте RADIUS для проверки подлинности. RADIUS проверка подлинности значительно медленнее, чем интегрированная проверка подлинности. Интегрированная проверка подлинности использует собственные протоколы аутентификации Active Directory, такие как NTLM и Kerberos, а они более надежны и высокопроизводительны.
• По возможности не используйте запрещающие правила, включающие «весь исходящий трафик» и используйте набор доменных имен для указания цели. Когда правило доступа настроено так, брандмауэр TMG будет вынужден выполнять обратный поиск DNS для каждого получаемого запроса, чтобы определить, включен ли целевой IP в набор доменных имен. Это значительно снижает производительность и перегружает DNS сервер.

Проверка подлинности

Применение проверки подлинности на основе групп и пользователей для веб-прокси траффика – это идеальный вариант. Однако процесс проверки подлинности пользователей может быть весьма затратным в терминах потребления ресурсов. По умолчанию, брандмауэр TMG будет использовать NTLM для проверки подлинности пользователей. С помощью NTLM брандмауэр TMG создает защищенный канал к одному контроллеру домена в сайте Active Directory, к которому он принадлежит. Каждый запрос, проверку подлинности которого должен выполнить брандмауэр TMG, будет обрабатываться в этом одном защищенном канале. В ситуации, где брандмауэр TMG сильно загружен, такое одиночное подключение может быстро стать «узким местом», приводящим к значительным задержкам открытия веб страниц и запросам проверки подлинности пользователей, ранее прошедших такую проверку.

Использование проверки подлинности Kerberos решает эту проблему. Благодаря Kerberos процесс проверки подлинности обрабатывается самим клиентом, а не брандмауэром TMG. Когда клиент делает запрос на тип требуемой проверки подлинности, он связывается с контроллером домена и получает Kerberos билет, представляемый брандмауэру TMG для получения доступа (подробную информацию о проверке подлинности Kerberos можно найти здесь). Проверка подлинности Kerberos доступна только для Веб-прокси клиентов, и эти клиенты должны использовать Internet Explorer 7 или выше. Если веб браузер настроен на использование Web Proxy Auto Discovery (WPAD) или сценария autoconfiguration, брандмауэр TMG должен быть настроен на предоставление FQDN прокси-сервера в сценарии autoconfiguration, как описано здесь. Если веб браузер настроен вручную, прокси-сервер необходимо указывать с помощью FQDN, а не IP адреса.

Ведение журналов

По умолчанию, TMG записывает все запросы в журналы на локальном экземпляре SQL Express, который устанавливается по умолчанию при установке продукта TMG. Инфраструктура ведения журналов в TMG более надежная по сравнению с предыдущими версиями продукта, что делает работу ведения журналов менее проблематичной. [Смотрите мою статью Logging Enhancements in Forefront Threat Management Gateway (TMG) 2010 для дополнительной информации]. Однако есть несколько рекомендаций, которых нужно придерживаться для обеспечения оптимальной производительности ведения журналов.

Файлы базы данных журналов нужно размещать на отдельном разделе; в идеале этот раздел не должен быть системным. Лучше чтобы этот раздел был на отдельном физическом диске. По умолчанию TMG хранит файлы базы журналов в системном разделе. Для перемещения этих файлов откройте консоль управления брандмауэра TMG и выделите раздел Журналы и отчеты (Logs & Reports) в навигационном меню, а затем нажмите Настроить функцию ведения журналов брандмауэра (Configure Firewall Logging) в панели Задачи (Tasks). Нажмите кнопку опций Options рядом с SQL Server Express Database (на локальном сервере), затем выберите Эта папка (введите полный путь) (This folder (enter the full path)): и укажите новый накопитель и путь к каталогу хранения файлов базы журналов. Для массивов предприятия такая папка должна существовать на каждом члене массива. Когда все готово, повторите этот процесс, нажав Настроить функцию ведения журналов веб-прокси сервера (Configure Web Proxy Logging).

Если брандмауэр TMG сильно перегружен, лучше использовать запись журналов в текстовые файлы. Одним недостатком использования текстовых файлов журналов является то, что просмотр истории данных журнала в консоли управления TMG больше недоступен. Однако в рамках производительности это идеальный вариант, так как запись журналов в текстовые файлы потребляет гораздо меньше системных ресурсов. Для настройки текстовых файлов журналов выполните вышеописанные шаги и выберите опцию Файл (File). Нажмите на кнопку Опции, после чего можно указать, где будут храниться файлы журналов.

Кэширование

Брандмауэр TMG способен кэшировать часто запрашиваемые веб объекты и хранить их в памяти и на диске. После чего эти объекты при запросах берутся из кэша и предоставляются клиентам с LAN скоростью, без необходимости обращения к серверу происхождения этих объектов. Кэширование уже не так эффективно, как оно было пять-десять лет назад, когда основная часть интернет контента была статической, однако включение кэша все еще занимает от 10 до 20 процентов его использования в большинстве сегодняшних сред. Получение 20 процентов трафика из кэша является быстрым и простым способом снижения загруженности WAN канала и улучшения производительности для конечных пользователей.

Чтобы включить кэширование, выделите раздел Политика веб доступа (Web Access Policy) в меню навигации и нажмите Настроить веб кэширование (Configure Web Caching) в панели Задачи (Tasks). Выберите закладку Диски кэша (Cache Drives), выделите участника массива, затем нажмите Настроить (Configure). Выделите диск для хранения кэша, укажите значение в поле Максимальный размер кэша (Maximum cache size (MG)): и нажмите Задать (Set).

HTTP сжатие

HTTP сжатие, поддерживаемое в TMG, позволяет брандмауэру запрашивать и доставлять веб содержимое в сжатой форме с помощью GZip. Включение HTTP сжатия потребляет дополнительные ресурсы ЦП, но может значительно улучшать производительность сетевого канала, когда TMG подключен к медленному каналу WAN.

Чтобы включить HTTP сжатие, выделите раздел Политика веб доступа (Web Access Policy) в меню навигации, и нажмите Настроить HTTP сжатие (Configure HTTP Compression) в панели Задачи. В закладке Общие (General) отметьте опцию Включить HTTP сжатие (Enable HTTP compression), затем выберите закладку Запрашивать сжатые данные (Request Compressed Data) и добавьте сеть, с которой будет запрашиваться сжатый HTTP контент.

Заключение

Есть огромное количество факторов, влияющих на общую стабильность и производительность брандмауэра TMG. В этой статье мы рассмотрели влияние конфигурации политики брандмауэра и проверки подлинности на производительность системы. Оптимизация политики брандмауэра путем расположения правил от самых простых к самым сложным и настройка клиентов на использование Kerberos проверки подлинности может значительно повысить производительность системы. Внесение изменений в стандартные опции ведения журналов, а также включение веб кэширования и HTTP сжатия (где это возможно) позволяет улучить работу TMG.

Если вы хотите прочитать предыдущую часть этого цикла статей, перейдите по ссылке Оптимизация производительности Forefront Threat Management Gateway (часть 1).