Технологические возможности

Сервер Internet Security and Acceleration (ISA) Server является брандмауэром и прокси-сервером класса предприятия, созданным компанией Microsoft. Как и следует из его названия, сервер ISA создан для придания соединениям с Internet большей безопасности и эффективности. Сервер ISA может выступать отдельно брандмауэром или прокси-сервером, а также может выполнять эти функции одновременно, становясь пограничным сервером локальной сети.

Кэширование содержания и прокси

Кэширование содержания, также известное как прокси, разработано для максимизации эффективности соединений локальной сети с Internet. Для примера предположим, что 10 000 пользователей вашей сети установили ресурс Yahoo! своей домашней страницей в Web-броузере. Каждый раз при запуске Web-броузера, он, прежде всего, запрашивает свою домашнюю страницу, загружая через соединение с Internet текст и графику. Загрузка десятью тысячами человек одного и того же содержания по несколько раз на день выглядит крайне неэффективной. Когда используется прокси-сервер, пользователи не соединяются непосредственно с узлами в Internet. Вместо этого они создают запрос к прокси-серверу с требованием выйти в Internet и получить содержимое некоторого узла Web. Когда прокси-сервер получает некоторое содержимое, он его кэширует, то есть сохраняет на своем жестком диске. Если другой пользователь запросит то же содержимое, прокси-сервер сможет его ему предоставить без выхода в Internet, а просто взяв с диска. Прокси-сервера содержат средства для определения того, что содержимое узла в Internet было изменено после его сохранения в кэше. Если такое событие происходит, при выполнении следующего запроса к этому узлу будет информация снова затребована из Internet, а не взята из кэша на диске.

Тот факт, что прокси-серверы становятся посредниками при выходе пользователей в Internet, делает существенным также и их использование в качестве фильтров содержания. Хотя большинство прокси-серверов (и ISA в их числе) не может осуществить слишком много при фильтрации содержания, практически все они являются расширяемыми, и позволяющими встраивать в себя фильтры сторонних производителей. Эти фильтры анализируют запросы пользователей на получение информации из Internet, перед тем, как прокси-сервер непосредственно приступит к ее получению. Если содержимое отфильтруется (например, если адрес узла содержится в списке узлов, предназначенных для взрослой аудитории), фильтр даст указание прокси-серверу вернуть пользователю сообщение об ошибке доступа к «запрещенному» узлу, вместо того, чтобы получать его содержимое из Internet. Фильтры также могут анализировать содержание страниц после их получения прокси-сервером, сканируя их на предмет наличия неприемлемых слов и выражений. Если содержимое не удовлетворяет требованиям фильтра, содержимое может быть либо заменено (например, нецензурные слова будут замены звездочками), либо прокси-серверу будет дано указание отвергнуть данную страницу в полном объеме и выдать сообщение пользователю о «недопустимом» содержании страницы.

Теория операций

Сервер ISA фактически осуществляет три вида кэширования: forward caching (прямое кэширование), scheduled caching (кэширование по расписанию) и reverse caching (обратное кэширование). Первым типом, уже рассмотренным в настоящей главе, является прямое кэширование, при котором сервер ISA, выступая посредником для пользователя, сохраняет содержимое запрошенной страницы для удовлетворения будущих запросов без выхода в Internet. Кэширование по расписанию заставляет сервер ISA периодически загружать определенное содержание из Internet, делая его доступным для пользователей еще до поступления от них запроса. Кэширование по расписанию работает подобно серверной версии функции Channels в системе Internet Explorer 4.0: сначала конфигурируются определенные адреса URL, после чего серверу ISA дается задание загрузить этот узел (и, если это необходимо, — все узлы, на которые в данном содержится ссылка). Конфигурируется расписание, согласно которому этот узел будет загружаться сервером ISA из Internet, обновляя свой кэш. В заключение, обратное кэширование заставляет сервер ISA обеспечивать внешних (из Internet) пользователей кэшированным доступом к внутренним Web-серверам. Для примера предположим, что у нас в локальной сети имеется внутренний Web-сервер, который осуществляет доступ к статичным страницам с информацией о продукции. Размещая этот Web-сервер за сервером ISA, а не непосредственно в Internet, мы может защитить его от атак из Internet. Обратное кэширование сервера ISA может также сократить и нагрузку на сервер: когда пользователь из Internet запрашивает страничку о продукте, сервер ISA может ее уже иметь в своем кэше, и передать пользователю, вообще не обращаясь к Web-серверу. Сервер ISA может использоваться для прямого и обратного кэширования одновременно.

Для определения того, когда срок действия кэша истекает, и он должен быть обновлен, сервер ISA использует информацию TTL (Time-to-live, срок годности). Большинство страниц в Web содержат информацию TTL внутри себя, и сервер ISA всегда при необходимости ее использует. Например, Web-страница с ежедневными новостями может содержать TTL равный 24 часам, таким образом, гарантируя, что прокси-сервер будет обновлять свежую копию страницы раз в день.

Естественно, у вас нет какого-либо влияния на информацию TTL, помещенную на сами Web-страницы. Однако вы должны удостовериться в работе TTL и информировать пользователей о вероятной причине получения ими устаревшего содержания из Internet.

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

Сервер ISA также поддерживает отрицательное кэширование (negative caching). Когда сервер ISA пытается получить содержимое из некоторого узла Web, а этот сервер оказывается недоступным, он получает сообщение “not available”. Отрицательное кэширование может сохранить такой ответ не некоторый период времени, выдавая в течение него пользователям быстрый ответ о недоступности ресурса, к которому они пытаются обратиться. Отрицательное кэширование может быть отключено, вследствие чего сервер ISA перестанет кэшировать отказы в доступе, заставляя сервер ISA пытаться получить содержимое Web-узла до тех пор, пока связь с ним не будет успешно установлена.

В сервере ISA можно сконфигурировать его общее поведение при кэшировании. Для страниц Web можно заставить сервер запрашивать содержимое очень часто, часто, обычным образом, или с использованием заданного относительного TTL. Заданная конфигурация повлияет на эффективность сервера ISA, так как слишком частые обновления способствуют увеличению нагрузки на канал в Internet, не зависимо от давности содержимого в кэше. Слишком редкие обновления, что очевидно, приводят к тому, что устаревшее содержание будет находиться в кэше дольше обычного. Для содержимого FTP, которое не содержит TTL, можно либо отменить кэширование, или задать относительную величину TTL (по умолчанию используется 1 день). Значение TTL для FTP (если оно задано) применяется ко всему кэшируемому содержимому FTP.

Существует некоторое содержание, кэшированием которого управлять нет возможности. Web-узлы имеют свойство посылать вместе с Web-страницами специальные заголовки управления кэшем, и сервер ISA не будет кэшировать содержание, которое имеет следующие их типы:

