GuiGui's Show

Comme à chaque passage à une nouvelle version de Debian GNU/Linux, voici un résumé de tout ce qui a foiré ou changé quand je suis passé à Buster.

Résumé des points qui peuvent poser problème (triés par niveau de risque) : suites cryptographiques faibles (RSA / DHE < 2048 bits, ECDSA / ECDHE < 224 bits) non prises en charge par défaut par OpenSSL (débrayable) + TLS 1.2 par défaut avec OpenSSL (débrayable), fin de la prise en charge des certificats x509 utilisant SHA-1 par OpenSSL (débrayable) et GnuTLS (non négociable), AppArmor activé par défaut, et traduction auto iptables->nftables.

Arborescence

/bin, /lib et /sbin n'existent plus. Il reste /usr/{bin,lib,sbin}.

Sur un système fraîchement installé, /bin, /lib et /sbin sont des liens symboliques. Sur un système mis à jour, rien change, sauf si l'on installe et utilise le paquet usrmerge.

Attention donc aux scripts qui contiennent des chemins absolus vers des binaires : il n'y aura pas toujours un lien symbolique sur /bin, /lib et /sbin.

Apache HTTPd + GnuTLS

Après la mise à jour, Apache HTTPd ne démarre plus. sudo journalctl -x -u apache2 affiche :

apachectl[6296]: AH00526: Syntax error on line 6 of /etc/apache2/mods-enabled/gnutls.conf:
apachectl[6296]: Could not find socache provider 'dbm', please make sure that the provider name is valid and the appropriate module is loaded (maybe mod_socache_dbm.so?).

GnuTLS active par défaut le cache partagé des sessions TLS. Il est stocké dans le backend DBM. Soit on désactive ce cache, soit on change de backend, soit, meilleure solution, on active le module correspondant avec a2enmod socache_dbm && systemctl restart apache2.

AppArmor

Généralités

AppArmor est installé et activé par défaut, sauf si apt est configuré pour ne pas installer les paquets recommandés (car AppArmor est une recommandation du noyau, pas une dépendance).

Je n'avais pas compris un truc : pour l'instant, l'utilisation d'AppArmor par chaque logiciel est basé sur le volontariat. Si un logiciel n'a pas de profil AppArmor, alors il n'est pas embêté. Actuellement, les profils sont fournis par les paquets apparmor, apparmor-profiles, apparmor-profiles-extra, par les logiciels volontaires (exemples : bind9, ntpd, haveged, tcpdump) et par les logiciels qui ne veulent pas se faire embêter (exemple : MariaDB livre un profil vide afin de désactiver AppArmor).

Pour voir les profils chargés et les processus contraints à un instant T, il y a la commande aa-status.

Problème avec BIND9

Sur mes systèmes, le seul logiciel qui a été contraint à tort par AppArmor est bind9. Dans son journal, je lisais :

named[551]: could not configure root hints from '/var/named/zones/defaultdb/db.root': permission denied
named[551]: loading configuration: permission denied
named[551]: general: error: dumping master file: /var/named/zones/slave/tmp-DwqA5s4Tm6: open: permission denied

C'est normal : le profil livré avec BIND9 (/etc/apparmor.d/usr.sbin.named) ne prévoit pas l'utilisation de /var/named. Or, je mets la configuration du serveur dans /etc/bind et le contenu servi par le serveur dans /var/named, car ce contenu est normalisé (il est le même quel que soit le serveur DNS utilisé BIND9, NSD, PowerDNS, etc.). Comme on met le contenu servi par un serveur web dans /var/wwwet la configuration de ce serveur web dans /etc/apache2 ou /etc/nginx.

Pour débloquer la situation, on crée un profil local qui surchargera le profil par défaut. Il se nomme /etc/apparmor.d/local/usr.sbin.named et son contenu est le suivant :

