GuiGui's Show

Depuis sa version 78, Thunderbird intègre nativement la prise en charge d'OpenPGP. Il utilise la bibliothèque de fonctions RNP, plus des appels à GnuPG (par exemple) comme le faisait l'extension Enigmail. Ainsi, Thunderbird importe la clé OpenPGP en en faisant une copie et en protégeant sa phrase de passe avec une chaîne de caractères générée automatiquement et stockée en clair dans le profil Thunderbird de l'utilisateur. Pour protéger la phrase de passe OpenPGP, il faut définir un mot de passe principal pour le gestionnaire de mots de passe interne.

Notons que, puisque la clé OpenPGP est copiée dans Thunderbird, il n'y a pas de synchronisation automatique entre Thunderbird et GnuPG. Un changement de date d'expiration, accorder sa confiance à une clé, signer une clé, importer une signature de sa clé, etc., toutes ces actions restent cantonnées à l'un ou à l'autre des logiciels.

Comme le note un observateur, la protection par un mot de passe principal n'offre pas les mêmes garanties qu'une utilisation d'Enigmail.
Sans agent GnuPG, Enigmail demandait la phrase de passe à chaque email à déchiffrer / signer. Avec un agent GnuPG, la phrase de passe restait quelques temps en RAM (sans protection) et les emails étaient lisibles sans protection durant cet intervalle.
Avec Thunderbird 78 (et suivants), si l'on ne défini pas de mot de passe principal, les emails sont lisibles en permanence. Si l'on en défini un, il est demandé à l'ouverture de Thunderbird et il est stocké en RAM jusqu'à ce que Thunderbird soit fermé, donc les emails sont lisibles dans cet intervalle, qui est plus long que ce qu'il était avec l'agent GnuPG.
À ce jour, Thunderbird ne permet pas de configurer un délai maximal de conservation du mot de passe principal en RAM.

On notera que la bibliothèque RNP comportait un bug qui lui faisait importer une clé sans la protéger, même si un mot de passe principal existait.

ÉDIT DU 24/09/2022 : j'avais écrit qu'il est possible de configurer Thunderbird pour utiliser GnuPG afin de pallier les déconvenues sus-exposées. Or, la doc' officielle que je pointais expose précisément qu'en ce faisant, GnuPG serait alors utilisé exclusivement pour les opérations de déchiffrement et de signature, et que l'implémentation interne continuerait d'être utilisée pour les opérations de chiffrement et de vérification d'une signature. Donc, il faut quand même synchroniser les trousseaux Thunderbird et GnuPG (Thunderbird a besoin de ta clé publique pour déchiffrer la copie des emails envoyés), surtout si tu utilises ta paire de clés OpenPGP pour d'autres usages que l'email avec Thunderbird (besoin des clés publiques de tes correspondants des deux côtés). En revanche, en utilisant GnuPG, ta clé privée sera alors protégée par celui-ci (et éventuellement son agent) plutôt que par Thunderbird, ce qui contrecarre bien deux des trois points énoncés ci-dessus. FIN DE L'ÉDIT.

GameShell = petit jeu GNU/Linux/BSD/MacOS en ligne de commande pour initier à quelques commandes Unix de base (cd, ls, rm, chmod, head, tail, find, grep, ps, kill, alias, cal, tr, nano, less, etc.) à travers 42 missions dans (et autour) d'un château (nettoyer le château, découvrir ses trésors, dérober la couronne, affronter un être maléfique, décrypter des messages, etc.). Codé par un prof de l'univ' Savoie Mont Blanc.

J'ai effectué les 42 missions. Je recommande. :)

Ici, nous utilisons snoopy. Packagé dans Debian GNU/Linux.

Avantages : un nom cool + pas besoin de ré-inventer la roue + contrairement à la méthode Octopuce, snoopy fonctionne en présence d'un hook preexec pour bash dont je me sers pour peupler mon agent SSH.
Inconvénient : par défaut, snoopy journalise également les actions d'origine non humaine (CRON, démon, tâche de fond, etc.), mais y'a moyen de définir des filtres dans sa configuration.

On peut aussi parvenir au même but avec psacct et acct.

bind() un service réseau sur une adresse IP que l'on n'a pas (dans une configuration "reprise sur panne" avec keepalived, par exemple) sans écouter sur toutes les adresses et les interfaces (avec « :: » et « 0.0.0.0 ») ?
Les paramètres de Linux « net.ipvX.ip_nonlocal_bind » sont là pour ça.