• Cache-control: no-cache. Этот заголовок указывает, что Web-сервер не желает, чтобы его содержимое вообще кэшировалось. Такой заголовок Web-серверы обычно включают для динамически генерируемых Web-страниц, таких как карточки покупок в Internet-магазинах.
• Cache-control: private. Этот заголовок обычно включается в Web-страницы, которые содержат конфиденциальную информацию. Кэширование таких страниц бесполезно, так как Web-сервер никогда не вышлет их содержимое кому-либо кроме своего исходного пользователя.
• Pragma: no-cache. Работа этого заголовка аналогична функции cache control: no-cache, однако она менее широко используется в Internet.
• Www-authenticate. Этот заголовок указывает, что страница требует аутентификации, и ее кэширование бесполезно, так как она уникальна для аутентифицированного пользователя.
• Set-cookie. Этот заголовок включается в любую Web-страницу, которая устанавливает cookie. Так как cookie большей частью содержат информацию, специфичную для пользователя, не имеет смысла кэшировать страницу, так как она будет бесполезна для остальных пользователей.

В дополнение, сервер ISA не кэширует ответы на исходящие запросы, которые содержат заголовок authorization или cache-control:no-store. Ответы на такие запросы обычно являются частными, и предоставляют пользователю Web-броузера управление кэшированием сервера ISA ответов на них.

Составляющие конструкции

Функции кэширования сервера ISA реализуются его встроенной службой Web Proxy. Эта служба имеет три основных элемента конструкции: подсистему хранения на диске, производительность и конфигурацию кэша.

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

• Старайтесь использовать для кэша только один логический диск. В то время, как сам сервер ISA этот вопрос не волнует, и он дает возможность распределить кэш по нескольким логическим устройствам, мой личный опыт показывает, что при использовании одного диска упрощается управление. Имейте в виду, что все логические диски, используемые для кэша, должны быть форматированы в файловой системе NTFS.
• Для кэша нужно отвести не менее 100МВ дискового пространства, плюс 0.5МВ для каждого клиента в локальной сети. В больших сетях емкость одного сервера может быть быстро исчерпана, а значит, вам лучше использовать массив кэширования. Этот вопрос будет рассмотрен в разделе «Архитектура предприятия» далее в этой главе.
• Старайтесь привлечь в процесс кэширование как можно больше физических дисков. В общем случае это подразумевает использование дискового массива RAID какого-либо типа, в котором несколько физических дисков конфигурированы для работы в качестве одного логического устройства. Если RAID-массив для вас не подходит, распределите кэш по нескольким дискам. Общая производительность кэширования возрастает по мере увеличения количества задействованных физических дисков.

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

Если вы все-таки собрались использовать дисковый массив, используйте его тип RAID 4, а не обычный RAID 5. Отличие состоит в том, что массив RAID 5 может обслужить сбой одного диска в массиве на основании информации о четности. Массивы RAID 5 обладают большей производительностью при чтении, но иногда показывают меньшую производительность при записи, чем массивы RAID 4, из-за необходимости записи информации о четности в дополнение к обычным данным. Массивы RAID 4 не обслуживают сбои дисков: если один диск выходит из строя, весь массив становится неработоспособным, и должен быть переформатирован. Если в вашей сети им5еется только один сервер ISA, использование массива RAID 4 не будет хорошим решением, так как сбой одного диска приведет к отказу всего сервера. При использовании массива кэширования (см. раздел «Архитектура предприятия» далее в этой главе), потеря одного члена массива не приводит к катастрофе, и RAID 4 позволит добиться большей производительности. Вам следует взвесить все потенциальные плюсы и минусы при принятии решения относительно типа дискового массива, который будет для вас наиболее приемлемым.

Производительность является важной составляющей любой конструкции сервера ISA. На уровне оборудования, для того, чтобы достичь максимальной производительности, сервер должен иметь как можно больше оперативной памяти и как можно более быструю дисковую систему. На уровне рабочей загрузки, будьте очень осторожны при использовании сервера ISA для осуществления обратного кэширования на сильно загруженных сетях. Как показано на рис. 12.1, сервер ISA может одновременно осуществлять прямое и обратное кэширование. Если осуществляется много запросов к внутреннему Web-серверу, и если он возвращает в основном статические страницы, тогда он может оказаться не таким уж загруженным. Основную массу его рутинной работы возьмет на себя сервер ISA, который будет выдавать пользователям содержимое своего кэша. При этом сервер ISA станет менее доступным для внутренних клиентов (или наоборот, если основную нагрузку на сервер ISA производят внутренние клиенты). Если сервер ISA должен выполнять обе эти функции, и одного сервера для такой работы не достаточно, можно использовать кэш-массив, который, в сущности, представляет собой кластер серверов ISA. В разделе «Архитектура предприятия» мы еще вернемся к этому вопросу.

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

Брандмауэр

Сервер ISA является полноценным брандмауэром, который хорошо интегрируется в сетевую среду Windows. Он позволяет определить, кто имеет права доступа в локальную сеть из Internet, и какие типы пакетов могут быть отправлены в Internet из локальной сети. Сервер ISA имеет возможность определения фактов внедрения в локальную сеть, что позволяет идентифицировать атаки на компьютерах серверов ISA. Серверы ISA позволяют задавать более детальные критерии доступа, чем менее интегрированные брандмауэры, позволяя определять правила организации трафика, основанные не только на типах пакетов, но и на потребностях отдельных пользователей и групп.

Теория операций

Перед тем, как вы сможете понять, как сервер ISA работает в качестве брандмауэра, нужно немного разобраться в том, как работает протокол TCP/IP. Данные, пересылаемые между компьютерами с использованием TCP/IP, организованы в пакеты, которые представляют собой просто небольшие сегменты данных, пригодные для передачи по сети. Например, отдельная Web-страница может быть разбита на сотни пакетов, которые собираются принимающим компьютером в единый поток входных данных. Каждый пакет помечается IP-адресом отправителя, называемым адресом источника, и IP-адресом получателя, называемым адресом назначения. Эти адреса используются маршрутизаторами между отправителем и получателем для пересылки пакетов в правильном направлении. Пакеты также маркируются номерами портов (или просто портами) источника и назначения. Когда пакет достигает точки назначения, получатель использует порт назначения для определения того, какая служба (например, Web-сервер или FTP-сервер) будет обрабатывать данный пакет. На порт источника всегда отправляется ответ, позволяющий отправителю ассоциировать ответ с исходным запросом.