# Site-specific additions and overrides for usr.sbin.named.
# For more details, please see /etc/apparmor.d/local/README.
/var/named/** r,
/var/named/zones/slave/* rw,

Il ne reste plus qu'à recharger la conf' d'AppArmor et à redémarrer BIND9 : systemctl reload apparmor.service && systemctl restart bind9.

Journalisation

Je déteste que tout soit consigné dans /var/log/syslog. J'aime bien avoir un journal pour chaque logiciel. Or, AppArmor tombe dans /var/log/syslog.

Pour remédier à ça, je crée un fichier /etc/rsyslog.d/apparmor.conf qui contient :

if $msg contains 'apparmor' then /var/log/apparmor.log
& stop

Je redémarre rsyslog : systemctl restart rsyslog (un reload ne suffit pas, de mémoire).

Pour l'archivage, je crée un fichier /etc/logrotate.d/apparmor contenant :

/var/log/apparmor.log
{
        monthly
        missingok
        rotate 12
        compress
        delaycompress
        notifempty
        create 640 root adm
        sharedscripts
        olddir /var/log/archives/systeme
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}

apt

• apt vérifie désormais que la date des fichiers d'un dépôt n'est pas dans le futur. Une option de configuration permet de revenir au comportement antérieur ;
  
  
• L'utilisation de dépôts non-authentifiés (absence de la clé OpenPGP, par exemple) émet désormais une erreur (qu'il faut contourner avec une option de configuration), plus un avertissement ;
  
  
• apt prend en charge nativement https. Plus besoin du paquet apt-transport-https qui contient désormais uniquement de la doc' ;
  
  
• La prise en charge des dépôts FTP est désactivée par défaut. Debian compte éteindre ses dépôts FTP… depuis novembre 2017. Une option de configuration permet d'activer la prise en charge de FTP par apt. En ce qui me concerne, je suis passé, à regret (le "tout sur HTTP" me pose un problème éthique, car ça rend le développement de nouveaux protocoles très compliqués en fermant le jeu), à HTTP.

deluged / deluge

Au démarrage de l'interface deluge-gtk, on doit démarrer le démon deluged puis s'y connecter. Or, là, il ne veut plus démarrer. Aucun message d'erreur.

On le lance en ligne de commande :

$ deluged
[…]
[ERROR   ] 00:41:33 rpcserver:378 [('SSL routines', 'SSL_CTX_use_certificate', 'ee key too small')]

Il existe un rapport de bug. La clé pour communiquer avec deluged ne respecte pas les critères de robustesse appliqués par défaut par OpenSSL dans Buster (voir ci-dessous).

Solution ? rm ~/.config/deluge/ssl/*. Une nouvelle clé sera générée et l'on pourra lancer deluged comme avant.

Dovecot

• Dovecot ne génère plus lui-même ses paramètres Diffie-Hellman. La directive de configuration ssl_dh_parameters_length est invalide. Il faut désormais générer nous-même nos DH avec openssl dhparam et les fournir à Dovecot. Exemple : ssl_dh = </etc/dovecot/ssl/dh_4096.pem.
  
  
• ssl_protocols est remplacé par ssl_min_protocol. Exemple : ssl_protocols = !SSLv3 devient ssl_min_protocol = TLSv1.
  
  
• La compression TLS est désactivée par défaut (ssl_options = no_compression), ce qui est une bonne chose vu les attaques que la compression rend possibles (CRIME).

dnssec-trigger

J'utilise ce logiciel depuis huit ans. Jamais un souci, rien. Mais après le passage à Buster, il refuse de démarrer :

dnssec-triggerd[1155]: [1581725206] unbound-control[31667:0] warning: control-enable is 'no' in the config file.
dnssec-triggerd[1155]: [1581725206] unbound-control[31667:0] error: connect: Connection refused for 127.0.0.1 port 8953
[…]
dnssec-triggerd[10688]: error: Error setting up SSL_CTX client cert
dnssec-triggerd[10688]: 140194432980928:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small:../ssl/ssl_rsa.c:310:
dnssec-triggerd[10688]: [10688] warning: unbound-control exited with status 256, cmd: /usr/sbin/unbound-control forward 80.67.169.40 80.67.169.12
dnssec-triggerd[10688]: Traceback (most recent call last):
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 774, in <module>
dnssec-triggerd[10688]:     main()
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 761, in main
dnssec-triggerd[10688]:     Application(sys.argv).run()
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 472, in run
dnssec-triggerd[10688]:     self.method()
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 556, in run_setup
dnssec-triggerd[10688]:     self._unbound_set_negative_cache_ttl(UNBOUND_MAX_NEG_CACHE_TTL)
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 641, in _unbound_set_negative_cache_ttl
dnssec-triggerd[10688]:     subprocess.check_call(CMD, stdout=DEVNULL, stderr=DEVNULL)
dnssec-triggerd[10688]:   File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
dnssec-triggerd[10688]:     raise CalledProcessError(retcode, cmd)
dnssec-triggerd[10688]: subprocess.CalledProcessError: Command '['unbound-control', 'set_option', 'cache-max-negative-ttl:', '5']' returned non-zero exit

On trouve deux rapports de bug : #898969 et #919256. La clé pour communiquer avec Unbound ne respecte pas les critères de robustesse appliqués par défaut par OpenSSL dans Buster (voir ci-dessous).

Je ne suis pas parvenu à résoudre ce problème en supprimant les clés actuelles et en en générant de nouvelles, du coup, j'ai bourriné :

• killall dnssec-trigger-panel ;
  
  
• sudo apt-get autoremove --purge dnssec-trigger unbound unbound-anchor ;
  
  
• sudo find / -iname '*dnssec-trigger*' + supprimer ce qui est pertinent, notamment /etc/dnssec-trigger et /etc/NetworkManager/dispatcher.d/01-dnssec-trigger-hook ;
  
  
• sudo apt-get install dnssec-trigger ;
  
  
• sudo dnssec-trigger-control-setup -i ;
  
  
• sudo systemctl restart unbound dnssec-triggerd

EasyRSA / OpenVPN

Plusieurs options de configuration ont été supprimées dans la version 2.4 d'OpenVPN (présente dans Debian depuis Stretch) comme tun-ipv6 et tls-remote. Ce n'est pas bloquant : OpenVPN émet un avertissement et utilise l'option de remplacement.

D'autres options seront supprimées dans OpenVPN 2.5. ns-cert-type, par exemple. Ce ne sera pas bloquant : OpenVPN émettra un avertissement et utilisera l'option de remplacement. Il n'est déjà plus possible d'émettre des certificats x509 comportant cet attribut avec EasyRSA.

ejabberd

Comme à chaque mise à jour majeure de Debian, la configuration d'ejabberd change pas mal : des modules qui n'existent plus / sont dépréciés, des directives de configuration qui n'existent plus, etc. :

[warning] <0.81.0>@ejabberd_config:emit_deprecation_warning:1436 Module mod_http_bind is deprecated, use mod_bosh instead
[warning] <0.81.0>@ejabberd_pkix:opt_type:131 Option 's2s_certfile' is deprecated, use 'certfiles' instead
[warning] <0.81.0>@ejabberd_c2s:listen_opt_type:984 Listening option 'certfile' for ejabberd_c2s is deprecated, use 'certfiles' global option 

La nouvelle version empaquetée de la configuration apporte également des macros qui permettent de configurer TLS pour les échanges entre serveurs et pour les échanges avec un client (certfiles, DH_FILE, TLS_CIPHERS, TLS_OPTIONS, etc.). C'est très pratique puisque ça factorise la conf'.

Vu que je modifie peu la configuration livrée (réduction d'un cran de la verbosité du journal (4 -> 3), domaine, certificat x509, paramètres DH, suites de chiffrement TLS, pas d'auth interne, et activation du module Message Archive Management), j'ai sauvegardé mon ancienne conf', j'ai pris celle livrée par le paquet et je l'ai modifiée.

ÉDIT DU 21/06/2020 à 19 H 30 : 1) Vu qu'on remet la configuration à zéro, il faut bien penser à désactiver, à nouveau, l'interface web en commentant le port 5280 dans la section « listen ». Par défaut, ejabberd écoute le monde entier… Si l'on veut conserver l'interface web, on peut changer la ligne « ip » de ce module afin qu'il écoute uniquement en local. 2) Ça ne date pas de Buster, mais epmd, un composant erlang dont dépend ejabberd, écoute le monde entier sur le port tcp/4369. Ça sert à agréger plusieurs serveurs et à piloter le serveur avec ejabberd. J'ai écrit un article pour configurer epmd afin qu'il écoute uniquement en local car cela se fait du côté de systemd, pas (plus ?) depuis la configuration d'ejabberd, contrairement à ce que prétend la doc' d'ejabberd. FIN DE L'ÉDIT DU 21/06/2020 à 19 H 30.

Firefox / Thunderbird

(Ce point a aucun rapport avec Debian Buster, mais Buster est l'ocassion de faire un rappel.)

DNS over HTTP (DOH) est en cours de généralisation. Il y a de bonnes raisons de ne pas vouloir utiliser DoH Pour le désactiver dans Firefox et dans Thunderbird (qui partage une grande partie de son code avec Firefox), on affecte la valeur « 5 » à la clé de configuration « network.trr.mode » dans « about:config » (ou menu « Édition » -> « Préférences » -> « Avancé » -> « Éditeur de configuration », pour Thunderbird). On peut aussi configurer cela plus finement comme l'expose l'article pointé.

GnuPG

Suite à l'attaque de 2019 contre les serveurs de clés consistant à saturer une clé de signatures, le projet GnuPG a choisi d'appliquer par défaut la politique "recevoir uniquement ses propres signatures depuis les serveurs de clés". Debian suit ce changement.

Je trouve que c'est une idiotie. Lire cet avis.

GnuTLS

On passe de la version 3.5.X à la version 3.6.X. Le principal changement est que SHA-1 n'est plus un algorithme de hachage convenable quand il est utilisé dans le cadre d'une signature de certificat, donc sa prise en charge dans ce contexte a été anihilée à la compilation. Les outils de manipulation LDAP (ldap-utils), qui utilisent GnuTLS, foireront sur un certificat SHA-1, par exemple.

hash-slinger

hash-slinger n'est pas empaqueté dans Buster à cause d'une dépendance à python3-m2crypto non satisfaite.

La version de hash-slinger qui utilise python2 que t'as pu installer avant de mettre à jour ton système pourrait ne pas fonctionner dans certains cas à cause de l'obsolescence de la bibliothèque TLS. Exemple :

tlsa --verify --port 25  <serveur>
Traceback (most recent call last):
  File "/usr/bin/tlsa", line 774, in <module>
    sslStartTLSConnect(connection, (str(address), int(args.port)), args.starttls)
  File "/usr/bin/tlsa", line 251, in sslStartTLSConnect
    ret = connection.connect_ssl()
  File "/usr/lib/python2.7/dist-packages/M2Crypto/SSL/Connection.py", line 293, in connect_ssl
    return m2.ssl_connect(self.ssl, self._timeout)
M2Crypto.SSL.SSLError: wrong version number

On remarque la présence d'autres bugs. Exemple :

$ tlsa --create --usage 3 --selector 0 --mtype 1 --certificate mycertfile.pem <nom_machine>
Could not verify local certificate: no start line (Expecting: CERTIFICATE).
Traceback (most recent call last):
  File "/usr/bin/tlsa", line 889, in <module>
    genRecords(args.host, args.protocol, args.port, chain, args.output, args.usage, args.selector, args.mtype)
NameError: name 'chain' is not defined

Heu ? Osef de la chaîne de certificats, on veut un usage 3 (mettre dans le DNS le seul certificat du serveur). Si l'on regarde le code :

chain = connection.get_peer_cert_chain()
genRecords(args.host, args.protocol, args.port, chain, args.output, args.usage, args.selector, args.mtype)

Heu ? Osef de récupérer le certificat auprès du pair c'est-à-dire du serveur puisqu'on le passe en paramètre (--certificate mycertfile.pem). C'est un bug connu.

Mieux vaut utiliser la version du dépôt git officiel du projet. Néanmoins, elle utilise la version 3 de Python. Donc il faut installer le module M2Crypto (sinon on aura l'erreur ModuleNotFoundError: No module named 'M2Crypto').

La compilation du module M2Crypto nécessite swig, donc on l'installe : sudo apt-get install swig.

On installe le module M2Crypto pour Python 3 : sudo pip3 install m2crypto.

On récupère hash-slinger : git clone https://github.com/letoams/hash-slinger.

On l'installe : cd hash-slinger && sudo make install.

ifupdown

• Une interface VLAN marquée « allow-hotplug » monte en même temps que l'interface physique parente quand celle-ci est branchée ;
  
  
• Le traitement des interfaces est désormais parallélisé. Attention aux scripts pre-up, post-up, etc.
  
  
• On peut désormais appliquer une regex minimaliste sur le nom / l'adresse MAC / le type d'une interface (exemple : « /eth* ») et lui donner un surnom qu'on peut réutiliser par la suite (exemple : « /eth*/=foo »).

iptables / ebtables / arptables

iptables (iptables-nft de son vrai nom), ebtables (ebtables-nft) et arptables (arptables-nft) utilisent désormais le sous-système noyau nf_tables au lieu de xtables. Le but est de préparer la migration d'iptables (et co) vers nftables qui aura prétendument lieu dans la prochaine version stable de Debian (je n'y crois pas : la commande ip (remplaçante de ifconfig, route, vlan et d'autres) et la commande ss (remplaçante de netstat) ont plus de 10 ans, comme nftables, et il ne s'est rien passé malgré les menaces de déprécier ifconfig et compagnie).

La syntaxe des règles iptables ne changedonc pas, grâce à iptables-nft (et compagnie) qui effectue la conversion en douce, mais il faudrait migrer vers nftables.

Si l'on veut migrer, iptables-translate et iptables-restore-translate permettent de traduire les règles existantes. iptables-translate pour traduire une règle, iptables-restore-translate pour traduire un fichier de règles (obtenu avec iptables-save, par exemple). Attention : il n'y pas de contrôle de la syntaxe sur les éléments variants (nom d'une interface, nom d'une chaîne, nom d'une cible, etc.). Exemple :

$ sudo iptables-translate -t nat -A POSTROUTINGE -o tun0 -j TOTO
nft add rule ip nat POSTROUTINGE oifname "tun0" counter jump TOTO

On notera également que certaines traductions ne sont pas proposées (je donne la traduction de cet exemple plus bas) :

$ sudo iptables-translate -P FORWARD ACCEPT
Translation not implemented
nft 

Voici ma procédure pour migrer d'iptables vers nftables à partir d'un système équipé de netfilter-persistent :

sudo iptables-restore-translate -f /etc/iptables/rules.v4 > /tmp/nftables.conf.tmp
sudo ip6tables-restore-translate -f /etc/iptables/rules.v6 >> /tmp/nftables.conf.tmp

# Un script nftables commence par « #!/usr/sbin/nft -f »
sed -i '1s&^&#!/usr/sbin/nft -f\n&' /tmp/nftables.conf.tmp

# iptables-restore-translate crée les tables nat et mangle alors que je ne les utilise pas ou rarement.
# Je les vire afin d'améliorer la visibilité 
sed -i '/ip nat/d' /tmp/nftables.conf.tmp
sed -i '/ip mangle/d' /tmp/nftables.conf.tmp

# Vu que je vais temporairement être sans pare-feu (surtout s'il y a des règles cassées), je me déconnecte du réseau
sudo ifdown eth0

# Je vire toutes les règles (filtrage, NAT, etc.) IPv4 et IPv6 actuellement en place
sudo nft flush ruleset

# J'importe les règles au format nftables avec l'outil d'administration adéquat
sudo nft -f /tmp/nftables.conf.tmp

# Je vérifie que les règles sont en place
sudo nft list ruleset

# Puisque tout est OK, je me connecte au réseau
sudo ifup eth0

# Puisque tout est OK, je crée le fichier de configuration utilisé par l'unit systemd pour charger les règles
# -s permet de ne pas inclure les compteurs (de paquets / octets) dans l'export
# Oui, le format issu de la commande ip[6]tables-restore-translate aurait fonctionné, mais je voulais conserver le format du fichier /etc/nftables.conf
sudo nft -s list ruleset | sudo tee /etc/nftables.conf

# J'insère l'entête obligatoire pour un script nftables
# + je purge toutes les règles de filtrage. Cela permet de partir sur un jeu de règles sain lors d'un start ou d'un restart
sudo sed -i '1s&^&#!/usr/sbin/nft -f\n\nflush ruleset\n\n&' /etc/nftables.conf

# J'active l'unit systemd nftables et je la démarre
sudo systemctl enable nftables
sudo systemctl start/restart nftables

# Je veux pouvoir revenir facilement à iptables, donc je ne vais pas le désinstaller
# donc j'empêche netfilter-persistent de charger les vieilles règles au démarrage
sudo systemctl disable netfilter-persistent
sudo systemctl mask netfilter-persistent

ATTENTION :

• Quand des règles ont été créées avec nftables dans une chaîne de type « ip[6] », ip[6]tables ne peut plus lire le contenu d'une table. Le message d'erreur suivant s'affiche : iptables v1.8.2 (nf_tables): table 'nat' is incompatible, use 'nft' tool.. C'est normal : il ne faut pas utiliser les commandes iptables-legacy / iptables-nft en même temps que nft, car elles utilisent des sous-systèmes différents du noyau ;
  
  
• Comme avec netfilter-persistent, si des règles ne peuvent pas être appliquées, aucune alerte est levée. SystemD remonte aucune info, aucun code retour. Attention donc à ne pas se retrouver à poil.

Commandes utiles :

• Démarrer / arrêter le pare-feu : sudo systemctl start nftables / sudo systemctl stop nftables ;
  
  
• Nettoyer les règles ajoutées temporairement à la mano : sudo systemctl restart nftables ;
  
  
• Voir toutes les règles (filtrage, nat, mangle, arp, ebtables) IPv4 et IPv6 en vigueur : sudo nft list ruleset ;
  
  
• Voir toutes les tables, les chaînes et les règles d'un protocole (IPv4, IPv6, etc.) : sudo nft list ruleset ip6 (ici, que les règles IPv6 ‒ je simplifie, ce n'est pas vrai, voir ci-dessous ‒) ;
  
  

• Voir toutes les chaînes et les règles d'une table : sudo nft list table ip6 filter (ici, que les règles de filtrage IPv6) ;

• Ajouter une règle à la fin d'une chaîne existante (oui, il faut utiliser les guillemets et les apostrophes dès qu'on veut insérer un commentaire contenant plusieurs mots) : sudo nft 'add rule ip filter INPUT iifname "eth0" udp dport 666-999 counter accept comment "Ceci est un commentaire de plusieurs mots"' (ajout d'une règle dans la chaîne nommée INPUT de la table filter du protocole ip autorisant les paquets UDP destinés aux ports entre 666 et 999 inclus qui entrent par l'interface eth0) ;

  • Insérer une règle au début d'une chaîne existante : nft insert rule ip filter INPUT iifname "eth0" udp dport 666-999 counter accept ;

