Telnet on Karpoke - Just Another Blog

Comprobar que no tenemos configurado Apache como un proxy abierto

Fri, 21 Sep 2012 16:53:00 +0100

Revistando logs de Apache, he visto que tenía algunas entradas del tipo:

93.174.93.52 - - [18/Sep/2012:02:23:11 +0200] "GET http://myproxylists.com/my-http-headers HTTP/1.1" 404 1046 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 (.NET CLR 3.5.30729)"
93.174.93.52 - - [20/Sep/2012:08:21:08 +0200] "GET http://myproxylists.com/my-http-headers HTTP/1.1" 404 1046 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 (.NET CLR 3.5.30729)"

Este suele ser el resultado de peticiones maliciosas que buscan encontrar servidores proxy abiertos. Si encontramos entradas de este tipo, lo primero que deberíamos hacer es comprobar que tenemos configurado el servidor correctamente, para no permitir hacer de proxy a peticiones de anónimos. De hecho, si no necesitamos un servidor proxy, lo mejor es asegurarnos que la directiva ProxyRequests no está inicializada a on.

Reiniciar el router desde el terminal

Thu, 09 Feb 2012 21:36:00 +0100

De vez en cuando, necesitamos reiniciar nuestro router. Por ejemplo, para provocar un cambio de IP, si tenemos IP dinámica. Podemos acceder al panel de administración del router mediante el navegador, normalmente en el puerto 80 u 8080, aunque también es posible hacerlo a través de telnet, en el puerto 22.

Para hacer más sencillo este trámite, utilizaremos un script que se conecta por telnet al router, introduce el usuario y la contraseña y lo reinicia mediante el comando reboot. Esto dependerá de cada modelo de router en concreto, pero creo que funciona para un gran número. En principio, no es posible apagarlo, sólo reiniciarlo.

Denegación de servicio en Apache utilizando la cabecera Range

Wed, 31 Aug 2011 14:19:00 +0100

Una vulnerabilidad descubierta por kingcope permite que los servidores Apache vulnerables sean susceptibles de sufrir una denegación de servicio.

La vulnerabilidad se encuentra en el uso de la cabecera Range. Esta cabecera se utiliza para obtener sólo una parte de la página. Si se solicitan varias partes además de pedir que la respuesta se comprima, mediante la cabecera Accept-Encoding: gzip, se dispara el consumo de procesador y memoria.

Existe un script que permite comprobar si el servidor es vulnerable y, si es el caso, explotar dicha vulnerabilidad.

Mostrando las cabeceras HTTP

Thu, 07 Oct 2010 10:35:00 +0100

Leyendo el artículo de análisis de cabeceras de SbD y, en particular, lo relacionado con las cabeceras no estándar, es decir, las que comienzan por X-, se me ha ocurrido que estaría bien ver qué debe haber por el mundo:

Suponiendo que el archivo sites.txt contiene un listado de los sitios que queremos comprobar:

$ for url in $(cat sites.txt); do
> echo $url
> curl -sI $url | grep "^X-"
> done > headers.txt

Es cierto que se podría haber realizado de otras formas: