Modifications Pi-Hole

Pour éviter les problème de migration entre la v5 et la v6, voici ce qui a été utile de faire dans mon cas :

1. Suppression du secret pour la page web
   Dans le service retirer :

secrets:
      - 'webpass'

2. Retirer les lignes secrets

secrets:
  webpass:
    file: "./webpass.secret"

3. supprimer les fichiers de base de données de statistique afin d’éviter un docker qui ne boot pas correctement et l’erreur suivante : ERROR: SQLite3: recovered 3 frames from WAL file /etc/pihole/pihole-FTL.db-wal (283)
   pihole-FTL.db
   pihole-FTL.db-shm
   pihole-FTL.db-wal
4. Mettre à jour : docker compose pull && docker compose down -v && docker compose up -d
5. Définir le mot de passe de l’admin web : docker exec -it votre_container pihole setpassword

Exemple d’un docker-compose simple :

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      #- "67:67/udp"
      - "2080:80/tcp"
      #- "2443:443/tcp"
    volumes:
      - '/var/lib/docker/data/pihole/etc-pihole/:/etc/pihole/'
      - '/var/lib/docker/data/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
    environment:
      TZ: 'Europe/Paris'

    restart: unless-stopped

Pour le reste des options docker pour Pi-Hole, référencez vous à mon article précédent, ainsi que la documentation officielle est très bien faite.

Liste d’url de backlist perso

Voici ma list d’url avec leur description :

Et pour copier ces blacklists :

https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts	
https://raw.githubusercontent.com/StevenBlack/hosts/master/extensions/fakenews/hosts
https://v.firebog.net/hosts/static/w3kbl.txt	
https://adaway.org/hosts.txt	
https://raw.githubusercontent.com/anudeepND/blacklist/master/adservers.txt	
https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt	
https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=0&mimetype=plaintext	
https://v.firebog.net/hosts/Easyprivacy.txt	
https://v.firebog.net/hosts/Prigent-Ads.txt	
https://raw.githubusercontent.com/FadeMind/hosts.extras/master/add.2o7Net/hosts	
https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/spy.txt	
https://hostfiles.frogeye.fr/firstparty-trackers-hosts.txt
https://raw.githubusercontent.com/StevenBlack/hosts/master/alternates/gambling/hosts	
https://raw.githubusercontent.com/kevle1/Windows-telemetry-blocklist/master/windowsblock.txt	
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/domains/native.winoffice.txt	
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/domains/native.amazon.txt	
https://raw.githubusercontent.com/lassekongo83/Frellwits-filter-lists/master/Frellwits-Swedish-Hosts-File.txt	
https://v.firebog.net/hosts/AdguardDNS.txt	
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/rpz/tif.mini.txt

Le projet github de mullvad d’où vient quelques listes.

L’article Pi-Hole migration v5 vers v6 est apparu en premier sur Mon linux.

Vous devez installer le plugin platformio sous VScodium (ou VScode si vous tenez aux spyware microsoft), en suivant le guide de Tasmota.

Activé MQTT TLS dans les headers Tasmota

Editer le fichier `user_config_override.h` pour y ajouter les lignes :

// FORCE ADDING TLS SUPPORT
#ifndef USE_MQTT_TLS 
#define USE_MQTT_TLS                             // Use TLS for MQTT connection (+34.5k code, +7.0k mem and +4.8k additional during connection handshake)
#define MQTT_TLS_ENABLED       true              // [SetOption103] Enable TLS mode (requires TLS version)
#endif

Vous pouvez y ajouter sans problème vos autres module dans ce fichier si vous avez besoin d’un support d’écran spécial, d’une sonde spécifique etc.

Pré-remplir les données wifi et MQTT

Si vous comptez avoir pas mal d’esp32 ou esp8266 dans votre domotique, je vous conseille aussi de setter les paramètres MQTT et wifi de votre réseau avec ces paramètres :