• Comme avec iptables, la case est importante : si le nom d'une table ou d'une chaîne est en majuscule, il faut respecter cela sinon on a un message d'erreur abscons : « Error: Could not process rule: No such file or directory » ;

• Supprimer une règle à chaud (la logique est identique pour une chaîne et une table) :

  # Récupérer le « handle » (numérotation interne) d'une règle
  sudo nft -a list ruleset
  # Supprimer cette règle (ici une règle dans la chaîne nommée INPUT de la table nommée filter du protocole IPv4)
  sudo nft delete rule ip filter INPUT handle <handle>

  
  

• Changer à chaud la politique par défaut d'une chaîne : sudo nft chain ip filter FORWARD { policy drop \; } (la politique par défaut de la chaîne nommée FORWARD de la table filter du protocole IPv4 est désormais drop (rejet silencieux) ;

• Créer une table, une chaîne et une règle :

          sudo nft add table ip nat
  # type et hook : à quelle interface réseau et à quelle partie de la pile réseau veut-on brancher la chaîne ? Ça détermine les paquets reçus par la chaîne
  #   valeurs possibles : https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_types
  #   On peut créer des chaînes persos, non-reliées à la pile réseau, qui recevront des paquets via d'autres chaînes (-j nom_chaîne)
  # policy : politique par défaut de la chaîne : que fait-on d'un paquet qui a matché aucune règle ?
  # priority : ordonner les chaînes d'un même type+hook entre elles (le nombre le plus élevé l'emporte)
  #   \ + positionnement dans le processus de filtrage : exemple < - 200 = le paquet sera transmis à la chaîne avant la mise en place du suivi de connexion
  #   valeurs possibles : https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority
  sudo nft add chain ip nat POSTROUTING '{ type nat hook postrouting priority 100; policy accept; }'
  sudo nft add rule ip nat POSTROUTING oifname "tun0" counter masquerade

• Du point précédent, on retient que le nom d'une table et d'une chaîne est totalement personnalisable. Avec iptables, la chaîne qui s'occupe du filtrage en sortie est forcément la chaîne nommée OUTPUT de la table nommée filter. Avec nftables, ça peut être la chaîne nommée « toto » de la table « LOL » :

  table ip LOL { # handle 82
      chain toto { # handle 1
          type filter hook output priority 0; policy drop;
          icmp type echo-request accept # handle 2
      }
  }

iptables-restore-translate traduit un jeu de règles ligne par ligne, donc on ne profite pas des possibilités de factorisation de nftables :

• Une unique règle qui s'applique à plusieurs interfaces réseau sans utiliser ipset : sudo nft add rule ip filter INPUT iifname {"tun0", "wlan0"} counter accept ;
  
  
• Une unique règle qui s'applique à plusieurs adresses IP source ou destination sans utiliser ipset (destination dans cet exemple) : sudo nft add rule ip filter OUTPUT ip daddr {192.0.2.1, 198.18.0.0/15} counter accept ;
  
  
• Une unique règle qui s'applique à plusieurs protocoles de la couche 4 : sudo nft add rule ip filter FORWARD ip protocol {tcp, udp} accept ;
  
  
• Une unique règle qui s'applique à plusieurs ports d'un même protocole de couche 4 : sudo nft add rule ip filter INPUT udp dport {53, 5353} counter accept ;
  
  
• Et si l'on veut autoriser un même port pour plusieurs protocoles comme autoriser, en une seule règle, le DNS (qui nécessite les ports udp/53 et tcp/53) ? Ce n'est pas vraiment prévu : le mot clé « dport » est relatif au mot clé (tcp ou udp). On peut ruser, mais c'est crade : sudo nft 'add rule inet filter INPUT ip protocol {tcp, udp} @th,16,16 53 counter accept comment "DNS udp et tcp"'. Attention : cela nécessite que le port de destination soit stocké au même emplacement dans l'entête des deux protocoles.

nftables permet également d'appliquer une même règle en IPv4 et en IPv6. Cela se fait avec une table de type « inet ». Cela signifie que des règles concernant IPv4 peuvent se trouver dans une table de type inet ET dans une table de type ip (d'où sudo nft list ruleset ip6 n'affiche pas toutes les règles IPv6 mais toutes les tables de type ip6). Exemple pour autoriser SSH en entrée en IPv4 et en IPv6 :

sudo nft add table inet filter
sudo nft add chain inet filter INPUT '{ type filter hook input priority 0; policy drop; }'
sudo nft add rule  inet filter INPUT tcp dport ssh counter accept

Attention : à hook identique et à priorité égale ou même supérieure une chaîne de type inet passe avant une chaîne de type ip. Si la chaîne inet ne drop pas le paquet, la chaîne ip le verra passer, sinon non. Source. Cela peut poser problème. Exemple : virt-manager crée un réseau NATé pour les machines virtuelles. Pour ce faire, il utilise des chaînes de type / de la famille ip. J'effectue tout mon filtrage dans des chaînes de type inet dont la politique est de drop sauf ce qui va dans un VPN. Conclusion : la machine virtuelle n'aura pas d'IP (DHCP foiré) et ne pourra pas sortir sur Internet.

