PinguinuX

En el blog de SPECT Research, postié la solución al desafío de 8dot8 Security Conference. El link aquí.

Saludos!

En una conversación por MSN, me pegaron un link a una página de frases para Facebook. El asunto es que nunca ví el link. El link era a Frasebook.net , un sitio de frases. Me pareció extraño que solo los links a ese sitio no se mostraran, así que empezé a mirar el tráfico de red.

Para los links que contienen el string “www.frasebook.net”, el servidor de MSN responde con un mensaje NAK, que significa que el receptor no pudo recibir el mensaje (mas info en http://www.hypothetic.org/docs/msn/switchboard/messages.php). Para otros links, como a Google, el servidor de MSN no envía ningún mensaje de vuelta.

Una de las hipótesis de por qué Frasebook.net está siendo bloqueado, es porque puede estar en alguna de las muchas listas negras de spam o malware. En la única que se encuentra es en AHBL, simplemente por el lío que esta lista tiene con GoDaddy. Sinceramente no creo que esta sea la razón para estar bloqueado en MSN.

Contramedidas

El bloqueo es hacia cualquier string conteniendo “www.frasebook.net”. 

Una de las medidas puede ser redireccionar el CNAME “www” a http://frasebook.net, ya que los links a http://frasebook.net no se encuentran bloqueados. Tampoco es un bloqueo por IP, es solo al string “www.frasebook.net”, tal vez por su parecido con “facebook.com”? Quizás.

La otra medida tiene que ver con la privacidad. Se sabe que el servicio de MSN no es peer-to-peer, sino que los mensajes pasan por un servidor central, que en este caso esta analizando los mensajes de todos los usuarios en busca de strings como “www.frasebook.net” y quizás cuantos más. Proteja su privacidad, use cifrado en sus conversaciones en redes no seguras. Existen plugins para aMSN como kryptonite (desarrollado por core de Pinguinux) y que ya viene por defecto (por lo menos así se ve en el source de aMSN) o Pidgin-Encryption para Pidgin.

Be safe.

En Facebook vi un screenshot de unos tweets dudosos de Camila Vallejo.

Todo parecía indicar que era ella, pero no es ella. Visualmente es ella, pero no es el usuario de Camila Vallejo (@camila_vallejo), sino @camiIa_vallejo, una cuenta fake que se hace pasar por Camila Vallejo. ¿Cómo genera la confusión? Son dos puntos:

1. Las referencias a la cuenta fake son creadas como @camiIa_vallejo, usando en el nombre “camila” en vez de una “L” minúscula, una “i” mayúscula, quedando “camiIa”.
2. La fuente usada por Twitter no permite diferenciar entre una “l” y una “I”, por lo que visualmente son iguales.

Si liberas un proyecto open-source, es bueno tener en cuenta una serie de buenas prácticas para facilitar el desarrollo cuando múltiples personas colaboran. Aquí detallaré algunas medidas que tengo presente a la hora de lanzar un proyecto open-source, usando como plataforma Github y dejando de lado consejos sobre ingeniería de software.

Tiempo de respuesta

Si estás al frente del proyecto, debes responder rápidamente tickets, delegar responsabilidades o por lo menos confirmar que la solicitud fue recibida. Si eres parte de los desarrolladores, ayudar en esta responsabilidad compartida. Un proyecto que tarda en responder frente a bugs/reportes/peticiones, genera desinterés en los usuarios.

Tabs o espacios

De mi preferencia es usar espacios, ya que cada desarrollador tendrá la misma alineación estandar y si se quieren respetar anchos máximos, no habrá confusión entre alguien que puede ocupar un tab igual a 4 u 8 espacios.

Mención aparte es cuando pegas código externo, que también lo debes adaptar a este convenio. Mira este archivo en Translatify, contiene alineación por espacios y tabs. En mi editor, se veía perfectamente alineado, pero Github entiende con un ancho diferente los tabs. Esto dificulta cuando lees código o decides colaborar en un proyecto open-source, por lo que activa en tu editor que muestre los espacios (es una opción en Eclipse por lo menos) para visualizar los tabs y cambiarlos por espacio. Esta es la nueva versión del archivo con los tabs suprimidos. Si bien esta tarea se puede automatizar con alguna herramienta o editor, es bueno tenerlo como práctica al iniciar el proyecto.

Tags firmados

Con muchas noticias sobre repositorios hackeados o  commits con código malicioso, firma los tags que representan las versiones de release con tu llave GPG, para asegurar a los otros que fuiste tú quien envio el código. Obviamente, antes ponla en los servidores de llaves para que cualquiera pueda verificar el tag.

Limpieza del repositorio

En los repositorios va código, no ficheros de configuración de IDE’s ni backups ni binarios. Es importante mantener esta limpieza, al igual que una buena organización de los ficheros, para que colaborar en el proyecto sea un agrado.

Documentación

Procura una buena documentación. Si usas Java, usa las herramientas en Java para documentar (JavaDoc), y así en cada lenguaje (Python -> Sphinx). Sigue las indicaciones que provee cada framework de documentación para aprovecharlo al máximo y generar una documentación clara y completa.

Esta son algunas de las cosas que sigo, ¿cuales añadirías?.

Saludos