// -- Setup your own Wifi settings  ---------------
#undef  STA_SSID1
#define STA_SSID1         "votre wifi"             // [Ssid1] Wifi SSID

#undef  STA_PASS1
#define STA_PASS1         "mot de passe"     // [Password1] Wifi password

// -- Setup your own MQTT settings  ---------------
#undef  MQTT_HOST
#define MQTT_HOST         "votre jeedom ou homeassistant" // [MqttHost]

#undef  MQTT_PORT
#define MQTT_PORT         8883                   // [MqttPort] MQTT port (10123 on CloudMQTT)

#undef  MQTT_USER
#define MQTT_USER         "tasmota"         // [MqttUser] Optional user

#undef  MQTT_PASS
#define MQTT_PASS         "mot de passe mqtt dédié pour vos tasmota"         // [MqttPassword] Optional password

#define MQTT_FULLTOPIC    "ip/room/%topic%/%prefix%/"  // mon exemple d'arborescence

Actuellement, il y a quand même la commande suivante à taper dans la console pour un certificat auto-signé qui est à faire comme expliqué dans l’article sur Tasmota MQTT : « SetOption132 1 »

L’article MQTTS sous Tasmota esp8266 possible ? est apparu en premier sur Mon linux.

Attention au format SVG qui doit être précisément SVG Tiny/Portable Secure 1.2 format (SVG P/S).

Cela se fait via un champ DNS TXT : default._bimi.mondomaine.net
Une valeur simple : v=BIMI1;l=https://votre_domain.tld/xxx/logo.svg;a=;

Une valeur avec un rejet de signature il faut mettre « a=; » explicitement.
Sinon il faut indiqué une signature au format pem.

Pour vérifier que le format du logo est bien correcte, vous pouvez utiliser également mxtoolbox.

Transformer son logo au bon format BIMI

Sur la partie compatibilité du format, je me réfère au site officiel du bimigroup qui conseille d’utiliser un outils de conversion disponible sur… Github d’une personne tiers…

J’ai converti mon logo SVG au format Tiny 1.2 pour ensuite utiliser leur outil windows pour le mettre au format SVG P/S. Autant PowerDMARC me renvoie que cela est valide, autant mxtoolbox me dit que le format ne respecte pas la norme… Je sèche un peu sur cette partie là.

Astuce pour stocker votre logo BIMI

Si vous avez suivis la mise en place du MTA-STS via docker, vous pouvez très bien mettre votre logo svg pour le BIMI sur le serveur nginx contenant votre fichier mta-sts.txt . Vous déplacez votre fichier à la racine de src :

cp mon_logo.svg /etc/docker/mta-sts.monlinux.net/src/logo.svg

Vous testez que le logo est disponible, vous devez avoir un code HTTP 200 :

$ curl -I https://mta-sts.monlinux.net/logo.svg
HTTP/2 200
accept-ranges: bytes
content-type: image/svg+xml
date: Mon, 26 May 2024 22:22:49 GMT
etag: "6638f52d-455b"
last-modified: Mon, 26 May 2024 22:20:13 GMT
server: nginx/1.25.5
content-length: 17755

Ensuite il faut créer le champ DNS suivant : « default._bimi.mondomaine.net » avec la valeur suivante : « v=BIMI1;l=https://mta-sts.mondomaine.net/logo.svg;a=;« 

Conclusion

Une fois le BIMI et le MTA-STS configuré à l’aide de power Dmarc pour la vérification, vous aurez un score honorable :

L’article BIMI pour identifier l’expéditeur mail est apparu en premier sur Mon linux.

Création du fichier mta-sts

La première chose à faire est de récupérer vos champs MX, pour cela :

dig @1.1.1.1 -t mx monlinux.net

Prenez la réponse, ici mta-gw.infomaniak.ch

monlinux.net.           300     IN      MX      5 mta-gw.infomaniak.ch.

