Desde hace 2-3 días (depende de la ubicación) hemos empezado a ver en nuestro dashboard de WordPress un mensaje para actualizar a la versión 3.1.2

Y la pregunta para quienes trabajamos en WordPress debe ser el porqué de esta nueva versión, qué nos trae y qué nos evita.

Multiple tag queries broken

Tras un reporte que dice que al realizar un query de forma tales.com/tag/tag1+tag2/ respondía con 404 en la versión de WordPress 3.1.1 la solución se dio cuando en el archivo wp-includes/query.php se cambio un uso incorrecto del operador sobre taxonomías, detalles en http://core.trac.wordpress.org/changeset/17611

WP_User_Query ordered by post_count doesn’t work if prefix is not wp_

Este es el que se puede llamar “El Bug”, y se resume que al parecer en el archivo wp-includes/user.php, en la línea 441 alguien introdujo el nombre de la tabla wp_posts en una sentencia en lugar de $wpdb->posts. ¿Qué significa esto? Que nuestro WordPress estaría metiéndose en datos de otra instalación o, en el mejor de los casos, funcionaría mal.

Walker_PageDropdown doesn’t filter titles correctly

Es un mal funcionamiento del filtro en los títulos, sólo se alteraron un par de líneas, http://core.trac.wordpress.org/changeset/17685

Too much escaping for pages when using Quick Edit

Este cambio previene que se sobreescape el título de las páginas.

Validate post status against capabilities in press this

Éste es el importante, un bug de seguridad. Permitía a un usuario con el rango “Colaborador” publicar contenidos.

Conocer estos cambios puede darnos un vistazo de cómo avanza WordPress.

Si algo nos ha enseñado la historia es que cuando un software tiene un propósito tan amplio como WordPress y un uso masivo a nivel global despierta más interés por parte de personas sin escrúpulos que desean aprovecharse y atacar las páginas y clientes que usan este sistema.

La enorme variedad de plugins que existen y que nos permiten hacer prácticamente cualquier sitio web también es el principal problema de seguridad, Recordemos que los plugins de WordPress se ejecutan directamente y el core del mismo no es responsable por la ejecución de los mismos. Si un plugin está corrupto no hay nada que el CMS pueda hacer al respecto, y por esta razón es importante tener algunas buenas practicas al momento de utilizar plugins y temas en nuestros sitios web. Esto me da pie a dar algunas recomendaciones de seguridad en WordPress.

Actualiza regularmente WordPress y los plugins instalados

Cuando ocurren estos descubrimientos de fallos seguridad son prontamente solucionados. Siempre es recomendable usar la ultima versión.

Buscar plugins

En internet existen miles de plugins disponibles para hacer casi cualquier cosa que uno se imagine, sin embargo mi recomendación es escogerlos del sitio oficial que wordpress.org tiene para tal fin. Está claro que WordPress no se hace responsable de éstos, pero al estar allí podemos ver la calificación del plugin, su autor y más información de manos de terceros.

Borra plugins que no uses

Para hacer nuestros sitios más dinámicos y cambiantes en ocasiones instalamos nuevos plugins y nuevas características. Por eso es importante que primero desactives y luego borres los plugins viejos que no uses, porque si aún existen en el servidor pueden ejecutarse sólo conociendo sus rutas.

No te confíes por tener un sitio pequeño

Cuando comencé en la web, escuché mucho “soy pequeño, a mí qué me van a querer atacar”. ERROR: la gran mayoría de los ataques se hacen a sitios pequeños. Olvidemos la imagen del hacker sentado frente al PC pensando mil y una formas de entrar al banco para robar millones, ahora existen bots sin sentimientos o miramientos escaneando en internet alguna presa y alguna vulnerabilidad en los sitios. En ocasiones los ataques sólo se hacen como parte de un ataque más grande.

Permisos sobre las carpetas y archivos

Los ataques que he sufrido siempre han sido por este motivo. Por descuido o por necesidad del servidor y la aplicación, estas carpetas quedan con posibilidad de ser escritas o modificables por cualquier usuario del servidor, esto permite que los atacantes suban sus propios programas. Es importante que siempre y cuando no sea absolutamente necesario, nuestros archivos y carpetas tengan sólo permisos de lectura.

Copia de respaldo Copia de respaldo Copia de respaldo

Esto se dice mucho pero vale la pena. Si tienen un sitio en producción y éste es importante, es vital que se hagan copias de los uploads de WordPress y de la base de datos. En algunos casos, la única forma de resolver un ataque es hacer borrón y cuenta nueva; obviamente hay que verificar que ni en la base de datos ni en los uploads hayan rastros de ataques previos.

Por último en esta breve lista, usar algunos plugins de verificación como TAC (Theme Authenticity Checker), y algunos de aseguramiento del sitio como es BulletProof Security que, mediante los archivos htaccess, asegura el sitio ante muchos tipos de ataques.

