Tal y como comenté en el post anterior sobre Amazon EC2, cuando diseñamos una aplicación es difícil a priori determinar cuáles van a ser los recursos que vamos a necesitar. Para lidiar con este problema podemos usar diferentes soluciones. En este artículo voy a explicar qué es Google App Engine y cómo podemos aprovecharnos de él para el desarrollo de nuestros proyectos.

Google App Engine es un servicio que ofrece Google en el cual podemos subir y ejecutar nuestros proyectos. Nosotros como desarrolladores únicamente hemos de preocuparnos de escribir código y subirlo al servicio. A partir de este momento nuestro proyecto se servirá desde la URL que tengamos asociada al servicio sin tener que preocuparnos de cosas como instalar un servidor, configurar los distintos servicios, agregar usuarios, agregar los dominios a alojar, comprobar que el servidor no se queda pequeño y ver si hay que contratar otro, etc. Además Google se encarga de que a medida que se necesiten más recursos ampliar el número de servidores en los que tu aplicación se ejecuta, sin que tú tengas que intervenir, de una manera transparente. Así te olvidas de tener que preocuparte por actualizar tus servidores, estar pendiente de que no te hayan hackeado el servidor y tienes alta disponibilidad y tolerancia a fallos de una manera sencilla.

Al igual que en Amazon EC2, en Google App Engine se paga en función del uso que le demos a nuestra aplicación, en esta página podéis consultar los precios del servicio. Una característica del servicio que nos viene muy bien en la época de desarrollo de la aplicación es que los primeros 500 MB de almacenamiento en disco, el primer GB de salida de datos y el primer GB de entrada son totalmente gratis.

Está claro que no todo son ventajas, algunos inconvenientes tiene en relación a EC2. Por ejemplo no puedes ejecutar código de cualquier lenguaje de programación ni usar la base de datos que quieras, estás limitado a usar o bien Java o Python como lenguaje de programación y su base de datos BigTable. Sin embargo desde mi punto de vista si tienes soltura con Python y un framework como Django y estás dispuesto (cosa que recomiendo si vas a desarrollar un proyecto grande en el que la escalabilidad va a ser un factor crítico) a usar una base de datos no relacional schemaless como podría ser MongoDB es una opción que recomendaría sin lugar a dudas.

Cuando desarrollamos una aplicación web que tiene proyección de convertirse en un proyecto grande a largo plazo siempre nos surgen una serie de preguntas que deberíamos de tener resueltas antes de poner nada en funcionamiento:

• ¿Cuántos recursos necesito para ejecutar la aplicación?
• ¿Qué servidor dedicado contrato?
• ¿Se quedará corto y se caerá el servicio enseguida o por lo contrario me sobrará servidor por todas partes y estaré pagando un dinero extra de forma inútil?
• Cuando el servidor tienda a quedarse pequeño ¿Cuánto tiempo voy a tardar en montar otro servidor y balancear la carga?

Este tipo de preguntas no son nada fáciles de responder a priori. Si nuestro servidor se satura la experiencia del usuario será muy mala y conllevará una mala imagen y un menor uso por parte de los usuarios, pudiendo hacer hasta que la aplicación fracase rotundamente.

Una solución a este tipo de problemas sería usar Amazon EC2 (Elastic Cloud Computing). Se trata de un servicio de Amazon en el cual tú contratas instancias de servidores dedicados, que no son más que máquinas virtuales, en función de tus necesidades. Hay varios tipos de instancias en función del uso que se le vaya a dar, instancias pequeñas para empezar y luego instancias que tienen mucha CPU (orientadas a ser servidores web) y/o instancias con mucha RAM (orientadas a alojar servidores de bases de datos).

El hecho de usar máquinas virtuales nos proporciona muchas ventajas. Podemos partir de una imagen base de una instalación de Linux y a partir de ahí configurarla a medida como queramos y guardarla como un modelo de instancia a usar en adelante. Cuando necesitemos un servidor nuevo lo único que tendremos que hacer es solicitar una nueva instancia y ejecutar ahí nuestra imagen personalizada (es un proceso que dura pocos minutos). Esta versatilidad nos permite ir añadiendo servidores o quitando en función de nuestras necesidades, de esta manera el gasto va acorde también al uso que requiera en cada momento nuestra aplicación. Es posible también automatizar este proceso mediante un script que controle el uso de recursos medio en nuestro conjunto de servidores, y que añada o quite servidores en función de la carga media total.

