por James Morey
Escritor de Tecnologías Web, del equipo de documentación de IIS

Este artículo contiene una explicación detallada de algunas de las funciones no comprendidas sobre seguridad en Microsoft® Internet Information Server (IIS) 4.0, incluyendo el mapeo certificado de cliente, restricciones de direcciones IP, enlaces y permisos para Web. No sólo descubrirá cómo trabajan estas funciones, sino que también cómo optimizar su configuración.

Antes de leer este artículo deberá tener un entendimiento básico tanto de IIS como la seguridad de Microsoft Windows NT® 4.0 incluyendo la infraestructura de clave pública, el protocolo SSL, así como conocimiento comprobable dem seguridad y autentificación. Para entender mejor estos conceptos, consulte la documentación sobre IIS en su servidor en el sitio en inglés http://localhost/iisHelp/iis/misc/default.asp. Comenzaré hablando sobre la relación entre la seguridad de Windows NT e IIS, de ahí pasaremos a temas específicos como autentificación, restricciones IP, SSL y permisos para Web. Al final de este artículo hay un breve glosario de términos importantes sobre seguridad y una lista de recursos a los que puede acudir para obtener más información.

Windows NT e IIS
IIS 4.0 es un servicio que se ejecuta sobre Windows NT. De ahí, se apoya principalmente en las cuentas de usuario de Windows NT y el sistema de archivos de Windows NT.

Cuentas de usuario
En el centro de la seguridad de Windows NT está la cuenta de usuario y su extensión lógica, el grupo del usuario. Cuando se instala IIS, crea dos cuentas de usuario, les asigna derechos de usuario específicos y los acomoda en grupos de usuarios específicos. Estas dos cuentas son IUSR_computername y IWAN_computername. La cuenta IUSR_computername es usada por IIS para asegurar acceso anónimo a los recursos del Web. IWAN_computername es la cuenta usada por el Servidor de transacciones de Microsoft (Microsoft Transaction Server, MTS) y varias entidades de IIS para proporcionar funciones programáticas y transaccionales. Como un propósito en este artículo, me enfocaré a la primera cuenta, IUSR_computername.

La cuenta IUSR_computername requiere tener el acceso de inicio de sesión local (Logon Locally) configurado correctamente. Esto se debe a que actúa dentro de IIS, que es un servicio que actúa localmente, tal como si fuera un usuario que físicamente se conecta al servidor. SI usa cualquier otra cuenta que no sea IUSR_computername para acceso anónimo, seleccione con cuidado los derechos que asigna. Cada visitante anónimo a su sitio obtendrá los derechos de la cuenta IUSR_computername.

IIS también depende de las cuentas de usuarios al proporcionar autentificación Básica y Windows Challenge/Resource. Con el fin de finalizar la operación con éxito, ambos métodos requieren que cuentas de usuarios válidas estén asignadas. Esto es necesario porque aunque IIS crea y configura la cuenta IUSR_computername, que se usa para autentificación Anónima, no crea ninguna cuenta para autentificación Básica. IIS asume que usted ha creado, o va a crear, cuentas Windows NT para ser usadas con la autentificación Básica y Reto/Respuesta.

Nota Debe tener cuentas válidas de Windows NT para ser usadas con la autentificación Básica y Reto/Respuesta. Ni Windows NT ni IIS las crean para usted. Sin dichas cuentas estos métodos de autentificación no funcionarán.

El sistema de archivos de Windows NT
Aunque IIS puede desempeñarse correctamente en la unidad de disco duro de una tabla de asignación de archivos (File Allocation Table, FAT), debe considerar cambiar el formato al sistema de archivos Windows NT File System (NTFS). Aquí está el por qué:

En el segundo punto, mencioné ACLs. Un ACL es una lista de cuentas de usuarios, grupos de usuarios y sus privilegios asociados con un recurso en particular, como un directorio o un archivo. Por ejemplo, el archivo MyISAPI.dll tendría una lista de cuentas de usuario y grupos de usuario que puedan accesarlo y qué nivel de acceso para el archivo van a obtener, como Lectura, Escritura o Ejecución. Los ACLs son otra función básica del modelo de seguridad de Windows NT y permite un control de acceso flexible y preciso a los recursos en el disco duro. Cada directorio y cada archivo tienen su propio ACL que define quién puede hacer qué y dónde. Aún cada ACL tiene un ACL que especifica quién puede ver y cambiar el ACL por sí mismo.

