Monthly Archives: septiembre 2014

Securing Apache and PHP in Ubuntu

Many of us know that Linux is a very secure system and Ubuntu is nowadays one of the most chosen options by many system administrators, however, a basic installation is not always perfect and we need to “touch things” in order to make it as good as possible.

The problem in Linux, specially in version 12.04, is that a basic installation of Apache 2 and PHP leaves a lot of clues about what we are actually using, so the ideal scenario would be to hide such information to avoid as much as possible an external attack because we have provided, for example, the PHP version that the system is using. Image that, for some reason, tomorrow somebody discovers a lack of security in our PHP version and we are announcing widely in the server’s headers that this version is the one we use. This could potentially be used by hackers in order to attack our systems.

As an example of this just use the following command agains the IP address of a plan Ubuntu installation with just Apache and PHP:

curl -X https://direcciondelservidor

you would probably get something like this:

Date: Fri, 19 Sep 2014 13:09:20 GMT

Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.3.10-1ubuntu3.11

Obviously we are giving “too much” information to any possible attacker so what we need to do is to remove it. To do that we need to do the following steps:

Edit the file /etc/php5/apache2/php.ini and add or modify the following lines:

disable_functions = exec,system,shell_exec,passthru
register_globals = Off
expose_php = Off
display_errors = Off
track_errors = Off
html_errors = Off
magic_quotes_gpc = Off

Following that edit the file /etc/php5/apache2/conf.d/security and do the same operation but with the following lines:

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Header unset ETag
FileETag None

Finally we need to edit the Apache config file where you have defined your website. If you have not changed the default one then it should be /etc/apache2/sites-available/default, and as before we need to add/edit some lines. These ones need to go where you have defined your VirtualHost block:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* – [R=405,L]

These lines require to have the Apache’s module mod_rewrite activated, so in order to make sure it is being used, execute the following command:

sudo a2enmod rewrite

And finally…

sudo service apache2 restart

If everything went fine we can execute again the curl command against our server and we will see something similar to this:

Date: Fri, 19 Sep 2014 13:17:29 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN

Much better now, isn’t it?

 

Fixing Shellshock vulnerability in Ubuntu

These days we have heard about the Shellshock vulnerability that affects to many unix based OSs. Well, of course Linux is among them so it’s affected.

The first step is to check if you Linux (Ubuntu) version is affected, so in order to make a quick test open a terminal and run thefollowing commands (3 in total):

1)

env X='() { :;}; echo' /bin/cat /etc/passwd; echo 'Welcome to he Simple ShellShock Tester By Svieg';echo 'Your infos are at risk';

2)

env x='() { :;}; echo Your system is vulnerable update ASAP' bash -c "echo Visit svieg.wordpress.com for update info"
3)

env X='() { (a)=>\' bash -c "echo date"

If for some reason any of the commands return the text saying that the computer is vulnerable or in the 3rd one you get the date instead of an error message, then your computer is in risk.

Ubuntu has fixed the problem the 25th of September, so expect fixing the problem with the typical:

sudo apt-get update; apt-get upgrade

Asegurando Apache y PHP en Ubuntu

Muchos en este mundillo sabemos que Linux es un sistema operativo muy seguro y que Ubuntu es cada vez más la opción elegida por muchísimos administradores de sistemas, sin embargo, como todo, una instalación básica no es siempre perfecta y hay que tocar “cosillas” para que sea lo más perfecta posible.

El problema que tiene Ubuntu, especialmente la versión 12.04, es que una instalación básica de Apache 2 y PHP deja bastante rastro de lo que estamos utilizando y lo ideal sería ocultar dicha información para evitar lo máximo que podamos un posible ataque externo. Como ejemplo de ello ejecutad el siguiente comando sobre cualquier servidor que hayáis montado:

curl -X https://direcciondelservidor

y seguramente obtendréis algo similar a esto:

Date: Fri, 19 Sep 2014 13:09:20 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.3.10-1ubuntu3.11

Evidentemente estamos dando “demasiada” información a cualquier posible atacante así que lo suyo es eliminarla, para ello hay que realizar lo siguiente:

Editar el archivo /etc/php5/apache2/php.ini y añadir o editar las siguientes lineas:

disable_functions = exec,system,shell_exec,passthru
register_globals = Off
expose_php = Off
display_errors = Off
track_errors = Off
html_errors = Off
magic_quotes_gpc = Off

A continuación editad el fichero /etc/php5/apache2/conf.d/security y realizad la misma operación pero con las siguientes líneas:

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Header unset ETag
FileETag None

Finalmente hay que editar el archivo donde hayáis configurado vuestra página de apache. Si no habéis cambiado el archivo en cuestión debería de ser /etc/apache2/sites-available/default y añadir las siguientes líneas dentro del bloque

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* – [R=405,L]

Estas lineas requieren del módulo mod_rewrite de Apache, así que hay que asegurarse que esté activado con el comando

sudo a2enmod rewrite

Y finalmente…

sudo service apache2 restart

Si todo ha ido bien y ejecutamos de nuevo el comando Curl sobre nuestro servidor veremos algo parecido a lo siguiente:

Date: Fri, 19 Sep 2014 13:17:29 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN

Mucho mejor ahora, ¿verdad?

iPhone, MP4 y HTTPS … ¡dolor de cabeza!

En mi último proyecto en el que he estado colaborando he tenido que poner unos cuantos (¡¡muchos!!) videos en MP4 para ser reproducidos desde la web usando streaming. Después de muchas peleas, y ya sé que hay mejores opciones, me decanté por usar Video.js como reproductor ya que necesitaba que “algo” los reprodujera en cualquier navegador, incluso en los vetustos Internet Explorer 8 (Cosas del cliente!!) y no me quedó otro remedio..

En fin, que llegó la hora de lanzar el proyecto, todos tan contentos y de repente comprobamos que algunos videos no funcionan bien en móviles.. en fin, cosas del formato. Tras recodificar los videos que fallaban y ver que todo iba a la perfección alguien grita de forma casi agónica diciendo “No funciona en mi iphone!!!”. En ese momento se te queda la típica cara de imbécil y miras al “amigo” como si fuera el aguafiestas del siglo y lo primero que se te pasa por la cabeza es que o ha puesto mal la dirección o que algo mal está haciendo. Pues no, por una vez en la vida el “amigo” estaba accediendo a la dirección correcta, el video estaba bien codificado y el puñetero iPhone de las narices se negaba a reproducir el video, sacando una bonita X en medio de la ventana del reproductor.

Tras pegarme una mañana entera peleándome con el dichoso video y viendo que no iba “ni pa tras” se me ocurre la genial idea de probar los videos en otra máquina y acceder desde el móvil a ella y …. ¡oh sorpresa! ¡Funciona! Pero… pero… ¿qué diferencia hay? Pues, sencillo, nuestra máquina en producción usaba HTTPS (conexión segura) y la de prueba no. Pues sí, ese era el problema, tan sencillo como eso.

La historia es que el certificado que nos habían suministrado no contenía el “bundle” del proveedor o agente registrador. En teoría esto no es necesario para hacer funcionar un sitio web con https, pero se ve que al amigo “iphone” no le gusta la idea. Tras “investigar” un poco consigo ponerme en contacto con el proveedor que había generado el certificado y me mandan su bundle, lo instalo en nuestro servidor y,….. siiiiii…. funcionan… bueno a medias… Funcionan bien, solo que mi “pequeño” iPhone 4 no abre ningún video que esté a más resolución de 640 pixels de ancho, pero eso ya, obviamente, es otra historia.