Stéphane Bortzmeyer a écrit 645 commentaires

Pas de problème. Vas-y. J'attends l'annonce de ton routeur sur LinuxFr :-)

Comme nom, je suggère Yakafokon.

Curieux, les nombreuses remarques sur le prix. Je croyais les Linuxiens surtout attachés à la liberté ? (Parce que, si on se fout du logiciel et matériel libre, il y a des tas de solutions moins chères, la plus évidente étant de garder la box du FAI…)

Si on laisse en place la box (une spécificité française, au passage) du FAI, pour gérer téléphone et télévision, ne laissant "que" Internet au Turris Omnia, cela me semble simple (en tout cas, chez Free, ça a marché du premier coup, et cela aurait encore mieux marché si je n'avais pas bouclé un câble Ethernet entre deux ports du Turris…)

Le Raspberry Pi n'a pas d'Ethernet gigabit (d'ailleurs, il n'a qu'un port). Ni de Wi-Fi (au prix de base).

Pour le prix, voir le site officiel (284 $ aujourd'hui).

Oui, on a le choix pour le Wi-Fi (2,4 ou 5). Cf. mon article :-)

Hmmm, pas de prise téléphonique sur l'Omnia, pas de logiciel installé par défaut pour gérer la téléphonie et aucune coopération à attendre d'Orange, donc je dirais que c'est mal parti.

Bizarre question. La liste des noms de domaines possibles est quasi-infinie. Vu la limite à 63 caractères, même en se limitant à ASCII (37 caractères possibles, avec les chiffres et le tiret), cela fait 37⁶³ noms possibles, soit 1499398741586788200414239710724876101933611366003344657118522818557991334322919287339806483 domaines (.com n'en compte que 130000000).

D'accord pour la nationalisation et la transformation des employés en fonctionnaires :-)

« les différentes phases ont commencé à 12h00 chaque jour et non à midi » Je ne comprends pas. 12 h et midi, ce n'est pas pareil ?

Un nom de domaine est facturé 4,5 € par an aux bureaux d'enregistrement. Je vous laisse imaginer ce qu'on peut faire comme vérification à ce tarif, même si les employés étaient payés au SMIC.

Parce que des tas de registres ont déjà essayé cela et que ça achoppe toujours sur le même problème : comment détecter les ventes "cachées" (celles où le titulaire affiché ne change pas mais où un accord secret transfère le domaine à quelqu'un d'autre) ?

Il vaut mieux avoir une base de données fiable (où le titulaire enregistré est le vrai) plutôt que de se lancer dans ces procédures d'extrême contrôle.

La décision de considérer l'usage d'un nom de domaine pour le courrier seul comme "du gaspillage" me parait très arbitraire et subjective.

Des zexplications à moi sur GNUnet : https://www.afnic.fr/fr/ressources/blog/le-systeme-de-nommage-de-gnunet-3.html

Il contient des belles conneries, comme de reprendre sans aucune nuance ni recherche critique les affirmations du voleur (qui aurait soi-disant consulté des juristes).

L'article de Next Inpact dit que « L'idée est ainsi de fournir la solution aux clients des hébergeurs, par exemple pour l'achat d'un nom de domaine. » Étant donné que le principal financier a son propre TLD (hébergé chez Verisign), cette possibilité sera-t-elle pour le .MAIF ou également pour d'autres TLD ?

Leftpad en C est là : https://github.com/lovenunu/leftpad-c

Expliquant ce que Ray Tomlinson avait fait (à part inventer le courrier électronique) : http://mailarchive.ietf.org/arch/msg/ietf/QIvFYGOJTEkPhXqRGsbxbImmEx8

Non, cette histoire de sécurité est largement pipeau http://www.bortzmeyer.org/ipv6-securite.html

Voici ce que donne l'exploitation "officielle" https://github.com/fjserna/CVE-2015-7547 sur une Debian "sid" (alias "unstable").

On git clone le code et on lance le serveur DNS méchant (il faut être root car il écoute sur le port privilégié 53) :

% sudo python CVE-2015-7547-poc.py

On modifie le /etc/resolv.conf pour utiliser ce résolveur DNS ("nameserver 127.0.0.1"). On teste :

% wget http://rue89.com/
--2016-02-17 15:59:53-- http://rue89.com/
Resolving rue89.com (rue89.com)... zsh: segmentation fault wget http://rue89.com/
Patatras, on a bien la bogue :-( Le serveur affiche :

[UDP] Total Data len recv 27
[UDP] Total Data len recv 27
Connected with 127.0.0.1:60873
[TCP] Total Data len recv 58
[TCP] Request1 len recv 27
[TCP] Request2 len recv 27
Et, vu avec tcpdump, cela donne (notez la taille de la réponse UDP, 2569 octets…) :

16:49:27.565275 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 69: 127.0.0.1.40012 > 127.0.0.1.53: 50702+ A? rue89.com. (27)
16:49:27.565306 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 69: 127.0.0.1.40012 > 127.0.0.1.53: 1856+ AAAA? rue89.com. (27)
16:49:27.575962 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 2569: 127.0.0.1.53 > 127.0.0.1.40012: 1856| 0/0/0 (2527)
16:49:27.576263 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 74: 127.0.0.1.45586 > 127.0.0.1.53: Flags [S], seq 1826763891, win 43690, options [mss 65495,sackOK,TS val 1657736187 ecr 0,nop,wscale 7], length 0
Maintenant, on patche (remettre un résolveur qui marche, puis "aptitude update && aptitude dist-upgrade" puis remettre le résolveur méchant dans resolv.conf). Et on réeessaie :

% wget http://rue89.com/
--2016-02-17 18:12:27-- http://rue89.com/
Resolving rue89.com (rue89.com)... failed: Name or service not known.
wget: unable to resolve host address ‘rue89.com’
C'est parfait, on n'est plus vulnérable.

Si, Serge Julien, dans son commentaire.

Si vous voulez crasher vos logiciels utilisant la vieille libc, voici un service utile :

http://5.150.196.47/

Débrancher les machines marcherait aussi… Ces conseils stupides vont avoir des conséquences : plus de connexion IPv6, plus de sécurité (en coupant DNSSEC et en limitant la taille).

Donc, oui, c'est stupide et il est regrettable que des publications comme Hacker News http://thehackernews.com/2016/02/glibc-linux-flaw.html aient repris ce conseil de manière acritique.

Par ailleurs, si on a un parc de 800 machines, et aucun mécanisme pour les mettre à jour, on est de toute façon mal parti…

Un mauvais article de la BBC (la grande majorité des objets, de l'embarqué, n'utilise pas la glibc) http://www.bbc.com/news/technology-35592916 et un autre d'Ars Technica (qui reprend les mauvais conseils des mainteneurs de la glibc) http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/

http://www.nextinpact.com/news/97886-ian-murdock-le-ian-debian-est-decede-a-age-42-ans.htm