Le Chaos Communication Congress (CCC) est un rendez-vous incontournable pour les passionnés de technologies, de cybersécurité, de sciences, et de culture hacktiviste. Nous nous sommes rendus à Hambourg pour la 38ᵉ édition du CCC, qui avait pour thème « Illegal Instructions ».

Avec 15 000 participants rassemblés au Centre des Congrès de Hambourg, le 38C3 a proposé un programme foisonnant, couvrant un large spectre de sujets :

• Des présentations techniques approfondies,
• Des conférences axées sur des enjeux politiques ou sociétaux,
• Des explorations artistiques et culturelles,
• Et des interventions scientifiques pointues.

L’événement s’est organisé autour de cinq salles principales : trois gérées directement par l’organisation du CCC (« Saal 1 », « Saal Glitch » et « Saal Zigzag ») et deux nouvelles (« Saal Huff » et « Saal Yell »), dont le contenu a été sélectionné par la communauté. Ces deux dernières salles, plus petites, ont permis d’enrichir encore le programme tout en étant retransmises et enregistrées, avec des traductions simultanées en anglais et en allemand.

Parmi les présentations marquantes, voici notre sélection de temps forts :

• La cérémonie d’ouverture
• Le retour des hackers polonais ayant manipulé des systèmes ferroviaires
• La révélation d’une fuite massive de données chez Volkswagen impliquant 800 000 véhicules électriques et leurs propriétaires (publiée aussi sur bleepingcomputer)
• OMG WTF SSO – A beginner’s guide to SSO (mis)configuration : une exploration des erreurs fréquentes dans la mise en place des solutions d’authentification unique
• io_uring, eBPF, XDP et AF_XDP : une plongée dans les technologies permettant d’optimiser les entrées/sorties
• Le protocole WHOIS : explications sur ce protocole historique et ses évolutions
• we made a globally distributed DNS network for shits and giggles
• 38C3: Infrastructure Review : une vue d’ensemble des chiffres et des coulisses techniques de l’événement.

Au total, c’est plus de 270 conférences à retrouver en vidéo sur media.ccc.de.

Le CCC est aussi un événement social : il offre une occasion unique de rencontrer des personnes d’horizons variés et de s’immerger dans une culture collaborative et bienveillante. Par exemple nous avons eu la chance de participer au sein de https://c3lingo.org/. Nous avons pu interpréter en direct plusieurs présentations en français, renforçant ainsi l’accessibilité du contenu pour les participants non anglophones.

Pour conclure, participer au Chaos Communication Congress c’est assister à des conférences qui diffusent de l’expérience et de nouvelles idées, et c’est s’immerger dans une communauté mondiale de passionnés partageant des connaissances et des valeurs d’inclusion et d’innovation. Une expérience que nous recommandons !

En raison d’une importante faille de sécurité de type « Remote Code Execution », les dumps générés avec mysqldump sous Debian 9/10/11 ne sont plus compatibles avec des mysql non corrigés. En effet, mysqldump ajoute une ligne pour forcer les clients MySQL non corrigés à se stopper :

/*!999999- enable the sandbox mode */

Si vous exportez vos dumps vers des serveurs MySQL non corrigés, vous devrez donc retirer cette ligne (par exemple avec la commande tail +2) pour permettre de restaurer le dump.

Comment savoir si mon mysqldump est concerné ?

Il vous suffit de jouer la commande mysqldump foobarbaz et vous devriez obtenir la ligne /*!999999- enable the sandbox mode */ si votre mysqldump intègre cette « correction ».

Sous Debian 9, 10 et 11, vous devriez être concernés.

Comment savoir si mon client MySQL est corrigé ou non ?

Si vous jouez la commande mysql –sandbox vous ne devriez pas avoir le message mysql: unknown option '--sandbox' sinon c’est que votre client MySQL n’est pas corrigé !

Je suis sous Debian 12, suis-je concerné ?

Pour l’instant (décembre 2024), MySQL n’est pas encore corrigé sous Debian 12 ! L’une des conséquences c’est qu’un dump généré sous Debian 9/10/11 n’est donc pas compatible pour Debian 12 ! Il faut donc retirer la 1ère ligne pour l’instant.

Une version corrigée pour Debian 12 est disponible dans stable-proposed-updates, mais elle est pour l’instant bloquée. Nous espérons qu’elle se débloque bientôt ou alors nous forcerons son utilisation sur nos serveurs infogérés.

mysql –sandbox

Nous vous conseillons d’utiliser l’option –sandbox le plus souvent possible, cela permet de s’assurer qu’aucune commande shell ne peut être injectée par le serveur MySQL.

Plus d’informations sur :

• Explications techniques sur le wiki public d’Evolix
• Article « MariaDB Dump File Compatibility Change » sur mariadb.org

Après Facebook en 2019 et Dropbox en 2020, j’ai fermé mon compte Twitter.

