Como hemos visto, las características propias de IIS y Windows 2000/2003 Server son adecuadas para mantener un nivel de seguridad razonable si se emplean con criterio. También es necesario comprender las implicaciones que estos ajustes de seguridad (y de configuración) tienen sobre el código que escribimos. De nada vale tener un IIS fortificado si nuestro código está escrito de manera descuidada y existen agujeros que se pueden explotar a través de peticiones lícitas a la aplicación. Por otra parte, aunque la seguridad básica esté bien gestionada y el código bien escrito continuamente se descubren nuevas vulnerabilidades, agujeros de seguridad y métodos de ataque ante los que estamos casi indefensos mientras no se libera un parche o se descubre una contramedida. Huelga decir que es fundamental mantener los sistemas correctamente actualizados, con los últimos parches y Service Packs. Sin embargo siempre ha de pasar cierto tiempo entre que se descubre un problema de seguridad, éste se hace público y el momento en que Microsoft publica la solución. En el ínterin nuestros sistemas se encuentran inermes y debemos intentar de que su exposición sea mínima. Parece obvio que cuantos menos frentes tengamos que defender más sencilla será la tarea. Es lo que se denomina comúnmente "disminuir la superficie de ataque". En este artículo vamos a conocer qué herramientas tenemos a nuestra disposición para disminuir los factores de riesgo de ataque exitoso y cómo impedir, incluso, ataques que intentan aprovechar agujeros desconocidos o sin solucionar. Las plantillas de seguridad Cualquiera que haya seguido un poco las diferentes vulnerabilidades de IIS y otros productos en los últimos años habrá observado que, en muchos casos, éstas se han debido a problemas en características y servicios accesorios que raramente se utilizan. Desde el momento en que tenemos en marcha un servicio innecesario o una característica que no utilizamos, se aumentan artificialmente las probabilidades de sufrir un ataque exitoso a través de éste. Hay que encontrar el equilibro entre funcionalidades y seguridad para estar razonablemente protegidos. Cuando me toca hablar de estos temas siempre me acuerdo de una máxima que nos repetían en la escuela de ingeniería: "Lo difícil no es diseñar una edificación que no se caiga, lo verdaderamente complicado es calcular una que casi no se caiga". Y es que cuando nos referimos a la seguridad informática nos encontramos en la misma situación: los métodos drásticos de protección no nos sirven de mucho pues no obtendríamos la funcionalidad requerida o un coste razonable, y los demasiado despreocupados tampoco porque estaríamos en peligro. Lo ideal es encontrar el punto justo de equilibrio en cada situación particular que nos mantenga protegidos sin escatimar funcionalidad. He ahí la dificultad. Para aprovechar la experiencia propia y la de los demás, Microsoft nos facilita una herramienta en el Kit de recursos de Windows 2000/2003 que va a ser de gran utilidad para conseguir este proverbial equilibrio. Su uso se basa en plantillas de configuración con instrucciones detalladas de cómo ajustar muchos de los parámetros que se refieren a la seguridad (desde ajustes en el registro o en el sistema hasta políticas de grupo). De este modo una vez que hayamos encontrado el punto justo que necesitamos podremos guardar los ajustes para reutilizarlos en el mismo servidor o en otros. También tenemos la oportunidad de reutilizar la experiencia de otros administradores en nuestro provecho. Podemos ver y modificar estas plantillas utilizando la herramienta "Visor de plantillas de seguridad" (que está disponible sólo en inglés con el nombre "Security Configuration and Analisys Tool IIS Templates"), he incluida, tras la instalación del Resource Kit, dentro de la carpeta C:\Windows\ResourceKit \Internet Information Services o equivalente. También podemos invocarla escribiendo "sectemplates.msc" desde la línea de comandos. Como se aprecia en la figura 1 existen diversidad de plantillas en las que se contemplan muchos parámetros de configuración (en la captura vemos algunos referentes al registro, pero hay bastantes más). Podemos partir de dos plantillas especialmente pensadas para IIS que se encuentran dentro del directorio c:\Archivos de programa\Resource kit llamadas secureinternetwebserver.inf y secureintranetwebserver.inf. Hay que tener en cuenta que, para poder acceder a ellas con la herramienta de la figura antes hay que copiarlas al directorio C:\Windows\security\templates y volver a ejecutar el visor. Una vez que hayamos decidido cuál es la configuración que más nos conviene podemos forzar su cumplimiento y auditarla gracias la utilidad SCAT. El SCAT (Security Configuration and Analysis Tool) no está accesible directamente desde la consola de gestión sino que hay que añadirlo a mano. Abra para ello una nueva consola de administración (escriba MMC desde la línea de comandos) y desde el menú "Consola·Agregar" o "Quitar complemento…" busque y añada el complemento "Configuración y análisis de seguridad". De entrada aparecerá solamente un nodo vacío con el mismo nombre que el complemento. Para poder auditar una política de seguridad debemos crear previamente una base de datos en el complemento. Pulse con el botón secundario del ratón sobre el nodo y escoja la opción "Abrir base de datos…". En el diálogo que aparece otorgue un nombre cualquiera a la nueva base de datos y en el siguiente paso elija la plantilla de seguridad que tenga preparada del punto anterior. Una vez hecho esto, y en apariencia, no habrá pasado nada. Sin embargo en el menú contextual del nodo aparecen algunas opciones que no estaban disponibles antes. Si escogemos "Analizar el equipo ahora…" obtendremos un informe detallado que compara la configuración real de nuestro servidor con la deseada (la que hayamos escogido en el paso anterior). En la figura 2 observamos un ejemplo en el que algunas directivas aparecen con un aspa denotando su incumplimiento. Se puede obtener un informe en un archivo de texto con todos estos resultados. Si estamos seguros de que todo lo especificado en la plantilla de seguridad es lo que nos conviene solamente hay que escoger la opción "Configurar el equipo ahora…" para que SCAT fuerce automáticamente al cumplimiento de todas las directivas de seguridad. Tenga cuidado con lo que hace puesto que determinados ajustes de seguridad podrían influir en el funcionamiento normal de sus aplicaciones Web si no tiene cuidado. Como norma general no utilice plantillas en servidores de producción sin haberlas probado concienzudamente en equipos de prueba en los que los posibles fallos sean tolerables. Esta pareja de herramientas es extremadamente útil y no sólo para configurar la seguridad de IIS, sino la del sistema en general. Añádalas a su caja de herramientas si le toca hacer este tipo de trabajos de vez en cuando. IIS Lockdown Tool Hace ya cierto tiempo Microsoft presentó una herramienta destinada a aumentar de manera automatizada la seguridad de IIS mediante el uso de un asistente. IIS Lockdown Tool, que así se llama dicha utilidad, ayuda a conseguir que en nuestro servidor sólo estén activadas las características de IIS que realmente necesitamos para trabajar, cerrando el acceso a todas las demás y por lo tanto disminuyendo las posibilidades de ataque. Esta utilidad viene integrada en las propias características de IIS 6.0 con Windows 2003 Server, por lo que no será necesario instalarla en este servidor; por esto serán las aplicaciones que se ejecutan sobre Windows 2000 Server las que realmente se beneficien de su uso. La última versión disponible de la herramienta es la 2.1 (aunque ya tiene más de dos años), y se puede descargar gratuitamente desde http://www.microsoft.com/downloads/release.asp?ReleaseID=43955. Ocupa algo menos de 300 Kb y, eso sí, sólo existe en el idioma inglés. El programa no necesita instalación alguna, y al ejecutarlo muestra un asistente que se describe con detalle a continuación. En primer lugar (figura 3) se nos pregunta de manera genérica qué tipo de servidor queremos configurar, para así ofrecernos diferentes opciones de bloqueo en cada caso. Hay opciones para casi todos los gustos, cubriendo gran cantidad de productos de Microsoft que pueden trabajar conjuntamente con IIS. Para nuestro ejemplo hemos escogido un servidor Web con ASP habilitado, que es un caso muy común. Conviene marcar la casilla de la parte inferior "View template settings" si queremos obtener mayor detalle sobre el proceso que se va a realizar. En el siguiente paso del asistente (figura 4) se escogen los servicios que deseamos mantener activados. En nuestro caso vamos a dejar activado solamente el servicio Web, pues lo demás no lo necesitamos. A continuación (figura 5) se ha de decidir qué tipos de archivo queremos dejar activos en el servidor para que se interpreten. En el ejemplo hemos mantenido únicamente la extensión .ASP, y en general será la opción más adecuada pues todos los demás tipos son conocidos por su peligrosidad potencial y además se utilizan en muy raras ocasiones. Es curioso que no hayan actualizado esta herramienta para limitar la ejecución de archivos ASPX, aunque para el caso que nos ocupa (protección de aplicaciones ASP.NET) tampoco tendría mucha utilidad impedirlas ¿verdad?. En el siguiente punto (figura 6) se eliminan todos los directorios virtuales y aplicaciones que IIS instala por defecto (como los ejemplos, el manual, la administración…) que deberíamos eliminar siempre en máquinas accesibles como ya comentamos en la anterior entrega de esta serie. También se sugiere la desactivación de WebDAV, que no se suele usar en aplicaciones Web salvo que deseemos permitir la gestión remota con carpetas (poco recomendable en Internet, no tan peligroso en Intranets). Las otras dos opciones de esta ventana ajustan los permisos NTFS de forma similar a la que ya hemos visto los dos anteriores artículos, impidiendo el uso de ciertos ejecutables y anulando los permisos de escritura en los directorios de la aplicación. Del último paso se hablará en profundidad enseguida, pero le recomendamos que mantenga el ajuste por defecto. Cuando llegue al final, el asistente aplicará todos los ajustes seleccionados (tarda un poco) y dejará al servidor en un estado mucho más seguro. Asegúrese de probar a fondo sus aplicaciones tras haber utilizado IIS Lockdown Tool ya que puede haber hecho inadvertidamente algún ajuste que las afecte y a lo mejor no funcionan como es debido. No se preocupe si necesita dejarlo todo como estaba. La próxima vez que ejecute IIS Lockdown Tool detectará su anterior ejecución y le dará la oportunidad de dejarlo todo exactamente igual, para posteriormente volver a probar con una configuración diferente si así lo desea. Si fuese necesario existe la posibilidad de ejecutar IISlockd.exe en modo automático, en el que los ajustes deseados se aplican en segundo plano, sin mostrar la interfaz de usuario. Si desea información sobre cómo hacerlo deberá leer el archivo RunLockdUnattended.doc incluido en el ejecutable. Protección ante ataques desconocidos con URLScan Hasta ahora hemos visto dos útiles herramientas que ayudan a proteger el servidor Web mediante configuraciones restrictivas de seguridad. Éstas, combinadas con unos permisos bien establecidos a partir de los conocimientos que hemos adquirido en anteriores entregas, harán que nuestras máquinas con IIS estén razonablemente a salvo. Existen ataques que tienen éxito a pesar de todas estas precauciones ya que aprovechan debilidades y errores de programación que todavía no han sido descubiertos o que no se han solucionado con el correspondiente parche. Ante este tipo de ataques conviene ser proactivos y no reactivos, es decir, lo ideal sería adelantarse a su existencia de algún modo para evitar que tengan éxito aun siendo desconocidos. Microsoft publicó dos semanas después de la primera versión de IIS Lockdown Tool una nueva utilidad que sirve precisamente para esto: URLScan. En un principio se trataba de una herramienta independiente, pero ahora está incluida en la instalación de IIS Lockdown Tool, concretamente en el último paso del asistente que antes he mencionado (figura 7). La gran mayoría de los ataques sufridos por servidores Web implican la utilización de alguna URL "extraña" o construida de alguna forma fuera de lo normal. URLScan es un filtro ISAPI que analiza todas las peticiones entrantes en el servidor Web y las discrimina en función de una serie de reglas que controla un archivo de configuración. Dado que la mayoría de los ataques necesitan utilizar técnicas similares para construir las peticiones de ataque (usan caracteres extraños, codifican las URLs con juegos de caracteres fuera de lo común, usan peticiones de un tamaño muy grande para aprovechar desbordamientos de buffer…), URLScan es muy efectivo a la hora de detectarlos. Cuando descubre algo "extraño" anula la petición, la cual nunca llega a IIS y por lo tanto se evita el ataque. Los parámetros que se pueden controlar sobre el funcionamiento de URLScan son muchos y están englobados dentro de las siguientes categorías: €    Métodos de solicitud de páginas y recursos. €    Codificación sospechosa de URL. €    Presencia de determinados encabezados en las peticiones. €    Presencia de caracteres no ASCII en la URL. €    Presencia de caracteres concretos en la URL. €    La extensión de los archivos solicitados.