Je découvre le multipath ISCSI qui permet de redonder l'accès à un espace de stockage exporté au format bloc avec le protocole réseau ISCSI. Ainsi, il est possible d'avoir deux chemins réseaux totalement distincts (câbles différents, routage différent, etc.) ou même deux têtes logicielles sur un même NAS utilisées simultanément (c'est d'ailleurs le support Dell qui nous a obligé à mettre en place le multipath ISCSI avant la mise à jour logicielle de notre NAS Unity XT).

Avec Debian GNU/Linux 10, on installe le paquet logiciel multipath-tools (device-mapper multipath), un p'tit fichier /etc/multipath/multipath.conf, on découvre/login avec iscsiadm (comme d'hab) puis on monte /dev/mapper/mpathX-partY au lieu de /dev/sdX.

Merci Alex de m'avoir appris cela (et de l'avoir mis en place).

Nous avons plusieurs centaines de machines Ubuntu 20.04 qui ne sont pas attribuées à un utilisateur précis.

Nous voulons éteindre automatiquement ces machines après une période d'inactivité.

Critères :

• Je parle d'inactivité "tout court", pas inactivité sur batterie ;
  
  
• Logiciel sans interface graphique doté d'un fichier de configuration (que l'on peut donc modifier avec Puppet).

sleepd

sleepd est packagé dans Debian GNU/Linux, mais il ne l'est plus dans Ubuntu après la version 14.04.

Le paquet Debian fonctionne très bien sur Ubuntu :

• apt download sleepd depuis une machine Debian ;
  
  
• apt install libx86-1 pm-utils vbetool sur une machine Ubuntu afin d'installer les dépendances ;
  
  
• dpkg -i sleepd_2.10_amd64.deb ;
  
  
• Ajouter les options que l'on veut dans /etc/default/sleepd : « -u » pour le délai avant action ; « -s /sbin/poweroff » pour éteindre la machine au lieu de la mettre en veille ; « -w » pour comptabiliser également l'activité sur d'éventuelles sessions SSH ;
  
  
• systemctl restart sleepd.

Alternatives

autopoweroff. Trop complet pour notre usage (il peut vérifier la consommation CPU et la joignabiltié de machines dont celle-ci dépend avant d'exécuter une action) donc fichier de configuration plus touffu.

CRON. Au début, je voulais écrire une tâche planifiée qui aurait tourné toutes les heures non-ouvrées et qui aurait utilisé la commande w pour déterminer si des utilisateurs ont eu une activité récente avant d'éteindre. Deux inconvénients : 1) pourquoi réinventer la roue ? ; 2) si l'on veut désactiver l'arrêt automatique lors d'une maintenance, il faut commenter le contenu d'un fichier, ce qui est moins pratique que systemctl stop sleepd.

On peine à supprimer récursivement (rm -r) plusieurs arborescences plus ou moins touffues sur un partage NFS version 3. Idem pour copier récursivement (cp -a) des arborescences. La suppression ou la copie s'arrête sur un fichier, jamais le même puisque plusieurs arborescences. Peu importe sa taille, ancienneté, etc., a priori. Impossible dès lors d'utiliser le point de montage (depuis la machine qui supprime / copie, bien entendu, pas depuis toute machine qui monte le partage). Le problème se produit quasiment chaque jour.

Solution : monter le partage NFS en retirant les options rsize=32768,wsize=32768 et laisser agir la négociation automatique.

Explication ? Aucune idée.

On notera qu'autofs est d'aucune utilité dans ce genre de blocage NFS.

Plus de détails sur le contexte ? OK.

On utilisait ces options (et ces valeurs) avec nos anciens NAS (marques : NetApp et Nexenta). On ne les utilise plus sur notre NAS actuel (Dell EMC Unity) même si elles fonctionnaient durant nos tests.

Une machine physique Debian 7 montait un volume en ISCSI depuis notre ancien NAS Nexenta et elle l'exportait en CIFS (parce que le CIFS de notre NAS Nexenta ne fonctionnait pas, probablement car nous n'avions pas de contrôleur de domaine winwin ni Samba AD DC) et en NFSv3 vers une machine virtuelle d'administration du contenu du volume disque (l'usage d'ISCSI, qui exporte au niveau bloc, empêche, par nature, de monter le volume en NFS depuis le NAS). Cette VM d'administration montait le partage avec les options rsize et wsize sus-exposées. Aucun problème durant plus de 5 ans.