C’est drôle qu’à la fin de mon post sur la fin de mon compte Dropbox je disais « il me reste principalement Instagram et Gmail » en oubliant complètement Twitter.
Je pense qu’à l’époque je considérais Twitter comme acquis et pas du tout problématique. Et depuis l’ouverture de mon compte en 2009 j’avais toujours eu beaucoup de chance (ou une bonne curation) et jamais ressenti de toxicité dans mon fil. Je ne suivais pas de comptes trop populaires, pas de médias mainstream. Tant que j’ai pu, j’ai utilisé un client sans pub ni bullshit d’algorithmes. Twitter a participé activement à mon instruction, à l’élargissement de mes connaissances sociales et techniques, à l’ouverture de mon esprit à des idées nouvelles et progressistes… Il a tenu une des promesses d’Internet.

Depuis le rachat de Twitter par Elon Musk, ses décisions éthiques et techniques désastreuses et enfin le naufrage d’extrême droite qu’il incarne, je ne pouvais plus supporter ça.

En janvier 2024, j’avais décidé de ne plus utiliser Twitter, pour 1 mois (comme un « dry january »), pour voir si j’arrivais à m’en détacher. Le mois s’est transformé en une année pendant laquelle je ne me suis connecté que 2 ou 3 fois. Ça a été un sevrage sans effort ni frustration. Pas de ressenti à la Trainspotting ou d’Arizona Dream pour moi.

Depuis 2019 j’utilise Mastodon sur l’instance interne d’Evolix (on en a aussi une ouverte à tou⋅tes). J’utilise aussi un client sans pub ni bullshit.
Je n’ai pas retrouvé toutes les mêmes personnes, mais j’en ai rencontré d’autres. et pour les grandes lignes je n’ai rien perdu.

J’ai aussi repris l’habitude de consulter des flux RSS de sites, blogs, médias… C’est tellement simple et propre. Ça aussi c’est une des promesses d’Internet qui est tenue.

Il y a quelques jours/semaines, j’ai téléchargé une dernière archive de mes données Twitter/X, et j’ai demandé à fermer mon compte. Je ne me fais pas d’idée, je ne pense pas qu’ils suppriment les données, mais je n’y suis plus.

Il paraît qu’il y a un risque de squatting sur les comptes fermés. Je n’ai pas trop pensé à ça (alors que j’y avais pensé en quittant Wordpress). On verra bien.

Il existe plusieurs guides en lignes pour arriver à un résultat similaire (voir en bas d’article), mais chaque cas étant un peu particulier j’ai choisi de faire un retour sur le mien.

Je vais probablement écrire des bêtises ou montrer que j’ai fait des choses un peu débiles, mais je suis sûr que vous me les pointerez avec bienveillance.

Depuis les débuts de l’ADSL en France, je suis chez Free. Tout n’est pas parfait, mais j’ai toujours eu plus de raisons de rester que de partir.

J’ai la Freebox v6 « Revolution » depuis sa sortie en 2010/2011. Pendant longtemps j’ai utilisé la multitude de services : Wifi, UPnP/DLNA, passerelle DECT, stockage/seedbox, player TV/DVD/…
À une certaine période, à chaque orage je perdais ma Freebox (probablement à cause d’installations communes mal isolées) et j’ai sérieusement songé à quitter Free. Ils ne sont pas responsables des orages ni des défauts d’isolation de l’ADSL, mais l’électronique de la Freebox est notoirement peu résistante aux surtensions venant du réseau téléphonique.
J’ai donc petit-à-petit réduit ma dépendance aux services proposés, jusqu’à avoir un “vrai” routeur ainsi qu’un réseau Wifi et un système multimédia indépendants. Je n’utilise plus le DECT (plus de fixe à la maison). Par contre j’utilise encore la passerelle VoIP interne avec mon alarme qui est branchée en RJ11 sur la Freebox Server.

Je ne sais pas pourquoi mais j’ai toujours cru que passer ma Freebox Server en mode “bridge” (au lieu de “routeur”) allait me désactiver Freebox Player et la passerelle VoIP. C’est pourquoi je restais en mode “routeur” avec un double-NAT.

Aussi, mon ADSL s’est fortement dégradé dans le temps. Alors que je suis à 500m du DSLAM, mon débit max en upload s’était réduit d’environ 1 Mo/s à 450 ko/s ces derniers mois.
Très récemment (en septembre), j’ai découvert par hasard que j’étais éligible à un raccordement à la fibre optique depuis un certain temps, mais Orange qui a posé les fibres avait référencé des adresses qui n’existent pas sur le cadastre, donc les outils de tests d’éligibilité me disaient toujours d’arrêter de rêver. Il a fallu que je fouille sur les outils de l’ARCEP pour voir que j’étais éligible.
Ça a été tout un périple – je le raconterai peut-être plus tard – mais je suis raccordé à la fibre depuis début décembre.

