Cédrix
1 line
54 KiB
JSON
1 line
54 KiB
JSON
[{"uuid":"0bba1ad7-e4cb-49a6-9467-fcfac2e09a93","slug":"deuxiemes-pas-devops-durcir-et-fiabiliser-un-serveur-debian","title":"Deuxièmes pas DevOps : durcir et fiabiliser un serveur Debian","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-06-08 07:00","created_at":"2026-05-12 23:01:34","updated_at":"2026-05-13 22:53:46","tags":{"logiciels":["Fail2ban","Debian"]},"plain":"Une fois le système de base configuré (dépôts, mises à jour, , identification — sujets traités dans l'article précédent), la machine est fonctionnelle mais encore vulnérable et un peu fragile pour un usage sérieux. Ce deuxième article s'attaque aux gestes qui transforment un serveur « qui marche » en un serveur sur lequel on peut raisonnablement faire tourner quelque chose : sécuriser l'accès SSH, mettre en place un pare-feu, automatiser les correctifs de sécurité et soigner quelques détails opérationnels.\r\n\r\nSécuriser l'accès SSH\r\n\r\nSSH est la porte d'entrée principale d'un serveur Linux. C'est aussi, statistiquement, la cible la plus attaquée : n'importe quelle IP publique reçoit en permanence des tentatives de connexion automatisées. Deux gestes simples changent radicalement la donne.\r\n\r\nPasser à l'authentification par clé\r\n\r\nLes mots de passe, même longs, restent vulnérables aux attaques par force brute et au phishing. Une paire de clés cryptographiques est à la fois plus sûre et plus pratique au quotidien.\r\n\r\nCôté poste de travail, on génère une paire de clés modernes :\r\n\r\n\r\n\r\nL'algorithme est aujourd'hui le choix par défaut recommandé : clés courtes, signatures rapides, sécurité solide. Le commentaire () facilite l'identification de la clé quand on en gère plusieurs.\r\n\r\nOn copie ensuite la clé publique sur le serveur :\r\n\r\n\r\n\r\nCette commande dépose la clé publique dans côté serveur avec les bonnes permissions. À partir de là, la connexion se fait sans saisir de mot de passe — il faut tester depuis une nouvelle session avant de passer à l'étape suivante, sous peine de risquer de se retrouver enfermé dehors.\r\n\r\nDésactiver la connexion root et les mots de passe\r\n\r\nUne fois la connexion par clé validée, on durcit la configuration SSH. Le fichier à modifier est :\r\n\r\n\r\n\r\nLes directives importantes à positionner (ou décommenter) sont :\r\n\r\n\r\n\r\nLa première interdit toute connexion directe en via SSH : on devra obligatoirement se connecter avec un utilisateur normal puis élever ses droits via . La deuxième supprime complètement l'authentification par mot de passe, ne laissant plus que les clés. La troisième confirme explicitement que l'authentification par clé est active.\r\n\r\nOn recharge ensuite le service pour appliquer les changements :\r\n\r\n\r\n\r\nImportant : garder la session SSH actuelle ouverte et tester la nouvelle configuration depuis un autre terminal avant de fermer la première. En cas de problème, on peut encore corriger le tir.\r\n\r\nPour aller un cran plus loin, changer le port SSH par défaut (22) vers un port moins évident réduit considérablement le bruit dans les logs. Ce n'est pas de la sécurité au sens strict (un scan le retrouvera), mais c'est un filtre efficace contre les attaques automatisées.\r\n\r\nMettre en place un pare-feu\r\n\r\nPar défaut, Debian n'a aucun pare-feu actif. Tout port ouvert par un service installé sera donc directement exposé. Deux outils standards existent : (le successeur officiel d', bas niveau et puissant) et (une surcouche pensée pour la simplicité). Pour démarrer, est le bon compromis.\r\n\r\n\r\n\r\nLa logique consiste à tout bloquer en entrée par défaut, puis à n'ouvrir explicitement que ce qui doit l'être :\r\n\r\n\r\n\r\nSi SSH écoute sur un port non standard, remplacer par (ou le port choisi). Oublier cette étape avant un est un grand classique du verrouillage involontaire.\r\n\r\nPour les services web, on ouvrira typiquement les ports 80 et 443 :\r\n\r\n\r\n\r\nL'état du pare-feu se vérifie avec :\r\n\r\n\r\n\r\nSur une architecture où la machine est derrière un reverse proxy (cas fréquent quand on expose plusieurs services sur un même domaine), seuls les ports utiles côté proxy doivent être ouverts au monde extérieur. Les services applicatifs eux-mêmes restent accessibles uniquement depuis le réseau interne.\r\n\r\nAutomatiser les correctifs de sécurité\r\n\r\nLes failles de sécurité ne préviennent pas, et personne n'a envie de lancer manuellement chaque matin sur dix machines. Le paquet applique automatiquement les mises à jour du dépôt .\r\n\r\n\r\n\r\nLa configuration se trouve ensuite dans . Par défaut, seuls les correctifs de sécurité sont appliqués automatiquement, ce qui est généralement le bon compromis : on profite des patches critiques sans risquer qu'une mise à jour fonctionnelle introduise une régression sur un service en production.\r\n\r\nQuelques options qui méritent l'attention dans ce fichier :\r\n: à régler sur si l'on accepte les redémarrages automatiques après une mise à jour de noyau, ou si l'on préfère les piloter à la main. La directive permet alors de choisir l'horaire.\r\n: pour recevoir un rapport par mail des mises à jour appliquées, à condition d'avoir un MTA configuré sur la machine.\r\n\r\nLe bon réflexe consiste à vérifier de temps en temps les logs dans pour s'assurer que tout se déroule sans heurts.\r\n\r\nSoigner les détails opérationnels\r\n\r\nQuelques outils complémentaires améliorent significativement le confort et la résilience d'un serveur.\r\n\r\nFail2ban surveille les logs d'authentification et bannit temporairement les IP qui tentent trop de connexions échouées. Même avec SSH par clé uniquement, le service réduit considérablement le bruit dans les journaux :\r\n\r\n\r\n\r\nLa configuration par défaut surveille déjà SSH ; elle peut être étendue à d'autres services (nginx, Postfix, etc.) via des fichiers dans .\r\n\r\nLogwatch ou journalctl méritent qu'on s'y attarde. Sur une Debian récente, est l'outil central pour consulter les logs systemd :\r\n\r\n\r\n\r\nPrendre l'habitude de jeter un œil aux logs régulièrement — ou de mettre en place une remontée centralisée si l'on gère plusieurs machines — change beaucoup de choses en exploitation.\r\n\r\nUn swap raisonnable, sur une VM ou un serveur dédié, évite que la machine ne devienne complètement injoignable en cas de pic de consommation mémoire. Sur un conteneur LXC en revanche, c'est généralement géré au niveau de l'hyperviseur.\r\n\r\nEt après ?\r\n\r\nAvec ces réglages, le serveur est dans un état correct pour accueillir des services réels : la surface d'attaque est réduite, les correctifs s'appliquent tout seuls, et les logs racontent ce qui se passe. La suite logique est l'installation de la pile applicative proprement dite (serveur web, base de données, runtime) et la mise en place d'un reverse proxy pour exposer plusieurs services derrière un même point d'entrée.\r\n\r\nComme évoqué dans le premier article, le moment où l'on commence à enchaîner ces étapes sur plusieurs machines est exactement celui où il faut basculer vers de l'automatisation : un script shell bien rangé pour commencer, puis Ansible ou un équivalent quand le parc grossit. Une bonne pratique consiste à versionner ces scripts dans un dépôt Git dédié à l'infrastructure, au même titre que le code applicatif."},{"uuid":"104a8694-4268-4e0a-99c7-e7ecfd47af1e","slug":"auto-heberger-son-serveur-mail-en-2026","title":"Auto-héberger son serveur mail en 2026","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-12 08:35","created_at":"2026-05-12 08:38:14","updated_at":"2026-05-12 08:40:06","tags":[],"plain":"Survivre aux règles de Gmail, Outlook et consorts\r\nContexte — Cet article de Clubic (lien) rappelle une vérité technique : SMTP date de 1982, n'a aucune sécurité native, et toutes les \"rustines\" (SPF, DKIM, DMARC, MTA-STS, DANE) ont été conçues par Yahoo, Cisco, Microsoft, Google. Depuis février 2024 (Google) et mai 2025 (Microsoft), tout expéditeur dépassant 5000 mails/jour vers Gmail/Outlook doit configurer SPF + DKIM + DMARC, maintenir un taux de spam < 0,1 %, et fournir un lien de désinscription en un clic.\r\nMais même en dessous de 5000/jour, ces règles s'appliquent en pratique : sans elles, ton mail finit en spam ou est rejeté. Ce dossier décrit comment monter son propre serveur mail tout en passant à travers ces filtres.\r\n--\r\n\r\nSommaire\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n2. Prérequis techniques\r\n3. Architecture cible\r\n4. Choix du fournisseur et de l'IP\r\n5. Configuration DNS complète\r\n6. Installation du stack mail\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n9. PTR (reverse DNS) et HELO\r\n10. Warmup d'IP : la phase la plus délicate\r\n11. Postmaster Tools, SNDS, FBL\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n13. Anti-spam entrant et hygiène\r\n14. Monitoring, logs, alertes\r\n15. Que faire quand Gmail rejette quand même ?\r\n16. Checklist finale avant mise en prod\r\n17. Annexes : commandes utiles\r\n--\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n\r\nL'auto-hébergement mail est techniquement possible, mais c'est probablement le service le plus pénible à maintenir en 2026. Avant de te lancer, lis ça :\r\n\r\nCe qui marche bien en auto-hébergé :\r\nRecevoir du mail (presque tout le monde te livre).\r\nEnvoyer vers d'autres serveurs auto-hébergés ou pros bien configurés.\r\nGarder le contrôle sur tes données, tes alias, tes domaines.\r\n\r\nCe qui est dur :\r\nEnvoyer vers Gmail / Outlook / Yahoo / iCloud sans atterrir en spam.\r\nSortir d'une blacklist une fois dedans.\r\nMaintenir un score de réputation IP correct sur la durée.\r\nSurvivre à un changement unilatéral des règles côté gros acteurs (cf. février 2024 et mai 2025).\r\n\r\nStratégie réaliste recommandée :\r\nRéception entrante : auto-hébergée à 100 %. Aucun risque, full contrôle.\r\nEnvoi sortant : deux options, selon ton volume et ton tolérance au risque.\r\nOption A — Pure auto-hébergée : tu envoies directement depuis ton serveur. Faisable, mais demande un warmup, une IP propre, et un suivi continu.\r\nOption B — Smart host sortant : tu envoies via un relais réputé (un autre de tes serveurs avec une IP qui a déjà sa réputation, ou un service type Mailjet/Sendgrid/SMTP2GO en bas volume gratuit). Tes mails sortent depuis l'IP du relais, qui a déjà sa réputation faite. C'est un compromis : tu perds une partie de la souveraineté technique, mais tu gagnes énormément en délivrabilité.\r\n\r\nLe reste du dossier suit l'option A — tout en t'expliquant comment basculer en B si nécessaire.\r\n--\r\n\r\n2. Prérequis techniques\r\nÉlément | Détail |\r\n---|---|\r\nDomaine | À toi, registrar peu importe, mais avec DNSSEC activable (cf. §8 pour DANE). |\r\nServeur | VPS ou dédié, 2 vCPU / 4 Go RAM minimum, Debian 12+ ou Ubuntu 24.04 LTS. |\r\nIP fixe v4 | Indispensable. IP \"résidentielle\" ou IP de datacenter récemment recyclée = exclues. |\r\nIP fixe v6 | Recommandée, mais désactivable si l'IPv6 du fournisseur est blacklistée. |\r\nPTR / reverse DNS | Modifiable par toi. Si l'hébergeur ne te le permet pas, change d'hébergeur. |\r\nPorts | 25, 465, 587, 993, 4190 ouverts sortants ET entrants. Le port 25 sortant est bloqué chez beaucoup d'hébergeurs grand public (OVH résidentiel, Free, etc.) : vérifie avant. |\r\nTLS | Certificat valide (Let's Encrypt suffit). |\r\n\r\nCompétences attendues : Linux en ligne de commande, DNS (champs A/AAAA/MX/TXT/SRV/CAA/TLSA), notion de TLS, lecture de logs et .\r\n--\r\n\r\n3. Architecture cible\r\n\r\nUn stack standard, éprouvé, en logiciels libres :\r\n\r\n\r\n\r\nComposants :\r\nPostfix : MTA. Reçoit, route, envoie le SMTP.\r\nDovecot : serveur IMAP/POP3, livraison locale (LMTP), authentification SASL pour Postfix, gestion Sieve (filtres).\r\nRspamd : antispam moderne, fait aussi la vérification SPF/DKIM/DMARC entrante, le greylisting, et — option recommandée — la signature DKIM sortante (en remplacement d'OpenDKIM).\r\nLet's Encrypt (certbot) : TLS.\r\n(Optionnel) Roundcube ou SnappyMail : webmail.\r\n\r\nAlternative tout-en-un : Mailcow ou Mailu, basés sur Docker, qui empaquètent tout ça avec une interface admin. Si tu préfères ne pas tout configurer à la main, c'est légitime — la majorité des règles DNS et de délivrabilité de ce dossier restent identiques.\r\n--\r\n\r\n4. Choix du fournisseur et de l'IP\r\n\r\nLe choix de l'hébergeur conditionne la moitié de ta délivrabilité. Avant de prendre un VPS :\r\n\r\n1. Le port 25 sortant est-il ouvert ? Beaucoup d'hébergeurs le bloquent par défaut pour limiter le spam (Hetzner l'ouvre sur demande, OVH l'ouvre selon le produit, Scaleway l'ouvre selon le compte). Pose la question au support avant de payer.\r\n2. Le PTR est-il configurable ? Si non, change.\r\n3. L'IP a-t-elle été utilisée par un spammeur ? Avant d'acheter le VPS, demande l'IP qu'on te donnera. Vérifie sur :\r\nmxtoolbox.com/blacklists.aspx\r\nmultirbl.valli.org\r\ntalosintelligence.com (Cisco)\r\nsenderscore.org\r\n \r\n Si l'IP est listée sur Spamhaus, Barracuda, SORBS, SpamCop, demande à l'hébergeur de te l'échanger ou prends un autre VPS. Une fois listée, tu vas y passer des semaines.\r\n4. Réputation du subnet (). Même si ton IP est propre, si le est pourri (beaucoup de spammeurs voisins), Gmail va te traiter avec méfiance. Vérifie sur senderscore.org en saisissant ton IP — le score du subnet apparaît.\r\n\r\nHébergeurs réputés corrects pour le mail : Hetzner, OVH (gamme dédiée, pas SoYouStart), Scaleway, Infomaniak (en VPS), Netcup. À éviter pour de l'envoi : DigitalOcean (subnets souvent grillés), Linode/Akamai (idem), AWS EC2 (le port 25 est limité par défaut, et la rate-limit est costaude).\r\n--\r\n\r\n5. Configuration DNS complète\r\n\r\nPour un domaine avec un serveur mail sur à l'IP (et en v6) :\r\n\r\n\r\n\r\nDétails dans les sections dédiées plus bas.\r\n\r\nÀ ne pas oublier : l'enregistrement PTR (reverse DNS) se configure chez ton hébergeur, pas dans ta zone DNS. Il doit pointer . C'est traité au §9.\r\n--\r\n\r\n6. Installation du stack mail\r\n\r\nSur Debian 12. Ce qui suit est volontairement condensé — pour une configuration ligne par ligne, suis le tutoriel de référence de Workaround.org qui est l'étalon depuis 20 ans.\r\n\r\n\r\n\r\nPostfix : configuration minimale-mais-saine\r\n\r\n\r\n\r\nDovecot, Rspamd\r\n\r\nCes composants demandent leurs propres fichiers de configuration. Renvoi explicite vers les tutos qui font autorité :\r\nWorkaround.org / ISPmail : https://workaround.org/ispmail/ — référence francophone et anglophone, mise à jour à chaque version Debian.\r\nRspamd quickstart : https://www.rspamd.com/doc/tutorials/quickstart.html\r\nDovecot wiki : https://doc.dovecot.org/\r\n\r\nSi tu veux gagner du temps, Mailcow () est aujourd'hui la solution clé-en-main la plus fiable.\r\n--\r\n\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n\r\nSans ces trois enregistrements correctement configurés, Gmail et Outlook rejetteront ou marqueront en spam la majorité de tes messages — peu importe ton volume.\r\n\r\nSPF (Sender Policy Framework)\r\n\r\nDéclare qui a le droit d'envoyer du mail pour ton domaine.\r\n: autorise les serveurs listés dans le MX du domaine.\r\n: rejet strict de tout le reste. Indispensable pour la réputation. Ne jamais utiliser (softfail) en prod : Gmail aujourd'hui considère comme un signal faible.\r\n\r\nSi tu envoies aussi via un relais externe (smart host) : ajoute son , ex. .\r\n\r\nLimite : un enregistrement SPF doit tenir en 10 lookups DNS maximum. Au-delà, il est invalide. Vérifie avec https://www.kitterman.com/spf/validate.html.\r\n\r\nDKIM (DomainKeys Identified Mail)\r\n\r\nSigne chaque mail sortant avec une clé privée. Le destinataire vérifie la signature via la clé publique publiée en DNS.\r\n\r\nGénération de la clé (Rspamd, sélecteur , clé 2048 bits) :\r\n\r\n\r\n\r\nLe fichier contient l'enregistrement DNS à publier :\r\n\r\n\r\n\r\nConfiguration Rspamd () :\r\n\r\n\r\n\r\nRecharge : .\r\n\r\nVérification : envoie un mail à check-auth@verifier.port25.com, tu reçois un rapport complet SPF/DKIM/DMARC en retour. Ou utilise https://www.mail-tester.com/ (note sur 10).\r\n\r\nDMARC (Domain-based Message Authentication, Reporting and Conformance)\r\n\r\nDit aux serveurs distants quoi faire en cas d'échec SPF/DKIM, et te renvoie des rapports sur ce qui passe et ce qui rate.\r\n: surveillance seule, à utiliser pendant 2-4 semaines en démarrage pour collecter les rapports sans pénaliser.\r\n: mise en spam des mails non authentifiés. Cible normale.\r\n: rejet pur. À atteindre en cible finale, après avoir vérifié 4 semaines de rapports propres.\r\n: adresse pour les rapports agrégés (quotidiens).\r\n: rapports forensiques (par message). Optionnel.\r\n: alignement strict — le domaine de signature DKIM et le domaine SPF doivent exactement correspondre au domaine .\r\n\r\nLecture des rapports DMARC : ils arrivent en XML, illisibles. Utilise un parseur :\r\nPostmark DMARC Monitoring (gratuit, agrège les rapports dans une UI).\r\nparsedmarc (auto-hébergeable, envoie dans Elasticsearch/Splunk/Grafana).\r\n--\r\n\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n\r\nCes standards sécurisent le transport entre serveurs (chiffrement TLS forcé). Gmail les regarde, Microsoft aussi. Pas obligatoires, mais ils boostent ta réputation.\r\n\r\nMTA-STS\r\n\r\nForce les serveurs distants à utiliser TLS pour t'envoyer des mails. Trois éléments :\r\n\r\n1. Enregistrement DNS TXT :\r\n\r\n\r\n2. Sous-domaine servant un fichier en HTTPS à :\r\n\r\n\r\n est la cible. En démarrage, mets pendant 1-2 semaines.\r\n\r\n3. Certificat TLS valide sur ce sous-domaine (déjà fait via certbot au §6).\r\n\r\nTLS-RPT\r\n\r\nDemande aux serveurs distants de t'envoyer des rapports en cas d'échec TLS.\r\n\r\n\r\n\r\nDANE (DNS-based Authentication of Named Entities)\r\n\r\nEncore plus solide que MTA-STS, mais nécessite DNSSEC activé sur ton domaine. Si ton registrar ne supporte pas DNSSEC, oublie DANE.\r\n\r\nDANE publie un hash du certificat TLS dans un enregistrement TLSA :\r\n\r\n\r\n\r\nOu plus simplement avec https://www.huque.com/bin/gentlsa :\r\n\r\n\r\n\r\nVérification globale de tout ton setup TLS+DANE : https://internet.nl/mail/ (excellent, recommandé).\r\n--\r\n\r\n9. PTR (reverse DNS) et HELO\r\n\r\nLe PTR est probablement la cause la plus fréquente de rejet par Gmail/Outlook chez les nouveaux auto-hébergés.\r\n\r\nRègle absolue : , et tout doit être un FQDN cohérent.\r\n\r\nConfigure le PTR dans le panneau de ton hébergeur (chez OVH : \"IP\" → \"Reverse DNS\") :\r\n\r\n\r\nVérifie :\r\n\r\n\r\nDans Postfix, et c'est ce qui est annoncé en HELO. Cohérence garantie.\r\n--\r\n\r\n10. Warmup d'IP : la phase la plus délicate\r\n\r\nUne IP neuve = pas de réputation = défiance maximale des gros acteurs. Tu ne peux pas envoyer 1000 mails le jour 1 sans te griller.\r\n\r\nPlan de warmup sur 4 à 6 semaines\r\nSemaine | Volume max/jour vers Gmail+Outlook | Volume max/jour total | Contenu |\r\n---|---|---|---|\r\n1 | 20-50 | 100 | Mails à toi-même, comptes test sur Gmail/Outlook/Yahoo. Réponds-y, marque \"non spam\" si en spam. |\r\n2 | 100 | 300 | Cercle proche qui sait répondre / interagir. |\r\n3 | 300 | 1000 | Élargissement progressif. |\r\n4 | 800 | 3000 | Ouvre aux usages normaux. |\r\n5+ | 2000+ | volume cible | Stable. |\r\n\r\nRègles d'or pendant le warmup :\r\nPas de mailing list, pas de notifs automatiques en masse. Privilégie des mails 1-à-1 conversationnels.\r\nDemande aux destinataires de répondre — un mail avec réponse a 100x le poids d'un mail ouvert silencieusement.\r\nAucun lien raccourci, aucun pixel de tracking, aucune image lourde.\r\nStop net si ton score Senderscore baisse ou si Gmail Postmaster Tools (cf. §11) montre du rouge.\r\n\r\nSi tu as un volume immédiat à envoyer\r\n\r\nBascule en option B (smart host) le temps du warmup, puis rapatrie progressivement en interne en répliquant les volumes ci-dessus.\r\n--\r\n\r\n11. Postmaster Tools, SNDS, FBL\r\n\r\nLes gros acteurs te donnent des dashboards dédiés. Inscris-toi à tous, dès la création du domaine.\r\nService | Acteur | Usage |\r\n---|---|---|\r\nGoogle Postmaster Tools | Gmail | Réputation IP+domaine, taux de spam, authentification, encryption. Indispensable. |\r\nMicrosoft SNDS | Outlook/Hotmail | Smart Network Data Services, qualité de l'IP. |\r\nMicrosoft JMRP | Outlook | Junk Mail Reporting Program, FBL Microsoft. |\r\nYahoo CFL | Yahoo | Complaint Feedback Loop. |\r\nValidity Sender Score | Indépendant | Score sur 100, à surveiller. |\r\n\r\nConfigure les feedback loops (FBL) : quand un destinataire clique \"spam\", tu reçois une notification. Ça te permet de désinscrire l'utilisateur avant qu'il ne dégrade ta réputation.\r\n--\r\n\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n\r\nExigence Google/Microsoft pour les expéditeurs en volume, mais à mettre en place dès le début même en bas volume.\r\n\r\nAjoute deux en-têtes à tous les mails non-strictement-personnels :\r\n\r\n\r\n\r\nL'URL HTTPS doit accepter une requête POST (pas seulement GET) avec dans le corps, et désinscrire immédiatement et silencieusement sans demander de confirmation.\r\n--\r\n\r\n13. Anti-spam entrant et hygiène\r\n\r\nUn serveur mail mal configuré côté entrée devient vite un relais de spam ou une cible. Configuration Rspamd minimale :\r\n\r\n\r\n\r\n\r\n\r\nActive aussi :\r\nVérification SPF/DKIM/DMARC entrante (par défaut activée dans Rspamd).\r\nRBL (Realtime Blackhole Lists) : Spamhaus ZEN, Barracuda. Attention à ne pas multiplier — 2 ou 3 RBL fiables suffisent.\r\nGreylisting : refuse temporairement les premiers contacts, ce qui élimine 80% du spam basique. Ne pas activer sur un domaine à fort volume transactionnel (gêne les notifs).\r\nBayes : laisse Rspamd apprendre via le dossier de Dovecot (signal / ).\r\n\r\nMises à jour : activé, redémarrage planifié, lecture des annonces sécu Postfix/Dovecot.\r\n--\r\n\r\n14. Monitoring, logs, alertes\r\n\r\nSans monitoring, tu découvres les problèmes par les utilisateurs. À mettre en place :\r\nLecture des logs : , , web UI de Rspamd sur .\r\nMétriques : exporter Postfix/Dovecot vers Prometheus + Grafana (, ).\r\nAlertes sur :\r\nFile d'attente Postfix > 50 messages ().\r\nScore Senderscore qui chute.\r\nApparition sur une RBL : surveillance automatisée par https://multirbl.valli.org/ ou via un script qui interroge plusieurs DNSBL en cron.\r\nÉchec TLS-RPT (rapport entrant signalant une connexion non chiffrée).\r\nRapports DMARC parsés régulièrement (cf. §7).\r\n--\r\n\r\n15. Que faire quand Gmail rejette quand même ?\r\n\r\nÇa arrive. Diagnostic dans l'ordre :\r\n\r\n1. Lis le code de rejet SMTP dans . Gmail renvoie des codes très explicites :\r\n→ contenu jugé spammy. Revois le contenu, ajoute du texte conversationnel, retire les liens douteux.\r\n→ tu as dépassé un seuil. Ralentis immédiatement, attends 24-48h, reprends doucement.\r\n→ ton DMARC ne passe pas. Revérifie SPF/DKIM/alignement.\r\n→ tu es sur une RBL. Va sur spamhaus.org/lookup/ pour vérifier et demander la sortie.\r\n2. Va dans Postmaster Tools (§11). Si \"IP reputation\" est rouge ou orange, regarde le contenu et le timing de tes envois récents.\r\n3. Test mail-tester : envoie à une adresse fournie par mail-tester.com, obtiens une note sur 10. Vise 10/10. Toute case manquante doit être corrigée.\r\n4. Sortie de blacklist : la plupart des RBL (Spamhaus, Barracuda) ont un formulaire de retrait. Spamhaus retire en quelques heures si tu corriges la cause. SORBS est plus lent. UCEPROTECT exige souvent de payer — ignore-la, peu de serveurs sérieux la consultent.\r\n5. Si rien ne marche, change d'IP. C'est parfois la seule issue. Demande à ton hébergeur une IP fraîche, refais un warmup.\r\n--\r\n\r\n16. Checklist finale avant mise en prod\r\n\r\nAvant d'envoyer le premier vrai mail :\r\n[ ] Domaine avec DNSSEC activé.\r\n[ ] IP testée sur 5+ blacklists, propre.\r\n[ ] Port 25 sortant ouvert et testé ().\r\n[ ] PTR configuré et cohérent avec le HELO.\r\n[ ] MX, A, AAAA, SPF, DKIM, DMARC publiés et validés via mxtoolbox.com.\r\n[ ] MTA-STS publié (mode au démarrage).\r\n[ ] TLS-RPT publié.\r\n[ ] DANE/TLSA publié (si DNSSEC OK).\r\n[ ] CAA publié.\r\n[ ] Test envoyé à : tout en .\r\n[ ] Test mail-tester.com : 10/10.\r\n[ ] Test internet.nl/mail/ : 100%.\r\n[ ] Inscription Postmaster Tools, SNDS, JMRP, Yahoo CFL.\r\n[ ] DMARC au démarrage, parser de rapports en place.\r\n[ ] List-Unsubscribe + List-Unsubscribe-Post implémentés.\r\n[ ] Plan de warmup affiché et respecté.\r\n[ ] Monitoring file d'attente + RBL en place.\r\n[ ] Backup chiffré des Maildir.\r\n\r\nAu bout de 4 semaines de rapports DMARC propres : passage à . Au bout de 8-12 semaines : .\r\n--\r\n\r\n17. Annexes : commandes utiles\r\n\r\n\r\n\r\nOutils web à mettre en favoris\r\nhttps://www.mail-tester.com/ — score sur 10\r\nhttps://internet.nl/mail/ — audit complet\r\nhttps://mxtoolbox.com/SuperTool.aspx — DNS, blacklists\r\nhttps://dmarcian.com/dmarc-inspector/ — vérif DMARC\r\nhttps://www.kitterman.com/spf/validate.html — vérif SPF\r\nhttps://postmaster.google.com/ — Google Postmaster\r\nhttps://senderscore.org/ — réputation IP\r\n\r\nDocumentation de référence\r\nISPmail / Workaround.org — https://workaround.org/ispmail/ — le tutoriel le plus complet et tenu à jour, par version Debian.\r\nMailcow docs — https://docs.mailcow.email/ — pour la version conteneurisée clé-en-main.\r\nPostfix officiel — https://www.postfix.org/documentation.html\r\nRspamd docs — https://www.rspamd.com/doc/\r\nRFCs essentielles** : 5321 (SMTP moderne), 7208 (SPF), 6376 (DKIM), 7489 (DMARC), 8461 (MTA-STS), 8460 (TLS-RPT), 7672 (DANE-SMTP), 8058 (One-Click Unsubscribe).\r\n--\r\n\r\nL'auto-hébergement mail en 2026 reste possible, mais c'est devenu un sport : les règles changent, les gros acteurs durcissent leurs critères, et l'écosystème pousse vers la centralisation. Si tu réussis le warmup et tiens 6 mois sans incident, tu as gagné — mais ne baisse pas la garde, un changement unilatéral de Google peut survenir à tout moment, comme en février 2024."},{"uuid":"7cf4eff3-2bab-4f2e-8982-247c89f7ca16","slug":"installer-webmin-l-outil-d-administration-en-mode-web","title":"Mettre en place un serveur Debian administrable avec Webmin","category":"linux","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2025-11-13 11:57","created_at":"2025-11-13 11:57:05","updated_at":"2026-05-12 10:48:26","tags":[],"plain":"Quand on monte un nouveau serveur, les premières heures sont toujours les mêmes : on durcit la machine, on crée un utilisateur correct, on coupe ce qui traîne, et on met en place de quoi l'administrer sans avoir à ouvrir un terminal pour chaque détail. Cet article décrit la procédure que j'utilise sur mes Debian fraîches : préparation via mes scripts, installation de Webmin, et activation de pour ne laisser passer que ce qui doit l'être. L'idée n'est pas de transformer le serveur en sapin de Noël, mais d'avoir une base saine sur laquelle bâtir, qu'il s'agisse d'expérimenter dans un LXC ou de préparer une VM destinée à recevoir une vraie charge. Étape 1 — Préparer la machine Sur une Debian neuve, on commence par récupérer un petit script qui en télécharge d'autres. C'est juste un point d'entrée : il va chercher dans mon dépôt Forgejo un ensemble de scripts d'initialisation que je maintiens à jour. À ce stade, un dossier apparaît à côté du script. C'est là que se trouve le vrai travail : fait ce qu'on a tous fini par écrire un jour : mise à jour des paquets, installation des outils de base, création d'un utilisateur non-root avec les bons droits sudo, durcissement minimal de SSH. Rien de magique, mais c'est répétable et c'est ce qui compte quand on provisionne souvent. Important : une fois le script terminé, il faut se déconnecter de la session et se reconnecter avec l'utilisateur que le script vient de créer. Tout ce qui suit se fait avec cet utilisateur, en passant par quand nécessaire. Continuer en root est une mauvaise habitude qui finit toujours par se payer. Étape 2 — Installer Webmin Webmin est une interface web d'administration système. Pour quelqu'un qui débute, c'est une porte d'entrée appréciable : on voit les services qui tournent, les utilisateurs, les paquets installés, les logs, le tout depuis un navigateur. Pour quelqu'un d'expérimenté, c'est un complément pratique quand on veut donner un accès limité à un collègue moins à l'aise en ligne de commande. Webmin fournit son propre script pour configurer le dépôt apt : Ce script ajoute le dépôt officiel Webmin à la liste des sources apt et importe la clé GPG associée. Une fois fait, l'installation devient une commande apt classique : Petite précision sur les deux paquets : Webmin sert à l'administration système (root ou utilisateur sudo), Usermin est sa version pour les utilisateurs standards, qui leur permet de gérer leur propre compte, leurs mails, leurs fichiers, sans toucher au système. Sur une machine mono-utilisateur, on peut se passer d'Usermin, mais l'installer maintenant coûte trois mégaoctets et évite d'y revenir plus tard. Étape 3 — Se connecter à l'interface Webmin écoute par défaut sur le port 10000 en HTTPS. Depuis un navigateur : est à remplacer par l'adresse de la machine. Le navigateur va râler à propos du certificat — c'est normal, Webmin génère un certificat auto-signé à l'installation. On peut accepter l'avertissement pour l'instant ; si la machine est destinée à un usage durable, on remplacera ça plus tard par un vrai certificat (Let's Encrypt via un reverse proxy, par exemple). Pour la connexion, on utilise les identifiants Linux de l'utilisateur sudo, pas un compte spécifique à Webmin. C'est l'utilisateur que a créé à l'étape 1. Webmin s'appuie sur PAM, donc tout compte système autorisé à se connecter peut potentiellement entrer — d'où l'importance de l'étape suivante. Étape 4 — Activer le pare-feu Une machine accessible sur internet sans pare-feu, c'est une question de temps avant les premiers ennuis. Sur Debian, je préfère à ou à la configuration brute de : la notion de zones est pratique, la syntaxe se retient, et l'intégration avec Webmin est correcte. Installation et activation : rend le service persistant au redémarrage, le lance immédiatement. Vérification : Le retour attendu est . Si c'est autre chose, permet de comprendre ce qui coince — c'est souvent un conflit avec un autre service de filtrage déjà en place. À ce stade, le pare-feu tourne mais avec une configuration par défaut qui, selon la zone active, peut bloquer Webmin. Il faut donc explicitement autoriser le port 10000 : Le écrit la règle dans la configuration ; sans ça, elle disparaît au prochain redémarrage. Le recharge la configuration pour que la règle prenne effet immédiatement. C'est l'erreur classique : on ajoute une règle, on continue à ne pas pouvoir se connecter, on perd dix minutes avant de se rappeler du . Pour aller plus loin Une fois cette base en place, plusieurs directions s'offrent selon le rôle de la machine. Si elle est destinée à héberger un service web public, l'étape logique suivante consiste à placer Webmin derrière un reverse proxy plutôt que de l'exposer directement sur le port 10000. Le port 10000 est alors fermé vers l'extérieur, et l'interface devient accessible via un sous-domaine en HTTPS avec un vrai certificat. C'est plus propre, plus sûr, et ça évite l'avertissement de certificat à chaque connexion. Si la machine est un serveur d'applications, autant profiter du fait que est en place pour réfléchir aux ports en amont. Mieux vaut décider tout de suite quelles applications écoutent où, plutôt que d'empiler les au fil de l'eau et de finir avec une configuration que plus personne ne comprend. Et dans tous les cas, garder une trace écrite des choix faits : quels ports ouverts, quel utilisateur sudo, quelle convention de nommage. Un fichier à la racine du home de l'admin, peu importe le support — l'important c'est que dans six mois, on puisse retrouver le fil sans avoir à tout rétro-ingénierer."},{"uuid":"a150a0d3-caac-4d1f-915d-8d3c35624df1","slug":"postfix","title":"PostFix : serveur de messagerie sous Linux","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-12-29 17:29:08","created_at":"2023-12-29 17:29:08","updated_at":"2023-12-29 17:29:08","tags":[],"plain":"Cet article est destiné aux débutants qui veulent configurer un serveur de messagerie électronique de base. Il est préférable d'avoir une connaissance élémentaire en administration système, ainsi que la capacité d'installer des logiciels et de modifier des fichiers de configuration. L'article a été rédigé en se basant sur Debian 11, mais les instructions devraient également convenir aux autres versions. Veuillez noter que des différences peuvent exister dans les autres versions. Postfix est un logiciel de serveur de messagerie open source largement adopté. En tant que \"MTA\" (Agent de Transfert de Message), il joue un rôle central dans le traitement, la transmission et la distribution des courriels. Doté de fonctionnalités avancées en matière de sécurité, de filtrage et de personnalisation, Postfix est un choix prisé pour la gestion des systèmes de messagerie. <nav stacked=\"true\" fade=\"true\"> </nav>\nIntroduction\nL'objectif fondamental de cette procédure est de permettre à n'importe quelle machine ou serveur d'envoyer des courriels vers une adresse spécifique. Pour y parvenir, il est nécessaire de préparer le courrier électronique à l'aide d'un programme externe, puis de le transmettre efficacement au serveur de messagerie de destination en utilisant le protocole SMTP (Simple Mail Transfer Protocol). Le processus de l'envoi de courriel via SMTP s'articule comme suit, prenons un exemple concret avec un courriel destiné à l'adresse alice@example.com : 1. L'utilisateur ou un programme externe crée le courrier électronique, en spécifiant les informations du destinataire (alice@example.com), en rédigeant le contenu du message et en incluant d'autres détails nécessaires. 2. Le courriel est ensuite remis au serveur SMTP local, qui se trouve sur la machine ou le serveur à partir duquel l'envoi est effectué. 3. Le serveur SMTP analyse le domaine du destinataire (dans ce cas, \"example.com\") pour déterminer comment atteindre le serveur de messagerie de destination. 4. Le serveur SMTP établit un contact avec le serveur de messagerie de destination (le serveur SMTP de \"example.com\" dans cet exemple) en utilisant le protocole SMTP. 5. Le serveur de messagerie de destination accepte le courriel, le stocke temporairement, puis le transfère éventuellement dans la boîte aux lettres de l'utilisateur Alice, située sur son propre serveur de messagerie. 6. Si tout se déroule sans problème, le courriel est ainsi livré avec succès à Alice, qui peut alors le consulter dans sa boîte de réception. Ce processus est la façon dont le protocole SMTP assure la transmission de courriels, encheminant ces derniers de l'expéditeur au destinataire, en utilisant les serveurs de messagerie appropriés à travers Internet.\nAxe de travail\nIl existe de nombreuses configurations et combinaisons différentes possibles lors de la mise en place d'un serveur de messagerie électronique, bien trop nombreuses pour être toutes couvertes ici. Par conséquent, cet article effectue certaines choix fondamentaux pour vous, tels que les logiciels que nous allons utiliser (Postfix et Dovecot). D'autres options nécessiteront des modifications de la part de l'utilisateur, comme les adresses réseau et les noms de domaine. Les paramètres plus avancés, comme la gestion de domaines virtuels et des utilisateurs, ne sont pas abordés dans cet article et ne seront pas traités ici. Dans ce contexte, nous utilisons Postfix comme agent de transfert de messagerie (MTA). Dovecot est utilisé pour permettre aux utilisateurs d'accéder à leur courrier électronique via les protocoles IMAP ou POP. Nous partons du principe que le nom de domaine utilisé est example.com, mais cela devrait être adapté par le lecteur. Vous pouvez utiliser un véritable nom de domaine pour un serveur de messagerie pleinement qualifié ou un faux nom de domaine si vous souhaitez uniquement créer un serveur de messagerie interne. Notre exemple suppose que le serveur de messagerie physique (hôte) porte le nom mail.example.com et est situé à l'adresse IP privée 192.168.0.1 (veuillez personnaliser ces informations en fonction de vos besoins). Le serveur de messagerie fournira des comptes de messagerie basés sur les comptes système d'utilisateurs standards, et les utilisateurs accéderont à leur courrier en utilisant leur nom d'utilisateur et leur mot de passe de compte système. Nous illustrons cela avec un utilisateur nommé John Smith, qui dispose d'un compte système avec le nom d'utilisateur john.\nServeurs SMTP\nSous Linux Debian, il existe plusieurs programmes d'envoi de courriels, chacun avec ses propres fonctionnalités et avantages. Voici quelques-uns des programmes les plus couramment utilisés pour envoyer des courriels sous Debian : 1. ssmtp: Simple SMTP est un programme léger qui permet d'envoyer des courriels via SMTP. Il est particulièrement adapté aux tâches d'envoi de courriels automatisées et ne prend pas en charge la réception de courriels. 2. msmtp: MSMTP est un autre client SMTP léger qui facilite l'envoi de courriels depuis la ligne de commande ou depuis des scripts. Il peut être configuré pour transmettre des courriels à travers un serveur SMTP externe. 3. Postfix: Bien que Postfix soit principalement un serveur de messagerie, il peut également être utilisé pour envoyer des courriels depuis une machine Debian. Il offre une grande flexibilité en matière de configuration, mais sa configuration peut être plus complexe que celle des clients SMTP plus simples. 4. sendmail: Sendmail est un programme de messagerie historique sous Unix/Linux, bien qu'il soit maintenant souvent remplacé par des alternatives plus modernes. Cependant, il est toujours disponible sur Debian et peut être utilisé pour envoyer des courriels. 5. Exim: Exim est un autre serveur de messagerie qui peut être configuré pour envoyer des courriels. Il est également capable de gérer la réception de courriels, ce qui en fait une option plus complète. Le choix du programme d'envoi de courriels dépendra de vos besoins spécifiques, de votre niveau de confort avec la configuration et de la complexité de votre infrastructure de messagerie. Pour des tâches simples d'envoi de courriels depuis la ligne de commande ou depuis des scripts, ssmtp ou msmtp sont souvent des choix pratiques. Pour des besoins plus avancés, Postfix ou Exim peuvent être mieux adaptés.\nInstaller Postfix\nPour installer Postfix sur Debian, vous devez utiliser le gestionnaire de paquets APT (Advanced Package Tool). Voici comment vous pouvez procéder : La première commande met à jour la liste des paquets disponibles dans les dépôts Debian, et la deuxième commande \"apt install\" installe Postfix ainsi que ces dépendances. Choisir Entrer la valeur FQDN de votre adresse de serveur si vous devez relancer la configuration de Postfix\n sudo dpkg-reconfigure postfix\n \nPour supprimer Sendmail, vous pouvez utiliser la commande suivante : Cette commande supprime le programme Sendmail de votre système Debian. Après avoir installé Postfix, vous devrez configurer ces logiciels pour les adapter à vos besoins spécifiques.\nConfigurer Postfix\nLes fichiers de configuration de postfix sont stockés dans /etc/postfix. Les deux principaux fichiers de configuration de postfix sont master.cf et main.cf, bien que nous ne traiterons que de main.cf ici. Tout d'abord, nous allons ajouter ou modifier certaines lignes dans le fichier de configuration main.cf. Les lignes suivantes doivent être ajoutées, modifiées ou décommentées :\nTests\nFaire un essai d'envoi de mail\n echo \"Le contenu du mail\" | mail -s \"ceci est le sujet\" mail@domaine.tld Le programme mail est une composante du package mailutils. Donc, si le programme n'est pas installer sur la machine, utilisez \n- Pour modifier un paramètre dans Postfix, il faut éditer le fichier de configuration\n sudo nano /etc/postfix/main.cf\n \nRedémarrer le service\n sudo systemctl restart postfix\n \n Gestion des Alias\nAjouter dans le fichier de configuration de Postfix, virtualaliasmaps = hash:/etc/postfix/virtual\n \nPuis ajouter dans le fichier les alias désirés tel que le modèle suivant : Enfin, exécuter le bloc suivant. Il sera nécessaire de l’exécuter à chaque modifications effectuées du fichier .\n sudo postmap /etc/postfix/virtual\n sudo systemctl restart postfix Mails en attente\nPour connaître les mails en attente\n sudo postqueue -p\n- Pour traiter tous les mails en attente\n sudo postqueue -f\n- Pour supprimer tous les mails en attente\n sudo postsuper -d ALL Reprise de la configuration de Postfix\nLe fichier de configuration de Postfix est . Il est éditable par nano ou vim. On va le reprendre pour configurer Postfix.\n-- myhostname = myserver.example.com Il est important que l'option corresponde au FQDN (fully qualified domain name) du serveur. La valeur à renseigner et celle qui renvoyée par la commande :\n nslookup 91.134.243.56\n|\n \nDans l'exemple précédent, le serveur est noté dans le Cette information est gérée par le serveur DNS Cette option se trouve les paramètres , chez kimsufi.com \n| Cette option, reverse DNS, se trouve dans les options du serveur VPS de vos serveurs dédiés, chez ovh.com\n|\n|\n-- Configurer le nom du serveur SMTP, domaine à afficher dans le courrier sortant myorigin = example.com Configuer le nom du serveur SMTP mydomain = example.com Configure to which SMTP domains to relay messages to, for example: relaydomains = example.com\n-- Configuration minimaliste du SMTP Greeting Banner: smtpdbanner = $myhostname\n-- Limiter les attaques par déni de services : Consulter le fichier log\nLe fichier log standard de postfix est Vous pouvez garder un oeuil sur les logs\n sudo tail -f /var/log/mail.info&\n \n \nEnvoyer un mail\nIl y a deux possibilités :\nenvoie depuis un client : mail\nconnexion en Telnet sur le serveur SMTP L'utilitaire mail fait parti de la suite mailutils\n sudo apt install mailutils\n-- Utilisation de l'utilitaire mail depuis un poste client. Pour envoyer un mail à de la part de \n echo \"This is the message body\" | mail -s \"This is the subject\" mail@example.com -aFrom:sender@example.com\n \nPour envoyer un mail à \n echo \"This is the message body\" | mail -s \"Hello World\" username\n-- Utilisation de telnet pour se connecter sur le serveur SMTP telnet mail.mymailserver.com 25\n \nPuis saisir les commandes SMTP EHLO checkeremail.com MAIL FROM:<sender@mailserver.fr> RCPT TO:<dest@mymailserver.com> DATA\n Subject: Sending an email using telnet\n Hello,\n Here is my body? Do you like it?\n Cédric\n . QUIT Vider tous les mails\nVider tous les mails présents dans la boite d'un utilisateur. On considère que la boite mail (mbox) de l'utilisateur se trouve dans le fichier sudo sh -c \"> /var/mail/www-data\" Gestion des certificats\nPour configurer Postfix et Certbot pour utiliser les certificats SSL/TLS de \"smtp.monserveur.fr\" avec Let's Encrypt, suivez ces étapes générales. Assurez-vous d'avoir les droits nécessaires sur le serveur et que vous êtes à l'aise avec l'édition de fichiers de configuration en ligne de commande. Configurer Postfix pour utiliser SSL/TLS\n1. Accédez à la configuration de Postfix:\nConnectez-vous à votre serveur en tant que sudouser.\nOuvrez le fichier de configuration principal de Postfix avec un éditeur de texte, tel que ou . Le fichier est généralement situé à . 2. Définissez les chemins des certificats:\nLocalisez ou ajoutez les lignes suivantes dans pour spécifier l'emplacement des fichiers de certificat et de clé privée (remplacez les chemins par les vôtres si nécessaire) :\nActivez l'utilisation de TLS en ajoutant ou en s'assurant que la ligne suivante est présente : 3. Redémarrez Postfix:\nSauvegardez vos modifications et fermez le fichier.\nExécutez la commande pour appliquer les modifications. Configurer Dovecot pour SSL/TLS\nSi vous utilisez Dovecot comme serveur IMAP/POP3 : 1. Les fichiers de configuration de Dovecot se trouvent généralement dans . Le fichier principal de configuration est souvent nommé , et il peut inclure d'autres fichiers de configuration situés dans . 2. Dans les fichiers de configuration de Dovecot, vous devrez trouver et modifier les lignes qui définissent le chemin du certificat SSL et de la clé privée. Recherchez quelque chose comme ceci : Pensez à désactiver la configuration présente dans . 3. Redémarrez Dovecot avec . 4. Après le redémarrage, assurez-vous que tout fonctionne comme prévu. Vous pouvez vérifier que Dovecot écoute avec le nouveau certificat en vous connectant avec un client de messagerie ou en utilisant OpenSSL : Configurer Let's Encrypt pour le renouvellement automatique\n1. Certbot gère généralement les renouvellements automatiquement. Cependant, vous pouvez personnaliser ou ajouter des scripts de renouvellement dans le dossier de hooks de renouvellement. 2. Scripts de renewal-hooks:\nPlacez les scripts personnalisés dans . Vous pouvez avoir des scripts , , et pour s'exécuter avant, pendant, et après le renouvellement.\nUn script typique dans pourrait redémarrer Postfix et Dovecot pour appliquer les nouveaux certificats. Voir les pages : \nSi vous avez deux scripts distincts, et et vous souhaitez exécuter les deux après le renouvellement de certificat Let's Encrypt par Certbot, vous pouvez configurer les hooks dans le fichier de configuration de renouvellement de Certbot ou les placer dans les répertoires de hook appropriés. Vous devriez ajouter des lignes pour posthook dans la section . Votre fichier pourrait ressembler à ceci : 3. Tester le renouvellement:\nExécutez pour tester le processus de renouvellement et s'assurer que tout fonctionne comme prévu. Vérification et maintenance\nVérifiez les logs de Postfix et Dovecot pour les erreurs liées aux certificats SSL/TLS.\nAssurez-vous que les certificats se renouvellent correctement en vérifiant les dates d'expiration et en observant le comportement du système lors des renouvellements planifiés. Remarques\nFaites toujours une copie de sauvegarde des fichiers de configuration avant de les modifier.\nLes chemins exacts et les commandes peuvent varier légèrement en fonction de votre distribution Linux et de la version de vos logiciels.\nAssurez-vous que les ports nécessaires sont ouverts sur votre pare-feu pour permettre les connexions TLS/SSL. En suivant ces étapes, vous devriez être capable de configurer Postfix et Dovecot pour utiliser les certificats SSL/TLS avec Let's Encrypt, améliorant ainsi la sécurité de votre serveur de messagerie. Assurez-vous de tester votre configuration pour vérifier que tout fonctionne correctement avant de la mettre en production. Biblio\nhttps:www.tecmint.com/install-postfix-mail-server-with-webmail-in-debian/\nhttps:*wiki.centos.org/HowTos(2f)postfix.html"},{"uuid":"6016aa4b-f42b-43ef-9957-b893fa030a0c","slug":"mosquitto","title":"Mosquitto : client et serveur MQTT","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-03-14 07:45:19","created_at":"2023-03-14 07:45:19","updated_at":"2023-03-14 07:45:19","tags":[],"plain":"Mosquitto est un courtier de messages (ou broker / serveur MQTT) MQTT open source. Plus d'infos sur MQTT à la page . Mosquitto peut être utilisé pour implémenter des scénarios tels que la collecte de données de capteurs, la surveillance de l'état des appareils et la gestion de l'IoT en général. Les clients MQTT peuvent se connecter à Mosquitto pour publier et/ou recevoir des messages sur des topics spécifiques, permettant une communication efficace et fiable entre les appareils. Dans cet article j'installe Mosquitto sur Rasbperry Pi. Le port par défaut 1883/tcp sera utilisé. Installer le service Mosquitto\nVoici les étapes générales pour installer Mosquitto sur Rasbperry Pi OS, Debian ou Ubuntu : Après l'installation, vous pouvez vérifier si Mosquitto est en cours d'exécution en utilisant la commande dans l'invite de commandes. Cela devrait afficher la version de Mosquitto et les informations de journalisation. Vérifier l’accessibilité du service\nPour vous assurer que le port Mosquitto est ouvert, vous pouvez utiliser un outil en ligne de commande comme nmap pour scanner votre adresse IP publique et vérifier si le port 1883 est ouvert. Par exemple, en utilisant la commande suivante : . Si le port Mosquitto est ouvert, vous devriez voir une ligne dans la sortie de la commande qui indique que le port 1883 est \"open\". Je conseille d’exécuter sur un autre ordinateur que celui qui exécute le service Mosquitto. Configurer la connexion identifiée\nLa connexion à Mosquitto peut être anonyme ou avec un nom d'utilisateur et un mot de passe, selon la configuration du serveur. Dans se paragraphe nous abordons la configuration d'un utilisateur. Pour créer un utilisateur et de définir un mot de passe afin d'accéder à Mosquitto, il faut utiliser l'utilitaire qui est installé avec Mosquitto et permet de gérer les informations d'identification des utilisateurs pour Mosquitto. sudo mosquittopasswd -c /etc/mosquitto/passwd UTILISATEUR Plus spécifiquement, cette commande effectue les actions suivantes :\npermet d'exécuter la commande avec des privilèges d'administrateur pour pouvoir écrire dans le dossier /etc/mosquitto où se trouve le fichier de mots de passe.\nest l'utilitaire de ligne de commande pour gérer le fichier de mots de passe.\ncrée un nouveau fichier de mots de passe s'il n'existe pas déjà, ou remplace un fichier existant.\nest le chemin d'accès complet au fichier de mots de passe à créer ou modifier.\nest le nom d'utilisateur à ajouter au fichier de mots de passe. Vous pouvez remplacer ce nom d'utilisateur par le nom que vous souhaitez utiliser. Une fois que vous avez créé le fichier de mots de passe et ajouté des utilisateurs, vous pouvez utiliser ces informations d'identification pour restreindre l'accès à Mosquitto, en configurant l'authentification basée sur le nom d'utilisateur et le mot de passe dans le fichier de configuration de Mosquitto. Cela est particulièrement important si vous utilisez Mosquitto dans un environnement de production ou si vous souhaitez sécuriser l'accès à votre broker MQTT. Vous devez modifier le fichier de configuration de Mosquitto pour autoriser l'authentification basée sur le nom d'utilisateur et le mot de passe. Ouvrez le fichier de configuration de Mosquitto. Le fichier peut être situé à différents endroits en fonction de votre installation. Par exemple, sur une installation standard de Mosquitto sous Linux, le fichier se trouve généralement dans . Ajoutez les lignes suivantes au fichier de configuration pour spécifier le chemin d'accès au fichier de mots de passe que vous avez créé avec , ainsi que les paramètres d'authentification : passwordfile /etc/mosquitto/passwd\n allowanonymous false Enregistrez le fichier de configuration et redémarrez le service Mosquitto pour que les modifications prennent effet :\n \n sudo systemctl restart mosquitto Après avoir suivi ces étapes, les utilisateurs devront s'authentifier avec un nom d'utilisateur et un mot de passe valides pour publier et souscrire à des messages dans Mosquitto. Si l'utilisateur n'a pas les bonnes informations d'identification, il sera refusé d'accès. Cette fonctionnalité de sécurité renforce la sécurité de Mosquitto et permet de restreindre l'accès à des utilisateurs de confiance uniquement.\n \nConfigurer la connexion anonyme\nLa connexion à Mosquitto peut être anonyme ou avec un nom d'utilisateur et un mot de passe, selon la configuration du serveur. Dans ce paragraphe nous abordons la configuration pour une connexion anonyme. Pour indiquer que la connexion au serveur MQTT est anonyme (sans nom d'utilisateur ni mot de passe), vous devez ajouter les lignes suivantes dans votre fichier de configuration : allowanonymous true Ceci autorisera les connexions anonymes au serveur MQTT. Si cette option n'est pas définie, toutes les connexions nécessiteront un nom d'utilisateur et un mot de passe valides. Assurez-vous de redémarrer le serveur MQTT après avoir modifié le fichier de configuration pour que les modifications prennent effet. Notez que l'utilisation de connexions anonymes peut présenter des risques de sécurité, car cela permet à n'importe qui de se connecter et de publier ou de recevoir des messages sans authentification. Il est donc recommandé d'utiliser des informations d'authentification sécurisées pour protéger votre serveur MQTT.\nEnvoyer / recevoir des messages MQTT\nMosquitto-clients est un outil en ligne de commande fourni avec le broker Mosquitto pour publier et souscrire à des messages MQTT à partir de la ligne de commande. En d'autres termes, Mosquitto-clients permet aux développeurs et aux administrateurs de système de tester et de déboguer des applications MQTT en utilisant des commandes simples pour publier et recevoir des messages. Cela peut être utile pour vérifier la connectivité, le flux de données et le traitement des messages entre les appareils et le broker Mosquitto. Pour installer les clients Mosquitto, y compris le client de ligne de commande et le client d'envoi , vous pouvez suivre ces étapes : sudo apt update\n sudo apt install mosquitto-clients Vous pouvez maintenant utiliser les clients Mosquitto pour publier et souscrire à des messages dans Mosquitto. Par exemple, vous pouvez utiliser la commande pour <u>publier des messages MQTT</u> à un topic : mosquittopub -h localhost -t sensor/elec -m 2546 Par exemple vous pouvez utiliser la commande pour souscrire au topic et <u>recevoir des messages MQTT</u> : mosquittosub -h localhost -t \"sensor/elec\""}] |