Guía de seguridad de WordPress (Parte III: 10 Buenas Prácticas)

Desde su explosión en popularidad, todos los dueños de sitios web que lo eligieron —casi el 30% de la red en 2017, si incluimos los servicios de wordpress.com— tuvieron que empezar a considerar la seguridad de WordPress. Gracias a su naturaleza democrática, cualquiera puede instalar, escribir y ponerse a publicar sin complicaciones, pero por contrapartida cualquier hacker puede aprovecharse de esa misma facilidad. En esta tercera y última parte de la serie, investigo las buenas prácticas bien establecidas por la comunidad de usuarios que nos pueden guiar en el camino.

Guia de seguridad de WordPress - Parte 3; 10 buenas prácticas

 

 

Niveles de seguridad de WordPress

Cualquier webmaster sabrá que un CMS necesita una infraestructura sobre la cual funcionar; en nuestro caso es LAMP (Linux, Apache, MySQL, PHP).

Es decir, una caja basada en una distribución Linux que funciona como servidor web de aplicaciones, con Apache configurado para ejecutar PHP, que obtiene sus datos de una base de datos MySQL.

Esta es la forma mayoritaria de arreglarlo. El tipo de software puede variar (otro motor SQL como Postgresql o webserver como Nginx; PHP es obligatorio).

La parte generalmente más robusta de esta cadena es Apache. Es el proceso que se ocupa del tráfico de datos entre el destino y el cliente.

Le sigue PHP, con una reciente versión mucho más segura y rápida, la 7. La superficie más vulnerable reside en la base de datos. No por culpa del software, sino porque es consultada y escrita constantemente. Tanto por WordPress como por todos los plugins y themes que pueda haber instalados.

En este bajo nivel, la seguridad de WordPress o cualquier otro software es manejada por la empresa proveedora del servicio de hosting.

A no ser que sepas cómo configurar una caja a nivel comercial para varios sitios web en producción, no es algo que te tenga que preocupar. Aunque hay algunos conceptos que conviene saber en el caso de que sea necesario obtener soporte.

 

Consejos a la hora de obtener soporte de tu hosting

  1. El sitio web debe estar aislado de los otros en el mismo servidor. Esto es para evitar que un hacker obtenga acceso a varios dominios simultáneamente con sólo vulnerar uno de ellos.
  2. PHP debe estar configurado de determinada manera para poder acceder al registro de errores.
  3. Se debe poder acceder a los logs de tráfico y de error del servidor web.
  4. También es conveniente que el sitio se pueda configurar por medio de .htaccess.

La responsabilidad de un webmaster comienza al nivel de la aplicación de WordPress, incluyendo su configuración y su base de datos. No antes.

Ahora bien, una vez que contrataste el servicio y estás listo para instanciar un WordPress independiente, ahí sí es necesario tener en cuenta estos consejos:

 

Guía de las 10 buenas prácticas para la seguridad de WordPress

Estas 10 buenas prácticas provienen de la experiencia y de las particularidades de la seguridad de WordPress.

  1. Mantener al día tanto el núcleo de WordPress como todos los plugins instalados.
  2. No usar contraseñas fáciles.
  3. Tener una política de backups automatizados, guardados por fuera del servidor del que obtienen sus datos.
  4. No instalar plugins desde fuentes que no sean el repositorio de WordPress.
  5. No tener usuarios con privilegios administrativos innecesarios (por ej., no poner como Administrador al Editor). Esto es la aplicación de un principio llamado el “del privilegio mínimo”.
  6. Utilizar autenticación por dos o más factores (2FA o multi-factor authentication) en las cuentas de los administradores.
  7. No tener la dirección por defecto, wp-login.php o wp-admin, para ingresar al Dashboard, o incorporar una protección captcha. No tener un superadmin con el nombre de usuario “Admin”. Ocultar los mensajes de error del login.
  8. No permitir que se puedan editar los plugins o themes desde el Dashboard. Esto podría relacionarse con otro principio, el que dicta que, si alguna vez alguien se puede introducir a tu sistema, sólo podrá hacer el mínimo de daño.
  9. Utilizar HTTPS con un certificado SSL, gratuito desde la iniciativa de Let’s Encrypt.
  10. Comprobar que la estructura de directorios tenga los permisos adecuados. Esto podría resumirse en que los ficheros tengan uno tipo 644 de ellos, y los directorios, 755. Un caso especial es wp-config.php, o el .htaccess. Estos deben tener uno mucho más restrictivo, como 600.
  11. Bonus Track:

    Restringir el acceso vía XML-RPC (vía este plugin) y REST API (vía este otro), o deshabilitarlo si no se necesita realmente. Estos canales permiten que WordPress funcione en conjunto con otras aplicaciones, por ejemplo la de escritorio.

