Compartir a través de

Protección del contenido en IIS a través de las ACL del sistema de archivos

de Nazim Lala

Introducción

La lista de control de acceso (ACL) es una lista de permisos asociados a un objeto. Cada una de estas entradas de permisos se denomina entrada de control de acceso (ACE); una ACE contiene los permisos asociados a un objeto determinado para una identidad determinada. Por ejemplo, en el caso de objetos del sistema de archivos, puede establecer lista de control de acceso en archivos o directorios de un sistema de archivos NTFS.

Para establecer o editar ACL pueden usar herramientas de la interfaz gráfica de interfaz de usuario (GUI) (como Mi PC o Explorador de Windows®). Solo debe hacer clic con el botón derecho en cualquier recurso de archivo o carpeta de una de estas herramientas, seleccionar Propiedades y, después, hacer clic en la pestaña Seguridad para ver una representación gráfica de la ACL en el recurso que eligió. En este cuadro de diálogo, puede aplicar o quitar permisos de grupo o usuario a los recursos del sistema, como archivos y carpetas. Para mostrar o modificar las ACL de archivo, también se puede usar una utilidad de línea de comandos, Cacl.exe.

Conceptos básicos de ACL

Es útil empezar con algunos conceptos básicos de ACL.

Permisos comunes de IIS

Los permisos más comunes de interés en ACE son de lectura, escritura, ejecución y lista del contenido de la carpeta.

  • Permisos de lectura y escritura. Los permisos de lectura y escritura conceden acceso de lectura y escritura al objeto del sistema de archivos, respectivamente.
  • Permiso de enumeración del contenido de la carpeta. El permiso de enumeración del contenido de la carpeta se usa para mostrar el contenido de una carpeta y es necesario registrar notificaciones de cambio de archivo en un directorio.
  • Permiso de ejecución. El permiso de ejecución se usa para especificar si el sistema operativo debe ejecutar una aplicación determinada como el usuario especificado. Este permiso no abarca escenarios de aplicaciones dinámicas como PHP (o Microsoft® ASP.NET). Al invocar un archivo .php o .aspx se ejecuta código, pero no desde la perspectiva del sistema operativo. En lugar de establecer el permiso de ejecución, debe examinar el uso de los permisos de script o ejecución.
  • Control total. El permiso de control total proporciona todo el acceso al objeto del sistema de archivos. Se recomienda evitar el control total y usar permisos de lectura y escritura más granulares.
  • Permisos de ejecución y script de IIS. Los archivos con contenido dinámico, como los archivos de .php (o .aspx), necesitan permiso de script para funcionar. Pero tenga en cuenta que, aunque las ACL del sistema de archivos tienen una marca de ejecución, no tienen nada para el script. Esto se debe a que tanto Internet Information Services 7 como las versiones posteriores (IIS 7 y superiores) tienen una configuración especial para indicar si un archivo determinado tiene contenido dinámico; esta configuración se almacena en la configuración de IIS, fuera de las ACL del sistema de archivos. Cuando se describen los permisos de script o de ejecución, se refiere la configuración de IIS, no al permiso de ejecución del sistema de archivos.
  • Herencia de objetos. Las ACL del sistema de archivos normalmente se heredan. En algunos casos, el directorio principal puede tener ACL muy flexibles que deben invalidarse en el nivel secundario para bloquear adecuadamente el contenido. Esto es poco probable que sea un problema en cualquier escenario hospedado, ya que hay pocos permisos en la raíz.

Identidades de IIS comunes