Dans une chaîne de type inet, il est possible de filtrer uniquement IPv4 ou IPv6. Soit en utilisant une directive spécifique à un protocole (exemple : sudo nft add rule inet filter INPUT ip daddr 192.0.2.1/32 accept, soit en utilisant les mots-clés « meta nfproto ipv(4|6) » (exemple : sudo nft add rule inet filter OUTPUT meta nfproto ipv4 udp dport 666 reject with icmp type admin-prohibited).

Documentations utiles :

• nftables dans le wiki Debian ;
  
  
• Doc' poussée sur les chaînes, hook, priorités, etc. sur le wiki nftables ;
  
  
• Mots-clés de référence utilisables dans une règle sur le wiki nftables.

logrotate / rsyslog

Mes journaux consignés par rsyslog n'étaient plus archivés par logrotate. De plus, dans /etc/logrotate.d/rsyslog, je constate qu'on n'utilise plus invoke-rc.d rsyslog rotate > /dev/null, mais /usr/lib/rsyslog/rsyslog-rotate.

Ces deux éléments sont liés : il y a un bug (l'unit systemd fait démarrer rsyslog sans PID, alors qu'on en a besoin pour invoke-rc.d) et Debian a mis en place le magnifique (ironie) script /usr/lib/rsyslog/rsyslog-rotate (résumé : si systemd est en cours d'utilisation, alors on utilise systemctl kill pour envoyer un signal à rsyslog, sinon on utilise invoke-rc.d).

J'ai modifié toutes mes configurations logrotate afin d'utiliser /usr/lib/rsyslog/rsyslog-rotate dans l'action de post-rotate, même si ça ne me semble pas pérenne…

man-db

CRON me rapporte une erreur :

/etc/cron.daily/man-db:
/usr/bin/mandb: error while loading shared libraries: libgdbm.so.3: cannot open shared object file: No such file or directory
run-parts: /etc/cron.daily/man-db exited with return code 127

Regardons les bibliothèques de fonctions qui sont liées dynamiquement à man-db :

$ ldd /usr/bin/mandb 
linux-vdso.so.1 (0x00007ffeb36fe000)
libmandb-2.7.6.1.so => /usr/lib/man-db/libmandb-2.7.6.1.so (0x00007fb4ffa8b000)
libman-2.7.6.1.so => /usr/lib/man-db/libman-2.7.6.1.so (0x00007fb4ff868000)
libgdbm.so.3 => /usr/lib/x86_64-linux-gnu/libgdbm.so.3 (0x00007fb4ff661000)
libpipeline.so.1 => /usr/lib/x86_64-linux-gnu/libpipeline.so.1 (0x00007fb4ff453000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb4ff0b4000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fb4fee9a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb4ffeb3000)

Hum… Il y a bien libgdbm.so.3… qui n'existe plus au profit de libgdbm.so.6.

""""Solution"""" ? apt-get install --reinstall man-db

Merci pour le poisson.

MariaDB

MariaDB 10.3 ne s'est pas installé tout seul, j'ai dû le faire à la mano (sudo apt-get install mariadb-server). J'imagine que j'avais installé le paquet mariadb-server-10.1 quand j'étais sous Stretch au lieu du paquet mariadb-server…

Durant l'installation, je lis mysql_install_db : Installation of system tables failed!. Dans le journal MariaDB (/var/log/mysql/…), je lis : Unable to lock ./ibdata1 error: 11.

Hum… Fichier déjà ouvert. Donc : systemctl stop mariadb && mysql_install_db && systemctl start mariadb.

MATE

Durant la mise à jour, le texte de toute fenêtre déjà ouverte (ou ouverte après-coup) foire : flou, difficile à lire, etc. Les intitulés des menus sont parfois tronqués comme le menu « fichier » dans Pluma. Sur tout site web, les caractères sont remplacés par des carrés. Après vérification, ce n'est pas un changement de définition (1920x1080) ni de résolution (en DPI).

On se dit qu'on va reboot. Depuis le menu MATE, ça ne fonctionne pas : je tombe sur un GNOME shell (qu'est-ce qu'il fout ici, celui-là ?!) qui me demande mon mot de passe comme si la session était verrouillée. Toute saisie est impossible. Le bouton arrêter / redémarrer en haut à droite de l'écran fait rien. Pas d'accès aux consoles (ctrl+alt+fx). On est parti pour un REISUB / BUSIER…

Au redémarrage, tout est OK : les textes et les menus s'affichent correctement et l'extinction / le redémarrage via le menu MATE sont fonctionnels. Même chose pour les tty.

Néanmoins, la sensibilité de la souris a été clairement abaissée. Mon pointeur se traîne… On corrige ça dans les paramètres.

Je note aussi que, quand caja (explorateur de fichiers MATE) gueule « failed to activate device operation not permitted », ça signifie que je n'ai pas saisi la bonne passphrase pour déverrouiller un disque dur interne (le message qui s'affiche pour pareille boulette sur un disque dur externe n'a pas changé…).

mumble

Prise en charge des suites de chiffrement qui permettent la Perfect Forward Secrecy (en clair : utilisation de clés de chiffrement symétrique temporaires qui ne sont pas échangées entre le client et le serveur grâce aux algos DHE / ECDHE, ce qui fait que si la clé privée asymétrique est compromisse, les échanges passés restent secrets). Cool. \o/

ntpd / tzdata

Le paquet tzdata livre désormais un fichier qui annonce les secondes intercalaires (ça permet de les gérer). ntpd est configuré par défaut pour utiliser ce fichier (leapfile /usr/share/zoneinfo/leap-seconds.list). Avant, il fallait récupérer manuellement le fichier auprès du NIST (ou de l'IANA ou…) et configurer ntpd nous-même. Cool.

Ça ne changera pas grand-chose puisque les serveurs NTP de strate 1 bien connus communiquent la seconde intercalaire via le protocole NTP lui-même.

ntpdate

Ce paquet ne fournit plus de hooks ifupdown permettant à ntpdate d'être exécuté à chaque fois qu'une connexion au réseau est établie. Il faut utiliser un démon NTP (ntpd, chrony, etc.) ou, au pire du pire, bidouiller ses propres scripts.

C'est positif, ça posait souvent problème : synchronisation aléatoire, ça n'utilisait pas les serveurs NTP du réseau reçus en DHCP, etc.

OpenDNSSEC

Lors de son démarrage, ods-enforcerd consigne Token.cpp(482): Could not get the token flag dans son journal. Cela fait penser à ce bug, mais il est trop vieux pour ne pas avoir été corrigé dans Buster. De plus, un simple systemctl restart ods-enforcerd suffit à faire rentrer les choses dans l'ordre. Je pense à une race-condition au démarrage du serveur, car ça n'est pas reproduit après le deuxième redémarrage. À défaut d'une solution, je me note d'être vigilant à chaque redémarrage de mon serveur…

J'ai découvert que, dans le cadre des DNS adapters (source), le signeur écoute sur les ports TCP et UDP 15354 de toutes les interfaces, et évidemment pas que sur localhost… Ce n'est pas ce que dit la documentation, mais c'est ce que je constate. Pour rattraper le coup, j'ai remplacé le bloc Listener dans /etc/opendnssec/conf.xml par celui-ci :

<Listener>
        <Interface>
                <Address>127.0.0.1</Address>
                <Port>5353</Port>
        </Interface>
</Listener>

OpenSSH

• Les variables d'environnement (y compris celles positionnées dans le fichier authorizedkeys) ne peuvent plus surcharger les variables « SSH* » de sshd ;
  
  
• La journalisation de l'authentification est plus précise durant la phase de pré-auth et le format de certains messages a changé donc attention aux outils qui examinent les journaux SSH.

OpenSSL

Par défaut, c'est la version 1.2 ou supérieure du protocole TLS qui sera utilisée.

Par défaut, les suites de chiffrement faibles sont désactivées. Adieu RSA / DHE avec des clés inférieures à 2048 bits et ECDSA / ECDHE < 224 bits. Adieu les certificats dont la signature repose sur SHA-1 pour en créer le condensat.

Dans les deux cas, cela peut être contourné dans /etc/ssl/openssl.cnf en remplaçant :

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

Par :

[system_default_sect]
MinProtocol = None
CipherString = DEFAULT

Attention : les applications peuvent faire comme elles veulent. Exemples : wpa_supplicant accepte les certificats x509 dont l'algo de hachage avant signature est SHA-1. openssl s_client affiche un message « Verify return code: 68 (CA signature digest algorithm too weak) »

PHP

J'utilise le module PHP pour Apache HTTPd. Je suis quasiment sûr que le paquet libapache-mod-php (et non pas libapache-mod-php7.2) était installé. Pourtant, j'ai dû activer moi-même le module PHP 7.3 (version empaquetée dans Buster) à la main (a2endmod php7.3 && systemctl restart apache2). Au préalable, j'ai migré ma conf' PHP (php.ini) personnalisée de /etc/php/7.2/apache2 vers /etc/php/7.3/apache2 (ne pas faire un cp sinon on ne bénéficie pas des nouveautés…, préférer diff).

Thunderbird

La date et l'heure des emails s'affichaient au format anglais. Le paquet thunderbird-l10n-fr était bien installé. J'avais vérifié mes locales. J'avais tenté de lancer Thunderbird depuis un shell en précisant la locale juste avant. J'avais tenté de bidouiller mail.ui.display.dateformat.default et ses amies Sans succès.

Depuis la mise à jour vers Buster, les dates et l'heure des emails sont au format français…

ssmtp

ssmtp n'est pas empaqueté dans Buster, mais il est présent dans testing et sid, donc, comme le T-800, il reviendra.

xsane

Depuis octobre 2018, xsane n'est plus maintenu (le site web officiel affiche « XSane (temporarily offline!) »).

#Debian 9 à Debian 10 ; Debian 9 à 10

Sur ma machine perso et depuis sa mise en service, le serveur graphique X.Org me crache des tonnes d'erreurs dans ~/.local/share/xorg/Xorg.0.log. Toujours la même : « (EE) FBDEV(0): FBIOPUTCMAP: Device or resource busy ». En permanence, dès que je bouge ma souris. ÉDIT DU 12/10/2020 À 20 H 50 : La procédure ci-dessous permet également de résoudre la coulée permanente d'erreurs « (EE) modeset(0): present flip failed ». FIN DE L'ÉDIT.

Le message d'erreur étant plutôt générique, je ne trouvais pas d'aide sur le web, donc j'avais laissé tomber. Je pensais à un problème de pilote graphique, de fonctionnalités non-supportées par ce dernier, quelque chose comme ça. Ce n'était pas gênant, car une rotation / nettoyage automatique du journal avait lieu, donc il consommait quelques Go à tout casser.

J'ai mis à jour mon système Debian GNU/Linux à la version Buster. Ce problème continue. J'ai un peu craqué : mon modèle d'ordinateur date de 2012-2013, il est équipé d'un GPU Intel greffé sur le CPU. Le GPU le plus simple et compatible au monde, et ça continue de foirer en 2020 ?!

Mon fichier de config' /etc/X11/xorg.conf date de 2014. Peut-être faut-il en générer une version actualisée ? Ouais, je sais : avec l'autoconfiguration Xorg, KMS et compagnie, on n'est plus censé devoir faire ça… sauf que ça a jamais vraiment fonctionné chez moi.

Pour générer un nouveau fichier xorg.conf (adapté de ce tuto) :

• Fermer ses logiciels / fichiers ;
  
  
• Basculer en console tty avec ctrl+alt+F[1-6] et se connecter en root ;
  
  
• Copier la conf' actuelle : cp /etc/X11/xorg.conf ~/xorg.conf.bak ;
  
  
• Stopper le gestionnaire d'affichage (gdm, dans mon cas, même si, depuis, je suis passé à lightdm) : systemctl stop gdm3 ;
  
  
• Générer la conf' : X -configure ;
  
  
• Déplacer la conf' au bon endroit : cp xorg.conf /etc/X11/xorg.conf ;
  
  
• Relancer le gestionnaire d'affichage : systemctl start gdm3.

Hop, plus aucune erreur dans ~/.local/share/xorg/Xorg.0.log depuis plusieurs mois. \o/

Sur mon serveur d'emails, j'utilise OpenDKIM pour signer quelques entêtes de mes emails sortants et pour vérifier la signature des entrants dans un contexte anti-spam (il ne s'agit pas de garantir la confidentialité / l'authenticité / l'intégrité de l'échange). J'ai configuré OpenDKIM pour qu'il vérifie les signatures DNSSEC afin de garantir l'authenticité et l'intégrité des clés publiques DKIM récupérées dans le DNS. Ça sert à rien (déjà que DKIM c'est du vent…), mais bon, ça fait joli.

Depuis bientôt 1 an (juin 2019), j'ai remarqué que la signature des emails entrants n'est plus vérifiée. J'avais constaté l'absence de l'entête « Authentication-Results » dans les emails. J'avais constaté que Postfix consigne ce qui suit pour chaque email reçu : « warning: milter inet:127.0.0.1:10028: can't read SMFIC_EOH reply packet header: Success ». Tant que je pouvais envoyer des emails et en recevoir, je m'en fichais.

Il y a 3 mois, j'ai décidé d'étudier cela attentivement, car, à moment donné, il faut bien se sortir les doigts.

Le message consigné par Postfix est trop générique : c'est le constat d'un milter défectueux, rien de plus.

OpenDKIM consigne rien excepté exited with status 1, restarting à chaque email reçu ou presque. Le lancer à la main (systemctl stop opendkim && opendkim -f -vvv) ne le rend pas plus bavard.

J'ai aucune idée. Dans ces moments-là, je reviens aux bases, j'essaye de me souvenir comment fonctionne précisément le logiciel incriminé, je relis la doc' relative à mon système d'exploitation, etc. La doc' Debian pour OpenDKIM est ici. Et la réponse s'y trouve sous forme d'un gros avertissement :

The Debian unbound package installs a default configuration file at /etc/unbound/unbound.conf. Do not attempt to use this file unchanged with ResolverConfiguration! opendkim will just quietly shut down.

The reason for the incompatibility is that the shipped unbound.conf includes an auto-trust-anchor-file setting, for which opendkim does not have the necessary permissions. Unfortunately, libunbound is rather fragile in this area. Prepare your own unbound.conf for opendkim and test carefully. 

Une fois qu'on a connaissance de ça, une recherche sur le web avec de nouveaux mots-clés permet d'obtenir une confirmation : Question #293418 : Questions : opendkim package : Ubuntu.

Je n'utilise pas /etc/unbound/unbound.conf, mais, dans ma configuration pour la bibliothèque Unbound, j'utilise bien auto-trust-anchor-file. Ce que je ne comprends pas, c'est que je stocke la clé publique de la racine DNS dans une arborescence dédiée à OpenDKIM : /var/lib/dkim/. C'est aussi là qu'est stockée la clé privée avec laquelle sont signés les emails. Ça devrait donc fonctionner.

Pour une raison qui m'échappe totalement, l'utilisateur OpenDKIM n'était plus propriétaire ni du dossier /var/lib/dkim, ni de la clé publique de la racine DNS. La bibliothèque Unbound exécutée par OpenDKIM (uid:gid identique, donc) ne pouvait donc pas l'actualiser. J'ai corrigé ça de cette manière :

chown opendkim:root /var/lib/dkim
chmod 755 /var/lib/dkim
chown opendkim:opendkim /var/lib/dkim/dnssec.root.key
chmod 664 /var/lib/dkim/dnssec.root.key

On redémarre OpenDKIM (systemctl restart opendkim) et c'est fini.

Résumé : si t'as configuré ton serveur d'emails Postfix pour qu'il prenne en compte les enregistrements DNS DANE TLSA et qu'un email n'est pas envoyé au motif d'erreur « Server certificate not verified », vérifie la validité de l'enregistrement TLSA associé au serveur emails du destinataire avec l'outil tlsa de la suite logicielle hash-slinger : il ne correspond très probablement pas au certificat x509 présenté par le serveur emails. Contacte l'hébergeur du serveur en utilisant whois -B <adresse_IP_du_serveur. On notera que le message d'erreur de Postfix n'est pas explicite, donc qu'il y a encore du boulot de ce côté-là avant une généralisation de DANE TLSA.

DANE TLSA permet de stocker, dans le DNS signé avec DNSSEC, les certificats x509 afin d'obtenir une deuxième chaîne de validation et de combler ainsi les immenses lacunes conceptuelles du modèle de sécurité de la norme x509. Détails et utilisation concrète ici.

Il y a quelques jours, j'ai rencontré, en production, mon premier pépin dont l'origine est DANE TLSA.

J'envoie un email. Un jour après, pour comprendre une toute autre chose, je consulte le journal de Postfix, mon serveur d'emails. Par hasard (tail -f et nouvelle tentative d'envoi récente), j'y lis ceci :

postfix/smtp[23743]: 235AB2AE: to=[CENSURE], relay=[CENSURE][[CENSURE]]:25, delay=82176, delays=82176/0.15/0.13/0, dsn=4.7.5, status=deferred (Server certificate not verified)

Notons que si je n'avais pas consulté le journal, j'aurais quand même été informé du problème en recevant, après 5 jours (valeur par défaut du paramètre maximal_queue_lifetime de Postfix), un email présentant le problème émis par « Mail Delivery System / MAILER-DAEMON », c'est-à-dire Postfix lui-même.

Je cherche à obtenir plus d'infos.

Ajouter « -v » dans la colonne « command + args » des services « tlsmgr » et « smtp » dans master.cf (exemple : « tlsmgr unix - - y 1000? 1 tlsmgr -v ») + systemctl reload postfix rend Postfix plus causant mais cela m'apprend rien.

Dans main.cf, je suis déjà en smtp_tls_loglevel = 1. En changer la valeur pour « 2 » et recharger Postfix ne m'en apprendra pas d'avantage.

Rien permet de comprendre l'origine du problème, pas un seul indice. Un message d'erreur explicite serait le bienvenu avant une généralisation de DANE TLSA.

Je connais les compétences des salariés de l'hébergeur emails de mon destinataire, donc je choisis de remettre en cause mon installation plutôt que la leur.

Comme m'y incite le premier résultat d'une recherche du message d'erreur « Server certificate not verified » dans un moteur de recherche, je commence à creuser la politique de validation d'un certificat x509 appliquée par Postfix (paramètres smtp_tls_(verify|secure)_cert_match) : avec quoi compare-t-on le Common Name / SubjectAltName ? Avec le nom du serveur ? Avec le nom de domaine du destinataire ? Avec celui de l'hébergeur emails ? Ma recherche en ce sens donnera rien.

Je réfléchis (enfin). Comme l'écrasante majorité des serveurs emails, le mien est configuré pour tenter un envoi en clair si l'envoi chiffré a été impossible (on nomme ça TLS / chiffrement opportuniste). Pourquoi mon serveur n'a pas agit comme ça cette fois-ci ?

Il est configuré pour prendre en compte les enregistrements DNS TLSA : smtp_dns_support_level=dnssec + smtp_tls_security_level=dane (attention : les versions de TLS et les suites de chiffrement autorisées se définissent désormais dans smtp_tls_mandatory_protocols et smtp_tls_mandatory_ciphers !). Si l'hébergeur emails du destinataire a positionné un enregistrement TLSA, cela signifie qu'il veut qu'on échange avec lui de manière chiffrée, donc on n'essaye pas de communiquer en clair. DANE TLSA pallie à la principale limite du chiffrement opportuniste : sans TLSA, si le message d'initialisation du chiffrement, STARTTLS, est perdu ou volontairement stoppé par un méchant, alors la communication s'effectue sans chiffrement.

Je vérifie la présence d'un enregistrement TLSA avec dig TLSA _25._tcp.<nom_du_smtp_distant_qui_est_mentionné_dans_relay_dans_le_journal_Postfix>. Il y en a bien un.

J'utilise tlsa, un petit script de la collection hash-slinger (qui permet, également et entre autres, la manipulation des enregistrements DNS SSHFP et des enregistrements DNS DANE OpenPGP) pour vérifier la validité de cet enregistrement.

Attention si tu utilises Debian GNU/Linux Buster : hash-slinger n'est pas empaqueté dans cette version à cause d'une dépendance à python3-m2crypto non satisfaite. La version de hash-slinger qui utilise python2 que t'as pu installer avant de mettre à jour ton système pourrait ne pas fonctionner dans certains cas à cause de l'obsolescence de la bibliothèque TLS (« M2Crypto.SSL.SSLError: wrong version number », c'est du vécu). Bref : sudo apt-get install swig && pip3 install m2crypto + installer hash-slinger depuis le dépôt git officiel (git clone + sudo make install).

Je vérifie donc la validité de l'enregistrement TLSA positionné par l'hebergeur emails :

$ tlsa --verify --port 25 <nom_du_smtp_distant_qui_est_mentionné_dans_relay_dans_le_journal_Postfix>
FAIL (Usage 3 [DANE-EE]): Certificate offered by the server does not match the TLSA record ([CENSURE])

Oups… Tout s'explique… Le certificat x509 présenté par le serveur emails ne correspond pas à l'enregistrement TLSA.

Afin d'être sûr de moi, je calcule moi-même le RDATA de l'enregistrement DNS en fonction du certificat actuellement utilisé avec $ openssl s_client -connect [CENSURE]:25 -starttls smtp -showcerts < /dev/null 2> /dev/null | openssl x509 -pubkey | openssl rsa -pubin | head -n -1 | tail -n +2 | base64 -d | sha256sum et, oui, il ne correspond pas à celui mis en service. Pour les détails : l'enregistrement présent est un condensat SHA-256 (mtype = 1) de la clé publique (selector = 1) du seul certificat du serveur (usage = 3), d'où cet enchaînement de commandes publié sur le blog de Stéphane Bortzmeyer pour le synthétiser.

Je contacte l'hébergeur emails. Comment ? whois -B <IP_du_serveur_emails>. D'une manière générale, ne pas oublier « -B » : cela permet d'obtenir des adresses emails autres que celle qui permet de signaler les abus. J'ai mis de côté d'autres paramètres bien utiles de la commande whois dans mon article Découvrons la RIPE database.

En fin de matinée du premier jour ouvré suivant mon email, l'enregistrement DANE TLSA a été retiré. Fin du problème, mais c'est dommage d'avoir laissé tomber… Peut-être est-ce un repli stratégique pour réfléchir à un meilleur déploiement, avec supervision et tout et tout ?

Ce matin, je veux appliquer les mises à jour de sécurité sur mon système Debian GNU/Linux Buster et…

Paramétrage de linux-image-4.19.0-8-amd64 (4.19.98-1+deb10u1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.19.0-8-amd64
E: /usr/share/initramfs-tools/hooks/growroot failed with return 1.
update-initramfs: failed for /boot/initrd.img-4.19.0-8-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: erreur de traitement du paquet linux-image-4.19.0-8-amd64 (--configure) :
 installed linux-image-4.19.0-8-amd64 package post-installation script subprocess returned error exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
 linux-image-4.19.0-8-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Lançons update-initramfs nous-même :

# update-initramfs -vuk 4.19.0-8-amd64
Calling hook growroot
Adding binary /sbin/sfdisk
Adding library-link /lib/x86_64-linux-gnu/libfdisk.so.1.1.0
Adding library /lib/x86_64-linux-gnu/libfdisk.so.1.1.0
Adding library-link /lib/x86_64-linux-gnu/libsmartcols.so.1.1.0
Adding library /lib/x86_64-linux-gnu/libsmartcols.so.1.1.0
Adding library-link /lib/x86_64-linux-gnu/libtinfo.so.6.1
Adding library /lib/x86_64-linux-gnu/libtinfo.so.6.1
E: /usr/share/initramfs-tools/hooks/growroot failed with return 1.

Regardons /usr/share/initramfs-tools/hooks/growroot (premier script qui termine en erreur) :

# cat /usr/share/initramfs-tools/hooks/growroot
#!/bin/sh
set -e

PREREQS=""
case $1 in
    prereqs) echo "${PREREQS}"; exit 0;;
esac

. /usr/share/initramfs-tools/hook-functions

##
copy_exec /sbin/sfdisk /sbin
copy_exec /usr/bin/growpart /sbin
[…]

Ça échoue sur « copy_exec /usr/bin/growpart ».

# ls -lh /usr/bin/growpart
ls: impossible d'accéder à '/usr/bin/growpart': Aucun fichier ou dossier de ce type

Intéressant. Il vient d'où, ce fichier ?

$ apt-file search /usr/bin/growpart
cloud-guest-utils: /usr/bin/growpart

Du paquet logiciel cloud-guest-utils. Cloud-init est utilisé par mon fournisseur de machines virtuelles et, en effet, je l'ai viré de mon VPS (machine virtuelle) depuis quelques mois. Pourquoi ça n'a pas supprimé le hook initramfs ?

$ apt-file search /usr/share/initramfs-tools/hooks/growroot
cloud-initramfs-growroot: /usr/share/initramfs-tools/hooks/growroot

Il est installé par un autre paquet logiciel. Peut-être que ce paquet est toujours installé ?

# apt-cache policy cloud-initramfs-growroot
cloud-initramfs-growroot:
  Installé : (aucun)
  Candidat : 0.18.debian7
[…]

Non. Peut-être y a-t-il de la configuration résiduelle ?

# dpkg -l | grep cloud-initramfs-growroot
#

Non.

""""Solution"""" : apt-get install --no-install-recommend cloud-initramfs-growroot && apt-get autoremove --purge cloud-guest-utils cloud-image-utils cloud-initramfs-growroot cloud-utils genisoimage qemu-utils.

@Oros :

Genre warriordudimanche.net ou lien.shazen.fr ne me retournent aucune réponse.

T'arrives à wget http://kosmogonia.fr/ ou https://switchy.o2switch.net:2083/ depuis ton serveur ? Un traceroute / mtr / traceroute -T -p 443 ?
J'ai voulu tester avec RIPE Atlas, mais il n'y a pas de sonde participante dans le réseau d'Edis.

$ dig +short warriordudimanche.net
109.234.161.33

$ dig +short lien.shazen.fr
109.234.161.21

$ whois 109.234.161.33
[…]
route:          109.234.161.0/24
descr:          o2switch Internet Routing
origin:         AS50474

@Oros :

Là où j'ai besoin d'aide c'est de trouver si dans le lot, il y en a où l'erreur était temporaire ou s'ils ont changé d'URL.

Je m'en suis occupé.

Au début, on a 208 shaarlis marqués invalides.

Combien y a-t-il de domaines non associées avec une IPv6 ou une IPv4 ? Boucle for + commande `host'.

• 130 domaines n'ont pas d'adresse v4/v6. Le domaine shaarli.fr, non renouvellé donc supprimé de fr., représente 85 URLs à lui seul ;
  
  
• 78 en ont au moins une.

Quel contenu est pointé par ces 78 URLs ? Allons-voir avec wget --quiet --max-redirect=0 --connect-timeout=10 --tries=1 -O - (un seul essai, on tente d'établir la connexion TCP durant 10 secs maximum, on refuse les redirections HTTP). Quand on a une réponse, on grep « pubDate » afin de nous assurer qu'il s'agit d'un flux RSS (et de voir la date du dernier shaarli publié).

• 10 shaarlis sortent avec le code retour 0. C'était donc une erreur temporaire ;
  
  
• 15 sortent en 4 : timeout TCP. Ça peut être dû à une IPv6 foireuse. On applique un wget -4 sur cette liste : on récupère aucun shaarli, donc c'est tout des shaarlis disparus ;
  
  

• 11 sortent en 5 : erreur x509. On utilise wget --no-check-certificate. 9 URL passent en code retour 8. 2 URLs sont des shaarlis OK avec un certificat x509 invalides ;

• 37 sortent en 8 : erreur HTTP. + les 9 URL du point précédent. 46 URL en tout. Ça peut être une redirection. On utilise wget sans interdire la redirection + grep 'Emplacement' | tail -n 1 pour choper l'URL de destination et l'ajouter à la liste.

  • On joue wget | grep 'erreur'. On a 16 URLs OK, 30 erreurs (404, 403, 410, 500).
    • J'ai regardé les URL en erreur, j'ai remonté la racine, j'ai essayé des sous-domaines comme shaarli ou links : les shaarlis n'existent plus, sauf dans 4 cas ;
      
      
    • Parmi les 16 URLS OK, seules 7 amènent à un flux RSS shaarli. Il s'agit principalement de redirections HTTP vers HTTPS ;
• 5 présentent un résultat qui n'est pas du RSS. J'ai vérifié à la main : soit le site web entier n'existe plus, soit je n'ai pas trouvéé de lien vers le shaarli (abandon de shaarli probable).

Au final, dans la liste https://github.com/Oros42/shaarlis_list/blob/master/shaarlis_HS.json , seuls les shaarlis suivants fonctionnent et peuvent être ajoutés à la rivière :

• http://lien.shazen.fr/?do=rss
  
  
• http://lienspersos.accessibilisation.net/shaarli/?do=rss (il est en double dans la liste « shaarlis_HS.json »)
  
  
• http://shaarli.epha.se/?do=rss
  
  
• https://j-mad.com/shaarli/?do=rss (il est présent en HTTP et en HTTPS dans la liste « shaarlis_HS.json », la redirection HTTP => HTTPS fait tomber le site HTTP dans code retour 8). Déjà présent dans « shaarlis.json », mais passage à HTTPS ;
  
  
• https://jcfrog.com/shaarli41/?do=rss . (il est en double, HTTP et HTTPS dans « shaarlis_HS.json »). Déjà présent dans « shaarlis.json », mais passage à HTTPS ;
  
  
• https://warriordudimanche.net/feed.php?rss/categorie015 OU https://warriordudimanche.net/feed/rss
  
  
• https://shaarli.hoab.fr/
  
  
• https://shaarli.yggz.org/?do=rss
  
  
• https://jeekajoo.eu/links/?do=rss . Déjà présent dans « shaarlis.json », mais changement du nom de domaine ;
  
  
• https://shaarli.librement-votre.fr/?do=rss
  
  
• https://chabotsi.fr/links/?do=rss . Déjà présent dans « shaarlis.json ». On peut aussi virer son doublon dysfonctionnel « https://chabotsi.fr/links?do=rss » ;
  
  
• https://e-jim.be/liens/?do=rss

Les shaarlis suivants ont besoin d'un ajustement avant de rejoindre la rivière :

• https://shaarli.base-jump.info/?do=rss . Soit on intègre la version HTTP à la rivière, soit le certificat x509 doit être corrigé (il ne couvre pas le nom de domaine) ;
  
  
• https://links.yosko.net/?do=rss . Certificat x509 qui ne couvre pas le nom de domaine + IPv6 HS ;
  
  
• https://shaarli.callmematthi.eu/?do=rss . Code HTTP 410 sur les flux (RSS et Atom). Probablement une erreur de config' ;
  
  
• https://links.green-effect.fr/?do=rss . (il est en triple, HTTP, HTTPS, URL invalide dans « shaarlis_HS.json »). IPv6 HS. Dans « shaarlis.json », on peut virer son doublon inutile « http://links.green-effect.fr/?do=rss?do=rss » ;
  
  
• https://web.amok.lu/shaarli/?do=rss . IPv6 HS ;
  
  
• https://ban.netlib.re/shaarli/?do=rss . IPv6 capricieuse (ne fonctionnait pas en début d'aprem, fonctionne depuis le milieu d'aprem).

@Antichesse :

Je subodore que tout le mérite revient à certains de vos postes qui sont d'une extrême qualitayyy, que dis-je d'une importance crousssiale !

Ce qui m'a fait basculer, c'est très clairement ce tutoriel : Retirer ses chaussettes - Strawberry. Pour l'instant, je ne parviens pas à le mettre en œuvre, donc je suis tristesse.

Bon, c'est un peu aussi pour les shaarlis qui causent d'informatique, particulièrement de technos relatives au développement. Je comprends pas tout, car ce n'est pas mon domaine, mais c'est le but : m'ouvrir l'esprit.

Aller en voici quelques uns pour la gloire

J'veux pas dire, mais deux shaarlis de la liste sont signés Animal alors que les autres ont un seul de leur shaarli dans la liste. #injustice. J'vous laisse voir ça entre vous, hein. :P

@GuiGui merci pour ta recommandation ;)

De rien. :)

P.S : je suis d'accord vis-à-vis des PR sur GitHub, mieux vaut se monter un Gitea chez soi.

Ou Gogs, qui a pour lui l'humour de son nom (peut-être s'agit-il d'une description réaliste du langage de programmation dans lequel il est codé ?).

@Oros :

Faut pas retirer de grosses coupure.

Je suis bien d'accord, mais c'est chiant si ton objectif est de retirer une somme d'argent proche du montant max des retraits (c'est toi qui as écrit ça)

En plus du fait que je connais le crochetage ^_^

Les tutos de crochetage m'envoient du rêve, mais je n'ai pas la patience. :D

@Oros :

Du coup, c'est aussi arrivé chez moi https://ecirtam.net/shaarlirss/

Youhou \o/ Merci.