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.

L’utilisation d’un relais tel que Microsoft 365 facilite la sécurisation de nos échanges mails, car une intégration de DKIM et DMARC est déjà gérée nativement! Si vous avez déjà vos mails ou l’ensemble de votre active directory, c’est dans cette direction qu’il faut se diriger pour une mise en place efficace.

Je suppose qu’il est possible de faire cela également avec Infomaniak pour ceux disposant de comptes pro chez eux. Avec mon compte perso je n’ai pas vu cette option. Avec OVH, oubliez directement! Du temps où j’étais encore client chez eux, j’avais parlé DKIM DMARC au support, et on m’a posés des questions pour savoir pourquoi je veux ces fonctions etc. Vraiment comme si j’étais un extraterrestre! On était tout de même en 2020… Rien n’était fait pour le mail mutualisé donc… Longtemps client perso et pro je suis passé chez Infomaniak pour la partie mutualisée en partie pour cela. J’arrête le OFF là

Configuration dans l’Exchange 365

Il faut créer un connector dans mail flow > connectors > Add a connector :

L’authentification est faite par adresse IP ou certificat valide. Il faut savoir que votre serveur relais interne postfix va lui-même se connecter sur VOTRE_DNS.mail.protection.outlook.com et celui-ci présente un certificat valide. Votre « client » va donc authentifier le serveur de Microsoft comme valide (notre serveur relais est client par rapport au relais M365).

L’authentification par IP est déjà suffisante en soit. Mais vous pouvez décider que les serveurs relais de Microsoft n’acceptent QUE les mails si le serveur client (votre relais SMTP) présente le bon certificat client. Ce qui fait qu’il y a une identification et authentification de part et d’autre!

• Configurer une restriction par votre IP publique de sortie :

• Configurer une restriction par un certificat valide : dans ce cas cela ne doit pas forcément être le certificat *.votredomain.tld, cela peut très bien être monrelais.mondomainetechnique.tld. La seule règle étant que ce certificat soit émis par une autorité de certification reconnue.

Mettre un certbot avec let’s encrypt sur votre serveur est envisageable si vous utilisez une vérification let’s encrypt par dns.

Si vous souhaitez plus d’infos, la documentation Microsoft est bien faite.

Remarque : Les limites d’envoie pour M365 sont larges et dépendent de votre licence.

Un mot sur le serveur Postfix

Il faut tout de suite savoir que Postfix est à la fois un serveur et un client. Il faut donc bien distinguer les directives. Veillez donc bien au début qui peut être :

• smtp_tls_xxx en tant que client
• smtpd_tls_xxx en tant que serveur

Notre serveur relais est serveur par rapport à nos serveurs internes. Il est client par rapport à Microsoft 365.

Configuration de notre relais mail Postfix

J’ai distingué les directives serveurs et clients pour que la configuration soit lisible.

Pour le comportement serveur du relais SMTP :

• smtpd_tls_security_level=may permet de spécifier que notre serveur accepte une liaison client en TLS mais également en clair. Il faut penser aux copieurs ou autre matériel ne gérant pas le TLS interne à notre réseau
• smtpd_tls_loglevel permet d’avoir une trace des connexions TLS dans les logs avec les ciphers pris en compte, pratique pour voir quel client envoie encore en clair et s’il peut être modifié
• smtpd_tls_cert_file et smtpd_tls_key_file renseignent le certificat et la clé utilisé en interne
• smtpd_tls_chain_files est le nouveau format pour pouvoir contenir plusieurs clés et certificats pour différents noms de domaine. Il faut toujours la clé et puis la chaîne de certificat et le certificat final
• smtpd_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés

### SERVER ###
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1

smtpd_tls_cert_file=/etc/xxx.crt
smtpd_tls_key_file=/etc/xxx.key
#alternative
#smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all

#optionel
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache



### CLIENT ###
relayhost = your-domain.mail.protection.outlook.com
smtp_tls_security_level = encrypt # optionnel : secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
#optionnel
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_chain_files = /etc/xxx.all

Pour le comportement client du relais SMTP :

