В этом разделе описывается порядок планирования фильтрации HTTP, что позволяет обеспечить защиту от угроз при просмотре веб-страниц за счет проверки содержимого, передаваемого через Forefront TMG.
 Примечание. |
|---|
| В этом разделе также описываются параметры, необходимые для настройки блокировки заголовков и URL-адресов в политике HTTP для правила. См. раздел HTTP filtering settings overview ниже. |
Forefront TMG предоставляет возможность настраиваемого контроля HTTP-трафика в форме фильтра HTTP. Фильтр HTTP на уровне приложения проверяет HTTP-команды и данные, проходящие через компьютер Forefront TMG, и пропускает только совместимые запросы. Благодаря тому, что серверы отвечают только на допустимые запросы, значительно повышается безопасность веб-серверов и обеспечивается управление доступом клиентов в Интернет.
Фильтрацию HTTP можно применять в следующих сценариях:
- Доступ внутренних клиентов к HTTP-объектам
(страницам и изображениям HTML либо другим данным, которые могут
быть переданы по протоколу HTTP) в другой сети (обычно в Интернете)
через компьютер Forefront TMG управляется правилами доступа
Forefront TMG. Политику HTTP можно применить к каждому правилу
доступа посредством фильтра HTTP.
- Доступ внешних клиентов к HTTP-объектам на
веб-сервере, опубликованном с помощью сервера Forefront TMG,
управляется правилами веб-публикации Forefront TMG. Политику HTTP
можно применить к каждому правилу веб-публикации посредством
фильтра HTTP.
Фильтрация HTTP зависит от правила: для каждого конкретного правила можно настроить свои условия фильтрации. Например, можно использовать фильтрацию HTTP для блокировки определенной одноранговой службы общего доступа к файлам для одного списка пользователей, но разрешить эту службу для другого списка. Когда содержимое блокируется параметром фильтра HTTP в правиле, происходит ошибка «502 Ошибка прокси-сервера», и пользователь получает сообщение «Запрос был отклонен фильтром HTTP».
Настройка политики фильтрации HTTP для правила включает следующие этапы:
- Установка максимального размера в байтах для
заголовка, полезных данных, URL-адреса или запроса, а также
запросов на блокировку URL-адресов, содержащих определенные знаки.
Описание параметров, необходимых для настройки блокировки
заголовков и URL-адресов в политике HTTP см. в разделе HTTP filtering settings overview.
- Блокировка определенных HTTP-методов
(команд). HTTP-методы (также называются HTTP-командами)
представляют собой инструкции, отправляемые в сообщении запроса,
уведомляющего HTTP-сервер о действии, которое необходимо выполнить
с указанным ресурсом. В качестве примера блокировки можно привести
блокировку метода POST, при которой внутренние клиенты не могут
размещать данные на внешней веб-странице. Это очень удобно для
безопасных сетевых сценариев, когда требуется предотвратить
размещение на веб-сайте важной информации. Также такая блокировка
удобна при веб-публикации: она позволяет предотвратить размещение
злоумышленниками вредоносного материала на веб-сайте.
- Блокировка отдельных расширений — можно
разрешить все или только определенные расширения. Рекомендуется
разрешать только выбранные расширения, так как это наиболее
безопасная конфигурация. Например, при публикации веб-сайта
разработчик этого сайта или администратор веб-сервера могут
определить список расширений, необходимых для нормального
функционирования сайта. Чаще всего блокировка расширений
используется для блокировки исполняемых (.exe) файлов.
- Блокировка определенных HTTP-заголовков.
- Блокировка отдельных сигнатур в заголовках
или теле запроса.
Общие сведения о параметрах фильтрации HTTP
В следующей таблице представлены сведения о более сложных параметрах, необходимых для настройки блокировки заголовков и URL-адресов в политике HTTP для правила.
| Параметр | Описание |
|---|---|
|
Максимальная длина заголовка (байт) |
Этот параметр применяется ко всем правилам, то есть его изменение в одном правиле отражается на всех остальных правилах. Уменьшение допустимого размера заголовка снижает риск атак, требующих длинных и сложных заголовков, таких как атаки переполнения буфера и некоторые атаки типа "отказ в обслуживании". Обратите внимание, что при установке слишком малого значения максимальной длины заголовка могут пострадать некоторые надежные приложения, использующие длинные заголовки. Рекомендуется сначала установить ограничение в 10 000 байт и увеличивать его только в том случае, если будут блокироваться надежные приложения. |
|
Разрешить любую длину полезных данных |
Ограничение полезных данных запроса приведет к уменьшению объема данных, который пользователь может разместить на данном веб-сайте в сценарии веб-публикации. Чтобы определить необходимое ограничение, оцените максимальный размер файла для допустимого сообщения, основываясь на данных по использованию узла, и укажите это значение в качестве допустимой длины полезных данных. При этом любое сообщение, длина которого превышает указанное значение, будет рассматриваться как потенциальная атака. |
|
Максимальная длина запроса (байт) |
Запрос — это часть URL-адреса, следующая после вопросительного знака (?). Если были выявлены случаи атак на основе длинных строк запросов, можно ограничить допустимую длину запроса. По умолчанию максимальная длина запроса составляет 10 240. Длинные запросы и URL-адреса являются известными векторами атаки для вирусов-червей в Интернете. Эти вирусы отправляют длинный запрос GET и используют URL для внедрения своих полезных данных. |
|
Проверять нормализацию |
Веб-серверы получают URL-закодированные запросы. Это означает, что определенные знаки могут быть заменены знаком процента (%) с последующим числом. Например, "%20" соответствует пробелу, следовательно, запрос на сайт http://myserver/My%20Dir/My%20File.htm полностью аналогичен запросу на сайт http://myserver/My Dir/My File.htm. Нормализация — это процесс декодирования URL-закодированных запросов. Поскольку знак % может быть URL-закодирован, атакующий может отправить на сервер тщательно подготовленный запрос, изначально обработанный двойной кодировкой. В этом случае службы веб-сервер может принять запрос, который иначе был бы отклонен как недопустимый. При выборе параметра "Проверять нормализацию" фильтр HTTP нормализует URL-адрес дважды. Если URL-адрес после второй нормализации отличается от URL-адреса после первой нормализации, фильтр отклоняет запрос. Это позволяет избежать атак на основе запросов с двойной кодировкой. |
|
Блокировать символы расширенного набора |
Чаще всего это символы из языков, в которых недостаточно 8 бит для представления знаков языка, и поэтому используется 16-битное представление. Например, URL-адреса, содержащие символы из двухбайтового набора (DBCS) или набора Латиница-1, будут блокироваться. Это позволяет блокировать некоторые атаки, однако при этом также могут оказаться заблокированными запросы и ответы, содержащие символы одного из нескольких языков, требующих расширенного набора знаков. Параметр "Блокировать символы расширенного набора" может отразиться на таких сценариях, как публикация веб-клиента Outlook, публикация сервера Microsoft Windows SharePoint Portal Server, и любом другом сценарии, в котором запрос GET передает параметр, включающий символ из двухбайтового набора. |
|
Заголовок VIA |
Заголовки VIA позволяют включить прокси-серверы, содержащиеся в пути запроса, также и в путь ответа. Каждый сервер в пути запроса может добавить собственный заголовок VIA. Каждый отправитель в пути ответа удаляет собственный заголовок VIA и пересылает ответ на сервер, указанный в следующем заголовке VIA в стеке. Например, эту функцию можно использовать, чтобы предотвратить разглашение имени сервера Forefront TMG в ответе. |