Tag: seguridad

Actualizaciones de seguridad automáticas en Ubuntu

Posted on by

Un tip breve pero muy útil, casi necesario: si estás a cargo de algún servidor, puedes activar la instalación automática de actualizaciones de seguridad lo que alivia bastante la carga ante anuncios de vulnerabilidades.

Para Ubuntu, puedes consultar la siguiente guía en su documentación comunitaria: Automatic Security Updates.

Las actualizaciones de seguridad se distribuyen a través de un repositorio específico, y cuando se publica una nueva versión por lo general va a estar limitada a solucionar una vulnerabilidad, por lo que el riesgo de que surja alguna incompatibilidad es muy baja.

Cómo usar un certificado SSL autofirmado de forma segura

Posted on by

Hace un par de publicaciones atrás, explicaba cómo configurar un certificado SSL autofirmado para la administración de WordPress, y señalaba la dificultad de comprobar la integridad de la comunicación entre el cliente y el servidor debido a que un certificado autofirmado no está validado por una autoridad de certificación comercial, como las que se incluyen entre los certificados aceptados por los navegadores más populares.

Aunque por una parte esto podría entenderse como una ventana abierta para ataques de man-in-the-middle, lo cierto es que es posible eliminar el riesgo de este tipo de ataques al utilizar un certificado autofirmado siguiendo un procedimiento relativamente sencillo.

Continue reading “Cómo usar un certificado SSL autofirmado de forma segura”

Cómo asegurar las cookies de acceso a tu sitio WordPress

Posted on by

Recientemente se ha dado a conocer una vulnerabilidad en el sistema de autenticación de usuarios para los sitios con WordPress, que básicamente consiste en lo siguiente:

  • La vulnerabilidad afecta tanto a sitios en WordPress.com como instalaciones propias.
  • Al acceder a la administración de tu sitio, WordPress crea una cookie que le permite validarte como un usuario que ha iniciado sesión.
  • Una gran cantidad de sitios con WordPress no funciona sobre HTTPS, por lo que la cookie se envía como texto plano.
  • Un atacante puede interceptar esa cookie, insertarla en su navegador, y luego hacerse pasar por el usuario que ha iniciado sesión. Esto es particularmente fácil en situaciones donde hay transmisiones “abiertas” de datos, por ejemplo en un café donde la conexión no tiene contraseña.
  • La cookie sigue siendo válida aun cuando el usuario cierre su sesión, por lo que podrías ingresar a tu administrador, cerrar la sesión, y el atacante aun tendría acceso.
  • El tiempo de expiración de la cookie es de 3 años en blogs de WordPress.com y 14 días en instalaciones propias.

Ahora pasemos a lo importante, ¿cómo evitarlo?

En primer lugar, la opción más sencilla pero seguramente inefectiva es la abstinencia: simplemente, evitar acceder a la administración de WordPress en redes no confiables. Pero como estamos hablando de seguridad, y en este sentido no se puede ser demasiado paranoico, desechemos esta opción.

Continue reading “Cómo asegurar las cookies de acceso a tu sitio WordPress”

Las secuelas de Heartbleed

Posted on by

Heartbleed es —en términos sencillos— el cagazo más grande que se ha descubierto en materia de seguridad informática en muchos años, y que en el contexto de las revelaciones que hemos conocido gracias a la denuncia de Edward Snowden no sólo ayuda a explicar algunas cosas sino también a ponernos a todos un poco más paranoicos.

Por ello es que los coletazos de su descubrimiento están lejos de terminar, y esto no se refiere únicamente a la multitud de sitios que aún estarán exponiendo a sus usuarios a esta vulnerabilidad, sino también a las deficiencias en procesos críticos que han quedado al descubierto por esta crisis mientras la polvareda aún no termina de asentarse.

En particular, existen dos iniciativas en las que vale la pena reparar porque representan dos caras muy distintas del mundo del software libre y el código abierto.

Continue reading “Las secuelas de Heartbleed”

Bloquear una IP con UFW

Posted on by

UFW es una herramienta para facilitar la configuración del firewall iptables en Linux, por lo que conocerla un poquito tarde o temprano puede resultar vital.

Hace poco, pude constatar un claro intento de hacer un ataque de fuerza bruta contra este blog, y a pesar que el excelente plugin Limit Login Attempts estaba bloqueando correctamente los intentos de login, había una IP en particular que seguía intentando acceder incansablemente a la página de login.

Tras acceder por SSH, llegó la hora de aplicar un sencillo comando para hacer la ley del hielo a este molestoso:

$: ufw deny from 192.168.144.xx

Sin embargo, el registro de nginx seguía mostrando intentos de acceso… ¿qué podía estar pasando?

