Cinco consejos de seguridad para WordPress

Autor: Armonth | El viernes 25 de mayo del 2007 @ 20:46.

Con el tiempo y la experiencia uno se va dando cuenta de que los riesgos (siempre presentes) en la seguridad de scripts en PHP y especialmente WordPress (dado que es el que más conozco) se pueden minimizar. Aquí van 5 consejos enfocados 100% a WordPress para ello:

  1. Desactiva wp-db-backup. Los motivos son de sobra conocidos, un fallo en este plugin o cualquier otro fallo que dé acceso a una cuenta de administrador permite al atacante descargar una copia de la base de datos.

    Como administrador el atacante puede generar muchos daños: borrar artículos, comentarios, insultar en tu nombre, borrar usuarios, cambiarles las contraseñas pero si no puede hacerse con una copia de la base de datos "en principio" no puede saber la contraseña de los otros posibles usuarios. No es ningún consuelo y realmente ante un ataque lo mejor es cambiar las contraseñas de todos los usuarios pero si son muchos y esto no es posible es mejor que no acceda a la BBDD: mejor tener que cambiar una contraseña que no todas.

    Además, wp-db-backup guarda la BBDD en un directorio generado aleatoriamente dentro de wp-content: nunca se deben guardar backups accesibles por web, es mejor tenerlos fuera (y si aún así acceden a ellos es que ya tienen control sobre toda tu máquina). Un fallo en Apache podría hacer que medidas como el no mostrar el índice de ficheros dejarán de ser efectivas y obtener la BBDD fácilmente. Si aún así quieres usarlo algunas opciones a tener en cuenta son:

    • Añade un .htaccess en el directorio de backups que impida el listado de ficheros del directorio: 

      Options -Indexes

    • Obliga a introducir una contraseña para acceder al directorio de backups, en el .htaccess debajo de lo anterior añade:

      AuthUserFile /home/tuusuario/.htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require user usuarioparaacceder

    El directorio /home/tuusuario/ debe ser un directorio fuera del acceso a la web por ejemplo si el raíz de tu web es /home/tuusuario/tudominio.com el fichero .htpasswd debe estar fuera de tudominio.com: nunca dejes el fichero .htpasswd accesible por web.

    Una vez hecho esto, creamos el fichero .htpasswd con el contenido siguiente que será el usuario y la contraseña separados por dos puntos juntos (:): 

    usuarioparaacceder:contraseñaparaacceder

    Sobra decir que las rutas (/home/tuusuario) y usuarioparacceder_ debe coincidir en los dos ficheros.

  2. Elimina los ficheros de instalación y los importadores. Una vez hecha la instalación o actualización de WordPress se deben borrar los ficheros de instalación: 

    /wp-admin/install.php
/wp-admin/upgrade.php
/wp-admin/installer-helper.php

    El tercero es opcional (aunque todo código que no sea necesario es aconsejable borrarlo) mientras que el primero y segundo si no se borran son un agujero de seguridad del tamaño del Gran Cañón del Colorado. Luego además podemos borrar los importadores:

    Los importadores (los ficheros de dentro de wp-admin/import/) sirven para importar contenido (es decir: modificar la base de datos) desde otros sistemas de blogging por lo que pueden ser vulnerables a ataques otra vez más la máxima es: si no lo necesito lo borro. ¿Quién importa a WordPress entradas desde 15 sistemas distintos? Pues eso: borra los que no uses.

  3. Limita el uso de plugins. Los plugins suelen ser vulnerables. Sobretodo a ataques XSS (una plaga hoy en día). Si puedes prescindir de un plugin no lo dudes y hazlo.

    Los plugins que potencialmente son más peligrosos son aquellos que permiten la entrada de parámetros mientras que aquellos que solo devuelven una salida (por ejemplo: añadir un dato sacado de la BBDD al diseño de la web) lo son menos.

  4. Protege /wp-admin/. De la misma forma que en el primer paso hemos protegido el directorio de backups, podemos hacerlo para el directorio /wp-admin/, quizá sea algo molesto pero si sabes a ciencia cierta en un momento dado que tu WordPress es vulnerable en el directorio wp-admin y todavía no hay solución puedes activar momentaneamente esta restricción.

  5. Utiliza una cuenta de autor. El bug anterior es un buen ejemplo: permite editar información de usuarios si estás como administrador.

    Crea una segunda cuenta con privilegios de "Autor" y usara para escribir, comentar, moderar comentarios, etcétera. Si en algún momento tienes que des/activar un plugin o editar un comentario de otro usuario tendrás que entrar como administrador pero es un mal menor.

    Por ejemplo, mi usuario es un "Autor" pero mediante los "Roles" tiene como permisos extendidos editar páginas/entradas (propias), moderar comentarios (sólo permite los tuyos), subir ficheros y escribir HTML no filtrado. Mientras que el resto de "Autores" tienen permisos básicos pero no pueden moderar...

    Las tareas tales como activar plugins, importar, administrar opciones, editar ficheros / plugins / plantillas / usuarios, administrar categorías / encuestas o cambiar temas requieren que entre como administrador pero no suelo necesitarlo

  6. (Bonus) Lee sitios que anuncien fallos: aquí en SigT solemos dar la brasa bastante con temas de WordPress, además que considero más práctico parchear (cuando son pocas líneas) que no "obligar" a actualizar todo WordPress cada vez, en Buayacorp Alex suele dar la brasa a los desarrolladores de WordPress con fallos y en el Planet Webdev cada vez que aparece un fallo de seguridad damos la brasa a lo menos 10 bloggers distintos por cada Planet: sale un bug y aparecen 20 entradas ;).

  7. (Bonus II) Quita el usuario administrador: o mejor dicho: desactiva el primer usuario administrador. Truco sólo para gente que sepa lo que hace. Muchos exploits automáticos atacan al user_ID = 1 de wp_users en la base de datos, una posible táctica para que estos exploits fallen sería (aunque aviso que hay que probarlo bien, no sea que algún plugin o algo también falle):

    • Crea un nuevo usuario con permisos de administrador (para que tenga un user_ID distinto).
    • Deja el usuario admin antiguo como "lector" (sin privilegios).

Actualmente WordPress se ha ganado el nombre de WordStress a pulso pero considero que los desarrolladores trabajan duro para solucionar los problemas. Creo que poco a poco se hará menos común el ver tantos fallos seguidos en tan poco tiempo.

Comentarios