Timezone, consejos y trucos para php, mysql y nodejs

Demian Rodriguez nos da unos consejos para minimizar estos problemas.

1) Establecer como timezone default “UTC” tanto en el server como en la base de datos.
Ej en Debian:

#dpkg-reconfigure tzdata
#restart mysql

2) Para el caso de MySQL, las columnas de tipo DATE, DATETIME o TIME no almacenan info sobre el timezone, uno es responsable de saber en que formato esta la fecha para despues mostrarla correctamente al usuario. Para esto es recomendable guardar todas las fechas en UTC.

3) Al mostrar una fecha al usuario se debe convertir al timezone adecuado. Como?

PHP:

// mostrar
$fechaDeMysql = "2011-06-01 08:30:20";
$date = new DateTime($fechaDeMysql, new DateTimeZone("UTC"));
$date->setTimeZone(date_default_timezone_get());
$date->format(...);

// guardar
$fechaQueVieneDeNoseDonde = 'Mon, 15 Aug 2005 15:52:01 +0300'; // ya tiene timezone
$date = new DateTime($fechaQueVieneDeNoseDonde);
$date->setTimeZone(new DateTimeZone("UTC"));
// guardarla en mysql...

NodeJS:
Si aca no mostramos nada al usuario es re facil, no hay que hacer nada
El proceso usa el tz del SO. Pero tambien lo podemos forzar seteando la variable de entorno al principio del script:

process.env.TZ = 'UTC';

Como obtener una fecha de la db y mostrarla al usuario en el TZ correcto? No se, es una incógnita como sabe JS en que TZ está la fecha que saque de la db. Lo pregunté aca: https://github.com/felixge/node-mysql/pull/55

// guardar
/**
 * metodo re copado para formatear fechas 
 * return formatted date as yyyy-mm-dd H:i:s using UTC
 */
Date.prototype.formatUTC = function() {
	function pad(n) {
		return n < 10 ? '0' + n : n
	}
	var d = this;
	return d.getUTCFullYear()+'-'
	  + pad(d.getUTCMonth()+1)+'-'
	  + pad(d.getUTCDate())+' '
	  + pad(d.getUTCHours())+':'
	  + pad(d.getUTCMinutes())+':'
	  + pad(d.getUTCSeconds());
};

var fechaParaInsertar = new Date('Mon, 15 Aug 2005 15:52:01 +0300').formatUTC();

Tirar servidor web usando formularios de busqueda

El ataque y los motivos

En el mundo web es comun encontrar muchos errores a la hora de asegurar nuestras aplicaciones.

Una de las situaciones mas comunes es dejar el apache sin proteccion contra request multiples (mas de cien por minuto) y dejar los formularios de busquedas sin proteccion.

Los formularios de busquedas sobre sitios con un volumen importante de informacion normalmente son una gran oportunidad para tirar un sitio abajo durante un momento, y si armamos un cron, lo dejamos abajo todo el dia.

Obviamente este ataque es simple, muy casero y no presenta complicaciones para ejecutar o defendernos.

Un proceso de busqueda requiere mas que nada de dos factures, un servidor web que atienda la peticion y un servidor de bases de datos que procese la busqueda.

Vamos a plantear el tipico escenario Linux + Apache + PHP + MySQL (lamp).

Como la mayoria sabe, mysq hace cache de las busquedas, para no procesar una y otra vez la misma query, simplemente reconoce la query y retorna el resultados, por lo que nuestra primer pista es hacer busquedas aleatorias de “cosas”.

Por otro lado, cuando hacemos una query que tarda N segundos, PHP queda a la espera del resultado, por lo que Apache queda a la espera por decante, y como sabemos, apache tiene un limite de procesos.

Entonces, si logramos llegar a ese limite de procesos, apache se “congela” dejando de atender a los usuarios.

Si le mandamos a mysql miles de querys que sean imposibles de hacer cache, procesara una y otra vez… buscando que mysql se “muera”.

El resultado de esto es un sitio muerto que deja de funcionar.

Ejemplo de un codigo simple para matar a un website sin proteccion.