Para proteger su contenido, puede usar ACL para permitir o denegar permisos a identidades concretas. Hay dos tipos de identidades: identidades de proceso (aquellas con las que se inicia el proceso de trabajo de IIS) e identidades del controlador de solicitudes (las de la autenticación de la solicitud).

  • Identidad de procesos de trabajo (WPI). El proceso de trabajo de IIS se ejecuta como WPI, que se puede configurar a través de los valores del grupo de aplicaciones en IIS. IIS 6.0 en Windows Server® 2003 e IIS 7, y las versiones posteriores, en Windows Server® 2008 tienen la identidad "Servicio de red" como WPI predeterminada. Sin embargo, Windows Server® 2008 R2 usa la identidad del grupo de aplicaciones como WPI predeterminada. Si una aplicación se autentica y realiza una suplantación, la identidad del controlador de solicitudes es la identidad de usuario autenticada.
    Si el valor fcgi.impersonate del archivo Php.ini está establecido en "true" (lo que se recomienda para IIS), los procesos PHP se ejecutan como el usuario autenticado. Es importante tener en cuenta que, en el caso de la autenticación anónima, el usuario autenticado sería el usuario anónimo configurado.
  • IIS_IUSRS. Se trata de un grupo de identidades integrado que es un contenedor de todas las identidades de procesos de trabajo (WPI) en el servidor. IIS incluye automáticamente todas las WPI de este grupo (no es preciso agregarlas manualmente).
    En IIS 6.0 en Windows Server 2003, este grupo se denomina IIS_WPG. Se trata de un grupo general que contiene todas las WPI y, por tanto, no es buen candidato para aislar el contenido. Todas las aplicaciones que se ejecuten en cualquier grupo de aplicaciones se ejecutarían como una identidad que se encuentra en el grupo en cuestión, por lo que dar a este grupo acceso de lectura significa que todas las aplicaciones pueden leer el contenido.
  • IUSR/Identidad de usuario anónimo. La cuenta IUSR integrada es la que se usa de forma predeterminada para indicar la identidad de usuario de cualquiera que use la autenticación anónima. La identidad de usuario anónima no solo se puede configurar, sino que también se puede establecer en una identidad que no sea la predeterminada.
    En la práctica, se debería configurar una cuenta personalizada para la cuenta de usuario anónimo, nunca se debería usar la cuenta integrada. Es importante saber que en IIS, que haya un usuario anónimo no significa que no haya un usuario autenticado. En su lugar, las solicitudes anónimas deben considerarse solicitudes en las que el usuario autenticado es la identidad de usuario anónimo.
  • Identidad del grupo de aplicaciones. Se trata de una identidad virtual asociada a un grupo de aplicaciones determinado. Cada vez que un usuario crea un grupo de aplicaciones, se crea una identidad virtual (identificador de seguridad o SID) con él; esta identidad se inserta en el proceso de trabajo de IIS para que el proceso de trabajo que se ejecuta en este grupo de aplicaciones tenga acceso al contenido con permisos bloqueados en esta identidad virtual. En Windows Server 2008 Service Pack 2 (SP2), el administrador puede crear sus procesos de trabajo con esta identidad virtual. Esto es algo que se puede configurar en el grupo de aplicaciones de IIS como el tipo "Identidad del grupo de aplicaciones" y es el tipo de identidad de WPI predeterminado para Windows Server 2008 R2. (la identidad es única para el grupo de aplicaciones que la creó y, por tanto, se puede usar para aislar contenido del servidor en los grupos de aplicaciones de forma más eficaz).
  • Identificador de usuario autenticado. Si la aplicación usa cualquier forma de autenticación (incluida la autenticación anónima), esta es la identidad del usuario autenticado. En el caso de autenticación anónima, esta identidad sería la identidad de usuario anónimo configurada.

Canalización de ejecución de IIS

Para saber qué identidades se pueden aplicar en cada fase, resulta útil conocer los conceptos básicos de la canalización de ejecuciones de IIS. Las dos partes de la canalización que se pueden aplicar con mayor facilidad son la autenticación y la asignación del controlador.

  • Autenticación. Antes de la autenticación, se desconoce el contexto de usuario autenticado y todos los procesos de trabajo de IIS se ejecutan como WPI. Si tiene una solicitud PHP que intenta acceder al contenido antes de autenticarse la solicitud, WPI necesitará acceso al contenido. Este escenario entra en juego cuando se usan las reglas globales de reescritura de direcciones URL que se ejecutan en la fase de solicitud global previa al comienzo de la canalización de IIS, que se produce antes de la autenticación. La reescritura de direcciones URL tiene la capacidad de procesar reglas de forma diferente en función de si el recurso al que se accede es un archivo o un directorio. Para que se pueda evaluar, debe producirse un acceso al sistema de archivos y, debido a su posición en la canalización de las ejecuciones, esta solicitud de acceso se produce como WPI.

    Después de la autenticación, se establece el contexto de usuario autenticado, pero se realiza necesariamente ninguna suplantación hasta que la solicitud se asigna a un controlador. En las fases entre la autenticación y la asignación de controladores, es muy probable que se ejecute como WPI.

  • Asignación a controlador. En esta fase de la canalización de ejecuciones, la solicitud se asigna a un controlador; por ejemplo, las solicitudes a *.php se asignan al controlador FastCGI. Una vez que esta asignación se produce y que se ha habilitado la suplantación, la identidad del controlador es el usuario autenticado y todo el acceso a recursos de esta fase se produce mediante la identidad de usuario autenticada.