¿Qué hacen ustedes en cuestión de seguridad?

Cuando descubrí que WordPress “manoseaba” saneaba el html que escribimos no me pareció correcto y una perdida de tiempo de procesamiento, sin embargo en proyectos compartidos de multiples usuarios es importante definir ciertas reglas sobre lo que se puede escribir claro en términos de html, por seguridad buena parte del html para los autores esta restringido, cosas como los iframes y demás, pero de la librería KSES podre hablar en algún otro artículo.

¿Pero cual fue la falla de seguridad?

parece que esta le permite a un atacante insertar código del lado del cliente, es un ataque de tipo XSS claro que el atacante tiene que ser un usuario de tipo autor cuando menos, los detalles del código que ha sido actualizado puede verse en el trac de WordPress.

¿Qué hacer si mi sitio hae sido víctima de un ataque XSS?

Si ya te han atacado actualizar wordpress no servirá de mayor cosa que no sea evitar más ataques, por que el daño ya se hizo a la base de datos, lo correcto es sanearla artículo por artículo.

Espero que este artículo les sirva para entender un poco más esta actualización de WordPress.

Esto es muy fácil de hacer si estás haciendo una nueva instalación de WordPress, pero como nos decía @Juan en los comentarios, no es tan fácil hacerlo si ya tienes tu blog instalado y en funcionamiento. Es por esto que hoy he querido hablar de WP Prefix Table Changer, un plugin que nos facilitará muchísimo esta tarea.

Este plugin es práctico por dos razones. Primero, si tienes el prefijo cambiado, cualquier atacante tendrá que adivinar dicho prefijo, cosa que puede ser realmente difícil dependiendo del que pongas. Por otra parte, muchos servicios gratuitos de hosting proporcionan una sola base de datos: en caso de que quieras tener más de un blog WordPress, será imprescindible cambiar dicho prefijo. Esto puedes cambiarlo en la instalación, pero siempre va bien poderlo cambiar si ya tienes el blog instalado y funcionando.

Como ya debéis haber visto, estamos tratando con la base de datos, así que es imprescindible que antes de empezar hagas una copia de seguridad. En general, cuando utilices plugins que cambien cosas importantes o cuando estés manipulando tu sitio, te recomiendo que hagas backup tanto de la DB como de los archivos del servidor FTP: mejor prevenir que curar. Puedes hacerlo utilizando WordPress Database Backup.

Seguidamente, sólo tienes que descargar el WP Prefix Table Changer, instalarlo y ejecutarlo. ¡Fácil!

Fuente: BlogSecurity

¿Qué hago si ya he detectado que tengo inyección de código?
Lo primero que deberíamos hacer es asegurarnos que el usuario malicioso no ha accedido a nuestro blog usando nuestro usuario de administración. Lo mejor que podemos hacer (tras repasar los consejos de seguridad) es cambiar nuestras contraseñas. Seguidamente, actualizaremos (si no lo tenemos) el WordPress a su última versión.

Tras las comprobaciones iniciales, deberemos eliminar el código de nuestra página web. Es muy probable que el usuario malintencionado sólo haya modificado los archivos de nuestra plantilla, así que lo mejor que podemos hacer es abrir nuestro theme con el editor que nos proporciona WordPress y revisar todos los archivos por si vemos algún texto raro. Habitualmente, se repetirá el mismo texto en casi todos los archivos y casi siempre estará ubicado en la parte final de nuestro archivo. Sólo tenemos que borrar dicho código (¡sin borrar nada más!) y ya tendremos nuestra página arreglada.

Es importante que, a parte de quitar el código malicioso, tengas en cuenta todos los consejos de seguridad que hemos ido explicando, ya que nos interesa especialmente que no nos vuelva a pasar en un futuro.

Google Webmaster Tools

Una vez eliminado el código malicioso de nuestro WordPress, debemos conseguir que Google nos indexe de nuevo, que elimine las palabras clave que no correspondan y los enlaces inadecuados. De esta forma, cuando ya tengamos nuestro blog limpio, deberíamos entrar a las herramientas para webmasters de Google y solicitar una reinclusión de nuestro sitio. Una vez en la página, debemos hacer clic debajo de Ayuda con (Help with) dónde pone Reconsideración del sitio (Site reconsideration). Se nos abrirá una página explicativa, y tenemos que escoger la opción Pedir reconsideración de mi sitio (Request reconsideration of your site). En la última página que se nos abrirá tendremos que seleccionar el sitio web que nos han hackeado, aceptar las condiciones y explicarles cuál ha sido el problema que hemos tenido para que Google no nos indexara correctamente.