Каждый пакет TCP/IP содержит вложение (payload), являющееся ни чем иным, как его содержимым. Вложения состоят из данных, форматированных в соответствии с протоколами уровня приложения, такими как HTTP, FTP, SMTP, и т.п. Как только пакет поступает на IP-адрес и порт назначения, принимающий компьютер обрабатывает вложение соответствующим образом. Например, пакеты, направленные на порт 80 Web-сервера, должны содержать вложения HTTP, так как Web-сервер не знает, как обрабатывать другие их типы.

Такие брандмауэры, как сервер ISA, способны ограничить потоки, основываясь на информации, заключенной в пакетах TCP/IP, или на типах вложений. Сервер ISA, при его тесной интеграции с операционной системой Windows, также может ограничить потоки на основе разрешений, предоставленных конфигурацией отдельным пользователям и их группам. При получении пакетов сервером ISA он пропускает их через серию фильтров, проверяющих право прохождения этих пакетов через сервер. Фильтры бывают двух типов:

• Пакетные фильтры (packet filter) проверяют IP-адрес и порт пакета, определяя, приемлем ли такой пакет. Пакетные фильтры используют статические правила, и пытаются поставить пакет в соответствие правилу, разрешающему его прохождение (все пакеты, которым не найдены соответствующие правила, не пропускаются). Например, можно определить правило, позволяющее пакетам, отправленным со всех IP-адресов локальной сети с любыми номерами портов в Internet, проходить через сервер ISA, если порт назначения равен 80. Это правило разрешит прохождение всех исходящих Web-пакетов.
  Сервер ISA в своих пакетных фильтрах также использует проверку состояния. Если вы сконфигурировали вышеуказанное правило разрешения исходящих Web-пакетов, ответы на эти запросы не будут приняты, пока не будут сконфигурированы статические правила, их разрешающие. А если для этого сконфигурировать статические правила, вы можете сделать свою локальную сеть открытой для всех входящих Web-пакетов, часть из которых не желательна. Проверка состояния решает эту проблему, автоматически разрешая принятие ответов от Web-серверов на пропущенные через сервер ISA запросы, то есть, сравнивая ответ с отосланным запросом.
• Фильтр протокола анализирует вложения пакетов, определяя, разрешено ли их прохождение. Фильтры протокола облегчают конфигурирование общих протоколов Internet, и не требуют знания их портов, разрешая конкретные виды пакетов (например, FTP), отправляемые на нестандартные номера портов (например, для серверов FTP пользователей, которые используют нестандартные порты).

Сервер ISA также реализует обратную публикацию (reverse-publishing) ресурсов в локальной сети. Обратная публикация указывает серверу ISA принимать входящие пакеты из Internet, направленные на заданные IP-адреса и порты. Сервер ISA после этого переправляет эти пакеты обозначенному серверу локальной сети для обработки. Например, можно сконфигурировать сервер ISA для приема входящих пакетов SMTP и пересылки их на локальный почтовый сервер. С точки зрения Internet, сервер ISA будет работать как сервер электронной почты. На самом же деле, сервер ISA будет просто перенаправлять пакеты на внутренний сервер электронной почты, таким образом предохраняя его от атак.

Сервер ISA также просматривает все входящие из Internet пакеты на предмет того, не представляет ли собой поток атаку на сервер ISA. Сервер ISA может определить следующие виды атак:

• Сканирование портов, которое взломщики обычно используют для того, чтобы определить, за какие порты отвечает сервер. Как только список портов получен, взломщик концентрирует следующие атаки именно на этих портах.
• Полусканирование IP (IP half scan). Это значит, что сервер ISA пытается подключиться к компьютеру назначения, а тот не отвечает. Это обычно является результатом того, что взломщик послал на сервер запрос, а после этого игнорировал ответ. При этом соединение с сервером остается открытым, и может быть использовано для будущих атак.
• Ping of death attack. При этом взломщик посылает чрезвычайно большие пакеты ICMP (Internet Control Message Protocol) в надежде переполнить обработчик TCP/IP получателя.
• UDP bomb attack. Здесь пакет UDP (User Datagram Protocol) содержит запрещенные значения. Старые реализации TCP/IP при попытке обработки таких пакетов просто выходили из строя.
• Windows out-of-band attack. Здесь взломщик пытается вызвать переполнение сервера, посылая громадное количество пакетов на один и тот же порт.

Сервер ISA содержит и другие фильтры для определения попыток взлома. Они описаны в документации и призваны защитить DNS, POP3 и другие протоколы, а также предохраниться от других общих типов атак.

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

Составляющие конструкции

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

Можно создать демилитаризованную зону, или DMZ, включив в нее несколько компьютеров, которые поддерживают и защищают общедоступные сервера. Идея такой зоны состоит в том, что внешний брандмауэр разрешает входящие пакеты из Internet для доступа к общедоступным серверам, в то время как внутренний брандмауэр удерживает эти пакеты вне более защищенной внутренней сети. Внешний брандмауэр разрешает для прохода в DMZ только специфичные пакеты (такие как Web или FTP), чтобы защитить сервера этой зоны от атак на свои порты.

В компьютерах, выступающих серверами ISA, и работающими только в качестве брандмауэров, не обязательно должно быть большое дисковое пространство. Главное, что им необходимо — это как можно больший объем оперативной памяти. Имейте в виду, что эти сервера должны проверять каждый входящий и исходящий пакет, а это требует быстрого процессора и хорошего сетевого адаптера. Естественно, сервер ISA ограничен в объеме данных, принимаемых из Internet и отправляемых в него, так как мощность канала в Internet у большинства компаний составляет доли процента от быстродействия их внутренних сетей.

Архитектура клиента

Сервер ISA поддерживает три типа клиентов, и реализует для них разные наборы функций. В современной гетерогенной компьютерной среде понимание того, как сервер ISA поддерживает разные типы клиентов, поможет вам принять лучшее решение относительно организации вашего сервера ISA.

Теория операций

Не забывайте, что сервер ISA фактически работает в двух режимах: прокси-сервера и брандмауэра (которые могут быть объединены на одном сервере). Каждый режим поддерживает разные типы клиентов. В режиме прокси-сервера поддерживаются CERN-совместимые Web-броузеры. (CERN – международный исследовательский центр, которым была разработана технология WWW. Прим. перев.) Такие броузеры и используются сегодня повсеместно — от Netscape Navigator 4.x до Internet Explorer 4.x, а также более поздние их версии. Поэтому если вы не используете некий допотопный Web-броузер, все ваши пользователи смогут ощутить достоинства использования прокси-сервера ISA.