Ensuite créer le fichier mta-sts.txt en format UTF8 linux avec les données suivantes, si vous avez plusieurs entrées mx, ajouter autant de ligne « mx: votre-2e-serveur" que nécessaire :

version: STSv1
mode: testing
mx: mta-gw.infomaniak.ch
max_age: 2592000

• la version est actuellement STSv1
• le mode testing permet à des serveurs non encore prêts de communiquer avec vous, il est possible d’être strict en utilisant le mode enforce pour que seuls des serveurs supportant TLS n’échange avec vos serveurs mails
• max_age est le temps en secondes de validité de l’autorisation. Au début partez sur 1h et une fois tout en place, vous pouvez mettre 1jour ou 1 mois si vous ne changez pas vos MX souvent.

Un article complet avec des détail sur dmarcadvisor en parle.

Création du docker

Le plus light étant de faire un container docker sur votre serveur ou votre cluster. Voici un exemple pour un docker simple avec nginx derrière un reverse proxy Traefik. Ce nginx est donc configuré en http étant donné que c’est Traefik qui gère la partie TLS HTTPS.

Créé l’arborescence nécessaire :

mkdir -p mta-sts.monlinux.net/src/.well-known
cd mta-sts.monlinux.net
vim src/.well-known/mta-sts.txt
vim docker-compose.yml

Le contenu du fichier docker-compose.yml :

Suite à mon article sur Traefik, je rappelle que le réseau partagé pour toutes les applications webs externes sont sur proxy-net. Sans cluster, je lui donne un nom et une limite de mémoire et ensuite des règles Traefik avec le resolver let’s encrypt.

version: '3.7'

networks:
  proxy-net:
    external: true

services:
  nginx:
    image: nginx:latest
    mem_limit: 100m
    container_name: mta_sts_monlinux
    networks:
      - proxy-net
    labels:
        - traefik.enable=true
        - "traefik.http.routers.mta_sts_monlinux.rule=Host(`mta-sts.monlinux.net`)"
        - traefik.http.routers.mta_sts_monlinux.tls.certresolver=le
        - traefik.http.routers.mta_sts_monlinux.entrypoints=websecure
        - traefik.frontend.passHostHeader=true
    volumes:
      - ./src:/usr/share/nginx/html
    restart: unless-stopped

Création des noms de domaine

Ne pas oublier de créer le domaine mta-sts.monlinux.net et de faire pointer sur votre Traefik ou autre hébergement web.

Ensuite il faut tester l’accessibilité via curl :

$ curl https://mta-sts.monlinux.net/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mta-gw.infomaniak.ch
max_age: 2592000

Maintenant il faut créer un record DNS de type TXT « _mta-sts.monlinux.net » avec comme valeur la version et un id unique qui s’incrémentera au moment d’un changement de politique. Personnellement je prend le même format que pour les dns, la date et 2 chiffres YYYYMMDDNN. Dans mon cas la valeur sera « v=STSv1;id=2024050601;« 

Vérification du champ mta-sts

Vérifiez que tout est correcte avec votre outil favori. Dans mon cas, j’utilise mxtoolbox. Vous mettrez votre domaine et vous choisissez le type « MTA-STS Lookup« 
Vous aurez droit à un rapport complet sur votre champ dns, le contenu de votre fichier et les vérifications des serveurs MX présents.

Voici l’exemple sur mon domaine :

L’article Se protéger du spoof DNS avec MTA-STS est apparu en premier sur Mon linux.

Deux type de rapports DMARC

• rua : adresse à laquelle envoyer les rapports agrégés de DMARC
• ruf : adresse à laquelle envoyer les rapports d’erreur individuels

Vous devez créer une adresse mail générique pour recevoir les rapports agrégés pour l’analyser avec un outil interne. Souvent du style dmarc_rua@mondomain.tld. Il faut ensuite modifier votre champ DMARC pour lui ajouter des paramètres :

_dmarc.mondomain.tld=v=DMARC1; p=none; rua=mailto:dmarc_rua@mondomain.tld; fo=1

fo=1: Générez un rapport d’échec DMARC si l’un des mécanismes d’authentification sous-jacents (SPF ou DKIM) produit un résultat autre que « pass » aligné. (Recommandé)

Exemple multi-email rua avec le séparateur virgule :

v=DMARC1;p=none;rua=mailto:dmarc_rua@xxx.brussels,mailto:xxxxxxxx@rua.easydmarc.us;ruf=mailto:xxxxxxxx@ruf.easydmarc.us;fo=1

Exemple quarantaine :

v=DMARC1;p=quarantine;rua=mailto:dmarc_rua@xxx.mondomain.tld;fo=1;

Les différents type de paramètres

Plus de détail sur les rapports agrégés

Outils d’analyse Power Dmarc en ligne

J’ai testé l’outil en ligne Power Dmarc, il est gratuit pour un domaine en usage personnel pour 10.000 mails envoyés / mois en envoyant un mail au support très réactif.
En pro, cela démarre à 8$/mois pour <50.000 mails/mois pour 5 domaines, ce qui est honnête comme tarif.

La création du compte est assez complet et vous pouvez vérifier directement que vous avez vous champs SPF, DMARC, DKIM sont correctes.

Notez que le DKIM va prendre un sélecteur « automatiquement », mais pas vraiment… Sauf si vous avez 1,2,etc pour votre sélecteur.

Chez Infomaniak, c’est une date au format international, il faut donc allez la renseigner sous peine d’avoir un « faux » score négatif.

Pour se faire, allez dans Settings > Manage Domains :

Après avoir sélectionné votre domaine, allez mettre le sélecteur manuellement :

Rapport généré depuis easyDmarc

Afin de montrer ce que permet la mise en place des rapports DMARC, vous voyez ici qu’une partie non authentifiée dans le champ SPF est envoyée depuis MailChimp, typiquement le marketing qui avait mis cela en place sans avertir l’IT.

Il faut régulariser cela avant de passer en mode « reject » le champ DMARC sous peine d’avoir ces mails-là bloqués!

Vous voyez également un certains nombre de mail transférés vers gmail ou Infomaniak, vous devez interdire les transfert dans votre serveur de mail ou votre prestataire.

Une fois que vous n’avez plus que des compliants, alors vous pouvez passer le champ DMARC à « v=DMARC1; p=reject; ».

Si vous avez des solutions open-source pour l’analyse des rapports XML, n’hésitez pas à partager, c’est une prochaine étape!

L’article Monitoring de rapport DMARC est apparu en premier sur Mon linux.

SPF

Permet de vérifier qu’un serveur/une IP puisse envoyé des mails pour le domaine en question.

Ce n’est qu’un champ dns à ajouter.

Exemple :

• pour OVH : "v=spf1 include:mx.ovh.com ~all"
• pour Infomaniak : « v=spf1 include:spf.infomaniak.ch include:spf.mailjet.com ~all« 

Il signifie que les paramètres SPF à utiliser sont ceux du domaine « inclus ». Par exemple pour mx.ovh.com :
text = "v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all"

ATTENTION : Le champ SPF à une limite importante, il ne faut pas dépasser les 10 DNS lookups par champ SPF. Bien faire attention également à vos « include » qui peuvent en contenir eux-même également. Vous pouvez le vérifier via mxtool.com. Le code d’erreur « PermError » peut apparaitre dans vos logs si vous dépassez cette limite.

Une très bonne source pour ce champ SPF mais aussi les 2 éléments essentiels suivants, qui sont le minimum à mettre en place.

DKIM

Permet d’authentifier que le message est bien légitime. Pour cela, le serveur mail envoi une signature faite avec sa clé privée. Le serveur client vérifie la signature via la clé publique qui se trouve dans les DNS du domaine qui envoi le mail. Cette sécurité mail permet de s’assurer que le message n’a pas été altéré ou remplacé.

Si vous êtes chez Infomaniak, vous avez tout ce qu’il faut de configuré.

Chez Microsoft, vous deviez générer une clé pour chaque domaine. Dans M365, il faut aller sur https://security.microsoft.com/ > Stratégies et règles > Stratégies de menace > sous Règles – Paramètres d’authentification des e-mails > onglet DKIM

Pour OVH, il y a 3-4ans ce n’était toujours pas d’actualité….

Si vous vous auto-hébergez, il faut générer une paire de clé sur : https://dkimcore.org

Mettre la clé privée dans le serveur mail et la clé publique dans les dns :
Key001._domainkey.mondomaine.tld.=v=DKIM1;p=xxxxxxxxxxx
Selector Key001

publier la clé dans les dns, à faire chez votre registar dns si vous êtes en auto-hébergé ou chez microsoft:

source bien détaillée

Si vous êtres chez Microsoft, je vous conseille aussi d’utiliser leur relay pour envoyés vos mails serveurs et applicatif signé par le DKIM.

DMARC

Champ txt permettant de dire aux serveurs mails distants quoi faire avec les mails incorrectement reçu de leur domaine.
3 possibilités :

• Rejeter (Reject)
• Ne rien faire (none)
• Considérer comme suspect (quarantine) pour que les mails usurpés se mettent dans les spam des destinataire mais ne sont pas supprimé

Exemple de record pour commencer :
_dmarc.mondomain.tld=v=DMARC1; p=none;

_dmarc.mondomain.tld= v=DMARC1; p=quarantine;sp=quarantine

• p: Appliquez cette politique aux e-mails qui échouent au contrôle DMARC. Cette politique peut être définie sur ‘none’ (aucune), ‘quarantine’ (quarantaine) ou ‘reject’ (rejet). ‘none’ est utilisé pour collecter le rapport DMARC et obtenir un aperçu des flux d’e-mails actuels et de leur statut ;
• sp: Cette politique doit être appliquée aux e-mails provenant d’un sous-domaine de ce domaine qui échouent au contrôle DMARC. En utilisant cette balise, les propriétaires de domaine peuvent publier une politique ‘générique’ pour tous les sous-domaines ;

Si votre infrastructure est utilisée et que vous ne savez pas si des personnes de votre entreprise utilise des systèmes de newsletter tel que mailchimp, mailjet, etc ou que vous avez peut-être des serveurs utilisés ailleurs que sur votre infrastructure, je vous conseille de commencer par un « none » ou un « quarantine ».

Vous pourrez ensuite mettre en place du monitoring de rapport DMARC pour voir si tout est ok avant de passé à « reject » comme politique.

Si vous maîtrisez tout, faites quelques tests en « quarantine » durant quelques semaines avant de passer à « reject ».

Vous avez là un bon bagage pour la sécurité mail, et pour aller plus loin, je vous conseille l’article de nextinpact sur le sujet ou microsoft avec méthode d’introduction.

L’article Sécurité mail – SPF DKIM DMARC est apparu en premier sur Mon linux.

Protocole de test

• Une base de données de dump brute de 7Go avec innodb a été utilisée
• Cela tourne sous MySQL 5.7, c’est une veille app comme il en reste beaucoup. Il faudra tester également avec MySQL 8.0.
• VM sous ESXi avec 12 vCPU intel Xeon qui ont 5ans.

Compressions utilisées

La compression de texte se passant mal pour bzip2, je l’ai d’office exclus. J’envisage donc Gzip et XZ. Il y a le monde un seul thread avec :

• Gzip
• XZ

Et multi-thread avec :

• pigz
• pixz

Quand il n’y a plus de gain selon le niveau de compression (pouvant aller de 1 à 9), j’arrête les tests inutiles.

Tableau benchmark compression Mysqldump

Pour Gzip, il n’y a plus de gain de taille après une compression de 7.

Pour XZ, il n’y a plus de gain de taille après un niveau de 5.

Résultats de compression Mysqldump

Le meilleur temps qui ne consomme pas trop de ressources, c’est pigz avec 4 threads et une compression de niveau 3. La compression est très bonne un niveau 7, mais 3% de taille en moins pour 28% de temps en plus, est-ce utile ? Vous savez quoi utilise pour gagner 5,5x l’espace disque en impactant très peu la charge CPU.

Comme vous pouvez le voir, il y a deux options si vous avez besoin d’archiver à long terme beaucoup de données :

• soit vous cherchez la rapidité et avoir un gain important de place par rapport à gzip et vous utiliserez pixz avec un niveau 1 de compression et 2 processus.
• soit vous cherchez une compression importante et vous utiliserez pixz avec un niveau 3 de compression et 5 processus. Un niveau plus haut que 3 ne sert à rien, trop de temps perdu pour un gain minime de compression, comme on peut le voir avec un niveau 5

Si vous avez une architecture master/slave MySQL, je vous conseille de le faire sur votre slave pour éviter les lock tables sur votre master.

J’ai effectué un comparatif également pour les backups compressés d’XtraBackup.

L’article Mysqldump benchmark compression est apparu en premier sur Mon linux.

Avec Everything et Flow Launcher, vous avez le combo gagnant pour une recherche windows rapide et pertinante… Surtout…

Installation

Via winget : winget install Flow-Launcher.Flow-Launcher voidtools.Everything
Via les sites officiels : everything et flow-launcher

Configurer Everything

Désactiver l’indexation de tous les drives

Dans les options d’Everything, allez dans Indexes > NTFS

1. Retirer les automatismes
2. pour chaque volume actuel, décocher Include in database et appliquer

Dans Indexes > Folders :

1. Ajouter vos répertoires de documents, vos nextcloud, vos onedrive
2. Pour chacun d’entre eux, planifier un scan à une heure où le pc est allumé, comme à midi
3. scanner tout

Arrêter la recherche windows indexed

Aller dans Windows Search settings > Advanced Search indexer Settings > Modify et retirez tous les disques, laissez Start Menu histoire de garder quelques chose si Microsoft pousse une mise à jour qui réactiverait l’indexation

Arrêtez le service d’indexation via services.msc

configurer Flow launcher

Au lancement, suivez les instructions

Choisissez une raccourci non utilisé, dans mon cas, ALT+F :

Activer Flow Launcher au démarrage :

Allez dans les settings de Flow Launcher > Plugins Explorer :

Dans l’onglet Everything Settings, indiquez le chemin du bin d’everything : C:\Program Files\Everything\Everything.exe

Dans l’onglet General Setting

• sélectionnez Everything au lieu de Windows Index pour la recherche
• Allez désactiver l’indexation windows si ce n’est déjà fait
• Dans mon cas j’utilise le launcher en priorité pour les recherches de fichiers, donc je veux que les résultats de ce plugin soit en haut de la liste, priorité 5

Enjoy avec ALT+F

L’article Recherche rapide windows avec Everything et Flow Launcher est apparu en premier sur Mon linux.

Explication du prefix dans Tasmota

%prefix%
Tasmota uses 3 prefixes for forming a FullTopic:

• cmnd – prefix to issue commands; ask for status
• stat – reports back status or configuration message
• tele – reports telemetry info at specified intervals

The order of %prefix% and %topic% doesn’t matter, unless you have enabled Auto-discovery for Home Assistant (SetOption19). Enabling this option re-formats the FullTopic to required order.

Using the tokens the following example topics can be made:

• FullTopic %prefix%/%topic%/ default
• FullTopic tasmota/%topic%/%prefix%/
• FullTopic tasmota/bedroom/%topic%/%prefix%/
• FullTopic penthouse/bedroom1/bathroom2/%topic%/%prefix%/
• FullTopic %prefix%/home/cellar/%topic%/