function getLetra(){
$letras=array("a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z");

$str="";
for($x=0;$x<6;$x++){
        $str.=$letras[rand(0,count($letras)-1)];
}
return $str;
}

for($x=0; $x<=100000; $x++){ $string=getLetra(); echo $r="wget 'http://www.sitio.com/buscador.php?q=$string' -O /dev/null & "; exec($r); }

Como vemos es un codigo muy simple y realmente efectivo para los sites que no han tomado las medidas de seguridad basicas.

Como protegernos

Antes que nada, configuramos el mysql con un timeout razonable.

Despues lo ideal es poner una rutina en PHP que controle los request que hace una misma ip, y bloquear la busqueda si se excede de lo “normal”.

Tambien se puede activar el modulo de proteccion mod_security y mod_evasive, el ultimo es ideal para evitar el ataque que explicamos anteriormente.

Leyendo Linuxeando, me entero en este post que How To Forge sacó una serie de guías para la configuración de un ISP (un servidor completo que ofrezca todos los servicios necesarios para un ISP y alojamiento web: servidor web Apache (con SSL), servidor de correo Postfix con SMTP-AUTH y TLS, servidor DNS con BIND, servidor FTP con Proftpd, servidor MySQL, Dovecot POP3/IMAP, Quota, Firewall, etc.).

Sacaron versiones para distintas distribuciones. Yo estoy esperando la de Slackware.

• The Perfect Server – openSUSE 11.0 (32-bit)
• The Perfect Server – CentOS 5.2 (32-bit)
• The Perfect Server – OpenSUSE 10.3 (32-bit)
• The Perfect Server – Fedora 9
• The Perfect Server – Ubuntu Hardy Heron (Ubuntu 8.04 LTS Server)
• The Perfect Server – Mandriva 2008 Spring Free (Mandriva 2008.1)
• The Perfect Setup – Debian Etch (Debian 4.0)

También hace un tiempo salió un documento de Implementación de servidores con GNU/Linux por Joel Barrios Dueñas.

Con respecto a otros sistemas operativos Unix, también está disponible esta guía para instalar un ISP en FreeBSD, pero por lo que estuve hablando con Cesar a esta guía le faltarían algunas cositas. Estaría bueno que Cesar publique su versión más completa y en castellano.

De más está decir que no pongo las manos en el fuego por NINGUNA de las guías nombradas, sino que esto es meramente para compartir información.

Dando vueltas por esto de la internet y la blogosfera en la mañana de ayer, encontré un par de videos bastante interesantes a cargo de Cuong Do, uno de los ingenieros que estuvo en el desarrollo de youtube desde el comienzo y ahora es manager del grupo de ingeniería del core del producto.

La verdad hasta el momento solamente vi entero el primer video, en el cual Do habla sobre la arquitectura de youtube y cuenta algunos problemas que tuvieron. Entre ellos destaca uno con la forma de almacenar los thumbnails directamente en disco en una estructura “plana” de directorios y que les generó en determinado momento un conflicto en el file system que no entendí exactamente cuál fue, pero lo terminaron resolviendo con una estructura jerárquica de directorios. Luego también habla de otro problema con MySQL y unas placas que tenían que generaban unos problemas de voltage y les daban unos quilombos con un checksum (muy loco).

En cuanto a la arquitectura habla de que tienen una serie de servidores de balanceo que envian los requests a los web servers, e internamente como ya sabemos los recibe Apache para el contenido dinámico y el contenido estático se sirve con lighthttpd. Y luego tienen los servidores de memcache y los de bases de datos. También habla de unos servidores que creo que son de Google que los usan para tener como “más a mano” los videos más vistos.

En cuanto a tecnologías repite un poco lo que ya se sabe: Servidores Linux (SuSE), Apache y Lighthttpd, MySQL 5.0.X, el 99% del código en Python y usan toda la serie de recursos de Google a las que accedieron luego de la compra (el motor de búsqueda, el file system, y todas esas cosas locas para procesamiento distribuido que tiene Google).

Este es el video:

Fuente: Gigaom.

Luego, viendo los comentarios del post vi que uno indicaba que en esta otra conferencia Do habría hablado de lo mismo, así que la dejo también porque es más larga (52 minutos).

Link a Google Video