El asistente IIS Lockdown configura URLScan a través de las indicaciones que le vamos dando en los sucesivos pasos, y a partir de las plantillas elegidas en primera instancia. Sin embargo no se facilita interfaz de usuario alguna para controlar al detalle el modo de trabajo de este útil complemento, por lo que es necesario hacerlo de forma manual. Su comportamiento se indica a través de los parámetros contenidos en el archivo URLScan.ini, ubicado en C:\Windows\system32\ inetsrv\UrlScan o en la ruta equivalente. En la figura 8 se observa el aspecto éste. Existen en el archivo multitud de entradas para configurar y afortunadamente todas incluyen un comentario adjunto, con una breve explicación sobre su utilidad. Al igual que en el caso de la herramienta anterior la forma de acceder a la documentación detallada de URLScan es un tanto retorcida. Dentro de IISLockd.exe (ver nota en el epígrafe anterior) está el archivo URLScan.doc, en el que encontraremos explicaciones detalladas de cada posible parámetro. Le remitimos a esta documentación para ajustarlo a sus necesidades. Advertencias sobre URLScan En este punto es necesario hacer algunas advertencias, ya  que la activación de URLScan produce algunos efectos secundarios que podrían afectar al correcto funcionamiento de nuestras aplicaciones a menos que afinemos su modo de trabajo a través del mencionado archivo. Primeramente he de advertir de que, por defecto, todas las URL con caracteres no anglosajones como tildes, eñes, diéresis, etc… dejarán automáticamente de funcionar. Y esto es válido no sólo para páginas .HTML, .ASP o .ASPX, sino que se aplica de igual manera a gráficos y otros recursos sobre cuyo nombre, en muchas ocasiones, no tenemos control alguno (por ejemplo si permitimos "subir" gráficos al servidor). Podemos evitar esto cambiando el parámetro AllowHighBitCharacters para que tome el valor 1, pero esto deja abierta la puerta a posibles ataques basados en UNICODE o UTF-8. Tampoco se permiten los puntos o los caracteres codificados con % en las rutas solicitadas, lo cual es un problema en archivos con espacios en su nombre, por ejemplo. Por otra parte, tras su instalación, URLScan se coloca como el filtro de mayor prioridad en IIS, tal y como muestra la figura 9. Esto puede interferir con otros filtros o extensiones ISAPI que deban transformar de algún modo las peticiones antes de que lleguen al servidor. Éste es concretamente el caso de las extensiones de FrontPage 2000, que de hecho se deshabilitan al instalar la herramienta. Si no colocamos URLScan por debajo de este tipo de extensiones en la lista de prioridades de la figura 9 dejarán de funcionar bien, así que no queda más remedio que probar a moverlo dentro de esta lista si se experimentan problemas. Además en este caso es necesario modificar el parámetro AllowLateScanning en URLScan.ini. Otra cuestión a tener en cuenta es que cuando se rechaza una petición inadecuada, ésta jamás llega a ser recibida por IIS, por lo que no aparece reflejada en los archivos de registro (log) del servidor. URLScan permite almacenar la información de todas las peticiones rechazadas en un archivo de registro propio que es muy útil para analizar su funcionamiento y detectar intentos de ataque. También se puede especificar un mensaje a mostrar o una URL a la que redirigir al usuario cuando se anule una petición. Esto último debemos hacerlo con cuidado puesto que no es recomendable dar demasiadas pistas de que el servidor está especialmente protegido y mucho menos de cómo lo estamos protegiendo. URLScan 2.5 La versión de URLScan incluida en IISLockdown Tool es la 2.0. Sin embargo Microsoft lanzó más adelante una nueva versión, la 2.5, que añade algunas nuevas mejoras y es recomendable que hagamos la actualización. Hasta hace poco no era posible instalar esta versión de forma independiente por lo que no quedaba más remedio que instalar previamente IIS Lockdown Tool con URLScan 2.0 y luego actualizar. Sin embargo hace un año Microsoft cambio la manera de empaquetar la instalación de la herramienta de forma que se pudiera instalar sola. En la dirección http://www.microsoft.com/technet/security/tools/urlscan.mspx encontrará información sobre este herramienta y un enlace a su descarga. Esta versión permite especificar el directorio en el que se quiere colocar el registro de actividad, habilita la posibilidad de registrar los ataques mediante peticiones de gran longitud así como limitar el tamaño de dichas peticiones. Aunque la utilidad de URLScan se ve algo disminuida en IIS 6 debido a que éste trae de serie muchas de las características de aquel, sigue siendo conveniente instalarlo y configurarlo con cuidado en Windows 2003 Server. En la página mencionada se explican todos los detalles al respecto. Antes de que Microsoft sacara esta nueva versión del instalador de URLScan, existían dos descargas diferentes del producto. Una de ellas se denominaba Baseline URLScan y la otra URLScan-SRP. La diferencia entre ellas estribaba en que la variante SRP impedía las transferencias "troceadas" de información al servidor, mientras que la otra no. Esta distinción hace que SRP nos protegiese ante 10 vulnerabilidades de IIS descubiertas en 2002 que tienen que ver con ello aunque no dispongamos del parche correspondiente (y por lo tanto también lo hará con vulnerabilidades desconocidas que aparezcan usando dichas técnicas), pero como contrapartida impedirá el funcionamiento de aquellas aplicaciones que deban enviar información al servidor usando truncado. Por otra parte SRP limita el tamaño máximo de los archivos enviados a 30 Mb. Por lo demás eran idénticos. Bien, la única variante que se puede descargar ahora con el nuevo instalador es la SRP, por lo que debemos tenerlo en cuenta. En resumen Las herramientas que hemos analizado en este artículo permiten una protección para IIS eficiente y sin necesidad de muchos conocimientos. Incluso en algunos casos impedirán ataques desconocidos o sin parchear. Debemos aprender a usarlas con corrección pero es indispensable seguir actualizando los sistemas y estar atentos a las novedades de seguridad que aparecen continuamente. En la próxima y definitiva entrega de esta serie vamos a ver algunos consejos de seguridad sueltos a mayores, y aprenderemos a usar herramientas para atacar a nuestros propios sistemas y así evaluar las medidas que hemos adoptado.