Espero que, si alguna vez tenéis algún problema con vuestro WordPress, este tutorial os sirva. Comentad si tenéis algún problema.

Muchas veces puedes no enterarte de que te han hackeado el sitio, ya que los usuarios malintencionados sólo muestran enlaces al robot de Google sin que los visitantes “normales” de nuestra web puedan notar nada. Esta técnica es conocida como cloaking.

Una de las formas manuales de detectar que nuestra web ha tenido una inyección de código malicioso es entrar en Google y buscar nuestro propio sitio web. Desde el buscador, accederemos a la caché: éste es el contenido que el buscador ha indexado de nuestra web. Si vemos algo diferente, habitualmente todo de texto que no es nuestro al final de nuestra página, es que hay algún tipo de hackeo.

Otra forma que podemos utilizar son las herramientas para webmasters de Google. Es un tema que trataremos más a fondo, pero centrémonos en el hackeo: si nuestro sitio tiene inyección de código, veremos como “palabras más encontradas por Google” algunas raras que no corresponden a nuestro contenido original.

Una forma automática es configurar las alertas de Google Alerts para que nos informen sobre contenidos raros en nuestro sitio. Para hacerlo, iremos a la página de Google Alerts y realizamos una búsqueda similar a “viagra OR cialis OR levitra OR Phentermine OR porn site:nuestrositio.com“. Configuraremos las alertas según convenga para que nos informe en nuestro correo cuando haya resultados nuevos sobre esas palabras en nuestro sitio.

Ahora ya sabemos cómo detectar si nuestro WordPress ha sufrido un ataque hacker de inyección de código. El próximo día hablaremos de cómo solucionarlo y qué hacer para que Google nos vuelva a indexar correctamente.

Fuentes: Ismael El-Qudsi, Adseok

Es por este motivo que se recomienda, en general, utilizar el mínimo de plugins posibles. Coge tu lista de plugins y pregúntate: ¿este plugin realmente es esencial para mi blog? Todos los plugins nos dan funcionalidades extra, pero seguro que algunos podrías ahorrártelos fácilmente. Y aquellos que sigas queriendo mantener instalados, debes tenerlos actualizados a su ultima versión para ahorrarte problemas.

Para controlar tu WordPress y comprobar que no esté fallando nada, puedes instalar algunos plugins de seguridad:

1. WordPress Database Backup: Siguiendo con el anterior artículo del tutorial de seguridad, plugin imprescindible para realizar tus copias de seguridad periódicamente sin preocuparte.
2. WP Security Scan: escanea tu instalación de WordPress para buscar vulnerabilidades de seguridad y sugerirte acciones para corregirlas. Escanea passwords, permisos de archivo, seguridad de la base de datos, protección de la administración de WordPress, etc.
3. Semisecure Login Reimagined: incrementa la seguridad del acceso (login) a tu blog utilizando una combinación de claves públicas y privadas de encriptación para esconder tus passwords de vistas ajenas. Se requiere JavaScript y es especialmente útil si no dispones de SSL.
4. Invisible Defender: Añade dos cajas de texto adicionales e invisibles a todos los formularios del blog, cosa que nos permite evitar muchos de los bots de SPAM y otras técnicas de ataque.
5. Theme Authenticity Checker: Nos permite escanear el código fuente de nuestro theme, siendo de esta forma capaz de encontrar inyecciones de código malicioso o ataques similares, mostrando donde está el código problemático para poderlo eliminar fácilmente.
6. WP Antivirus: Antivirus para WordPress que permite encontrar ficheros sospechosos, es una solución fácil y efectiva de proteger tu blog frente a exploits y inyecciones de SPAM. Aquí tienes la reseña de WP Antivirus en TodoWP de Marcelo Lynch.

Hay muchos más plugins disponibles por Internet, seguro que muchos muy buenos, pero creo que con estos puedes tener una buena instalación segura. Si conoces algún otro interesante, ¡coméntalo y así todos aprendemos!

Fuentes: Bitelia, anieto2k, bitsignals.

Habitualmente WordPress no falla, no perdemos datos cuando instalamos plugins o themes, ni cuando actualizamos alguno de sus componentes. No obstante, siempre que hagamos algún cambio importante en nuestro blog deberíamos tener copia de nuestra base de datos y de nuestros archivos de servidor. Un error típico y fácil es hacer copia solamente de la base de datos, y dejarnos sin copiar las imágenes y archivos que tengamos almacenados en nuestro blog.

Empecemos por la base de datos. Personalmente, en mi blog utilizo un plugin que se llama WordPress Database Backup. Al instalarlo, te aparece un menú de Backups en el apartado de Herramientas de tu blog, donde puedes configurar respaldos manuales (guardar una copia de tu base de datos en el servidor o en tu ordenador) o automáticos (programar respaldos que te enviarán a un correo electrónico, con posibilidad de hacerlo cada hora, dos veces al día, cada día, una vez a la semana…). Un plugin muy recomendable.