При работе с брандмауэром сервер ISA распознает два типа клиентов: 32-битный Windows, и все остальные. Сервер ISA на 32-битных системах Windows требует установки специального клиентского программного обеспечения. Этот клиент перехватывает обычные методы обработки потоков TCP/IP. Все потоки, посылаемые по внутренним адресам локальной сети, обрабатываются в обычном режиме. Все исходящие потоки клиент брандмауэра перехватывает и отсылает на сервер ISA, наряду с сопровождающей аутентификационной информацией. Этот клиент позволяет серверу ISA включить в правила брандмауэра информацию о пользователях и группах, например, разрешая отсылку определенных типов пакетов для конкретных пользователей.

Все клиентские компьютеры, на которых не установлено клиентское программное обеспечение сервера ISA, рассматриваются как клиенты “SecureNAT”. Сервер ISA продолжает защищать доступ из Internet к таким клиентам, однако не получает от них аутентификационную информацию. Это значит, что выход в Internet им не будет предоставлен, если он организован только на основании аутентификационных данных пользователей сети. Если у каких-либо клиентов запущена операционная система, отличная от 32-битного Windows, или вы не хотите устанавливать клиент брандмауэра, то следует сконфигурировать правила брандмауэра так, чтобы предоставлять им доступ в Internet, не основываясь на правилах, содержащих в себе проверку учетных записей пользователей и групп.

Составляющие конструкции

С точки зрения конструкции, работа с клиентами 32-битной системы Windows является самой простой. При этом следует просто установить программное обеспечение клиента сервера ISA на этих компьютерах одним из множества способов, в том числе и с помощью сценариев подключения или объектов групповой политики Windows 2000. Очень важно сконфигурировать на сервере ISA правильную таблицу локальных адресов (Local Address Table или LAT) и дать этой таблице найти клиентов брандмауэра. Таблица LAT укажет клиентам, какие адреса являются локальными, а какие — внешними, и должны пропускаться через брандмауэр. Если у вас имеются клиенты с операционной системой, отличной от Windows, вам следует спланировать правила брандмауэра так, чтобы разрешить этим клиентам работать соответствующим им образом. Это значит, что ваши правила будут ограничены фильтрами IP-адресов и номеров портов, и не будут содержать фильтрацию пакетов по пользователям и группам.

Некоторые действия по конфигурированию Web-броузеров придется выполнить на клиентских машинах, с тем, чтобы они смогли использовать прокси-сервера ISA. Ели выполнять установки прокси на компьютерах клиентов вручную, это займет много времени. Сервер ISA предлагает два автоматизированных варианта такого действия: сценарий автоматической конфигурации и автоматическое обнаружение прокси-сервера. Последний метод является наиболее простым, так как Web-броузер уже по умолчанию сконфигурирован для автоматического обнаружения установок прокси-сервера. (Если это не так, вам придется, по крайней мере, сконфигурировать их для этого. Чтобы сконфигурировать все броузеры за один раз, вы должны быть способны использовать Политику Групп (Group Policy) или какой-либо другой централизованный механизм.) Автоматическое обнаружение фактически выполняется с помощью DNS (служба имен домена) и DHCP (протокол динамического конфигурирования узла). Для этого на сервере DNS нужно создать новую запись Alias(CNAME) с именем WPAD с полным именем вашего сервера ISA. После этого в DHCP нужно сконфигурировать глобальный или групповой параметр с именем WPAD и кодом 252. Значением этого параметра должен быть полный адрес URL записи DNS CNAME: http://wpad/wpad.dat. Как только эти действия выполнены, все Web-броузеры активизируют автоматическое обнаружение прокси-сервера, и станут способными правильно найти ваш сервер ISA.

Архитектура предприятия

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

Теория операции

Сервер ISA предлагает три функции поддержки архитектуры предприятия:

• Кэш-массивы (cache arrays), позволяющие объединять несколько компьютеров с установленным сервером ISA в кластер, работающий как единый гигантский прокси-сервер.
• Кэш-цепочки (cache chains), позволяющие пересылать серверам ISA запросы на другие сервера ISA, образуя таки образом иерархию кэширования.
• Три режима сервера, которые позволяют компьютеру работать как прокси-сервер, как брандмауэр, или совмещать эти две функции. Эти режимы позволяют назначить сервер ISA конкретной задаче, повышая его способность справляться с требованиями.

Кэш-массивы оказываются полезными в любой крупной организации, где объем Web- и FTP-запросов превосходит мощность одного сервера. Кэш-массив является группой, или кластером, компьютеров серверов ISA, которые распределяют между собой общую нагрузку по кэшированию. Эти серверы взаимодействуют между собой по протоколу CARP (Cache Array Routing Protocol, протокол маршрутизации кэш-массивов) для определения того, какой сервер должен кэшировать какой URL. Когда клиенты подключаются к кэш-массиву, соответствующий сервер ISA обрабатывает запрос, основываясь на адресе URL, содержащемся в нем. Кэш-массивы можно создать только тогда, когда серверы ISA установлены на членах домена Active Directory, и когда этот домен инициализирован утилитой Enterprise Initialization сервера ISA. Кэш-массивы не доступны в стандартной редакции (Standard Edition) сервера ISA. Конфигурация и политики массива хранятся в Active Directory, позволяя централизованно управлять всеми массивами из одного места.

Кэш-цепочки эффективны в крупной распределенной среде. В сущности, кэш-цепочка создает иерархию компьютеров или массивов серверов ISA. Для примера предположим, что существует 10 отраслевых офисов, соединенных с главным офисам каналами T1 (первичный цифровой канал). В свою очередь, центральный офис также соединен с Internet каналом T1. Можно установить сервер ISA в каждом офисе, и соединить их в цепь с массивом в главном офисе. Пользователи в отраслевых офисах будут обращаться к содержимому собственного сервера ISA, и, если искомое не будет обнаружено, сервер свяжется с массивом главного офиса. Массив главного офиса попытается выполнить запрос из своего кэша, и, в случае неудачи, выйдет в Internet. Результатом этого станет уменьшение нагрузки на каналы связи между офисами и с Internet, при обращении к содержимому Web или FTP.

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

Составляющие конструкции

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

Вам не обязательно иметь работающий домен Active Directory, чтобы обслуживать кэш-массив серверов ISA. Вы можете, например, создать новый домен только с целью поддержки серверов ISA. Этот домен затем станет точкой перемещения существующего домена Windows NT, которое можно выполнить позже или по ходу установки. Обособленный же сервер ISA (при отсутствии массивов) можно создать и при отсутствии Active Directory. Однако обособленный режим уменьшает масштабируемость сервера ISA, так как он ограничен объемом потока, который способен обработать один сервер.

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

Технологическая поддержка