Nous avons cloné + virtualisé la machine physique Debian 7. Elle monte le même volume ISCSI, mais elle le monte depuis notre nouveau NAS Dell EMC, et elle l'exporte en CIFS (le temps de migrer nos utilisateurs, l'alias DNS avec lequel sont configurées les machines de nos utilisateurs ne pouvant être repris par notre nouveau NAS car la négociation SMB échoue car le client Kerberos du NAS refuse l'incohérence entre l'alias et le nom réel du service SMB, et l'ancien nom réel n'a plus de sens avec l'arrivée du nouveau NAS donc nous voulions pas le conserver) et en NFS à la même machine d'administration. Dès lors, cette machine d'administration a rencontré le problème sus-exposé. Le retrait des options entraîne une négociation automatique rsize=1048576,wsize=1048576 d'après cat /proc/mounts, soit bien plus que ce qu'on paramétrait à la main.

Deux changements entre avant et après : virtualisation de l'exportateur NFS et changement de l'initiateur ISCSI (de NAS, quoi). La logique impose de suspecter plutôt le deuxième. D'autant que nous n'utilisons plus rsize/wsize pour monter du NFS directement depuis notre nouveau NAS. On peut supposer qu'un enchaînement rsize/wsize fixées à 32 k + ISCSI ne convient pas à notre NAS Dell Unity.

Depuis quelques mois, nous avons un serveur coturn installé depuis les dépôts Debian GNU/Linux. Implémentation de TURN, l'un des nombreux palliatifs pour tenter de faire fonctionner des logiciels multimédias pair-à-pair avec du NAT au milieu.

Ce service se vautre plusieurs fois par semaine. Évidemment, rien dans son journal. Sauf aujourd'hui : segfault. Mes recherches sur le web retournent rien (ou des paths vieux de 5-7 ans, qui ont donc été intégré depuis, en ce qui concerne l'erreur de segmentation). On pourrait lancer coturn en mode ultra-verbeux (« -V »), sortir gdb (pour la segfault), etc. Mais en attendant ?

Pour ces cas-là, systemd propose Restart=on-failure, c'est-à-dire redémarrer un service à chaque fois qu'il crashe.

J'utilise ça dans des units systemd depuis plus de 5 ans. Mais, dans Debian, coturn est livré avec un script sysv qui utilise start-stop-daemon. Est-ce que ça fonctionne ? Oui.

Utiliser la commande systemctl edit coturn.service.

Saisir :

[Service]
RemainAfterExit=no
Restart=on-failure
RestartSec=10s

Enregistrer.

Désormais, systemctl status coturn affiche deux lignes supplémentaires : « Drop-In: /etc/systemd/system/coturn.service.d / override.conf ».

« RemainAfterExit » est nécessaire, sinon systemd ne fait pas le job.

« RestartSec » n'est pas nécessaire mais laisse un peu de répit à coturn pour démarrer et éviter une boucle de redémarrage (systemd essaye de faire redémarrer un service en boucle, jusqu'à une limite pré-définie et surchargeable, après quoi il laisse le service HS, ce que je ne veux pas).

Si l'on veut tester, on remplace « on-failure » par « always » puis killall coturn.

Nous avons un serveur avec plusieurs instances de MariaDB. Une instance = un processus, un port TCP, un fichier de configuration dédié, etc.

Sur ce serveur, si l'on tape la commande mysql -P <numéro_port_instance> -u <user> -p <nom_bdd>, MariaDB nous retourne l'erreur « ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory" ».

