Tengo muchos intentos en mi servidor web (pequeño, personal y absolutamente sin importancia), y apache y fail2ban suelen hacer bien su trabajo. Pero hay una entrada de registro que me preocupa:
xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"
El problema es que la respuesta no era un código 404, sino un 200. Esta bien? Me parece extraño, pero mi conocimiento en este campo (y en muchos otros) es, por decirlo suavemente, limitado.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. La configuración predeterminada parece devolver una página de "Bienvenido a nginx" sin contenido significativo, en nuestro sistema ubuntu. Por lo tanto, es una respuesta 200, pero es una simple página general: en realidad no estamos representando la solicitud en otro lugar ni nada de eso.Respuestas:
Primero, desde el principio, no sé qué intenta lograr el presunto atacante. Tal vez haya un script PHP o una versión PHP vulnerable a algún ataque extraño de ID de sesión, no lo sé. Sin embargo, probablemente no tenga nada de qué preocuparse.
Su servidor se comportó exactamente como se esperaba. 200 es el código esperado en esa situación particular debido a cómo Apache interpreta la URL que se le pasa.
Primero,
http://allrequestsallowed.comse trata como el encabezado 'Host:' más habitual (tenga en cuenta que no creo que esto se especifique en el RFC y que otros servidores no puedan interpretarlo de esta manera.Estaba equivocado, esto se especifica en RFC 2616 en la sección 5.1. 2, aunque los clientes rara vez parecen usar ese formulario. Disculpe, necesito arreglar una implementación de servidor HTTP que escribí hace un tiempo ...).Ahora, presumiblemente no tiene un sitio llamado 'allrequestsallowed.com'. Entonces, ¿qué sucede cuando Apache obtiene un
Host:encabezado (o equivalente) para un nombre de host que no reconoce? Elige el primer host virtual como predeterminado. Este es un comportamiento bien definido y documentado para Apache. Entonces, sea cual sea su primer host virtual (o solo la configuración del servidor principal si no hay ningún host) se hace cargo, sin importar cómo se llame.Ahora, el resto de la URL dada consta de dos partes: la ruta
/y un parámetro GET (el?PHPSESSID...bit).Ahora, la ruta
/debería estar presente en casi todos los servidores web que existen. En la mayoría de los casos, se asigna a algo comoindex.htmlo tal vez unindex.phpscript, aunque, por supuesto, puede anular todo esto.Si se asigna a un archivo HTML estático, no ocurre absolutamente nada inusual: se devuelve el contenido del archivo, y eso es todo, simplemente se ignora el parámetro. (Suponiendo que no tenga determinadas directivas de configuración avanzadas establecidas, y casi con seguridad no las tiene).
Por otro lado, si se trata de un script de algún tipo, esa
PHPSESSIDvariable se pasará al script. Si el script realmente usa esa variable (en este caso particular, solo los scripts PHP que usan el manejo de sesión incorporado de PHP probablemente lo harán), su comportamiento dependerá de los contenidos.Sin embargo, con toda probabilidad, incluso si se
/asigna a un script PHP usando sesiones, no ocurrirá nada notable. El ID de la sesión probablemente no exista de todos modos, y será ignorado o el script mostrará un error.En el caso improbable de que la ID de la sesión exista, bueno, el atacante podría secuestrar la sesión de otra persona. Eso sería malo, pero en realidad no es un agujero de seguridad en sí mismo: el agujero estaría donde el atacante obtuviera la información de ID de sesión (rastrear una red inalámbrica es un buen candidato si no está usando HTTPS). En realidad, no podrían hacer nada que el usuario cuya sesión originalmente no pudo hacer.
Editar: Además, el '% 5C' dentro del SESSIONID se asigna a un carácter de barra diagonal inversa. Esto parece ser una prueba para ataques transversales de directorios en hosts de Windows.
fuente
nginxolighttpd, y después de enviar las IP / hosts de origen a una empresa de análisis cibernético, se confirmó que se trataba de explotar agujeros en el servidor, entre otras cosas. . Solicitudes similares a la especificada por el OP, diferentes hosts. ¿Estás diciendo que deberían ignorarse por completo? Porque si están realmente preocupados, pueden bloquear los hostsiptables.Tengo este allrequestsallowed registrado en una ip que se utiliza como registro A para todos nuestros dominios de estacionamiento.
Mi idea es que este nombre de host se usa en combinación con el archivo de host local del "atacante" que apunta al host de destino.
El servidor web real en 31.44.184.250 es solo para manejar solicitudes externas.
Mi opinión: totalmente inofensiva. No vea ningún uso de valor agregado, excepto las cosas que puede hacer con cualquier otro nombre de dominio falso en su archivo host.
fuente