Единственной поддерживающей технологией для сервера ISA является Active Directory, и то она требуется только при использовании централизованного конфигурирования и кэш-массивов. Предыдущие версии сервера ISA (они назывались Proxy Server) основывались на сервере IIS (Internet Information Server), и привлекались в качестве фильтра ISAPI (интерфейс прикладного программирования Internet-сервера) этого сервера. В противоположность этому, сервер ISA не только не требует установки IIS, но и приводит к конфликтам, если IIS установлен на одном с ним компьютере.

Сервер ISA, естественно, полностью полагается на протокол TCP/IP, но не так сильно, как остальные сервера пакета .NET Enterprise Servers. Сервер ISA просто работает с TCP/IP на более детальном уровне для анализа пакетов и протокола, и организации правил брандмауэра, основанных на IP-адресах.

Интеграция в .NET Enterprise Server

Сервер ISA напрямую не связан ни с каким из серверов пакета .NET Enterprise Servers. Однако он реализует существенные службы, которые позволяют некоторым другим серверам пакета работать более безопасно и эффективно. Например, любой Web-сервер может быть защищен от атак, используя функции обратной публикации и обратного кэширования сервера ISA. Любой из серверов пакета, использующий Internet для связи (Exchange Server, BizTalk Server, Commerce Server, и т.д.) может быть защищен функцией обратной публикации сервера ISA. Наряду с этим, сервер ISA может обеспечить аналогичной защитой и приложения операционных систем, отличных от Windows. Обратная публикация полностью не зависит от производителя системы, так как работает только с информацией IP-адресов и отображением портов, а не с конкретными протоколами приложений.

Внедрение сервера ISA в свои конструкции

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

Конструкция брандмауэра

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

В корпоративной среде с удаленными офисами поддержка VPN (виртуальная частная сеть) в серверах ISA позволяет им выступать как в качестве брандмауэра, так и в качестве оконечного элемента соединения VPN между отраслевыми и главным офисом. При этом центральный офис должен иметь один сервер ISA для обслуживания соединения VPN, а другой – для доступа в Internet. Каждый удаленный офис может использовать единственный сервер ISA для обеих этих задач.

Конструкции кэша и прокси

Конструкции кэша не без удовольствия можно свести к одному. Для примера можно рассмотреть основную конструкцию сети, использующую серверы ISA в кэш-массиве. Такая конструкция повышает производительность кэширования, позволяя каждому серверу сосредотачиваться на своем подмножестве адресов URL, к которым осуществляют доступ пользователи. Такой массив толерантен к сбоям, так как CARP автоматически переразмещает сервера, вышедшие из строя или выведенные из обслуживания, перераспределяя их нагрузку между оставшимися серверами массива.

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

Интегрированные конструкции

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

Альтернативные технологии и продукты

Компания Microsoft немного запоздала на рынок прокси-серверов и брандмауэров. Несмотря на то, что предшественник сервера ISA — Proxy Server 2.0 — появился более пяти лет назад, он не реализовывал таких устойчивых функций брандмауэра, какими сегодня располагает сервер ISA, и каких требовали большинство компаний.

Брандмауэры

Множество компаний производили брандмауэры, которые запускались в операционной системе Windows. Среди них —Firewall-1 компании Checkpoint, который стал одним из наиболее популярных брандмауэров под Windows. Такая продукция, как брандмауэр Pix компании Cisco, являются «черными ящиками» со своей собственной внутренней операционной системой. Такие блоки просто вставляются в локальную сеть и начинают работать, позволяя конфигурировать себя с помощью протокола Telnet или Web-интерфейса.

Самым большим преимуществом сервера ISA перед этими продуктами является его интеграция с Active Directory для централизованного управления, встроенные возможности прокси-сервера (перенося его в класс решений «все-в-одном») и его интеграция с операционной системой Windows, позволяющая правилам доступа базироваться на учетных записях пользователей и групп. Сервер ISA также относительно прост в конфигурировании, по сравнению с такими продуктами как Pix, которые требуют более близкого знакомства с протоколами TCP/IP.

Кэш и прокси

Сервера кэширования и прокси стали практически товаром, доступным у множества производителей в форме встраиваемых «черных ящиков», которые требуют минимальной настройки или вообще не конфигурируются. Сервер ISA, благодаря своим возможностям создания кэш-массивов и кэш-цепочек, заполняет нишу в классе серверов для предприятий, однако эти возможности не уникальны. То, чего добивался сервер ISA — это встроенные функции брандмауэра и хороший выбор первоклассных дополнительных возможностей. Сервер ISA — один из немногих продуктов, которые позволяют расширяемость за счет продуктов сторонних производителей: фильтров содержания, кэш-массивов, кеш-цепочек, централизованного управления, и других, — объединяя все в один пакет.

Реальный пример

Мы использовали компанию Pete’s Big Beverages в качестве примера того, как можно внедрить различные сервера пакета .NET Enterprise Servers, в том числе и сервер ISA. Компания PBB имеет главный офис в Денвере и множество региональных офисов, разбросанных по всему миру. Некоторые из этих региональных офисов имеют собственные подключения к Internet, хотя целиком полагаются на инженерно-техническое управление из центрального офиса в Денвере в таких вещах, как конфигурирование локальной сети. Офисы в континентальной части США имеют частные каналы связи с офисом в Денвере, и для доступа в Internet используют его подключение. Конструкция, использованная компанией, содержит кэш-массив в каждом региональном офисе, централизованно управляемые доменом Active Directory верхнего уровня компании. Офисы со своими личными каналами выхода в Internet используют сервер ISA одновременно в качестве прокси и брандмауэра, при этом также используя его поддержку виртуальных частных сетей VPN для ее организации с центральным офисом. Региональные офисы в США имеют кэш-массивы, которые связаны в цепь с массивом в Денвере, максимизируя эффективность каналов связи между офисами.

Разрешение проблем

Не возможно установить сервер ISA в режиме Enterprise
При попытке установки сервера ISA инсталлятор предлагает только установку в режиме Standalone (обособленного сервера).

Такое поведение определено согласно конструкции. При попытке установки сервера ISA проверяется, является ли данный компьютер членом домена Active Directory, и использует ли уже этот домен схему расширения серверов ISA. Если хотя бы одно из этих условий не выполнено, установка может быть произведена только в режиме обособленного сервера, который не может стать членом массива. Для того, чтобы установить сервер ISA в режиме Enterprise, поддерживающий массивы, прежде всего, нужно убедиться, что используемый компьютер с установленной системой Windows 2000 Server принадлежит к домену Active Directory (а не домену Windows NT), и что на этом домене прошла установка пакета инициализации ISA Server Enterprise Initialization. Последнее из этих действий расширяет схему Active Directory так, чтобы она включала дополнительные атрибуты, необходимые для поддержки конфигурации массива серверов ISA.