El precio de Amazon EC2 va en función del tiempo que tenemos en funcionamiento una instancia, del tipo de instancia, del uso de espacio en discos EBS (es un tipo de espacio en disco que nos proporciona Amazon ya que el disco de las instancias es volátil) y de la cantidad de datos transferidos.

Un ejemplo real en el que se usa Amazon EC2 es el caso del agregador de noticias Menéame, Ricardo Galli en su blog relata cómo tienen montada toda la arquitectura de red en EC2.

En resumen podemos decir que EC2 es una buena alternativa para montar nuestras aplicaciones web “en la nube”, ya que nos permite escalar recursos de acuerdo a nuestras necesitades. En una futura entrada hablaré de Google App Engine y de sus ventajas e inconvenientes respecto a Amazon EC2.

Memcached es simple pero a la vez muy potente, su objetivo es el de almacenar objetos en memoria RAM a los que podamos acceder a posteriori cuando sea necesario. Se puede almacenar cualquier clase de objeto que estará asociado a un identificador único.

Memcached no está pensado para sustituir a una base de datos ya que los objetos almacenados en ella no son persistentes, es decir, se almacenan únicamente en memoria RAM y nunca son volcados a disco. La clave es colocar a Memcached entre nuestra aplicación web y el sistema gestor de bases de datos que estemos usando (por ejemplo, MySQL). Cuando en la aplicación web se necesite un dato primero se consultará su existencia en Memcached, si el dato está disponible habremos obtenido el objeto deseado directamente de memoria RAM y a una velocidad mucho mayor que si se hubiera tenido que ir a buscar ese mismo dato a disco. En caso de que el dato no se encuentre en Memcached se procederá a obtener el dato del sistema gestor de bases de datos y a almacenarlo en Memcached para que la próxima vez que se intente acceder ya se encuentre en memoria. A continuación se puede observar el pseudocódigo equivalente a una parte de una aplicación web que use Memcached:

funcion obtener_objeto(objid)
{
   objeto = memcached_get("obj".objid)
   si(definido(objeto))
      devolver objeto
   objeto = basedatos_get(objid)
   memcached_set("obj".objid, objeto)
   devolver objeto
}

Por tanto sólo la primera vez que se necesite un objeto se tendrá que ir a disco a buscarlo y las sucesivas veces este objeto se encontrará en memoria para ser servido directamente. Esto es cierto mientras únicamente se produzcan lecturas en la base de datos, sin embargo cuando se producen escrituras la cosa cambia y hay que afrontar los problemas que surgen. Cuando se escribe un dato lo más sencillo es eliminar el objeto de memcached, de manera que la próxima vez éste no sea encontrado y se cargue desde el sistema gestor de bases de datos. Existen otras técnicas más complicadas para ganar en rendimiento en relación a las escrituras, pero se escapan de la visión general que se quiere dar en este artículo sobre este sistema. Para establecer un símil fácil de comprender para gente que ya conozca la arquitectura de un procesador podríamos decir que nuestra aplicación web es como la CPU, Memcached sería la caché L1 y el sistema gestor de bases de datos sería la caché L2. Memcached también permite agrupar servidores formando clústeres, de esta manera los datos se distribuyen entre los diferentes nodos del cluster y se gana en capacidad y en tolerancia a fallos.

En la propia página web de Memcached se puede ver como es usado en sitios web con grandes cargas de usuarios como la Wikipedia, Twitter, Youtube, WordPress, etc.

En definitiva se puede decir que el uso de Memcached es algo muy recomendado en nuestras aplicaciones web, ya que ayudará a que sean más escalables y que expriman aún más la capacidad de nuestros servidores.

Sería interesante saber cuando hay actualizaciones disponibles para posteriormente entrar a mano y realizarlas bajo nuestra supervisión de forma manual. Para ello he elaborado un script de gran sencillez cuyo cometido es el de actualizar la lista de paquetes disponibles en Debian/Ubuntu y posteriormente realizar una simulación de actualización del sistema, en caso de que se necesite descargar algo nos avisa mediante correo electrónico.

