Securizando WordPress II

Tras la publicación y los comentarios surgidos a raíz del post donde comentábamos una serie de medidas para aumentar la seguridad del CMS WordPress (Securizando WordPress), me di cuenta que la inquietud y el interés en este tema es muy elevado. Por ese motivo queremos recoger en este artículo las recomendaciones que nuestros lectores han realizado a través de los comentarios a lo largo de estas semanas, y además añadir alguna otra que consideramos de interés y que no queremos dejar de compartir. Agradecemos desde aquí la colaboración de los lectores que con vuestros comentarios aportáis un valor añadido a este blog.

HenryGR nos recomendaba “cambiar el sitio completo de instalación y cambiar la ubicación del sitio y editar el archivo .htaccess” del dominio. Para los que no lo sepáis el archivo .htaccess es un fichero que permite definir directivas de configuración para cada directorio sin necesidad de editar el archivo de configuración principal de Apache. Si cambiamos el directorio de instalación de wordpress deberemos cambiar por tanto también el fichero .htaccess para indicar la ubicación definida. Esta medida la considero bastante interesante y está en la línea de lo que proponía en el primer artículo donde indicaba la recomendación de cambiar el directorio web por defecto httpdocs, aunque para esto deberíamos modificar en el servidor la ruta pública del dominio.

Cabe destacar en este artículo una herramienta que nos propuso Antonio Sanz (@antoniosanzalc) y que hemos tenido oportunidad de probar. Es un plugin denominado Automatic Updater for WordPress que “se encarga de detectar e instalar automáticamente nuevas versiones tanto de WordPress como de los plugins”. Una herramienta que nos facilita el mantener actualizado nuestro sitio web. De todos modos no podemos olvidar tampoco un apunte que realizaba el propio Antonio y no falto de razón. Esta recomendación consiste en no instalar plugins de los que no tengamos referencias o que no sepamos la procedencia de los mismos. En muchos casos los plugins o extensiones aportan una funcionalidad extra al sistema, pero pueden llegar a ser una “puerta de entrada” si no es adecuada su seguridad. Como recomendaba el propio Antonio en su comentario, se debe “buscar el número de versión, el número de descargas e investigar sobre al autor para intentar estimar la calidad del plugin”.

Antonio además en un comentario reciente compartía con todos los lectores de Security Art Work una presentación sobre Seguridad en WordPress, entre otras cosas con información que hemos ido recogiendo aquí, y un documento con varios enlaces muy interesantes sobre el tema. Gracias Antonio por compartir tan valiosa información.

Destacar de los enlaces anteriores uno que no podíamos dejar pasar. Es algo que nos trae de cabeza a algunos, y son los permisos que debe tener cada uno de los directorios o ficheros de la instalación WP. Si ponemos permisos restrictivos en algunas ocasiones no podemos instalar plugins automáticamente, actualizar de versión desde el panel, subir imágenes o archivos a un post, … perdemos funcionalidades que para usuarios no avanzados resultan interesantes. Pero si ponemos permisos 777 tendremos todas las funcionalidades accesibles (al menos por temas de permisos) pero dejamos al alcance de cualquiera el acceso y la edición a los directorios y ficheros del CMS. Por tanto debemos encontrar ese equilibrio donde se impida a un usuario no autorizado a acceder a los ficheros pero las funcionalidades estén disponibles. En ocasiones habrá que priorizar funcionalidad o seguridad porque aunque no son cosas compatibles en algunas situaciones nos podemos ver en esa situación. Estas son las paginas donde nos explican cómo llevar a cabo este cambio de permisos y como aconsejan desde WordPress: Hardening WordPress y Changing File Permissions.

A pesar de todas las medidas de seguridad que debemos tener en cuenta a la hora de instalar un blog con WordPress y que hemos contado en estos dos artículos, este gestor de contenidos sigue siendo uno de los más utilizados, de los más conocidos y de los más sencillos de utilizar, de ahí que tenga tanto éxito. Eso sí, no debemos olvidar y debemos tener siempre en cuenta los riesgos a los que estamos expuestos y las medidas que debemos llevar a cabo.

Comments

  1. Muy buenas tardes a todos,

    Al final todo es cuestión de poner en la balanza riesgo vs recursos. En nuestro caso, como no tenemos activos críticos que dependan de nuestros WP (no se acaba el mundo universitario), hemos definido nuestro procedimiento de esta forma para cada nuevo WP:

    1) Petición del nuevo WP por parte de un responsable identificado y registro de la misma (para que sepamos a quién dar con la palanqueta en caso de que pase algo malo)
    2) Instalación de WP con un usuario distinto de admin.
    3) Instalación y configuración del plugin Automatic Updater

    También hay que decir que esto solo es referente al propio WP. Cosas como copias de seguridad, cortafuegos, capar el FTP, etc … tienen que ir dadas por el servidor.

    Con estas 3 medidas sencillas deberíamos de cubrir como bien dice el amigo Pareto el 80% de las necesidades de seguridad de nuestro WP.

    Obviamente, para aquellos que tengan más recursos y/o su WP sea más crítico … se pueden hacer muchas cosas más (y para eso están post tan interesantes como estos).

    Un saludo,

    Antonio Sanz
    I3A/Universidad de Zaragoza

  2. Mejor con mod_rewrite y protegerse de inyecciones SQL y XSS, hay unas reglas sencillas con las que puedes evitarlas. Aparte tambien con otro htaccess deshabilitar la ejecucion de codigo en carpetas de los uploads. Otra cosa tambien es buscar los ficheros .txt .bak .conf …y otros sospechosos con find para quitarlos de ahí o directamente bloquearlos con directivas apache para que no sean transferidos.

    Salu2

  3. Hablamos de segurizar el WordPress… Puff pero que pasa con el vuestro ????

    Forbidden

    You don’t have permission to access /wp-login.php on this server.

    Apache/2.2.15 (CentOS) Server at http://www.securityartwork.es Port 80

    (Sacamos la versión de Apache y el sistema operativo)

    Robots.txt

    User-agent: *
    Disallow: /wp-admin/
    Disallow: /wp-includes/

    Sitemap: https://www.securityartwork.es/sitemap.xml.gz
    Google Sitemap Generator Plugin by Arne Brachhold

    Uno de los plugines que estáis usando

    Y esto con solo 3 consultas …

    El problema es que estamos invadidos por aplicaciones, plugins, parches olvidando estudiar. Solo aprendemos como se usan varios programas confiando plenamente en ellos. Es verdad las herramientas como Wpscan of @erwan_lr, @gbrindisi, @_FireFart_ & @ethicalhack3r nos ayuda mucho en nuestro trabajo pero no tenemos que olvidar que hay que estudiar, estudiar y estudiar ““Учиться, учиться и еще раз учиться”” como decía el abuelo Lenin (…mi Patria. Vivir, estudiar y luchar como …).

    Un placer leer este articulo :D

  4. Hola Claudio,

    Es cierto que es complicado mantenerse actualizado en sistemas como WordPress, que no sólo actualizan el core con mucha frecuencia, sino también los diferentes plugins que se puedan tener instalados.

    En cualquier caso, ten en cuenta que tanto la información de robots.txt como el sitemap.xml es información que debe ser pública según su finalidad.

    Gracias por tu comentario y un saludo

Trackbacks

  1. […] Tras la publicación y los comentarios surgidos a raíz del post donde comentábamos una serie de medidas para aumentar la seguridad del CMS WordPress (Securizando WordPress), me di cuenta que la inqu…  […]