Compartir a través de

Cambios en la seguridad entre IIS 6.0 e IIS 7 y versiones posteriores

  • Artículo

por equipo de IIS

Introducción

IIS 7 y versiones posteriores aportan muchas nuevas mejoras de seguridad de IIS 6.0. Este documento es una introducción de estas mejoras con respecto a la autenticación, autorización, SSL, lista de restricciones de extensión de servicio Web y restricciones de IP.

Autenticación

Para ASP.NET desarrolladores de aplicaciones había habido, antes de IIS 7, dos modelos de autenticación con los que necesitaba programar. Estos modelos eran las canalizaciones de IIS y ASP.NET. En primer lugar, IIS examinaría la solicitud y realizaría sus rutinas de autenticación y, después, la pasaría a ASP.NET para que pudiera realizar una tarea similar.

En IIS 7 y versiones posteriores, hemos unificado estos dos modelos para generar una nueva canalización sólida que haga lo mejor que hicieron ambos modelos anteriores. IIS todavía admite todos los protocolos de autenticación antiguos, pero ahora también admite la autenticación de formularios que puede protegerse contra todos los tipos de contenido y no se basa en las cuentas de Windows. Además de admitir todas las características antiguas que ha llegado a conocer y amar también hemos mejorado algunas de ellas, como la característica Autenticación anónima.

Estos cambios se tratarán en las próximas secciones.

Cambios de autenticación anónima

En IIS 7 y versiones posteriores, la autenticación anónima se comporta de forma similar a la que tenía en versiones anteriores con un solo cambio: la capacidad de ejecutarse bajo el contenido de la identidad del proceso de trabajo. Cada grupo de aplicaciones está configurado para ejecutarse en el contenido de una cuenta de usuario y el valor predeterminado de esta cuenta es NETWORKSERVICE.

Era muy común que las aplicaciones de ASP.NET desactivaran la suplantación y se ejecutaran en la identidad del grupo de aplicaciones mediante el código siguiente en sus archivos web.config:

<identity impersonate="false"/>

Hay varios escenarios en los que las aplicaciones tendrían que ejecutarse en el contexto de la identidad del proceso:

  • La identidad del proceso es una cuenta con pocos privilegios y los administradores han bloqueado sus sistemas para esa cuenta
  • A la identidad del proceso se le ha concedido acceso a la red y se utiliza para acceder a recursos backend como bases de datos

Como parte del rediseño de IIS 7 y versiones posteriores, queríamos que este escenario fuera seguro y fácil de hacer. Para implementar este escenario, en IIS es necesario:

  • Instalación y habilitación del módulo autenticación anónima
  • Establecimiento del nombre de usuario anónimo y la contraseña en una cadena vacía

Para ello, modifique la configuración de la autenticación anónima para que aparezca de la siguiente manera:

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

Esta configuración indicará a IIS que se ejecute siempre en el contexto de la identidad del proceso de trabajo.

De manera predeterminada, la identidad de autenticación anónima en IIS 7.0 y versiones posteriores es la cuenta IUSR. Esta cuenta es una identidad con pocos privilegios con derechos y privilegios mínimos. Para obtener más información sobre la nueva cuenta integrada, consulte el artículo Descripción de la cuenta integrada y el grupo en IIS 7 y versiones posteriores.

Cambios de Passport

El soporte con la autenticación heredada de Passport se ha integrado en IIS 5/6 y Windows Server 2000 y 2003. El soporte técnico de Passport en IIS 5 y 6 se ha expuesto como una casilla en la pestaña Seguridad del directorio en el administrador de servicios IIS para "Habilitar la autenticación de Passport". Esta casilla proporcionó a IIS la capacidad de enviar desafíos de protocolo de interpolación heredados. Además de esto, todavía era necesario registrar el sitio web con el portal de aprovisionamiento de servicios de Passport, obtener una clave de cifrado y configurar el Administrador de Passport heredado en el servidor antes de que la integración de IIS fuera funcional.

En Windows Server 2008 y versiones posteriores, se quitaron los archivos binarios heredados de Passport e integración con IIS.

El servicio Passport ha cambiado desde entonces a Windows Live ID. Aunque el nuevo servicio Live ID ha crecido ciertamente fuera del servicio de Passport heredado, hay cambios importantes. Uno de los cambios más importantes es cómo se integra un sitio de asociado con Live ID. Puede agregar la autenticación de Live ID mediante el SDK de autenticación web de Windows Live ID disponible públicamente. Aunque el servicio Windows Live ID también admite la federación de identidades y ADFS, esa funcionalidad es nueva para casos específicos y no es un reemplazo de "Passport".

autenticación de formularios

La autenticación de formularios forma parte de ASP.NET y permite que tanto las identidades de Windows como las que no son de Windows se autentiquen y obtengan un objeto de usuario que las aplicaciones puedan usar más adelante. IIS 7 y versiones posteriores ahora admiten completamente la autenticación de formularios y se pueden configurar para proteger el acceso a todos los tipos de contenido.

Cómo IIS 7 y versiones posteriores determinan la identidad autenticada

En IIS 7 y versiones posteriores, el motor principal procesa las reglas de autenticación de forma similar a la de las versiones anteriores de IIS con solo algunos cambios menores. Para comprender mejor el orden de procesamiento, estas son las reglas basadas en el pedido IIS las evalúa:

  • En primer lugar, IIS determina si se ha configurado un nombre de usuario y una contraseña en el directorio virtual. Si se ha definido un conjunto de credenciales, se usarán esas credenciales. En el caso de los administradores anteriores a IIS 7, estas credenciales son las credenciales UNC
  • Si no hay credenciales configuradas en el directorio virtual, IIS usará las credenciales proporcionadas durante la autenticación. Estas credenciales pueden pertenecer a la identidad configurada para la autenticación anónima o las credenciales proporcionadas por el usuario durante el protocolo de enlace de autenticación cuando está habilitada la autenticación de Windows, implícita o básica
  • Si no se estableció ningún usuario autenticado (por ejemplo, la autenticación de formularios está habilitada), determinaremos si se debe usar la identidad del proceso
  • Si no tenemos una identidad en este momento, IIS devolverá un acceso denegado

Authorization

Compatibilidad con AzMan

En IIS 6.0, se introdujo un nuevo modelo de autorización basado en reglas de AZMan. En IIS 7 y versiones posteriores hemos dejado de usar esta característica en favor de un nuevo modelo que es muy similar al modelo de autorización de ASP.NET (consulte el tema de autorización de direcciones URL a continuación).

Autorización de URL

En IIS 7 y versiones posteriores, tiene dos soluciones de autorización. La primera consiste en usar el modelo de autorización de ASP.NET. Este método requiere definir todas las reglas de autorización en la configuración< system.web> y requiere cero cambios para las aplicaciones que ya tienen reglas escritas para ASP.NET. El segundo modelo consiste en pasar a la nueva arquitectura de autorización de IIS. Este modelo es muy similar a ASP. Modelo de NET con algunos cambios menores:

  • Las reglas no dependen del pedido
  • Las reglas de denegación se ordenan en la parte superior de la lista
  • Las reglas se procesan de la manera opuesta de ASP.NET, principalmente en el orden: abuelo, padre, entonces niño; ASP.NET las reglas de autorización en el orden opuesto: secundario, padre y abuelo

Para comprender mejor las diferencias entre el modelo de autorización de ASP.NET y el modelo de autorización de IIS, veamos primero una configuración de autorización de ASP.NET:

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

En este ejemplo estamos permitiendo Vik_Malhotra pero estamos negando a todos los demás. En IIS, la configuración es muy similar:

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

El motivo del cambio de sintaxis fue que queríamos asegurarnos de que los desarrolladores de aplicaciones supieran que estos dos modelos son de hecho diferentes, pero al mismo tiempo podían mover reglas de una implementación a la otra con un trabajo mínimo.

SSL

En IIS 6.0, IIS había almacenado información relacionada con SSL en la metabase y había administrado una gran parte del proceso de negociación SSL junto con HTTP.SYS. En IIS 7 y versiones posteriores, hemos movido la mayoría de esta configuración a HTTP. Almacén de SYS.

Para ilustrar cómo cada una de las opciones de configuración de IIS 6.0 se transfiere a la configuración de IIS 7 y versiones posteriores (o HTTP.SYS configuración), se ha construido el siguiente gráfico a continuación.