Si l'instance par défaut (celle qui écoute sur tcp/3306 / /var/run/mysqld/mysqld.sock) est toujours active, l'erreur est, en toute logique, « ERROR 1045 (28000): Access denied for user `'@'localhost' (using password: YES) », car on tente de se connecter à l'instance par défaut.

Le paramètre « -P », qui permet de préciser le port TCP à utiliser, ne se suffit pas à lui-même : il faut ajouter --protocol=tcp.

Ou utiliser la socket UNIX de l'instance à laquelle on veut accéder avec -S /var/run/mysqld/<socket>.

Après avoir voulu me remémorer comment fonctionne une capture réseau du point de vue du noyau Linux, je me suis interrogé sur l'activation, en détail, du mode promiscuous.

Définition

Une carte réseau Ethernet fait remonter au système d'exploitation uniquement les trames Ethernet qui lui sont destinées. Le tri est opéré sur l'adresse MAC de destination. Sont conservés les paquets dont l'adresse MAC est celle de la carte réseau, l'adresse broadcast (FF:FF:FF:FF:FF:FF), ou l'une des adresses multicast (01:00:5E:XX:XX:XX pour IPv4, 33:33:XX:XX:XX:XX pour IPv6).

Ce filtrage est effectué matériellement par la carte réseau.

Le mode promiscuous permet de retirer ce filtrage, donc d'écouter tout ce qui passe sur le réseau.

Bon, il faut relativiser :

• À l'époque des réseaux équipés avec des hubs ou avec une topologie en bus, on recevait tout le trafic réseau de toutes les machines du réseau.
  
  
• Sur les réseaux d'aujourd'hui, équipés avec des switchs, on reçoit uniquement le trafic destiné à la machine, broadcast, multicast ou autre (01:80:C2:XX:XX:FF pour LLDP / STP / IEEE1905, etc.). Le seul moment où un switch fait fuiter du trafic unicast, c'est quand il ne connaît pas l'association entre une adresse MAC et un port ou quand sa table de correspondance est pleine.

Pratique

Le mode promiscuous est global à une interface réseau : exécuter un tcpdump -p (on demande à ne pas activer le mode promiscuous) à côté d'un tcpdump (mode promiscuous activé) est vain : quel que soit l'ordre de lancement des commandes, le tcpdump -p verra les paquets qui ne sont pas destinés à la machine tant que le tcpdump (promiscuous) est en cours d'exécution.

Voir si l'une des interfaces réseau du système est en mode promiscuous : ip -d l sh | grep -B 1 promiscuity. Si le nombre affiché est supérieur à 1, alors plusieurs applications (+ le noyau voir ligne suivante) ont activé le mode promiscuous.

Activer le mode promiscuous sans passer par libpcap : sudo ip l set promisc on dev <INTERFACE>. Pour le désactiver : sudo ip l set promisc off dev <INTERFACE>.

Promiscuous ne voit pas tout

Le mode promiscuous ne permet pas de voir TOUT le trafic réseau adressé à la machine. Une carte réseau peut filtrer matériellement le trafic qu'elle juge invalide : toute trame 802.1Q quand aucun VLAN est configuré sur le système, trames réseaux trop courtes ou dont la somme de contrôle est incorrecte, etc.

Linux filtre aussi

Tous les paquets qui arrivent sur une interface configurée en mode promiscuous ne parviendront pas jusqu'aux logiciels "serveurs" en écoute, car le noyau fait le tri.

Le tri le plus simple à mettre en évidence est que, si le transfert de paquets IP n'est pas activé (/proc/sys/net/ipv4/ip_forward = 0), alors tous les paquets IP dont l'adresse IP de destination n'est pas l'une des IPs de la machine (multicast inclus) seront détruits. Ils n'arriveront même pas jusqu'à la chaîne FORWARD de Netfilter/iptables. Il doit exister d'autres filtrages.

Et donc, comment le mode promiscuous est activé par la libpcap ?

Si l'on regarde le code, la libpcap (utilisée par tcpdump, wireshark, etc.) utilise la fonction système setsockopt() pour positionner l'option. Il ne reste plus qu'à remonter le code de Linux.

• setsockopt() est une fonction implémentée pour chaque famille/protocole. Une socket libpcap est de type AF_PACKET / PF_PACKET, donc c'est la fonction packet_setsockopt() située dans le fichier net/packet/af_packet.c qui est utilisée. Elle appelle packet_mc_add() qui appelle packet_dev_mc(), toujours dans af_packet.c.
  • dev_set_promiscuity() dans net/core/dev.c est appelée et elle appelle __dev_set_promiscuity() toujours dans net/core/dev.c. On notera que c'est cette fonction qui journalise « device XXXX entered promiscuous mode » dans kern.log.
    • __dev_set_promiscuity() appelle dev_change_rx_flags() (toujours dans net/core/dev.c) qui appelle ndo_change_rx_flags. Le pilote peut implémenter une fonction (ou non) pour remplacer celle par défaut et l'enregistrer dans la structure netdev_ops de la structure net_device. Exemple : le pilote e1000e n'implémente pas cette fonction.
      
      
    • __dev_set_promiscuity() appelle dev_set_rx_mode() (toujours dans net/core/dev.c) qui appelle ndo_set_rx_mode(). Le pilote e1000e la remplace avec e1000e_set_rx_mode() (« .ndo_set_rx_mode = e1000e_set_rx_mode, ») dont le commentaire indique « e1000e_set_rx_mode - secondary unicast, Multicast and Promiscuous mode ». Cette fonction met à jour les registres de la carte réseau et, surtout, restaure+écrit les adresses multicast et unicast quand on sort du mode promiscuous.