Starend

J’ai mis en place une machine pour me permettre de tunneliser un certain nombre de choses depuis la Colombie. La messagerie par exemple…
Cette machine est une machine virtuelle hébergée par une vraie machine qui tourne dans le placard. Le tout animé par xen.

Il existe déjà des tutoriels sur le net pour installer la machine hôte Debian avec xen et pour créer des machines virtuelles notamment avec l’outil xen-create-image.

Mais… les choses ne seraient pas assez simple sinon… je veux plutôt installer une machine virtuelle Debian 7 en utilisant le DVD d’installation et non en passant par debootstrap ou tout autre méthode similaire…

(suite…)

Je bataille depuis un moment avec un serveur Kimsufi de chez OVH. Ce serveur a une adresse IPv4 et une grande plage d’adresses IPv6. Chouette!

Mais…
Si s’adresse IPv4 et la plage IPv6 sont bien disponibles et fonctionnels, je galère sous FreeBSD v9.0. En l’état, la route par défaut en IPv6 tombe sans prévenir au bout d’une demi-heure après le reboot de la machine…
Donc ce n’est pas bien utilisable en l’état (l’IPv6 bien sûr).

J’ai essayé par tous les moyens depuis le fichier de configuration /etc/rc.conf de changer cette route par défaut. J’ai même modifié /etc/sysctl.conf. Rien n’y fait, le système attribue automatiquement par défaut une adresse de lien local. Cette adresse marche, mais elle n’est pas configurée comme STATIC… donc elle disparaît au bout d’un certain temps.

Je n’ai pas trouvé quel script de démarrage force cette route sur une adresse de lien local (rtsol par exemple). Donc je choisi une autre solution moins élégante mais efficace : je supprime puis force ma route par défaut en fin de démarrage.
Il faut créer le fichier /etc/rc.local avec :
route del -inet6 default
route add -inet6 default 2001:XXXX:XXXX:eaff:ff:ff:ff:ff -static
Changer les droits du fichier (chmod 755 /etc/rc.local).

Et voila, on a notre route par défaut au démarrage, et elle ne tombe pas !

Ref :
– http://www.freebsd.org/doc/handbook/network-ipv6.html
– http://forum.ovh.com/showthread.php?t=85332
– http://help.ovh.com/Ipv4Ipv6#link10
– http://forums.freebsd.org/showthread.php?t=21804

Les divulgations autour du programme PRISM font se poser des questions à beaucoup de monde. Une des solutions préconisée est d’utiliser des outils de chiffrement et/ou d’anonymisation.

On savait déjà que l’anonymisation de données avait des limites. Des études au USA ont permit de retrouver les identités de personnes à partir de données anonymisées de la sécurité sociale. Le big data présente toutes les caractéristiques pour permettre des corrélations aboutissant au rattachement de données isolées à des personnes.

Mais intéressons-nous au réseau TOR. Ce réseau de re-routage et d’anonymisation a été conçu aux USA. Il est aujourd’hui encore maintenu par une fondation américaine.

La page de Wikipédia sur TOR parle d’une possibilité d’attaque dite Time Pattern, c’est à dire une attaque sur l’empreinte temporel des flux réseaux passants par des nœuds TOR. En effet, un nœud qui reçoit un paquet réseau TOR essaye comme un routeur de le renvoyer au plus vite vers le nœud suivant, et ainsi de suite jusqu’au serveur destinataire. La façon (temporel) qu’une machine a de « parler » sur le réseau est donc assez bien retransmise jusqu’au serveur destinataire.

Il faut, me direz-vous, pouvoir sniffer le serveur destinataire et le poste client (si il est connu), mais sûrement aussi tous les relais TOR intermédiaires pour pouvoir remonter du serveur au client. Cette méthode permet de lever l’anonymisation.
Si il semble facile, au moins pour un gouvernement, de capturer le trafic réseau d’un serveur en particulier, il semble difficile de pouvoir faire la même chose pour tous les nœuds TOR et encore moins tous les postes clients du monde, même pour un gouvernement. La robustesse du réseau TOR repose sur cette propriété.
Le réseau TOR repose aussi sur de la cryptographie, mais uniquement pour les échanges « proches ». Et cela ne protège pas du Time Pattern.

Or, que fait PRISM ?
Et bien il fait justement cette chose qui semble difficile à faire : capturer le trafic réseau d’une grande partie des ordinateurs de l’Internet, voir peut-être tous. Et cela comprend les serveurs, les nœuds TOR et les postes clients…