Tras un par de búsquedas en Google pude dar con la respuesta: básicamente, había un problema de prioridades en las reglas del firewall, ya que sólo va a aplicar la primera coincidencia.

Para pode resolver este impasse, en primer lugar debes obtener el listado de reglas activas y sus prioridades, lo que puedes lograr con ufw status numbered.

Este comando te devuelve el listado de reglas activas y un número identificador de la prioridad. A partir de esto, puedes crear una nueva regla e insertarla en un lugar específico; por ejemplo para agregarla en primer lugar:

$: ufw insert 1 deny from 192.168.144.xx

¡Listo!

Sanitizar consultas con cláusulas “IN” con $wpdb en WordPress

Posted on by

Uno de los métodos que incluye la clase wpdb es prepare, que permite preparar una consulta a la base de datos para asegurarnos que se ejecute de forma segura.

Su utilización es bastante sencilla — y si hasta ahora no la estás utilizando deberías leer inmediatamente la sección sobre cómo proteger tus consultas ante ataques de inyección SQL — pero hasta hace poco no había ideado una forma sencilla de preparar consultas con cláusulas IN.

Una solución bastante sencilla que podemos aplicar es la siguiente:

// obtener un listado de IDs de entradas "especiales"
// $special_entries = array(1, 3, 5, 8, 13, [...]);
$special_entries = get_option('my_special_entries');

// ¿cuántas condiciones se van a seleccionar?
$how_many = count($special_entries);

// prepara la cantidad adecuada de reemplazos
// si se buscarán strings, el último parámetro sería '%s'
$placeholders = array_fill(0, $how_many, '%d');

// unir los reemplazos con comas
// $format = '%d, %d, %d, %d, %d, [...]'
$format = implode(', ', $placeholders);

// la consulta
$query = "SELECT ID, post_title, post_name, post_parent FROM $wpdb->posts WHERE post_parent IN($format)";

// obtener los resultados de forma segura
$results = $wpdb->get_results( $wpdb->prepare($query, $special_entries) );

Googlear tu blog es cosa de seguridad

Posted on by

Seguramente más de alguna vez pusiste tu propio nombre en Google para saber qué salía sobre tí, o bien el nombre o la dirección de tu sitio para ver cómo estaba indexando. Ahora tienes una excusa para seguir haciéndolo: no es por narcicismo, sino por seguridad…

Hace algunos días me puse a buscar algunos artículos en otros blogs a través de Google, pero al obtener los resultados noté algo extraño en lo que mostraba Google: en lugar de los títulos adecuados, aparecían frases típicas de enlaces de spam. Por ejemplo, en Dokshor.com, de mi compañero AyerViernino Fabián Ramírez

Continue reading “Googlear tu blog es cosa de seguridad”

Respaldar datos con Conduit

Posted on by

Conduit, un proyecto para crear una completa solución de sincronización para GNOME, que hace poco he venido utilizando para mantener un respaldo de los archivos que utilizo para la preparación de mi tesis de grado. Si utilizas Ubuntu, puedes descargarlo como paquete de instalación desde GetDeb, o bien dirigirte a la página del proyecto para descargar las fuentes y examinar la documentación para compilarlo.

Conduit Su funcionamiento es bastante sencillo: cuenta con un conjunto de “dataproviders” (barra izquierda) que se pueden enlazar entre sí en un “lienzo” (área derecha). Algunos dataproviders solamente pueden enviar información, otros sólo recibirla y otros funcionan en ambos sentidos, lo que está representado por las flechas que acompañan a cada ícono. Además, es posible organizar un grupo de manera que desde un origen puedas enviar información a varios destinos: por ejemplo, desde tu carpeta de fotos hacia Flickr, Picasa y Facebook.

En mi caso, me interesaba mantener una copia de los archivos de mi tesis en otros lados, por lo que lo he arreglado para copiarlos desde mi disco duro a mi espacio en Box.net, una carpeta en un disco duro externo y una carpeta en mi servicio de web hosting; probablemente este sea la opción menos “obvia”, pero gracias a la posibilidad de crear enlaces con servidores (en Ubuntu, anda a Lugares > Conectar con el servidor... y configura tus datos), es bastante sencillo hacerlo.

Conduit es un proyecto en pleno desarrollo, y como tal, hay muchas cosas que todavía no funcionan completamente como deberían y su documentación es escasa. Afortunadamente, su progreso es dinámico y alentador; seguramente se convertirá en una herramienta indispensable en poco tiempo más.

Link: Conduit

WordPress 2.3 y las preocupaciones por la privacidad

Posted on by