Foto de Andre Furtado en Pexels
Foto de Andre Furtado en Pexels

 

Conclusión

A veces puede resultar abrumadora la cantidad de alarmas sobre la seguridad de WordPress. En ocasiones, ciertas compañías en este negocio exageran el peligro. Pero otras tantas no, porque el riesgo es real. Tanto como la dark web.

Mantener WordPress a salvo es un trabajo constante, mantenido en el tiempo. Empieza por crear flujos de trabajo que actualicen regularmente el núcleo, los plugins y themes. Que protejan de alguna forma la página del login, mediante un captcha o la ocultación de su URL por defecto. Y que hagan lo suyo con las cuentas de usuario importantes por medio de doble autenticación (2FA).

Esto debe estar complementado por una solución, comercial o gratuita, para filtrar el tráfico HTTP. WordFence es el plugin más popular, aunque prefiero Shield. Existen otras soluciones livianas y que no necesitan de configuración, como Bad Behavior y Block Bad Queries.

 

Bonus Track: 3 principios útiles para la seguridad de WordPress

 

Defensa en profundidad (Defense in depth)

Este concepto consiste en considerar la seguridad como un proceso constante.

Además, tiene en cuenta los casos de fallo. Es decir que los procedimientos deberían servir también cuando un sistema es vulnerado.

Según la Wikipedia,

Defensa en profundidad es un concepto de la seguridad de la información que describe múltiples controles a través de un sistema. Su intencionalidad es proveer redundancia en el evento de que uno de estos controles falle o una vulnerabilidad sea explotada.

Probablemente derivado de la defensa militar, nos ayuda a dividir nuestra área de acción por capas.

Según el Codex,

… no hay una sola solución capaz de afrontar todas tus preocupaciones con respecto a la seguridad. En vez de eso, es más acertada una aproximación por capas de acuerdo a recursos complementarios entre sí. Cada uno diseñado para mitigar las limitaciones del otro. Si uno falla, aún puede ser detenido el ataque, o por lo menos ser capaz de verlo tempranamente y recuperarse.

Aplicado en la práctica, se puede armar una serie de medidas pensando en cómo se complementan. Por ejemplo: mantengo actualizado el núcleo de WordPress para evitar ser atacado mediante una vulnerabilidad ya conocida en versiones previas. Y aún así utilizo un firewall basado en web.

Si igualmente es vulnerada gracias a un tipo de agujero todavía no descubierto —llamado del tipo día cero o zero day—, el intruso no podrá plantar un virus o payload utilizando el Dashboard para modificar el código de los plugins o themes instalados, puesto que esto ha sido deshabilitado por configuración.

Y si está activo el logging puedo tratar de establecer el momento de la intrusión. Para revertir el estado mediante un backup guardado en la nube, previamente a que esto ocurriera.

 

Principio del privilegio mínimo o necesario (Least Privilege Principle)

Según la Wikipedia:

“En seguridad de la información, computación y otros campos, este principio dice que todo módulo —proceso, usuario o aplicación— debe poder acceder sólo a la información y a los recursos que le son necesarios para su propósito legítimo.”

