El concepto de «seguridad por oscuridad» viene ya de lejos. Imagino que, si hablamos de servidores web, nace de la necesidad de protegerse tanto de muchos ataques automatizados que pueden llegar a nuestro servidor web, buscando versiones de software vulnerables, como de la imposibilidad de realizar esas actualizaciones o frente a ataques «0 day», para los que no hay ningún parche disponible.

Hoy vamos hablar de una herramienta interesante que ya mencioné  hace más de un año en el pasado FIMP. Se trata de «Whatweb», (acceso a la web del proyecto y su lugar en GitHub). Se trata básicamente de una herramienta capaz de identificar las versiones instaladas de la gran mayoría de CMS (gestores de contenidos) actuales, plugins y una gran variedad de aplicaciones web. También proporciona datos tan relevantes como versiones de Apache, SSL o PHP a través de la información extraída de las «cabeceras» o «banners» que lee cuando realiza una petición al website en cuestión.

"Features" (Según se lee en la web del proyecto):
	* Over 1000 plugins
	* Control the trade off between speed/stealth and reliability
	* Plugins include example URLs
	* Performance tuning. Control how many websites to scan concurrently.
	* Multiple log formats: Brief (greppable)
          XML, JSON, MagicTree, RubyObject, MongoDB, SQL.
	* Proxy support including TOR
	* Custom HTTP headers
	* Basic HTTP authentication
	* Control over webpage redirection
	* Nmap-style IP ranges
	* Fuzzy matching
	* Result certainty awareness
	* Custom plugins defined on the command line

Por lo general, simplemente dentro del directorio desde donde hayamos descargado Whatweb, ejecutamos;

Buscando información con Whatweb y «Server Spy».

dabo@debian:~/whatweb$ ./whatweb *****web_muy_conocida.com

http://******.com [302]  HTTPServer[Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g], RedirectLocation[/es/], X-Powered-By[PHP/5.2.6-1+lenny13],

Como podéis ver, ese servidor, revela mucha información. Pero no hace falta usar nuestro apreciado Nmap ni otras técnicas más complejas a la hora de recopilar información. Si ponemos como ejemplo Spotify, hubiese bastado con una extensión para Iceweasel / Firefox tan simple como puede ser «Server Spy«.

Si hablamos de la detección de versiones en un gestor de contenidos tan utilizado como WordPress, sobre el que hace unos días escribí una entrada con medidas para mejorar su seguridad, junto a una recopilación de  20 plugins recomendados, vamos al siguiente párrafo…

Como ejemplos bajo WordPress, podríamos ver muchos sites tan visitados (supongo, que no es mi caso;) como la web del «incombustible» Sylvester Stallone (la foto de portada no tiene desperdicio), u otros tan visitados como Mashable funcionan con este CMS . (Aclarar que en muchas ocasiones, simplemente viendo el código fuente, además de la versión de WordPress, también se suelen revelar muchos otros datos de interés).

dabo@debian:~/whatweb$ ./whatweb http://****web_muy_conocida.com/

http://******.com/ [200] X-Powered-By[PleskLin], WordPressSpamFree[2.1.1.1], HTML5, HTTPServer[Apache], WordPress[3.2.1], JQuery, UncommonHeaders[x-pingback], MetaGenerator[WordPress 3.2.1],

Ahí, incluso vemos algún plugin como WordPressSpamFree y su versión, además de la propia de WordPress. Pero en este caso, el servidor está mejor configurado si hablamos de «seguridad por oscuridad» ya que no revela la misma información que el que aloja la web de Spotify, la diferencia es la presencia por ejemplo de Plesk junto a WP.

Con un «simple» curl -i

Pero también, desde la línea de comandos, con una simple petición realizada con «curl«, ya sería suficiente para conseguir mucha información

dabo@debian:~$ curl -i spotify.com

HTTP/1.1 302 Found
Date: Mon, 24 Oct 2011 18:22:33 GMT
Server: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g
Location: http://www.spotify.com/
Vary: Accept-Encoding
Content-Length: 312
Content-Type: text/html; charset=iso-8859-1

El mismo ejemplo realizado con este blog (también bajo Debian y Apache, no vamos a descubrir/ocultar ahora la pólvora;) con esa petición vía curl, devolvería una mínima información.

dabo@debian:~/$ curl -i daboblog.com

HTTP/1.1 301 Moved Permanently
Date: Mon, 24 Oct 2011 18:25:04 GMT
Server: Apache
X-Pingback: https://www.daboblog.com/xmlrpc.php
Location: https://www.daboblog.com/
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/html; charset=UTF-8

Simplemente pone «Apache» y no se proporciona otra información. ¿Cuál es la diferencia?. Básicamente, la forma de evitar este exceso de información y por resumirlo en dos acciones a realizar (que hay mucho más, lógicamente), se trata de modificar lo siguiente.

Cambiando la configuración de Apache.

En la configuración de Apache (en Apache 2 y Debian estaría por defecto en /etc/apache2/apache2.conf)

Cambiamos los siguientes valores; «ServerTokens» por defecto está en “Full”, lo cambiamos a “Prod”. Otra directiva, «ServerSignature» por defecto está en “On”, lo cambiamos a “Off”.

Luego con un /etc/init.d/apache2 reload para que vuelva a «leer» la configuración de Apache sería suficiente ¿o no?.

Realmente no, ya que, a través de otra directiva por defecto que viene en la configuración de PHP, se revela también información acerca de estas cuestiones tal y como se puede comprobar aún con esa directiva cambiada en Apache con otro curl -i.

Cambiando la configuración de PHP.

Para ello, editamos el fichero de configuración de PHP, php.ini (En Debian o Ubuntu sería por lo general en /etc/php/apache2/php.ini). En otras distros al igual que con Apache (o httpd.conf) podéis buscar con un find / -iname php.

El valor «expose_php» por defecto está en “On”, hay que ponerlo en “Off” (no olvidéis hacer un «reload» a Apache para que cargue esta nueva conf de PHP). Esta directiva, además de revelar que está ejecutándose PHP, algo que no es un riesgo para la seguridad realmente, también proporciona información sobre la versión de Apache y en ocasiones del S.O, por lo que tampoco como se ha podido ver, no harían falta herramientas como xprobe o la función «fingerprint» de Nmap para saber que distro o versión de GNU/Linux corre en el servidor.

Como podéis ver, eso de «la seguridad por oscuridad» de oscuro tiene poco, yo diría que «clarifica» las cosas, aunque esto de la seguridad web es un concepto mucho más amplio, donde la «seguridad total» es un mito hablando de estos entornos. Estamos hablando de técnicas simples y nada intrusivas, pero que pueden hacer que nos llevemos algún susto si nos pilla con el pie cambiado alguna actualización, o sale el típico «0 day» (que nos puede pasar a todos). Nos vemos en el capítulo 2 de «/* Sec Tools */».