Radio WordPress #15: Seguridad avanzada en WordPress

Hoy hablamos de seguridad avanzada, pero no de plugins, no, hablamos de WordPress, de cómo limitar el acceso al fichero wp-config.php, de las claves de autenticación de WordPress, del prefijo de las tablas, de cómo evitar el listado de ficheros desde apache y de cómo bloquear el debug de php y los mensajes de error.

El capítulo de hoy es bastante completo y de hecho se me ha ido de tiempo, es un poco más largo, pero os recomiendo que lo escuchéis y que pongáis en práctica lo que aquí os cuento, os va a ayudar mucho y os va a hacer la vida mucho más fácil.

CÓDIGO PARA EL .HTACCESS PARA BLOQUEAR EL LISTADO DE FICHEROS

Options -Indexes

CÓDIGO PARA EL .HTACCESS PARA BLOQUEAR EL ACCESO AL wp-config.php

<files wp-config.php>
order allow,deny
deny from all
</files>

COMPROBAR QUE ESTÁN DESACTIVCADOS LOS ERRORES DE PHP EN EL FICHERO .htaccess

define(‘WP_DEBUG’, false);
define(‘WP_DEBUG_LOG’, false);
define(‘WP_DEBUG_DISPLAY’, false);

Generador de Claves de WordPresshttps://api.wordpress.org/secret-key/1.1/salt/

[showhide type=»transcripcion» more_text=»Ver transcripción(%s más palabras)» less_text=»Esconder transcripción (%s menos palabras)»]

Transcripción

Hola a todos, esto es Radio WordPress.com, un podcast dedicado a todos aquellos que de una manera u otra convivimos con WordPress.

Mi nombre es Eduardo Collado, este es el capítulo 15 y hoy 16 de Enero de 2017 vamos a hablar sobre la configuración avanzada de WordPress para hacerle mucho más seguro.

La seguridad de WordPress comienza por WordPress, si no aseguramos Worpdress como debe de ser no habrá plugin que nos pueda ayudar.

En serio, no comprendo esa obsesión de mucha gente de poner plugins de seguridad, que los recomienden por todas partes pero que no recomienden asegurar el WordPress.

Realmente he estado pensado mucho en ello, no os creáis, y he llegado a la conclusión de que mucha gente simplemente no sabe cómo asegurar Worpdress mínimamente, por eso es tan importante el capítulo de hoy porque vamos a tratar ese tema, vamos a saber un poco más y vamos a poder asegurar un WordPress ya de una forma más avanzada de la que vimos el otro día.

—MÚSICA—

Vamos a empezar protegiendo nuestro fichero wp-config.php. Recordad que en este fichero guardamos cosas tan importantes como nuestro usuario y contraseña de base de datos y es sumamente importante protegerlo y no dejarlo ahí abandonado tal y como viene por defecto.

Este fichero ya sabéis que está en el raíz de nuestro WordPress.

Para proteger el acceso a este fichero podemos hacerlo de dos formas, ojo, no tienen por qué ser excluyentes sino que podemos compaginarlas.

La primera será modificando los permisos en nuestro servidor y la segunda modificando nuestro fichero .htaccess para que no sea accesible desde el exterior, lo ideal es usar las dos técnicas para protegerlo.

Los permisos de nuestros ficheros deberían de ser 644, es decir el propietario del fichero, el WordPress puede leer y escribir en el fichero y el resto sólo pueden leerlo.

Esto significa que si usáis un buen hosting cada web se ejecutará con un usuario diferente, como en Neodigit, pero cuiado, hay muchos sitios donde las webs las ejecuta el usuario de apache, y esto significará que se podría leer el fichero desde cualquier web del servidor, así que enteraros de cómo funciona el tema de permisos en vuestro hosting y si todas las webs se ejecutan con el mismo usuario salir de ahí corriendo, no perdáis el tiempo.

Los directorios tendrán permisos 755 ya que para entrar en un directorio es necesario ejecutarlo.

Ni que decir tiene que esa manía de poner a los ficheros permisos 777 es lo equivalente a pegarse un tiro en el pie, eso no lo hagáis nunca.

La protección por htaccess podemos hacerla con una directiva deny from all, os la dejo en las notas del programa, pero básicamente será:

<files wp-config.php>
order allow,deny
deny from all
</files>

Este código se introducirá siempre antes de cualquier línea del htaccess de WordPress.

—MÚSICA—

Otro tema interesante que se puede hacer es usar las Claves únicas de autentificación, las cuales se configuran en el wp-config.php. Estas claves se pueden configurar y cambiar tantas veces como queráis gracias al configurador de WordPress, os dejo el enlace en las notas del programa.

Es bueno que uséis esas claves, y de hecho es muy probable que ya lo tengáis configurado pues se configuran autómaticamente, pero si no lo tenéis configuerado hacerlo a mano, eso os permitirá que vuestros usuarios logados estén mucho más seguros.

—MÚSICA—

Otra de las cosas que podéis hacer es definir un prefijo en la base de datos único, tal y como comentamos ya en el tercer capítulo del podcast cuando os pedí que fuerais imaginativos en ese punto, que pusierais algo aleatorio.

Por defecto ese prefijo es wp_, pero claro, todo el Mundo sabe cual es el prefijo por defecto, así cualquiera que consiga un accceso a nuestro wordpress y puede hacer peticiones a la base de datos si pregunta por la tabla wp_options podrá ver cosas, sin embargo, si hemos usado otro prefijo se encontrará perdido y no podrá consultar pues no conocerá el nombre de la tabla.

Por supuesto el mejor sitio para configurar los prefijos es en el momento de instalar, pero si lo queréis cambiar luego ya no es tan sencillo y puede llevarnos horas y muchos momentos de frustración, así que acordaros de cambiarlo en el momento de la instalación, siempre.

Otra cosa que tenemos que comprobar es que nuestro hosting no nos permita el listado de ficheros, es decir, si ponemos dominio/wp-content que no nos muestre el listado de ficheros. Si nuestro hosting permite mostrar los ficheros de un directorio podéis simplemente indicar en el htaccess

Options -Indexes

Obviemente esto no es la solución, sino arreglarlo a nivel de servidor, pero como parche os puede servir

—MÚSICA—

WordPress tiene un par de cosas que no son necesariamente buenas, una es el mostar los mensajes de error, los cuales muestran información tal como el path absoluto dentro del servidor etc.. por defecto viene desactivado, pero no es mala idea asegurarnos que está desactivado comprobando en el wp-config.php que es así

define(‘WP_DEBUG’, false);
define(‘WP_DEBUG_LOG’, false);
define(‘WP_DEBUG_DISPLAY’, false);

[/showhide]