Перед запуском Enterprise Initialization и расширением схемы Active Directory убедитесь, что вы хорошо представляете себе разветвления расширенной схемы. Каждый контроллер домена в этом лесу будет модифицирован этой новой схемой, и все сервера Global Catalog должны перестроить свои каталоги (если ваш домен не является на 100% контроллером домена Windows .NET Server). Когда вы будете готовы к расширению схемы, просто вызовите программу Enterprise Initialization в меню ISA Server Setup, которое запустится автоматически при вставке компакт-диска ISA Server.

Помните, что режим Enterprise доступен только в редакции Enterprise Edition сервера ISA. Если вы используете редакцию Standard, вам не удастся установить режим предприятия, что бы вы ни делали.

Резюме

Сервер ISA предлагает гибкое решение для защиты локальной сети и для увеличения эффективности доступа в Internet. В этой главе мы рассмотрели возможности сервера ISA, используемого в качестве прокси-сервера и брандмауэра, равно как и его архитектурные особенности, такие как кэш-массивы и цепочки. Была также описана поддержка сервером ISA различных клиентских компьютеров, работающих под Windows или другой операционной системой; а также методы создания сетевых решений, которые содержат сервер ISA для защиты значимых ресурсов локальной сети

Обзор функций администрирования

Сервер ISA (Internet Security and Acceleration) — довольно сложный в администрировании продукт, так как в локальной сети он выполняет одновременно две функции — брандмауэра и прокси-сервера. Более того, в системе безопасности сети он играет критичную роль, так что нужно запастись временем, и дважды проверить то, что вы делаете, уделяя серьезное внимание каждому проводимому в его настройках изменению.

Задачи администрирования

Администрирование сервера ISA можно разделить на четыре основные задачи:

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

Большая часть из этих задач выполняется из вкладки ISA Management в консоли MMC (Microsoft Management Console). При своей установке сервер ISA инсталлирует консоль по умолчанию, содержащую эту вкладку, в меню Start. Можно указать ему установить эту вкладку и в другие консоли, которые используются для администрирования предприятия.

Помните, что сервер ISA подерживает три типа клиентов: клиентов брандмауэра, клиентов Web и клиентов SecureNAT. Клиентами брандмауэра являются компьютеры, на которых установлена операционная система Windows и клиентская поддержка ISA Firewall Client. Некоторая часть административной работы будет связана именно с поддержкой этими программами.

Консоль ISA Management

Консоль ISA Management реализует доступ к настройке конфигурации и функций сервера ISA.

Firewall Client

Утилиты поддержки клиента сервера ISA (ISA Firewall Client) устанавливаются на компьютерах сети, работающих под операционной системой Windows. Это программное обеспечение дает возможность серверу ISA управлять доступом к брандмауэру на основе информации о принадлежности клиентов к группам, учетным записям, приложениям, и т.п. Клиентская часть содержит свое диалоговое окно конфигурирования, открывающееся из Панели Управления компьютера клиента.

Программы поддержки клиента позволяют отключить функции клиента, что переведет компьютер в ранг клиентов SecureNAT, и сделает невозможным фильтрацию его пакетов на основании информации о пользователях и группах. Отключение поддержки клиента может оправдать себя только в тех случаях, когда выявляются и устраняются источники проблем в сети, и нужно исключить функции ISA Server из списка потенциальных источников проблемы. Можно сконфигурировать клиента так, чтобы он автоматически выявлял в локальной сети сервер ISA, или же жестко прикрепить его к определенному серверу ISA. В заключение, можно в трей компьютера клиента поместить значок, показывающий, подключен ли клиент к брандмауэру и работает ли эта связь нормально.

Администрирование сервера ISA

Будьте аккуратны, так как функции сервера ISA слегка отличаются, в зависимости от того, как он устанавливался. Например, при его установке в среде Active Directory нужно вначале запустить утилиту ISA Enterprise Initialization для расширения схемы Active Directory с целью поддержки сервера ISA. Эта утилита также позволяет определить, в какой мере компьютеры серверов ISA на предприятии будут применять централизованную политику, которая будет сконфигурирована в Active Directory.

При установке сервера ISA вам будет также предложено принять решение и по следующим вопросам:

• Будет ли компьютер принадлежать массиву (даже если он — только первый член нового массива), или будет обособленным сервером.
• Какую функцию будет выполнять компьютер: прокси-сервера, брандмауэра; или же эти функции в нем будут совмещены.
• Будет ли данный компьютер членом домена и руководствоваться политиками предприятия, или нет. Это решение определяет, будет ли сервер принадлежать массиву, или использовать корпоративную политику. Однако обе эти функции требуют того, чтобы сервер был членом домена Active Directory.

Для примеров, приводимых в этой главе я установил сервер ISA так, чтобы он реализовывал максимум возможных своих функций: я сделал его членом домена и массива, а также одновременно брандмауэром и прокси-сервером. В зависимости от того, как вы будете устанавливать свой сервер ISA, отдельные окна, показанные в этой главе, и описания действий будут не вполне соответствовать тому, что вам придется делать.

Общая конфигурация сервера

Важной концепцией сервера ISA является Таблица Локальных Адресов (Local Address Table или LAT). В ней определяются те адреса, которые сервер ISA будет трактовать как адреса локальной сети; все остальные адреса будут им восприниматься как внешние. При установке сервера ISA формируется исходная таблица LAT.

Примечание. Можно дать возможность серверу ISA при установке самостоятельно создать таблицу LAT. При этом в нее будут автоматически добавлены следующие диапазоны адресов: от 10.0.0.0 до 10.255.255.255, от 172.16.0.0 до 172.31.255.255, от 169.254.0.0 до 169.254.255.255 и от 192.168.0.0 до 192.168.255.255. При этом также будут добавлены диапазоны адресов всех подсетей, к которым данный компьютер принадлежит.

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

Можно также воспользоваться Мастером Security Configuration Wizard сервера ISA, чтобы повысить уровень безопасности сервера ISA. Как мы видим, этот мастер предлагает выбрать один из следующих трех уровней безопасности:

• Dedicated. Этот уровень обеспечивает максимальную безопасность сервера ISA, и предназначен для компьютеров, исключительной ролью которых является брандмауэр. Этот уровень как раз и рекомендуется устанавливать, так как он обеспечивает защиту от самых распространенных сетевых атак.
• Limited Services. Этот уровень немного приоткрывает компьютер, позволяя ему наряду с ролью брандмауэра выполнять роли контроллера домена и файл-сервера. Этот уровень будет достаточным для серверов сети, используемых для размежевания ее сегментов, однако его нельзя использовать на серверах, подключенных к Internet.
• Secure. Небезопасный уровень. Сервер ISA открывает дополнительные порты, позволяющие функционировать запущенным на компьютере серверам приложений и баз данных. Эта конфигурация не рекомендуется. Если у вас есть обычный сервер приложений, и вы планируете его задействовать в качестве брандмауэра — оставьте эту затею, и купите лучше для брандмауэра отдельный компьютер.

