O UrlScan versão 2.5 é uma ferramenta de segurança que restringe
determinados tipos de requisições HTTP processadas pelo Internet Information
Services (IIS). Através do bloqueio de requisições HTTP específicas, a
ferramenta de segurança UrlScan pode ajudá-lo a prevenir que requisições
potencialmente prejudiciais cheguem ao servidor. O UrlScan versão 2.5 agora é
instalado em servidores executando o IIS 4.0 ou superior.
Este artigo inclui as seguintes informações: Novos recursos do UrlScan 2.5 A Microsoft relançou a versão 2.5 da ferramenta de segurança UrlScan com um novo
instalador do UrlScan 2.5, para computadores executando o IIS 4.0 e superior.
Importante: Apesar do UrlScan 2.5 ajudar a proteger
seus servidores contra ataques, você sempre deve avaliar e aplicar as últimas
atualizações de segurança da Microsoft. Conforme novas vulnerabilidades são
descobertas, a Microsoft publica atualizações como Service Packs e correções.
Para atenuar qualquer risco presentes nestas vulnerabilidades, você precisa
aplicar estas atualizações de segurança conforme forem disponibilizadas.
A ferramenta UrlScan utiliza dois arquivos — UrlScan.dll e UrlScan.ini — que são
empacotadas juntas no arquivo UrlScan.exe. Esta última atualização do UrlScan
2.5 garante aos administradores ainda mais controle sobre as configurações e
possui recursos que auxiliam os administradores a aumentar a segurança e
"fechar" seus servidores.
O UrlScan 2.5 introduz os seguintes recursos, que não estavam disponíveis em
versões anteriores:
Alteração da pasta de armazenamento dos logs A opção LoggingDirectory é utilizada para especificar a pasta que
armazena o arquivo de log. Este valor deve refletir o caminho absoluto (por
exemplo, C:\LOGS) da pasta que armazena o arquivo de log. Se você não
especificar uma pasta, a ferramenta criará o arquivo de log na mesma pasta que
contém o arquivo UrlScan.dll.
A opção LogLongUrls foi acrescentada para permitir o aumento do
comprimento das URLs que são registradas. Em versões anteriores, o UrlScan
truncava as linhas do log em 1024 bytes. A nova opção permite uma melhora nos
registros aumentando este limite para 128 kilobytes (KB). Os valores permitidos
são 0 ou 1 e o valor padrão é 0. Se a opção LogLongUrls for alterada
para 1, então o UrlScan irá registrar até 128 KB por requisição. Se o valor for
mantido em 0, então as entradas no log irão conter apenas os primeiros 1024
bytes.
A seção RequestLimits foi adicionada para que a ferramenta possa forçar
limites no tamanho, em bytes, de partes separadas das requisições que chegam ao
servidor. A seção RequestLimits inclui as seguintes entradas:
- MaxAllowedContentLength:Força o valor máximo para o comprimento do conteúdo. Ela não previne
necessariamente o servidor de ler mais dados do que o valor especificado. Por
exemplo, se um cliente faz uma transferência codificada através de um POST,
esta opção da ferramenta UrlScan não é efetiva em mapear o tamanho da entidade
na requisição. O valor padrão é 2 GB (2,000,000,000 bytes).
- MaxUrl: Restringe o comprimento da URL na requisição, em bytes, mas não
restringe o comprimento da string de consulta (query string). Ao atualizar a
ferramenta utilizando o instalador, o valor padrão é de 16 KB.
Nota: Se você extrair manualmente os arquivos UrlScan.dll do executável UrlScan.exe e
não atualizar o arquivo UrlScan.ini, a configuração padrão será de 260 bytes.
Neste caso, você deverá adicionar o parâmetro MaxUrl = 16384 no arquivo
UrlScan.ini para sobreescrever a configuração padrão.
- MaxQueryString: Restringe o comprimento da string de consulta (query
string), em bytes. O valor padrão é 4 KB.
Você pode impor um limite, em bytes, no tamanho de um cabeçalho de requisição
específico através do prefixo Max- no nome de um cabeçalho. Por exemplo,
a seguinte entrada impõe um limite de 100 bytes no cabeçalho "Content-Type":
Max-Content-Type=100. Para listar um cabeçalho sem especificar um valor máximo,
utilize o valor 0. Por exemplo, Max-User-Agent=0. Os cabeçalhos que não forem
listados na seção RequestLimits não terão verificados seus limites nos
comprimentos.
O Microsoft® Windows Server™ 2003 possui muitos recursos nativos que ajudam a
tornar seguro servidores com o IIS 6.0. A ferramenta UrlScan fornece algumas
funcionalidades adicionais, como controle de verbos além do fornecido pelo IIS
6.0. Além disso, algumas empresas integraram recursos do UrlScan em suas
práticas de gerenciamento de servidores IIS e outros servidores Microsoft. Se
você quiser utilizar as funcionalidades adicionais do UrlScan 2.5 ou
simplesmente manter seus procedimentos gerenciais de segurança, considere então
a instalação e o uso do UrlScan com o IIS 6.0.
O UrlScan 2.5 não está incluído no IIS 6.0 porque o IIS 6.0 possui recursos
nativos que fornecem funcionalidades de segurança iguais ou superiores aos
recursos do UrlScan 2.5. A Tabela 1 mostra como os recursos do IIS 6.0 e o
UrlScan 2.5 tratam certas questões de segurança. Leia a comparação para uma
melhor decisão sobre a instalação do UrlScan 2.5 em seus servidores que
executam o IIS 6.0.
Tabela 1: Recursos do UrlScan 2.5 comparados aos recursos nativos do IIS 6.0
| Recurso do UrlScan 2.5 | Capacidade nativa do IIS 6.0 | | DenyExtensions: Este recurso foi implementado no UrlScan
para limitar a superfície de ataque do servidor através da prevenção, baseado
na extensão do arquivo, de requisições específicas executarem código ISAPI ou
CGI no servidor.
| O IIS 6.0 limita a superfície de ataque do servidor através da
possibilidade de administradores especificarem o código ISAPI ou CGI que pode
ser executado no servidor. Como o IIS 6.0 especifica o código diretamente, não
é necessário saber qual é a extensão do arquivo na URL que está invocando o
código. |
| DenyVerbs: Código WebDAV pode ser invocado em um servidor
Web baseado no uso de verbos HTTP específicos. Este recurso foi implementada no
UrlScan para limitar a superfície de ataque do servidor através da prevenção de
requisições que invocam o WebDAV. |
O IIS 6.0 permite que administradores habilitarem ou desabilitarem
explicitamente o WebDAV. Como esta ação afeta diretamente o código WebDAV, não
é necessário inspecionar os verbos HTTP que são associados a cada requisição. |
| DenyHeaders: Código WebDAV pode ser invocado em um servidor
Web baseado no uso de verbos HTTP específicos. Este recurso foi implementada no
UrlScan para limitar a superfície de ataque do servidor através da prevenção de
requisições que invocam o WebDAV. |
O IIS 6.0 permite que administradores habilitarem ou desabilitarem
explicitamente o WebDAV. Como esta ação afeta diretamente o código WebDAV, não
é necessário inspecionar os verbos HTTP que são associados a cada requisição. |
NormalizeUrlBeforeScan: Este recurso permite que
administradores especifiquem quando o IIS irá processar URLs mal escritas
enviadas pelo cliente ou URLs canônicas processadas pelo servidor.
Nota: Não é um procedimento
prático definir este valor para 0 em um servidor em produção. Ao definir um
valor 0, todas as extensões de arquivos e outras URLs definidas no arquivo
UrlScan.ini precisam especificar todos os possíveis codificadores para cada
caracter. O número de permutações resultantes torna virtualmente impossível o
gerenciamento em um servidor em produção. |
O mecanismo restritivo, nativo no IIS 6.0, é baseado no código
executável que é permitido - não é baseado na URL que o cliente solicita. Por
esta razão, o recurso NormalizeUrlBeforeScan não é necessário no IIS
6.0.
| | VerifyNormalization: O UrlScan foi criado para ser
executado em várias versões do IIS. O código que trata URLs canônicas pode ser
melhorado com versões mais recentes e Service Packs no IIS. Este recurso
permite ao UrlScan detectar limitações em potencial relativas a URLs canônicas
em sistemas sem as atualizações. |
O componente HTTP.SYS utilizado no IIS 6.0 teve o tratamento de
código canônico especialmente escrito para ajudar na proteção contra estes
tipos de ataques.
| | DenyUrlSequences: Este recurso foi implementado no UrlScan
para permitir que a ferramenta detecte sequências que são utilizadas em ataques
baseados em URLs no servidor Web. |
No IIS 6.0 não é necessário negar sequências nas URLs. Por design,
o IIS 6.0 não é susceptível a ataques baseados em URLs que utilizam as
sequências de caracteres listadas na seção DenyUrlSequences padrão do
arquivo UrlScan.ini fornecido pela Microsoft.
| | AllowDotInPath: O mecanismo restritivo do UrlScan depende
de uma notificação no filtro, que ocorre no início do processamento de uma
requisição. Neste momento, a ferramenta UrlScan não consegue identificar com
certeza como o IIS processa a URL para o parâmetro PATH_INFO. É possível que o
parâmetro PATH_INFO afete a extensão do arquivo na URL. Definindo AllowDotInPath
para 0 irá causar a rejeição de qualquer requisição quando a extensão do
arquivo for ambígua devido a uma condição de ponto no caminho ("dot in path"). |
O recurso AllowDotInPath não é necessário no IIS 6.0 porque
o IIS 6.0 não depende de notificações do filtro para seu mecanismo de
restrições ("lockdown"). |
| RemoveServerHeader: Este recurso permite ao UrlScan remover
ou alterar a identidade do servidor a partir do cabeçalho de resposta "Server"
ao cliente. |
O IIS 6.0 não inclui o recurso RemoveServerHeader porque
este recurso não oferece um benefício real de segurança. A maioria dos ataques
não são específicos quanto ao sistema operacional. Ainda, é possível detectar a
identidade do servidor e informações sobre o sistema operacional através de
mecanismos que não dependam do cabeçalho do servidor. |
| EnableLogging, PerProcessLogging e PerDayLogging:O UrlScan não faz parte do núcleo do servidor IIS. Por isso, a ferramenta
utiliza um utilitário adicional que produz seu próprio arquivo de log. Estas
configurações controlam como a ferramenta produz e nomeia seus arquivos de log. |
O IIS 6.0 registra todas as atividades restritivas nos logs do
serviço W3SVC. Requisições que são rejeitadas devido a restrições ou código
executável são identificadas como erros 404 e sub-erros 2 (404.2) nos logs.
Requisições para arquivos estáticos que são rejeitados devido a serem de tipo
desconhecido são identificadas como erros 404 e sub-erros 3 (404.3). |
| AllowLateScanning: Este recurso permite que administradores
especifiquem quando a ferramenta deve examinar as URLs: antes ou depois de
outros filtros. Existem vários filtros que modificam as URLs e pode ser
indesejável que a ferramenta examine a URL depois dela ser modificada. O filtro
da Extensões de Servidor do FrontPage é um exemplo de filtro que modifica a
URL. |
O recurso AllowLateScanning não é necessário no IIS 6.0
porque o IIS 6.0 não depende de notificações de filtros para seu mecanismo
restritivo. Este mecanismo nativo do IIS 6.0 é baseado no código executável que
pode ter sua execução permitida e não na URL que o cliente solicita.
| | RejectResponseUrl: Este recurso trabalha em conjunto com
o UseFastPathReject. Se o recurso UseFastPathReject for
definido para 0, então as requisições rejeitadas serão mapeadas para a URL
especificada neste parâmetro RejectResponseUrl. Se a URL especificada
não existir, o cliente irá receber uma resposta 404 normal, como se o cliente
tivesse solicitado uma página inexistente. Se a URL existir, o servidor irá
customizar a resposta que será enviada ao cliente. |
No IIS 6.0, uma requisição que é rejeitada devido a uma restrição
de um código executável gera um erro customizado 404.2. Um arquivo estático
rejeitado devido a um tipo MIME desconhecido irá gerar um erro customizado
404.3. Os administradores podem utilizar o mecanismo de customização de erros
do IIS para controlar estas respostas. |
| UseFastPathReject: O mecanismo de restrições do UrlScan
depende de uma notificação do filtro que ocorre no início do processamento da
requisição. Como resultado, se a ferramenta rejeita a requisição diretamente, a
resposta 404 não pode ser gerada. Portanto, o cliente recebe uma resposta 404
não amigável em vez de um erro customizado que normalmente ocorre. Se o
parâmetro UseFastPathReject for definido para 0, a ferramenta UrlScan
irá remapear a requisição para a URL especificada no parâmetro RejectResponseUrl. |
O mecanismo de restrições do IIS 6.0 não depende das notificações
do filtro. Uma requisição que for rejeitada devido a um código executável
restrito gera um erro customizado 404.2. Um arquivo estático rejeitado devido a
um tipo MIME desconhecido gera um erro customizado 404.3. Os administradores
podem utilizar o mecanismo de customização de erros do IIS para controlar estas
respostas. |
| AllowHighBitCharacters: Este recurso permite que a
ferramenta detecte caracteres não ASCII nas URLs. |
A faixa de caracteres permitidas é tratada pelo componente
HTTP.SYS. Este valor pode ser alterado através da modificação da seguinte chave
do registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\EnableNonUTF8
Cuidado: Editar incorretamente
o registro pode causar sérios danos ao sistema. Antes de alterar o registro,
você deve fazer um backup do mesmo. |
| MaxAllowedContentLength: Este recurso permite que a
ferramenta UrlScan imponha limites no tamanho das requisições que são feitas ao
servidor. |
O IIS 6.0 possui capacidade nativa de limitar o tamanho das
requisições. Este recurso é configurado através das propriedades MaxRequestEntityAllowed
e ASPMaxRequestEntityAllowed da metabase. |
| MaxUrl, MaxQueryString, e MaxHeader: Estes
parâmetros permitem ao UrlScan impor limites no tamanho das URLs, strings de
consulta e cabeçalhos específicos que são enviados ao servidor. |
O componente HTTP.SYS utilizado pelo IIS 6.0 permite que limites
de tamanho possam ser definidos em várias partes da requisição. Os valores
podem ser alterados modificando-se os parâmetros AllowRestrictedChars, MaxFieldLength,
UrlSegmentMaxLength e UrlSegmentMaxCount nas seguintes chaves do
registro:
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\AllowRestrictedChars
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\MaxFieldLength
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\UrlSegmentMaxLength
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\UrlSegmentMaxCount
Cuidado: Editar incorretamente o
registro pode causar sérios danos ao sistema. Antes de alterar o registro, você
deve fazer um backup do mesmo.
| Por que a ferramenta UrlScan foi disponibilizada também para o IIS 6.0 ?
Esta ferramenta fornece um pequeno nível de funcionalidades adicionais em
relação ao que o IIS 6.0 fornece. O UrlScan é uma ferramenta flexível que os
clientes podem utilizar para propósitos não cobertos neste artigo. Algumas
empresas integraram a ferramenta UrlScan nas suas práticas de gerenciamento dos
servidores IIS e outros servidores Microsoft. Por estas razões, alguns clientes
podem desejar instalar o UrlScan 2.5, utilizando-o no IIS 6.0.
Para maiores informações sobre o UrlScan 2.5, leia o artigo 307608 do Microsoft
Knowledge Base ,
Utilizando o UrlScan no IIS (site em inglês).
O UrlScan 2.5 é instalado em computadores executando o IIS 4.0 ou superior.
Cenários de atualizações também são suportados.
Para instalar o UrlScan 2.5- Faça o download do arquivo Setup.exedo UrlScan 2.5.
- Clique duas vezes no arquivo Setup.exe.
- Analise as condições de uso do produto, em UrlScan Installer Package End User
Agreement e clique em Yes para aceitar as condições. Se você
clicar em No, o instalador será encerrado.
- Quando a instalação terminar, a seguinte mensagem será visualizada: "UrlScan has
been successfully installed." Clique em OK para fechar o
instalador.
Para desintalar o UrlScan 2.5- No Painel de Controle, clique duas vezes em Adicionar ou Remover Programas.
- Selecione UrlScan 2.5 e clique em Alterar/Remover.
- Quando a ferramenta UrlScan 2.5 for removida do servidor, a seguinte mensagem
será visualizada: "UrlScan has been successfully uninstalled." Clique em OK
para completar o processo de desinstalação.
Entendendo o instalador do UrlScan 2.5Ao instalar o UrlScan 2.5, o instalador do UrlScan 2.5 executa as seguintes
ações:
- Instala os arquivos UrlScan.dll e UrlScan.ini em
%windir%\system32\inetsrv\urlscan. Se a ferramenta já estiver instalada no
computador, o arquivo UrlScan.ini é atualizado com todas as configurações que
não estiverem presentes na configuração atual.
- Adiciona o UrlScan como um filtro global no IIS.
Ao instalar o UrlScan em um servidor que executa o IIS 6.0, o instalador do
UrlScan 2.5 faz algumas alterações adicionais, permitindo que a ferramenta
trabalhe no novo modelo de processos do IIS 6.0. Estas alterações são as
seguintes:
- O parâmetro PerProcessLoggingé definido para 1 no arquivo UrlScan.ini. Isto garante que dois processos do
UrlScan não escrevam no arquivo de log ao mesmo tempo.
- O UrlScan é marcado como compatível com cache na metabase. Isto garante que
dois ou mais processos que executem o UrlScan não escrevam no arquivo de log ao
mesmo tempo.
- Uma nova subpasta de log, localizado na pasta ..\inetsrv\urlscan é criada. Isto
garante que a pasta do UrlScan não seja confundida com todos os arquivos de log
que a opção PerProcessLogging irá criar.
Ao instalar o UrlScan 2.5 no IIS, o instalador definirá permissões para os
arquivos UrlScan.dll, UrlScan.ini e o arquivo de log. Ao instalar o UrlScan 2.5
no IIS 6.0, o instalador definirá permissões adicionais nos mesmos arquivos
para permitir que o UrlScan 2.5 trabalhe com o modo de processos isolados do
IIS 6.0. A Tabela 2 lista as permissões do IIS que são definidas quando o
UrlScan 2.5 é instalado.
Tabela 2: Permissões do IIS 6.0 para o UrlScan 2.5
| Arquivo/Pasta | Permissões | | ..\inetsrv\urlscan\urlscan.dll
| Leitura e escrita (definido no IIS 6.0 apenas):
Serviço Local, IIS_WPG e Serviço de Rede
Controle total: Administradores e Sistema Local |
| ..\inetsrv\urlscan\urlscan.ini | Leitura (definido no IIS 6.0 apenas): Serviço Local,
IIS_WPG e Serviço de Rede
Controle total: Administradores e Sistema Local |
| ..\inetsrv\urlscan\logs | Leitura e escrita (definido no IIS 6.0 apenas):
Serviço Local, IIS_WPG e Serviço de Rede
Controle total: Administradores e Sistema Local |
Se uma versão do UrlScan for detectada no computador, a instalação será
considerada uma atualização. Em um cenário de atualização, as alterações que o
instalador faz serão as mesmas de uma instalação nova a menos que você tenha
configurado uma pasta customizada para os logs. Se você definiu um local
diferente para o armazenamento dos logs, então as novas pastas de logs não
serão criadas.
Clique em uma das questões a seguir:
Pergunta: O que é o UrlScan?
Resposta: O UrlScan é uma ferramenta de segurança que
analisa todas as requisições ao servidor, filtrando-as a partir de regras
definidas pelo administrador. A filtragem de requisições ajuda a tornar o
servidor mais seguro, porque a maioria dos ataques maliciosos compartilham uma
característica comum - elas involvem o uso de requisições não usuais. Por
exemplo, a requisição pode ser extremamente longa, solicitar uma ação não
usual, ser codificada utilizando um conjunto de caracteres alternativos ou
incluir sequências de caracteres que são raramente vistos em solicitações
legítimas. Através desta filtragem, a ferramenta ajuda a prevenir que estas
requisições cheguem ao servidor e potencialmente causem danos.
Pergunta: O UrlScan 2.5 trabalha junto com o IIS 6.0?
Resposta:Sim. O UrlScan 2.5 é a única versão do UrlScan suportada pela Microsoft para
uso no IIS 6.0.
Pergunta: Eu já utilizo o UrlScan 2.0. Por que
eu devo fazer o download desta atualização?
Resposta:O UrlScan 2.5 inclui novos recursos que podem ser adicionados para aumentar a
segurança dos servidores que executam o IIS. Estes novos recursos incluem:
Pergunta: Eu já configurei o UrlScan em meu site.
O UrlScan 2.5 irá sobreescrever minhas configurações atuais?
Resposta:Não. O instalador adiciona apenas novas entradas a seu arquivo de
configurações. A ferramenta suporta todas as configurações presentes nas
versões anteriores.
Pergunta: Se o UrlScan 2.5 ajuda a proteger
meu servidor contra certas vulnerabilidades, é necessário que eu aplique as
atualizações de segurança?
Resposta:Sim. Para ajudar a proteger seu servidor contra novas e existentes
vulnerabilidades de segurança, a Microsoft recomenda fortemente que você avalie
e instale as últimas atualizações de segurança assim que elas sejam
disponibilizadas.
Pergunta: Eu não tenho certeza se utilizo
transferências codificadas ("chunked-transfer encoding") em minhas
aplicações. O que é isto?
Resposta:Transferência codificada (ou chunked-transfer encoding) é um recurso
presente no HTTP/1.1 que transmite o corpo da mensagem em uma requisição
ou resposta como pacotes que possuem a informação relativa a seu tamanho. O
HTTP 1.1 permite que clientes enviem requisições POST utilizando este tipo de
transferência. Na maioria dos casos, o IIS irá automaticamente decodificar
estas requisições antes que elas sejam processadas. Se o tamanho da requisição
exceder um limite específico (por padrão 48KB) o código ISAPI ou CGI a qual a
requisição é direcionada precisa conhecer este tipo de transferência para
processar a requisição corretamente. Se você possui código em um servidor que
recebe requisições POST e não tem certeza que ele suporte transferências
codificadas, então considere utilizar o UrlScan para proibir requisições que
incluam o cabeçalho "Transfer-Encoding". Para maiores informações sobre
transferências codificadas, leia a seção 3.6.1 da
RFC 2616 (site em inglês),
"Hypertext Transfer Protocol — HTTP/1.1."
|