WordPress 2.3 te informa sobre las actualizaciones a tus plugins, pero ¿cómo sabe qué notificaciones enviarte? La información enviada ¿constituye una violación a la privacidad?

Ésta es una noticia fresquita: algunas horas después del lanzamiento de WordPress 2.3, apareció [un hilo en Slashdot->http://yro.slashdot.org/article.pl?sid=07/09/25/1632246] titulado WordPress 2.3 espía a sus usarios (que a esta hora ya ha sido actualizado a WordPress 2.3 no espía a sus usuarios).

La polémica se ha armado por el sistema de notificación de actualizaciones para el core y los plugins de WordPress, una de las novedades más interesantes de la nueva versión; lógicamente, si el sistema habría de informar que existirían actualizaciones disponibles, tenía que existir alguna forma de “saber” qué plugins habían instalados en cada blog, lo que se ha logrado a través de el envío de un informe a un servidor central en api.wordpress.org.

Lo objetable de este sistema se ha centrado fundamentalmente en un punto: que el informe enviado no incluye solamente la lista de plugins instalados, sino además el número de versión y la URL del blog, algo que por muchos es visto como innecesario y derechamente injustificable.

La respuesta de Matt Mullenweg no ha sido especialmente alentadora —traducción de SigT:

Si no os fiáis de wordpress.org os sugiero hacer una de las siguientes cosas:

  1. Usar un software diferente.
  2. Crear un fork de WordPress (una ramificación/proyecto paralelo).
  3. Instalar uno de los plugins ya comentados.

He estado revisando los mensajes en la lista de correo de los desarrolladores de WordPress y he podido encontrar algunos nuevos detalles: la discusión se ha centrado sobre las razones que podrían justificar el envío de la URL de cada blog, ya que en principio parece una decisión poco afortunada; se ha argumentado que en su reemplazo se podría haber utilizado un hash MD5, que serviría de todos modos como un identificador único, pero sin otorgar detalles concretos sobre cada blog. Aquí Matt ha respondido de una manera algo más razonable; resumo sus razones:

  1. Una URL es (según él) la mejor forma de identificar un blog, ya que se pueden normalizar, agrupar por sub/dominios, crear estadísticas por dominios, asociar con perfiles en WordPress.org, etc. —en este sentido le encuentro razón; una URL/:uri: es ciertamente una fantástica forma de identificar un sitio en internet… pero ¿para qué?
  2. Un hash MD5 es único, pero no tiene más valor; cualquier cambio, como la barra final (dominio.com versus dominio.com/) o de mayúsculas/minúsculas alterará la relación entre el blog y su hash —nuevamente, ¿para qué es necesaria mantener la identificación del blog con la información sobre plugins?
  3. Podrían haber nuevas funcionalidades que aun no se han planificado y necesitarían de esto —mmm… sí; me huele a sacada de pillo: ¿porqué recién ahora sale a la luz esta idea? ¿no se les habrá ocurrido justo ahora, cierto?
  4. Un hash MD5 no es necesariamente más anónimo: cualquiera que tenga acceso a una lista de los hashes y una lista de URLs podría identificar los blogs —cierto, lo que abre algunas preguntas: ¿cómo tendrían acceso a estas listas? y ¿qué tan seguros estarán los datos en los servidores de WordPress.org? Recordemos que hace algún tiempo alguien logró poner una versión modificada de una actualización; si alguien logra acceder a la información sabrá inmediatamente las vulnerabilidades de un montón de blogs.
  5. Estamos a horas del lanzamiento discutiendo un cambio que fue enviado hace meses —en este punto le encuentro toda la razón: ¿porqué nadie dijo nada antes del lanzamiento? Muchas personas conocíamos el calendario del lanzamiento, vimos pasar las betas y los release candidate, pero recién ahora a alguien se le ocurre que hay otra forma de hacer las cosas. Raro, ¿no?

A todo esto, se ha actualizado la [política de privacidad->http://wordpress.org/about/privacy/] en WordPress.org, y un [usuario no identificado->http://digg.com/users/lawthomp], registrado hoy, ha enviado algunas notas a Digg al respecto y un par de comentarios bastante cizañeros.

Es cierto, hay mucho de FUD en esto (como decía antes, ¿por qué justo ahora aparecen estas preocupaciones?), pero hay cosas que se pueden mejorar. En lo personal, más que la preocupación por la privacidad, me queda la preocupación por la seguridad de los datos enviados, no solo en su almacenamiento en el servidor de WordPress, sino también sobre su seguridad en el tránsito hacia allá… ¿y si fueran cifrados con una clave API de WordPress.com?

Habrá que ver en qué termina esto. Otros que han escrito al respecto: