Securizando WordPress

Como bien sabéis, los sistemas de gestión de contenidos (CMS) son cada vez más utilizados para la elaboración de páginas y blogs tanto personales como corporativos. Estos sistemas permiten mantener una página actualizada sin tener conocimientos avanzados de programación web, y pudiéndose instalar en un servidor de manera fácil y rápida. Uno de los sistemas más extendidos es WordPress. WordPress es un gestor de contenido libre, diseñado especialmente para gestionar blogs, y que contiene multitud de plantillas personalizables. Además destaca por su facilidad de uso, que permite que cualquier persona sea capaz de mantener actualizada la página en pocos pasos.

Hay dos opciones para utilizar WordPress. La primera de ellas es un servicio a través de la página wordpress.com y donde fácilmente cualquier persona puede crear su propio blog. La otra opción es instalarse la aplicación en un servidor propio o en un servicio de hosting. Son muchas las ventajas que podemos obtener al instalar un gestor de contenidos como WordPress en nuestro servidor, pero también son muchos los riesgos a los que nos exponemos. No han sido pocas las vulnerabilidades que se han ido encontrando en las diferentes versiones de WordPress, y muchas las personas que intentan sacar provecho de esas vulnerabilidades ya sea para insertar código malicioso, para obtener información o simplemente como un reto para ver de que son capaces de hacer.

Por tanto es conveniente tomar una serie de medidas para prevenir posibles ataques. Hace unos meses, desde CSIRT-cv INTECO ofrecían una guía bastante completa con una serie de recomendaciones y que os animamos a leer. Pero en este post queremos añadir alguna medida y resaltar alguna de las que en esa guía ya nos recomendaban nuestros compañeros del CSIRT, teniendo no obstante en cuenta que no son las únicas medidas a aplicar.

1. La primera es la más obvia y en la que siempre se hace especial hincapié, pero a la vez una de las más importantes, es la de mantener actualizada la versión de WordPress ya que el equipo de desarrollo del sistema va solucionando las vulnerabilidades que se van encontrando y además mejorando las funcionalidades del gestor. El principal problema en este caso es el tiempo y problemas que generan las actualizaciones del wordpress, cuyo proceso, a pesar de haber mejorado mucho a lo largo de los últimos años, no puede realizarse mediante el típico “siguiente-siguiente” o también conocido como guía-burros. A eso hay que añadir los aspectos de compatibilidad con plugins, por lo que aunque es un proceso totalmente recomendable y necesario, puede no ser trivial.

2. Cambiar el directorio web por defecto donde nuestro sistema carga los ficheros. Generalmente el directorio es httpdocs pero en algunos sistemas se permite cambiarlo. Para esto habría que cambiar los ficheros manualmente de directorio y después cambiar en el servidor la ruta del directorio principal de ese dominio en cuestión.

3. Otra medida es la de cambiar los puertos por defecto del servidor, tanto el FTP (por defecto 21) como el de SSH (por defecto 22). Esto no afecta solo a WordPress sino que es una medida que influye a todo el servidor pero que previene ataques automatizados.

4. Por otro lado también es posible extraer el directorio wp-content del directorio de la aplicación WordPress. En wp-content es donde se encuentran los temas, plugins y ficheros propios del blog. En http://codex.wordpress.org/Editing_wp-config.php#Moving_wp-content_folder se pueden encontrar los cambios que hay que hacer si queremos aplicar esta u otras medidas. Pero básicamente consiste en insertar estas líneas en el fichero de configuración wp-config.php:

define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' );
define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');
define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );
define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins');
define( 'PLUGINDIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );

5. Otra de las medidas a implantar es cambiar el prefijo con el que se crearán las tablas de la base de datos de WordPress. Por defecto es WP_, por lo que si no se cambia se corre el riesgo de sufrir ataques de inyección de código.

Además de estas recomendaciones, os remitimos a la guía que como hemos comentado al principio del artículo publicó el CSIRT-cv y donde se completan algunas de estas medidas y se comentan muchas otras que pueden hacer que nuestro WordPress sea menos vulnerable y evitarnos así más de un disgusto.

Si tenéis otras medidas o consejos que pueden ayudar a proteger un sistema WordPress, os invitamos a que las escribáis en los comentarios.