Dans jeedom détection automatique des commandes info avec leur nom via cela dans jmqtt : exemple le nom POWER est pris pour stat/ip/espcam-laser/POWER

Une explication complète de la gestion d’arborescence MQTT pour Tasmota est expliquée sur le site officiel.

Configurer Tasmota pour joindre Mosquitto en MQTTS

Pour configurer MQTTS sur un ESP32 déjà configuré sur votre wifi, vous devez indiquer plusieurs champs dans le menu Configuration > Configure MQTT

• le DNS ou IP de votre serveur MQTT (Jeedom)
• le port MQTTS 8883 (et pas MQTT 1883)
• Cocher la case « MQTT TLS »
• laisser le client
• Indiqué l’utilisateur / mot de passe que vous avez configuré dans Mosquitto
• Indiquez le Topic, un nom reconnaissable
• Pour le Full Topic, veuillez à bien utiliser %topic% et %prefix%, je vous donne un exemple suivant mon arborescence protocole/piece/nom/#

Une fois sauvegardé, vos allez voir dans la Console que votre ESP32 ne peut joindre votre serveur Mosquitto. C’est normal : de base Tasmota ne fait confiance qu’aux certificats d’autorité de certification (CA) et pas aux certificats auto-signé. Plus d’informations dans la documentation.

Il est prévu dans Tasmota de faire confiance la première fois uniquement à un certificat auto-signé. Si celui-ci change par la suite, Tasmota refusera de s’y connecter! Très pratique dans notre cas, car toujours faire confiance à un certificat non signé quelconque, ce serait une passoire pour du main in the middle.

Pour activer cela, il faut activer l’option suivante via la console :

SetOption132 1

Erreur possible

Si une erreur dans les logs de ce type, c’est une erreur TCP de connexion, vérifier que ce n’est pas un problème de firewall : MQT: TLS connection error: -1002]

L’article Tasmota et MQTT – MQTTS est apparu en premier sur Mon linux.

• L’identification du serveur et la sécurisation du flux
• L’identification du client
• L’authentification du client

Vous devez faire le bon compromis entre sécurité et flexibilité. Il ne faut pas forcément pousser le bouton à fond pour tous les cas de figures.

Génération des clés et certificats

Pour MQTTS, 2 options s’offre à vous comme pour un serveur HTTPS :

• générer vos certificats auto-signé
• via une autorité de certification

Dans mon cas ce n’est que du local, ce sera donc de l’auto-signé.

Je génère toujours les clés et certificats sur ma machine perso et ensuite je copie les certificats/clés sur le serveur et les clients, afin de les archiver. C’est donc à faire dans un dossier à garder sous Linux ou en WSL sous Windows.

Veillez bien à remplacer les DNS suivants par votre domaine externe pointant sur votre serveur ainsi que votre DNS interne ou IP interne pour joindre votre serveur MQTT (dans mon cas installé sur mon serveur Jeedom) : DNS:jeedom.YOURDOMAIN.TLD,DNS:jeedom.home

mkdir ca broker clients

#CA
openssl genrsa -out ca/ca.key 2048
openssl req -new -x509 -days 9999 -subj "/C=BE/CN=MQTT-CA/O=home" -key ca/ca.key -out ca/ca.crt

#broker
openssl genrsa -out broker/mosquitto.key 2048
openssl req -new -subj "/C=BE/O=home/CN=MQTT-mosquitto" -key broker/mosquitto.key -out broker/mosquitto.csr
openssl x509 -req -extfile <(printf "subjectAltName = DNS:jeedom.YOURDOMAIN.TLD,DNS:jeedom.home,DNS:localhost,IP:127.0.0.1,IP:::1") -in broker/mosquitto.csr
 -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out broker/mosquitto.crt -days 9999 -sha256
 
