Subscríbase al boletin de noticias de OpenKM para estar informado

Guía definitiva de seguridad para Joomla

Escrito por Josep Llort en febrero 13, 2018

Joomla es un sistema de gestión de contenidos (o CMS, por las siglas en inglés, Content Management System) que permite desarrollar sitios web dinámicos e interactivos. En los últimos años se ha popularizado enormemente su uso para la creación de sitios web, al igual que otras herramientas tales como WordPress. Estas herramientas permiten la creación de tu web tanto personales como profesionales, por ejemplo tiendas online; y facilitan el mantenimiento del contenido de las páginas web a usuarios no técnicos.

Podemos encontrar hostings a precios muy competitivos, que ofrecen soporte de bases de datos y scripts PHP; donde instalar tu sitio web basado en Joomla, así como tiendas online preconfiguradas, basadas en Joomla.

Su innegable éxito, ha hecho que resulte enormemente atractivo para los "black hackers" explotar vulnerabilidades con fines, más que dudosos.

Existe desde hace años en la comunidad "open source" un debate abierto sobre el hecho de si debería limitarse el acceso al código fuente de las aplicaciones; dado que el acceso libre permite que "personajes" con más que dudosos intereses, inviertan tiempo en localizar agujeros de seguridad, para su propio beneficio. El espíritu de la comunidad "open source" ha sido desde sus inicios, el de compartir el código bajo la premisa de que los usuarios de la comunidad sean colaboradores activos en las aplicaciones; mejorándolas, cooperando en la solución de errores y haciendo que éstas sean cada día más robustas. Pero no nos engañemos; este idealismo bien intencionado choca frontalmente con la realidad. No todos los humanos son bienintencionados; no todos son altruistas, no vivimos en UTOPIA. Desde mi punto de vista ambas posturas; "compartir versus cerrar" el código fuente de las aplicaciones, tienen parte de razón en la discusión, por lo que este debate abierto no creo que vaya a cerrarse pronto.

En el momento actual en el que nos encontramos, la velocidad de la red se ha incrementado hasta límites insospechados. Recuerdo aquellos años en que me conectaba a Internet a través de mi módem: los inicios de las descargas de los ficheros mp3; y cuando aparecieron los primero DVDRIP de 600MB, pensé que aquello estaba totalmente destinado al fracaso. Ficheros de 600MB por aquel entonces eran algo impensable para redes domésticas y sólo desde centros tales como universidades se podían conseguir velocidades aceptables para este tipo de descargas. Me equivoqué y hoy en día el ancho de banda es más que suficiente para este tipo de ficheros y para otros tipos de actividades.

Entre estos "otros tipos de actividades" nos encontramos con los programas malintencionados automatizados "BOTS"; cuya única misión es la de rastrear la Internet a altas velocidades buscando "sitios web Joomla con vulnerabilidades". A diferencia de los ecosistemas marinos, en la Internet, el pez pequeño pasa más fácilmente inadvertido y puede comerse al pez grande. Podemos encontrar distintos tipos de ataques: aquellos destinados a la DDOS ( denegación de servicio ), ataques por fuerza bruta que intentan logearse con el usuario "admin", o aquellos que aprovechan vulnerabilidades del gestor de contenidos web de Joomla, para obtener acceso a nivel del SO, instalando ROOT KITS, enviando SPAM, etc. Todos aquellos que en algún momento hayan administrado un sitio web Joomla, y que periódicamente vayan revisando los ficheros de log del servidor, pueden comprobar que casi a diario y de forma totalmente automatizada, se dan intentos de acceso malintencionados.

Problemas comunes en la gestión de contenidos con Joomla

Mantenimiento en el tiempo

Con Joomla me he encontrado con diversos problemas; uno de los más sangrantes quizás sea la dificultad de actualizar versiones un tanto antiguas. Expondré el caso; un usuario adquirió con el tiempo una plantilla comercial para una versión determinada de Joomla. La gran cantidad de plantillas de Joomla, la facilidad de instalación y las extensiones de Joomla, son unas de las funcionalidades que permiten de una forma muy asequible montar un sitio web basado en Joomla, con un coste económico realmente bajo.

Fácilmente podemos aplicar un diseño web a nuestro Joomla, adquiriendo una plantilla a un muy bajo coste; obteniendo un resultado final en las páginas web de tipo profesional. Los costes de un diseño web a medida para un sitio web son elevados, tanto en tiempo como en dinero; resultando esta solución altamente atractiva; de ahí el éxito de la misma.

El problema aparece cuando la versión del sitio web de Joomla va avanzando en el tiempo, pero la plantilla deja de ser compatible y no podemos alegremente subir de versión. He aquí la primera encrucijada: cambiar de diseño no es tarea fácil y más si algunas funcionalidades de dicha plantilla se basan en extensiones de Joomla, que con el tiempo terminan obsoletas. Aquí tenemos pocas opciones y ninguna es realmente agradable. Intentar actualizar a una versión superior, y aplicar las correcciones necesarias a nivel de código fuente, renunciando a aquellas extensiones de Joomla y funcionalidades obsoletas; o aguantar con una aplicación que ha quedado definitivamente desfasada y que no va a poder actualizarse. Nadie dijo que las decisiones fuesen fáciles; aquella web tan fantástica, rápida y económica que se montó 3 años atrás, se ha convertido en una cárcel. A medida que Joomla ha ido avanzando en su desarrollo, los procesos de actualización han sido más amigables; aunque si seguimos los foros de soporte, veremos que no exentos de problemas.

Extensiones Joomla

Existen millares de extensiones de Joomla; esto ofrece al CMS una gran versatilidad y potencia, pero a la vez es uno de sus talones de Aquiles. Por defecto, Joomla viene con un montón de extensiones que probablemente no necesites para nada. También hay que ir con cuidado a la hora de instalar versiones un tanto antiguas, que no se han ido actualizando. En definitiva; las extensiones de Joomla son terreno abonado de los "black hackers" para encontrar agujeros de seguridad. En todas las guías de seguridad que se precien, una de las primeras cosas que se indica es eliminar o desactivar tantas extensiones como no sea necesario. Aquí tenemos otro pequeño inconveniente; uno tiene que saber lo que desactiva, porque movidos por el impulso imparable de securizar nuestro sitio web, podemos fácilmente dejar el sitio web no operativo al eliminar alguna extensión.

Brecha de seguridad

Es más que posible que aunque hayas seguido todas las recomendaciones de seguridad y buenas prácticas, terminen accediendo a tu servidor. Personalmente esto me ha sucedido una vez y te queda un mal sabor de boca. En mi caso el sitio web que por aquellos tiempos administraba; quedó comprometido durante 2 horas. En 2 horas pueden pasar muchas cosas y ninguna buena. Diversas páginas PHP fueron modificadas añadiendo código malicioso y el atacante utilizó el servidor para enviar 150.000 correos. De esto hace ya más de 10 años; recuerdo perfectamente haber contactado con la brigada de delitos informáticos y prefiero no entrar en detalles; quiero pensar que las cosas han mejorado. No sabría decir qué me resultó más amargo; si la intrusión o el uso del servidor durante esas 2 horas. Me hubiese gustado hablar con el "camarada del bloque comunista", y decirle que por mucho talento que exista en una intrusión, de todos es sabido que es más fácil destruir que construir. Predicar en el desierto sólo puede reconfortar al própio espíritu.

Después de un ataque en que el sistema ha quedado comprometido, uno tiene que reinstalar el sistema operativo y la copia de seguridad. Y lo peor es que la herramienta por la que se han colado, te ha dejado una sensación de desconfianza que ya no desaparecerá.

Buenas prácticas

En muchos sitios web encontrarás gran cantidad de buenas prácticas. Algunas son obligatorias para cualquier ecosistema software, otras son más específicas :