Esto se puede aplicar al trabajo con clientes. Si por ejemplo un periodista quiere instalar o desinstalar plugins, de todas maneras no debería ser Administrador.

Tendría más capacidades de las que necesita. Lo que puede llevar a que la web quede más expuesta de lo necesario. Por supuesto, sólo si su cuenta fuera hackeada.

O bien que, con la mejor de las intenciones (y aunque resulte poco probable), active un plugin que genere problemas. Estos pueden tener relación con la compatibilidad, la seguridad de WordPress misma o la eficiencia.

Lo más aconsejable es hacerlo de tipo Editor con capacidades adicionales —como poder instalar o desinstalar plugins— utilizando User Role Editor.

El sistema predeterminado de usuarios de WordPress

La jerarquía predeterminada de niveles de usuario es:

  1. SuperAdmin
    El que instala WordPress por primera vez, podríamos decir el webmaster.
  2. Admin
    Quien tiene acceso a todas las características de edición: creación, publicación y destrucción de entradas, imágenes, videos y ficheros. También a los procesos relativos a la instalación, desinstalación, activación y eliminación de plugins y themes.
  3. Editor
    Quien puede crear, editar, publicar y borrar todo tipo de contenidos, tanto de su propia autoría como de cualquier otra. Algo parecido a lo que en ciertas películas sobre periodismo se llamaba el “editor en jefe” en una redacción.
  4. Autor
    Puede escribir, subir y publicar sus propias entradas y contenidos, sólo los suyos.
  5. Colaborador
    Similar al Autor en que puede escribir y editar, pero no publicar. Sus artículos podrían estar sujetos a la aprobación del Editor, por ejemplo.
  6. Suscriptor
    Es el rol por defecto al crear un usuario y por una buena razón. Puede publicar comentarios y sólo editar algunos datos personales.

 

Seguridad por ocultación (Security Through Obscurity)

Esta opción es la menos recomendable de todas. WordPress, al ser de código abierto, ya está en contra de ella. Sin embargo puede servir para aplicar en ciertos casos. Como cuando no es posible implementar determinada acción.

“Un sistema que depende en este principio de oscuridad puede tener vulnerabilidades teóricas o reales, pero sus diseñadores creen que ocultando sus fallas se prevendrá un ataque exitoso (…) Nunca debería ser el único mecanismo de defensa.”

Una práctica recomendada no hace mucho consistía en cambiar el prefijo por defecto de las tablas de la base de datos —que es wp_— al momento de la instalación. El argumento era que podría evitar un ataque por inyección SQL.

No obstante, no es así ya que el atacante no necesita saberlo de antemano. Además, está para poder configurar varias instancias de WordPress en una sola database.

Otro de los consejos más comunes que demostró ser innecesario es ocultar la versión de WordPress. Si aplicamos la buena práctica de mantenerlo siempre actualizado, resulta superfluo. No hay incidencias conocidas en una release actual.

De todas maneras, y como lo define el propio Códex:

La seguridad por ocultación puede ser valiosa en una estrategia de defensa en profundidad, pero no puede ser la única forma de proteger tu sitio.

Algunos casos en los que esta técnica se podría implementar son:

  1. Si hay un error de PHP o de MySQL, que se les muestre sólo a los administradores.
  2. Las notificaciones de actualización que sean vistas también sólo por administradores.
  3. Que los errores de autenticación en la página de login no se muestren, así no puede saberse dónde se originaron. Por lo tanto, evitando el acceso a los nombres de usuario.

¡Si esta información te resulta útil, tus comentarios y sugerencias son bienvenidos!

[Antes] < Guía de seguridad de WordPress (Parte I: La Dark Web)

[Antes] < Guía de seguridad de WordPress (Parte II: Malware)

1.11.2018 (6.11.2018)

Suscribite para recibir lo último en Design & WordPress

Dejá un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Do NOT follow this link or you will be banned from the site!