Llevo muchos años utilizando WordPress y me parece interesante compartir algunas de las medidas de seguridad que considero básicas para mantener una instalación segura. No entraré en detalle de ninguno de los temas, pero si alguien quiere que me esplaye un poco más o que escriba un post sobre ello, lo haré.

Establece los permisos de archivos y directorios

Desde el terminal, si tenemos acceso al servidor, nos aseguraremos que los directorios y los archivos tienen los permisos establecidos correctamente. En la mayoría de los casos de la siguiente manera:

Para directorios:

find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

Para archivos:

find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Establece las claves secretas de tu wp-config.php

Las claves secretas de nuestro WordPress se utilizan para dotar de mayor seguridad a las cookies de nuestro sitio y que terceras personas “no se hagan pasar por nosotros”. Debéis introducirlas en el archivo wp-config.php y podéis generarlas aleatoriamente desde aquí.

Renombra el usuario admin y asegúrate de que su contraseña es segura

La mayoría de los usuarios de WordPress mantienen al usuario “admin” como administrador de su sitio, por lo que si alguien intenta hackearlo lo tendrá el doble de fácil, puesto que solamente tendrá que introducir la contraseña. Por eso es importante no utilizar, ni siquiera tener, un usuario llamado “admin” en el blog. Podemos crear un nuevo administrador utilizando este usuario y a continuación loggearnos con él para borrar el antiguo o también acceder a PhpMyAdmin y modificarlo como se explica aquí.

Sobra decir, que también tendremos que tener una contraseña segura, para lo cual resulta muy interesante “How Secure is My Password“, una página que te indica la fuerza de la misma. Utilizar servicios como 1Password o LastPass también puede ayudarnos.

Mantén actualizados WordPress y los plugins que utilices

Las mayores vulnerabilidades suelen producirse en versiones antiguas de WordPress o en plugins desactualizados, porque los hackers tienen más tiempo para trastear con estas versiones, así que una buena manera de prevenir ataques es mantenerlo todo actualizado siempre y cuando sea posible.

Cambia el Prefijo de la Base de Datos

Por defecto, WordPress establece el prefijo “wp_” en las tablas de nuestra base de datos. Esto supone un problema porque estamos dando pistas de cómo se llaman nuestras tablas: wp_options, wp_posts, wp_comments, etc. Modificando el prefijo conseguiremos ponérselo más difícil a los hackers.

Para hacerlo, si aún no hemos instalado WordPress, nos bastará con editar la siguiente línea en el archivo wp-config.php:

$table_prefix  = 'r235_'; 

Podemos cambiar “r235_” por lo que queramos, siempre y cuando contenga números, letras o guiones bajos.

En el caso de que nuestro blog ya tenga un recorrido, tendremos que cambiar el prefijo de todas las tablas existentes, lo que podemos hacer metiendo mano directamente en la base de datos (¡Ojo!) o utilizando el plugin WP Security Scan, que realiza esta tarea automáticamente

Prevenir ataques de fuerza bruta en el login de usuarios

Si utilizas el usuario “admin” del blog o una contraseña sencilla, las probabilidades de que un ataque por fuerza bruta tengan éxito son muy altas, pero si no es así también existe alguna posibilidad puesto que WordPress no limita el número de accesos erróneos en periodos cortos de tiempo, así que a base de paciencia (o utilizando una gran cantidad de ordenadores infectados) se puede conseguir. Para prevenir esto se puede utilizar un plugin, como Simple Login Lockdown o similares.

Proteger el acceso los arhcivos htaccess, wp-config.php y directorio wp-includes

Solamente tú y el servidor deberían tener acceso a estos dos archivos, que son muy importantes puesto que en ellos aparecen datos privados (como la contraseña y usuario de la base de datos) y las normas de redirección del blog.

Para evitar que accedan terceras personas a ellos, añade las siguientes líneas al archivo .htaccess:

Para wp-config.php:

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

Para .htaccess:

<Files .htaccess>
order allow,deny
deny from all
</Files>

Para el directorio wp-includes:

# Block the include-only files.
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]

# BEGIN WordPress

Desactivar el editor HTML de WordPress para plugins y plantillas