• Leer con calma unas cuantas guías de instalación de Joomla y controlar el proceso de instalación.
• Realizar copias de seguridad, tanto de base de datos como de los ficheros del sitio web.
• Estar permanentemente actualizado a la última versión.
• Controlar periodicamente los logs de tu web.
• Eliminar el usuario admin.
• Establecer alguna extensión que proporciona mayor seguridad a los sitios web Joomla; tales como aquellas que bloquean al usuario que intenta logearse más de 10 veces desde la misma dirección IP. En definitiva, instalar contramedidas para los ataques basados en fuerza bruta. Podemos encontrar distintas extensiones enfocadas a solucionar este tipo de problemas.
• Instalar el mínimo de extensiones posibles.
• Usar siempre contraseñas seguras.
• Utilizar certificados SSL.
• Instalar herramientas a nivel del SO para controlar los cambios que tienen lugar en el sistema de ficheros ( trazabilidad de los cambios en el sistema de ficheros ).
• Intentar seguir las novedades en cuanto a agujeros de seguridad, tanto de Joomla como de sus extensiones.
• Permitir el acceso a las funcionalidades que realmente tus usuarios necesitan.

Después de haber hecho todo esto; ¿ Podemos estar seguros de que nuestro sistema de gestión de contenidos no va a ser atacado ? Desde mi experiencia, cuanto más potente sea el servidor en Internet donde tengamos nuestro sitio web Joomla, peor. La razón es sencilla; los "black hackers" quieren acceder a servidores potentes el máximo tiempo posible, para sus intereses. Los servidores potentes, en definitiva, son un dulce caramelo para estos personajes. Hemos mejorado nuestra seguridad; ya no será tan fácil, pero ten por seguro que eres su objetivo. Todo es cuestión de tiempo.

La solución

Esta guía definitiva pretende ofrecer una propuesta para todos aquellos que están buscando una guía de seguridad para aplicar a sitios web Joomla, más allá de las buenas prácticas convencionales.

Mi propuesta es simple; parte de la premisa de que cualquier sitio web basado en Joomla, es vulnerable de facto y por tanto el objetivo, es eliminar de base ésta vulnerabilidad. Es decir, que el sitio web Joomla no sea accesible directamente desde la Internet. Aquello a lo que no se tiene acceso, difícilmente va a poder ser hackeado.

Y alguien dirá; ¿ He tenido que leer toda esta disertación que ya sabía, para que ahora me digan que no puedo tener Joomla online ? ¿ Y entonces qué me están contando? ¿ Que no lo tenga instalado ? Pues no. Lo que digo es que si queremos securizar un sitio web Joomla, la mejor opción es no proporcionar acceso directo a él, a través de Internet.

Y si no proporcionamos acceso a directo a Joomla desde Internet ¿ De qué me sirve ? Pues mi propuesta es crear una imagen estática del sitio web y periodicamente ir actualizandola.

Imagina que tenemos un sitio web Joomla base; con el dominio www.sample.com podemos realizar el siguiente planteamiento:

• Un grupo de usuarios accederán al sitio web a través de private.sample.com
• Tendremos una imagen pública del sitio web en www.sample.com

Aunque existe algún intento en la dirección de crear alguna extensión en Joomla para publicar contenidos estáticos; en la presente fecha del artículo, no he localizado absolutamente nada que razonablemente funcione bien, o no pase de ser un solución experimental.

Creo firmemente que cualquier CMS que se precie, debe permitir la publicación de contenidos web de forma estática. Desde mi conocimiento actual, éste es un punto crucial a la hora de evaluar la implantación de una solución de este tipo y debería formar parte del proceso de selección. En OpenKM por ejemplo; después de evaluar distintas soluciones, nos decidimos por "crear nuestro propio sistema de publicación de contenidos estáticos" ( en un artículo futuro ya nos extenderemos en este tema con mayor detalle). A partir de nuestro gestor documental y "mediante el KCenter" ( Knowledge Center ) creamos una herramienta que nos permite publicar y mantener la web de forma estática. Éste artículo del blog, se encuentra en realidad alojado en uno de nuestros sistemas de gestión documental corporativos, y mediante una aplicación que hace de intermediario entre el gestor documental y el sitio web; actualizamos periodicamente nuestra página web. En nuestro caso particular,el hecho de disponer de una potente API en el gestor documental y la plataforma KCenter- que ya nos ofrecía gran parte de las funcionalidades que necesitábamos para la solución - nos permitió en menos de una semana, desarrollar nuestro propio sistema de publicación de contenidos estático.