Je dois dire d’ailleurs que le service client de Free (et la procédure de transition ADSL/Fibre) a été incroyable. J’étais resté sur des équipes sous-dimensionnées, délocalisées, limites incompétentes… Mais je constate que ça s’est énormément amélioré.

Et qu’est-ce qu’on fait quand on passe à la fibre ? On court tester à quel point ça va vite. Un copain qui héberge un “speedtest” chez lui (chez Free aussi) m’a demandé de tester la liaison entre nos deux connexions. Sauf que les services qu’il héberge ne sont accessibles qu’en IPv6 et par flemme (notamment à cause de l’empilement de routeurs chez moi) je n’avais pas fait en sorte de pouvoir faire de l’IPv6.

Après tant d’années à procrastiner, j’ai voulu faire l’effort et activer l’IPv6. Et une des approches les plus simples était de passer le Freebox Server en mode bridge. J’étais prêt à renoncer complètement au Freebox Player, mais des pages mentionnaient qu’en bidouillant un truc avec un VLAN 100… on pouvait le faire remarcher. Idem pour la passerelle VoIP qui n’était pas listée dans les services désactivés en passant en mode bridge.

Fin du contexte, début de la technique.

Lorsque la Freebox Server passe en mode bridge, elle attribue l’IP publique (probablement par DHCP) à la première machine qui la demande sur son switch ethernet.

En passant dans ce mode, j’ai perdu accès à Internet et au FreeboxOS.

Sur le switch intégré du Freebox Server j’avais aussi une sonde Atlas (86.83% d’uptime depuis avril 2012) en plus du FreePlug et de mon routeur.
Donc soit l’adresse publique a été donnée d’abord à la sonde Atlas au lieu de mon routeur, soit mon routeur n’avait pas encore refait de requête DHCP et il était resté sur son adresse locale.
J’ai eu peur d’avoir fait une belle connerie ; j’ai tout débranché du Freebox Server et rebooté mon routeur. Ça l’a forcé à refaire une requête DHCP et il a donc pris l’adresse publique. Et comme il n’avait rien changé à sa configuration de serveur DHCP, NAT… j’ai retrouvé accès à Internet et au FreeboxOS.

Pour l’accès au FreeboxOS par https://mafreebox.freebox.fr, je n’ai pas en tête le détail exact, mais je suppose que le Freebox Server intercepte les requêtes à 212.27.38.253. En tous cas on ne perd pas l’accès quand on est mode bridge. On peut toujours revenir en arrière… C’est aussi utile pour retrouver l’adresse IPv6 du lien local (pour plus tard).

Au final, j’ai rebranché ma sonde Atlas en aval du routeur et elle remarché directement. Pour le FreePlug, j’y reviens plus tard, mais y’a pas de souci.

Pour la partie IPv6, j’ai suivi des articles à droite et à gauche mais voici en gros ma configuration (valide pour EdgeOS v2.0.9-hotfix.7).

NB : J’ai mis des ****** à la place d’informations spécifiques et sans intérêt.
J’ai mis <IPV6-PREFIX> qui correspond aux 4 premiers “champs” de votre bloc d’IPv6 donné par Free.
Enfin, j’ai mis <FREEBOX-IPV6-LINK-LOCAL> pour la route statique, qui correspond à l’adresse IPv6 locale de votre Freebox Server. On récupère cette information dans FreeboxOS > Paramètres de la Freebox > Mode Avancé > Configuration IPv6 > Général.