Selección de una identidad

Averiguar las cuentas adecuadas a las que conceder permisos depende del perfil y de los recursos críticos de la aplicación. Las principales consideraciones son qué permisos se conceden y si usted está autenticado, o no.

  • Concesión de los permisos adecuados. El contenido dinámico, como el de las aplicaciones de PHP y ASP.NET, necesita el permiso de script de IIS y el acceso de lectura. Si necesita utilizar archivos ejecutables, deben tener el permiso de ejecución de IIS y deben configurarse correctamente en la lista de restricciones de CGI. Todo lo que no cargue el usuario solo necesita acceso de lectura en el sistema de archivos.
    El contenido que vaya a cargar un usuario debe estar en una carpeta que no sea a la que se asigna acceso de escritura. Es importante no conceder a esta carpeta permisos de ejecución o de script de IIS, con el fin de que los usuarios no puedan cargar y ejecutar código malintencionado.
    En general, para que la aplicación funcione correctamente la WPI debe tener acceso de lectura a todo su contenido.
  • Aplicaciones que requieren autenticación. En las aplicaciones que requieran autenticación, bloquee todos los recursos en un grupo que contenga todos los usuarios autenticados. Si tiene diferentes categorías de usuarios (administrador y no administrador), cree grupos independientes y conceda a cada uno de ellos el acceso pertinente. Por ejemplo, si la aplicación tiene un directorio de administradores que contenga scripts de administración, conceda los permisos necesarios para leer este directorio solo al grupo de administradores. Si la aplicación realiza una suplantación, la identidad del controlador es el usuario autenticado; de lo contrario, es su WPI. Si ha establecido que el valor de fcgi.impersonate sea "true" en el archivo Php.ini, la identidad de los procesos de fcgi es la identidad de usuario autenticada; de lo contrario, es la WPI. Con esta información, un administrador puede determinar el conjunto correcto de ACL que se colocarán en el contenido.
  • Aplicaciones que se ejecutan de forma anónima. Es importante tener en cuenta que la ejecución anónima en IIS implica que está autenticado como identidad de usuario anónima. En este caso, bloquee los recursos a la identidad del grupo de aplicaciones o a la identidad anónima configurada personalizada y proporcione acceso a la identidad del grupo de aplicaciones a través de la identidad anónima. Si concede al grupo IIS_IUSRS acceso al contenido, las aplicaciones que se ejecuten en cualquier grupo de aplicaciones tendrán acceso al contenido. Si permite que los usuarios anónimos carguen archivos, la aplicación debe garantizar que se realizan más comprobaciones de los tipos de contenido que estos usuarios pueden cargar para mantener el servidor seguro.

Cómo se establecen las ACL

Hay varias forma de establecer las ACL a través de la shell, entre las que se incluyen las herramientas de línea de comandos, como Icacls.exe. Este artículo se centra en el mecanismo del manifiesto de la Herramienta de implementación web (XML) que se puede usar para establecer las ACL. Esto se usa al instalar una aplicación a través de la herramienta de implementación web.

Para conceder permisos de lectura, ejecución y escritura al directorio del sistema de archivos MyApp para el usuario Foo, agregue la siguiente línea al archivo Manifest.xml:

<setAcl path="MyApp" setAclAccess="ReadAndExecute, Write" setAclUser="Foo" />

Para establecer la ACL en la ruta de acceso MyApp/Upload para que los usuarios anónimos puedan cargar contenido, agregue la siguiente línea al archivo Manifest.xml:

<setAcl path="MyApp/Upload" setAclAccess="Write" setAclUser="anonymousAuthenticationUser" />

Tenga en cuenta que anonymousAuthenticationUser es un token especial que se resolverá en su identidad de autenticación anónima configurada.

Para conceder acceso de lectura a la carpeta MyApp\Data a la identidad del grupo de aplicaciones, agregue la siguiente línea al archivo Manifest.xml:

<setAcl path="MyApp/Data" setAclAccess="Read" />

Tenga en cuenta que setAclUse r no se usa aquí (el valor predeterminado es Identidad del grupo de aplicaciones).