Una programación segura es muy importante, pero no podemos olvidar la plataforma del servidor en la que la aplicación reside, empezando por el sistema operativo y llegando hasta el software encargado de prestar el servicio HTTP, por lo que ciertos consejos de seguridad en lo referente a este último nunca deben despreciarse. Sin embargo debido a los diferentes tipos de servidores web y sistemas operativos, estos consejos pueden variar sustancialmente aunque los principios de protección sean los mismos.
IIS es una plataforma mixta de servicios web (HTTP/HTTPS, FTP, SMTP y NNTP) y las versiones con las que comunmente podemos conseguirnos son la 5, 6, 7 y 7.5. Sin embargo si usted actualmente tiene algún tipo de servicio en la primera de estas (versión 5) o anteriores, el mejor consejo que podría darle es que trate de mudar sus aplicaciones a cualquiera de las versiones superiores.
Entrando en materia a continuación mostraremos una lista de acciones o consejos que aumentarán la seguridad de este tipo de plataformas:
Reduzca la superficie de ataque apagando o eliminando los servicios que no necesita.
Ya que el IIS es una plataforma de servicios múltiples lo primero que debe hacer es reducir radicalmente la superficie de ataque apagando o eliminando los servicios de dicha plataforma que no se utilizan. Es muy sabido que un servidor SMTP mal configurado puede dedicar la mayor parte de los servicios de su sistema operativo a enviar SPAM. Tener un servicio FTP activo permanentemente es una brecha por la cual el atacante podría introducir sus scripts malignos en nuestra web. Y ni hablar del NNTP!
Desactive la opción de mensajes de error detallados.
Si bien en el ambiente de desarrollo esta opción es de gran ayuda, mantenerla activa solo sirve para que un atacante intente generar errores que le entreguen información adicional y le descubran algún dato que abra la brecha de seguridad esperada. Para información acerca de cómo desactivar esta opción en ASP.NET puede visitar este enlace. También puede manejar sus errores de forma dinámica, es decir haciendo que la página de especial de error que usted cree sea también una página dinámica que reporte el error a una base de datos o un archivo de registros personal, así como que envíe un e-mail dependiendo del tipo de error. Algunos ejemplos puede encontrarlos aquí.
Instale sus directorios de aplicación web en una unidad diferente a la unidad que aloja el sistema operativo.
En caso de que un atacante pudiera obtener acceso a la unidad en la que usted aloja su aplicación, usted agradecerá sobremanera que este no tenga a mano utilidades importantes del sistema operativo como cmd.exe y otros igualmente poderosos.
Remueva el mapeo de extensiones no utilizadas.
Su servidor probablemente pueda y esté listo para resolver el mapeo de extensiones asp, php, cgi y otras dependiendo de los diferentes módulos CGI o librerías ISAPI instaladas. Nuevamente, si usted no necesita ejecutar ASP clásico o PHP simplemente deshabilite este tipo de extensiones.
Use URLScan.
URLscan es un módulo que permite filtrar direcciones URL con determinadas características que pudieran considerarse como intentos de ataque. Inclusive actúa como una especie de firewall de aplicación que puede evitar una gran parte de los problemas. Sin embargo recuerde: la mejor manera de eliminar una brecha de seguridad en su aplicación es corregirla en el código en la que se origina. Descargue el URLscan aquí
Siempre utilice el sistema de archivos NTFS para las unidades en las que debe alojar sus aplicaciones.
El problema con los sistemas de archivo FAT y FAT32 es que no utilizan un sistema de control de acceso lo suficientemente cerrado como para alojar aplicaciones web en las que los recursos deban restringirse de forma eficiente o variadas. El sistema ACL de NTFS es muy superior y por tanto mucho más seguro.
Mantenga los archivos de registro de sus servicios web fuera del directorio de su aplicación.
Por defecto los archivos de registro se encuentran en el directorio "c:\windows\system32\logs" lo cual es perfecto, pero algunos administradores los ubican en otros directorios para evitar que los programadores u otros usuarios que los necesiten tengan acceso a un directorio tan crítico como este. La idea no es mala, pero tampoco se deben ubicar bajo el directorio web de nuestra aplicación. Los archivos de registros de IIS como en cualquier otro sistema, tienen un formato de nombre preestablecido, por lo que son muy fáciles de ubicar una vez conseguido un directorio "logs", "weblogs" o algo parecido mediante el uso de un scanner de rutas y archivos como por ejemplo OWASP Dirbuster. Usted no querrá que el atacante pueda obtener información detallada de la ubicación de los recursos simplemente bajando a su equipo uno de estos archivos.
Renombre, borre o restrinja el acceso a cualquier utilidad potencialmente peligrosa.
Quizás por esto es que principalmente hay que colocar la aplicación en una unidad diferente a la del sistema operativo. Sin embargo si en la unidad en la que está ubicada la aplicación usted encuentra alguna aplicación potencialmente peligrosa trate de eliminarla, restringir el acceso a la misma o renombrarla.
Desative el usuario "guest" y elimine el acceso de usuarios del grupo "guests" a áreas fuera de su directorio principal de IIS (webroot).
Usuarios como IUSR_machinename e IWAM_machinename pertenecientes al grupo "guests" no deben tener acceso a ninguna otra parte que no sea el directorio de la aplicación web. Tampoco deben tener atributos de escritura o ejecución en ninguna carpeta de sus aplicación. Utilidades para subir archivos necesitan a veces atributos de escritura en algún directorio, y si no puede evitar usar este tipo de componentes arcaicos, pues almenos en las propiedades del directorio seleccionado elimine todo tipo de permisos de ejecución de secuencias de comandos y archivos ejecutables.
Utilice si es posible los módulos de Restricción dinámica de IPs.
Este módulo relativamente nuevo, le permitira defenderse de ataques de DoS limitando las solicitudes múltiples de ciertas características que las pudieran identificar como intentos de DoS. Lo único malo de este módulo es que solo está disponible para IIS 7.0 y 7.5 - http://www.iis.net/download/dynamiciprestrictions.
Hasta la próxima...
Entradas
No hay comentarios.:
Publicar un comentario