firewall {
    all-ping enable
    broadcast-ping disable
    group {
        network-group RFC1918 {
            description "RFC1918 ranges"
            network 10.0.0.0/8
            network 172.16.0.0/12
            network 192.168.0.0/16
        }
    }
    ipv6-name WANv6_IN {
        default-action drop
        description "WAN inbound traffic forwarded to LAN"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related sessions"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
        rule 30 {
            action accept
            description "Allow ICMPv6"
            protocol icmpv6
        }
    }
    ipv6-name WANv6_LOCAL {
        default-action drop
        description "WAN inbound traffic to the router"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related sessions"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
        rule 30 {
            action accept
            description "Allow ICMPv6"
            protocol ipv6-icmp
        }
        rule 40 {
            action accept
            description "Allow DHCPv6"
            destination {
                port 546
            }
            protocol udp
            source {
                port 547
            }
        }
    }
    ipv6-receive-redirects disable
    ipv6-src-route disable
    ip-src-route disable
    log-martians enable
    name IOT_IN {
        default-action accept
        description ""
        rule 1 {
            action accept
            description "Allow established/related"
            log disable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 2 {
            action drop
            description "Drop invalid state"
            log disable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
        rule 3 {
            action drop
            description "Block local access"
            destination {
                group {
                    network-group RFC1918
                }
            }
            log disable
            protocol all
            source {
                group {
                }
            }
        }
    }
    name IOT_LOCAL {
        default-action drop
        description ""
        rule 1 {
            action accept
            description "Allow established/related"
            log disable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 2 {
            action drop
            description "Drop invalid state"
            log disable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
        rule 3 {
            action accept
            description "Allow DNS"
            destination {
                port 53
            }
            log disable
            protocol tcp_udp
        }
        rule 4 {
            action accept
            description "Allow DHCP"
            destination {
                port 67
            }
            log disable
            protocol udp
        }
    }
    name WAN_IN {
        default-action drop
        description "WAN to internal"
        rule 10 {
            action accept
            description "Allow established/related"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    name WAN_LOCAL {
        default-action drop
        description "WAN to router"
        rule 10 {
            action accept
            description "Allow established/related"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    name WAN_OUT {
        default-action accept
        description "router to WAN"
        rule 1 {
            action drop
            description "TV out (ethernet)"
            log enable
            protocol all
            source {
                mac-address ******
            }
        }
        rule 2 {
            action drop
            description "TV out (wifi)"
            log enable
            protocol all
            source {
                mac-address ******
            }
        }
        rule 3 {
            action accept
            description NTP
            destination {
                port 123
            }
            log enable
            protocol udp
        }
    }
    receive-redirects disable
    send-redirects enable
    source-validation disable
    syn-cookies enable
}
interfaces {
    ethernet eth0 {
        address dhcp
        address fe80::1/64
        description Internet
        duplex auto
        firewall {
            in {
                ipv6-name WANv6_IN
                name WAN_IN
            }
            local {
                ipv6-name WANv6_LOCAL
                name WAN_LOCAL
            }
            out {
                name WAN_OUT
            }
        }
        speed auto
    }
    ethernet eth1 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth2 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth3 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth4 {
        description Local
        duplex auto
        poe {
            output off
        }
        speed auto
    }
    loopback lo {
    }
    switch switch0 {
        address 10.10.0.1/24
        address <IPV6-PREFIX>::1/64
        description Local
        ipv6 {
            dup-addr-detect-transmits 1
            router-advert {
                cur-hop-limit 64
                link-mtu 0
                managed-flag false
                max-interval 600
                other-config-flag false
                prefix <IPV6-PREFIX>::/64 {
                    autonomous-flag true
                    on-link-flag true
                    valid-lifetime 2592000
                }
                reachable-time 0
                retrans-timer 0
                send-advert true
            }
        }
        mtu 1500
        switch-port {
            interface eth1 {
            }
            interface eth2 {
            }
            interface eth3 {
            }
            interface eth4 {
            }
            vlan-aware disable
        }
        vif 20 {
            address 10.10.20.1/24
            description IOT
            firewall {
                in {
                    name IOT_IN
                }
                local {
                    name IOT_LOCAL
                }
            }
            mtu 1500
        }
    }
}
protocols {
    static {
        route6 ::/0 {
            next-hop <FREEBOX-IPV6-LINK-LOCAL> {
                description Freebox
                interface eth0
            }
        }
    }
}
service {
    dhcp-server {
        disabled false
        hostfile-update disable
        shared-network-name IOT {
            authoritative disable
            subnet 10.10.20.0/24 {
                default-router 10.10.20.1
                dns-server 10.10.20.1
                lease 86400
                start 10.10.20.2 {
                    stop 10.10.20.254
                }
                static-mapping shellyplugsg3-****** {
                    ip-address 10.10.20.11
                    mac-address ******
                }
            }
        }
        shared-network-name LAN {
            authoritative enable
            subnet 10.10.0.0/24 {
                default-router 10.10.0.1
                dns-server 10.10.0.1
                domain-name ******
                lease 86400
                start 10.10.0.21 {
                    stop 10.10.0.240
                }
                static-mapping TV-ethernet {
                    ip-address 10.10.0.33
                    mac-address ******
                }
                static-mapping TV-wifi {
                    ip-address 10.10.0.48
                    mac-address ******
                }
            }
        }
        static-arp disable
        use-dnsmasq disable
    }
    dns {
        forwarding {
            cache-size 500
            listen-on switch0
            listen-on switch0.20
        }
    }
    gui {
        http-port 80
        https-port 443
        older-ciphers enable
    }
    mdns {
        reflector
    }
    nat {
        rule 5010 {
            description "masquerade for WAN"
            outbound-interface eth0
            type masquerade
        }
    }
    ssh {
        port 22
        protocol-version v2
    }
    unms {
        disable
    }
}
system {
    analytics-handler {
        send-analytics-report true
    }
    crash-handler {
        send-crash-report true
    }
    domain-name ******
    host-name ******
    login {
        user ****** {
            authentication {
                encrypted-password ******
            }
            level admin
        }
    }
    ntp {
        server 0.ubnt.pool.ntp.org {
        }
        server 1.ubnt.pool.ntp.org {
        }
        server 2.ubnt.pool.ntp.org {
        }
        server 3.ubnt.pool.ntp.org {
        }
    }
    offload {
        hwnat enable
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
    time-zone Europe/Paris
}

Je précise tout de même quelques caractéristiques de la configuration de mon routeur :

• J’utilise eth0 pour le WAN et j’ai créé switch0 avec eth1-4 pour le LAN. Je n’utilise pas le PoE sur eth4.
• J’ai une TV connectée (à mon grand regret) à qui je refuse la sortie sur Internet à part pour le NTP (et en écrivant ces lignes je capte que cette règle ne s’applique qu’en IPv4 et pas encore en IPv6).
• J’ai un réseau Wifi spécial pour les objets connectés (car certains doivent accéder à Internet) qui tague les paquets avec le VLAN 20. Ça permet au routeur de les cantonner à un LAN spécial (séparé du LAN principal), tout en les laissant sortir sur Internet. Ça protège contre la latéralisation (depuis un object connecté on ne peut pas voir les ordis/NAS/téléphones/…).
• La plupart de mes appareils (ordis,NAS, téléphones…) ont une IP fixe dans la plage du DHCP, mais j’ai omis ça exprès. Vous n’avez pas besoin de savoir ce qu’il y a chez moi.

Avec cette configuration, j’ai bien de l’IPv6 sortant sans problème.

Il y a par contre un truc étrange ; lorsque je suis en SSH sur le routeur, un ping en IPv6 ne marche pas alors qu’il marche depuis un ordi sur le LAN. Je m’en fiche pas mal mais c’est probablement que j’ai raté quelque chose.

Il reste un détail, le Freebox Player. Même si la plupart du temps j’utilise un autre système multimédia, j’aime savoir que je peux utiliser le lecteur DVD/BluRay du Player.

J’avais noté que selon les Freebox il y avait des astuces pour faire marche le Player quand le Server est en mode bridge. Pour la Freebox « Révolution » il y a une histoire de VLAN 100.
Mais en branchant un câble ethernet (ou les FreePlugs) entre le Freebox Player et le switch intégré du Freebox Server, ça marche directement. Je n’ai eu aucune configuration à faire.
J’ai même essayé de reboot le Freebox Server et le routeur, pour vérifier si l’histoire du DHCP pour l’IP publique n’allait pas casser, mais non, c’est resté fonctionnel.

Je n’ai pas encore fait le test de l’appel sortant par mon alarme. Je brancherai un téléphone à la place pour essayer, mais j’ai toute raison de penser que c’est OK.

Quelques références utiles

• Freebox + routeur Wi-Fi, les différentes options - MAJ 04/2021
• FREE IPV6 sur Ubiquiti Edgerouter-8 Pro… la solution
• Enabling IPv6 Prefix Delegation on AT&T Internet for a Second Firewall (EdgeRouter 4) – Part 2
• IPv6 Firewall Rules (EdgeRouter 4) – Part 3
• Configuring IPv6 on EdgeRouter Lite

Voici le post-mortem d’un incident de délivrabilité vers Microsoft qui s’est produit chez nous à l’été 2024.

À partir du 9 juillet 2024, nous constatons que des spams sont envoyés avec des expéditeurs en @evolix.net vers Microsoft. On s’en rend compte car on reçoit des bounces mais aussi quelques réponses/plaintes d’utilisateurs sur une adresse qui existait bien (la plupart des adresses en @evolix.net utilisées n’existait pas).

Exemple d’un spam envoyé depuis une IP thaïlandaise :

Date: Thu, 11 Jul 2024 12:28:20 +0000
From: Service Plus Affiliate <xxx@evolix.net>
To: xxx@outlook.com
CC: xxx@outlook.com
Subject: Quick Savings Alert: 50% OFF Home Warranty Sale!
Return-Path: xxx@evolix.net
Message-ID: <Exf6vWO9DBgkI4iTvmHxvEhaLe@phvpthsdmaszxsx.evolix.net>

Ces spams sont envoyés par des adresses IPs complètement extérieures à nous, on n’y prête pas tellement attention dans un premier temps.

Les spams se poursuivent sur le même modèle mais en utilisant des expéditeurs en @XXX.evolix.net où l’enregistrement DNS XXX.evolix.net n’existe même pas.

À partir du 17 juillet, plusieurs serveurs remontent des problèmes de délivrabilité vers Microsoft en passant en jaune/rouge dans SNDS.

À partir du 19 juillet, des clients nous remontent des problèmes de délivrabilité vers Microsoft : les emails envoyés passent systématiquement dans la boîte Spam voire disparaissent.

Nous relayons alors les emails impactés par notre service « Zedmel », ce qui corrige une partie des problèmes.

Mais de plus en plus de clients nous remontent ce même problème.

Le 31 juillet 2024, après pas mal d’analyses, on se rend compte que le problème se produit quand on a « evolix.net » visible dans l’email envoyé : HELO, reverse DNS, etc.

Les emails sont bien acceptés par les serveurs SMTP de Microsoft, mais ils obtiennent une « note tueuse » maximale : X-MS-Exchange-Organization-SCL: 9
Ces emails sont alors mis en Spam ou en Quarantaine (suivant la politique des administrateurs Office365) c’est-à-dire invisibles pour le destinataire.

En effet, quand un client n’a pas personnalisé le reverse DNS de son serveur dédié, nous mettons par défaut un enregistrement en XXX.evolix.net

Les serveurs avec des domaines personnalisés ne sont pas impactés.

On se lance donc dans la personnalisation des domaines des serveurs impactés.

Mais en parallèle, les vagues de spams se poursuivent avec @evolix.net ou @XXX.evolix.net

Le 5 août 2024, nous décidons de changer nos enregistrements SPF et DMARC pour « evolix.net« 
pour « forcer » Microsoft à rejeter ces spams et faire cesser le problème à sa source.

Comme nous avons des centaines de serveurs avec des adresses IP de nombreux fournisseurs, et comme nous avons quelques process qui envoient des emails en @evolix.net depuis les serveurs nous avions mis un SPF qui autorise le monde entier :
evolix.net. IN TXT "v=spf1 include:spf.protection.evolix.net +all"
C’est une grosse erreur : SPF est un mécanisme d’autorisation, il ne faut jamais autoriser le monde entier… au pire il vaut mieux ne pas mettre de SPF.
On passe donc notre SPF ainsi :
evolix.net. IN TXT "v=spf1 ptr include:spf.protection.evolix.net ~all"
(le champ « ptr » est déconseillé mais c’est notre seul moyen d’autoriser nos centaines de serveurs éparpillés partout, d’autres gros acteurs comme OVH l’utilisent aussi).
On passe aussi à une politique DMARC plus stricte pour avoir des rejets :
"v=DMARC1;p=reject;sp=reject"

Le 12 août 2024, après avoir finalement fixé les quelques process susceptibles d’envoyer
en @evolix.net vers l’extérieur on passe même le SPF en -all pour être sûr que
Microsoft coupe bien le robinet des spams :
evolix.net. IN TXT "v=spf1 ptr include:spf.protection.evolix.net -all"

Les vagues de spams se sont en fait arrêtées depuis quelques jours déjà.

Le 13 août, on prend contact avec l’équipe Postmaster de Microsoft pour expliquer tout ça et se renseigner jusqu’à quand le blocage de « evolix.net » va durer.
On est habitué à avoir des réponses de leur part, mais dans ce cas nos demandes restent lettre morte.

On les relance à peu près toutes les semaines sans succès.
Pour mémoire, voici les « support request » toujours sans réponse à ce jour :

• Microsoft Support Request 7048679NNN : ouvert le 13 août, 7 relances (dernière le 23 septembre)
• Microsoft Support Request 7050730NNN : ouvert le 6 septembre, 2 relances (dernière le 23 septembre)

En parallèle, durant le mois d’août on s’assure que le problème est bien contourné partout.

Mais on aimerait tout de même que ce blocage chez Microsoft soit réglé.

Dans le merveilleux monde de la réputation des IPs et domaines au niveau SMTP, en général les blocages ne durent pas plus que 30 jours.
Vu que Microsoft ne nous répond pas, nous prenons notre mal en patience et espérons que le blocage disparaîtra début septembre au pire.

Le 6 septembre 2024, le problème est toujours présent et Microsoft ne nous répond toujours pas malgré nos relances.
Nous décidons alors de créer un compte Office365 (gratuit le 1er mois puis quelques euros ensuite) afin de contacter Microsoft en tant que « client ». Nous ouvrons donc le ticket 2409061410002NNN auprès du support niveau 1.
On obtient rapidement une réponse par email et même par téléphone, mais malheureusement cela reste du support de base. Même si l’interlocuteur ne maîtrise pas trop mal SPF/DKIM/DMARC il nous aiguille sur des fausses pistes.

Le 18 septembre 2024, on ouvre un nouveau ticket 2409181420002NNN auprès du support niveau 1.
On obtient également rapidement des réponses par email et par téléphone, mais cela reste basique.
On insiste en demandant que le problème soit escaladé. On nous demande de produire des rapports
à l’aide d’outils Microsoft assez fastidieux mais on persiste.
On répond/relance le 19 septembre, le 23 septembre, le 25 septembre, le 30 septembre,
le 1er octobre, le 4 octobre, le 8 octobre, le 11 octobre…
On nous redemande de recréer des rapports déjà fournis, on nous demande poliment de patienter.

Le 15 octobre 2024 vers 16h, on reçoit un appel téléphonique de Microsoft :
« j’ai escaladé au support niveau 2, puis niveau 3, et ils me disent qu’ils ont enlevé le blocage, ça sera effectif dans 24h maximum »
On a un peu du mal à y croire, on attend de constater le déblocage.

Le 16 octobre au matin, le problème est toujours présent.
Mais à midi, on refait à nouveau un test avec Message-ID contenant « evolix.net » et effectivement : l’email atterrit en INBOX avec une « note tueuse » minimale : X-MS-Exchange-Organization-SCL: 1

On essaye évidemment d’en savoir plus sur la cause, mais on a toujours que le support niveau 1 en interlocuteur, et l’on comprend vite que l’on n’aura pas davantage d’informations.

Conclusion

Une grande partie des messageries est monopolisée par des gros acteurs qu’il est très difficile de contacter. Il faut éviter d’avoir une raison de les contacter, donc il faut mettre des politiques SPF et DMARC strictes pour tous les domaines et sous-domaines que l’on gère. Il faudrait ne pas autoriser les envois d’emails avec des domaines inconnus (par exemple avec postsrsd) et rate-limiter les envois pour les utilisateurs non aguéris ou des applis web publiques (par exemple avec Postwd). Et si vraiment besoin de contacter un gros acteur pour un problème complexe, mieux vaut ouvrir un compte payant et les contacter en tant que client.

Les leçons qu’on en tire :

il ne faut jamais utiliser +all dans un enregistrement SPF, au pire il est préférable de ne pas avoir de SPF…

• il vaut mieux être radical avec des -all en SPF et reject en DMARC afin de détecter au niveau SMTP les problèmes et non pas avoir des emails mis en Spam ou pire « en quarantaine » (invisible pour l’utilisateur final)
• tout enregistrement DNS existant doit avoir du SPF/DMARC, notamment si un domaine ou sous-domaine n’envoie pas d’email, il faut l’indiquer via SPF ("v=spf1 -all") et annoncer une politique DMARC stricte ("v=DMARC1;p=reject;sp=reject")
• on peut analyser finement les entêtes des gros fournisseurs pour comprendre leurs vérifications antispams
• en dernier recours, il faut pouvoir changer les domaines / adresses IP utilisés pour l’envoi
• si un problème de réputation est toujours présent après 30 jours, c’est qu’il y a eu une opération manuelle
• il faut continuer de propager la « bonne parole » pour « run your own mail server » afin de limiter ces monopoles malsains sur la messagerie

Filiale d’Evolix au Canada depuis 2015, Infogérance Evolix Inc propose des services d’hébergement et infogérance de serveurs Linux (Debian) pour le Canada.
Cette implantation au Canada permet de couvrir deux continents et va dans le sens d’une surveillance en 24/7.

Depuis notre arrivée, nous avons eu l’occasion de rencontrer et tisser des liens avec la très sympathique communauté Linuxienne et Pro-Libre du Québec, qui mérite ce petit article.

*** Rencontres Linux Québec : « qu’il vente, qu’il pleuve ou qu’il neige ! »

Depuis 21 ans, Martial Bigras, grand organisateur, et sa fine équipe, organisent des rencontres mensuelles entre les passionnés de Linux et de Logiciels Libres.
Tous les 1er mardis du mois, les participants se rejoignent pour un moment d’échange, que cela soit en présentiel sur Montréal ou à distance sur Big Blue Button.

Servis en français, les Meetups sont ouverts à tous, qu’importe votre région/continent. Malgré l’horaire des rencontres, 17h30/22h30 (heure de l’Est), il n’est pas rare d’y voir quelques participants francophones venant d’autres pays. Les sujets abordés couvrent aussi bien les bonnes pratiques du moment, des sujets d’actualités que des présentations d’outils Libres, le tout dans la bonne humeur et avec une volonté de partager.
Tout le monde est bienvenu qu’importe son niveau, du débutant aux gurus !

« Fun Fact : les Linux Meetups QC sont les plus gros Linux Meetups francophones en Amérique du Nord ! »

*** Chasse au trésor informatique (CTF : Capture The Flag) : 21 septembre 2024

Depuis les 5 dernières années, un CTF est organisé chaque année pour célébrer l’anniversaire des Linux Meetup Qc, cette année, cet évènement aura lieu le 21 septembre 2024 en mode hybride (présentiel et distanciel).
Evolix soutient cette initiative et fera encore partie des sponsors de l’évènement, de nombreux lots seront à gagner, des prix de présence et des récompenses en lien avec le CTF.

Il y aura une infrastructure spéciale en place pour l’occasion. Un grand merci à Dominique Derrier pour avoir travaillé pendant plusieurs mois afin d’inclure de nouveaux défis captivants et à Pascal Gad pour avoir testé au moins 10% des défis .
Certaines questions seront abordables pour tous les passionnés de Linux, d’autres demanderont de la créativité et d’ingénieuses solutions et les dernières feront appel à votre expertise de Guru Linux.
Le but est de découvrir ou redécouvrir de manière ludique des éléments de Linux.

Cette rencontre est gratuite et ouverte à tous, quel que soit votre niveau de compétence en Linux, du débutant à l’expert. Elle rassemble des personnes de diverses professions.

**** Journée internationale des Logiciels Libres

Cette année la journée des Logiciels Libres sera le 21 septembre, une raison supplémentaire de célébrer cette journée en participant au CTF !

**** Prochains évènements où croiser l’équipe d’Evolix de Marseille :
* Mini Debconf à Toulouse : https://wiki.debian.org/DebianEvents/fr/2024/Toulouse

Pour contacter Evolix Canada, en savoir plus sur nos services d’hébergement et infogérance de serveurs sous Debian ou échanger sur les Logiciels Libres, vous pouvez nous écrire sur hello@evolix.ca ou venir nous rencontrer en personne au 4284 De La Roche à Montréal. Café offert !

Nous avons eu le plaisir de participer à la DebConf24 qui s’est tenue à Busan en Corée du Sud. Cet événement, rassemblant plus de trois cents développeurs et contributeurs Debian du monde entier, s’est déroulé dans un cadre aussi chaleureux qu’inspirant, tant sur le plan des échanges que du climat (35ºN avec un climat subtropical humide, autant dire qu’on a eu chaud !).

Une semaine dédiée à la collaboration : DebCamp

Avant le début officiel de la conférence, la semaine du DebCamp nous a permis de nous concentrer sur des travaux en équipe. C’était une opportunité précieuse pour avancer sur des projets spécifiques. Nous avons eu l’occasion de travailler avec Athos Ribeiro sur l’amélioration de notre outillage d’empaquetage pour les librairies PHP. Athos a, en parallèle, posé les bases des tests automatisés (autopkgtest) pour cet outillage, et a entamé le processus pour devenir officiellement Développeur Debian.

De notre côté, nous avons contribué de manière significative avec plus de soixante-dix envois de paquets et l’interaction avec une quarantaine de bogues. Cependant, ces chiffres restent modestes par rapport à l’effort colossal d’empaquetage de homeassistant, initié par Edward Betts et rapidement soutenu par Thomas Goirand ainsi que de nombreux autres contributeurs. Ce projet a vu l’ajout de plusieurs centaines de paquets à Debian, avec un besoin encore plus important à venir.

Points forts de la DebConf24

La semaine de la DebConf a été marquée par une série de présentations et d’ateliers captivants. Voici quelques moments marquants :

• Le nouveau solveur APT : Julian Andreas Klode a présenté les dernières avancées du solveur pour le gestionnaire de paquets APT, en passant par un historique de son développement et en mettant en lumière les nouvelles fonctionnalités .
• Sequoia PGP : une alternative à GnuPG : Justus Winter a partagé ses travaux sur Sequoia, une alternative à GnuPG conforme aux RFC pour gérer OpenPGP. Cette présentation est arrivée à point nommé, juste avant la publication officielle de la RFC 9580, décrivant la dernière version d’OpenPGP (v6).
• Développement du noyau Linux : Helen Koike a animé un atelier où les participants ont pu mettre en place un environnement de développement pour le noyau Linux et proposer des correctifs, certains ayant même vu leur contribution acceptée dans l’heure dans la branche staging du noyau.
• AppArmor et les conteneurs : Leesoo Ahn a détaillé les applications d’AppArmor dans le contexte des conteneurs, offrant une perspective sur la sécurisation des environnements containerisés.
• Mise à jour en direct du noyau Linux : Emmanuel Arias et Santiago Ruano Rincón ont présenté leurs travaux pour permettre l’ajout de correctifs de sécurité au noyau Linux sans nécessiter de redémarrage, une avancée importante pour la disponibilité des systèmes.
• DebConf25 en Bretagne : Enfin, l’équipe bretonne a présenté les lieux de la prochaine DebConf qui se tiendra en juillet 2025, en Bretagne, un événement que nous attendons avec impatience.

Conclusion

Ces deux semaines intenses à Busan, que ce soit lors du DebCamp ou de la DebConf, ont été riches en enseignements, en collaborations fructueuses et en moments mémorables. La Corée du Sud, avec sa culture dynamique et accueillante, nous a offert un cadre exceptionnel pour renforcer les liens au sein de la communauté Debian. Nous revenons avec de nouvelles idées, des collaborations renforcées et une motivation renouvelée pour contribuer à ce projet qui nous passionne tant. Nous sommes impatients de continuer à échanger et à partager sur ces sujets dans les mois à venir, en attendant la DebConf25.