Si alguien accede a tu panel de administración, por defecto tendrá acceso a la edición de tus plantillas y plugins. Es poco recomendable realizar los cambios a los archivos del blog desde la administración porque si metemos la pata no hay vuelta atrás, no tenemos deshacer, así que es bastante recomendable desactivar esta característica añadiendo la siguiente línea en el wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Oculta la versión de WordPress que utilizas

Por defecto, por razones estadísticas WordPress muestra en el código de la cabecera del blog la versión que se está utilizando, lo que puede facilitar la tarea de los hackers a la hora de buscar vulnerabilidades. Para evitar esto, en el archivo functions de nuestra plantilla podemos añadir la siguiente línea:

remove_action('wp_head', 'wp_generator');

Si lo preferimos, también podemos utilizar algún plugin que realiza esta tarea automáticamente, como por ejemplo Secure WordPress.

Realiza copias de seguridad

Aunque no tiene que ver directamente con la seguridad, sí que tiene que ver con que te sientas más seguro y que te ahorres unos cuentos dolores de cabeza en el caso de que algo falle. Para realizar copias de seguridad de la base de datos puedes utilizar un plugin (fácil) o programar un script que realice la tarea automáticamente (hardcore) utilizando CRON.

Un plugin para realizar esta tarea de manera sencilla puede ser WP-DBManager (WordPress Database Backup hace mucho tiempo que no se actualiza).

Si te va lo hardcore, puedes editar el siguiente shell script para dejarlo a tu gusto y luego ejecutarlo periódicamente con CRON:

DBNAME='BASE_DATOS'
DBPASS='CONTRASEÑA'
DBUSER='USUARIO'
#Email al que se enviará por correo la backup
EMAIL="EMAIL"
#El prefijo que utilices en tu base de datos
PREFIX="PREFIJO_DB";
DATE=`date +%Y%m%d` ;

#Exportamos la BD
mysqldump --opt -u $DBUSER -p$DBPASS $DBNAME > backup.sql
#La comprimimos
gzip backup.sql
#Codificamos el archivo como archivo adjunto y lo enviamos por email
uuencode $DBNAME-backup-$DATE.sql.gz $DBNAME-backup-$DATE.sql.gz | mail -s "[bocabit.com] Backup MySQL Completa" $EMAIL
rm $DBNAME-backup-$DATE.sql.gz

Plugins recomendados para asegurar nuestro WordPress

Por último, os dejo un listado algunos de los plugins que yo utilizo para ahorrarme quebraderos de cabeza y mantener WordPress un poco más seguro.

• Akismet: Para evitar el spam en los comentarios del blog.
• Secure WordPress: Desactiva las versiones de WordPress y realiza otras pequeñas tareas.
• WP Security Scan: Detecta vulnerabilidades en nuestra instalación y realiza el cambio de prefijo de la base de datos automáticamente.
• Simple Login Lockdown: Evita ataques de fuerza bruta en el login de usuarios.
• WP-DBManager: Realiza backups de nuestro blog, optimiza y arregla la base de datos.

Si conocéis más plugins o trucos de seguridad os animo a que dejéis un comentario.

Tú, que cuidas al milímetro con quién compartes tus publicaciones, que realizas una investigación policial cada vez que te envían una petición de amistad y que, en sana dubitación con tu yo interior, piensas durante horas si aceptas ser etiquetado en una foto con “ese tipo” en su yate de lujo durante tus vacaciones de verano. ¡Cómo osáis, amigos de Facebook, perturbar mi paz!.

Por suerte para ti, hay una solución al alcance de los dedos para controlar qué información se puede compartir con las aplicaciones de tus amigos y cual no.

1. Pulsa en el engranaje de la parte superior derecha para desplegar las opciones de configuración de tu cuenta.
2. En el desplegable que aparece, selecciona “Configuración de privacidad“.
3. En la barra lateral, haz clic en el apartado “Aplicaciones“.
4. Baja hasta casi el final de la página y, en el apartado que se llama “Aplicaciones que usan otras personas“, haz clic en “Editar”.
5. Desmarca todas las casillas correspondientes a información que no quieras compartir.
6. Pulsa “Guardar cambios” y respira hondo.

Ya no nos tendremos que preocupar más de las aplicaciones que utilizan nuestros contactos,aunque si de verdad no quieres permitir que ninguna aplicación (incluso de las que tú utilizas) acceda a tu información, puedes desactivar “la plataforma”, que es todo el sistema social de Facebook que utilizan las aplicaciones (Acceso utilizando tu cuenta de Facebook, contenido social en juegos, etc). Lo puedes hacer desde la parte superior del apartado aplicaciones.

Lo malo, es que si la desactivas no podrás utilizar ningún tipo de aplicación de Facebook. Lo bueno, que ninguna empresa mala podrá utilizar tus información para mostrarte publicidad relevante a tus gustos o espiarte en su maquiavélico plan para dominar el mundo.

Vía | Naked Security

Básicamente, Amazon Web Services se divide en varios servicios que ofrecen servicios muy concretos. En un servidor compartido/privado todos estos servicios ya vienen configurados de serie sin tocar prácticamente nada, lo que pude suponer una dificultad considerable a alguien que no está acostumbrado a lidiar con administración de servidores y servicios web.

¿Qué vamos a hacer?

Entonces hemos decidido montar un blog de WordPress utilizando Amazon. ¿Qué ventajas nos ofrece? Para empezar, resulta “barato” en comparación con otros servicios similares. Es muy personalizable, rápido y tiene un uptime (Tiempo de disponibilidad del servidor) muy alto. Por contra, como decía antes, hay que tener ciertos conocimientos y MUCHA PACIENCIA para ponerlo todo en marcha.

Montar un blog no implica solamente instalar WordPress y echar a correr. Es probable que también necesitemos almacenar los datos del mismo (imágenes, vídeos,…), configurar un dominio para él, instalar un plugin de formularios de contacto para enviar/recibir emails (En este caso utilizaremos Google Apps), etc. Todo esto utilizando los siguientes servicios de Amazon:

• Amazon EC2: Donde tendremos nuestro servidor virtual y donde instalaremos WordPress.
• Amazon S3: Donde almacenaremos nuestras imágenes y archivos estáticos.
• Amazon CloudFront: Lo utilizaremos de CDN para aumentar la velocidad de las peticiones a archivos estáticos del blog.
• Amazon Route 53: Gestión de los registros DS del blog. Se utilizarán para configurar los servidores de correo.

¿En base a qué se nos va a cobrar?

Vamos a utilizar unos cuantos servicios y desgraciadamente no son gratuitos, aunque Amazon AWS nos permite pagar únicamente por lo que utilizamos. La facturación de cada servicio es diferente y es la que sigue.

• Amazon EC2: Nos cobra por cada hora que esté funcionando el servidor y por ancho de banda. Si lo queremos tener funcionando 24/7, tendremos que pagar el máximo, que son una media de 24 x 31 horas.
• Amazon S3: Depende de la cantidad de espacio en disco que utilicemos y del número de peticiones PUT/POST que se haga al contenido almacenado.
• Amazon CloudFront: El precio depende del ancho de banda saliente consumido y por cada 10.000 peticiones (HTTP/HTTPS).
• Amazon Route 53: El consumo depente de cuantos dominios tengamos y por cada millón de peticiones que se hagan al mismo.

¿Cuánto nos va a costar?

Pese a que Amazon AWS dispone de una calculadora de precios, de primeras puede resultar complicado estimar lo que consumiremos en cada apartado, así que podéis haceros una idea de lo que costaría teniendo en cuenta que los siguientes datos reales pertenecen a un blog de unas 2.000 visitas al día.

• Amazon EC2: 24.50 dólares.
• Amazon S3: 0.07 dólares (1.40 dólares aproximados el primer mes, porque tendremos que transferir todos los archivos una vez).
• Amazon CloudFront: 1.80 dólares.
• Amazon Route 53: 0.80 dólares.

A todo esto, habrá que sumarle los impuestos (VAT), que son de más o menos el 20%. Con los precios anteriores sería en torno a los 5,40 dólares.

Conclusiones

Teniendo en cuenta que los cálculos son aproximados puesto que el gasto depende del consumo, utilizar Amazon AWS para alojar un blog saldría por unos 28 dólares al mes, unos 21 euros al cambio. No es caro teniendo en cuenta lo que se nos ofrece, aunque tampoco está al alcance de todo el mundo y hay que tener bien claro cómo rentabilizarlo.

Si tenemos un blog con estas visitas, un servidor compartido es más que suficiente (siempre y cuando no tengamos montada alguna filigrana que consuma una cantidad memoria exagerada), pero si eres de los que le gusta trastear y tener todo controlado es una buena opción ya que es un poco más barato que un VPS y te ofrece más posibilidades de personalización.