El contenido del script es el siguiente:

#!/bin/bash
LOGFILE=/tmp/log_aptitude
aptitude update  > $LOGFILE
aptitude -sy upgrade >> $LOGFILE
grep -q "Necesito descargar 0B" $LOGFILE
if [ $? -eq 1 ]
then
      cat $LOGFILE | mail -s "Se necesita actualizar el servidor" mi@correo.com
fi

Sustituyendo mi@correo.com por nuestra dirección de correo electrónico donde recibir las notificaciones.
Para añadirlo al crontab de forma que se ejecute cada 3 horas habría que ejecutar como root

crontab -e

y añadir la siguiente línea:

0 */3 * * * /root/scripts/aptupdates

Una vez hecho esto en el momento en que haya alguna actualización pendiente de realizar se nos informarán por correo, evitando así tener que entrar periódicamente al servidor y comprobar esto de forma manual.

Esta práctica es muy recomendable, pero no significa que nos cubra completamente, ni mucho menos. Gran cantidad de bugs no se comunican a los creadores del software hasta pasados unos días, semanas e incluso meses posteriores a su descubrimiento, pero lo que sí se crean son los denominados xploits o-day que circulan dentro de los círculos privados de determinados grupos aficionados a la seguridad. Estos xploits permiten en multitud de casos aprovechar una vulnerabilidad remota para ganar acceso a la máquina, en algunos casos directamente como root y en otros casos como usuario normal, pero una vez dentro el conseguir acceso como root se basa en ejecutar otro xploit local, cosa que suele ser de menor dificultad una vez dentro del sistema.

Con el fin de minimizar la probabilidad de que nuestro servidor sea hackeado este artículo quiere presentar (para los que no los conozcan) y recomendar encarecidamente el uso del conjunto de parches denominados Grsecurity. La definición que aportan en su web es la siguiente:

Grsecurity is an innovative approach to security utilizing a multi-layered detection, prevention, and containment model. It is licensed under the GPL.
It offers among many other features:

• An intelligent and robust Role-Based Access Control (RBAC) system that can generate least privilege policies for your entire system with no configuration
• Change root (chroot) hardening
• /tmp race prevention
• Extensive auditing
• Prevention of arbitrary code execution, regardless of the technique used (stack smashing, heap corruption, etc)
• Prevention of arbitrary code execution in the kernel
• Randomization of the stack, library, and heap bases
• Kernel stack base randomization
• Protection against exploitable null-pointer dereference bugs in the kernel
• Reduction of the risk of sensitive information being leaked by arbitrary-read kernel bugs
• A restriction that allows a user to only view his/her processes
• Security alerts and audits that contain the IP address of the person causing the alert

Este conjunto de parches podría en gran cantidad de casos, aún ejecutando en nuestro servidor un proceso que tenga alguna vulnerabilidad conocida, que esta vulnerabilidad pueda ser explotada.  Los mecanismos que añade al kernel para aumentar la seguridad son de un nivel que se escapa del objetivo de este artículo. Por poner un ejemplo, para aquellos que conozcan en que se basan las vulnerabilidades de tipo stack overflow y que alguna vez hayan experimentado con un xploit de este tipo diremos que Grsecurity introduce aleatorización en la dirección EIP de ejecución de los procesos, de forma que un offset precalculado y almacenado en el xploit no serviría para nada en un servidor con estos parches.

La instalación de Grsec requiere parchear el kernel, aunque se pueden encontrar kernels ya parcheados por internet yo recomiendo bajarse los fuentes de la distribución y parchear uno mismo a mano el kernel.

Una característica que me gusta mucho también de Grsec es que si lo activas puedes permitir que los usuarios sólo vean los procesos que están ejecutando ellos mismos, así nunca podrán ver información sensible de los procesos que otros usuarios estén ejecutando en el sistema.

Como conclusión final podemos decir, al igual que en otros artículo que esto aumenta la seguridad de nuestros servidores, pero en ningún caso nos hemos de dormir ya que continuamente aparecen nuevas vulnerabilidades que podrían afectarnos.

Más enlaces de interés para aquellos que quieran profundizar en el tema:

Página oficial de Grsecurity

