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!) »).