IIS 7.5 Solicitar logs de filtragem versus UrlScan 3.1

Question

Quando o IIS 7.5 Request Filtering bloqueia uma solicitação, parece adicionar uma entrada nos logs da Web regulares do IIS com um 404.

a) Existe alguma maneira de enviar os logs detalhados de Filtragem de Pedidos para um arquivo separado? O UrlScan pode especificar o LoggingDirectory e manter esse "ruído" fora dos nossos logs reais do IIS

b) Além disso, há uma maneira de obter mais informações de que a Solicitação de Filtragem bloqueou uma solicitação? O UrlScan registrou a regra que causou a negação, bem como o controle sobre um redirecionamento usando RejectResponseUrl, que era especialmente conveniente em sites que não eram de produção.

c) Se esses recursos forem importantes, a prática recomendada é ainda instalar o UrlScan 3.1 no IIS 7.5 (Windows 2008 R2) e desabilitar a Filtragem de Solicitações?

Qualquer orientação é apreciada.

    

Answer 1

É perfeitamente aceitável usar o URLScan em vez de Filtragem de Solicitações se você gostar mais dele. É até aceitável usar os dois ao mesmo tempo, tanto quanto eu sei. Eu acho que para os casos de uso que você fala, o URLScan pode ser mais fácil de configurar.

Para responder às suas perguntas específicas:

1. Solicitação de filtragem não possui registro separado. Usar a extensão do registro avançado (com seus recursos de filtragem) pode levá-lo até lá.
2. Acho que o nível mais baixo de granularidade que você pode obter é o subcódigo de erro. Tudo rejeitado pela Filtragem de Solicitação é um 404.x, em que X é o motivo pelo qual a Filtragem de Solicitação negou a solicitação. Esta página contém um gráfico dos motivos. Como tudo a partir da Filtragem de Solicitações é apenas um código de resposta 404.x, você pode usar os erros personalizados do IIS para substituir RejectResponseUrl.
3. Já respondi acima.