Personalmente, hago un backup semanal de la base de datos, de forma automática a mi correo electrónico. No obstante, esto no debe ser así en todo blog: depende, sobre todo, de lo que actualices. Si es un blog muy activo, con comentarios a diario, muchas entradas, etc., quizá es mejor hacerlo a diario. Es igual de fácil, ¡con este plugin es todo automático!

Para las copias de seguridad del servidor no utilizo ningun plugin ni programa automático. Muchas compañías de hosting te ofrecen la posibilidad de que te hagan respaldos automáticos en sus propios servidores, de forma que ya no necesitarías hacer nada. Aun así, yo estoy acostumbrado a hacer una copia de seguridad de mi servidor de vez en cuando, quizá una vez al mes o cada dos meses. En mi servidor básicamente lo que se actualiza son blogs, así que no tengo muchas novedades, solamente imágenes para ilustrar los posts. Creo que así es suficiente, pero esto es decisión vuestra.

Espero que este pequeño tutorial haga que los usuarios de WordPress se conciencien y hagan todas las copias de seguridad necesarias para no perder nunca nada. Y, sobre todo, no olvidéis las copias de seguridad antes de actualizar vuestro WordPress a una nueva versión: es el proceso más delicado que hace nuestro sistema de gestión de contenidos y es mejor no dejar nada al azar.

1. Usuario de la base de datos: lo ideal es crear un usuario destinado exclusivamente a nuestro blog, con permisos exclusivos para trabajar con las tablas de WordPress. Es por eso que no debemos utilizar nunca el usuario root. En general, los permisos que daremos al usuario destinado a acceder a la base de datos de nuestro blog serán SELECT, INSERT, UPDATE, DELETE (para datos) y CREATE, ALTER, DROP (para estructuras), pudiendo descartar el CREATE y el DROP si comparte su base de datos con otros proyectos.
2. Cambia el prefijo de tus tablas: WordPress por defecto utiliza wp_ como prefijo para las tablas correspondientes a nuestro WordPress, pero siempre se debería cambiar esta opción en nuestra instalación. De esta forma alguien que quiera acceder a nuestros datos deberá conocer ese prefijo antes. Lo mejor, pues, es utilizar un prefijo aleatorio que no sea de fácil deducción.
3. Elimina los ficheros de instalación: en /wp-admin/, install.php, upgrade.php e installer-helper.php. También puedes eliminar los importadores (wp-admin/import/), que sirven para importar contenido y modifican la base de datos.
4. Fichero wp-config.php: es nuestro fichero más importante para la configuración de WordPress y, por lo tanto, para nuestra seguridad. Con él conectamos a la base de datos, así que hay información confidencial. Por este motivo, tenemos que darle permisos 644, es decir, tenerlo como fichero de sólo lectura.
5. Cambia tu usuario Administrador. Ya tenemos nuestro WordPress instalado, es hora de configurarlo. Lo mejor es crear otro usuario para utilizarlo como administrador (puedes configurarlo desde el panel de administración) e inhabilitar (ponerlo como suscriptor) el administrador que nos crea nuestro WordPress.
6. No utilices tu usuario de administración. Aunque lo acabemos de crear, no lo utilices. En general no necesitarás ser administrador de tu blog, sólo querrás escribir y cambiar cuatro cosas. Así que puedes crearte otro usuario editor o autor, con tu nick y nombre, y configurarlo a tu manera para utilizarlo habitualmente para escribir. Así, si perdieras la contraseña o te la descubrieran, solamente podrían modificar unas pocas cosas de tu instalación. Puedes instalar Role Manager para marcar qué permisos quieres que tenga el usuario que utilizarás para escribir habitualmente.
7. Restringe los directorios que tus usuarios no verán: wp-content, wp-includes y wp-admin son los directorios más usados por WordPress, es por eso que debemos limitar el uso de estas carpetas.  En una próxima entrada haremos especial hincapié en este punto, explicando cómo configurar nuestros archivos .htaccess
8. Crea un archivo en blanco: por defecto, las carpetas de plugins son completamente visibles. Si creas un documento en blanco y lo guardas allí como index.html, ya no serán tan fácilmente visibles.
9. Bloquea las carpetas a los motores de búsqueda. No es necesario que los bots accedan a nuestros archivos de WordPress, así que podemos bloquearlos con el archivo robots.txt. Añade la siguiente línea: Disallow: /wp-*

Espero que estos consejos en la instalación os hayan servido. Si hay alguna duda, o queréis que hable sobre algún tema de seguridad concreto que no haya quedado claro, por favor, comentad.

Fuentes: anieto2k, Online Tech Tips, sigt.