Basta con pulsar sobre el botón en el que aparece un cursor en la parte superior derecha del inspector (“Toggle element state”). Una vez hecho clic, se nos desplegará una serie de opciones para elegir el estado del elemento: hover, focus, visited o active.

Con este pequeño truco podremos establecer mucho más fácilmente los estilos cuando pasamos el ratón sobre un elemento HTML.

Cuando me presenté en la tienda el 7 de Marzo religiosamente y le dije al tendero que tenía una reserva de Simcity, sabía que era bastante probable que no pudiera jugar ese primer día. Una simple búsqueda en Twitter del hastag #simcity daba lugar a cientos de quejas de jugadores de otros países que ya habían comprado el juego y que no podían jugar debido a que los servidores de EA estaban colapsados.

Simcity requiere de una conexión permanente a Internet para jugar, o mejor dicho, para que funcione el DRM de Electronic Arts y no te expulse del juego por pirata. Este sistema también lo utilizó Blizzard en su Diablo III y los resultados fueron similares: unos cuantos días sin poder jugar al juego.

Durante unos los primeros días, los servidores de cada continente pasaron de ser 2 a 8 para distribuir mejor a los usuarios, pero para que la tarea fuese más sencilla, EA también decidió capar el juego: desactivar la velocidad rápida, tablas de clasificación, logros, etc. A día de hoy, 3 semanas después de su lanzamiento solamente funcionan los logros.

Si únicamente fuera eso lo que no funcionase, podría pasarse un poco por alto, pero además, el juego viene con más de una docena de bugs que te arruinan la partida: atascos que evitan que tus camiones de comercio lleguen a las fábricas, problemas al establecer los ingresos/gastos de la ciudad (puede pasar de ganar 100.000 a perder 500.000 de repente sin explicación alguna), errores al contabilizar los materiales enviados a una obra común de la región (gran obra), tráfico que se queda parado e inmoviliza a la policía y a los bomberos y que provoca que la ciudad arda en llamas. Mi favorito es cuando te dice que se han detectado errores en tu ciudad y esta se queda en el limbo: no puedes acceder a ella nunca más.

Llevo 64 horas jugadas y el juego tiene mucho potencial, pero es inevitable tener la sensación de que es un producto muy poco testado, que se ha lanzado con prisa. Aunque es posible que en el futuro lo arreglen, en estos momentos no lo puedo recomendar; resulta desesperante perder una partida en la que llevas horas por un error.

Al menos podré jugar al Simcity 4, que me ha regalado Electronic Arts como compensación, si alguien tiene un monitor de 4:3 que me avise, que el juego no es compatible con 16:9…

Fuente | Vimeo

Desde mi | Flickr

Crear la carpeta de usuario nueva

Lo primero que debemos hacer es crear la carpeta de usuario en el disco duro secundario. Debe tener el mismo nombre que la carpeta de usuario del disco de arranque.

Crear una copia exacta de los archivos

A continuación debemos crear una copia exacta de los archivos de la carpeta de usuario original en la nueva carpeta que hemos creado en el disco duro secundario. Para ello utilizaremos en el terminal el comando ditto, que creará una copia exacta:

sudo ditto -rsrc ORIGEN DESTINO

En mi caso quedaría de la siguiente forma:

sudo ditto -rsrc /Users/rene /Volumes/MacintoshHD/rene/

(Para obtener las rutas correctamente, podemos simplemente arrastrar desde el Finder cada una de las carpetas.)

Actualizar la configuración de Mac OS X

Una vez hecho esto, tendremos una copia de los archivos hecha, incluyendo los permisos de escritura y lectura correctos. Ahora deberemos decirle al sistema que la ubicación de la carpeta de usuario ha cambiado. Para ello accederemos a “Preferencias del Sistema”, “Usuarios y Grupos”. Una vez ahí haremos clic derecho sobre el usuario que deseemos modificar y elegiremos “Opciones Avanzadas”. En la ventana que se abre solamente tendremos que modificar la línea “Directorio de inicio” seleccionando la ubicación que hemos creado previamente.

Una vez hecho esto, reiniciaremos y ya habremos movido el directorio Home de nuestro usuario al disco duro secundario. Una vez que comprobemos que todo ha funcionado correctamente, podremos borrar la carpeta de usuario original.