6039 links

  • GuiGui's Show

  • Home
  • Login
  • RSS Feed
  • Tag cloud
  • Picture wall
  • Daily
Links per page: 20 50 100
◄Older
page 90 / 302
Newer►

  • modprobe.d : install versus blacklist

    Rappel : si une instruction blacklist <nom_module> ajoutée dans /etc/modprobe.d/blacklist.conf (ou autre fichier .conf dans le même dossier) n'empêche pas le chargement d'un module dans le noyau Linux, on peut utiliser l'instruction install <nom_module> /bin/true. J'avais oublié.

    Quelle différence ? Un module a un nom présentable (genre « uvcvideo ») et des noms techniques qui correspondent aux matériels pris en charge par le module (exemple : « usb:v0416pA91Addcdscdpic0Eisc01ip00in* » est la désignation technique d'un ensemble de caméras USB pris en charge par le module uvcvideo).

    blacklist a pour effet d'inhiber les noms techniques. Donc, quand Linux détecte un matériel, il cherche dans les modules, il ne trouve pas de nom qui correspond au matériel, donc il ne charge pas le module (pourtant présent sur le système), donc le matériel n'est pas activé / pris en charge. En revanche, si le module est désigné par son nom présentable par un autre module ou par l'administrateur système (modprobe <nom_module>), alors il sera chargé.

    install permet de faire exécuter une commande au lieu de charger un module. Tout le temps. Même si le module est appelé par son nom présentable par l'adminsys ou par un autre module.

    Commande pour vérifier que modprobe a bien pris en compte une configuration déposée dans /etc/modprobe.d/ : modprobe --showconfig. C'est très verbeux, donc il faut y aller à coup de grep.

    Il n'est pas forcément nécessaire de reconstruire l'initrd (avec update-initramfs -vuk <version_noyau>) après l'exclusion d'un module. C'est utile uniquement si l'initrd est susceptible de charger ledit module, donc plutôt sur les modules de matériels (pas vboxnetflt, le module "réseau pont" de VirtualBox, par exemple) nécessaires au boot (pas uvcvideo pour une caméra USB, par exemple).

    13/06/2020 15:20:41 - permalink -
    - http://shaarli.guiguishow.info/?pA_R_g

  • Datagueule : Utopie(s) ? par #DATAGUEULE — KissKissBankBank

    Il reste une semaine pour financer une série de vidéos documentaires dont chaque épisode d'une heure mettrait en avant une alternative (dite utopie) qui existe quelque part dans le monde. Des vidéos dont des entretiens permettent de se faire une idée du projet.

    Série produite par les personnes de #Datagueule qui ont déjà eu recours au financement participatif pour leur film Démocraties(s) ?.

    Je trouve l'idée excellente : prendre connaissance de ce qui se fait ailleurs, apprendre de ce qui fonctionne ou non, voir que des alternatives fonctionnent à grande échelle, découvrir des façons de faire qui, à titre individuel, nous correspondent mieux, etc.

    07/06/2020 13:36:29 - permalink -
    - https://www.kisskissbankbank.com/fr/projects/dtg-utopies

  • Story Time : L'enfer du bug non-reproductible ! - Antichesse (o ^ω^ o)

    Bien joué pour l'analyse du problème. :)

    Le PC-P de @Lenny tout comme le mien ont une partition Ext4 chiffrée ! Or mon PC Fixe a une partition en clair et il faut savoir qu'une partoche Ext4 en claire permet des chemins de fichiers de 255 caractères tandis qu'une Ext4 chiffrée est limitée à 143 caractères ! Le voilà notre coupable...

    Quel procédé utilises-tu pour chiffrer ta partition ext4 ?

    Pour ma part, j'utilise dm_crypt+luks et je peux utiliser les 255 octets (oui, octets, pas caractères : si tu mets un caractère Unicode dans un nom de fichier, tu perds 2 octets alors qu'un seul caractère est affiché) autorisés par ext4 pour un nom de fichier. La longueur maximale du chemin d'un fichier permise par ext4 est de 4 096 octets. C'est logique que dm_crypt ne réduise pas cette limite d'ext4 car il se place au-dessous de tout système de fichiers.

    J'en déduis que t'utilises probablement une surcouche cryptographique aux systèmes de fichiers comme EncFS ou eCryptfs. La limite que tu rencontres viendrait donc de cette surcouche cryptographique, pas du fait que tu utilises de la crypto (regarde, j'en fais et je conserve la limite de 255 octets).

    Grâce à toi, j'ai découvert qu'ext4 propose le chiffrement natif. J'ai essayé viteuf : c'est bien bien bien le bazar. La taille maximale du nom d'un fichier est toujours de 255 caractères.

    01/06/2020 20:17:38 - permalink -
    - https://cakeozolives.com/shaarli-antichesse/?_pazcA

  • Changer la douille d'un point lumineux

    Résumé : ce shaarli est pour les noobs du bricolage dans mon genre. Si l'intensité lumineuse d'une ampoule LED fluctue avant de rendre l'âme prématurément, alors il y a très probablement un faux contact quelque part, soit à l'intérieur de la douille (entraînant l'oxydation des broches de la LED, ce qui, à terme, empêche le courant de passer), soit à l'extérieur de la douille, soit du côté du domino, soit…. Ce faux-contact est amplifié / réduit par l'action de la chaleur (d'où la fluctuation incompréhensible de l'intensité de l'ampoule). Il faut changer la douille ou le domino. Si tu dois changer la douille et que t'es aussi peu à l'aise que moi en bricolage, achètes une douille avec les fils pré-dénudés. N'oublie pas de désarmer le disjoncteur responsable du circuit. Le reste va bien se passer.



    En août 2019, je change une ampoule dans ma salle de bain. Il s'agit d'une ampoule LED avec un culot GU5.3 (ampoule avec des broches de taille intermédiaire). Elle est placée dans un spot tout en métal et orientable encastré dans un faux plafond / plafond suspendu.

    Pour changer l'ampoule d'un tel spot, il """"suffit"""" (en pratique, c'est bien galère…) de retirer la tige en métal qui se trouve sur la façade de l'ampoule (il faut presser les """"languettes" qui ressortent). Ça sert à rien de retirer le spot du plafond (car, au final, il faudra forcément jouer avec la tige sus-mentionnée). Je n'avais pas compris ça, donc j'avais tout démonté. Cela avait cassé (enfin, je croyais…) l'un des deux ressorts qui tiennent le spot plaqué contre le faux plafond depuis l'intérieur (le spot est attiré par la gravité, les ressorts font pression sur le Placo pour y résister). (Pour les curieux, c'est moi qui ai remis viteuf le ressort sur le spot avant de prendre la photo, mais il ne tient plus, il ne fait plus pression.)



    En novembre 2019, pendant plusieurs jours l'intensité lumineuse de cette même ampoule fluctue : diminue, augmente, diminue longtemps, petit pic de retour à la normale, rechute, etc. Puis elle cesse de fonctionner. Une durée de vie de trois mois, c'est quand même très très court, même en tenant compte des astuces des fabricants pour en réduire la durée de vie (à ce sujet, voir le documentaire Prêt à jeter (voir mes notes)). D'autant que l'autre ampoule de la pièce fonctionne toujours, alors qu'elle a une durée d'utilisation égale à celle de l'ampoule défectueuse et de sa prédécesseure…

    Je re-démonte le spot du plafond. L'une des broches de l'ampoule a glissé et n'est plus totalement enfoncée dans la douille. Je mets ça sur le compte du poids du spot (ben oui, il tient dans le plafond grâce à un seul ressort depuis août). Je remets tout en place. Ça re-foire quelques minutes après…

    Rétrospectivement, il y avait des indices concernant l'origine du problème : le fait que tripoter la douille fasse s'allumer ou s'éteindre l'ampoule, le fait que la broche de l'ampoule qui glisse hors de la douille soit oxydée, etc. Mais, sur le coup, je ne percute pas et je décide d'abandonner : il me reste une ampoule fonctionnelle dans la pièce, ça me suffit amplement, hop, problème suivant.



    Mi-mai 2020, pouf, le spot tombe sur le sol. Le seul ressort restant a faibli. Je décide de m'intéresser au problème car j'ai désormais un trou dans mon plafond (l'emplacement du spot) et je crains que la vapeur d'eau abîme le Placo dont la face intérieure ne doit pas être traitée pour résister à l'eau (la douche est à moins de 10 cm de ce spot). Comme à chaque fois que je comprends rien au monde qui m'entoure, je fais appel à professeur Johndescs en lui envoyant une série de clichés englobant tout le circuit, de l'ampoule au domino en passant par le spot et la douille.

    Concernant le ressort qui a sauté en août 2019, il suffit de le réarmer. Sa tige externe doit être plaquée contre l'intérieur du spot. Sa tige interne doit être plaqué contre l'extérieur du spot. Bref, prendre exemple sur le ressort restant. J'étais convaincu qu'il manquait des pièces qui auraient sauté en même temps et que je n'aurai pas retrouvé, mais, non, ça juste fonctionne !

    Concernant la fluctuation de l'intensité lumineuse / extinction impromptue de l'ampoule, son origine est très probablement un faux contact causé et amplifié par la chaleur. Sur les photos, Johndescs repère qu'un des plots du domino est un peu bruni. Il pense à un faux contact de ce côté-là et me préconise de tirer sèchement sur le câble vissé sur ce plot. Pas de chance, le câble ne me reste pas entre les mains, donc, a priori, le faux contact n'est pas ici.

    Côté douille, on remarque un fil un peu dénudé (hou le coquinou !). En le tripotant, je peux l'enfoncer plus ou moins profond dans la douille, et dans certains cas, l'ampoule s'allume et reste allumée tant que je maintiens la position. OK, le faux contact est ici. La broche de l'ampoule qui est oxydée est justement en contact avec ce fil électrique. Tout s'explique. Les fils électriques étant soudés à l'intérieur de la douille, on ne peut pas les ré-ajuster nous-même, il faut remplacer la douille.



    J'achète une douille GU5.3.

    Je sais dénuder du câble réseau avec la pince dédiée, mais sans pince, je ne vois pas comment dénuder des fils électrique, sauf à utiliser au couteau. Et vu ma maîtrise, c'était plutôt mon doigt qui allait finir dénudé. Coup de chance, ils étaient pré-dénudés !

    Y'a plus qu'à désarmer le disjoncteur du circuit lumineux, puis dévisser les deux fils de la douille côté domino puis insérer l'un des fils de la nouvelle douille (j'ai inséré un peu plus profond que le pré-découpage, genre 2 mm en plus, car ça se voyait qu'il manquait ça) puis visser le plot tout en maintenant fermement le fil, puis faire la même chose avec le deuxième fil. Si quelques filaments du fil n'entrent pas, ou pas totalement, ce n'est pas grave vu qu'il s'agit d'un fil qui va transporter 50 tout petits watts…

    J'apprends deux choses :

    • Je pensais qu'un domino est forcément une multiprise, que l'on s'en sert forcément pour dupliquer un câble (afin de brancher les prises / points lumineux d'une même pièce sur un même disjoncteur). C'est faux. Dans le cas présent, il sert d'indirection qui permet un changement facile de la douille sans démonter le plafond ;

    • Les plots / trous d'un domino sont conducteurs. Il n'y a donc pas besoin de faire toucher les fils électriques. Chaque fil dans son trou / plot, et le domino fait circuler le courant entre les plots / trous qui sont face à face.

    Je remercie les gus qui ont posé l'électricité chez moi : tous les points lumineux de ce secteur (plusieurs pièces, donc) sont sur un même disjoncteur. La pièce où je dois intervenir n'ayant pas de fenêtre, et la lumière du jour qui arrive par rebond étant insuffisante, j'aurais bien aimé pouvoir profiter de la lumière artificielle de la pièce alentour… Mais non. Je n'ai pas de lampe-torche, donc j'ai bricolé au flash de mon ordinateur de poche. :D

    Reste à ré-armer le disjoncteur puis à actionner l'interrupteur. Johndescs m'avait prévenu : si l'un des fils touche celui opposé, ça fera un court-circuit et le disjoncteur sautera, c'est le pire qui puisse t'arriver (ce qui m'avait motivé à agir : si le plus grand risque est celui-ci, ça va quoi). Hé bah même pas : ça fonctionne. \o/



    Bientôt une semaine que ça chemar. J'ai changé la douille d'un point lumineux pour la première fois et je suis très fier de moi. \o/

    01/06/2020 19:17:06 - permalink -
    - http://shaarli.guiguishow.info/?hByQ5A

  • BPCE : les emails non plus…

    J'ai voulu signaler leur problème DNS à la Banque Populaire et à la Caisse d'Épargne, mais impossible de leur envoyer un email.

    Le serveur emails pour tous les domaines dont font partie les adresses emails techniques trouvées dans les bases de données publiques accessibles avec le protocole whois (et bientôt RDAP ?) est mail-in.bpce-it.fr.

    Celui-ci refuse mes emails pour le motif suivant : « 550 #5.7.5 DKIM unauthenticated mail is prohibited. If you believe that this failure is in error, please refer to https://tools.ietf.org/html/rfc6376 or contact postmaster [à] bpce-it.fr for more information via alternate means. »

    J'ai bien envoyé mon courriel via le seul serveur emails autorisé pour mon domaine.

    Étrangement, un email envoyé par Stéphane depuis un domaine qui n'implémente pas DKIM passe très bien. Cela illustre que DKIM n'est pas obligatoire pour communiquer avec BPCE. Peut-être qu'une signature DKIM devient obligatoire quand la réputation de l'adresse IP ou du réseau du serveur emails émetteur est questionnable ? Mon serveur est hébergé chez OVH, émetteur de spam malgré lui, alors que celui de Stéphane est dans un réseau IP de bonne réputation.

    Encore plus étrange : mes emails sont bien signés en suivant la norme DKIM. Peut-être y a-t-il un problème technique de mon côté ?

    Je m'envoie un email à une autre adresse que je gère et qui met en œuvre la validation DKIM : à l'arrivée, les entêtes de l'email confirment qu'il comporte bien une signature DKIM et que celle-ci est valide : « Authentication-Results: viki.guiguishow.info; dkim=pass (3072-bit key; secure) header.d=[CENSURE] header.i=@[CENSURE] header.b="PGTxFJuT"; dkim-atps=neutral ».

    Il existe des testeurs de serveur emails. J'en ai utilisé trois (plus que ça en vrai, mais certains ne fonctionnent plus) : https://www.mail-tester.com/ , auth-results [à] verifier.port25.com , et ping [à] stamper.itconsult.co.uk . Tous les trois confirment la présence et la validité d'une signature DKIM dans mes emails sortant. Il semble donc que le problème est du côté de BPCE.

    De plus, j'ai configuré une politique ADSP souple, « dkim=all » qui signifie "normalement, tout courriel émanant de ce domaine sera signé, mais si ce n'est pas le cas, ne le jete pas à la corbeille, stp". Évidemment, elle a la valeur d'un conseil : le récepteur fait bien ce qu'il veut.

    Pour signer les entêtes de mes emails sortants, mon serveur emails utilise une clé RSA 3072 bits. C'est la taille recommandée par l'ANSSI (document B1) pour mettre sérieusement en pratique de la cryptographie au long terme. Mais, c'est vrai que, pour signer des emails dans le cadre de la lutte anti-spam (c'est l'objet de DKIM), une clé de taille inférieure serait suffisante. Néanmoins, début 2018, le RFC 8301 a mis à jour le RFC de DKIM (6376) : « Signers SHOULD use RSA keys of at least 2048 bits. Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. ».

    Je conçois bien un problème à ce niveau-là : ma clé est rejetée en raison de sa taille, donc mon email est considéré comme étant non signé, donc, soit la réputation du réseau de mon serveur emails joue contre lui, soit BPCE-IT est intransigeant avec les domaines qui ont une politique ADSP fut-elle souple. Cette hypothèse a été confirmée par BPCE-IT : « […] en raison d’une limitation de notre produit actuel, nous ne pouvons pas vérifier de signature au-dessus de 2048 bits et il ne connait pas la notion de politique ADSP. Ainsi la signature 3072 bits est traitée en erreur […] ».

    A priori, ce souci a été signalé à BPCE-IT par Stéphane, merci. :)

    31/05/2020 17:21:24 - permalink -
    - http://shaarli.guiguishow.info/?BbXzTQ

  • Problème DNS BPCE : la Caisse d'Épargne également impactée

    Après la publication de l'article Le problème DNS de la semaine par Banque Populaire, Stéphane et moi-même avons lu des témoignages sur Twitter relatant qu'un problème similaire serait en cours à la Caisse d'Épargne depuis, a priori, le même laps de temps : ici, là-bas, là, encore là, ici aussi, là-bas, et puis ici et enfin là.

    Banque Populaire et Caisse d'Épargne faisant partie du même groupe, BPCE, ce n'est pas surprenant.



    Nous avons déjà posé les définitions et exposé le contexte dans l'article sur le problème DNS à la Banque Populaire, donc passons directement à la résolution du nom www.caisse-epargne.fr à la main :

    $ dig @d.nic.fr www.caisse-epargne.fr
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr.  172800  IN  NS  ns1.gcetech.net.
caisse-epargne.fr.  172800  IN  NS  ns2.gcetech.net.
[…]

$ dig @91.135.176.225 www.caisse-epargne.fr
[…]
;; AUTHORITY SECTION:
www.caisse-epargne.fr.  86400   IN  NS  nslp2.gcetech.net.
www.caisse-epargne.fr.  86400   IN  NS  nslp1.gcetech.net.
[…]

$ dig @91.135.188.225 www.caisse-epargne.fr
[…]
;; AUTHORITY SECTION:
www.caisse-epargne.fr.  86400   IN  NS  nslp2.gcetech.net.
www.caisse-epargne.fr.  86400   IN  NS  nslp1.gcetech.net.
[…]

$ dig @91.135.177.240 www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr.  120 IN  A   91.135.178.85
[…]

$ dig @91.135.189.240 www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr.  120 IN  A   91.135.178.85
[…]

    Constat ?

    • Tout comme à la Banque Populaire, le nom www.caisse-epargne.fr est délégué ;

    • Contrairement à la Banque Populaire, deux serveurs DNS qui font autorité situés dans deux réseaux IP différents (mais situés dans une même infrastructure technique et administrative / organisationnelle) assurent le service, ce qui est le minimum syndical en matière de DNS ;

    • Comme à la Banque Populaire, on relève un TTL (durée de vie de l'information associée à un nom DNS dans le cache des serveurs récursifs) court, mais acceptable. Si un tel délai est très utile lors d'une migration afin de rendre la bascule effective sous un court délai, il est déconseillé le reste du temps, car, ne bénéficiant pas des caches, le moindre problème technique entraînera une panne d'une toute autre ampleur. De plus, des hébergeurs de serveur DNS récursif réécrivent, donc ignorent, les TTL courts (c'est le cas de l'opérateur Free, par exemple).



    Jusque-là, le problème reste entier. Continuons à creuser.

    Les serveurs DNS qui font autorité pour la zone www.caisse-epargne.fr, nslp1.gcetech.net. et nslp2.gcetech.net. , répondent NODATA (cette information n'existe pas dans le type demandé, mais des informations d'un autre type existent pour le nom demandé) aux requêtes DNS de types NS et SOA :

    $ dig @91.135.177.240 SOA www.caisse-epargne.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42171
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr.  60  IN  SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]

$ dig @91.135.189.240 SOA www.caisse-epargne.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5107
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr.  60  IN  SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]

$ dig @91.135.177.240 NS www.caisse-epargne.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18648
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr.  60  IN  SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]

$ dig @91.135.189.240 NS www.caisse-epargne.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3758
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr.  60  IN  SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]

    Cela est totalement contraire à la norme DNS et cela peut bloquer certaines implémentations de récursifs DNS (voire certaines versions d'une même implémentation), ce qui explique le côté aléatoire et partiel de la panne.



    Mais, cette fois-ci, l'impact de ce choix technique est plus subtil :

    $ dig @1.1.1.1 A www.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15150
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @80.67.169.12 A www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr.  120 IN  A   91.135.178.85
[…]
;; Query time: 2302 msec
[…]

$ dig +short @80.67.169.12 version.bind chaos txt
"unbound 1.9.0"

$ dig @80.67.169.40 A www.caisse-epargne.fr
[…]
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

$ dig +short @80.67.169.40 version.bind chaos txt
"unbound 1.6.0"

    Le comportement du service de résolution des noms de CloudFlare reste inchangé.

    En revanche, si aucun des serveurs DNS récursifs du FAI FDN parvient à résoudre www.banquepopulaire.fr, l'un d'eux, un Unbound en version 1.9 parvient à résoudre le nom www.caisse-epargne.fr. On notera qu'il met environ 2 secondes pour ce faire, ce qui est très long et révélateur d'un problème. Le serveur Unbound en version 1.6 ne parvient pas à résoudre www.caisse-epargne.fr.

    Cela explique pourquoi je n'ai pas perçu que la Caisse d'Épargne était également impactée quand j'ai diagnostiqué le problème de la Banque Populaire : mon Unbound local transmet toutes mes requêtes DNS aux deux serveurs DNS récursifs de FDN (afin de profiter de la mutualisation de cache, donc de réduire la charge sur les serveurs DNS qui font autorité de tous les services Internet que j'utilise) et comme l'un répond, j'accède sans problème au site web de la Caisse d'Épargne.



    Quelle est donc cette implémentation de serveur de noms DNS qui accepte de charger une zone DNS dépourvue d'enregistrements de types SOA et NS ?

    $ dig +short @nslp1.gcetech.net. version.bind chaos txt
"none"

$ dig +short @nslp2.gcetech.net. version.bind chaos txt
"none"

    Ça ressemble quand même fortement à un BIND qu'on aurait configuré avec « version "none"; » au lieu de « version none; », mais rien permet de justifier cette affirmation. Comme à la Banque Populaire, il est très probable qu'une (ou plusieurs) middlebox, équilibreur de charge ou non, soit présente entre ces serveurs DNS et Internet et qu'elle soit responsable de cette panne partielle par altération des réponses du serveur ou filtrage de certaines requêtes.



    Notons que la Caisse d'Épargne n'a pas fait la même erreur que la Banque Populaire : les serveurs DNS qui font autorité pour www.caisse-epargne.fr, nslp1.gcetech.net. et nslp2.gcetech.net. répondent en UDP et en TCP :

    $ dig +tcp @91.135.177.240 A www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr.  120 IN  A   91.135.178.85
[…]

$ dig +tcp @91.135.177.240 NS www.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61730
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr.  60  IN  SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]

$ dig +tcp @91.135.189.240 A www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr.  120 IN  A   91.135.178.85
[…]

$ dig +tcp @91.135.189.240 NS www.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61788
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr.  60  IN  SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]



    En revanche, les équipes techniques de la Caisse d'Épargne devraient réviser la syntaxe du champ « RNAME » d'un enregistrement DNS de type SOA. Il permet d'indiquer une adresse email permettant de signaler un problème. Dans le cas de la Caisse d'Épargne :

    $ dig +short SOA caisse-epargne.fr
ns1.gcetech.net. postmaster.it-ce.fr. 2020052602 21600 3600 1209600 86400

$ dig @91.135.177.240 SOA www.caisse-epargne.fr
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr.  60  IN  SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]

// Selon la convention d'usage, l'adresse emails doit donc être hostmaster@P-SR1-IGTM1.big.caisse-epargne.fr
$ dig MX P-SR1-IGTM1.big.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29793
[…]

$ dig A P-SR1-IGTM1.big.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2114
[…]

// Non. L'adresse doit être hostmaster.P-SR1-IGTM1 à big.caisse-epargne.fr (il aurait fallu l'indiquer en mettant un « \. » entre « hostmaster » et « P-SR1-IGTM1 ». 
$ dig MX big.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8736
[…]

$ dig A big.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51961
[…]

// Non. L'adresse n'est quand même pas hostmaster.P-SR1-IGTM1.big à caisse-epargne.fr ?! (Et si oui, même remarque que ci-dessus)
$ dig +short MX caisse-epargne.fr
5 mail-in.bpce-it.fr.

$ telnet mail-in.bpce-it.fr. 25
Trying 91.135.189.237...
Connected to mail-in.bpce-it.fr.
Escape character is '^]'.
220 mail-in.bpce-it.fr ESMTP
EHLO test.guiguishow.info
250-mail-in.bpce-it.fr
250-8BITMIME
250-SIZE 28311552
250 STARTTLS
MAIL FROM:<[CENSURE]>
250 sender <[CENSURE]> ok
RCPT TO:<hostmaster [à] P-SR1-IGTM1.big.caisse-epargne.fr>
550 #5.1.0 Address rejected.
RCPT TO:<hostmaster.P-SR1-IGTM1 [à] big.caisse-epargne.fr>
250 recipient <hostmaster.P-SR1-IGTM1 [à] big.caisse-epargne.fr> ok
RCPT TO:<hostmaster.P-SR1-IGTM1.big [à] caisse-epargne.fr>
250 recipient <hostmaster.P-SR1-IGTM1.big [à] caisse-epargne.fr> ok
QUIT
221 mail-in.bpce-it.fr
Connection closed by foreign host.

    La deuxième adresse, hostmaster.P-SR1-IGTM1 [à] big.caisse-epargne.fr , est invalide puisqu'aucun serveur d'emails est défini pour ce domaine (si l'on tente d'envoyer un email, le MTA émetteur remonte légitimement l'erreur suivante : « Host or domain name not found. Name service error for name=big.caisse-epargne.fr type=AAAA: Host not found »). Vu les élements, le contenu du champ « RNAME » devrait être « hostmaster\.P-SR1-IGTM1\.big.caisse-epargne.fr ». Ça a aucun rapport avec la panne partielle dont traite cet article, mais c'est tout de même un problème de configuration.



    Alors, au final, quelle est l'origine du problème ?

    Difficile à dire. On le saura jamais vraiment, toute entité (société commerciale, administration, association, personne) étant toujours très réticente à faire des retours sur ses erreurs / fautes / échecs.

    Je pense qu'il y a une middlebox (ou plusieurs) entre Internet et les serveurs DNS qui font autorité pour la zone DNS www.caisse-epargne.fr qui, comme tout boîtier prétendument magique ‒ qui externalise de fait la réflexion ‒ souvent imposé au service informatique par la direction afin qu'elle puisse prétendre œuvrer pour la sécurité des clients sans investir ni comprendre / maîtriser la technique sous-jacente, doit forger des réponses DNS invalides (NODATA pour les types SOA et NS).

    Néanmoins, ça n'explique pas l'intégralité du problème. Pourquoi la plupart des serveurs DNS récursifs de la planète parviennent à résoudre les noms de la Caisse d'Épargne ? Les différentes implémentations de qname-minimisation amplifient-elles le problème ? Aucune idée…



    Merci à Stéphane Bortzmeyer pour son aide, son soutien ainsi que sa motivation pour faire remonter ces pannes à BPCE, notamment sur Twitter.

    31/05/2020 13:41:42 - permalink -
    - http://shaarli.guiguishow.info/?TqC4Ug

  • Le problème DNS de la semaine par Banque Populaire

    Depuis au moins jeudi 28 mai 2020 à 22 h 45 (UTC+2), impossible d'accéder à certains sites web du groupe Banque Populaire Caisse d'Épargne :

    • https://www.banquepopulaire.fr ne fonctionne pas (vitrine + SSO) ;

    • https://www.ibps.loirelyonnais.banquepopulaire.fr ou https://www.ibps.bpaca.banquepopulaire.fr ou https://www.ibps.mediterranee.banquepopulaire.fr/ ne fonctionnent pas (accès à l'espace personnel) ;

    • https://groupebpce.com/ fonctionne.

    • ÉDIT DU 31/05/2020 À 14 H 05 : www.caisse-epargne.fr est également impacté, voir Problème DNS BPCE : la Caisse d'Épargne également impactée. FIN DE L'ÉDIT DU 31/05/2020.



    Qu'est-ce qui ne fonctionne pas, précisément ? La résolution des noms DNS. Mon navigateur web Mozilla Firefox affiche « Recherche de […] » puis « Hum, nous ne parvenons pas à trouver ce site. ».

    Comme d'habitude, Twitter fournit des témoignages dont le plus savoureux relate :

    Bonjour @BanquePopulaire impossible de se connecter avec l’application sur iPhone depuis hier soir et donc de déverrouiller ma carte bancaire... C’est un problème général?

    À quel moment tu t'es dit que c'est génial de débloquer une carte bancaire avec un logiciel pour ordinateur de poche ?! Tout peut foirer ! Ton ordinateur de poche peut tomber en panne, ton opérateur de téléphonie mobile aussi, un opérateur Internet de transit idem, Banque Populaire également, etc. Ce choix d'une telle dépendance à une technologie est hallucinant.



    J'ai mon accès à Internet fixe chez le Fournisseur d'Accès à Internet associatif FDN et j'utilise les serveurs DNS récursifs de ce dernier. Le problème est le même depuis un serveur OVH (en utilisant les serveurs DNS récursifs d'OVH). Le service de résolution des noms de CloudFlare parvient jamais à résoudre le nom. Celui de Google y parvient plutôt souvent, mais il y a encore des ratés. Depuis un accès à Internet Orange avec un dnsmasq local, ça fonctionne difficilement ou pas du tout.

    La transmission réseau entre FDN (ou OVH ou Orange) et le réseau Banque Populaire est OK : un mtr -T -P 443 91.135.183.174 montre ni incident réseau ni perte de paquets.

    Le niveau applicatif est OK : un openssl s_client -connect 91.135.183.174:443 -crlf permet de dialoguer en HTTPS avec l'un des serveurs de la Banque Populaire. Une mesure depuis le réseau RIPE Atlas confirme cela, voire la mesure numéro 25558553.

    Enfin, ajouter une association IP pour les noms www.ibps.bpaca.banquepopulaire.fr et www.banquepopulaire.fr dans mon fichier /etc/hosts rend ces sites web parfaitement fonctionnels. Attention : utiliser ce contournement uniquement pour des tests ! Si Banque Populaire change les adresses IP de ses services, la surcharge locale rendra inaccessibles les services.

    On confirme donc un problème de résolution de certains des noms DNS de la Banque Populaire.



    Néanmoins, mes mesures avec le réseau RIPE Atlas montre un faible taux d'échec de la résolution DNS : mesure numéro 25556510, mesure numéro 25556573 et mesure numéro 25556574.

    Effectuons la résolution DNS à la main :

    $ dig @d.nic.fr www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
banquepopulaire.fr.        172800        IN        NS        dns2.bpce.fr.
banquepopulaire.fr.        172800        IN        NS        dns1.bpce.fr.

;; ADDITIONAL SECTION:
dns1.bpce.fr.                172800        IN        A        91.135.189.110
dns2.bpce.fr.                172800        IN        A        91.135.177.110
[…]

$ dig @91.135.189.110 www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.ibps.bpaca.banquepopulaire.fr. 3600        IN NS
nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.177.110 www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.ibps.bpaca.banquepopulaire.fr. 3600        IN NS
nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.182.250 www.ibps.bpaca.banquepopulaire.fr
[…]
;; ANSWER SECTION:
www.ibps.bpaca.banquepopulaire.fr. 30 IN A        91.135.183.174
[…]

$ dig @91.135.189.110 www.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.banquepopulaire.fr.        3600        IN        NS        nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.177.110 www.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.banquepopulaire.fr.        3600        IN        NS        nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.182.250 www.banquepopulaire.fr 
[…]
;; ANSWER SECTION:
www.banquepopulaire.fr.        30        IN        A        91.135.183.180
www.banquepopulaire.fr.        30        IN        A        91.135.183.180
[…]

$ dig @k.gtld-servers.net. groupebpce.com
[…]
;; AUTHORITY SECTION:
groupebpce.com.                172800        IN        NS        dns1.bpce.fr.
groupebpce.com.                172800        IN        NS        dns2.bpce.fr.
[…]

$ dig @91.135.189.110 groupebpce.com
[…]
;; ANSWER SECTION:
groupebpce.com.                3600        IN        A        151.101.194.133
groupebpce.com.                3600        IN        A        151.101.2.133
groupebpce.com.                3600        IN        A        151.101.66.133
groupebpce.com.                3600        IN        A        151.101.130.133
[…]

$ dig @91.135.177.110 groupebpce.com
[…]
;; ANSWER SECTION:
groupebpce.com.                3600        IN        A        151.101.130.133
groupebpce.com.                3600        IN        A        151.101.66.133
groupebpce.com.                3600        IN        A        151.101.2.133
groupebpce.com.                3600        IN        A        151.101.194.133
[…]

    On constate trois choses :

    • Les noms www.ibps.*.banquepopulaire.fr, www.*.banquepopulaire.fr et www.banquepopulaire.fr sont délégués à un seul serveur de noms DNS qui fait autorité ! C'est une très mauvaise pratique !

    • Le nom corporate (présentation du groupe), groupebpce.com, dispose d'une qualité de service supérieure à celle des noms utilisés par les clients de la Banque Populaire (pour consulter leurs comptes, entrer en contact avec leur conseillère, etc.) : deux serveurs de noms, de multiples adresses IPs sur lesquelles récupérer le contenu du site web, etc. Amusant. Ça expose les priorités. Ça explique pourquoi je parviens à accéder au site web https://groupebpce.com tout en ne parvenant pas à accéder au site web de ma banque régionale Banque Populaire ;

    • Un TTL (durée de vie de l'information associée à un nom DNS dans le cache des serveurs récursifs) très court (30 secondes). Si un tel délai est très utile lors d'une migration afin de rendre la bascule effective sous un court délai, il est très déconseillé le reste du temps, car, ne bénéficiant pas des caches, le moindre problème technique entraînera une panne d'une toute autre ampleur.



    Jusque-là, le problème reste entier. Continuons à creuser.

    Le serveur qui fait autorité pour les zones www.ibps.*.banquepopulaire.fr et www.banquepopulaire.fr , nsisp1.i-bp.banquepopulaire.fr , répond négativement aux requêtes de types NS et SOA :

    $ dig @91.135.182.250 SOA www.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17798
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @91.135.182.250 NS www.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 36129
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @91.135.182.250 SOA www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31905
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @91.135.182.250 NS www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17813
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

    Cela est totalement contraire à la norme DNS et cela peut bloquer certaines implémentations de récursifs DNS (voire certaines versions d'une même implémentation), ce qui explique le côté aléatoire de la panne.

    Les serveurs DNS dns1.bpce.fr et dns2.bpce.fr répondent aux requêtes de types NS et SOA pour la zone groupebpce.com, ce qui explique que le site web corporate fonctionne là où les autres sites web ne fonctionnent pas.



    Le serveur DNS nsisp1.i-bp.banquepopulaire.fr ne répond pas aux requêtes DNS émises au-dessus du protocole TCP :

    $ dig +tcp @91.135.182.250 A www.banquepopulaire.fr
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +tcp @91.135.182.250 A www.banquepopulaire.fr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.

    C'est, là encore, totalement contraire à la norme DNS : tout serveur DNS doit être accessible sur udp/53 et tcp/53.



    Cette absence de réponse aux requêtes de types SOA/NS posera encore plus de problèmes aux récursifs DNS qui implémentent la qname minimisation, un mécanisme qu'il faut activer car il participe à la préservation de la vie privée des utilisateurs d'un serveur DNS récursif. En effet, une divergence d'interprétation de la norme existe concernant la recherche des délégations. On rappelle au passage qu'une délégation DNS ne se voit pas à l'œil nu. Exemples : bpaca.banquepopulaire.fr n'est pas délégué par banquepopulaire.fr, ibps.bpaca.banquepopulaire.fr n'est pas non plus délégué par bpaca.banquepopulaire.fr. Bref : un point entre deux labels d'un nom de domaine ne marque pas forcément une délégation. Afin d'identifier les délégations, certaines implémentations, comme Unbound, effectuent des requêtes de type A (que le serveur DNS nsisp1.i-bp.banquepopulaire.fr accepte, pour rappel), d'autres des requêtes de type NS (qui sont refusées par nsisp1.i-bp.banquepopulaire.fr).

    Concernant l'amplification du problème par certaines implémentations de qname minimisation dans les serveurs DNS récursifs , le mystère continue, car :

    $ dig +short @80.67.169.40 version.bind chaos txt
"unbound 1.6.0"

$ dig +short @80.67.169.12 version.bind chaos txt
"unbound 1.9.0"

$ dig +short @::1 version.bind chaos txt
"unbound 1.9.0"

$ dig +short @80.67.169.12 www.ibps.bpaca.banquepopulaire.fr
;; connection timed out; no servers could be reached

$ dig @80.67.169.12 www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33639
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig +short @::1 www.ibps.bpaca.banquepopulaire.fr
91.135.183.174

    En clair : une même version d'Unbound œuvrant sur le même réseau IP, deux comportements différents. Que j'active ou non la qname-minimisation sur mon Unbound local (sur mon accès à Internet fixe FDN, donc), ça fonctionne. Peu importe le type de qname-minimisation, souple ou stricte.

    Même chose avec un BIND9.16 sur mon accès à Internet FDN : quelle que soit la configuration retenue pour la qname-minimisation (« strict » ou « relaxed »), ça fonctionne. J'ai réussi à obtenir un « SERVFAIL » en mode « relaxed », mais je n'arrive pas à le reproduire sur demande (même en redémarrant BIND, même en le stoppant+rallumant).

    Dans le sens inverse, on peut exposer que le résolver de CloudFlare implémente la qname-minimisation (source) et que, justement, il ne parvient pas à résoudre les noms de la Banque Populaire sus-mentionnés.

    Bref, on peut affirmer tout et son contraire.



    Mais, pourquoi les sondes du réseau RIPE Atlas ne remontent-elles pas un taux d'échec de la résolution DNS plus élevé ? Concentration des serveurs DNS récursifs utilisés. Au sein d'un même réseau, celui d'Orange par exemple, tous les clients (au sens commercial du terme) vont utiliser le même serveur DNS récursif, celui d'Orange (ou celui de Google Public DNS ou celui de CloudFlare). Si le serveur DNS récursif parvient à résoudre le nom une fois, toutes les sondes Atlas situées dans ce réseau en bénéficieront le temps du TTL (durée de rétention de l'information dans le cache du serveur récursif, 30 secondes dans le cas présent). Rappelons que les serveurs DNS récursifs de certains réseaux, comme Free, sont connus pour ré-écrire les TTL jugés courts (les ignorer, donc), ce qui permet de limiter l'ampleur de l'effet "ça marche, ça marche plus, ça marche, etc.".



    Les TTL courts amplifient l'aspect "ça marche, ça marche plus".



    Alors, au final, quelle est l'origine du problème ?

    Difficile à dire. On le saura jamais vraiment, toute entité (société commerciale, administration, association, personne) étant toujours très réticente à faire des retours sur ses erreurs / fautes / échecs.

    Je pense qu'il y a une middlebox entre Internet et le serveur DNS qui fait autorité nsisp1.i-bp.banquepopulaire.fr qui, comme tout boîtier externalisé prétendument magique imposé au service informatique par la direction afin qu'elle puisse prétendre œuvrer pour la sécurité des clients sans investir ni comprendre / maîtriser la technique sous-jacente, doit bloquer certaines requêtes DNS de manière excessive (sur-blocage). Qu'est-ce qui me fait penser cela ? L'implémentation de serveur qui fait autorité est un BIND 9.11.5-P4 (dig @91.135.182.250 CH TXT version.bind ;) ). Ce logiciel refuse de charger une zone DNS dénuée de NS/SOA (« zone [CENSURE]/IN: has 0 SOA records […] zone [CENSURE]/IN: has no NS records […] zone [CENSURE]/IN: not loaded due to errors. »), donc, si l'on a des réponses, sauf pour les types NS et SOA, c'est probablement un intermédiaire entre nous et le serveur qui les vire.

    Néanmoins, ça n'explique pas l'intégralité du problème. Pourquoi deux serveurs récursifs DNS avec la même version d'Unbound ne parviennent pas au même résultat ? Pourquoi la plupart des serveurs DNS récursifs de la planète parviennent à résoudre les noms de la Banque Populaire ? Les différentes implémentations de qname-minimisation amplifient-elles le problème ? Aucune idée…



    La Banque Populaire est coutumière d'une configuration DNS défectueuse.

    En 2015, le nom banquepopulaire.fr était délégué à deux serveurs de noms Orange Business Services (ex Oléane) qui n'étaient pas configurés pour ce nom (on nomme ça une lame delegation). Les deux autres serveurs DNS qui font autorité étaient internes au groupe BPCE et cessaient de répondre aux requêtes (UDP et TCP) au moins une fois par semaine, et notamment le dimanche matin entre 11 h et 12 h. Amusant, non ?

    Comme ces derniers jours, il y avait des tweets (notamment celui-ci), mais ça n'a pas suffit. Stéphane Bortzmeyer et moi-même avons envoyé des emails à toutes les adresses BPCE pertinentes trouvées. Il a fallu deux mois avant d'avoir un acquittement (email acquitté le 24/08) et plusieurs mois pour que le problème soit corrigé…



    Merci à Stéphane Bortzmeyer de m'avoir expliqué l'origine probable de cette panne partielle. L'outil dnsviz m'avait bien pointé l'absence de réponse aux requêtes de type SOA/NS de la part du serveur nsisp1.i-bp.banquepopulaire.fr , mais je ne l'ai pas interprété correctement.

    30/05/2020 17:13:11 - permalink -
    - http://shaarli.guiguishow.info/?F7a6EA

  • Dépôts inamovibles au fond de la cuvette des toilettes ? Utiliser un détartrant

    Résumé : si t'as des dépôts couleur merde au fond de la cuvette de tes toilettes qui ne partent pas avec les produits ménagers habituels, utilise un détartrant pour salle de bain. Oui, ce shaarli est pour les noobs de la vie dans mon genre.



    Je nettoie la cuvette de mes toilettes avec du vinaigre blanc / d'alcool à 8 % d'acidité. J'ai beau laisser agir (plus de trente minutes / une heure), j'ai beau frotter des dizaines de minutes avec le côté grattant d'une éponge, une brosse de toilettes et même avec une brosse à dents pour les recoins, il reste pas mal de dépôts couleur merde (forcément) au fond de la cuvette, notamment dans les recoins bien pénibles à nettoyer. On dirait une espèce de pâte, un chouïa élastique.

    Quand je ne comprends pas le monde qui m'entoure, j'appelle professeur Johndescs à la rescousse. Qui m'explique que c'est très probablement du tartre qui dégagera si j'utilise un détartrant.

    J'achète le premier détartrant venu. Non, pas celui pour la cafetière, le lave-vaiselle et autres appareils. Celui pour salle de bain, sanitaires, robinetterie, carrelage mural, baignoire, douche, lavabo, etc. Genre ça, là. Je démonte le pulvérisateur. Je verse environ la moitié du flacon qui contient 500 ml. J'attends un quart d'heure. J'essuie le fond de la cuvette avec du PQ. je tire la chasse. Hop, la cuvette est propre. Deux fois que je fais ça et que ça fonctionne impec'. C'était donc bien du tarte…

    Du coup, il est aisé de répondre à la question « pourquoi j'ai jamais eu ça avant ? ». Parce que j'ai jamais résidé aussi longtemps dans une même habitation, donc le tartre n'a pas eu l'occasion de se déposer. Parce que le taux de calcaire dans l'eau varie en fonction de la localisation géographique et que j'ai jamais habité dans cette région française avant.

    26/05/2020 22:17:33 - permalink -
    - http://shaarli.guiguishow.info/?gS8s1Q

  • Bonjour TLS v1.3

    Le protocole TLS 1.3 a été publié en 2018. Ce protocole permet de sécuriser (confidentialité, authentification, intégrité) les communications sur Internet de tout type (web, emails, messagerie instantanée, téléphonie, etc.) de point à point (d'un client à un serveur, par opposition à un chiffrement de bout en bout, c'est-à-dire d'un internaute à un autre). Pour plus d'infos sur TLS 1.3, voir le billet de blog de tonton Bortzmeyer, l'article Prise en main de TLS 1.3 avec OpenSSL 1.1.1 publié dans le numéro 226 de GLMF et l'article RFC 8446 - TLS 1.3 : que faut-il attendre de cette nouvelle version ? publié dans le numéro 105 de MISC.

    Pour ma part, je retiens :

    • Grand nettoyage :

      • RSA n'est plus utilisable pour échanger des clés de session (nécessaires pour le chiffrement symétrique), donc il reste uniquement des échanges de clés DH qui garantissent la confidentialité persistante / future ;

      • Tous les algos démodés / foireux (RC4, algos de chiffrement par bloc dits CBC, MD5, SHA-1, etc.) dégagent. Il reste cinq suites cryptographiques (dont trois sont activées par défaut dans OpenSSL), toutes basées sur le chiffrement intègre (AEAD) afin de pallier aux attaques à texte choisi contre les algos CBC (genre BEAST) et aux attaques par rembourrage contre la manière d'implémenter la preuve d'intégrité dans les algos CBC (la dénommée Mac-then-Pad-then-Encrypt, voir l'article de tonton Bortz) genre POODLE, même si une extension TLS permet depuis plusieurs années de passer au mode plus sécurisé Encrypt-then-Pad-then-Mac). En résumé, les grandes familles d'algos à notre disposition sont les suivantes : échange de clés éphémères = DHE ou ECDHE, authentification (signature) = RSA ou ECDSA (DSA dégage, tout comme la possibilité de présenter des certificats OpenPGP) et chiffrement symétrique = AES AEAD. Enfin, si dans les versions précédentes de TLS, on peut négocier des courbes, leurs paramètres et des groupes finis de DH, avec TLS 1.3, il n'est plus possible d'utiliser des paramètres (courbes, points sur les courbes, groupes finis DHE, etc.) maison pour (EC)DHE, il faut utiliser exclusivement ceux normalisés. L'idée est d'éviter les paramètres foireux et/ou générés par une implémentation foireuse (ça s'est déjà vu) ;

      • La compression TLS et la renégociation des clés de session en cours de route n'existent plus. Vu les attaques les utilisant genre CRIME, ce n'est pas une perte. La reprise d'une session fonctionne désormais comme un échange de clé partagée, il n'y a plus de code informatique dédié à cette fonctionnalité ;

      • Pour l'authentification des messages TLS, si l'on utilise RSA, alors on l'utilise forcément avec le schéma / profil RSA-PSS (Probabilistic signature scheme) défini dans la version 2.1 du standard PKCS#1 qui est plus robuste que celui de la version 1.5 de PKCS#1 qui rendait possible des attaques par rembourrage genre ROBOT. Pour l'authentification du pair (serveur ou client), les implémentations doivent supporter RSA-PSS (c'est la nouveauté) et le prioriser dans la négociation, mais sans plus ;
    • La poignée de main TLS est désormais partiellement confidentielle et intègre. Ça explique pourquoi, au sein d'un échange TLS, on voit très rapidement des messages du type « Application data » auparavant réservés au seul contenu applicatif protégé : ces messages contiennent désormais la fin de la poignée de main sous une forme chiffrée. C'est ça, qui rend envisageable ESNI, le chiffrement du SNI, c'est-à-dire le nom du serveur que l'on cherche à contacter (utile sur un serveur mutualisé afin que le serveur envoie le bon certificat x509, celui du service avec lequel on veut échanger). Les clés de session (je simplifie) sont échangées dans l'extension « Keyshare » des messages « (Client|Server)Hello » puis confirmées après l'échange du certificat du serveur (afin d'en garantir l'authenticité). L'authenticité de la poignée de main n'est garantie qu'à sa fin ;

    • Afin d'éviter les pare-feux mal-conçus et les boitiers de sécurité foireux massivement déployés, TLS 1.3 imite, au niveau réseau, TLS 1.2 : la version présentée dans le message « ClientHello » est toujours 1.2 alors que la vraie version est négociée dans une extension, on conserve le champ « CompressionMethod » dans les messages « *Hello » alors qu'il n'y a plus de compression TLS (voir ci-dessus), et l'on conserve les messages « ChangeCipherSpec » qui servent pourtant plus à rien, etc. Voilà où nous en sommes pour quelques enfoirés qui font nawak :( ;

    • Une poignée de main TLS < 1.3 se fait en 2 RTT (deux allers-retours entre le client et le serveur). Hors poignée de main TCP (1 RTT) et hors requête applicative (1 RTT). Je trouve cette présentation trompeuse, car, dans un même trajet (aller ou retour), plusieurs messages TLS seront échangés, potentiellement dans des paquets IP séparés. On tombe à 1 RTT lors de la reprise d'une session existante. Un mode 0 RTT (0-RTT / early-data) apparaît avec TLS 1.3 : lors de la reprise d'une session, on peut envoyer des données applicatives (chiffrées et intègres) dès le premier message. Cela a un coût : on perd la confidentialité persistante (car les données sont chiffrées avec la clé partagée, PSK, contenue dans le ticket de session) et on se rend vulnérable à un rejeu d'une requête capturée sur le réseau. L'application doit gérer cela… sauf qu'il est très compliqué de différencier une requête non-idempotente (donc problèmatique)… Sinon, le serveur TLS doit conserver un état… ce dont personne veut, toute la reprise d'une session est et a toujours été sans état. Je vois jamais une présentation de l'intérêt du mode 0-RTT : je trouve qu'il est utile entre un reverse proxy et un serveur backend afin d'être certain d'une absence de perte de performance, par exemple, sauf si le réseau entre eux est multi-datacenters / international (auquel cas, un risque de surveillance externe existe, et encore, mieux vaut chiffrer + 0-RTT que de faire du trafic en clair) ;

      • Dans OpenSSL, le mode 0-RTT / early-data est désactivé par défaut, une application doit demander explicitement son activation à la bibliothèque cryptographique qu'elle utilise. « By default the server does not accept early data; a server may indicate support for early data by calling SSL_CTX_set_max_early_data() or SSL_set_max_early_data() to set it for the whole SSL_CTX or an individual SSL object respectively » (source). Je n'ai pas vérifié le comportement des autres implémentations de TLS.
    • Dans TLS < 1.3, un même champ permettait d'indiquer l'algo pour l'échange de clés, celui pour l'authentification (du pair et des messages TLS), celui pour le chiffrement symétrique et éventuellement celui pour garantir l'intégrité. Désormais, il y a trois champs : échange de clés = « supported groups » (anciennement « supported elliptic curves », mais vu qu'on peut aussi faire du DHE, ce nom ne se justifiait plus et il a sauté avec le RFC 7919), auth = « signature algorithms », chiffrement symétrique et intégrité = « cipher suites » (le vieux champ). Les versions précédentes de TLS utilisent aussi les extensions « supported groups » et « signature algorithms », donc TLS 1.3 acte seulement le changement sémantique du champ « cipher suites » ;

    • Il n'y a plus d'ordre imposé dans la chaîne des certificats fournie à un client TLS à l'exception que le certificat du serveur doit être le premier. C'était déjà le cas en pratique, c'est désormais dans la norme ;

    • On note l'apparition d'une extension TLS sympa nommée « certificate_authorities ». Elle indique la liste des autorités de certification connues du client, et elle peut aider le serveur à choisir un certificat qu'il enverra (par exemple en n'envoyant le certificat CAcert que si le client connait cette AC). (j'ai copié cette phrase depuis le blog de tonton Bortz).



    La bibliothèque de fonctions cryptographiques OpenSSL implémente TLS v1.3 à partir de sa version 1.1.1. Celle-ci est disponible dans la version Buster (10) de Debian. Donc ma récente mise à jour vers Debian Buster (voir mes notes sur ce qui change et/ou qui pose problème entre Stretch et Buster) m'en ouvre les portes. \o/ Notons que la protection contre le rejeu possible du mode 0-RTT (avec des états côtés serveurs ?) et l'utilisation des groupes finis DHE, entre autres, ne sont pas disponibles dans cette version.

    Pour activer TLS 1.3, il y a rien à faire, ni côté client, ni côté serveur, puisque la version de TLS est négociée lors de l'établissement d'une communication chiffrée afin d'en retenir la plus élevée.

    Néanmoins, attention aux configurations de serveurs applicatifs qui listent explicitement les versions de TLS utilisables. Exemples : un serveur d'emails Postfix configuré avec smtpd_tls_protocols = !SSLv2, !SSLv3 utilisera automatiquement TLS 1.3 si le client la prend en charge ; Idem pour un serveur IMAP/POP Dovecot configuré avec ssl_min_protocol = TLSv1.2. En revanche, un Apache httpd configure avec SSLProtocol +TLSv1.1 +TLSv1.2 n'utilisera pas TLSv1.3, il faudra le configurer explicitement (SSLProtocol +TLSv1.1 +TLSv1.2 +TLSv1.3) ou exclure les protocoles non-fiables plutôt que de lister les protocoles fiables (voir l'exemple Postfix ci-dessus).



    Comment vérifier qu'un serveur applicatif n'utilise pas le mode 0-RTT / early-data (il est désactivé par défaut, c'est aux serveurs applicatifs de l'activer, lire ci-dessus) ? En testant nous-même. Quand un serveur applicatif accepte le mode 0-RTT, il en informe tout client en positionnant l'extension « early_data » dans un ticket de session TLS. Voyons ça en pratique :

    • D'un côté, on monte un serveur TLS : openssl s_server -accept 4433 -cert <chemin_vers_certificat_x509> -key <chemin_vers_clé_privée> ;

    • De l'autre, on se connecte à ce serveur TLS : openssl s_client -connect <nom_serveur>:4433 -tlsv1_3. On remarque la ligne « Max Early Data: 0 » dans la section « New Session Ticket arrived » : 0-RTT n'est pas disponible ;

    • On interrompt (ctrl+c) le serveur TLS et on en monte un avec le mode 0-RTT activé : openssl s_server -accept 4433 -cert <chemin_vers_certificat_x509> -key <chemin_vers_clé_privée> -early_data. On relance le client TLS. Cette fois-ci, on lit « Max Early Data: 16384 », donc 0-RTT est disponible ;

    • On peut ensuite tester tous nos vrais serveurs (Apache httpd, Postfix, Dovecot, etc.) ainsi. Ne pas oublier -starttls <protocole> en fonction du cas. ;)

    • Si l'on a un doute, on peut initier une première connexion TLS en conservant le ticket (-sess_out <nom_fichier_stockage_ticket_TLS>) puis une deuxième en donnant le ticket (-sess_in <nom_fichier_stockage_ticket_TLS>) et en envoyant du contenu (-early_data early_data.txt) qu'il faut créer d'abord (avec echo 'Bonjour' > early_data.txt, par exemple). Si le serveur a accepté nos données utilisateur, OpenSSL affichera « Early data was accepted ». Sinon, il affichera « Early data was not sent ». On peut contrôler tout ça avec Wireshark en déchiffrant l'échange TLS à l'aide de SSLKEYLOGFILE (puisque ces messages TLS sont désormais chiffrés).

    On peut aussi désactiver le mode 0-RTT dans les logiciels clients. Pour Firefox et Thunderbird, cela se fait en attribuant la valeur « false » à la clé « security.tls.enable_0rtt_data » dans about:config.

    25/05/2020 00:10:39 - permalink -
    - http://shaarli.guiguishow.info/?dg4Ftw

  • Télécharger un replay France TV depuis un système GNU/Linux quand Youtube-dl n'y parvient pas - GuiGui's Show - Oros links

    Solution Youtube-dl + Tor

    Vu que j'utilise un Fournisseur d'Accès à Internet français, j'avais directement exclu l'hypothèse d'un filtrage / zonage géographique. Je viens de tester avec un bon vieux SSH port forwarding dynamique sur un serveur situé derrière une ligne Orange + youtube-dl --proxy socks5://127.0.0.1:6666 --geo-bypass -f mp4 et ça chemar. En réalité, c'est l'option -f mp4 (qui permet de sélectionner le format désiré) qui fait le boulot : si je la laisse activée tout en virant le proxy, ça continue de fonctionner.

    24/05/2020 19:40:09 - permalink -
    - https://www.ecirtam.net/links/?ZkeRzQ

  • NSS Key Log Format - Mozilla | MDN

    La variable d'environnement « SSLKEYLOGFILE » permet d'indiquer un fichier où seront stockés les secrets cryptographiques (clés de session) échangés par un programme lors de communications TLS.

    Ça fonctionne avec la majorité des bibliothèques TLS. J'ai testé avec Firefox (lib = NSS), Chromium (lib = BoringSSL), curl (lib = OpenSSL), wget et ldapsearch (lib = GnuTLS). A priori, ça fonctionne sous GNU/Linux, mais aussi sous winwin et Mac OSX.

    C'est logique, car c'est à chaque programme de vérifier l'existence de la variable d'environnement, d'ouvrir le fichier, d'appeler la callback de la bibliothèque TLS, etc. Exemple : le sous-programme s_client d'OpenSSL ne prend pas en charge cette variable, il faut utiliser le paramètre -keylogfile.

    On peut utiliser ces secrets afin de déchiffrer une communication avec Wireshark sans recourir à une attaque MitM. Généralement, le programme n'efface pas les secrets consignés lors de sessions précédentes ou par d'autres programmes (il ajoute ses secrets à la fin du fichier) , wireshark sera en mesure de déchiffrer tous les flux chiffrés qu'il a capturés, même si un logiciel a effectué plusieurs connexions chiffrées ou s'il a renégocié les clés.

    Vu que j'ai déjà déchiffré des flux avec wireshark, j'ai l'impression de redécouvrir quelque chose que je savais autrefois… Curieuse sensation… Merci à l'article Prise en main de TLS 1.3 avec OpenSSL 1.1.1 pour le rafraîchissement de mémoire.

    24/05/2020 15:33:23 - permalink -
    - https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

  • Télécharger un replay France TV depuis un système GNU/Linux quand Youtube-dl n'y parvient pas

    Je voulais récupérer le dernier épisode de Cash investigation. Comme tous ceux de la saison 2019/2020, il n'est pas disponible sur le compte Youtube de l'émission. Il ne semble pas être disponible dans la DHT BitTorrent (recherche effectuée avec le moteur de recherche DHT BTDigg). Il ne semble pas être disponible en téléchargement libre sur le web. Il est disponible en replay sur le site de France TV. Jusqu'à quand ?

    Pour en récupérer une copie, j'utilise la dernière version (2020.05.08) de Youtube-dl. J'obtiens uniquement les sept premières secondes de son. Que ce soit avec VLC, mplayer, ffmpeg, faac, sound-konverter, audacity, etc. Même en demandant à Youtube-dl de conserver séparément la piste audio et la piste vidéo (-k), la piste son reste défectueuse. Tous les logiciels sus-cités voient une fin prématurée de la piste audio. ffmpeg hurle « Invalid data found when processing input ». Elle occupe 96 mo et un cat en montre l'intégralité. Je te passe mon debug à coup de dd (dd if='Cash investigation - Egalité hommes femmes - balance ton salaire-7309baab-7d24-4d74-afd2-695d61d19e18.fhls_v5_os-audio-aacl-64-Audio_Français.mp4' bs=1 skip=99000 of=frag2.mp4 puis « skip=198000 » puis…) : la piste audio est bien complète, mais un lecteur audio quelconque échoue à le lire toutes les sept secondes, ce qui correspond à la taille d'un fragment (pour leur diffusion sur le web, les fichiers vidéos sont découpés en fragments de taille variable). Je pense donc que la concaténation des fragments pose problème. Je n'ai pas réussi à en obtenir une meilleure en demandant à Youtube-dl de conserver tous les fragments (--keep-fragments) et à fffmpeg de les chaîner.

    L'extension Firefox Video DownloadHelper ne parvient pas à télécharger la vidéo, car elle se fait berner par les fragments.

    Au final, voici une méthode qui fonctionne (ÉDIT DU 24/05/2020 À 20 H 10 : méthode beaucoup plus simple : utiliser le paramètre -f mp4 de Youtube-dl afin de sélectionner mp4 comme format désiré. Merci Oros. FIN DE L'ÉDIT) :

    • Demander à Youtube-dl de conserver séparemment l'audio de la vidéo et d'enregistrer les informations sur le média dans un fichier JSON : youtube-dl -k --write-info-json 'https://www.francetvinfo.fr/replay-magazine/france-2/cash-investigation/cash-investigation-du-mardi-19-mai-2020_3939739.html' ;

    • Récupérer l'URL du conteneur qui liste l'ensemble des fragments qui composent la piste audio (nommé, abusivement, je trouve, « liste de lecture » / « playlist ») dans le fichier d'information JSON avec jq. Il se reconnaît aisément : il y en a un seul et la description de son format contient les mots « audio only »). Allons-y : jq -r '.formats[] | select(.format | test("audio only"; "i")).url' 'Cash investigation - Egalité hommes femmes - balance ton salaire-7309baab-7d24-4d74-afd2-695d61d19e18.info.json' ;

    • Enregistrer le flux audio avec VLC. « Enregistrer le flux brut » ne fonctionne pas, il faut le convertir. Je choisis le format libre Vorbis (48 kHz, 128 kb/s). Allons-y : cvlc --play-and-exit 'https://cloudreplayfrancetv.akamaized.net/f6b0050f44ce5/229120135_france-domtom_TA.ism/ZXhwPTE1OTAyODkxNjV+YWNsPSUyZmY2YjAwNTBmNDRjZTUlMmYyMjkxMjAxMzVfZnJhbmNlLWRvbXRvbV9UQS5pc20qfmhtYWM9OTUxZjE2ZmY5MGFlMDJmOTM5NzE4NWY1MDRmNjM5OTY2Zjg5MmJhMzYyNTEzZmQ3NWE1N2Q1Mjk0ODQ5YWRiOA==/229120135_france-domtom_TA-audio_fre=64000.m3u8' --sout '#transcode{vcodec=none,acodec=vorb,ab=128,channels=2,samplerate=48000}:file{dst=cash_audio.ogg}'. On obtient le même résultat en passant par l'item « Convertir / Enregistrer » du menu « Média » de l'interface graphique, mais je veux me la péter ;

    • On attend que VLC termine le téléchargement de l'audio et que Youtube-dl termine celui de la vidéo puis on fusionne les deux dans un unique conteneur vidéo libre Matroska avec ffmpeg : ffmpeg -i 'Cash investigation - Egalité hommes femmes - balance ton salaire-7309baab-7d24-4d74-afd2-695d61d19e18.fhls_v5_os-2186.mp4' -i cash_audio.ogg -c:v copy -c:a copy Cash_investigation_-_Egalite_hommes_femmes_balance_ton_salaire.mkv.
    24/05/2020 01:51:02 - permalink -
    - http://shaarli.guiguishow.info/?AcEkgQ

  • Décrémenter un serial DNS quand on utilise OpenDNSSEC

    Lors de l'incrémentation du serial d'une zone DNS, je me trompe. Au lieu de saisir « 2020052205 », je saisis « 20200522050 » (un zéro en trop). Je demande à OpenDNSSEC de signer la zone (DNSSEC). Puis je me rends compte de mon erreur : dig SOA <domaine> affiche « 3020633059 ». Comment faire redescendre ce serial ?

    Normalement, il suffit de décrémenter le serial, de redémarrer le serveur de noms (ou de forcer le chargement de la zone sans contrôle du serial) puis de faire de même sur les slaves. Mais, il y a OpenDNSSEC au milieu et, lui, a une mémoire du serial. Si je signe à nouveau la zone après avoir remis le serial comme il faut, le serial passe à 3020633060.

    Essayons naïvement de préciser le serial sur la ligne de commande ?

    # ods-signer sign guiguishow.info --serial 2020052206
Error: Unable to enforce serial 2020052206 for zone <CENSURE>.
Zone <CENSURE> scheduled for immediate re-sign.

    Regardons les dates de modification dans /var/lib/opendnssec. Aucun fichier modifié récemment sauf une sauvegarde du fichier de zone avant sa dernière signature. Après vérification, OpenDNSSEC ne s'en sert pas comme référence pour le serial.

    En fait, le serial est lu dans le fichier de zone non signé lors du démarrage du démon signer puis il est conservé en mémoire vive.

    Il suffit donc de stopper le signer et l'enforcer (systemctl stop opendnssec-signer.service opendnssec-enforcer.service), puis de mettre le serial désiré dans le fichier de zone non signé puis de démarrer l'enforcer et le signer (systemctl start opendnssec-signer.service opendnssec-enforcer.service). Le journal d'OpenDNSSEC m'informe :

    ods-signerd: [namedb] zone <CENSURE> unable to use datecounter as serial: 2020052200 does not increase 2020052206. Serial set to 2020052207
ods-signerd: [STATS] <CENSURE> 2020052207 RR[count=23 time=0(sec)] NSEC[count=14 time=0(sec)] RRSIG[new=37 reused=0 time=0(sec) avg=0(sig/sec)] TOTAL[time=0(sec)]

    « 2020052206 » est le serial que j'ai écrit dans le fichier de zone non signé.

    Lors du chargement de la zone par OpenDNSSEC, BIND9 consigne error: zone <CENSURE>/IN: zone serial (2020052207/3020633062) has gone backwards, mais il recharge la zone.

    Sur les serveurs DNS slaves, il faudra utiliser nsd-control force_transfer <nom_zone> ou rndc retransfer <nom_zone> afin de forcer le transfert de la zone réparée sans contrôle préalable du serial.

    Fin de l'incident.

    22/05/2020 18:53:11 - permalink -
    - http://shaarli.guiguishow.info/?8sUGkw

  • systemd fait aussi du contrôle d'accès

    Je pensais qu'il y a que AppArmor et SELinux qui limitent les droits d'un logiciel sur un système de fichiers. Ben non, il y a aussi systemd, avec les directives ReadWritePaths, ReadOnlyPaths et InaccessiblePaths d'une unit de type service, donc avec les espaces de nommage Linux.

    Je l'ai découvert avec le serveur de noms nsd. Alors que je lui demandais d'écrire le fichier de zone correspond à une zone pour laquelle mon serveur est slave avec nsd-control write <nom_zone>, nsd a journalisé ce qui suit :

    nsd[14377]: nsd[14377]: info: writing zone <CENSURE>. to file /var/named/zones/slave/<CENSURE>
nsd[14377]: error: cannot write zone <CENSURE>. file /var/named/zones/slave/<CENSURE>~: Read-only file system
nsd[14377]: cannot write zone <CENSURE>. file /var/named/zones/slave/<CENSURE>~: Read-only file system

    Hé oui, je sauvegarde mes fichiers de zone, c'est-à-dire le contenu que je publie dans le DNS, dans /var/named, tout comme on met le contenu d'un site web, c'est-à-dire ce qu'on publie, dans /var/www.

    Solution :

    • systemctl edit nsd.service ;

    • Le fichier doit avoir le contenu suivant :

      [Service]
ReadWritePaths=/var/lib/nsd /etc/nsd /run /var/named/zones/slave


    • systemctl daemon-reload ;

    • systemctl restart nsd.service.
    22/05/2020 18:28:42 - permalink -
    - http://shaarli.guiguishow.info/?hGxWGQ

  • Activation de HTTP/2 sur ce site

    Résumé : activation de HTTP/2 sur ce serveur, donc migration vers mpm_event (car HTTP/2 = requêtes en parallèle dans une même connexion ce que ne peut pas gérer mpm_prefork), donc migration du module PHP pour Apache httpd (on rappellera que la fondation Apache publie d'autres logiciels que httpd : Tomcat, Storm, Ant, Kafka, Hadoop, etc.) vers PHP-FPM (car le module n'est pas multithreadé), donc suppression du chroot Apache httpd devenu inutile, donc suppression du chroot BIND9 par homogénéité entre tous les logiciels que j'utilise. Je termine par un joli bug Apache httpd quand on utilise h2c (HTTP/2 sur une connexion non chiffrée). Je rappelle que les navigateurs web prennent en charge uniquement HTTP/2 over TLS (HTTPS/2, quoi).



    Il y a quelques mois, j'ai testé l'activation de la nouvelle version du protocole qui soutient le web, HTTP/2.

    J'en avais déduis que son fonctionnement « plusieurs requêtes dans une même connexion TCP / HTTP » nécessite plutôt un module de traitement Apache httpd qui gère réellement les requêtes parallèles. Exit mpm_prefork, bonjour mpm_event (recommandé par la doc' officielle d'Apache httpd). Sauf que, le module PHP pour Apache n'est pas utilisable avec mpm_event, justement car il n'est pas multi-tâches. Il faut donc passer à PHP-FPM.

    Par défaut, PHP-FPM n'est pas chrooté. Il peut l'être. Vu les emmerdes que ça m'a apporté au fil des ans (voir ici et là), ça en m'intéresse pas. Puisque PHP n'est plus un module d'Apache httpd, est-il encore utile de chrooter ce dernier ? Apache httpd va uniquement manipuler des fichiers statiques, pas de code dynamique avec des saisies utilisateur… Un chroot aura environ aucun intérêt.

    J'ai déjà dé-chrooté MySQL car c'était la galère. Si je dé-chroote Apache httpd, il restera BIND9. Chrooter BIND9 m'a posé aucun souci pendant 10 ans. Mais, d'une part, il n'est pas chrooté par défaut, et, d'autre part, je ne l'ai pas totalement chrooté dans les règles de l'art (un chroot doit être hermétique et auto-suffisant, sans lien vers l'extérieur). Virer le chroot de BIND9, c'est assurer l'homogénéité de fonctionnement entre les logiciels que j'utilise, ce qui simplifie la mémorisation de l'architecture technique. Le seul logiciel encore chrooté sera Postfix, mais il est livré ainsi et le chroot m'a jamais posé problème.

    Mon chroot MySQL aura tenu 7 ans, mes chroots Apache httpd et BIND9 auront tenu 10 ans. Le module PHP pour Apache httpd aura tenu plus de 10 ans. Pas si mal.

    Au final, j'ai :

    • Dé-chrooté BIND9 ;

    • Dé-chrooté Apache httpd ;

    • Migré du module PHP d'Apache httpd à PHP-FPM ;

    • Activé HTTP/2 dans Apache httpd ;


    Dé-chroot-er BIND9

    Aucune difficulté : il suffit de copier (cp -a) les fichiers de zone, les clés, les journaux de transferts de zones, etc. du chroot vers l'emplacement hors chroot (/etc/bind par défaut, mais j'ai l'habitude de séparer la configuration du contenu en mettant la conf' dans /etc et le contenu dans /var/named comme l'on sépare le contenu d'un site web dans /var/www de la configuration d'un serveur web dans /etc∕) puis de retirer l'option « -t » dans /etc/default/bind9 puis de redémarrer BIND9. Si aucune erreur est consignée dans le journal, on peut supprimer le chroot avec un rm -r.


    Dé-chroot-er Apache httpd

    Il faut copier (cp -a) le contenu des sites web (les DocumentRoot) depuis l'emplacement du chroot vers /var/www puis retirer les directives de configuration ChrootDir et LoadFile du fichier /etc/apache2/apache2.conf. Dans chaque hôte virtuel (aka virtualhost), il faut s'assurer que les directives DocumentRoot et Directory sont toujours valables (si le chroot était bien fait, elles devraient l'être).

    Côté module PHP pour Apache httpd, il faut annuler la bidouille du script de nettoyage régulier des sessions PHP et virer le paramétrage d'un magasin de certificats x509 interne au chroot plutôt que le magasin par défaut du système.

    Enfin, on redémarre Apache httpd. Si aucune erreur est consignée dans le journal, on peut supprimer le chroot avec un rm -r.


    Migrer du module PHP d'Apache httpd à PHP-FPM

    J'ai déjà tout écrit dans mon shaarli sur mon test de HTTP/2 donc je vais faire court.

    Il faut…

    Installer PHP-FPM avec apt-get install php-fpm.

    Dans la configuration des hôtes virtuels (aka virtualhosts) d'Apache httpd, il faut retirer les directives php_admin_value. Si l'on veut les conserver et que leur valeur est commune à tous les hôtes virtuels, on les déplace dans le php.ini (/etc/php/7.3/fpm/php.ini). Si non, il faut créer autant de pools que de virtualhosts et mettre les directives php_admin_value dans la définition d'un pool (/etc/php/7.3/fpm/pool.d/www.conf, par exemple).

    Remplacer prefork par event : a2dismod mpm_prefork && a2enmod mpm_event.

    Désactiver le module PHP et activer l'utilisation de PHP-FPM : a2dismod php7.3 && a2enconf php7.3-fpm. Si t'as plusieurs pools, il ne faut pas activer cette conf' généraliste, mais ajouter une directive de proxy fcgi spécifique (socket différente) à l'intérieur de chaque hôte virtuel.

    Redémarrer Apache httpd. Si aucune erreur est consignée dans le journal, on peut désinstaller le module PHP pour Apache httpd : apt-get autoremove --purge libapache2-mod-php libapache2-mod-php7.3 && rm -r /etc/php/7.3/apache2.

    Les erreurs / avertissements / notifications liées au code PHP (oubli d'un point virgule, mauvais échappement d'une chaîne de caractères, etc.) sont toujours consignées dans le fichier error.log d'un hôte virtuel. Les erreurs liées à PHP-FPM toutes pools confondus (nombre maximum de processus atteint, etc.) sont consignées dans le journal d'erreur de PHP, /var/log/php7.3-fpm.log). Il est possible d'avoir un journal par pool en surchargeant error_log dans la définition du pool.

    Par défaut, le pool www est éxecuté sous le compte utilisateur www-data, c'est-à-dire… celui du serveur web. Comme avec le module PHP pour Apache httpd. On peut changer ça (ainsi que les droits sur les fichiers des sites web) mais, boarf, la motivation me manque.


    Activer HTTP/2 dans Apache httpd

    J'ai déjà tout écrit dans mon shaarli sur mon test de HTTP/2 donc je vais faire court : a2enmod http2 && systemctl restart apache2.

    Je rappelle viteuf qu'il y a trois manières d'initier une connexion HTTP/2 : extension TLS ALPN, entête HTTP/1.1 « Upgrade: h2c » sur connexion non chiffrée ou entête HTTP/1.1 « HTTP Alternative Services ». **Les navigateurs web, notamment Mozilla Firefox, prennent en charge exclusivement la première méthode (HTTP/2 over TLS, HTTPS).


    Lulz

    On notera un truc rigolo dans le journal Apache httpd access.log de l'hôte virtuel lors d'un accès h2c (HTTP/2 sur une connexion en clair, non TLS, non chiffrée) :

    2001:db8::1 - - [01/Jan/1970:01:00:00 +0100] "GET / HTTP/2.0" 200 132608 "-" "curl/7.64.0"
2001:db8::1 - - [15/Feb/2020:17:56:05 +0100] "GET / HTTP/1.1" 101 132733 "-" "curl/7.64.0"

    La connexion HTTP/2 qui a forcément eu lieu après la connexion HTTP/1.1 est consignée avant… et avec un horodatage inexact.

    Cette erreur se retrouve dans les entêtes transmis au client web :

    HTTP/1.1 101 Switching Protocols
Upgrade: h2c
Connection: Upgrade

HTTP/2 200 
date: Thu, 01 Jan 1970 00:00:00 GMT
server: Apache
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
pragma: no-cache
last-modified: Sat, 15 Feb 2020 17:08:49 GMT
vary: Accept-Encoding,User-Agent
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: text/html; charset=utf-8

    Évidemment, cela a un impact sur la durée du cache côté client web et sur tout ce qui utilise la date… ÉDIT DU 23/11/2020 À 22 H 40 : Cela impacte le calcul de la date dans l'entête « Expire » sur une image, par exemple, mais, dans cet exemple précis, la date qui apparaît dans l'entête « Expires » n'est pas une erreur de calcul liée à la date faussée par le bug h2c, mais une date symbolique passée choisie par les développeurs de PHP pour désactiver la mise en cache lors de l'ouverture d'une session sur un site web. FIN DE L'ÉDIT.

    22/05/2020 15:13:52 - permalink -
    - http://shaarli.guiguishow.info/?j22Ejw

  • Configurer l'horloge et NTP sur des switchs HP

    Comware 5

    Exemple de matériels : HP 5120 ou HP 5800.


    Fuseau horaire

    sys
clock timezone Paris add 01:00:00

    Aucune contraire sur le nom du fuseau (« Paris », dans mon exemple). On pourrait aussi le nommer par son vrai nom : CET.


    Heure d'été

    sys
clock summer-time paris-ete repeating 02:00:00 2020 March last Sunday 03:00:00 2020 October last Sunday 01:00:00

    Aucune contrainte sur le nom (« paris-ete », dans mon exemple). On pourrait aussi le nommer par son vrai nom : CEST.

    Ça se lit : tous les ans (« repeating ») à partir de 2020, à partir du dernier dimanche du mois de mars (« March last Sunday ») à 2 h du mat' (« 02:00:00 ») et jusqu'au dernier dimanche d'octobre (« October last Sunday ») à 3 h du mat' (« 03:00:00 »), ajouter une heure (« 01:00:00 »).

    L'aide de la ligne de commande nous incite plutôt à préciser la date (27/03, 27/10) de la bascule, mais vu qu'elle change chaque année, ça n'est pas pertinent.

    Je me suis questionné : faut-il fixer le point de départ sur l'année en cours (2020) ou l'année de fabrication du matériel ? En effet, à froid, le switch reviendra sur sa date de fabrication. Il n'appliquera donc pas l'heure d'été. Pas grave. Une fois que NTP aura synchronisé l'horloge (on rappelle que NTP bosse uniquement en UTC, il ignore les fuseaux horaires et autres fioritures), l'heure d'été sera appliquée.


    NTP

    sys
ntp-service unicast-server <nom_ou_adresse_IP_du_serveur> [ options éventuelles comme l'interface réseau source, la version de NTP, la priorité du serveur, etc.]

    Contrairement à une machine UNIX équipée du démon ntpd de l'ISC qui interdit une correction de l'horloge quand l'écart avec le serveur de temps est trop important, un switch HP se synchronisera même s'il a des années de retard. On lit très souvent le contraire, mais c'est inexact.


    Vérifier

    Horloge / fuseau horaire / heure d'été : display clock.

    NTP : display ntp-service sessions.


    Comware 7

    Exemple de matériels : HP 5130, HP 5510 ou HP 6600.


    Fuseau horaire

    Identique à Comware 5.


    Heure d'été

    sys
clock summer-time paris-ete 02:00:00 March last Sunday 03:00:00 October last Sunday 01:00:00

    Ça se lit comme sur Comware 5, c'est simplement plus concis.


    NTP

    sys
ntp-service unicast-server <nom_ou_adresse_IP_du_serveur> [ options éventuelles comme interface réseau source, version de NTP, priorité du serveur, etc.]
ntp-service enable

    Attention : l'état du client NTP peut rester bloqué sur « INIT » pendant une à deux minutes durant lesquelles aucune requête est faite au serveur NTP. Ce comportement est troublant, mais il faut attendre.

    Contrairement à une machine UNIX équipée du démon ntpd de l'ISC qui interdit une correction de l'horloge quand l'écart avec le serveur de temps est trop important, un switch HP se synchronisera même s'il a des années de retard. On lit très souvent le contraire, mais c'est inexact.


    Vérifier

    Comme sur Comware 5.

    16/05/2020 18:12:34 - permalink -
    - http://shaarli.guiguishow.info/?ll2aIQ

  • Cisco ASDM : « Unable to launch device manager from vpn.mycompagny.example »

    On a un VPN Cisco ASA. On voudrait changer sa configuration depuis chez soi. On pourrait le faire en CLI (ligne de commande, via SSH), mais la création d'un compte utilisateur et l'association de règles de filtrage est pénible à comprendre. Pas envie de faire un effort pour un équipement en fin de vie. Comme d'habitude, utilisons ASDM (Adaptive Security Device Manager), une GUI (interface graphique) sous forme d'applet java.

    D'habitude, ça fonctionne, mais là, après la saisie de l'identifiant et du mot de passe, ça coince : Unable to launch device manager from vpn.mycompagny.example.

    Il n'est pas difficile de deviner qu'on se fait dégager par une règle de filtrage. Hé oui, contrairement à d'habitude, on est côté WAN, la joie du télétravail. Il est normal de réserver l'administration d'un équipement (réseau ou non) à des connexions internes. Établir le VPN avant de tenter une connexion changera rien : le trafic à destination du VPN n'est pas encapsulé dans le VPN, sinon ça ferait une boucle infinie. ;)

    On pourrait passer en CLI pour s'autoriser dans l'ACL appliquée sur l'interface WAN. Boarf. C'est un coup à oublier de la refermer. On aurait dû prévoir une interface réseau d'administration dédiée. Comme ça, une connexion à travers le VPN aurait fonctionné. Mais on ne l'a pas fait, on ne va pas revenir sur ça sur un équipement en fin de vie.

    Utilisons la fonctionnalité port forwarding de SSH ?

    En pratique :

    • Établir le VPN ;

    • sudo ssh -L443:<IP_du VPN>:443 <identifiant>@<nom_serveur_à_l'intérieur_du_réseau> ;

    • echo -e '\n127.0.0.1\tvpn.mycompagny.example' | sudo tee -a /etc/hosts ;

    • javaws "https://vpn.mycompagny.example/admin/public/asdm.jnlp".

    Après usage, ne pas oublier de nettoyer : sudo sed -i '/vpn.mycompagny.example/d' /etc/hosts.

    16/05/2020 17:03:52 - permalink -
    - http://shaarli.guiguishow.info/?oLV1uQ

  • Dessin : Framasoft et "le monde d'après"

    Blanquer : ‒ Franchement, ces services libres, gratuits et performants c'était fabuleux. On passera un contrat avec Microsoft en insistant pour qu'ils fassent aussi bien.

    Dessin de Flock, voir https://www.nextinpact.com/news/108965-flock-se-deconfine.htm .

    09/05/2020 14:50:59 - permalink -
    - https://cdn2.nextinpact.com/images/bd/news/175862.png

  • Socle Interministériel de Logiciels Libres - Liens en vrac de sebsauvage - GuiGui's Show - ~ sweet ~

    Ce qui me fait dire que c'est de l'intox, c'est que je le vois revenir avec l'argument du : "si ça se paye pas, ça tue le business". C'est tendancieux et généralement faux, non ?
    Malgré de bonnes solutions libres (et souvent gratuites), je ne vois pas de domaine ou le business ne peux plus jouer le game. Au contraire même peut-être. (c'est un ressenti j'ai pas fait d'étude de marché lol).

    Je ne discuterai pas des non arguments "pas sûr, pas pro", etc. : ils ont été démontés trouzemille fois.
    Considérer que libre = gratuit, c'est partir sur de mauvaises bases, de toute façon. J'essaye de financer mes logiciels libres, même si c'est souvent impossible pour les petits logiciels qui n'ont pas de mécanismes de collecte de fonds et pour les logiciels piliers / cachés (FreeBSD / PF pour PFSense, par exemple. Le fait de payer une prestation + licence PFSense ne fait pas automatiquement remonter du pognon à FreeBSD -> il faut demander / faire pression sur la société commerciale éditrice de PFSense pour qu'elle le fasse systématiquement). J'essaye que mon employeur en fasse autant : BIRD, Proxmox, OpenVPN, PFSense, Asterisk, etc. tu peux acheter du support ou des licences à la société commerciale éditrice. Donc, oui, le libre, ça rogne potentiellement des parts de marchés aux autres solutions, mais comme autre tout produit ou service, libre ou non, quoi, ça n'empêche pas le business. Ça vit de modèles économiques différents (don, vente de support / prestations intellectuelles, mutualisation par la demande, licences, fonctionnalités supplémentaires, etc.). Donc, là encore, ce n'est pas le sujet, et encore moins pour les salariés puisque l'argent ne sortira pas de leur poche.


    ça n'a pas tardé avant d'avoir des demandes auprès des managers... sans réponses. (alors qu'on nous casse les couilles toute l'année pour "se former"). Faut se former mais faut pas que ça coûte, surtout en temps, la ressource qui vaut plus cher que ton petit cul de travailleur. Bref, nos managers ne se mettent pas au niveau qu'il nous impose (comment les respecter à terme ?)...

    J'ai aussi entendu ça : "il faut se former afin de continuer à produire de la valeur qui sera captée par l'employeur, mais ça serait bien de ne pas s'absenter pour autant parce que sinon la société commerciale perd du fric". Tu le sens, le bel avenir des MOOC et autres formations continues à distance que tu pourras faire en dehors du temps de travail ? :))))


    Je rejoins le râlage de seb (ou de Framasoft, April, LQDN, ...) sur la priorité : que les pouvoirs publics ne soient pas sur ce registre affectif, certains fonctionnaires ont une responsabilité pour proposer de nouvelles solutions et ils doivent avoir les moyens en conséquences ! Le discours officiel est aussi une priorité : valoriser équitablement les solutions et LAISSER UNE MARGE aux utilisateurs.

    Personnellement, je préfère m'attaquer aux serveurs de la fonction publique et à leurs logiciels : il y a énormément plus de données personnelles et d'intelligence de ce côté-là que sur le PC de Ginette qui, soit se connecte aux logiciels distants, soit saisit des documents qui seront par nature publics (compte-rendu du Conseil d'Administration, acte de nomination, etc.). En situation de sous-effectif voulu (on dégrade le service en privant de ressources ceux qui le font tourner -> le citoyen râle -> on impose l'externalisation en expliquant que ça va résoudre tous les problèmes), ça me semble plus pertinent de prioriser cet aspect-là. Laisser une marge, ça consiste aussi à ne pas râler en permanence, à ne pas vouloir imposer le libre dans le public (ce qui était la position de l'April sur la loi pour une République numérique), et à accepter qu'un utilisateur te dise "je ne veux pas de ta merde, même si c'est dans le référentiel bidule du ministère machin".

    08/05/2020 13:30:47 - permalink -
    - https://dukeart.netlib.re/shaarli/?2W2i7Q

  • Socle Interministériel de Logiciels Libres - Liens en vrac de sebsauvage - GuiGui's Show - Ban's links

    Je vais faire mon libriste au melon démesuré, mais pour ce dernier point je pense que tu ne couvre pas l'ensemble du problème qui est aussi en grande partie que les "alternatives" libres ne sont pas le même logiciel, et ne s'uitlisent pas pareil. Au final la qualité de l'outil n'a que peu de rapport avec la question, la question est beaucoup que la personne est là pour faire son taf, pas pour prendre en main quelque chose de nouveau.

    C'est vrai, mais il y a une limite à ce raisonnement : pour qu'un gus prenne sur lui l'étude d'un autre logiciel (libre ou pas, ce n'est pas mon sujet), il faut que celui-ci soit techniquement ou qualitativement supérieur à la norme. Or, winwin versus nux ou MS Office versus LibreOffice, y'a pas de différence quand t'es une secrétaire. Les deux vont faire chier (si, nux peut faire chier), les deux permettent de saisir le courrier demandé par le boss, sur les fonctions de base, GIMP apporte rien par rapport à Photoshop (et inversement), etc. C'est juste une guéguerre de chapelles (genre en vrai winwin, quand t'as compris la logique, que tu t'es formé, que t'as les bons outils d'administration et les bonnes pratiques, ça juste fonctionne aussi bien que nux, faut arrêter de mentir). Donc quand tu vois l'ordi comme un simple outil pour faire le taff demandé afin de toucher ton salaire, t'en a rien à faire d'une alternative tant que ça t'apporte rien, que ça ne te simplifie pas la vie, que ça ne te permet pas d'aller plus vite (et même, si le boss s'en rend compte et qu'il te file plus de taff, t'as rien gagné, donc, parfois, faut pas chercher à optimiser son temps), etc. En gros, si je devais faire plus court : je ne blâme pas le salarié lambda, il a raison de ne pas se poser de questions, car, dans l'écrasante majorité des cas, ça lui apportera aucun avantage. C'est mon point de divergence avec toi.

    Tous les logiciels métiers n'existent pas en logiciels libres utilisables par le commun des mortels (tu ne fais pas de la comptabilité sérieuse ‒ = comptes à rendre ‒ à grande échelle ‒ = Grande Entreprise ‒ avec Ledger, GNUCash ou Odoo, par exemple) et inversement, y'a des domaines ou le libre remplace avantageusement la bouse privatrice (genre pour piloter certaines machines dans les laboratoires de recherche ou pour de l'enseignement très ciblé).

    Dans le cas que j'ai présenté, il me semble que cette personne a essayé GIMP (elle en donne l'impression en tout cas), d'où l'ampleur de sa réaction outrée "arrêtez de vouloir m'apprendre mon métier alors que vous avez jamais utilisé GIMP pour effectuer mon travail !" (ce qui est vrai). Du coup, j'en arrive à la conclusion qu'il y a plusieurs manières de faire une chose et que, si cette personne n'a pas accroché à GIMP, ça sert à rien de la forcer ni de râler ni de la former. C'est dommage et tout ce qu'on veut, mais elle a fait son choix.

    Et, dans les deux cas, on retombe sur les blocages formation et notoriété que j'énonce dans mon premier shaarli.

    08/05/2020 12:52:16 - permalink -
    - https://ban.netlib.re/shaarli/?jt3lEg
Links per page: 20 50 100
◄Older
page 90 / 302
Newer►
Mentions légales identiques à celles de mon blog | CC BY-SA 3.0

Shaarli - The personal, minimalist, super-fast, database free, bookmarking service by the Shaarli community