Diablotins & Démons Web

Afin de soutenir l’initiative du 42Registry, ce blog est désormais aussi accessible via l’URL http://majinboo.42/. L’extension .42 n’étant pas une extension officielle de l’ICANN, il faut utiliser un resolver avec une configuration spécifique (cf le site du 42Registry)

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:

Vu que la fin du monde pénurie d’adresses IP V4 est pour bientôt, il devient de bon ton de se mettre à l’IPV6. Nous allons donc voir dans cet article comment cela ce passe au niveau de FreeBSD.

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.