Packetstorm

SecurityFocus

Cuando un atacante explota un fallo en un servidor y logra acceso, lo primero que suele hacer es cubrir sus huellas mediante la instalación de un rootkit. Esto puede implicar modificar binarios o librerías del sistema con versiones creadas especialmente para el caso; por ejemplo se podría sustituir el binario /bin/ls del sistema con una versión que no mostrase los ficheros que empiecen por una cadena en especial, así el atacante podría dejar ficheros en el sistema cuyo nombre comenzasen por esa cadena y nadie más podría ver que existen usando el comando ls.

Aunque existen mecanismos más complejos y eficientes para ocultar ficheros en el sistema (como por ejemplo modificando la syscall table del kernel con una versión alternativa de una llamada al sistema), este método es bastante común. El problema radica en que el administrador no se ha dado cuenta de que un binario ha sido reemplazado por una versión alternativa troyanizada, si tuviera algún método de realizar una comprobación automática podría detectar a tiempo este tipo de intrusiones.

Para conseguir detectar estas modificaciones de forma automática existe una estupenda herramienta denominada Tripwire, que genera una base de datos con un hash digital de los ficheros del sistema. Lo ideal es generar esta base de datos con el sistema recien instalado, antes de conectarlo a la red, así estaremos seguros de que está totalmente limpio. Una vez generada la base de datos podremos realizar chequeos periódicos de forma automática añadiendolo en el crontab, pudiendo configurar el software para que envíe un email al administrador en caso de detectar modificaciones en algún fichero.

El primer paso que un atacante realiza cuando consigue explotar el fallo a través de la aplicación web es el de descargar en el servidor alguna aplicación que le permita acceder remotamente de forma cómoda, como por ejemplo mediante una shell. En el caso de los gusanos creados especialmente para este propósito el comportamiento es muy similar, explotan el fallo, descargan el mismo gusano en el sistema y lo ejecutan para seguir infectado otros servidores.

El usuario sube al servidor esta aplicación maliciosa en un directorio en el cual tenga permisos de ejecución el usuario que ejecuta el servicio web, pero como estos directorios pueden variar entre distintas distribuciones se recurre a utilizar en la mayoría de casos el directorio en el cual todos los usuarios pueden escribir, es decir, /tmp .

Para intentar minimizar las oportunidades de éxito de este tipo de ataques surge la idea de marcar de alguna manera el directorio /tmp como directorio donde no se puedan ejecutar aplicaciones, sin embargo esto no es posible aplicarlo directamente a directorios, sino que se debe realizar sobre particiones completas.

Para lograr conseguir este objetivo sin la necesidad de modificar la tabla de particiones de nuestro disco duro vamos a recurrir a dispositivos loop. Básicamente lo que haremos será crear un fichero del tamaño que deseemos que tenga el directorio /tmp, y posteriormente montaremos este sistema de ficheros en el mismo directorio, marcándolo como no ejecutable para conseguir así nuestro objetivo.

A continuación se puede ver un código de ejemplo que crea un directorio /tmp no ejecutable con un tamaño de 1GB:

cd /var
dd if=/dev/zero of=tmploop bs=1024 count=$((1024*1024))
/sbin/mke2fs tmploop
cp -R /tmp /tmpbak
mount -o loop,noexec,nosuid,rw /var/tmp0 /tmp
chmod 0777 /tmp
cp -R /tmpbak/* /tmp/

Esto nos dejaría /tmp preparado, ahora habría que borrar /tmpbak cuando hayamos comprobado que todo ha ido correctamente. Sin embargo cuando el servidor sea reiniciado estos cambios se van a perder. Para que esto no ocurra habría que añadir la siguiente línea al fichero /etc/fstab :

/var/tmploop       /tmp    ext2    loop,noexec,nosuid,rw  0 0

La biometría abarca el estudio de todos aquellos métodos que permiten reconocer de forma única a una persona, estos métodos son denominados técnicas biométricas. Para que este reconocimiento sea efectivo el método usado se ha de basar en alguna característica reconocible que sea totalmente diferente entre dos personas, como por ejemplo el reconocimiento de la huella dactilar.

Gracias a la biometría se pueden agilizar muchos procesos que se ejecutan miles de veces cada día y también garantizar que se mantengan unos ciertos niveles de seguridad, como por ejemplo fichar al entrar y salir del trabajo o controlar el acceso a zonas restrigidas.

Sin embargo estas técnicas no son socialmente aceptadas; gran cantidad de veces los usuarios de estos métodos no ven con muy buenos ojos la introducción de estos sistemas, ya que se pueden sentir amenazados de diversas formas. Por un lado estos métodos permiten tenerlos más controlados y así evitar que se produzca la picaresca y por tanto se pierdan horas de trabajo (como el caso en el cual se ficha mediante tarjetas y los compañeros se las dejan unos a otros cuando saben que van a faltar al trabajo o llegar tarde).

Por otro lado hay ciertos métodos biométricos mediante los cuales un usuario puede ver comprometida cierta información de la cual no quisiera que nadie tuviera constancia; en el caso concreto del análisis de ADN además de reconocer al usuario podríamos conocer también si ha consumido ciertos tipos de estupefacientes en los últimos días (debido a que uno de los métodos para la realización de este test es el de tomar una muestra de cabello) . Este tipo de información podría provocar, aunque las sustancias que el empleado consuma fuera del horario laboral no estuvieran interfiriendo en el trabajo, el despido del mismo en la empresa.

En el caso concreto del reconocimiento de iris, algunos usuarios pueden ser un tanto escépticos ante la (inocua) luz que se proyecta en el ojo en la fase de reconocimiento, esto provoca un recelo a la hora de usar el mismo.

En resumen podemos decir que la biometría por sí sola no sirve para nada sino está asociada a una educación de los usuarios finales en el uso de la misma, que son los que terminarán haciendo uso o no de ella y por tanto determinando su eficacia.

En varios blogs se pueden encontrar soluciones a este problema, un tanto radicales bajo mi punto de vista, que hacen que cuando un blog te enlace directamente una imágen esta sea sustituida por otra en tiempo de ejecución, o incluso que no se muestre nada, ahorrando así todo el ancho de banda.

Sin embargo si nos paramos a pensar un poco, lo que nos gustaría no es que nadie nos hiciera hotlinking de las imágenes, sino que ese blog acreditara en alguna parte que la imagen está extraída de nuestro blog. Como no podemos obligar al propietario del mismo a que nos enlace o nos nombre en algún sitio acerca de donde ha sido obtenida la imagen, vamos a aprovecharnos para incluir la URL de nuestro blog en la imagen enlazada, para ello haremos uso de los archivos .htaccess de Apache y de la librería GD de PHP. Lógicamente no queremos que las imágenes que incluyamos en nuestro blog tengan incrustada la URL del mismo.

La idea es simple, cuando un blog nos enlace una imágen directamente la petición GET llegará al servidor con un campo HTTP_REFERER que no corresponderá con la URL de nuestro blog, en ese momento se invocará un script PHP al cual le pasamos la ruta de la imagen solicitada. Este script PHP se encargá en tiempo real de abrir la imagen, incrustarle la URL de nuestro blog y mostrarla.

Este es un ejemplo de una imagen enlazada directamente por nuestro blog:

Este es un ejemplo de como se mostraría la misma imagen si alguien nos hiciera Hotlinking:

Para conseguir incluir este sistema en cualquier página web es necesario usar Apache, con soporte de archivos .htaccess y tener instalada la librería GD en PHP.

Paso 1: Editar el archivo .htaccess e incluir lo siguiente sustituyendo tudominio.com por tu dominio.

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?tudominio\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{REQUEST_URI} .*\.(jpe?g|gif|bmp|png)$
RewriteRule ^(.*)$ /nohotlink.php?i=$1 [L]

Paso 2: Crear un archivo en el directorio raiz de la web denominado nohotlink.php e incluir el siguiente contenido, sustituyendo www.tudominio.com por tu dominio

<?php
function imagecreatefromfile($path, $user_functions = false)
{
$info = @getimagesize($path);

if(!$info)
{
return false;
}

$functions = array(
IMAGETYPE_GIF => ‘imagecreatefromgif’,
IMAGETYPE_JPEG => ‘imagecreatefromjpeg’,
IMAGETYPE_PNG => ‘imagecreatefrompng’,
IMAGETYPE_WBMP => ‘imagecreatefromwbmp’,
IMAGETYPE_XBM => ‘imagecreatefromwxbm’,
);

if($user_functions)
{
$functions[IMAGETYPE_BMP] = ‘imagecreatefrombmp’;
}

if(!$functions[$info[2]])
{
return false;
}

if(!function_exists($functions[$info[2]]))
{
return false;
}

return $functions[$info[2]]($path);
}

header(“Content-type: image/png”);
$im        = imagecreatefromfile($_GET['i']);
$width    = imagesx($im);
$height    = imagesy($im);
putenv(‘GDFONTPATH=’ . realpath(‘.’));
$white = imagecolorallocate($im, 255, 255, 255);
$grey  = imagecolorallocate($im, 128, 128, 128);
$black = imagecolorallocate($im, 0, 0, 0);
$orange = imagecolorallocate($im, 220, 210, 60);
$tamano = 10;
$texto = “www.tudominio.com“;
$tb = imagettfbbox($tamano, 0, “arial”, $texto);
$altura = $tb[3] – $tb[5];
imagefilledrectangle  ($im  , 0  , $height-$altura-2  , $width  , $height, $black);
$x = ceil(($width – $tb[2]) / 2);
imagettftext($im, $tamano, 0, $x, $height-4, $orange, “arial”, $texto);
imagepng($im);
imagedestroy($im);

?>

Paso 3: Descargar en el directorio raiz de vuestra web la fuente arial.ttf, la podeis obtener desde aqui.

Y listo, ya tendríamos todo en funcionamiento. Podemos hacer una prueba de si el sistema funciona usando el siguiente comando desde wget:

wget http://www.tudominio.com/alguna_imagen.jpg –referer=http://www.otrodominio.com

Normalmente en los procesos de autenticación interviene lo que denomicamos un único factor, entendiendo como factor cualquier método de autenticación en el sistema, como podría ser una contraseña, un código PIN, una huella dactilar, una secuencia de ADN… Sin embargo si queremos que este proceso de autenticación en el sistema sea más robusto lo ideal es hacer que intervengan dos factores (tres sería mejor, pero el proceso sería demasiado tedioso) siendo a esto a lo que denominamos autenticación multifactor.

Al comienzo de este artículo se puede ver la imágen de un RSA SecurID, un pequeño aparato con forma de llavero que únicamente posee una pantalla LCD en la cual es muestra un número, lo primero de todo hay que destacar que este aparato no posee ningún método de comunicación con el exterior, ni puerto USB, ni Wi-Fi, ni bluetooth, ni infrarrojos ni nada parecido, funciona aislado del mundo exterior. Cada 30 segundos el número que aparece en pantalla cambia por otro generado aleatoriamente, es decir, incorpora un generador de números pseudoaleatorios en su interior y una semilla que permite que esta secuencia sea diferente en cada SecurID. Esta semilla también está almacenada en el servidor de autenticación y por tanto haciendo una serie de cálculos rápidos puede saber en cada momento que número muestra nuestro aparato por pantalla.

Cuando vamos a autenticarnos en el sistema introducimos nuestro nombre de usuario y un número PIN que sólo nosotros conocemos seguido del número que aparezca en ese mismo instante en la pantalla del SecurID, a continuación si esta primera fase de autenticación se realiza correctamente el sistema procede a solicitarnos nuestra contraseña de usuario para acceder al sistema.

¿ Por qué ganamos seguridad usando este sistema ? Sencillamente porque si usamos un método tradicional de usuario y contraseña un atacante que por fuerza bruta logre adivinar la contraseña tendrá acceso al sistema, sin embargo con este método si el atacante conoce el nombre de usuario y contraseña no concerá ni el PIN necesario ni tendrá el RSA SecurID en su posesión para ver el número que aparece en pantalla. El caso de que el usuario pierda el RSA SecurID tampoco es problema ya que un atacante no conocerá el PIN necesario aunque pueda ver en pantalla el número que aparece en el momento de la autenticación.

Este tipo de medidas se han de tomar debido a que no podemos dejar que toda la seguridad asociada al proceso de autenticación recaiga en el usuario del sistema ya que se convertiría en la mayor brecha potencial.