• relayhost on vient mettre le DNS de notre tenant M365
• smtp_tls_security_level le niveau de securité minimal accepté en TLS. Je vous conseille secure
• smtp_tls_mandatory_ciphers high contient un « bundle » de ciphers satisfaisant
• smtp_tls_loglevel permet d’avoir une trace des connexions TLS
• smtp_tls_CAfile permet de spécifié le fichier des CA faisant autorité. Un fichier du système contient déjà les CA connus du monde
• smtp_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés
• smtp_tls_chain_files spécifiez la chaine de certificats client qui est utiliser si vous aviez choisi une restriction par un certificat client pour votre connector M365. L’ordre dans la chaine est importante : votre clé privée, suivie de votre certificat, ensuite le certificat intermédiaire et pour finir le certificat du CA

host xxx.mail.protection.outlook.com[104.47.2.7] said: 550 5.4.1 Recipient address rejected: Access denied. AS(201776281) [AB4EUR01RT057.eop-EUR01.prod.protection.outlook.com] (in reply to RCPT TO command)

postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: matched peername: *.mail.protection.outlook.com
postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: subject_CN=mail.protection.outlook.com, issuer_CN=DigiCert Cloud Services CA-1, fingerprint=6A:DD:32:6D:2A:0C:C5:3A:9E:D7:E7:91:3D:6F:5C:F4, pkey_fingerprint=20:78:41:CD:EC:4F:19:7A:E0:B2:01:4F:3C:3D:1C:EE
postfix/smtp[71318]: Verified TLS connection established to your-domain.mail.protection.outlook.com[104.47.0.36]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Fichier main.cf d’un relais SMTP Postfix complet :

myorigin = /etc/hostname
mydomain = your-local-domain
mydestination = $myhostname, $myorigin, localhost.localdomain, localhost, localhost.your-local-domain

# Backward compatibility off
compatibility_level = 3.6
relay_domains = $mydestination
append_dot_mydomain = yes
smtputf8_enable=yes
smtpd_banner = $myhostname ESMTP
biff = no
readme_directory = no

# TLS parameters server
smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all
#alternative
#smtpd_tls_cert_file=/etc/xxx.cer
#smtpd_tls_key_file=/etc/xxx.key
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# TLS parameters client
relayhost = xxx.mail.protection.outlook.com
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# Client certificat to be identified by M365
#smtp_tls_chain_files = /etc/xxx.all

smtpd_client_restrictions = permit_mynetworks reject
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

mynetworks = 10.0.0.0/22,xxx
mailbox_size_limit = 0
message_size_limit = 29480000
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

header_checks = regexp:/etc/postfix/header_checks_regexp
smtp_header_checks = regexp:/etc/postfix/replace_header_checks_regexp

sender_canonical_maps = regexp:/etc/postfix/sender_canonical_regexp

Configuration d’un serveur client interne linux

Voici la partie TLS d’un fichier main.cf d’un postfix « satellite » qui se connecte à notre relais interne. Il dois évidement avoir le certificat serveur de notre relais ou notre CA interne de configuré dans les certificats du système ou via la directive smtp_tls_CAfile.

smtp_tls_security_level = may
smtp_tls_loglevel = 1
#optionnel
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

L’article Relais mail Postfix – envoyer ses mails sécurisés vers M365 est apparu en premier sur Mon linux.

J’explique ici le cas où le suffixe DNS interne est yourdomain.lan et le domaine externe est your-domain.tld

D’abord il faut distinguer 2 types de mails :

• Ceux envoyés directement à partir de la machine ou une de ses applications locales
• Ceux envoyés depuis la machine qui fait office de relais.

Ce sont bien 2 choses différentes pour postfix et donc 2 types de filtre différents.

Filtre de sortie pour les mails générés sur la machine

sender_canonical_maps = regexp:/etc/postfix/sender_canonical_regexp

/^(.*)@(.*)\.your-local-domain\.lan$/ ${2}-${1}@your-domain.tld
/^(.*)\ <(.*)@(.*)\.your-local-domain\.lan>$/ ${1} <${3}-${2}@your-domain.tld>

postmap /etc/postfix/sender_canonical_regexp

Vous pouvez toujours ajouter un « catch all » à la fin comme décrit dans l’article précédent de réécriture de mail simple avec postfix.

Filtre de sortie pour les mails transitant sur notre relais interne

Typiquement vous avez un relais mail interne utilisé par vos autres serveurs. Il faut dans un premier temps ajouter votre adresse IP publique de sortie dans le champ SPF de votre nom de domaine. Le DKIM et DMARC permettent de sécurisé encore mieux l’authenticité de vos messages, mais une chose à la fois

Vous pouvez utilisez la directive header_checks ou smtp_header_checks. Dans mon cas j’ai besoin de faire 2 opérations pour le même filtre mail, ce qui n’est pas possible de base. Mais en jouant avec ces 2 directives, je peux arriver à mes fins : marquer les mails à problème et faire une réécriture de mail :
ATTENTION à l’ordre : c’est d’abord header_checks qui est interprété et ensuite smtp_header_checks. Il faut d’abords mettre le WARN et ensuite le REPLACE

header_checks = regexp:/etc/postfix/warn_checks_regexp
smtp_header_checks = regexp:/etc/postfix/header_checks_regexp

/^From:\ (.*)@(.*)\.yourdomain\.lan$/ WARN bad sender
/^From:\ (.*)\ <(.*)@(.*)\.yourdomain\.lan>$/ WARN bad sender

/^From:\ (.*)@(.*)\.your-local-domain\.lan$/ REPLACE From: ${2}-${1}@your-domain.tld
/^From:\ (.*)\ <(.*)@(.*)\.your-local-domain\.lan>$/ REPLACE From: ${1} <${3}-${2}@your-domain.tld>

postmap /etc/postfix/warn_checks_regexp
postmap /etc/postfix/header_checks_regexp

Le reste de votre configuration postfix dépendra :

• Si vous envoyez directement les mails vers Internet, auquel cas je vous conseille de configurer les signatures DKIM et d’utiliser le record DNS DMARC
• Si vous utilisez un serveur relais tel que M365 si vous y géré déjà vos services mails

L’article Réécriture de mail – serveur relais postfix est apparu en premier sur Mon linux.

Envoi de mail via un compte mail unique SASL

Dans le cas, il faut réécrite tout champ mail : que ce soit le corps ou l’enveloppe. Cela doit correspondre au mail du compte, afin d’éviter d’être considéré comme spam malgré l’utilisation d’un compte mail légitime.

/.+/ nas@monemail.tld

sender_canonical_maps = regexp:/etc/postfix/sender_canonical

postmap /etc/postfix/sender_canonical

service postfix restart

postmap -q root@localhost.localhost regexp:/etc/postfix/sender_canonical
nas@monemail.tld

postmap /etc/postfix/sender_canonical_regexp

Plus d’info sur la directive sender_canonical_maps sur la documentation officielle.

Je vous conseille d’utiliser mailjet pour ne pas utiliser directement les identifiants de votre provider mail. Ou du mois utilisé un token API et pas votre mot de passe principal. C’est plus sécurisant, surtout si c’est pour un VPS.

compatibility_level = 2
mydomain = nas.local
mydestination =
inet_interfaces = localhost
relayhost = in-v3.mailjet.com:587
sender_canonical_maps = regexp:/etc/postfix/sender_canonical
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_mechanism_filter =
smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_CApath = /etc/ssl/certs
alias_maps = hash:/etc/aliases
default_destination_concurrency_limit = 2
default_destination_rate_delay = 1s
smtputf8_enable = no
default_transport = smtp

in-v3.mailjet.com:587 votremail@votredomaine.tld:motdepasse

L’article Réécriture de mail simple avec postfix est apparu en premier sur Mon linux.

Installation de certbot

Dans ce cas-ci, il sera installé sur le serveur Apache directement. Suivez d’abord les instructions d’installation selon votre système.

Sous Debian 9, faites directement ceci :

apt-get install certbot python-certbot-apache

Validation d’un seul domaine via let’s encrypt

Pour valider un seul domaine pour un certificat, il faut déjà avoir créé la configuration du site en HTTP. Certbot se chargera de demander le certificat à let’s encrypt et de créer une configuration de site identique en HTTPS, vous n’aurez rien à faire côté Apache. Vous aurez la possibilité de choisir de rediriger les utilisateurs depuis http vers https.

Exécutez ceci et suivez les instructions :

certbot --apache

Pour prendre en compte la modification, rechargez Apache :

service apache2 reload

Par la suite, un renouvellement de certificat pourra se faire via :

certbot renew

Un certificat let’s encrypt n’est valide que 3 mois. Il faut donc le renouveler tous les 3 mois. Heureusement un cron permet de le faire automatiquement, vérifiez que celui-ci est bien présent /etc/cron.d/certbot :

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Validation d’un certificat multi-domaine

Afin de valider un certificat multi-domaine, il faut spécifier ces domaines via des arguments de certbot. Bien évidemment pour le renouvellement il n’y aura rien de spécial à faire, cela suit la même procédure qu’un domaine seul.

Il faut exécuter manuellement:

certbot-auto --apache -d domaineprincipal.tld -d www.domaineprincipal.tld -d ...

Le premier domaine sera utilisé comme domaine principal, tous les autres seront utilisés comme domaines secondaires, appelé « SAN Certificates« . Cela signifie « Subject Alternative Name ».

Notre certificat multi-domaine a été installé directement dans la configuration Apache par Certbot, il suffit d’un reload de la configuration Apache.

L’article Créer un certificat multi-domaine let’s encrypt avec Apache est apparu en premier sur Mon linux.

Vous pouvez installer le contrôleur sur un serveur linux, windows ou macOS. C’est du java avec une base de données MongoDB. Il tourne très bien sur un serveur qui héberge aussi mon nextcloud, deluge, samba, etc. Mais mon « souci » est qu’il fonctionne sur un port alternatif et je voudrais le rendre disponible sur le port HTTPS où tourne déjà mon Apache avec nextcloud, un proxy pour deluge-web, let’s encrypt, etc.

L’accès à la gestion des clients et AP du contrôleur se fait via une page web principalement. Il existe aussi une application android. Il faut bien comprendre que sans contrôleur, on ne sait pas manager les AP. Donc ces AP ne disposent pas d’une page web d’administration comme les autres AP du marché grand public ou semi-pro.

L’application Android permet toutefois de faire un mode disvovery et faire une simple installation AP pour un seul réseau. Mais pour ce qui est de diffuser 2 SSID simultanés, de passer par un portail captif, etc. Il vous faut un contrôleur.

Pour lier un AP au contrôleur Unifi à distance, cela se fait soit via Unifi-discover sur pc (il faut être sur le même réseau ethernet layer2) ou via une app android Unifi. Les méthodes sont décrites sur la guideline d’Ubiquiti.

Je vous livre ma configuration d’Apache pour se connecter en HTTPS pour sécuriser l’accès à distance au contrôleur Unifi. Et ce sera avec une URL plus classe que http://unify.domain.com:8080/inform

Installer le paquet Unifi nécessaire

Vous pouvez récupérer le paquet le plus récent du software Unifi. Un paquet deb est dispo pour ceux qui sont sous Debian ou Ubuntu.

dpkg -i /disk/upload/unifi_sysvinit_all.deb
unifi depends on mongodb-server (>= 2.4.10) | mongodb-10gen (>= 2.4.14) | mongodb-org-server (>= 2.6.0); however:
Package mongodb-server is not installed.
Package mongodb-10gen is not installed.
Package mongodb-org-server is not installed.
unifi depends on openjdk-7-jre-headless | java8-runtime-headless; however:
Package openjdk-7-jre-headless is not installed.
Package java8-runtime-headless is not installed.
apt-get -f install

L’accès se fait via : https://localhost:8443
Attention que le premier réseau utilisable dans l’AP est en mode untagged

L’url pour joindre un second contrôleur : controller inform URL http://unify.domain.com:8080/inform

Mettre un proxy revers apache pour du WSS sur /wss et du http à la racine :

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/unify.domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/unify.domain.com/privkey.pem

# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode

# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
# keep the host
ProxyPreserveHost On

# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass /wss wss://127.0.0.1:8443/wss retry=0
ProxyPassReverse /wss wss://127.0.0.1:8443/wss
ProxyPass / https://127.0.0.1:8443/ retry=0
ProxyPassReverse / https://127.0.0.1:8443/
ProxyPreserveHost On

L’accès au contrôleur Unifi se fait maintenant via https://unify.domain.com

L’article Configurer son contrôleur Ubiquiti UniFi dans son proxy Apache est apparu en premier sur Mon linux.