Cuando Microsoft sacó Windows Server 2003 con IIS 6.0 se dio un gran paso adelante en cuanto al paradigma secure by default. A diferencia de anteriores versiones, IIS 6.0 se instalaba con muchas de sus funcionalidades deshabilitadas por defecto (p. ej. extensiones ISAPI y componentes CGI), de forma que cada administrador debía habilitar explícitamente las funcionalidades que realmente fuera a utilizar. En una instalación por defecto de IIS 6.0 sólo se sirve contenido estático.
Con Windows Server 2008 e IIS 7.0 se ha dado un paso más en esta dirección, pero este tema ya lo trataré en un post separado.
En todo caso, aunque la instalación por defecto de IIS 6.0 ya nos proporciona un buen punto de partida en cuanto a seguridad, podemos tomar una serie de precauciones para hacer nuestros servidor menos susceptibles a ser atacados, y en el peor de los casos, mitigar las consecuencias de un eventual ataque exitoso. Estas son algunas de las recomendaciones que damos a nuestros clientes (no están ordenadas por importancia):
Reducir la superficie de ataque del servidor usando la herramienta Security Configuration Wizard for Windows Server 2003.Utilizar esta herramienta es una buena práctica para establecer un buen punto de partida del bastionado de los servidores IIS. Esta herramienta nos ayuda a determinar la funcionalidad mínima requerida para el rol o roles de nuestro servidor y nos permite:
· Deshabilitar servicios no requeridos.
· Bloquear puertos que nos están en uso.
· Aplicar restricciones a los puertos que dejamos abiertos.
· Deshabilitar las Web Extensions de IIS que no vayamos a necesitar.
· Establecer políticas de auditoría eficaces.
Utilizar Host Headers para los sitios web en IIS.El uso de Host Headers previene que un sitio web responda a cualquier otra URL que las que están configuradas como Host Headers. De esta forma podemos evitar ataques de escaneo de IPs. La mayoría de los gusanos se extienden mediante escaneo de IPs, por lo que podemos minimizar las susceptibilidad de nuestro servidor a estos ataques simplemente utilizando host headers.
Almacenar el contenido del sitio web en una partición o unidad de disco distinta a la del sistema y auditar los permisos NTFS. Esto nos permitirá protegernos de ataques del tipo directory traversal o backtracking en los que el hacker intenta acceder a ficheros de sistema mediante rutas relativas para obtener el control de la máquina. Restringir al máximo los permisos NTFS del contenido del sitio web es igualmente muy importante.
Desplegar los servidores IIS publicados en Internet fuera del dominio corporativo.Debido a la exposición de los frontales IIS a los ataques de Internet, siempre es recomendable tenerlos los más separados posible de la intranet corporativa y el dominio de directorio activo. De tal forma mitigaremos el potencial daño al resto de máquinas del dominio si la seguridad del servidor IIS se ve comprometida.
Usar URLScan 3.1 para bloquear peticiones potencialmente peligrosas.
Con URLScan podremos crear reglas para bloquear verbos HTTP específicos, extensiones de ficheros, secuencias de caracteres y aplicarlas de forma individual a uno o varios de los encabezados HTTP de cada petición.
Por ejemplo, podemos crear reglas para mitigar ataques de inyección de SQL, de forma que las peticiones cuyo querystring (o cualquier otro encabezado HTTP relvante como las cookies) cumpla una serie de requisitos serán bloqueadas y nunca llegaran a procesarse por nuestro servidor web.
La herramienta la podemos descargar desde aquí:UrlScan version 3.1 RTW - x86
UrlScan version 3.1 RTW - x64
Algunos recursos sobre la herramienta:
Common URLScan Scenarios
http://learn.iis.net/page.aspx/476/common-urlscan-scenarios/
UrlScan 3.1
http://blogs.iis.net/wadeh/archive/2008/10/31/urlscan-3-1.aspx
Habilitar extended logging de IIS
Los logs de IIS nos pueden proporcionar información valiosa sobre intentos de ataque y ataques exitosos a nuestros servidores web. Es recomendable habilitar extended logging de IIS configurado de modo que se registren todos los campos disponibles (por defecto no se registran todos). Adicionalmente, debemos almacenar los logs en una partición o unidad de disco distinta a la del contenido del sitio web y distinta a la del sistema operativo. Por último debemos restringir los permisos NTFS a la carpeta de logs. De esta forma dificultaremos la tarea del hacker a la hora de borrar sus huellas tras una ataque exitoso. Únicamente tendrán permisos full control sobre esta carpeta los administradores (y el sistema). Posteriormente debemos analizar regularmente dichos logs, lo cual podemos hacer, por ejemplo, utilizando Log Parser (ver post Análisis de logs de IIS utilizando Log Parser).
Auditar regularmente la seguridad de los servidores mediante el Microsoft Baseline Security Analyzer
Esta herramienta nos ayuda a identificar vulnerabilidades causadas por configuraciones y políticas inadecuadas, falta de actualizaciones de seguridad, y adicionalmente realiza una serie de comprobaciones específicas sobre la configuración de IIS.
Microsoft Baseline Security Analyzerhttp://www.microsoft.com/technet/security/tools/mbsahome.mspx
Espero que os sea de utilidad.
- Daniel Mossberg
Existen diversos escenarios en los que nos es útil saber qué método de autenticación está utilizando nuestra aplicación web y con qué credenciales se está ejecutando nuestro código. Para poder determinarlo de forma rápida he desarrollado una página ASP.NET que hace estas comprobaciones y muestra el resultado en pantalla.
Este es el código de la página ASPX:
<%@ Page Language="C#" Debug="true" %>
<%@ Import Namespace="System.Threading" %>
<%@ Import Namespace="System.Security.Principal" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
public string AuthType, AuthPackage, WindowsID, HttpContextID, ThreadID;
private AuthTypeEnum _authType;
internal enum AuthTypeEnum
{
Anonymous,
Negotiate,
NTLM,
Other
}
protected void Page_Load(object sender, EventArgs e)
_authType = AuthTypeEnum.Other;
GetIdentities();
Response.Headers.Add("Connection", "Close");
private void GetIdentities()
AuthType = GetAuthType();
AuthPackage = GetAuthPackage();
WindowsID = GetWindowsID();
HttpContextID = GetHttpContextID();
ThreadID = GetThreadID();
private string GetAuthType()
if (Context.User.Identity.AuthenticationType != String.Empty)
_authType = AuthTypeEnum.Negotiate;
return Context.User.Identity.AuthenticationType;
else if (!Context.User.Identity.IsAuthenticated)
_authType = AuthTypeEnum.Anonymous;
return "Not Authenticated (Anonymous)";
else
return "-";
private string GetAuthPackage()
if (_authType != AuthTypeEnum.Anonymous &&
Context.Request.ServerVariables["HTTP_AUTHORIZATION"] != null)
string authHeader =
Context.Request.ServerVariables["HTTP_AUTHORIZATION"];
if (authHeader.StartsWith("Negotiate TlRMTVNTUA"))
return "Kerberos";
return "NTLM";
private string GetWindowsID()
if (WindowsIdentity.GetCurrent().Name != String.Empty)
return WindowsIdentity.GetCurrent().Name;
private string GetHttpContextID()
if (HttpContext.Current.User.Identity.Name != String.Empty)
return HttpContext.Current.User.Identity.Name;
private string GetThreadID()
if (Thread.CurrentPrincipal.Identity.Name != String.Empty)
return Thread.CurrentPrincipal.Identity.Name;
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
<title>ASP.NET Identity Test</title>
<style type="text/css">
.style_div
font-family: "Consolas";
font-size: 22px;
.left
font-weight: bold;
width: 300px;
.right
color: #FF0000;
</style>
</head>
<body>
<form id="form1" runat="server">
<div class="style_div">
<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="left">
Authentication Type:
</td>
<td class="right">
<% Response.Write(AuthType); %>
</tr>
Authentication Package:
<% Response.Write(AuthPackage); %>
Windows Identity:
<% Response.Write(WindowsID); %>
HttpContext Identity:
<% Response.Write(HttpContextID); %>
Thread Identity:
<% Response.Write(ThreadID); %>
</table>
</div>
</form>
</body>
</html>