#client (facultatif) si on souhaite une authentification par certificat du client au lieu de password
openssl genrsa -out clients/local-tasmotas.key 2048
openssl req -new -subj "/C=BE/O=home/CN=MQTT-client-tasmotas" -key clients/local-tasmotas.key -out clients/local-tasmotas.csr
openssl x509 -req -in clients/local-tasmotas.csr -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out clients/local-tasmotas.crt -days 9999 -sha256

MQTTS côté broker Mosquitto

Les certificats et clés privées doivent être archivés, ils ne le sont pas dans le backup Jeedom.

La configuration de base du fichier Debian est : /etc/mosquitto/mosquitto.conf

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d

C’est conseillé d’utiliser un fichier dans conf.d : dans mon cas sous Jeedom avec l’installation du plugin jMQTT, le fichier suivant est créé et sera utilisé : /etc/mosquitto/conf.d/jMQTT.conf

Copie des fichiers nécessaires du broker sur le serveur Jeedom :

scp ca/ca.crt broker/mosquitto.crt broker/mosquitto.key jeedom:
ssh jeedom
sudo mv ca.crt mosquitto.crt mosquitto.key /etc/mosquitto/certs/
ls -l /etc/mosquitto/certs

Editer via l’interface web la configuration du fichier jMQTT.conf ou via vim /etc/mosquitto/conf.d/jMQTT.conf

• on laisse les connexions en clair du port 1883 provenant de localhost uniquement (127.0.0.1), plus d’accès en clair depuis l’extérieur (sert pour jeedom se connecter au broker Mosquitto)
• on active le port TLS 8883 sur toutes les interfaces

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous true

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key

# Only allow clients with a valid certificat (false to only trus the broker and not the clients)
require_certificate true

Rédémarrez le service et vérifier que le port 8883 est ouvert pour tous et 1883 n’est plus accessible que par 127.0.0.1 :

sudo systemctl restart mosquitto.service
sudo ss -tlpn | egrep '(1883|8883)'
LISTEN    0         100                0.0.0.0:8883             0.0.0.0:*        users:(("mosquitto",pid=14185,fd=6))
LISTEN    0         100              127.0.0.1:1883             0.0.0.0:*        users:(("mosquitto",pid=14185,fd=5))

A ce moment là, le trafic entre nos clients et notre serveur est sécurisé. Mais n’importe quel client peut se connecter à notre serveur sans mot de passe!

Basé sur la documentation jMQTT officielle, d’autres informations et erreurs courantes sont disponibles sur ce blog.

Authentification

Mes clients étant des ESP32 qui disposent de Wifi ou mon pc avec MQTT explorer pour le debug, tout en local, une authentification par mot de passe est suffisante. Je distingue les clients IoT avec un seul mot de passe et mes 2 pc avec chacun un mot de passe différent.

Pour un serveur MQTTS publique, l’authentification des clients par certificat est recommandé

1. Créer les fichiers de mot de passe : mosquitto_passwd -c <password file> <username>
   sudo mosquitto_passwd -c /etc/mosquitto/distant.passwd tasmota
2. Configurer le broker avec la ligne : password_file <path to the configuration file>
3. Ajout d’un second utilisateur sudo mosquitto_passwd /etc/mosquitto/distant.passwd hp
4. Redémarrer : sudo systemctl restart mosquitto.service

Le fichier /etc/mosquitto/conf.d/jMQTT.conf

per_listener_settings true

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous true

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key
allow_anonymous false
persistence false
require_certificate false
password_file /etc/mosquitto/distant.passwd

Si vous préférez utiliser un mot de passe pour Jeedom en local, selon si le plugin vous l’impose, vous pouvez le faire :

per_listener_settings true

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous false
persistence false
password_file /etc/mosquitto/local.passwd

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key
allow_anonymous false
persistence false
require_certificate false
password_file /etc/mosquitto/distant.passwd

source

L’article MQTTS sécuriser Mosquitto MQTT est apparu en premier sur Mon linux.