GuiGui's Show

Ce n'est pas le passage à Jessie lui-même qui va durcir vos configs TLS mais le fait que des logiciels serveur y sont présents dans une version qui ouvre de nouveaux horizons. Il s'agit d'Apache httpd, d'ejabberd et de dovecot. Je repars des configurations que j'ai donné dans un autre shaarli (à la fin) : http://shaarli.guiguishow.info/?GPqmpA

Commençons par Dovecot :
    * La directive de configuration « ssl_prefer_server_ciphers = yes » permet de forcer les clients à respecter l'ordre du serveur dans le choix de la suite cryptographique à utiliser parmi toutes celles supportées des deux côtés. Cette directive évite le choix d'une suite cryptographique sous-optimale (bug ou attaque par repli afin de choisir une suite que l'attaquant sait cassable facilement). Voir https://www.howtoforge.com/tutorial/how-to-protect-your-debian-and-ubuntu-server-against-the-logjam-attack/

    * La génération des paramètres de Diffie-Hellman a complètement changé depuis la branche 2.1 : « When Dovecot starts up for the first time, it generates new 512bit and 1024bit Diffie Hellman parameters and saves them into <prefix>/var/lib/dovecot/ssl-parameters.dat. Dovecot v2.1.x and older regenerated them every week by default, but because the extra security gained by the regeneration is quite small, Dovecot v2.2 disabled the regeneration feature completely. » (source : http://wiki.dovecot.org/SSL/DovecotConfiguration ). Avec ce changement, rien de nous empêche de générer des paramètres de Diffie-Hellman plus robustes, même sur un tout petit serveur genre OlinuXino ou Raspberry Pi avec « ssl_dh_parameters_length = 4096 », par exemple. J'ai mis 4096 bits dans cet exemple car c'est la taille de la clé dans le certificat x509 utilisé par ce serveur. Je rappelle que l'ANSSI recommande 3072 bits et que la NSA dit 3072 bits minimum (voir http://shaarli.guiguishow.info/?r6npkg ). ;) Après l'ajout de cette directive de configuration, Dovecot générera les paramètres de Diffie-Hellman au prochain reload/restart. :)


Continuons avec Apache httpd :
    * « Beginning with version 2.4.7, mod_ssl makes use of standardized DH parameters with prime lengths of 2048, 3072 and 4096 bits and with additional prime lengths of 6144 and 8192 bits beginning with version 2.4.10 (from RFC 3526), and hands them out to clients based on the length of the certificate's RSA/DSA key. » (source : https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificatefile ). C'est déjà une excellente nouvelle : on gagne en sécurité sans avoir quoi que ce soit à configurer.

    * On voudrait aussi pouvoir utiliser des paramètres de Diffie-Hellman personnalisés afin d'être sûrs de leur unicité (pour éviter les attaques par pré-calcul) et/ou de leur bonne génération (utiliser un bon générateur de nombre pseudo-aléatoires). Pour cela, on peut utiliser la directive de configuration « SSLOpenSSLConfCmd » (voir https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslopensslconfcmd ). Exemple : « SSLOpenSSLConfCmd DHParameters "/etc/apache2/ssl/dh_4096.pem" » (voir http://shaarli.guiguishow.info/?hCgBYQ pour apprendre à générer des dhparam). L'ennui, c'est qu'il faut avoir OpenSSL >= 1.0.2 alors que nous avons uniquement la version 1.0.1 dans Jessie... Une autre idée est de chaîner le fichier contenant les paramètres DH au fichier contenant votre certificat x509 (pour ce faire : cat moncert.pem dh_4096.pem > cert+dh.pem) et de donner ce chaînage à manger à « SSLCertificateFile ». Perso, je ne fais pas ça car je factorise un même fichier certificat entre tous mes logiciels serveur car j'ai la flemme de changer X fichiers à chaque renouvellement de certificat. J'attendrais donc OpenSSL 1.0.2


Terminons avec ejabberd :
    * Ejabberd permet enfin de définir la liste des suites cryptographiques que l'on souhaite utiliser ! C'est la directive de configuration « ciphers » dans un listener c2s et la directive « s2s_ciphers » pour la liste à utiliser lors des communications s2s (entre deux serveurs XMPP). On peut utiliser une liste plus robuste comme celles que je donne à l'adresse suivante : http://shaarli.guiguishow.info/?YddWtQ . Exemple : « ciphers: "EDH+aRSA EECDH+aRSA aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4 !SEED !CAMELLIA" »

        Attention : il y a un comportement totalement incompréhensible : « ciphers » devrait agir uniquement sur la connexion entre mon client XMPP et mon serveur. Or, si je sélectionne uniquement des suites cryptos supportant la confidentialité persistante (parce que je sais que mon client, Gajim, supporte les algos PFS), booom, la plupart de mes contacts deviennent injoignables (remote-server-not-found). Une capture réseau côté serveur montre que mon serveur initie des connexions mais que les négociations TLS échouent et les connexions sont clôturées. Aucun problème avec les contacts qui utilisent, comme moi, un ejabberd et un gajim venant de Jessie ET (et c'est important), qui ont défini une liste de suites cryptos moins moisie que celle par défaut dans leur config ejabberd. Aucun problème si, dans ma config ejabberd, je mets uniquement des suites cryptos PFS dans s2s_ciphers et des suites PFS mais pas seulement dans ciphers... Oui, ça n'a aucun sens, il y a clairement un os quelque part...


    * On a également à notre disposition la directive de configuration « protocol_options » (et son amie « s2s_protocol_options » ;) ) qui va nous permettre de virer SSLv3 et de forcer les clients à respecter l'ordre du serveur dans le choix de la suite cryptographique à utiliser. Les autres options possibles sont consultables à l'adresse suivante : https://github.com/processone/tls/blob/master/c_src/options.h (oui, code is doc, certainement :S ). Ça donne donc ceci :
      « s2s_protocol_options:
          - "no_sslv2"
          - "no_sslv3"
          - "cipher_server_preference" »

     Et « protocol_options:
            - "no_sslv2"
            - "no_sslv3"
            - "cipher_server_preference" »

    * On n'oublie pas de préciser « starttls_required: true » dans le listener c2s. Ça évite que la communication passe en clair si, pour X raisons (bug, attaque par repli par un Homme du Milieu), la négociation TLS échoue. Je rappelle que sur la connexion c2s, il y a votre roster (liste de contacts) qui passe + l'état de vos contacts (absent puis disponible puis absent puis déconnecté,... ;) ) +  le contenu des communications par la suite. Vous devriez également préciser « s2s_use_starttls: required » mais là, ça dépend des serveurs de vos contacts... Google ne supporte pas TLS par exemple donc si vous faites ça, vous vous privez de parler à ces personnes-là. :(

    * Par défaut, ejabberd génère des paramètres de Diffie-Hellman de 1024 bits ce qui est clairement trop faible de nos jours (logjam tout ça, voir http://shaarli.guiguishow.info/?S2CJMg ). On peut générer des dhparam plus robustes (voir apache httpd ci-dessus) et les utiliser avec les directives de config « dhfile » et « s2s_dhfile» (voir https://blog.process-one.net/securing-ejabberd-against-logjam-attacks-and-future-threats/ ) mais... ces directives de configuration arrivent avec la version 15.06 alors que nous avons la 14.07 dans Debian Jessie. :( Upgrader la lib erlang-p1-tls (qui apporte les fonctionnalités TLS) indépendamment ne sert à rien. On peut utiliser la version (de ejabberd ET de erlang-p1-tls) présente dans les backports mais ça sera sans moi : la team security de Debian ne s'occupe pas des backports donc pas question sur un serveur.

    * Enfin, cette nouvelle version d'ejabberd, de par les options précédentes, re-ouvre les portes de MUC (discussion à plusieurs sur XMPP, voir http://shaarli.guiguishow.info/?fBKCuA) sur des serveurs configurés un peu durement niveau crypto comme jabber.ccc.de. \o/

En mettant à jour de Wheezy à Jessie, quelques problèmes sont apparus avec ejabberd :
    * Le serveur refusait d'être lancé avec un joli message dans les logs :
      « <0.38.0>@gen_mod:start_module:90 Problem starting the module mod_admin_extra for host <<"guigui.example">>
        options: []
        error: undef
       [{mod_admin_extra,start,[<<"guigui.exemple">>,[]],[]},
        {gen_mod,start_module,3,[{file,"src/gen_mod.erl"},{line,82}]},
        {lists,foreach,2,[{file,"lists.erl"},{line,1336}]},
        {ejabberd_app,start,2,[{file,"src/ejabberd_app.erl"},{line,67}]},
        {application_master,start_it_old,4,
                     [{file,"application_master.erl"},{line,272}]}]
        2016-01-03 16:10:49.411 [critical] <0.38.0>@gen_mod:start_module:95 ejabberd initialization was aborted because a module start failed.

     Cela vient du fait que j'ai conservé mon ancienne configuration, qui charge le module « mod_admin_extra » qui a été déplacé dans ejabberd-contrib (https://github.com/processone/ejabberd-contrib), voir https://www.ejabberd.im/node/24787 . Il faut donc installer le package ejabberd-contrib ou virer mod_admin_extra de la configuration ejabberd. Il n'est pas présent dans le fichier de conf' par défaut de Jessie donc on peut vivre sans. :D


    * Par défaut, ejabberd utilise désormais une syntaxe yaml pour son fichier de configuration. C'est toujours mieux que le format erlang. \o/ On peut convertir son ancien fichier de conf' à la nouvelle syntaxe avec « ejabberctl convert_to_yaml /etc/ejabberd/ejabberd.cfg /etc/ejabberd/ejabberd-converted.yml ». J'ai rencontré deux problèmes :
        * « Error: eacces ». Cela signifie que l'utilisateur ejabberd n'a pas le droit d'écrire dans le dossier de destination. Une impossibilité de lire le fichier source se manifeste par « Problem 'exit "Problem loading ejabberd config file /tmp/ejabberd.cfg : permission denied"' occurred executing the command. »

        * « Problem 'error function_clause' occurred executing the command.
            Stacktrace: [{p1_yaml,encode_pair,
                      [inet6,4],
                      [{file,"src/p1_yaml.erl"},{line,117}]},
             {p1_yaml,'-encode/2-lc$^0/1-1-',2,
                      [{file,"src/p1_yaml.erl"},{line,98}]},
             {p1_yaml,'-encode/2-lc$^0/1-1-',2,
                      [{file,"src/p1_yaml.erl"},{line,98}]},
             {p1_yaml,'-encode/2-lc$^1/1-0-',2,
                      [{file,"src/p1_yaml.erl"},{line,100}]},
             {p1_yaml,encode_pair,2,[{file,"src/p1_yaml.erl"},{line,118}]},
             {p1_yaml,'-encode/2-lc$^0/1-1-',2,
                      [{file,"src/p1_yaml.erl"},{line,98}]},
             {p1_yaml,'-encode/2-lc$^0/1-1-',2,
                      [{file,"src/p1_yaml.erl"},{line,98}]},
             {p1_yaml,encode,1,[{file,"src/p1_yaml.erl"},{line,90}]}] »

         Le parser ne gère pas le mot-clé « inet6 » que l'on utilise dans le fichier de configuration pour faire écouter ejabberd en IPv6 (et aussi en IPv4 en fonction de bindv6only ;) ). C'est un bug connu et corrigé (voir https://github.com/processone/ejabberd/issues/803 ) mais ce n'est pas dans Jessie ni encore dans les backports. IPv6 c'est pour demain qu'ils disent... Deux méthodes :
            * Si votre fichier de configuration n'est pas trop spécifique / poilu, je vous recommande de prendre le modèle yml fourni par défaut et de le re-remplir à votre convenance (genre domain, certificat x509,...). Pas seulement pour éviter ce bug de parse ou le déplacement de mod_admin_extra mais aussi pour conserver les commentaires explicatifs de ce que fait chaque directive de config' et, enfin, pour éviter d'autres galères...

            * Mettre les « inet6 » en commentaire dans les blocs listen de votre ejabberd.cfg puis convertir le fichier puis corriger le fichier généré en ajoutant « ip: "::" » à chaque listener car sinon ejabberd écoute uniquement en IPv4...

Avec SNMP, il est possible d'exposer tout ou partie de l'arborescence soit selon le modèle "expose uniquement telle partie" soit selon le modèle "expose tout sauf cette partie". C'est le principe des vues.

Prenons un cas concret : Zabbix ne sait pas interpréter les valeurs qu'il remonte concernant la shared memory dont la taille varie (à la hausse comme à la baisse) en fonction des besoins jusqu'à attendre le maximum défini par kernel.shmall dont on peut positionner la valeur avec sysctl. Cette mal-interprétation génère des fausses alertes qui, en plus d'être pénibles, habituent les techs à ne plus prêter attention aux mails émis par la supervision ce qui représente la pire situation possible.

Plutôt que de trifouiller SNMP, est-ce qu'on ne pourrait pas demander à Zabbix d'exclure la shared memory ? Zabbix la découvre tout seul, avec un discovery et tout le bazar... Il faudrait créer un filtre et tout et tout, voir https://www.zabbix.com/documentation/2.4/manual/discovery/low_level_discovery point 3.1 . Ce n'est pas fun à mes yeux et pour une fois que j'avais un alibi pour creuser la syntaxe d'un fichier snmpd... Bon ça va, ok, je le reconnais : en vrai, je suis maso. :P

Cet exemple est bateau mais le masquage d'une partie ou de l'intégralité de l'arborescence SNMP peut servir (exemple parmi d'autres : générer un graphe de débit pour une seule interface réseau pour que seul l'utilisateur branché sur cette interface puisse consulter ce graphe, voir http://net-snmp.sourceforge.net/wiki/index.php/Vacm#VACM_Masks.2C_or_How_to_restrict_access_to_a_particular_index_.28row.29_in_a_Table) donc ce n'est pas inintéressant de se pencher sur ça.

Dans l'arborescence SNMP, c'est le tableau nommé « hrStorageTable » qui contient, entre autres, la description, la taille d'une allocation, le nombre total d'allocations possibles et le nombre d'allocations réalisées de chaque espace logique de stockage (RAM, shared memory, points de montage,...). Voir http://www.net-snmp.org/docs/mibs/host.html#hrStorageTable . Donc pour récupérer les tailles exprimées sous la forme qu'on leur connaît (Mio, Gio, Tio,...), il faut multiplier le bon nombre d'allocations par la taille d'une allocation. Exemple : espace occupé sur le stockage en octets = taille d'une allocation * nombre d'allocations réalisées. #IZI

L'OID (l'identifiant unique d'un élément dans l'arborescence SNMP) de ce tableau hrStorageTable est .1.3.6.1.2.1.25.2.3 (ou HOST-RESOURCES-MIB::hrStorageTable en langage presque courant...). Ensuite, on met la colonne à laquelle on souhaite accéder : .1.3.6.1.2.1.25.2.3.1.3 = HOST-RESOURCES-MIB::hrStorageTable.1.3 = description de tous les points de montage, .1.3.6.1.2.1.25.2.3.1.6 = HOST-RESOURCES-MIB::hrStorageTable.1.6 nombre d'allocations utilisées,... Ensuite, on met l'ID du stockage : dans mon cas .1.3.6.1.2.1.25.2.3.1.3.1 = HOST-RESOURCES-MIB::hrStorageTable.1.3.1 = nom donné à ma RAM, .1.3.6.1.2.1.25.2.3.1.3.31 = nom donné à la racine (/),...

Les ID / descriptions ne se devinent pas, on les remonte avec : snmpwalk -v2c -c <communauté> <IP_agent_SNMP> HOST-RESOURCES-MIB::hrStorageTable.1.3 :)

La shared memory a l'ID 8. Ce que nous voulons faire c'est donc dégager tout ce qui concerne .1.3.6.1.2.1.25.2.3.1.X.8. Peu importe la valeur de X puisque l'on veut virer la description, l'ID, la taille d'une allocation, les allocations effectuées,... Bref, nous voulons faire disparaître toute information sur l'objet d'ID 8 de la table hrStorageTable.

On a l'OID : .1.3.6.1.2.1.25.2.3.1.X.8, il reste à calculer le masque. Cet OID nécessite 12 bits pour être représenté (ne faites pas attention aux nombres > 1, c'pas comme ça qu'on compte :D ). Il nous faudra donc deux octets, c'est plié d'avance.

Mettons un 1 sous chaque élément de l'OID que l'on souhaite invariant. Et mettons 0 sous chaque partie variante. Dit de manière plus simple : on met un 1 en dessus de chaque élément de l'OID que l'on veut matcher dans la requête SNMP qui sera adressée au serveur. Nous voulons matcher tous les bits sauf le 11e, peu importe ce que contient ce dernier.

OID :        .1.3.6.1.2.1.25.2.3.1.X.8
Masque :  1 1 1 1 1 1  1  1 1 1 0 1 0 0 0 0
On regroupe les bits en paquets de 8 (pour faire des octets) et on convertit en hexadécimal : 1 1 1 1 1 1 1 1 = ff ; 1 1 0 1 0 0 0 0 = d0 . Masque final : ff:d0 \o/
On a donc tout pour créer notre vue : « view    <label>     excluded        .1.3.6.1.2.1.25.2.3.1.3.8       ff:d0 ».

Ici, on dit donc que l'on exclut la ligne d'ID 8 dans la table hrStorageTable, peu importe la colonne. #IZI

Si l'on remplaçait le masque par ff:f0, on dirait que seulement l'OID .1.3.6.1.2.1.25.2.3.1.3.8 doit être exclu. On exclurait donc uniquement la description de la shared memory mais on pourrait toujours récupérer la taille d'une allocation en .1.3.6.1.2.1.25.2.3.1.4.8, par exemple. #IZI

Si l'on remplaçait « excluded » par « included », on dirait bien que seul .1.3.6.1.2.1.25.2.3.1.X.8 peut être lu. On pourrait donc récupérer uniquement les infos sur la shared memory. Et si on remplaçait « excluded » par « included » et le masque par ff:f0, alors on autoriserait uniquement la consultation de la description de la shared memory. #IZI

Mais avant de dire ce que l'on exclu, il faudrait peut-être dire ce que l'on inclu ? Car exclure quelque chose du néant, ça va pas être possible. Voici donc la vue finale :
« view    <label>     included        .iso
  view    <label>     excluded        .1.3.6.1.2.1.25.2.3.1.3.8       ff:d0 »
On inclus tout l'arbre SNMP et on dégage la ligne de la table hrStorageTable qui concerne la shared memory.


Maintenant, il faut écrire le fichier de configuration de snmpd kiVaBien. La page pointée par ce shaarli n'est plus vraiment appropriée, je lui préfère https://aresu.dsi.cnrs.fr/spip.php?article175 que j'ai shaarlié y'a quelque temps en http://shaarli.guiguishow.info/?t_NB6w.

Pour simplifier, je vais développer un exemple complet :
« ## Listen
agentAddress udp:161,udp6:161


## Qui suis-je ?
# snmpd remplit le sysName tout seul avec le FQDN de la machine
sysLocation Internet
sysContact guigui@example.com


## Qui voit quoi ?
# Déclaration des machines autorisées
# Se lit comme : les machines avec les IP 192.0.2.1 et 127.0.0.1, qui viennent nous causer
# en positionnant la communauté à la valeur « zabbix » font partie de la comsec nommée « supervision »
#                   Nom             Source          Communauté
com2sec supervision     127.0.0.1       zabbix
com2sec supervision     192.0.2.1       zabbix

# Déclaration des groupes d'accès
# Les machines de la comsec supervision font partie du groupe nommé « ReadOnly » (ce n'est qu'un label,
# pas une permission effective !) qu'ils utilisent SNMP version 1 ou 2c
#             Nom             Version         Com2sec
group   ReadOnly        v2c            supervision
group   ReadOnly        v1              supervision

# Déclaration des vues
# La vue NoSharedMem masque HOST-RESOURCES-MIB::hrStorageTable.hrStorageEntry.X.8
# Donc on vire les infos à propos de la shared memory que Zabbix ne sait pas interpréter
#                    Nom             Incl/Excl                      Subtree                         Masque (optionnel)
view    NoSharedMem     included        .iso
view    NoSharedMem     excluded       .1.3.6.1.2.1.25.2.3.1.3.8           ff:d0

# Association entre un groupe et une vue
# Le groupe ReadOnly est associé a la vue NoSharedMem en lecture seule
#           GroupName       Contexte    Version      SecLevel        Prefix               Read            Write   Notif
access  ReadOnly               ""              any             noauth          exact       NoSharedMem     none    none


##  Params divers
# To keep "snmpd[3458]: Connection from UDP: [127.0.0.1]:48911" from filling your logs
dontLogTCPWrappersConnects true »


Notons que, sans la vue, une configuration snmpd qui autorise les mêmes deux machines à lire toute l'arborescence sans aucun droit d'écriture, ça se dit : « rocommunity zabbix 89.234.141.72/32 ». On voit donc que les vues sont complexes et pas toujours appropriées. :)

Il ne reste plus qu'à déployer ce fichier de configuration avec Puppet^WAnsible ou autre selon vos goûts. :)

Sur mon serveur perso, je chroote Apache httpd depuis 3 ans et demi pour essayer mais ça cause tout un tas de problèmes pour un gain en sécurité pas évident du tout... Tant qu'à faire, voici quelques problèmes dont je me souviens et que je n'ai pas encore documenté :
    * Il fallait quand même créer les dossiers correspondants au DocumentRoot de chaque virtualhosts dans /var/www (ou autre chemin si vous l'avez changé...) sinon erreur au démarrage. Ça ne semble plus être nécessaire de nos jours.

    * Il faut charger explicitement les librairies utilisables. Genre si l'on a besoin d'une résolution de noms, il faut copier /etc/resolv.conf dans le chroot (au même emplacement, ofc) et ajouter ceci à la conf' Apache : « LoadFile /lib/x86_64-linux-gnu/libnss_dns.so.2 » sinon plus de résolution des noms et ces messages dans les logs :
    « PHP Warning:  file_get_contents(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /var/www/[...] on line 3
      PHP Warning:  file_get_contents([...]): failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known in /var/www/[...] on line 3 »

    * Il faut copier /usr/share/zoneinfo et son contenu dans le chroot sinon PHP se vautrera dès qu'une fonction relative au temps/date sera utilisée. Exemples : « PHP Fatal error:  date_default_timezone_get(): Timezone database is corrupt - this should *never* happen! », «  PHP Fatal error:  strtotime(): Timezone database is corrupt - this should *never* happen! », « PHP Warning:  strtotime(): Invalid date.timezone value 'Europe/Paris', we selected the timezone 'UTC' for now. », « PHP Warning:  date_default_timezone_get(): Invalid date.timezone value 'Europe/Paris', we selected the timezone 'UTC' for now. ».

    * Problème de suppression des fichiers de session (stockés dans session.save_path). PHP n'a pas de mécanisme pour supprimer automagiquement ces fichiers. Sous Debian GNU/Linux, c'est stocké dans /tmp qui est souvent un tmpfs qui se vide donc à chaque extinction du serveur. De plus, un script, /usr/lib/php5/sessionclean est exécuté en cron toutes les 30 minutes. Problème : ce script récupère bien le chemin où sont stockés les fichiers... mais sans tenir compte du chroot. Ainsi « session.save_path = /tmp » dans le php.ini d'un PHP exécuté dans un chroot Apache httpd ne désigne pas /tmp mais $chrootdir/tmp (/var/apache/chroot/tmp dans mon cas puis chrootdir = /var/apache/chroot). Mon workaround :
        * Dupliquer /usr/lib/php5/sessionclean en /usr/local/lib/php5-sessionclean ;

        * Définir moi-même $save_path en commentant save_path=$(echo [...]) et en le remplaçant par « save_path=/var/apache/chroot/tmp »

        * Dupliquer /etc/cron.d/php5 en /etc/cron.d/php5-custom dans lequel j'appelle /usr/local/lib/php5-sessionclean au lieu de /usr/lib/php5/sessionclean

        * systemctl restart cron pour prendre en compte cette modification

    * Problème avec la validation des certificats x509. Voir http://shaarli.guiguishow.info/?lWsIvQ

    * Les sockets UNIX deviennent compliquées à utiliser pour communiquer avec les SGBD. On doit donc utiliser des sockets TCP... C'est déjà le cas par défaut donc ça n'entraîne pas de contraintes supplémentaires.

« Dec 26 17:54:17 localhost postfix/smtpd[16304]: warning: SASL authentication failure: Internal Error -4 in ../../lib/server.c near line 1757
Dec 26 17:54:17 localhost postfix/smtpd[16304]: warning: SASL authentication failure: Internal Error -4 in ../../lib/server.c near line 1757
Dec 26 17:54:17 localhost postfix/smtpd[16304]: warning: SASL authentication failure: Internal Error -4 in ../../lib/server.c near line 1757
Dec 26 17:54:17 localhost postfix/smtpd[16304]: warning: xsasl_cyrus_server_get_mechanism_list: no mechanism available
Dec 26 17:54:18 localhost postfix/smtpd[16304]: fatal: no SASL authentication mechanisms
Dec 26 17:54:18 localhost postfix/master[5159]: warning: process /usr/lib/postfix/smtpd pid 16304 exit status 1
Dec 26 17:54:18 localhost postfix/master[5159]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling »

Et 1 an et demi après, je me réponds à moi-même : il faut installer le package libsasl2-modules...

Voici ce que contient le composant « rpi » des dépôts Debian Raspbian. Soit 3 logiciels : gstreamer1.0-omx, gstreamer1.0-omx-dbg et ssh-regen-startup. Si aucun de ces logiciels est installé sur votre Raspberry Pi, vous pouvez supprimer le composant rpi de votre sources.list.

Ça signifie aussi que les packages bricolés de partout par les mainteneurs Raspbian sont injectés directement dans le composant « main ».... C'est plutôt contestable. Mais ce n'est pas un scoop, voir http://www.guiguishow.info/2013/09/07/auto-hebergement-sur-olinuxino/#toc-4076-technique . D'où ma préférence pour les OLinuXino : ça utilise les dépôts Debian standard donc on bénéficie du support de la team Debian-Security et de sa réactivité (alors que les màj, même de sécu, sont décalées de plusieurs jours chez Raspbian).

L'interface web de Sympa m'affiche cette erreur lorsque je consulte les archives publiques d'une liste, après avoir confirmé que je ne suis pas un spammeur... On ne trouve rien sur un moteur de recherche à part des SYmpa dans le même état que le mien... Si quelqu'un a la solution, qu'il fasse signe.

Une liste des changements qui m'ont affecté lors du passage de Wheezy à Jessie et donc d'Apache httpd 2.2 à Apache 2.4 :

    * « NameVirtualHost has no effect and will be removed in the next release » : « La directive NameVirtualHost n'a plus aucun effet, si ce n'est l'émission d'un avertissement. Toute combinaison adresse/port apparaissant dans plusieurs serveurs virtuels est traitée implicitement comme un serveur virtuel basé sur le nom. ». J'ai donc simplement supprimée cette directive de configuration. Ça signifie également que la création de plusieurs VirtualHost TLS (reposant sur SNI) fonctionne désormais out-of-box ce qui représente un beau progrès.

    * « Invalid command 'LockFile', perhaps misspelled or defined by a module not included in the server configuration » : « Les directives AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la directive unique Mutex. ». Voir https://askubuntu.com/questions/368515/upgraded-to-ubuntu-13-10-apache-not-able-to-start pour une directive de configuration de remplacement. Notons que c'est bien la même qui a été retenu dans la conf' par défaut chez Debian.

    * « Ignoring deprecated use of DefaultType in line NN of /path/to/httpd.conf - supprimez la directive DefaultType et remplacez-la par les directives de configuration appropriées. ». Cette ligne a simplement été supprimée de la config' par défaut chez Debian. J'en ai fait autant.

    * Chez Debian et Ubuntu, le nom des fichiers contenant les différents VirtualHosts doit terminer par « .conf » sinon ils sont ignorés, voir https://www.linode.com/docs/security/upgrading/updating-virtual-host-settings-from-apache-2-2-to-apache-2-4 . Il faut donc :
        * rm /etc/apache2/sites-enabled/*
        * cd /etc/apache2/sites-available
        * for vhost in `ls`; do mv $vhost $vhost.conf; sudo a2ensite $vhost; done;
        * systemctl reload apache2

    * « Either all Options must start with + or -, or no Option may. ». En effet, j'avais des « SymLinksIfOwnerMatch » qui n'ont jamais posés de problèmes... Il suffit donc d'ajouter un « + » devant pour confirmer qu'on veut bien activer cette option. Voir https://serverfault.com/questions/647665/either-all-options-must-start-with-or-or-no-option-may

    * Le mécanisme de contrôle d'accès change. Pour l'instant, la compatibilité est assurée mais il vaut bien se préparer en avance :
        * « Order deny,allow Deny from all » devient « Require all denied »

        * « Order allow,deny Allow from all » devient « Require all granted »

        * « Order Deny,Allow Deny from all Allow from <IP> » (très utile pour faire une maintenance peinard ;) ) devient « Require all denied Require ip <IP> »

        * « Order Allow,Deny Deny from <IP> Allow from all » (très utile contre les pénibles ;) ) devient
        « <RequireAll>
                Require all granted
                Require not ip <IP>
          </RequireAll>
    Voir https://httpd.apache.org/docs/2.4/fr/howto/access.html

Chez ARN, FAI associatif en Alsace, nos machines ont une BMC c'est-à-dire un contrôleur permettant le management à distance (accès console, reboot, monitoring bas niveau,...) de la bécane (voir https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller).

La BMC de notre HP, un truc ILO 2 est perfectible : elle peut continuer à ping mais ne plus présenter son interface web... et devenir ainsi inutile. Impossible de reboot uniquement la BMC depuis le serveur lui-même (ipmitool bmc reset cold, voir https://serverfault.com/questions/205658/restarting-an-ibm-bmc-without-restarting-the-server-itself) dans ces moments-là : ça ne juste fonctionne pas. Le seul moyen est de rebooter totalement (éteindre + couper les arrivées électriques) la machine. Pas cool de découvrir ça quand on a besoin de la BMC car on a foiré un truc...

On a donc mis en place un monitoring HTTP en plus du monitoring ICMP des BMC. Aucun problème sur notre Dell iDRAC... Problème sur notre ILO 2, bien entendu : le check retourne toujours « CRITICAL - Socket timeout after 10 seconds » même si l'on augmente la durée avant timeout. Un navigateur web ne rencontre aucun problème. Problème avec TLS, peut-être ? Non, une capture réseau montre que c'est la même version de TLS et la même suite cryptographique qui sont choisis dans les deux cas (check et navigateur web).

Ce n'est pas la faute de la BMC mais celle du check de monitoring check_http que l'on trouve dans nagios. En effet, ce dernier exécute une requête HTTP 1.1. La BMC répond avec un Content-Type: chunked. La norme HTTP 1.1 *impose* le support de ce content-type donc la BMC n'est pas fautive : le check demande à causer HTTP 1.1 sans savoir parler la langue... Depuis mi-2014 environ (voir https://github.com/monitoring-plugins/monitoring-plugins/pull/1286), check_http sait causer chunked mais visiblement, c'est sacrément buggué (voir https://github.com/nagios-plugins/nagios-plugins/issues/103 par exemple).

Conclusion : on utilise l'argument « -N » de check_http pour lui dire de se concentrer sur les entêtes HTTP uniquement, et non pas sur le contenu envoyé par la BMC. Ainsi, on vérifie quand même que la BMC est fonctionnelle (une connexion HTTP est possible) sans se prendre la tête.

Une histoire de dette technique. Notons que pour l'obsolescence programmée ou pour faire acheter le dernier joujou inutile mais mega cher à la mode, là y'a du monde mais pour la sécurité, y'a plus personne pour faire du gavage d'oies. :))))

« Mozilla a annoncé qu’elle ne supporterait plus les certificats SHA-1 à partir de 1er juillet 2016. Microsoft a également abondé dans le même sens et a fixé le mois de juin 2016 comme date de fin du support de SHA-1 dans son navigateur. Google qui avait fixé la sienne au 1er janvier 2017 est en cours de réflexion afin de voir s’il ne serait pas judicieux de rapprocher la date de fin du support de SHA-1 au 1er juillet 2016 comme Mozilla.


[...]

À l’opposé de ces entreprises qui souhaitent ne plus supporter ce standard le plus tôt possible, nous avons CloudFlare et Facebook qui après avoir évalué l’impact de l’abandon du support de SHA-1, ont les regards tournés dans le sens contraire et encouragent les entreprises à supporter le standard afin de ne pas priver une partie des utilisateurs de la sécurité offerte par cet algorithme de hachage.

Selon l’enquête menée par Cloudflare, 37 millions d’internautes n’ont pas d’équipements compatibles avec SHA-2 et seraient définitivement coupés des pages chiffrées avec cet algorithme de chiffrement dès l’abandon du support SHA-1.

Facebook a produit des statistiques similaires après avoir détecté que « 3-7 % des navigateurs actuellement utilisés ne sont pas en mesure d’utiliser la norme SHA-256 plus récente

[...]

Twitter qui est également concerné par le problème a effectué des tests qui ont permis de démontrer que 3 à 6 % de ses utilisateurs ne pourront pas accéder à sa plateforme à partir de SHA-2.

[...]

Avec cette annonce, les utilisateurs disposant uniquement de support pour SHA-1 peuvent espérer continuer à accéder à ces plateformes après l’abandon du support par certaines entreprises. Toutefois, pour que cette initiative puisse atteindre son objectif, ne serait-il pas intéressant pour d’autres entreprises de suivre le pas ?

En outre, vu que Twitter annonce que le support pour SHA-1 sera abandonné en mars 2019, ne serait-il pas mieux de le faire maintenant ? Par ailleurs, ces entreprises soulignent que le support pour SHA-1 sera abandonné si une attaque se produisait. Devrait-on attendre qu’une telle occurrence survienne avant d’abandonner ce certificat ? Ne serait-il pas mieux d’obliger ces utilisateurs à acquérir d’autres supports compatibles avec SHA-256, au lieu de vouloir leur offrir une sécurité à risques ? »

Via https://twitter.com/aeris22/status/682517278504562689