Configuración de Metabase de IIS 6.0 Descripción de la propiedad Arquitectura de IIS 7.0 y versiones posteriores
AccessSSLFlags AccessSSLFlags es máscara de bits del valor AccessSSL AccessSSL128 AccessSSLNegotiateCert AccessSSLRequireCert AccessSSLMapCert 0 significa ningún SSL. La propiedad sigue siendo admitido con IIS 7.0 y la configuración posterior en la sección de < acceso>
CertCheckMode Habilite o deshabilite la comprobación de CRL (lista de revocación de certificados). Este valor ahora se almacenará en http.sys en el objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
Revocationfreshnesstime Si la propiedad RevocationFreshnessTime se establece en 1 (true), la lista de revocación de certificados (CRL) en el cliente de certificado se actualiza mediante la CRL desde la ubicación remota, incluso si la CRL que se almacena en caché en el cliente de certificado es válida. El intervalo de tiempo de espera predeterminado es un día a menos que use El valor de RevocationURLRetrievalTimeout para especificar un intervalo de tiempo de espera diferente (en minutos). Este valor ahora se almacenará en http.sys en el objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SecureBindings La propiedad SecureBindings especifica una cadena usada por IIS para determinar qué puntos de conexión de red seguros usa la instancia del servidor. Esta propiedad todavía se admite en IIS 7.0 y versiones posteriores en la sección de< enlace> para <sitios>. El protocolo utilizado debe ser "https".
SSLAlwaysNegoClientCert La propiedad SSLAlwaysNegoClientCert controla las negociaciones de conexión de cliente SSL. Si esta propiedad se establece en true, cada vez que se negocian las conexiones SSL, el servidor negociará inmediatamente un certificado de cliente, lo que impedirá una renegociación costosa. Establecer SSLAlwaysNegoClientCert también ayuda a eliminar los interbloqueos de renegociación de certificados de cliente, lo que puede ocurrir cuando un cliente está bloqueado al enviar un cuerpo de solicitud grande cuando se recibe una solicitud de renegociación. Este valor ahora se almacenará en http.sys en el objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SSLCertHash La propiedad SSLCertHash se usa para almacenar el hash del certificado SSL que se está usando. Este valor ahora se almacenará en http.sys en el objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SslCtlIdentifier La propiedad SslCtlIdentifier contiene un valor único que identifica una lista de confianza de certificados (CTL) específica. Debe usarse con SslCtlStoreName para hacer referencia con precisión a un CTL. Este valor ahora se almacenará en http.sys en el objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SslCtlStoreName La propiedad SslCtlStoreName contiene el nombre del almacén CryptoAPI que contiene listas de confianza de certificados (CTL). Debe usarse con SslCtlIdentifier para hacer referencia con precisión a un CTL. Este valor ahora se almacenará en http.sys en el objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SSLStoreName La propiedad SSLStoreName se usa para almacenar el nombre del almacén donde reside el par de claves del certificado. Este valor ahora se almacenará en http.sys en el objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.
SslUseDsMapper La propiedad SslUseDsMapper especifica si IIS va a usar el mapeador de certificados del servicio de directorio de Windows o el mapeador de certificados de IIS. Si SSLUseDSMapper se establece en false, IIS usa el asignador de certificados de IIS. Este valor ahora se almacenará en http.sys en el objeto PHTTP_SERVICE_CONFIG_SSL_PARAM.

Para obtener más información sobre el objeto HTTP.SYS PHTTP_SERVICE_CONFIG_SSL_PARAM, consulte la siguiente documentación.

Todos estos cambios se controlan de forma transparente en segundo plano, por lo que, como administrador del servidor, no hay nada especial que tenga que hacer- IIS hará todo para usted. Si tiene aplicaciones que acceden a las propiedades antiguas de IIS 6.0 ahora se encuentran en HTTP. El almacén de configuración de SYS, nuestra interfaz del asignador de ABO garantizará que los valores correctos sean leídos o escritos, por lo que las aplicaciones no producirán errores, sino que seguirán funcionando.

Lista de restricciones de extensión de servicio web

En IIS 7 y versiones posteriores, esta característica se ha modificado ligeramente para que su nombre ahora lea "isapiCgiRestrictionList", pero de lo contrario actúa y se comporta como lo tenía en IIS 6.0.

La razón de este cambio era resaltar su verdadero uso. En IIS 6.0, esta característica se agregó para asegurarse de que los archivos binarios de ISAPI o CGI no se pudieron copiar en los servidores IIS y, a continuación, se les permitió ejecutar. Con el rediseño de IIS 7 y versiones posteriores, tenemos dos modelos admitidos:

  • La canalización de ISAPI "clásica"
  • Nueva canalización integrada

Si estamos en la canalización ISAPI "clásica", todo seguirá funcionando como se esperaba al usar IIS 6.0. Para ilustrar este punto, considere cómo funciona ASP.NET al ejecutarse en modo ISAPI. En primer lugar, deberá agregar la ruta de acceso completa de la aspnet_isapi.dll y establecerla allowed="true", como se muestra a continuación:

<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>

Ahora y solo ahora se permitirá que este código (aspnet_isapi.dll) se ejecute. Si cambiamos el modo de canalización a integrado y cambiado allowed="false", se seguirá ejecutando el código de ASP.NET.

¿Por qué? La razón es que isapiCgiRestrictionList solo se aplica al código ISAPI y CGI. En el modo integrado, ASP.NET ahora forma parte de la nueva arquitectura y, como resultado, no se ve afectado por isapiCgiRestrictionList. Si no desea ejecutar ASP.NET código en la nueva canalización integrada, bastará con quitar managedEngine de la lista de módulos.

Restricciones de IP

Las restricciones de IP funcionan exactamente de la misma manera que en el pasado, excepto que ahora se admite una nueva propiedad denominada "allowUnlisted". Esta propiedad se agregó para facilitar la configuración de directivas de seguridad para el sistema a nivel global. Por ejemplo, si la directiva solo requería que se permitan determinadas direcciones IP, pero rechazar todas las demás que no aparecen en la lista no eran muy fáciles de hacer en el pasado. Del mismo modo, rechazar solo un conjunto determinado de direcciones IP y permitir que todos los que no aparecen en la lista se puedan hacer fácilmente ahora. Como administrador del servidor, puede establecer una directiva global y, a continuación, bloquear este valor para que los administradores de la aplicación o del sitio no puedan cambiarlo en el servidor.

Para ilustrarlo, considere una máquina de desarrollo a la que solo desea que los usuarios accedan localmente. La siguiente configuración implementa esa directiva estableciendo allowUnlisted="false" y, a continuación, solo permite explícitamente el acceso localhost (127.0.0.1):

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