Проделав эту основную конфигурационную работу, мы готовы к установке параметров конфигурации сервера ISA как брандмауэра и как прокси-сервера. Не забывайте, что сервер ISA построен на принципе наименьшей доступности POLA (Principle of Least Access). Это значит, что по умолчанию сервер ISA не пропускает пакеты из локальной сети и в нее. Типы пакетов, которым прохождение будет разрешено, должны конфигурироваться вручную.

Управление элементами политики

Элементы политики — это фундамент конфигурации доступа к серверу ISA. Они представляют собой сущности, которые затем вкладываются в политики. Например, если нужно разрешить всем клиентам локальной сети получать доступ ко всем компьютерам в Web, используя Web-броузеры, нужно определить три следующие сущности: компьютеры клиентов как группу; все адреса в Web как другую группу, и Web-протокол (HTTP). Сервер ISA поддерживает пять основных типов элементов для политик:

• Расписания
• Множества клиентов
• Множества адресов назначений
• Определения протоколов
• Группы содержания

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

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

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

Следующим элементом конфигурирования являются протоколы. Сервер ISA изначально сконфигурирован для множества протоколов, к которым можно добавить и дополнительные. Протоколы определяются своими портами TCP и UDP, которые они используют. При этом им присваиваются смысловые имена, позволяющие отличать правила друг от друга. Вполне вероятно, что большая часть необходимых вам протоколов уже будет определена в сервере ISA, однако всегда при необходимости вы сможете к ним добавить и собственные определения.

В заключение, можно сконфигурировать группы содержания, которые будут представлять отдельные категории материала, опубликованного в Internet, в частности, в Web. При необходимости, к ним можно добавить и дополнительные, взяв за основу расширения файлов и строки типов MIME (такие как text/html или application/msword). Группы содержания, в сущности, определяют только типы файлов (файлы HTML, документы Word, и т.п.), они не имеют никакого отношения к информации, содержащейся в этих файлах.

Имейте в виду, что до сих пор мы занимались только созданием элементов политик. Когда готовы все элементы, которые ограничат загрузку документов Word из компьютеров Web-серверов компании Microsoft, можно приступать к созданию и реальных правил доступа.

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

Правила политики

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

Помните, что правила могут как разрешать, так и запрещать потоки, и любой поток считается запрещенным, пока он не будет разрешен соответствующим правилом. Согласно конфигурации на рис. 22.11, только серверы моей локальной сети будут способны осуществить доступ в Internet, при этом они смогут получить доступ только к серверам узла Microsoft.

Правила протокола работают аналогично. Как показано на рис. 22.12, я сконфигурировал два правила протокола. Первое из них запрещает все исходящие пакеты, использующие протокол AOL Instant Messenger, а второе разрешает прохождение любых пакетов FTP. Обратите внимание на название правила “No outbound FTP” (запрещение исходящих пакетов FTP), которое, на самом деле, в соответствии со своей конфигурацией, разрешает прохождение исходящих пакетов FTP.

Правила узла, содержания и протокола работают совместно. Например, хотя мною создано правило, разрешающее исходящие пакеты FTP, я разрешил доступ своим серверам только к узлу компании Microsoft. Таким образом, эта комбинация разрешит доступ моим серверам к тем узлам Microsoft, которые поддерживают протокол FTP. Политики предприятия и массива также могут налагаться, в зависимости от того, как инициализировано предприятие. Когда же правила конфликтуют друг с другом, принимается то из них, которое является более агрессивным с точки зрения запретов. Другими словами, правило “Allow” (разрешить) всегда будет вытесняться правилом “Deny” (запретить).

Управление кэшированием

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

Правила пропускной способности используют дополнительный элемент политики, сконфигурированный на уровне массива: элемент приоритета потока. Приоритеты пропускной способности определяются в относительных величинах. Например, элемент с приоритетом 100 получит только половину мощности потока, который будет назначен элементу с приоритетом 200. Два элемента, сконфигурированные с приоритетом 5, получат приблизительно равную мощность потока. Эти элементы конфигурируются, а затем используются в правилах потоков сервера ISA как для входящих, так и для исходящих потоков. Не забывайте, что правила пропускной способности определяют приоритеты, а не абсолютные мощности потоков. В период, когда остальные потоки находятся в состоянии ожидания, протокол с самым низким приоритетом (например) может использовать всю мощность канала. Приоритеты пропускной способности играют роль только тогда, когда одновременно задействовано несколько типов потоков, и их необходимо отсортировать по приоритету.

Щелкнув правой кнопкой на папке Cache Configuration под именем массива, и выбрав в контекстном меню пункт Properties, можно выполнить основные задачи конфигурирования для кэш-массива. Содержание с более краткосрочным сроком годности будет более часто обновляться из Internet, что приведет к наличию более свежего содержания за счет дополнительной нагрузки на канал доступа в Internet.

Кэш протокола FTP конфигурируется аналогично, за исключением того, что срок годности (time to live) задается для всего содержимого кэша (в случае протокола HTTP срок годности определяется для каждого объекта, на основании содержащейся в его заголовке информации). По умолчанию это значение равно 24 часам (1440 мин.). Это значит, что кэшируемое содержание обнуляется каждые 24 часа, и при следующих запросах пользователей заново извлекается из Internet.

Во вкладке Active Caching конфигурируется способность сервера ISA заблаговременно загружать содержание в кэш, то есть еще до того, как пользователь ее запросит. Здесь можно управлять частотой активного кэширования, а состав содержания определяется сервером ISA на основании текущих шаблонов. Можно сконфигурировать сервер ISA для автоматической загрузки в кэш наиболее часто запрашиваемого содержания. Состав этого содержания определяется в консоли ISA Manager в папке Scheduled Content раздела конфигурации массива.

Активное кэширование может оказаться полезным для наиболее часто запрашиваемых Web-узлов, так как сервер ISA способен сделать содержание доступным для пользователей еще до того, как пользователи его запросят, таким образом значительно сокращая время реакции на запросы.

Во вкладке вкладке Advanced окна конфигурации кэша определяется масса дополнительных параметров:

• Можно запретить использование кэша для хранения больших объектов. Не следует забывать, что кэш имеет ограниченный объем дискового протсранства, который определен при его настройке, и большие объекты могут значительно сократить объем, доступный для других страниц.
• Страницы, в которых не определена дата “последнего изменения”, не могут кэшироваться достаточно точно, так как серверу ISA трудно определить тот факт, что версия в Internet является более свежей, чем в кэше. Требуя от сервера ISA кэширования таких страниц, мы потенциально можем обречь пользователей на получение устаревшего материала. Когда сервер ISA кэширует такие объекты, он применяет собственное произвольное значение срока годности, которое может не соответствовать реальным качествам материала (быть слишком большим или слишком маленьким).
• Сервер ISA можно принудить кэшировать динамическое содержание (то есть, содержащее в строке URL параметры). При нормальных условиях кэширование такого содержания бесполезно, так как страницы отличаются для каждого пользователя. Содержание может быть получено из кэша только тогда, когда состав параметров этого же URL, введенный другим пользователем, окажется таким же.
• Когда сервер ISA не может открыть Web-узел страницы, его можно заставить сгенерировать страницу с ошибкой, или вернуть самую последнюю версию страницы из кэша, если она там существует.

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

• Я бы разрешил серверу ISA кэшировать большие объекты, так как они оказывают наибольшую нагрузку на канал в Internet. При этом я бы обеспечил кэш достаточным объемом дискового пространства на быстродействующем дисковом массиве.
• Я бы позволил серверу ISA кэшировать объекты с неопределенным временем изменения, так как сервер ISA все равно через некоторый период времени при наличии запроса заменит эту страницу на новую.
• Я бы не разрешил серверу ISA кэшировать динамические страницы. Я убедился, что вероятность получения динамической страницы из кэша чрезвычайно низка. К сожалению, динамические страницы составляют большую долю современных Web-потоков, так что отключение такого кэширования умаляет значимость сервера ISA как прокси-сервера. Но что делать… — это реалии современности.
• Я бы позволил серверу ISA возвращать кэшированные страницы, если требуемый Web-сервер оказался недоступным, убедившись, что страница не хранится в кэше дольше 80% своего срока годности, и это время составляет не более 1440 минут. Моя теория состоит в том, что пользователю лучше увидеть немного устаревшую страницу, чем не увидеть ее вообще. Я думаю, большинство пользователей со мною согласится.

Сервер ISA имеет сложную конфигурацию сетевых подключений для каждого массива. В этом наборе параметров определяется, как сервер ISA распределяет запросы от клиентов. Он может дозваниваться вашему ISP, маршрутизировать информацию по VPN, и т.п. Эти правила позволяют серверу ISA обслуживать множество сетевых подключений. Более подробно они описаны в документации по серверу ISA.

В заключение, существует окно фильтрации пакетов для массива серверов ISA. Эти фильтры перехватывают практически все, что проходит через массив серверов ISA, пропуская или отсекая определенные типы пакетов. Здесь можно задать такую конфигурацию, когда определенные типы пакетов будут обрабатываться конкретными членами массива. Можно также разрешить всем членам массива обрабатывать все пакеты. В этом окне предоставлен доступ к функции Secure Your ISA Server Computer, уже описанной ранее в этой главе, а также к функции выявления атак на компьютер ISA.

Оптимизация производительности сервера ISA

Оптимизировать сервер ISA не сложно. В общем случае достаточно убедиться, что сервер оснащен высококлассными скоростными сетевыми адаптерами с драйверами, сертифицированными компанией Microsoft для вашей операционной системы (Windows 2000 или Windows .NET). Также лучше разместить кэш на высокоскоростных дисковых массивах, желательно сконфигурированных в массив RAID-5, обеспечивающий наивысшую пропускную способность. В заключение, можно оснастить компьютер сервера ISA одним-двумя высокоскоростными процессорами и максимумом памяти, который способна принять данная материнская плата. Если один сервер ISA даже с таким оснащением стал перегруженным, добавьте к нему еще один. Преимущество использования сервера ISA в домене Active Directory состоит в возможности конфигурирования кэш-массивов и кэш-цепочек, позволяющих распределить нагрузку среди нескольких серверов.

Операции восстановления при сбоях

Резервирование сервера ISA выполняется в том же режиме, что и для любого другого сервера приложений Windows. В основном нас интересует только состояние системы. Даже не пытайтесь создавать резервную копию кэша: за время, которое вы потратите на его восстановление, он уже устареет, и сервер ISA все равно его не будет брать в расчет. Лучше сосредоточьтесь на состоянии системы (в том числе и на реестре), и убедитесь, что домен Active Directory толерантен к сбоям (это обычно достигается за счет наличия нескольких контроллеров домена). В корпоративной среде большая часть критичной информации конфигурации сервера ISA все равно содержится в домене Active Directory, так что защите Active Directory от сбоя следует уделить основное внимание. Когда наступает время для создания резервной копии — используйте любое подходящее приложение согласно своему вкусу (Windows Backup или утилиту стороннего производителя).

Советы профессионалов по администрированию

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

• Применяйте настолько, насколько возможно, корпоративную политику. Если политика пропускной способности не может быть внедрена на уровне предприятия, вынесите ее на уровень массивов. Это позволит более просто решать проблемы доступа, так как все правила будут находиться в едином месте.
• Для элементов и правил политики используйте описательные имена, и педантично документируйте то, что они собой представляют. Это простое действие поможет в дальнейшем быстро решать любые проблемы доступа, не требуя дополнительного времени на выяснение того, чему посвящено каждое из правил.
• Устанавливайте поддержку клиента сервера ISA на компьютерах с операционной системой Windows. Это требуется для предоставления возможности установки на сервере ISA более робастных элементов политики, например, для создания множеств клиентов, основанных на учетных записях и группах. Клиент Firewall Client загружает с сервера ISA таблицу LAT, и не обращается к серверу ISA для работы с локальными адресами, поэтому никакого влияния на внутрисетевые потоки это не окажет.

Решение проблем

Комбинирование правил

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

То, как инициализировано предприятие, будет определять то, как политики массива будут влиять на политики предприятия. Сочетание этих двух политик может быть запутанным. Для примера предположим, что существует некоторое корпоративное правило, позволяющее использование протокола AOL Instant Messenger. Один из ваших удаленных офисов имеет массив серверов ISA, который блокирует этот протокол. Сам массив этого офиса сконфигурирован в цепочке с массивом серверов ISA главного офиса, на котором используется только корпоративные политики. Предприятие было инициализировано для разрешения установки на уровне массивов таких политик, которые ограничивают корпоративные политики. В результате в удаленном офисе будет блокирован протокол AOL Instant Messenger.

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

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

Резюме

Сервер ISA обладает мощными способностями прокси-сервера и брандмауэра, которые можно сконфигурировать так, чтобы они наиболее полно обеспечивали конкретные потребности предприятия. Комбинируя различные элементы политик в правила, можно настроить доступ; а комбинируя параметры кэша, можно настроить сервер ISA так, чтобы качество обслуживания клиентов было максимально высоким.