Alterações na segurança entre o IIS 6.0 e o IIS 7 e posterior

Artigo
03/08/2024

pela equipe do IIS

Introdução

O IIS 7 e posterior traz vários aprimoramentos de segurança em relação ao IIS 6.0. Este documento apresenta esses aprimoramentos em relação à autenticação, à autorização, ao SSL, à lista de restrições de extensão do serviço Web e às restrições de IP.

Autenticação

No caso dos desenvolvedores de aplicativos ASP.NET, antes do IIS 7, havia dois modelos de autenticação nos quais você precisava programar. Esses modelos eram os pipelines do IIS e do ASP.NET. Primeiro, o IIS examinava a solicitação e executava as rotinas de autenticação e, em seguida, a transmitia para o ASP.NET, de modo que ele pudesse realizar uma tarefa semelhante.

No IIS 7 e posterior, unificamos esses dois modelos para produzir um novo pipeline robusto que faz o melhor que os dois modelos mais antigos faziam. O IIS ainda dá suporte a todos os protocolos de autenticação antigos, mas agora também dá suporte à autenticação de formulários que pode proteger contra todos os tipos de conteúdo e não depende de contas do Windows. Além de dar suporte a todos os recursos antigos que você já conhece e adora, também aprimoramos alguns deles, como o recurso Autenticação Anônima.

Essas alterações serão discutidas nas próximas seções.

Alterações da Autenticação Anônima

No IIS 7 e posterior, a Autenticação Anônima se comporta de maneira semelhante à de versões anteriores, com apenas uma alteração: a capacidade de ser executada no conteúdo da identidade do processo de trabalho. Cada pool de aplicativos é configurado para ser executado no conteúdo de uma conta de usuário, e o valor padrão dessa conta é NETWORKSERVICE.

Era muito comum os aplicativos ASP.NET desativarem a representação e serem executados na identidade do pool de aplicativos por meio do seguinte código nos arquivos web.config:

<identity impersonate="false"/>

Há vários cenários em que os aplicativos precisavam ser executados no contexto da identidade do processo:

A identidade do processo é uma conta de baixo privilégio, e os administradores bloquearam os respectivos sistemas para essa conta
A identidade do processo recebeu acesso à rede e é usada para acessar recursos de back-end, como bancos de dados

Como parte da reformulação do IIS 7 e posterior, queríamos tornar esse cenário seguro e fácil de implementar. Para implementar esse cenário, no IIS, é necessário:

Instalar e habilitar o módulo de Autenticação Anônima
Definir o nome de usuário anônimo e a senha como uma cadeia de caracteres vazia

Para fazer isso, modifique a configuração da autenticação anônima para que ela apareça da seguinte maneira:

<anonymousAuthentication enabled="true" userName="" defaultLogonDomain="" />

Essa configuração instruirá o IIS a ser executado sempre no contexto da identidade do processo de trabalho.

Por padrão, a identidade de autenticação anônima no IIS 7.0 e posterior é a conta de IUSR. Essa conta é uma identidade de baixo privilégio com direitos e privilégios mínimos. Para saber mais sobre a nova conta interna, veja o artigo Noções básicas sobre a conta interna e o grupo no IIS 7 e posterior.

Alterações no Passport

O suporte para a autenticação herdada do Passport foi integrado ao IIS 5/6 e ao Windows Server 2000 e 2003. O suporte ao Passport no IIS 5 e 6 foi exposto como uma caixa de seleção na guia Segurança do Diretório no gerenciador de serviços do IIS em “Habilitar Autenticação do Passport”. Essa caixa de seleção fornecia ao IIS a capacidade de enviar desafios herdados do protocolo Tweener. Além disso, ainda era necessário registrar o site no portal de provisionamento do serviço Passport, obter uma chave de criptografia e configurar o Gerenciador do Passport herdado no servidor para que a integração do IIS funcionasse.

No Windows Server 2008 e posterior, os binários herdados do Passport e a integração ao IIS foram removidos.

Desde então, o serviço Passport passou a se chamar Windows Live ID. Embora o novo serviço Live ID certamente tenha se expandido do serviço Passport herdado, há alterações importantes. Uma das maiores alterações é como um site de parceiro se integra ao Live ID. Você pode adicionar a autenticação do Live ID usando o SDK de Autenticação da Web do Windows Live ID disponível publicamente. Embora o serviço Windows Live ID também dê suporte à federação de Identidade e ao ADFS, essa é uma nova funcionalidade para casos específicos e não é uma substituição do “Passport”.

Autenticação de formulários

A autenticação de formulários é integrada ao ASP.NET e permite que identidades do Windows e identidades que não são do Windows se autentiquem e obtenham um objeto de usuário que os aplicativos possam usar posteriormente. O IIS 7 e posterior já dá suporte completo à autenticação de formulários e pode ser configurado para proteger o acesso a todos os tipos de conteúdo.

Como o IIS 7 e posterior determina a identidade autenticada

No IIS 7 e posterior, as regras de autenticação são processadas pelo mecanismo principal, de maneira semelhante à que eram em versões anteriores do IIS, com apenas algumas pequenas alterações. Para entender melhor a ordem de processamento, aqui estão as regras com base na ordem que o IIS as avalia:

Primeiro, o IIS determina se um nome de usuário e uma senha foram configurados no diretório virtual. Se um conjunto de credenciais tiver sido definido, essas credenciais serão usadas. Para os administradores anteriores ao IIS 7, essas credenciais são as credenciais UNC
Se nenhuma credencial estiver configurada no diretório virtual, o IIS usará as credenciais fornecidas durante a autenticação. Essas credenciais podem pertencer à identidade configurada para autenticação anônima ou às credenciais fornecidas pelo usuário durante o handshake de autenticação quando a autenticação Básica, Digest ou do Windows está habilitada
Se nenhum usuário autenticado tiver sido estabelecido (por exemplo, a autenticação de formulários está habilitada), determinaremos se a identidade do processo deve ser usada
Se não tivermos uma identidade neste momento, o IIS retornará uma mensagem de acesso negado

Autorização

Suporte ao AzMan

No IIS 6.0, introduzimos um novo modelo de autorização baseado nas regras do AZMan. No IIS 7 e posterior, preterimos esse recurso em favor de um novo modelo muito semelhante ao modelo de autorização do ASP.NET (confira o tópico de autorização de URL abaixo).

Autorização de URL

No IIS 7 e posterior, você tem duas soluções de autorização. A primeira é usar o modelo de autorização do ASP.NET. Esse método exige a definição de todas as regras de autorização na configuração <system.web> e nenhuma alteração para os aplicativos que já têm regras escritas para o ASP.NET. O segundo modelo é migrar para a nova arquitetura de autorização do IIS. Esse modelo é muito semelhante ao modelo do ASP.NET, com algumas pequenas alterações:

As regras não dependem da ordem
As regras de negação são classificadas no início da lista
As regras são processadas da maneira oposta à do ASP.NET, principalmente em relação à ordem: avô, pai e filho. A autorização do ASP.NET processa as regras na ordem oposta: filho, pai e avô

Para entender melhor as diferenças entre o modelo de autorização do ASP.NET e o modelo de autorização do IIS, primeiro vamos dar uma olhada em uma configuração de autorização do ASP.NET:

<authorization>
    <allow users="Vik_Malhotra" />
    <deny roles="administrators" />
    <deny users="*" />
</authorization>

Neste exemplo, estamos permitindo Vik_Malhotra, mas negando todas as outras pessoas. No IIS, a configuração é muito semelhante:

<authorization>
    <add accessType="allow" users="Vik_Malhotra" />
    <add accessType="deny" roles="administrators" />
    <add accessType="deny" users="*" />
</authorization>

O motivo da alteração da sintaxe foi que desejávamos garantir que os desenvolvedores de aplicativos soubessem que esses dois modelos são de fato diferentes, mas, ao mesmo tempo, poderiam mover regras de uma implementação para a outra com um esforço mínimo.

SSL

No IIS 6.0, o IIS armazenava informações relacionadas ao SSL na metabase e gerenciava grande parte do processo de negociação do SSL em conjunto com o HTTP.SYS. No IIS 7 e posterior, migramos a maior parte dessa configuração para o repositório do HTTP.SYS.

Para ilustrar como cada uma das configurações do IIS 6.0 são levadas para a configuração do IIS 7 e posterior (ou para a configuração do HTTP.SYS), o gráfico a seguir foi construído abaixo.

Configuração da metabase do IIS 6.0	Descrição da propriedade	Arquitetura do IIS 7.0 e posterior
AccessSSLFlags	AccessSSLFlags é uma máscara de bits de AccessSSL AccessSSL128 AccessSSLNegotiateCert AccessSSLRequireCert AccessSSLMapCert. Um valor igual a 0 significa Nenhum SSL.	Propriedade ainda com suporte no IIS 7.0 e configuração acima na seção de <acesso>
CertCheckMode	Habilita ou desabilita a verificação de CRL (lista de certificados revogados).	Esse valor agora será armazenado em http.sys no objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
RevocationFreshnessTime	Se a propriedade RevocationFreshnessTime for definida como 1 (true), a CRL (lista de certificados revogados) no cliente do certificado será atualizada pela CRL do local remoto, mesmo que a CRL armazenada em cache no cliente de certificado seja válida. O intervalo de tempo limite padrão é um dia, a menos que você use o RevocationURLRetrievalTimeout para especificar um intervalo de tempo limite diferente (em minutos).	Esse valor agora será armazenado em http.sys no objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SecureBindings	A propriedade SecureBindings especifica uma cadeia de caracteres usada pelo IIS para determinar quais pontos de extremidade de rede seguros são usados pela instância do servidor.	Ainda há suporte para essa propriedade na configuração do IIS 7.0 e posterior na seção <associação> em <sites>. O protocolo usado precisa ser usado pelo “HTTPS”.
SSLAlwaysNegoClientCert	A propriedade SSLAlwaysNegoClientCert controla as negociações de conexão do cliente SSL. Se essa propriedade for definida como true, sempre que as conexões SSL forem negociadas, o servidor negociará imediatamente um certificado do cliente, impedindo uma renegociação cara. A configuração de SSLAlwaysNegoClientCert também ajuda a eliminar deadlocks de renegociação de certificado do cliente, que podem ocorrer quando um cliente é bloqueado ao enviar um corpo de solicitação grande quando uma solicitação de renegociação é recebida.	Esse valor agora será armazenado em http.sys no objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SSLCertHash	A propriedade SSLCertHash é usada para armazenar o hash do certificado SSL que está sendo usado.	Esse valor agora será armazenado em http.sys no objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SslCtlIdentifier	A propriedade SslCtlIdentifier contém um valor exclusivo que identifica uma CTL (lista de certificados confiáveis) específica. Ele precisa ser usado com SslCtlStoreName para referenciar com precisão uma CTL.	Esse valor agora será armazenado em http.sys no objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SslCtlStoreName	A propriedade SslCtlStoreName contém o nome do repositório CryptoAPI que contém uma CTL (lista de certificados confiáveis). Ele precisa ser usado com SslCtlIdentifier para referenciar com precisão uma CTL.	Esse valor agora será armazenado em http.sys no objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SSLStoreName	A propriedade SSLStoreName é usada para armazenar o nome do repositório em que se encontra o par de chaves do certificado.	Esse valor agora será armazenado em http.sys no objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SslUseDsMapper	A propriedade SslUseDsMapper especifica se o IIS deve usar o mapeador de certificados do Serviço de Diretório do Windows ou o mapeador de certificados do IIS. Se SSLUseDSMapper for definido como false, o IIS usará o mapeador de certificados do IIS.	Esse valor agora será armazenado em http.sys no objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.

