L’initiative est intéressante pour deux raisons :

• L’ICANN a tendance à oublier la neutralité du réseau dans certaines des ses actions (par exemple : l’invalidation de certains noms de domaines sur de simples présomptions), l’émergence de modèles alternatifs à l’ICANN est donc important pour le bon fonctionnement d’un Internet libre et ouvert
• C’est le premier TLD numérique, les RFC ne l’excluent pas mais certains développeurs n’ont jamais eu l’occasion de tester le bon fonctionnement de leur code avec ce type de domaines.

En particulier les développeurs de Lighttpd qui ont eu la bonne idée d’inclure un parsing supplémentaire pour le header Host de chaque requête HTTP traitée. Cette fonctionnalité n’est a priori pas nécessaire pour respecter les RFC et n’apporte pas grand chose d’un point de vue sécurité (si le parsing générique des headers HTTP contient une vulnérabilité, ce parsing ne protégera qu’un seul header et ne bloquera pas l’exploitation sur les autres headers). Par contre ce parsing renvoi une erreur sur TLD numériques : le parseur se prend les pieds dans le tapis quand il parse en commençant par les derniers caractères majinboo.42, il pense qu’il parse une IP alors qu’il est en train de parser un FQDN.

Comme je suis d’une humeur fainéante aujourd’hui et que je ne voyais pas l’intérêt de ce parsing, je me suis limité à un patch désactivant ce parsing. Voici donc le patch quick’n'dirty à déposer dans files/src-request.c si vous utilisez le port FreeBSD :

--- src/request.c.orig  2010-12-28 14:44:38.000000000 +0100
+++ src/request.c       2010-12-28 14:45:30.000000000 +0100
@@ -1102,23 +1102,23 @@
}

/* check hostname field if it is set */
-       if (NULL != con->request.http_host &&
-           0 != request_check_hostname(srv, con, con->request.http_host)) {
-
-               if (srv->srvconf.log_request_header_on_error) {
-                       log_error_write(srv, __FILE__, __LINE__, "s",
-                                       "Invalid Hostname -> 400");
-                       log_error_write(srv, __FILE__, __LINE__, "Sb",
-                                       "request-header:\n",
-                                       con->request.request);
-               }
-
-               con->http_status = 400;
-               con->response.keep_alive = 0;
-               con->keep_alive = 0;
-
-               return 0;
-       }
+//     if (NULL != con->request.http_host &&
+//         0 != request_check_hostname(srv, con, con->request.http_host)) {
+//
+//             if (srv->srvconf.log_request_header_on_error) {
+//                     log_error_write(srv, __FILE__, __LINE__, "s",
+//                                     "Invalid Hostname -> 400");
+//                     log_error_write(srv, __FILE__, __LINE__, "Sb",
+//                                     "request-header:\n",
+//                                     con->request.request);
+//             }
+//
+//             con->http_status = 400;
+//             con->response.keep_alive = 0;
+//             con->keep_alive = 0;
+//
+//             return 0;
+//     }

switch(con->request.http_method) {
case HTTP_METHOD_GET:

Tout d’abord, il faut savoir que la plupart des outils réseaux de base n’acceptent pas par défaut les adresses IPV6, suivant le cas, un flag doit être précisé sur la ligne de commande ou un binaire supplémentaire existe. Voici une petite liste des correspondances IPV4 -> IPV6 :

• ping -> ping6
• traceroute -> traceroute6
• ifconfig -> ifconfig inet6
• nmap -> nmap -6

Il n’y a donc que très peu de changement, juste quelques caractères en plus à taper. Au niveau du /etc/rc.conf, il suffit d’activer l’IPV6 et de préfixer l’ensemble des directives de configuration réseaux par ipv6_, ce qui donne dans le cas du serveur qui héberge ce blog :

ipv6_enable="YES"
ipv6_ifconfig_em0="2001:14c8:500:117:d9ae:cea0:0:a9 prefixlen 96"
ipv6_static_routes="default"
ipv6_route_default="default 2001:14c8:500:117:d9ae:cea0:0:be"

Les changements sont donc mineurs, d’autant plus que contrairement au IPTables de Linux, PF supporte IPV6 nativement, il n’y a donc pas de PF6 (à la manière d’IP6Tables) à installer et configurer pour sécuriser les flux IPV6.

Bien entendu afin de quantifier l’impact des dernier patchs, j’ai fais quelques bench avant (8.1-RELEASE à jour) et après (8-STABLE compilé il y a une semaine). Le protocole de test est assez simple : on lance un iozone avec 5 threads concurrents sur une partition ZFS. Deux cas différents ont été testés : le cas de « petits » fichiers (100 Mo par fichier) : les 1024 Mo de RAM du serveur permettent alors de cacher au moins une partie des fichiers de tests, dans le deuxième cas de test, les fichiers font 1 Go. Pour chaque test, la taille de l’enregistrement était paramétré à 4 Ko, ce qui est volontairement faible et explique les faibles débits sur les lectures / écritures non séquentielles.

« Petits » Fichiers

Dans ce test, la RAM aide à maintenir les performance lors des accès aléatoires et concurrents. Les gains de performances lors des lectures / écritures parallèles sont impressionnants.

« Gros » fichiers

Dans ce test, la RAM aide beaucoup moins, les gains de performance sont plus faibles mais restent quand même appréciables.

Conclusion

Les gains de performances des derniers patchs ZFS sont réellement significatif, la compilation d’une version stable n’étant pas forcement adaptée à toute les situations, certains préférons néanmoins attendre la sortie de la prochaine release pour en profiter.

Tout a commencé à 16h avec l’ouverture des portes de la Péniche alors que certains attendait sur le quai depuis un moment déjà. Quelques binouzes plus tard, il est déjà 17h et c’est le début des conférences et l’heure des choix cornéliens : chacun des deux étages de la Péniche héberge une conférence différente. Il faut donc choisir entre deux bonnes conférences ce qui n’est pas tout le temps facile. Je n’ai malheureusement pas eu l’occasion de suivre les premières conférences car trop occupé à finalisé la conférence que j’ai présenté à 19h15.

Une fois ma conférence terminée, je peux enfin profiter totalement de l’évènement et enchainer les conférences. Tout d’abord, GeoHot : Hacking embedded devices avec des détails sur l’état de l’art du hacking de la PS3. Ensuite, cde nous a présenté le déboguer opensource xdbg qui n’atteint pas encore le niveau de IDA Pro mais semble très prometteur. Puis c’est au tour de Mathieu Suiche qui nous explique comment analyser la mémoire physique d’un mac sous leopard et fini par récupérer le mot de passe de l’utilisateur stocké dans un buffer qui n’a pas jamais été vidé par le process de logon. (Il faudra que je test ça sur mon macbook 10.6.4)

La fin des conférences permet d’aller faire un tour du côté des workshops, j’ai malheureusement raté le hack de caddie made in la grotte du barbu. Par contre, j’ai vu des gens très intéressants reprogrammer une LiveBox et Xavier de Xavbox reprogrammer des consoles de jeux. Le concept des workshops permet de créer un hacker space temporaire qui s’accorde très bien avec le reste de la soirée.

Le reste de la soirée a été partagé entre un concert rock terminé par un mix électro et les différents challenges (CTF + challenge public très varié). Pour ma part, j’ai donné quelques coup de mains à droite et à gauche et j’ai discuté avec quelques hackers qui avaient pour certains fait plusieurs centaines de kilomètres pour évènement.

Concernant HZVault, les slides de la conférence sont disponibles ici et là. La release de l’outil aura lieu dans quelques jours.

Cependant, cette solution peut aussi engendrer certaines instabilités, en particulier sur les machines virtuelles générant beaucoup d’IO. Voici donc quelques astuces pour obtenir le meilleur d’une machine virtuelle avec VMWare ESXi.

• Rester si possible en FreeBSD 7.x : la version 8.0 n’est pour l’instant pas officiellement compatible avec ESXi
• Tuning du /boot/loader.conf afin de garder une horloge relativement fiable (en effet, dans un contexte virtualisé, le processeur virtuel « saute » facilement des ticks qui sont données à une autre machine virtuelle) :

  kern.hz=100

• Tuning du /etc/sysctl.conf afin d’optimiser la partie système de fichier :

  vfs.read_max=256

• Tuning du /etc/rc.local afin d’optimiser les accès aux disques durs virtuels (à adapter en fonction du nombre de disques durs virtuels) :

  camcontrol tags da0 -N 127
  camcontrol negotiate 0:0 -a -W 16 -O 127 -R 160.000

• Enfin, il est recommandé d’installer la version opensource des VMWare Tools disponible via le port /usr/ports/emulators/open-vm-tools-nox11 (Attention, ce port nécessite d’avoir les sources du kernel disponible dans /usr/src)

Il est où mon device ?

La réponse à cette question fait un peu plus de 3 lettres. Contrairement à ce que semble indiquer le handbook sur la page dédié au ports séries. Le device du port série n’est pas forcement /dev/sio0. Sur les cartes mères récentes, c’est en général /dev/cuau0. Afin de rester dans la confusion, il est aussi à noter que la détection de ce device n’apparait dans /var/run/dmesg.boot. La seule solution que j’ai trouvée pour vérifier que le port série a bien été détecté a donc été de lister le contenu de /dev.

Comment je l’utilise ?

Dans le cas le plus fréquent de nos jours : connexion à l’interface de management d’un équipement réseau, la marche à suivre est relativement simple. Il suffit d’utiliser le programme cu (installé par défaut) en précisant le device (option -l) et éventuellement la vitesse (option -s). Pour récupérer, à la vitesse impressionnante de 9600bps, la console d’un équipement connecté sur le premier port série, il faudra donc éxecuter la commande ci-dessous.

 # cu -l /dev/cuau0 -s 9600 

Lien vers l’article

Lien vers l’article

Malheureusement, je suis passé sur la dernière version de Firefox et vu qu’aucune mise à jour n’a été effectué par le mainteneur du plugin, le plugin n’était plus utilisable. Heureusement pour moi, les plugins Firefox sont en fait de simple fichiers ZIP contenant une description et une archive JAR qui contient des fichiers javascripts et css. Après quelques modifications, j’ai pu réaliser une version du plugin compatible avec Firefox 3.5. Le mainteneur a été contacté mais pour les impatients la version modifiée du plugin est disponible à cette adresse : http://mirror.labs.fr/pub/Firefox/asnumber_35.xpi.

Astuce : Si vous voullez heberger des extensions Firefox sur votre propre serveur, il ne faut pas oublier d’associer l’extension .xpi au mime-type application/x-xpinstall.

Et c’est là que les problèmes commencent. Pas pour Google, ce sont de grand enfants, ils savent quand ils vont publier, ils savent donc quand patcher leurs serveurs. Par contre, ils oublient que reveler une faille un jeudi soir [1] et juste quelques heures après que le patch ait été ajouté dans les sources Linux, c’est rendre l’ensemble des serveurs Linux vulnérable pour au moins un week-end. Et ça n’a pas manqué aucune distribution majeure n’a eu de patch prêt avant lundi.

Jusqu’à hier, on avait donc quasiment l’ensemble des Linux du monde vulnérable et avec comme seule solution de patchage des grosses bidouilles. C’est quand même assez genant, et cela est totalement opposé aux règles communement admises pour la révalation de failles de sécurité. [2]

[1] http://seclists.org/fulldisclosure/2009/Aug/0173.html

[2] http://www.wiretrip.net/rfp/policy.html