No hemos quedado exentos de recibir ataques: nuestro log así lo demuestra. Pero al menos sabemos que no vamos a permitir el acceso por un fallo de seguridad en el gestor de contenidos, que escapa a nuestro control.

Propuesta de configuración

Configuración de apache para el sitio web Joomla:

<VirtualHost *:80>
  ServerName private.sample.com
  DocumentRoot /home/sample
  AcceptPathInfo On

  # security change from apache 2.4
  <Directory /home/sample>
	Options Indexes FollowSymLinks
	AllowOverride All
	Require all granted
  </Directory>

  CustomLog /var/log/apache2/private-sample-access.log combined
  ErrorLog /var/log/apache2/private-sample-error.log
  ErrorDocument 404 /messages/404.php
</VirtualHost>

Podemos definir el subdominio private.sample.com en nuestro DNS; o simplemente para aquellos usuarios que realmente vayan a administrar los contenidos del sitio web Joomla, añadir la entrada en el fichero de hosts.

Script de sincronización ( mirror del sitio web joomla ):

#!/bin/bash
#
echo -e "CLONE WEBSITE SAMPLE\n"
httrack http://private.sample.com -O /home/static/sample +*.sample.com -v --updatehack --update

echo -e "REMOVE local. from the url\n"
cd /home/static/sample/private.sample.com
rpl -x .html -x .html -x .js -x .txt -R private.sample.com sample.com *

echo -e "CHANGE PERMISSIONS\n"
chown static:www-data * -R /home/static/sample/private.sample.com
find . -type f -exec chmod 0460 {} \;
find . -type d -exec chmod 2570 {} \;
echo -e "DONE SAME !!!\n"

• La utilidad "httrack" nos permite crear una imagen del sitio web ( la primera vez que utilizamos el comando tenemos que quitarle los parámetros --updatehack --update ) .
• La utilidad "rpl" nos permite renombrar las url's private.sample.com a sample.com.

Podemos programar una tarea con el crontab para que se ejecute diariamente, por ejemplo cada día a las 11 de la noche:

# Edit this file to introduce tasks to be run by cron.
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
0 23 * * * /root/clone-static-sample.sh | tee /root/logs/clone-sample.$(date +\%Y.\%m.\%d_\%H.\%M.\%S).log

 Finalmente la configuración de apache para la imagen del sitio web:

<VirtualHost *:80>
  ServerName www.sample.com
  ServerAlias sample.com
  DocumentRoot /home/static/sample/private.sample.com
  AcceptPathInfo On

  # security change from apache 2.4
  <Directory /home/static/sample/private.sample.com>
	Options Indexes FollowSymLinks
	AllowOverride All
	Require all granted
  </Directory>

  CustomLog /var/log/apache2/sample-access.log combined
  ErrorLog /var/log/apache2/sample-error.log
  ErrorDocument 404 /messages/404.html
</VirtualHost>

Problemas de la solución

Esta solución tiene como mínimo un pequeño inconveniente; los formulario web. Si tenemos formularios web, éstos van a dejar de funcionar en una imagen del sitio web. ¿Tenemos que renunciar a los formularios web o aplicar un parche a la imagen del sitio web para que funcionen los formularios ? Mi consejo es desactivar los formularios web y no permitir la ejecución de scripts PHP, desde el sitio web imagen que hemos creado.

Conclusión

En este artículo he intentado proporcionar un enfoque distinto a la seguridad de los sitios web basados en gestores de contenidos. En especial todos aquellos que no permiten la publicación en estático. Es un punto de partida que puede aplicarse tanto a sitios web basados en Joomla, como a otros gestores de contenido. El ejemplo anterior y las herramientas utilizadas, se basan en el sistema operativo Linux; pudiéndose utilizar otros sistemas operativos y herramientas para obtener el mismo resultado.