Para obter mais informações sobre o objeto HTTP.SYS PHTTP_SERVICE_CONFIG_SSL_PARAM, confira a documentação a seguir.

Todas essas alterações são tratadas de maneira transparente nos bastidores, para que você, como administrador do servidor, não precise fazer nada especial. Ou seja, o IIS cuidará de tudo. Se você tiver aplicativos que acessam as propriedades antigas do IIS 6.0 agora localizadas no repositório de configuração do HTTP.SYS, nossa interface de mapeador ABO garantirá que os valores corretos sejam lidos/gravados, de modo que não haja falhas em seus aplicativos, mas que continuem funcionando.

Lista de restrições de extensão do serviço Web

No IIS 7 e posterior, esse recurso teve pequenas modificações, passando a se chamar “isapiCgiRestrictionList”, mas, de outro modo, ele age e se comporta como fazia no IIS 6.0.

O motivo dessa alteração foi enfatizar o verdadeiro uso dele. No IIS 6.0, esse recurso foi adicionado para garantir que binários ISAPI ou CGI fraudulentos não possam ser copiados para seus servidores do IIS e, em seguida, ter permissão para execução. Com a reformulação do IIS 7 e posterior, temos dois modelos com suporte:

O pipeline de ISAPI “clássico”
O novo pipeline integrado

Se estivermos no pipeline de ISAPI “clássico”, tudo continuará funcionando como você esperava ao usar o IIS 6.0. Para ilustrar este ponto, considere como o ASP.NET funciona quando executado no modo ISAPI. Primeiro, você precisará adicionar o caminho completo da aspnet_isapi.dll e defini-la como allowed=“true”, conforme mostrado abaixo:

<isapiCgiRestriction>
    <add path="F:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
    allowed="true" groupId="ASP.NET v2.0.50727" description="ASP.NET v2.0.50727" />
</isapiCgiRestriction>

Agora e somente agora, esse código (aspnet_isapi.dll) terá permissão para ser executado. Se alternarmos o modo de pipeline para Integrado e mudarmos allowed=“false”, o código do ASP.NET ainda será executado.

Por quê? O motivo disso é que isapiCgiRestrictionList só se aplica ao código ISAPI e CGI. No modo integrado, o ASP.NET passa a integrar a nova arquitetura e, como resultado, não é afetado por isapiCgiRestrictionList. Se você não quiser executar o código do ASP.NET no novo pipeline integrado, basta remover managedEngine da lista de módulos.

Restrições de IP

As restrições de IP funcionam exatamente da mesma forma que no passado, exceto que agora há suporte para uma nova propriedade chamada “allowUnlisted”. Essa propriedade foi adicionada para facilitar a configuração de políticas de segurança para seu sistema em âmbito global. Por exemplo, fazer com que a política exigisse que apenas certos endereços IP fossem permitidos, mas todos os outros que não estivessem listados fossem rejeitados não era muito fácil de fazer no passado. Da mesma forma, agora é fácil rejeitar apenas um determinado conjunto de endereços IP e permitir todos os que não estão listados. Como administrador do servidor, você pode definir uma política global e, em seguida, bloquear esse valor para que ele não possa ser alterado no servidor por administradores do aplicativo ou do site.

Para ilustrar, considere um computador de desenvolvimento que você só deseja que os usuários acessem localmente. A configuração a seguir implementa essa política definindo allowUnlisted=“false” e, em seguida, permite explicitamente apenas o acesso de localhost (127.0.0.1):

<system.webServer>
    <security>
        <ipSecurity allowUnlisted="false">
            <add ipAddress="127.0.0.1" allowed="true" />
        </ipSecurity>
    </security>
</system.webServer>

Compartilhar via