Los NTFS y los ACLs le proporcionan una base para asegurar sus recursos de servidor. Para convertir una partición o disco duro a NTFS, escriba lo siguiente en la interface de comandos (Command prompt).

CONVERT <drive>: /FS:NTFS

Precaución
Una vez que una unidad de disco o partición se ha convertido a NTFS usando la utilería de línea de comando CONVERT, ya no revertir la conversión usando esta utilería. Hay utilerías de otras compañías que pueden revertir una conversión.

Esta sección ofrece explicaciones detalladas sobre permisos de Web, autentificación, mapeo certificado de cliente, dirección de IP y restricciones en el nombre del dominio y la encriptación de Secure Sockets Layer (SSL).

Permisos de Web contra permisos de NTFS
IIS tiene permisos de Web como Lectura y Escritura. NTFS también tiene sus propios permisos, como Lectura y Escritura. No es una sorpresa que ésto pueda ser confuso. La clave para entender la diferencia entre ambos es ésta: los permisos de Web realmente controlan qué verbos HTTP pueden ser ejecutados por recursos de HTTP. Los permisos de NTFS controlan qué cuentas de usuario tienen qué tipo de acceso a los recursos en el disco duro.

Sobre esto tratan los recuadros para seleccionar Lectura o Escritura en la etiqueta del sitio Web en IIS. Controlan qué verbos HTTP son permitidos para los recursos. No controlan los permisos del sistema de archivos de NTFS para los recursos.

Ahora vamos a intercambiar los permisos: NTFS tiene Lectura y Escritura y el Web sólo lectura. El resultado es que el usuario Web aún no puede escribir sobre el sitio Web porque se niega el permiso. Sin embargo, el cliente en la red puede copiar el archivo fácilmente porque a NTFS no le importa lo que IIS diga. IIS sólo se encarga de requisiciones de HTTP y no de requisiciones de sistemas de archivos.

Los permisos Mantra: Si los permisos de Web y NTFS no coinciden, el más restrictivo de ambos será usado para las requisiciones de HTTP.

Selección del método indicado de autentificación La autentificación Anónima es apropiada para sitios Web públicos, porque permite a cualquiera tener acceso a los recursos de ese sitio. Para los sitios que contienen información confidencial, sin embargo, querrá controlar el acceso más cuidadosamente. En este caso, tiene usted cuatro opciones de autentificación: autentificación de Windows NT Reto/Respuesta (Challenge/Response), autentificación Básica, mapeo certificado del cliente o una aplicación personalizada de autentificación como un filtro ISAPI.

Windows NT Challenge/Response
La autentificación Windows NT Reto/Respuesta usa directamente cuentas de usuario de Windows NT y no transmite información del inicio de sesión (logon), como el nombre del usuario y contraseña, en la red. Esto es muy importante si quiere proteger los nombres de usuarios y contraseñas de sus clientes. También, debido a que este tipo de autentificación usa cuentas de usuario individuales, puede tener una gran flexibilidad sobre el nivel de acceso de esos clientes.

La autentificación Reto/Respuesta usa tecnología hashing para transmitir información sobre credenciales. En el proceso hashing, una copia de un mensaje en texto plano se ejecuta dentro de una operación matemática y resulta en un valor hash que está generalmente entre y 160 bits de tamaño. Se dice que el valor hash es de un solo sentido, es decir, no es computacionalmente factible para derivar el mensaje original desde ahí. La autentificación Reto/Respuesta usa una serie de estos intercambios hash entre el servidor y el cliente para establecer la identidad del usuario antes de otorgar el acceso a los recursos.

A continuación se explica por qué los valores hash son tan efectivos para la seguridad:

Debido a que tanto el cliente como el servidor son autentificados durante el intercambio criptográfico, nadie puede entrar y emular al servidor (los usuarios ya saben con quién están tratando). A pesar de la efectividad de este proceso, existen dos limitaciones:

Autentificación Básica
La autentificación Básica transmite el nombre del usuario y la contraseña en línea con codificación Base64. Si va a aplicar la autentificación Básica, tenga lo siguiente en mente:

La autentificación Básica es ampliamente utilizada en Internet porque es más fácil de implementar, es soportada por la mayoría de los exploradores, y no se requieren niveles mayores de seguridad. En realidad, a menos que su sitio sea interesante para los hackers, no hay mucha gente en espera de interceptar sus paquetes IP.

Haciendo más segura la autentificación Básica
Se estará preguntando a estas alturas cómo puede obtener un método seguro de autentificación que sea soportado por la mayoría de los exploradores. La respuesta es usar la autentificación Básica encriptada por SSL. Esta combinación le ayudará a lograr un control hermético de acceso a su información sensible sin el temor a accesar información que sea interceptada y usada con malas intenciones. También permite autenticar su servidor de manera que los usuarios puedan conservar la confidencialidad de su identidad. Para información más detallada, vea la sección "Misterios de SSL".

Para iniciar la autentificación Básica con SSL:

El mapeo de certificados de cliente de IIS asocia o mapea, información de certificados de cliente con cuentas de usuario de Windows NT. Esta forma de autenticar puede ser muy segura y flexible y la mayoría de los exploradores nuevos aceptan el uso de certificados de cliente.

Existen dos métodos que IIS usa para mapear certificados de cliente a estas cuentas: "muchos para uno" y "uno para uno". La mayor diferencia entre ellos es que "uno para uno" usa el certificado actual, cuando "muchos para uno" solamente usa cierta información contenida en el certificado, como quién emitió el certificado. Con el mapeo de "uno para uno", si un usuario obtiene un nuevo certificado, el mapeo anterior fallará y un nuevo mapeo se va a requerir para el nuevo certificado. Con el mapeo de "muchos para uno", si el usuario obtiene un nuevo certificado usando la misma información, el mapeo lo aceptará como con el mapeo anterior.

Por ejemplo, Bob obtiene un certificado de cliente usando MiEmpresa para la empresa, MiUnidad para la unidad organizacional, MiCiudad para la ciudad y MiEstado para el estado. Cuando él obtiene el certificado de parte del CA, contendrá toda la información que él les proporcionó, además de alguna información adicional (vea la sección "¿En qué consiste un certificado?". El certificado de Bob se mapea a su cuenta de usuario usando tanto el mapeo de "uno para uno" como el de "muchos para uno". Ambos mapeos funcionan bien.

Algún tiempo después, Bob obtiene otro certificado, usando información idéntica a la usada anteriormente. El certificado que él obtiene contiene exactamente la misma información que el certificado anterior, pero la información adicional es un poco diferente. El anterior mapeo de "muchos para uno" funciona porque no pone atención a la información adicional, sólo le interesa la información que proporcionó Bob. El mapeo de "uno para uno" va a fallar porque usa la información adicional durante el proceso de autentificación.

El mapeo de "muchos para uno" detectará el nuevo certificado de Bob idéntico al anterior. El mapeo "uno para uno" verá al nuevo certificado como un certificado completamente nuevo y, de ahí, que ya no será válido. Un nuevo mapeo de "uno para uno" se va a requerir para el nuevo certificado de Bob.

¿Qué es un certificado?

Un certificado es un archivo de texto especial que contiene dos secciones: una sección de texto plano (que puede ser leído por los usuarios) que contiene información sobre el propietario del certificado, el emisor y así; y una sección encriptada (que no puede ser leída por los usuarios) que contiene la firma digital y una clave pública de la autoridad del certificado.

El archivo de texto tiene una extensión .cer de modo que cuando se abre, el sistema operativo usa cualquier utilería de certificado que tenga para ver el archivo. Si abre uno de estos archivos en el Block de notas (Notepad), se verá así:

-----BEGIN CERTIFICATE-----
CBHcm91cCBDQS5jcmwwRqBEoEKGQGZpbGU6Ly9cXENFUlRTUlZcQ2VydFNydlxDZXJ0R
W5yb2xsXE1TIENlcnRTcnYgVGVzdCBHcm91cCBDQS5jcmwwCQYDVR0TBAIwADBiBggrBg
EFBQcBAQRWMFQwUgYIKwYBBQUHMAKGRmh0dHA6Ly9DRVJUU1JWL0NlcnRTcnYvQ2VydEV
ucm9sbC9DRVJUU1JWX01TIENlcnRTcnYgVGVzdCBHcm91cCBDQS5jcnQwDQYJKoZIhvc
NAQEEBQADQQAhq70nRlse0ulPstU+IWdjeNj5p
-----END CERTIFICATE-----

Mapeo de "muchos para uno"
El mapeo de "muchos para uno" usa sólo cierta información contenida en el certificado, como quién emitió el certificado o para quién fue emitido. Usted puede establecer reglas "comodín", como "Aceptar todos los certificados de "tal" autoridad de certificación". Puede usted ser tan específico o tan general como quiera ser. Fácil y rápidamente puede mapear muchos certificados para una cuenta única de usuario de esta manera. También, no hay necesidad de tener una copia del certificado del cliente en su servidor. Si el usuario obtiene un nuevo certificado que tenga la misma información que antes, el antiguo mapeo aún funcionará.

Mapeo de "uno para uno"

Debido a que "uno para uno" usa información adicional que es única para cada certificado, puede estar confiado sobre la identidad del usuario. Esto es porque "uno para uno" usa un intercambio criptográfico, tal como Reto/Respuesta, involucrando el par de claves del certificado de cliente. Durante este intercambio el servidor requiere comparar la información enviada por el explorador del usuario contra una copia de la certificación del cliente en el servidor. De ahí, que el servidor deba tener una copia de cada certificado de cliente usado para el mapeo de "uno para uno".

¿Qué es un par de claves?
La encriptación y otros métodos de seguridad involucran el uso de valores únicos llamados claves. El usado más ampliamente en esquemas de la encriptación utiliza algo llamado par de claves. Como su nombre lo indica, un par de claves consiste en dos claves. Una es llamada clave pública y puede ser compartida con varios individuos. La otra clave, la clave privada, solamente la conoce el propietario del certificado, ya sea un certificado de servidor o un certificado de cliente. La clave privada y la clave pública forman un par de claves asimétrico, donde las dos claves en cada extremo de la transmisión criptográfica son diferentes uno de otro. Si usted encripta un mensaje con la clave privada, sólo la clave pública puede desencriptarlo. Si encripta un mensaje con la clave pública, sólo la clave privada puede desencriptarlo.

Encriptación privada--> desencriptación pública Sólo el usuario destinatario puede leerlo

Obteniendo y almacenando certificados de cliente

La pregunta obvia es ¿Exactamente cómo obtengo una copia del certificado del cliente en mi servidor?

Puede extraer la información que necesita sobre el certificado usando un script de la documentación de Windows NT Option Pack en http://localhost/iishelp/iis/htm/core/iicrtsc.htm. Puede usar este script en su Default.asp para copiar la información sobre el certificado del cliente a su servidor en archivo de texto.

Los certificados por sí mismo pueden ser extraídos desde el archivo de texto, al copiar la información en el Block de notas y salvándolo como un archivo de certificado (.cer). Copie cada sección de texto, incluyendo -----BEGIN CERTIFICATE----- hasta las líneas -----END CERTIFICATE-----. Ahora puede implementar el cambio siguiente si es necesario.

Para ser utilizable en el mapeo del certificado de cliente en IIS, estos archivos de certificados deben estar en un formato de Base64 Encoded X.509. Deberían estar ya en el formato correcto, pero como no hay seguridad en ello, es mejor hacer la conversión, sólo para estar seguros. Si ha instalado el Service Pack 4, puede hacer la conversión de la siguiente manera:

Nota Este script copia cada uno de los casos de cada certificado de cliente que es enviado a su sitio. Así, por ejemplo, si Bob envía su certificado 100 veces durante el día, el script creará 100 copias del certificado de Bob. Esto significa que el archivo de texto que el script crea puede hacerse muy grande en poco tiempo. Para corregir ésto, podría ya sea escribir un script o un filtro ISAPI que salve cada certificado en un archivo de texto por separado.

Las direcciones de IP son números únicos que identifican a las computadoras en la red. La dirección de IP de la computadora de la que el usuario hace una requisición siempre es enviada junto con ésta. De ahí, usted puede garantizar o denegar el acceso a recursos de servidor basándose en las direcciones IP de la parte solicitante. Al seleccionar la opción para otorgar acceso (Grant Access) en el administrador de servicios de Internet, usted está diciendo: "Quiero otorgar el acceso a quien sea excepto a las direcciones de IP que se indican en la lista".

Puede especificar las direcciones de IP individualmente o en grupos al usar la identificación de la red (Network ID) y una máscara de subred (subnet mask), cuya definición se describe más adelante. También puede especificar un dominio o un nombre de sistema de nombre de dominio (domain name system DNS). Al usar el nombre del dominio, como MiCompetidor.com, es conveniente, pero puede causar una búsqueda invertida de DNS cada vez que la autentificación se solicite. Esto puede afectar el desempeño de su servidor.

Búsquedas (lookups) de DNS
Una búsqueda de DNS es una convocatoria al servidor DNS para identificar el nombre dado al dominio y entonces proporcionar la dirección de IP correspondiente. Esta dirección de IP se regresa a IIS e IIS la usa para la exclusión de la dirección de IP. Esto es un problema para el desempeño.

Existen dos factores que afectan el desempeño. El primero es la locación física de su servidor DNS. Si está al otro lado del mundo, el viaje redondo para obtener la dirección de IP para IIS puede llevar algún tiempo. Si el servidor DNS está en la computadora que está ejecutando el IIS, el viaje redondo es evitado pero la búsqueda aún usa el CPU y los recursos de memoria. El segundo factor es el tamaño puro de su red. Si tiene nombres de DNS en su red, no hay problema. Si tiene 450,000 nombres de DNS en su red, la búsqueda revertida va a tardar un poco.

La identificación de la red y la máscara de subred
La identificación de la red es una base para la dirección de IP que es usada para comparar las direcciones de IP de las requisiciones recibidas. La máscara de subred es un número que especifica qué bits de la identificación de la red serán usados en una operación AND (bit-wise) de las direcciones de IP que van llegando. ¿Entendido?

Generalmente, la identificación de la red es la dirección de IP de un enrutador de IP en particular. Un enrutador de IP es una computadora o cualquier dispositivo que "sabe" a cuáles direcciones de IP les da servicio o enruta. Cuando la identificación de la red recibe una requisición, o pasa la requisición a su nodo o dice "No, aquí no hay nadie con ese nombre". "Generalmente" es la palabra operativa aquí. La estructura de la identificación de la red para su empresa es uno de esos temas de "seguridad del trabajo" en el área de su administrador de redes (si necesita saber qué identificación de red en particular puede usar, probablemente tenga que preguntar a su administrador de redes). Para ver las direcciones de IP, identificaciones de red y máscara de subred de su computadora, escriba "ipconfig /all" en la línea de comandos.

Las identificaciones de red y la máscara de subred trabajan así: Suponga que tiene un grupo de direcciones de IP de su departamento de contabilidad que no quiere que accesen su sitio R&D. Usaría la opción de otorgar acceso Grant Access para otorgar el acceso a cualquiera, excepto a las direcciones de IP que usted especifique.

Digamos que la identificación de la red para el departamento de contabilidad es 172.21.13.45. Con el propósito de restringir cada una de las direcciones de IP de ese departamento, usaría la máscara de subred 255.255.255.0. Es como si usara comodines y tecleara 157.112.189.* de modo que cualquier dirección de IP que inicie con 172.21.13 será excluida. Otra forma de verlo es, "Excluir el rango de dirección de IP de 172.21.13.0 a 172.21.13.255." Si fuera a usar la máscara de subred 255.255.0.0, entonces cada dirección de IP que inicie con 172.21 sería excluida. Note que la máscara de la subred no es una dirección de IP.

Cómo funcionan realmente la identificación de la red y las máscaras de subred
Las direcciones de IP consisten de cuatro juegos de 8 bits. En consecuencia, la dirección de IP 172.21.13.45 se vería como:

172.21.13.45 10101100.00010101.00001101.00101101

Una máscara de subred es usada para "enmascarar" la comparación bit-wise, que es una operación AND. El patrón de bits de la máscara de subred actúa como una pantalla que permite o niega la comparación de bits. Por ejemplo, si fuera a compara la identificación de la red anterior usado la máscara de subred 255.255.255.0, se vería así:

Identificación de la red 10101100.00010101.00001101.00101101
Máscara de subred yyyyyyyy.yyyyyyyy.yyyyyyyy.nnnnnnnn
Patrón de comparación 10101100.00010101.00001101.xxxxxxxx

Donde haya una "n", el bit de la dirección de IP que se recibe no será comparada. Donde haya una "y", sí lo será. El resultado es que cualquier dirección de IP con el patrón de comparación de bits será excluida. La "x" en el patrón de comparación de bits significa "ignore este bit". Al usar máscaras de subred extrañas, como 255.107.0.0, puede excluir (o incluir) cualquier rango de direcciones de IP que desee.

¡Tenga cuidado con la máscara de subred!
Si yo hubiera usado la máscara de subred 0.0.0.255, cualesquiera direcciones de IP que terminen en 00101101 (45) habrían sido excluidas. Es muy importante conocer qué máscara de subred usar y estar seguro que usted no está otorgando accesos cuando realmente quiere negarlos.

Secure Sockets Layer (SSL) es el método más ampliamente usado hasta hoy para crear transacciones seguras en el Web. Básicamente, el método utiliza la criptografía de clave pública para generar e intercambiar en forma segura una clave usada comúnmente, llamada la clave de sesión, que es usada por el encryptado simétrico. Las funciones de SSL en IIS no pueden ser usadas hasta que un certificado de servidor ha sido obtenido y enlazado al sitio Web.

Al enlazar, quiero decir que IIS asocia el certificado con una dirección de IP en particular: combinación de número de puerto. Esta combinación podría ser "Cualquiera no asignado":"Cualquiera no asignado", que puede cubrir todos los sitios Web posibles que su servidor pueda contener, o tan específicos como 172.21.13.45:80, que se refiere a un sitio Web específico.

Con todas estas funciones de seguridad, SSL puede parecer complejo. Por ejemplo, ¿cómo podría usted enlazar el certificado del servidor (un certificado para cada sitio o el mismo certificado para todos los sitios)? ¿Requiere de encryptado? ¿Qué longitud de bit debería usar? ¿Cómo puede respaldar su certificado de servidor?

Enlaces de servidor y certificado de servidor
Por defecto, IIS usa el puerto 443 como el puerto de SSL. Usted puede, sin embargo, usar cualquier puerto que quiera para SSL. Puede tener muchos sitios, cada uno con un número de no asignado a SSL o un número de puerto de SSL. Por ejemplo, usted podría tener un sitio llamado SitioEjemplo. Podría tener el puerto 90 como el puerto no asignado a SSL y un puerto 445 como el puerto SSL. Los usuarios escribirían http://www.SitioEjemplo.com para accesar la versión no asignada a SSL. Para accesar la versión SSL, se usaría http://www.SitioEjemplo.com. También se podría usar el número de puerto de IP:

https://www.Example.com:445.

https://www.ExampleSite.com:90.

Cuando selecciona "Cualquiera no asignado" como la asignación de IP, el certificado es enlazado a todos los sitios Web que anteriormente no estaban enlazados a ellos el certificado de servidor (aún sitios con puertos asignados, como el sitio Web de Default y el sitio Web del administrador que están ya instalados por IIS). Si ninguno de sus sitios tienen certificados asignados a ellos, entonces el certificado se enlaza en forma efectiva al servicio WWW. Esto está bien, y su servidor trabajará perfectamente.

Longitud de bit y ese tipo de cosas
Cuando está creando una requisición de certificado y un par de claves con el Administrador de claves y éste le pregunta qué longitud de bit usar, le está preguntando por la longitud de bit de la clave privada del certificado de servidor. Esta clave sólo es conocida por el servidor. Las diferentes autoridades de certificación (CAs) tienen diferentes capacidades de longitud de bits. Verifique con el CA sobre las longitudes de bits disponibles. Es aconsejable seleccionar la longitud de bit mayor disponible de su CA y por las restricciones de exportación. Típicamente, esta es una longitud de 1024 bits para versiones domésticas y 512 bits para versiones de exportación.

La longitud de la clave que está bajo la restricción de exportación es la clave actual usada para encriptar y desencriptar los mensajes. En SSL, esta es una clave de sesión y está restringida en las versiones de exportación de IIS a una longitud de 40 bits. De ahí que, si está usando una versión de exportación de IIS, no será capaz de usar claves de sesión de 128 bits. Puede, sin embargo, aún usar claves privadas de servidor de 521 bits. La longitud de la clave puede ser establecida en la ventana de diálogo de Comunicaciones seguras (Secure Communications).

Dos de las preguntas más frecuentes con relación a las conexiones seguras son "¿Cómo puedo tener SSL activado en un directorio virtual y desactivado para otro? " y "Si no he requerido un canal seguro (Require Secure Channel) al accesar este recurso habilitados, ¿está funcionando SSL?"

Permítanme forjar dos términos aquí que ayudarán a responder a estas preguntas: SSL habilitado y SSL requerido.

SSL habilitado significa que los usuarios que solicitan recursos en su servidor pueden hacerlo usando el formato https://. Esto es, pueden establecer una conexión segura de SSL con su servidor, pero esto no es requerido. Pueden aún usar el formato http:// para los recursos sobre una conexión no encryptada. SSL es habilitado tan pronto usted enlaza un certificado de servidor al sitio, o su servicio WWW.

SSL-requerido significa que sólo las conexiones SSL pueden ser hechas para los recursos (http:// no funcionará del todo). Esto sucede sólo cuando usted selecciona la opción de Requerir un canal seguro al accesar este recurso en la ventana de diálogo Secure Communications.

La opción de Requerir un canal seguro al accesar este recurso puede ser seleccionada en a nivel de Master, sitio, directorio virtual o de archivo. Sin embargo, tan pronto como enlace un certificado de servidor a un sitio, cada recurso incluido en este sitio, es decir todos los directores y archivos virtuales, están habilitados para SSL aún si usted no ha seleccionado la opción Requerir un canal seguro al accesar este recurso. Todo lo que hace el parámetro de Requerir es forzar a los usuarios a establecer una conexión SSL.

El truco de "un certificado "
Enlazar un certificado de servidor al nivel de Propiedades master (Master Properties) usando "Cualquier dirección IP no asignada" y "Cualquier puerto no asignado" enlazarán efectivamente el certificado a cada sitio Web que no ha sido enlazado previamente a un certificado. Si este es su primer certificado de servidor, significa que efectivamente se enlazará al servicio completo del Web. Puede hacer esto también al enlazar individualmente el mismo certificado de servidor a cada sitio.

La forma más fácil de hacer su sitio completamente inalcanzable
Hasta este momento, se estará preguntando si puede establecer la opción de Requerir un canal seguro al accesar este recurso en el nivel de Propiedades master. La respuesta es sí. ¿Será una buena idea? Probablemente no. Cuando establece Requerir un canal seguro al accesar este recurso en el nivel de Propiedades master, lo está configurando para todos los sitios, aún cuando estos no estén enlazados al certificado de servidor y desde luego, no habilitado para SSL. Esto significa que los sitios ahora tienen acceso de los usuarios. Si usan el formato http://, se les indicará que se requiere SSL para los recursos. Si entonces usan el formato https://, se les dirá que la página no puede ser cargada porque no hay un certificado de servidor enlazado al sitio. Básicamente, lo que sucede es esto: Necesita usar https://U. ¡Ah sí!, https:// no funciona.

No puede configurar SSL en un nivel de Propiedades master sin un certificado de servidor. IIS es lo suficientemente listo para obligarlo a conseguir uno antes de establecer SSL del todo. Sin embargo, una vez que cuente con un certificado de servidor para establecer Requerir un canal seguro al accesar este recurso en el nivel master, aún para sitios que no tengan un certificado enlazado a ellos.

El truco aquí es poner atención a la ventana de diálogo Anulación de herencia (Inheritance Overrides) que aparece cuando selecciona Requerir un canal seguro al accesar este recurso en el nivel master. Seleccione sólo los que tienen el certificado enlazado a ellos.

Nota Configurar cualquier cosa al nivel de Propiedades master debe hacerse con cuidad, ya que los resultados pueden ser propagados a cada sitio, directorio virtual y archivo para el servicio WWW. SSL no es una excepción a esto. Sugeriría insistentemente que SSL sea establecido solamente a nivel de sitio o directorio virtual, y no al nivel master. Es muy fácil que inadvertidamente haga inaccesible su sitio Web a los usuarios. También, configurando SSL al nivel master significa que cada solicitud de https sea encriptada. Esto puede afectar significativamente el desempeño de su servidor.

Access Control List (ACL) Es una lista de cuentas de usuario y grupos de usuario y sus privilegios que es asociada con un recurso en particular.

Encriptación asimétrica Una clave es usada para encriptar y la otra clave para desencriptar.

Enlazando una dirección IP: combinación de números de puerto que IIS asocia con certificado de servidor.

Autoridad de Certificación (CA) Un tercero de confianza mutua que emite certificados.

Certificado de cliente Una parte de una identificación digital para los usuarios que accesan su sitio. Contiene información sobre el usuario y es "firmada" con una firma digital desde la autoridad de certificación que lo emitió.

Sitio Default Cualquier sitio Web que es enlazado al puerto 80.

Firma digital Un hash de un mensaje que es encriptado con la clave privada del que envía el mensaje.

Hashing El proceso en el que una copia de un mensaje en texto plano es ejecutada a través de una operación matemática que resulta en un valor hash que usualmente tiene 160 bits de largo. No es computacionalmente factible derivar el mensaje original desde el valor hash.

Verbo HTTP Los verbos HTTP son enviados por los usuarios del explorador y indican al IIS qué es lo que el usuario quiere hacer con el archivo solicitado. Puede leerse (GET) el archivo o escribir (POST) sobre él.

Paquetes de IP La unidad por la cual la información es enviada a través de las redes de información.

Ruteador de IP Una computadora u otro dispositivo, que "conoce" la dirección IP a quien está dando el servicio o ruteando.

Filtro ISAPI Una aplicación, generalmente un DLL, que está frente a IIS y actúa como un filtro a las requisiciones que llegan a IIS.

Longitud en bits de la clave (o fuerza en bits) La longitud, en bits binarios, de una clave. Los mensajes encryptados por claves mayores son más difíciles de quebrantar que los que tienen claves más cortas.

Par de claves Un par de valores únicos que son usados para establecer una conexión SSl, encryptar información que está siendo transmitida, o ambos. En la criptografía de una clave pública existen una clave privada y una clave pública. Los mensajes que la clave privada encripta pueden sólo ser desencriptada con la clave pública, y viceversa.

Identificación de redes Una dirección de IP de base que es usada como un punto de referencia para comparar las direcciones de IP de las requisiciones que van llegando.

Encryptado de clave pública Un método común de encryptado que usa un par de claves asimétricas para encryptar y desencriptar mensajes.

Certificado de servidor Una parte de la identificación digital para su servidor. Contiene información sobre el servidor y es "firmado" con una firma digital desde la autoridad de certificación que la emitió. También contiene una clave usada para formar una conexión SSL. Debe tener un certificado de servidor enlazado a su servidor para poder usar SSL.

Clave de sesión Una clave encryptada creada durante el establecimiento de la conexión a SSL. Esta clave es conocida sólo para el usuario y el servidor y es usada para encryptado simétrico.

Máscara de subred Un numero que especifica qué bits de la identificación de la red serán usados como una operación AND (bit-wise) con las direcciones de IP que acompañan la requisición.

Encriptación simétrica Donde la misma clave es usada para encryptado y desencriptar de mensajes.

El paquete de recursos de IIS es otro gran recurso. El capítulo sobre seguridad toca el tema sobre algunos atentados que podrían ser hechos contra su sitio, y qué debe hacerse al respecto.

El paquete de recursos de Windows NT contiene una plethora de ideas, información y sugerencias sobre la seguridad de Windows NT. Lo recomiendo ampliamente para su equipo de seguridad. Está disponible en TechNet de Microsoft.

"Cómo solucionar los problemas de los permisos para IIS 4.0" es un gran recurso de solución a problemas para una de las cuestiones más importantes de IIS. Infórmese sobre Q185874 en TechNet de Microsoft.